I have some comments on draft-ietf-6lowpan-nd-07. I know there has been discussion of this draft during the IETF meeting in Hiroshima, and plans to split draft-ietf-6lowpan-nd-07 into two pieces have been suggested. I think my comments can be viewed as either complementary to or independent of those plans.
I have two questions based on reading draft-ietf-6lowpan-nd-07: 1. In a mesh-under network, the L2 characteristics of the lowpan are close to those usually assumed for implementation of IPv6; in particular, there are no "lowpan routers" at L3 and L3 messages *can* be delivered (perhaps with lower probability of success) directly between lowpan nodes. Why is ND not sufficient in this model? Would proxy ND be sufficient? 2. In a route-over network, all nodes are routers and forwarding information is carried in the routing protocol, eliminating the need for default router information and address resolution functions. Why is lowpan-ND needed in a route-over network? To answer these questions, draft-ietf-6lowpan-nd-07 needs a description of the components of a lowpan, the traffic delivery functions provided by the individual components and by the lowpan as a whole. RFC 4944 considers just the mesh-under case, while draft-ietf-6lowpan-nd-07 considers both mesh under and route over network. draft-ietf-6lowpan-nd-07 introduces new concepts like "lowpan router" and "edge router", and "IP routing" and "Relaying" without a clear architectural model and definition of how these components and functions operate in practice. For example, from the presentation at the 6lowpan WG in Hiroshima, I understand that all of the nodes in a 6lowpan network are considered to be in one subnet (more precisely, the subnet is "the interfaces of LoWPAN Nodes and Edge Routers sharing the same subnet prefix') and all sharing one IPv6 prefix. A 6lowpan router "forwards datagrams between arbitrary source-destination pairs using a single 6LoWPAN interface performing IP routing on that interface". As this forwarding paradigm is not the usual router behavior of forwarding IP traffic between interfaces attached to different links, some explanation is required for how the forwarding paradigm works. In some places in the document, I think this forwarding function is called "relaying". What is "relaying" and how does it relate to "forwarding" as mentioned in the definition of "6lowpan router"? Any description of 6lowpan needs to differentiate between mesh-under and router-over behavior, or explain which parts of the document apply to which form of lowpan. I can understand how a mesh-under lowpan has datagram delivery behavior that approximates wired ethernet, and how additional functions are required because of the differences in lowpan delivery reliability, node sleep/available cycles and broadcast/multicast/unicast semantics. I would expect that a mesh-under lowpan does not use lowpan routers, and uses some additional machinery to work around differences between a mesh-under lowpan and the more usual link-layer delivery characteristics assumed by IP-over-foo documents. Is the route-over architecture, using nodes and lowpan routers, shared with any other lowpan architectures like the work in the roll, autoconf or manet WGs? If so, it would be good to coordinate closely with those models; if not, the new route-over architecture needs a more detailed description. It's also at least a little surprising to me that the IEEE 802.15.4 spec isn't referenced directly; are there some architectural notions that can be shared from that spec? My suggestion is to add some text that describes the model and behavior of the various lowpan components that are used to build a lowpan protocol that provides the functions of RFC 4861 ND. The fundamental datagram machinery needs to be formulated and described first and then the new protocol can be built on that machinery. - Ralph _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
