Hi Zach: > >The other approach people are suggesting is that you do need AR >between all nodes within radio range and that the NR/NC AR approach is >not sufficient. > >Now this should be brought back to Carsten's question of the day - Do >we need AR at all, and if so to what extent? Once the WG agrees on >that goal - I am sure we can figure out a way to achieve it.
I'm with you as usual. This is a 2 step discussion. * First step is to clean up the remnant assumptions on LLA/IID tyings so that the current spec holds together without it. There's still text like in 3.4 that needs cleaning up and I'd think that this work is needed right now. Great thing that Carsten woke us up on this. * Then talk about the line of sight direct communication. The requirement for that has been expressed at ROLL, in particular in the context of home and building automation. In any case, a path is supposed to exist via the router if the target is reachable at all over IP. So there is no emergency to locate what is only a shortcut - that may or may not exist over one hop - and a simple beacon would suffice in a constrained node. IOW we do not need full fledge discovery as in 4861 though it would be good to be able to use it if it is available. RPL proposes that a host MAY multicast an NA-DAO to advertise itself over one hop. That is certainly a beginning and probably the only thing that can be done simply and generically because it can be broadcasted on a broadcast medium (ala ND), or copied to all circuits on statically or dynamically allocated circuits such as P2P time slots (ala InvND). Whether a better or more suited discovery can apply depends on the medium and the deployment. To be honest I think that this text does not belong to RPL but to ND and I'd be fine to include the capability to do that, but certainly that should be controlled by policy / application needs. For instance, one could use 6LowPAN-ND on Ethernet to enforce source address validation. In a given deployment this could be done for packets going outside the subnet in which case 4861 could still be used within. In another, we'd want any packet to be validated and thus 4861 would be disabled and all packets would be forced to go via a router that would validate the registration and thus the right to use the address. In another instance, a sensor and an actuator would be placed in line of sight expecting that most of the time they can see each other. In a given deployment, some provisioning might be involved to setup a one-hop Time Slotted circuit between the 2 hosts. As part of that provisioning, they would be instructed to advertise themselves to one another. But if the circuit is between 2 routers, there might be no point in sending the NA. What do you think? Pascal > >- Zach > > >> What do you think? >> >> Pascal >> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On >> Behalf Of Jonathan Hui >>> Sent: mercredi 14 octobre 2009 01:01 >>> To: Carsten Bormann >>> Cc: 6lowpan >>> Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1) >> Addressresolution is a waste of energy >>> >>> >>> On Oct 13, 2009, at 3:30 PM, Carsten Bormann wrote: >>> >>>> (1) Address resolution is a waste of energy >>>> >>>> IPv4 needed address resolution for Ethernet to map a 32-bit address >>>> space, n<32 bits of which were a host number within a network, to a >>>> 48-bit MAC address. IPv6 continued to follow that model for >>>> Ethernet even if that strong need no longer was there, with a likely >>>> default mapping but a possibility for manual assignment (or DHCP), >>>> so address resolution (AR) was still needed. >>>> >>>> In 6lowpans, the congruence of MAC and IP addresses is a >>>> prerequisite to efficient header compression. >>>> >>>> Also, we actually have a way to assign *MAC addresses* the way DHCP >>>> did this for *IP addresses*: 16-bit addresses are not owned by a >>>> device but can be assigned (using NR/NC in 6lowpan-nd-06), so if >>>> there is a need to assign a functional IP address to a device this >>>> can be done by assigning it the equivalent 16-bit MAC address. >>>> >>>> In 6lowpans, address resolution requires the establishment (using >>>> energy-wasting packets) and maintenance (using precious memory) of >>>> state that no longer serves a useful purpose. >>>> Using anything but the default mapping causes additional header >>>> overhead, wasting energy. >>>> The need for assigned addresses can easily be covered by assigning >>>> 16-bit addresses. >>>> >>>> Hence, the decision was to get rid of address resolution and >>>> hardwire the (IID part of the) mapping. >>>> >>>> I would like to hear arguments why the above reasoning was >>>> incorrect. >>> >>> Being a part of the discussion in Dublin, I wouldn't say that the >>> above reasoning was incorrect, just incomplete in thinking through >>> the >>> architectural implications. Playing devil's advocate here, some >>> points on the flip side: >>> >>> - This limits IIDs to one 64-bit and one 16-bit value at a time, is >>> this OK? It limits the number of addresses. It limits the ability >>> to >>> assign multiple addresses from different pools possibly from >>> different >>> administrative domains. It limits games one might play with >>> addressing for various purposes. >>> - The improvement in header compression is limited to the first and >>> last IP hops. Assuming 14-byte prefix is compressible, the added >>> cost >>> is 2 bytes for each address (a total of 4 bytes) overhead when both >>> IIDs do not map directly to their respective link addresses. When >>> communicating outside the network, one of the addresses is either >>> always compressible or not, so the compression argument is even less. >>> >>> I agree with the primary concern about energy of sending extra >>> packets >>> to resolve and address. This is not a code complexity issue. I >>> would >>> prefer a mechanism to know if a link address can be computed from an >>> IID, if not then perform AR. But I'm not sure there is a feasible >>> way >>> to get there. There are ways to reduce the frequency by including >>> LLAOs wherever possible, but doesn't eliminate the need for NS/NA in >>> the most general case. >>> >>> -- >>> Jonathan Hui >>> >>> _______________________________________________ >>> 6lowpan mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/6lowpan >> _______________________________________________ >> 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
