Subject: Re: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-routing-requirements-04

From: JP Vasseur <[email-masked]>
Date: Fri, 7 Aug 2009 10:36:40 +0200

Hu Eunah,

On Jul 28, 2009, at 6:06 PM, Eunsook Eunah Kim wrote:

> Dear 6lowpaners,
>
> The draft of 6lowpan routing requirements are revised to -04, applying
> the comments at the meeting.
> JP worries the term *routing* in adaptation layer, and Eric gave us a
> good terminology to use there.
> Now you will find the description under the figure to reduce the
> confusion between "IP routing" and "mesh-under path computation +
> forwarding". :-)
>
> I would like to point out again that the figure is to show the basic
> architecture based on RFC4944 and WG concensus so far.
>
> Please check the revised version and give your comments.
>

Just to make sure that we are on the same page, I am not so much worried
about the terminology but the architecture here ...

cut and paste from the ID:

Figure 1 shows the place of 6LoWPAN routing in the entire network
    stack.

     +-----------------------------+    +-----------------------------+
     |  Application Layer          |    |  Application Layer          |
     +-----------------------------+    +-----------------------------+
     |  Transport Layer (TCP/UDP)  |    |  Transport Layer (TCP/UDP)  |
     +-----------------------------+    +-----------------------------+
     |  Network Layer (IPv6)       |    |  Network       +---------+  |
     +-----------------------------+    |  Layer         | Routing |  |
     |  6LoWPAN       +---------+  |    |  (IPv6)        +---------+  |
     |  Adaptation    | Routing*|  |    +-----------------------------+
     |  Layer         +---------+  |    |  6LoWPAN Adaptation Layer   |
     +-----------------------------+    +-----------------------------+
     |  IEEE 802.15.4 (MAC)        |    |  IEEE 802.15.4 (MAC)        |
     +-----------------------------+    +-----------------------------+
     |  IEEE 802.15.4 (PHY)        |    |  IEEE 802.15.4 (PHY)        |
     +-----------------------------+    +-----------------------------+
     * Here, 'Routing' is not equivalent to IP routing,
       but includes the functionalities of path computation and
       forwarding under the IP layer.

In our world, routing is performed at the IP layer (RPL) so as to run  
on a myriad of L2.
Routing in an adaptation layer makes no sense to me. Perform L2  
meshing/routing is
a reality of course, and I personally believe that trying to combine  
L2 meshing with L3
routing in our world is completely wrong but this is another discussion.

For example, you write:

"When a 6LoWPAN follows the Mesh Under configuration, the LoWPAN Edge
    Router (ER) is the only IPv6 router in the 6LoWPAN (see Figure 3).
    This means that the IPv6 link-local scope includes all nodes in the
    LoWPAN.  For this, a Mesh Under mechanism MUST be provided to  
support
    multi-hop transmission."

Who is the normative MUST for ?

Back to L2 meshing/routing, if there must be document somewhere I truly
believe that this should go in some white paper or a book, not sure  
that we
need an IETF requirement document. If the objective is to provide  
requirements
for L2 meshing/routing, then it should be discussed with the SDO in  
charge on
these L2 technologies.

Still, there is good data in the document and I would be happy to  
discuss on how
we could make some use of it.

Thanks.

JP.

> -eunah
>
> ---------- Forwarded message ----------
> From: IETF I-D Submission Tool <[email-masked]>
> Date: Tue, Jul 28, 2009 at 5:57 PM
> Subject: New Version Notification for draft-ietf-6lowpan-routing- 
> requirements-04
> To: [email-masked]
> Cc: [email-masked], [email-masked], [email-masked]
>
>
>
> A new version of I-D, draft-ietf-6lowpan-routing-requirements-04.txt
> has been successfuly submitted by Eunsook Kim and posted to the IETF
> repository.
>
> Filename:        draft-ietf-6lowpan-routing-requirements
> Revision:        04
> Title:           Problem Statement and Requirements for 6LoWPAN  
> Routing
> Creation_date:   2009-07-28
> WG ID:           6lowpan
> Number_of_pages: 32
>
> Abstract:
> 6LoWPANs are formed by devices that are compatible with the IEEE
> 802.15.4 standard.  However, neither the IEEE 802.15.4 standard nor
> the 6LoWPAN format specification define how mesh topologies could be
> obtained and maintained.  Thus, it should be considered how 6LoWPAN
> formation and multi-hop routing could be supported.
> This document provides the problem statement and design space for
> 6LoWPAN routing.  It defines the routing requirements for 6LoWPAN
> networks, considering the low-power and other particular
> characteristics of the devices and links.  The purpose of this
> document is not to recommend specific solutions, but to provide
> general, layer-agnostic guidelines about the design of 6LoWPAN
> routing, which can lead to further analysis and protocol design.
> This document is intended as input to groups working on routing
> protocols relevant to 6LoWPAN, such as the IETF ROLL WG.
>
>
>
> The IETF Secretariat.
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 7 Aug 2009 15:10:37 +0200

