[net2-wg] Network level names and mapping

[Rodrigo Fonseca]

That sounds like the right thing to do.

About maintaining the mapping, is the LinkSrcPacket the right way to go?

Thanks,
Rodrigo


On 4/21/06, Philip Levis <pal at cs.stanford.edu> wrote:
> On Apr 21, 2006, at 2:07 PM, Rodrigo Fonseca wrote:
>
> > Hi,
> >
> > Om an I had a long chat yesterday about how to deal with the mapping
> > of names for the network layer and the link layer.
> >
> > We want to provide a separation between network-level names (a unique
> > identifier per node), from link level names ("interfaces", radios, or
> > mac-addresses are examples). The motivating example is a node with two
> > radios, which will look like two links at the link layer, but will be
> > one network level entity, the node.
> >
> > So far in TinyOS these have been clumped together as the
> > TOS_LOCAL_ADDRESS.
> >
> > That said, the link estimator will only care about link layer
> > addresses. These are the addresses you send active messages to, your
> > one-hop neighbor addresses. However, the network layer (in our case
> > for now the TreeRoutingEngine) will want to keep mappings of network
> > layer names. To keep that mapping, it will need two things:
> >
> > 1. a node will add its own network level name in its outgoing hello
> > messages, say nw_addr.
> > 1.5 upon receiving this message, the network layer component at the
> > other node will know which nw_addr this message came from.
> >
> > 2. to establish the mapping between nw_addr and link level addresses
> > (ll_addr), upon receiving such a packet, the node will have to query
> > the entity it received it from for the link level source address.
> >
> > The way we thought this should be done is the following. The Receive
> > interface for the TreeRoutingEngine is provided by the
> > LinkEstimatorReceiver. This module should also provide a LinkSrcPacket
> > interface, which would return the ll_addr for this packet.
>
> In 2.x, there is such a distinction: there's the am_addr_t associated
> with a packet interface, and there's a TOS_NODE_ID, which identifies
> the node itself. In my first (not yet compiling) stab at the
> ForwardingEngine, the source address from Send is TOS_NODE_ID, but I
> assume that the per-hop source and dest are am_addr_t types.
>
> Right now, it is not exactly specified with TOS_NODE_ID is; there's
> been talk about writing a TEP about it (Gil took a stab at IEEE EUIDs
> a while ago).
>
> Phil
>