Subject: RE: [6lowpan] Rechartering consensus...

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 27 Aug 2007 17:27:00 +0200

>
>"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

---

From: Kris Pister <[email-masked]>
Date: Mon, 27 Aug 2007 08:57:32 -0700

>> 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! :)

ksjp

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 27 Aug 2007 18:14:37 +0200

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.
If we want to change this, I'd like to hear a good argument why this  
recent consensus is no longer valid.

Gruesse, Carsten

---

From: "Joe Polastre" <[email-masked]>
Date: Mon, 27 Aug 2007 09:19:38 -0700

> integral part of the 6lowpan requirements.

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: Kris Pister <[email-masked]>
Date: Mon, 27 Aug 2007 09:38:36 -0700

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).

ksjp

---

From: "Joe Polastre" <[email-masked]>
Date: Mon, 27 Aug 2007 19:16:43 -0700

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.

-Joe

On 8/27/07, Kris Pister <[email-masked]> 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).
>
>  ksjp
>
>
>  Joe Polastre wrote:
>

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 27 Aug 2007 23:49:15 -0700

> physical wire (ie, it sits right above the "physical layer").

A minor but significant clarification, the data link in the IP world has 
traditionally meant two *or more* devices connected directly over a 
single shared-media. This is why so many protocols rely on link-local 
multicast and why LAN technologies that do not support it must emulate 
it, as we saw with LANE. It is also why we see some push from members in 
this working group for a "mesh-under" routing and forwarding strategy.

> mess underneath to look like a single data link to L3 protocols.

Putting MPLS' applicability to L2Ns aside, one thing to learn from MPLS 
is that the control protocols are, largely, IP protocols. Thus, MPLS is 
"route-over" but redefines the forwarding mechanisms to be below IP. 
But, yes, many claimed advantages of MPLS (e.g. label lookup, traffic 
engineering, etc.) may also see similar advantages in L2Ns.

--
Jonathan Hui
[email-masked]

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Tue, 28 Aug 2007 11:08:29 +0200

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.

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. 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, NBBS etc... 

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). 

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?

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...
>

---

From: Rene Struik <[email-masked]>
Date: Tue, 28 Aug 2007 09:40:43 -0400

Dear Pascal:

With due respect, I am not clear how this would "better" security at all, 
since I do not know what your metric is. Please explain. 

More generally, it seems you would do the community a favor if you could 
expand in some detail on trust lifecycle management and outline the 
resources (crypto primitives, implementation cost protocols (both in 
hardware/software), time latency, packet expansion, etc.) required to 
implement IP security with sensors. Some references to peer-reviewed 
papers that elaborate on this would also be helpful.

Best regards, Rene

====
[from the 6lowpan thread]

As Kris and

Rene 
-----
Certicom Research
http://www.certicom.com

"Pascal Thubert \(pthubert\)" <[email-masked]> 
08/28/2007 05:05 AM

To
"Carsten Bormann" <[email-masked]>, "Kris Pister" 
<[email-masked]>, "Joe Polastre" <[email-masked]>
cc
6lowpan <[email-masked]>
Subject
RE: [6lowpan] Rechartering consensus...

Hi Carsten,

So my proposal is:

What do you think?

Pascal

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Tue, 28 Aug 2007 17:27:45 +0200

Hi Rene:

I was discussing the VPN functionality. It could be possible to deploy
VPN up to the sensors and even split a sensor network into multiple VPNs
though that one is really far fetched. The point is that for a same
crypto cost, end to end security at IP level avoids the risk of the
gateway being compromised: Same discussion exactly as 802.11e/EAP vs.
VPN. in, say, 802.11 networks...

Pascal

________________________________

From: Rene Struik [mailto:[email-masked]] 
Sent: Tuesday, August 28, 2007 3:41 PM
To: Pascal Thubert (pthubert)
Cc: 6lowpan; Carsten Bormann; Joe Polastre; Kris Pister
Subject: RE: [6lowpan] Rechartering consensus...

Dear Pascal: 

With due respect, I am not clear how this would "better" security at
all, since I do not know what your metric is. Please explain. 

Best regards, Rene 

==== 

As Kris and

Rene 
-----
Certicom Research
http://www.certicom.com 

08/28/2007 05:05 AM 

To

cc

Subject

 

Hi Carsten,

So my proposal is:

What do you think?

Pascal

---

From: Rene Struik <[email-masked]>
Date: Tue, 28 Aug 2007 11:38:55 -0400

Hi Pascal:

I am somewhat doubtful as to "same crypto cost", flexibility of trust 
configurations, initial set-up, trust maintenance, enforcement of security 
policies, and such. So far, I have not seen any evidence that this can be 
realized on sensor networks with currently standardized IP protocols (but 
perhaps I have the wrong set of a few hundred of papers on this... ). 
However, I would love to be delighted and convinced that this can indeed 
be realized after all.

