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 PROTECTED]
Sent: Monday, August 27, 2007 6:15 PM
To: Kris Pister
Cc: Carsten Bormann; Pascal Thubert (pthubert); 6lowpan
Subject: Re: [6lowpan] Rechartering consensus...
On Aug 27 2007, at 17:57, Kris Pister wrote:
6lowpan requires a mesh routing protocol below the IP layer.
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
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
