Hi: This is work that started at 6LoWPAN and was part of the early 6LoWPAN ND WG doc. It is now contiguous to 6MAN work with the Efficiency aware IPv6 Neighbor Discovery.
The context is a backbone link, in a situation where the 6LoWPAN ND or the Efficiency aware IPv6 Neighbor Discovery reservation mechanism is used as opposed to, or together with, the classical IPv6 Neighbor discovery. With a single router, acting as registrar (aka NEAR, or 6LBR), and the subnet prefix declared as not_onlink, connectivity can be ensured between energy efficient devices and between those and classical devices via the registrar router, as described by the Efficiency aware IPv6 Neighbor Discovery draft and/or 6LoWPAN ND. But say that the network grows large and we want to have more than one router acting as registrar. How do the routers interact when a packet reaches one registrar but the target energy efficient device is registered to the other? And then, say that the same IPv6 address is now registered to the second router. Is this a movement, or a duplication? Should the registration be accepted? What about states in the first router? The draft uses proxy neighbor discovery with an enhanced ARO option to resolve this. The registrar advertises the device IPv6 address with its own MAC address as target. This way, in a fashion very similar to a Home Agent, it attracts packets to registered devices, and then it can route the packets based on its registration state. A sequence number (TID) is added to the ARO to resolve the freshest location of a device in case of movement, while the existing unique ID is used to discriminate duplications. One side benefit of the draft is that the prefix does not need to be declared as not_onlink anymore, and still communication between a classical device and a 6LoWPAN device can be achieved transparently to the device. Another is that stateful devices such as SAVI switches get a more solid information to base their states upon. Finally, this can be useful for VM deployments that use MAC rewrites in the switches. I can only insist that the registration model is a much needed feature for low power devices. In the industrial case, we foresee a backbone with tens to a hundred registrars (backbone routers), and tens of thousands of 6LoWPAN devices attached. And it is critical that the ND operation on the backbone stay very light in order to obtain such numbers, in particular with a drastic economy on multicasts such as gratuitous NAs. More in the draft : ) Pascal -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: lundi 25 février 2013 18:02 To: Pascal Thubert (pthubert) Subject: New Version Notification for draft-thubert-6lowpan-backbone-router-03.txt A new version of I-D, draft-thubert-6lowpan-backbone-router-03.txt has been successfully submitted by Pascal Thubert and posted to the IETF repository. Filename: draft-thubert-6lowpan-backbone-router Revision: 03 Title: 6LoWPAN Backbone Router Creation date: 2013-02-25 Group: Individual Submission Number of pages: 20 URL: http://www.ietf.org/internet-drafts/draft-thubert-6lowpan-backbone-router-03.txt Status: http://datatracker.ietf.org/doc/draft-thubert-6lowpan-backbone-router Htmlized: http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-thubert-6lowpan-backbone-router-03 Abstract: Some LLN subnets are expected to scale up to the thousands of nodes and hundreds of routers. This paper proposes an IPv6 version of the Backbone Router concept that enables such a degree of scalability using a high speed network as a backbone to the subnet. The IETF Secretariat -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
