Subject: [RSN] Re: [6lowpan] Rechartering consensus...

From: JP Vasseur <[email-masked]>
Date: Tue, 4 Sep 2007 16:27:41 -0400

Hi Kris,

On Aug 27, 2007, at 11:57 AM, Kris Pister wrote:

> >> 6lowpan requires a mesh routing protocol below the IP layer.
>
> For sure the word "requires" is incorrect.  I don't think that  
> there's any question at this point that it's possible to route  
> over.  There is still reasonable debate over what the optimal thing  
> to do is, where different people have very different views of what  
> "optimal" means! :)
>

If I may reformulate your question ... "Considering that Route over  
is MUST for the number of reasons discussed
on various Mailing Lists, why do we still need a mesh under routing  
solution ?".

Thanks.

JP.

> ksjp
>
> Pascal Thubert (pthubert) wrote:
>>> "6lowpan Mesh Routing"
>>>
>>> JP> One of these "hot" topic. And of course, the main question will
>>> to be
>>> discuss whether Mesh-under routing is required if Route over is
>>> available.
>>> In particular, open questions are "If we claim a need for a mesh
>>> under routing,
>>> does that mean that we'll see a plethora of IDs showing how to adapt
>>>
>> all
>>
>>> protocols (e.g. MANET) used in a 802.15.4 environment ?"
>>>
>>>
>> [Pascal] Hi JP:
>>
>> "While most routing protocols are defined above the IP layer, 6lowpan
>> requires a mesh routing protocol below the IP layer."
>>
>> I'm also anxious about that sentence. The need for a mesh under vs.
>> routing over should be motivated; also, if that happens, then the  
>> IETF
>> might not be the place for this work. It already happens in a  
>> number of
>> places such as SP100, HART or 802.15.5.
>>
>> It seems more consistent to focus on IP and delegate a routing over
>> protocol to the Routing Area. So I'd rather have 6LoWPAN support the
>> RL2N (RSN ML) efforts because they are defining a mesh technology  
>> that
>> is L2 agnostic, fit into the IETF scope and benefit from the area
>> experience in routing, as opposed to proposing yet another mesh under
>> protocol that might not be well considered by the mentioned standard
>> organizations.
>>
>> Pascal
>>
>> _______________________________________________
>> 6lowpan mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/6lowpan
>>
> _______________________________________________
> 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: JP Vasseur <[email-masked]>
Date: Tue, 4 Sep 2007 16:27:51 -0400

On Aug 27, 2007, at 12:14 PM, Carsten Bormann wrote:

> On Aug 27 2007, at 17:57, Kris Pister wrote:
>
>> For sure the word "requires" is incorrect.
>
> I'm sure the term "6lowpan" can be redefined to make this statement  
> true.
> For now, RFC4919 takes the stance that L2 routing ("mesh") is an  
> integral part of the 6lowpan requirements.

Note that RFC4919 is a problem statement, not a requirement document  
with RFC2119
language. Furthermore there is nothing in the RFC that mandates for  
the routing function to
take place at the layer2.

> If we want to change this, I'd like to hear a good argument why  
> this recent consensus is no longer valid.
>

Thanks.

JP.

> Gruesse, Carsten

---

From: JP Vasseur <[email-masked]>
Date: Tue, 4 Sep 2007 16:31:33 -0400

On Aug 27, 2007, at 12:38 PM, Kris Pister wrote:

> Carsten - I'm using 6lowpan in the broad sense of the original  
> acronym, not just RFC4919.  That may be incorrect, and I should use  
> different terminology.
>
> Joe - what layer does MPLS fit in?  MPLS looks a little weird, and  
> a little "2.5"-ish, but to me it's the approach that makes the most  
> sense for 6lowpan.  I haven't gone back to read all of the  
> discussion, but it seems like the only thing that got added in v6  
> was the flow label.  This flow label provides a wonderful  
> opportunity to work with protocols like HART and sp100 that use an  
> L3 graph-ID to govern L2 operation.  I think that we could define a  
> different HC that keeps the v6 flow label and uses that to control  
> L2.  I'm not sure how much of RSVP, etc would be needed to pull  
> this off, but it seems like it should be possible to do something  
> very similar to what already exists for MPLS (but probably  
> simplified, compressed, etc).  I'd like to work on this with  
> someone who is more facile with all of the L3 stuff (which I am not).