On Aug 7, 2009, at 10:36, JP Vasseur wrote:

 > In our world, routing is performed at the IP layer (RPL) so as to  
run on a myriad of L2.

JP,

too bad we didn't have time during the 6lowpan meeting to continue
the discussion in Stockholm when it became interesting.

To understand the confusion, you have to look back about three decades.

In the mid-1970s, there was a gold-rush by different entities to
establish their network architecture as the global standard.
Everything about interoperability that we now take for granted in the
Internet was unreachable utopia by then.

The Open Systems Interconnection (OSI) project at ISO decided to
develop a *Reference Model*, which was to bring order into the chaos
by *prescribing* a layered architecture for the standardization that
was going to be planned.
You need to understand that ISO 7498 was much less a technical than a
political document, trying to reign in the diverging lines of
development.

We all know where OSI went.  However, the seven-layer model has become
such a striking idol of network architecture that it has been used for
introductory courses in networking ever since, even though it has been
completely irrelevant for 15 years.

The ARPANET/Internet community developed its own architecture, with
TCP (later split into TCP/IP) at the middle, applications on top, and
subnetworks below.  This architecture has been written up in RFC 1122,
section 1.1 -- please read.  Note that when RFC 1122 talks about
a link layer, it means the link to one of the subnetworks making up
the Internet, not the subnetworks themselves -- the Internet
architecture is subnetwork architecture agnostic!  The *gateways* that
speak a link layer protocol to the subnetworks only became *routers*
later.

The important observation is that OSI was a prescriptive full-stack
model, designed essentially to ward off alternative designs.  In
contrast, the Internet architecture is a descriptive model of the
layers around the Internet layer, with decreasing focus as we go
further away from the Internet layer.

In recent research, it has become clearer and clearer that the
fixed-layers OSI model is constraining development and its
straitjacket needs to be discarded to be able to move on.  It is
extremely unfortunate that we continue to describe protocol
*functions* by OSI *layer* numbers:

-- the OSI layer numbers don't fit the Internet model. E.g., TCP
covers both L4 and certain parts of L5 in the OSI model.  Of course,
as the OSI model is only used as an idol and not as the actual
obsolete specification it is now, nobody remembers that, so for many
TCP now is a "layer 4" protocol.

-- many functions are performed by multiple layers in the OSI model
(e.g., reliability, flow control).  Many functions *not* performed by
a specific OSI layer *are* performed by the most equivalent layer in a
modern architecture and v.v.

-- the strict layering no longer works (see above).  L2TP is above L3.
Why use the layer numbers except as an extremely compact abbreviation?

Sorry, I have given too many networking courses.  Back to your argument.

The argument that the routing function is always exclusively performed
at the IP layer is invalid.  It certainly was invalid for ARPANET (or
CYCLADES, for that matter), which had their own elaborate routing
protocols.  It also certainly is invalid for 6LoWPAN networks such as
ISA100 that employ mesh routing functionality at the subnetwork layer
(which ISA100 calls DLL, Data Link Layer).  However, at the political
level, we generally don't do subnetworks in the IETF (nontrivial
exceptions notwithstanding), so routing work in the IETF is indeed
about IP routing.

6LoWPAN is designed based on the technical characteristics of IEEE
802.15.4 technology, but retains a degree of independence from some
aspects of the subnetwork architecture.  If the basic IEEE 802.15.4
functionality is augmented by routing functionality within the
subnetwork layer, i.e., routing based on subnetwork identifiers (MAC
addresses), the 6LoWPAN routing requirements apply to that.  If the
routing within the LoWPAN is done using IP identifiers, the 6LoWPAN
requirements apply to that.  RPL is an interesting candidate routing
protocol for the latter, but also could be used for the former after
adapting the identifier formats.  The requirements are mostly
independent of the identifier space being routed, and that is the
reason the routing requirements document applies to both mesh-under
and route-over.

Gruesse, Carsten

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 17 Aug 2009 11:26:46 +0200

Carsten Bormann a écrit :
[large snip]
> requirements apply to that.

And what if 802.15.5 L2 mesh routing is used in a 802.15 network?

I suppose both the 6LoWPAN adaptation layer and RPL become less 
necessary routing, in that case.

I doubt the 6LoWPAN routing requirements apply to 802.15.5.

Alex