It may help if you could exemplify what you would like to realize, by 
stating different steps in the key management lifecycle, security 
objectives, crypto protocols and surrounding security policies to realize 
these objectives, impact on message sizes, estimates on energy use, and 
latency on low-cost platforms. Additionally, it would help to understand 
what communication behavior one would like to support (e.g.. unicast, 
multicast, broadcast) and how these communication behaviors are utilized 
to facilitate, e.g., key updates. Finally, it would help to understand 
what happens if a change of network topology occurs, e.g., network merge, 
partition, replacement of device, etc., and how you envision this can be 
facilitated in a secure fashion using currently standardized IP 
protocols).

Best regards,

Rene 
-----
Certicom Research
http://www.certicom.com

08/28/2007 11:26 AM

To
"Rene Struik" <[email-masked]>
cc
"6lowpan" <[email-masked]>, "Carsten Bormann" <[email-masked]>, "Joe 
Polastre" <[email-masked]>, "Kris Pister" <[email-masked]>
Subject
RE: [6lowpan] Rechartering consensus...

Hi Rene:
 
I was discussing the VPN functionality. It could be possible to deploy VPN 
up to the sensors and even split a sensor network into multiple VPNs 
though that one is really far fetched. The point is that for a same crypto 
cost, end to end security at IP level avoids the risk of the gateway being 
compromised: Same discussion exactly as 802.11e/EAP vs. VPN. in, say, 
802.11 networks?
 
Pascal

Dear Pascal: 

Best regards, Rene 

==== 

As Kris and

Rene 
-----
Certicom Research
http://www.certicom.com 

To

Hi Carsten,

So my proposal is:

What do you think?

Pascal

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Tue, 28 Aug 2007 18:42:38 +0200

Hi Rene

You can stack as many hundreds of pages as you like, you might still end
up missing some. A mailing list such as this one is a good place to
exchange ideas, share knowledge and solve problems, open-mindedly as
opposed to aggressively. In the specific case, you might be interested
in the work done at CAPWAP and EPC Global for RFID. This is an example
of how provisioning can be done in this space, and that art might help
6LoWPAN in the chartered work on bootstrapping. Now if we already had
all your answers figured out, I guess that this group and a number of
others would be done, wouldn't it? 

On the constructive side, you're listing requirements that might or
might not appear in various configurations. Other requirements might
appear as well. For instance, in terms of security objectives, do we
want to support global mobility - this was discussed in the context of
the first objective of our new charter-? It might be difficult to do
that if you constrain your security design to the mesh network. OTOH,
RFC 4877 is a tool that you can use over the Internet, building on RFC
4301, 4103 and 4106. Do we want to reinvent that sort of wheel?

Also, I did not find that you rejected the concept that end to end
security is generally an improvement over multiple consecutive secured
networks, and I consider the initial case closed.

Pascal

Sent: Tuesday, August 28, 2007 5:39 PM

Hi Pascal: 

I am somewhat doubtful as to "same crypto cost", flexibility of trust
configurations, initial set-up, trust maintenance, enforcement of
security policies, and such. So far, I have not seen any evidence that
this can be realized on sensor networks with currently standardized IP
protocols (but perhaps I have the wrong set of a few hundred of papers
on this... ). However, I would love to be delighted and convinced that
this can indeed be realized after all. 

It may help if you could exemplify what you would like to realize, by
stating different steps in the key management lifecycle, security
objectives, crypto protocols and surrounding security policies to
realize these objectives, impact on message sizes, estimates on energy
use, and latency on low-cost platforms. Additionally, it would help to
understand what communication behavior one would like to support (e.g..
unicast, multicast, broadcast) and how these communication behaviors are
utilized to facilitate, e.g., key updates. Finally, it would help to
understand what happens if a change of network topology occurs, e.g.,
network merge, partition, replacement of device, etc., and how you
envision this can be facilitated in a secure fashion using currently
standardized IP protocols). 

Best regards, 

Rene 
-----
Certicom Research
http://www.certicom.com 

08/28/2007 11:26 AM 

To

cc

"6lowpan" <[email-masked]>, "Carsten Bormann" <[email-masked]>,
"Joe Polastre" <[email-masked]>, "Kris Pister"
<[email-masked]> 

Subject

 

Hi Rene: 

Pascal 

Dear Pascal: 

Best regards, Rene 

==== 

As Kris and

Rene 
-----
Certicom Research
http://www.certicom.com 

08/28/2007 05:05 AM 

To

cc

Subject

  

Hi Carsten,

So my proposal is:

What do you think?

Pascal