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