Hi Zach, Understood. The ND for 6LoWPAN draft now has a sentence included which makes that a SHOULD. Thanks for pointing this out. [Julien] ok
You will have to keep lobbying elsewhere to get that updated to a SHOULD for general IPv6 ND... [Julien] you are right, I will follow up on 6man and roll Cheers, Julien - Zach Julien Abeille (jabeille) wrote: > Hi Zach, all, > > 1 the ND section refering to per neighbor packet buffering is "While > waiting for address resolution to complete, the sender MUST, > for each neighbor, retain a small queue of packets waiting for > address resolution to complete. The queue MUST hold at least one > packet, and MAY contain more. However, the number of queued packets > per neighbor SHOULD be limited to some small value. When a queue > overflows, the new arrival SHOULD replace the oldest entry. Once > address resolution completes, the node transmits any queued packets." > > From a pure standard perspective, multiple queues are a MUST (one per > neighbor) > > From a certification perspective (Ipv6ready logo), there is a specific > test for multiple queues (test number v6LC.2.1.2B). > > From a deployment perspective, the feature is very useful, especially > for routers. What I would like is to make the MUST become a SOULD, and > let the implementation choose to buffer as much as it can, depending > on the available RAM. As typical packets are small in sensor networks, > this is feasible. > > 2 this is not an issue specific to 802.15.4/6lowpan, but to any very > constrained device, over any layer 2. > > Cheers, > Julien > > > > -----Original Message----- > From: Zach Shelby [mailto:[EMAIL PROTECTED] > Sent: vendredi 24 octobre 2008 10:52 > To: Julien Abeille (jabeille) > Cc: [email protected] > Subject: Re: [Roll] FW: per neighbor packet buffering "issue" > > Hi Julien, > > This is a valid concern. The ND for 6lowpan draft (-00 coming today) > is meant to exactly fix the problems that standard IPv6 ND (RFC4861) > has for 6lowpan. It is not expected that 6lowpan nodes implement > RFC4861, but rather just ND for 6lowpan, which borrows only minimal > features from RFC4861. So I believe we can fix all problems here. > > Are you referring to this piece of text from RFC4861? > > Once the IP address of the next-hop node is known, the sender > examines the Neighbor Cache for link-layer information about that > neighbor. If no entry exists, the sender creates one, sets its > state > to INCOMPLETE, initiates Address Resolution, and then queues the > data > packet pending completion of address resolution. For multicast- > capable interfaces Address Resolution consists of sending a Neighbor > Solicitation message and waiting for a Neighbor Advertisement. When > a Neighbor Advertisement response is received, the link-layer > addresses is entered in the Neighbor Cache entry and the queued > packet is transmitted. The address resolution mechanism is > described > in detail in Section 7.2. > > That doesn't tell me that you need a *separate* buffer for each > neighbor, just that you need to buffer the packet while performing > address resolution. A minimum IPv6 implementation should work with 2 > buffers then? > > Currently the draft specifies that 6lowpan nodes do not need to > subscribe to the all-nodes multicast and are not required to answer > multicast NS messages, asnwering unicast NS is also optional. Here is > the current text from our draft: > > A LoWPAN node does not use multicast for its Neighbor Solicitation > as > prescribed by the ND protocol [RFC4861] and oDAD [RFC4429]. For > lookup purposes, all NS messages are sent in unicast to the Edge > Router, that answers in unicast as well. The message is a standard > Neighbor Solicitation but for the destination that set to the Edge > Router address or the well known 6LOWPAN_ER anycast address as > opposed to the solicited-node multicast address for the destination > address. > > The Target link-layer address in the response is either that of the > destination if a short cut is possible over the LoWPAN, or that of > the Edge Router if the destination is reachable over the Transit > Link, in which case the Edge Router will terminate 6LoWPAN and relay > the packet. > > A 6LoWPAN node does not need to join the solicited-node multicast > address for its own addresses and should not have to answer a > multicast Neighbor Solicitation. It may be programmed to answer a > unicast NS but that is not required by this specification. > > - Zach > > Julien Abeille (jabeille) wrote: >> Dear all, >> >> I started a thread on 6man about one issue in Neighbor Discovery >> which > >> is extremely costly for embedded device: >> While performing address resolution for a neighbor, a node must be >> able to buffer at least one packet for the neighbor. >> >> It means if your neighbor cache can support 4 neighbors, you must >> allocate 5K RAM for this buffering, 10K for 8 neighbors. This is very >> costly and will prevent most constrained platforms to be IPv6 > compliant. >> I feel that without this, a node with 4K of RAM can be compliant. If >> the standard is not revised, you will probably need to upgrade to a >> chip with 16K RAM. >> >> This is true on any L2, not specific to 802.15.4, and also true with >> the neighbor discovery extensions 6lowpan is working on. >> >> I think this is critical we manage to have neighbor discovery revised >> on this point. >> What do you think? >> >> Regards, >> Julien >> _______________________________________________ >> Roll mailing list >> [EMAIL PROTECTED] >> https://www.ietf.org/mailman/listinfo/roll > -- Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti FINLAND mobile: +358 40 7796297 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