As discussed in the past, this may be an option indeed, using a PCE- 
based or
distributed approach to compute paths instantiated by some protocols  
TBD.
This would be very much similar to MPLS and in line with the requirement
for L3 routing. Should a WG (RSN) be formed, this would be the place  
where
to discuss the pros/cons of such approach. But before discussing the  
routing
solution we first need to flesh out the application specific routing  
requirement
IDs since such solution may clearly not be applicable to all scenarios.

Thanks.

JP.

> Joe Polastre wrote:
>> First comment is that mesh is a networking protocol, not a data-link
>> protocol.  Thus, it cannot be an L2 "routing" requirement.
>>
>> Since IP is at L3, I agree with Kris--mesh can either be L2.5 (which
>> is a bit weird IMHO), it can co-exist with IP (in an undefined way),
>> or it can be leveraged above IP similar to overlays.
>>
>> -Joe
>>

---

From: JP Vasseur <[email-masked]>
Date: Tue, 4 Sep 2007 16:31:42 -0400

On Aug 27, 2007, at 10:16 PM, Joe Polastre wrote:

> To me, its a matter of defining abstractions clearly.  Data link
> traditionally meant two points connected directly with the use of a
> physical wire (ie, it sits right above the "physical layer").
>
> In this domain, we have this quirky ability to have multiple direct
> connections.  For example, I may be able to directly connect with
> Kris, but I can also connect with Kris via John.  From a software
> layering perspective, I can leverage both options at L2/L2.5 to make
> it look to the network layer like I have a reliable direct data-link
> connection to Kris, regardless of whether I reach Kris directly or
> talk to him via John.  This becomes murkier if all of your "direct"
> connections are not direct at all or have no possible direct
> path--then you're potentially treading on the realm of L3 protocols.
> This is why this mesh networking domain has had the problem of
> communicating data and metadata between layers transparently, since
> each of the layers seems to muddle in other layers' business.
>
> I agree that MPLS is probably most applicable here, and really is one
> of these L2.5 services because it is abstracting all kinds of ugly
> mess underneath to look like a single data link to L3 protocols.

To avoid confusion, MPLS Routing is performed at layer 3 !
It is the dataplane that does not involve IP lookup but the routing  
function
is definitely at the IP layer: LDP paths follow the IGP shortest  
paths and
TE LSPs are computed using the TED that is fed by the routing protocols;
then constrained-based routing is used to compute a constrained
path and TE LSP establishment is performed via RSVP-TE.

Thanks.

JP.

>
> -Joe
>
> On 8/27/07, Kris Pister <[email-masked]> wrote:
>>
>> acronym, not
>> just RFC4919.  That may be incorrect, and I should use different
>> terminology.
>>
>>  Joe - what layer does MPLS fit in?  MPLS looks a little weird,  
>> and a little
>> "2.5"-ish, but to me it's the approach that makes the most sense for
>> 6lowpan.  I haven't gone back to read all of the discussion, but  
>> it seems
>> like the only thing that got added in v6 was the flow label.  This  
>> flow
>> label provides a wonderful opportunity to work with protocols like  
>> HART and
>> sp100 that use an L3 graph-ID to govern L2 operation.  I think  
>> that we could
>> define a different HC that keeps the v6 flow label and uses that  
>> to control
>> this off,
>> but it seems like it should be possible to do something very  
>> similar to what
>> already exists for MPLS (but probably simplified, compressed,  
>> etc).  I'd
>> like to work on this with someone who is more facile with all of  
>> the L3
>> stuff (which I am not).
>>
>>  ksjp
>>
>>
>>  Joe Polastre wrote:
>>

