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

From: gabriel montenegro <[email-masked]>
Date: Fri, 13 Jul 2007 18:01:41 -0700 (PDT)

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 <[email-masked]>
To: [email-masked]; 6lowpan <[email-masked]>
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-bitFrom [email-masked] Mon Aug 06 10:17:28 2007
Subject: RE: [RSN] Comments on draft-dokaspar-6lowpan-routreq-02
From: Geoff Mulligan <[email-masked]>
To: [email-masked]
Date: Wed, 18 Jul 2007 12:03:29 -0600
Cc: '6lowpan' <[email-masked]>, [email-masked]

Very interesting and provocative question you pose at the end of your
message - "do we need mesh under?" I think and hope that this will
generate some discussion on the list. 

I suspect that there are people on the list that will argue that mesh
under is fact (it is deployed today) and that of course we need mesh
under and will use standard layer 3 routing between 6lowpan subnets.
Currently this is the thinking within SP100 for industrial wireless.

802.15.5 is certainly looking at and, I think, plans to standardize on a
two different mesh under designs/protocols.

Utilizing trill is an interesting thought.  I don't yet know enough
about trill to comment on it's applicability.

Certainly the manet protocols might be applicable.

What is critical to this discussion is that if 6lowpan does not select
or generate a mesh under protocol (if one is necessary and used) then
there will not be interoperability between multi-hoping nodes.  If
mesh-under is not used (but router over is used for multi-hopping) then
all 6lowpan nodes can exchange packets and forward packets (but we need
to understand the implications of one node per subnet).

	geoff

On Wed, 2007-07-18 at 06:53 -0700, dculler wrote:
> The argument for route-over is pretty simple.
>  
> 1. In the vast majority of wireless sensor networks in existance the
> dominant communication pattern is data collection (from nodes in the
> PAN to IP-based computers external to the PAN) and control actions
> (from controllers external to the PAN to devices within the PAN).
> There are cases where data collection point and/or the controller is a
> gateway device on the PAN, but this physical collocation is rather
> artificial.  If is far more typical that where a gateway is deployed
> it is used to bridge communication to other networks.  
>  
> This is true not only for wireless instrumentation, but wired
> instrumentation as well.  See for example
>  
> BACNET: http://www.bacnet.org/Tutorial/HMN-Overview/sld028.htm and
> http://www.bacnet.org/Tutorial/HMN-Overview/sld 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

_______________________________________________
RSN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rsn

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 13 Jul 2007 18:01:41 -0700 (PDT)

Hi Tim,

-gabriel

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

-tjs