Hi, On Nov 16, 2009, at 21:30 , Ralph Droms wrote:
> Responses - well, mostly more questions - inline... > > On Nov 16, 2009, at 1:05 AM 11/16/09, Carsten Bormann wrote: > >> Quick answers: >> >> On Nov 16, 2009, at 06:43, Ralph Droms wrote: >> >>> 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? >> >> RFC 4861 ND works in a pure RFC 4944 mesh-under network if: >> 1) the mesh-under (L2) routing protocol provides subnet-wide multicast, >> 2) that is efficient enough to be used for routine ND messages, >> 3) nodes are awake often enough to detect and reply to NS messages. >> >> Such networks do exist, but these assumptions are not necessarily compatible >> with many application scenarios we have in mind; this is the reason we >> started with ND optimizations. > > OK, and I understand you're working on application scenarios. I think you > need a digest from the applications scenarios into a set of characteristics > of the underlying L2 services that is explicitly written down somewhere. We are not working with application scenarios as such, but you could say that we are working with link-layer scenarios. And I agree those could be documented better than just talking about mesh-under and route-over. > > Can you reuse the scenario work from the roll WG? It might not hurt to reference the work done there? We can definitely look at that and see what is related to our work there. I think most of us have related scenarios in mind for 6LoWPAN anyways. >>> 2. In a route-over network, all nodes are routers >> >> That is not the assumption: The assumption is that there are hosts and >> routers, and that the forwarding function is performed by the routers. >> There needs to be a protocol that enables hosts to register themselves to >> routers, independent of the routing protocol. > > Is it commonly assumed in lowpans that there are both hosts and routers or is > that architectural assumption specific to the 6lowpan/802.15.4 work? This is a common assumption for low-power embedded devices, especially wireless ones. In order to keep a node as simple as possible, and to save battery power you would configure it as a host. This also allows for nodes that can not participate in the particular routing algorithm in use. In 6lowpan this becomes even more important as we are dealing with simple autonomous nodes which are often battery powered. There will surely be LoWPANs deployed with no routing at all - in which case we only have an ER and hosts. > >> Since the host-router relationship is somewhat ephemeral due to the nature >> of the wireless links, address assignment needs to be lowpan-wide instead of >> per host-router relationship. >> As ND-07 is not by itself supporting host-host communication, address >> resolution only happens between hosts and routers. > > Do you mean that the only address resolution is for a router to resolve the > MAC address of a destination host? You could say we don't actually do address resolution (as in a mechanism initiated when you don't know the link-layer address). Instead the node registration exchange between nodes and routers includes sufficient link-layer address information. Therefore nodes know the L2 addresses of their default routers, and routers know the L2 addresses of the nodes registered with them. > >> Re one other term: "relaying" is the term ND-07 is using for what routers do >> between themselves to process host NR messages; it is not IP forwarding. > > Is this relaying specific to ND-07; i.e., does ND-07 require a forwarding > overlay? This is specific to nd-07 and only when a router performs registration on behalf of a node. The nice thing about the document split, is that the base document would no longer have to deal with or talk about relaying. > >> It is probably more appropriate to give the inter-router message a different >> name (e.g., relayed NR, RNR), so the confusion between this relaying process >> and IP forwarding is reduced; this is the part that will move to the second >> document after the split. Exactly! The other nice thing is that the split allows us to treat mesh-under and route-over in a very similar way as we only have to deal with the host-router interface over one hop. We can also treat an ER and a Router equally in the base document. So it would go a long ways towards simplifying the terminology, architecture etc. in the base document. Zach >> >> Gruesse, Carsten >> > > - Ralph > > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan -- http://www.sensinode.com http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
