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
