Hi Julien,
Understood. The ND for 6LoWPAN draft now has a sentence included which
makes that a SHOULD. Thanks for pointing this out.
You will have to keep lobbying elsewhere to get that updated to a SHOULD
for general IPv6 ND...
- 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
