Re: [6lowpan] "Link-Local Routing" versus "Network-Layer Routing"

[gabriel montenegro <[e-mail]>]

Hi Tim,

There is an incorrect assumption in the message below: 

The 6lowpan "Transmission of IPv6 Packets over IEEE 802.15.4 Networks"
draft specifies that the link-local portion of an IPv6 address is
actually the 64-bit or 16-bit [link-layer] address used by 802.15.4.


6lowpan does not mandate such a relationship. It only says that if it does in fact
exist, then here is how to take advantage of it. The fact that this is not being mandated
should be evident from the text in section 10.1:

   the IPv6 interface identifiers (bottom 64
   bits) for the source or destination addresses can be inferred from
   the layer two source and destination addresses (of course, this is
   only possible for interface identifiers derived from an underlying
   802.15.4 MAC address); ...
      IC:  Interface identifier elided (derivable from the corresponding
         link-layer address).  If applied to the interface identifier of
         either the source or destination address when routing in a mesh
         (Section 11), the corresponding link-layer address is that
         found in the "Mesh Addressing" field (Section 5.2).
Notice that the above is merely an optimization, and one applied to the IPv6 header compression scheme.
As such, it is orthogonal and independent to the mesh delivery support. We want that independence as 
the IPv6 header compression works only for IPv6, whereas the lowpan layer (including the mesh delivery)
works independently of the protocol being transported in this link. In other words, you could use the lowpan
layer for IPv4, appletalk, or any other protocol. 

So your suggested wording below is not true in general,  but it may apply in a meaningful subset of possible cases.

-gabriel

----- Original Message ----
From: Timothy J. Salo <[e-mail]>
To: [e-mail]; 6lowpan <[e-mail]>
Sent: Friday, July 13, 2007 1:27:45 PM
Subject: [6lowpan] "Link-Local Routing" versus "Network-Layer Routing"

The document "Routing Requirements for Low Power And Lossy Networks"
(draft-culler-rl2n-routing-reqs-01) contains lots of good information
and identifies a number of topics that require additional thought.

This e-mail responds to Section 3, "'Route over' versus 'Mesh under,",
which includes the following language:

 > Clearly routing techniques can be defined at the link layer (also
 > referred as to the "Mesh Under" approach).  By contrast, the "Route
 > over" approach exclusively relies on IP routing over a network made
 > of a variety of nodes interconnected by links of various nature.  The
 > aim of this document is to define the routing requirements L2Ns at
 > the IP layer.  As such, it pertains to collections of IEEE 802.15.4
 > devices, but is not limited to communication within a single IP link.
 > It pertains to IP level routing among multiple such PANs, routing
 > among IEEE 802.15.4 PANs and other links, and routing in other low
 > power (wireless) networks.

In short, we are using a model that the 6lowpan Working Group is
developing a link-layer routing protocol.  Of course, being the IETF,
we don't want to actually say that, which apparently motivated the
creation of the opaque term "mesh under".  I propose an alternative
model of the 6lowpan routing activity that, I claim, fits the facts just
as well as does the link-layer routing model.  More importantly, this
alternative model will be more useful is helping us think about and
write about the type of routing being developed by the 6lowpan Working
Group.

The 6lowpan "Transmission of IPv6 Packets over IEEE 802.15.4 Networks"
draft specifies that the link-local portion of an IPv6 address is
actually the 64-bit or 16-bit [link-layer] address used by 802.15.4.
Stated differently, if I give you a 64-bit or a 16-bit address as used
in the 6lowpan format document, you won't be able to tell me whether it
is really an 802.15.4 link-layer address or an IPv6 link-local address
(because, as specified in the format document, a particular address
is used for both purposes).  For that matter, the routing protocol
won't be able to tell you whether the address is a link-layer or a
[elided] network-layer address.  In some sense, all I am suggesting is
that we emphasize the network-layer use, rather than the link-layer
origin, of these 64-bit and 16-bit 802.15.4/link-local addresses.

Given this context, I propose that the type of routing that the 6lowpan
Working Group is developing can be better described as [IP,
network-layer] "link-local routing".  That  is, it is really
network-layer routing, but its scope is restricted to a single IPv6
link.  And, because the scope of this routing protocol is restricted to
a single IPv6 link, the protocol transports only elided IPv6 addresses,
namely only the link-local portion of the IPv6 addresses.

I will try, in the next few days, to draft alternative language for
Section 3 of the Culler draft that describes the 6lowpan routing
work as creating a network-layer, link-local, routing protocol.

-tjs


_______________________________________________
6lowpan mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/6lowpan

_______________________________________________
6lowpan mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/6lowpan