---

From: JP Vasseur <[email-masked]>
Date: Tue, 4 Sep 2007 16:40:29 -0400

Hi Pascal,

On Aug 28, 2007, at 5:08 AM, Pascal Thubert ((pthubert)) wrote:

> Hi Carsten,
>
> Yes, I suspect we want to alter the wording of a requirement in the
> charter. I've not seen similar text in RFC 4919 but I might have  
> missed
> it. Rather, the RFC states in page 5 the requirement on a routing
> protocol.
>
> We want IPv6 in the sensor space ASAP so that applications in edge
> servers can be developed for it and 6LoWPAN is a major step on that
> path. Proprietary versions of mesh under protocols (TSMP, X-mesh, you
> name it) are being deployed in the field and it would be great that  
> the
> standard versions move to IPv6 as the de facto network layer and  
> provide
> the associated LINK abstraction. I understand that the SP100-NetTrans
> task group has already taken the position to use 6LoWPAN as the  
> network
> layer.

That reminds me that we still need to work on routing metric scheme  
providing
layer-2 abstraction.

>
> A mesh under is one fine way to provide the link abstraction that IP
> needs, and a frame relay PVC based cloud is the proof that the model
> works.

Well it is also the proof that Routing in an overlay network is  
sometimes
problematic (we all remember IP routing over ATM with PNNI).

> There is little question in my mind that 6LoWPAN can work with
> WiHART or similar once they provide this abstraction. What's tricky is
> the word "requires" in the proposed re-charter that Geoff sent in June
> for this thread.
>
> A L2 mesh will provide a P2MP or NBMA abstraction for IP, but will  
> have
> trouble optimizing the support of multicast upon which IPv6 relies for
> basic operations. Also, when we consider the self-forming, self- 
> healing
> characteristics that we are looking for, then some history might  
> help us
> avoid past mistakes. There have been a number of attempts to provide
> mesh under mode in the WAN space, including PNNI,

Here we go ...

> NBBS etc...

Not to mention end-to-end routing consistencies, QoS routing, ...

> After years of trials and failure, IP routing has emerged to be the  
> most
> consistent solution to optimize end-to-end connectivity, with the
> tooling and management support that comes with it. Further, this  
> enabled
> a new virtual switched network, MPLS, which benefits from IP  
> routing for
> its path computation, optimization (Traffic Engineering Constrained
> Path) and isolation (Virtual Private Networks).

Absolutely.

>
> So in my mind, it is not true that 6LoWPAN requires a mesh under
> protocol. What is true is that the routing that 6LoWPAN requires would
> largely benefit from IP technology should it be IP based. As Kris and
> Joe discussed in this thread, IP routing would enable us to extend the
> MPLS network down to the sensors, for a better security and QoS
> management.
>
> So my proposal is:
> - work with external standard groups such as HCF and SP100 to insure
> that 6LoWPAN is compatible with their link abstractions.
> - work with the routing area to provide an alternate IP-based routing
> over solution
>
> What do you think?

Well I think that we have reached a consensus on the second bullet,  
thus the work
being done by RSN (although there is still no WG: we may have a BOF  
in Vancouver).

On the first bullet, I cannot agree more. This is what I was  
referring to by "routing metric
scheme providing layer-2 abstraction".

Thanks.

JP.

>
> Pascal
>
>> -----Original Message-----
>> From: Carsten Bormann [mailto:[email-masked]]
>> Sent: Monday, August 27, 2007 6:15 PM
>> To: Kris Pister
>> Cc: Carsten Bormann; Pascal Thubert (pthubert); 6lowpan
>> Subject: Re: [6lowpan] Rechartering consensus...
>>
>> If we want to change this, I'd like to hear a good argument why this
>> recent consensus is no longer valid.
>>
>> Gruesse, Carsten
>