Subject: [Roll] FW: per neighbor packet buffering "issue"

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Fri, 24 Oct 2008 10:02:48 +0200

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-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Fri, 24 Oct 2008 15:51:11 +0200

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-masked]] 
Sent: vendredi 24 octobre 2008 10:52
To: Julien Abeille (jabeille)
Cc: [email-masked]
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

> While performing address resolution for a neighbor, a node must be 
> able to buffer at least one packet for the neighbor.
> 
> 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

-- 

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.
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Zach Shelby <[email-masked]>
Date: Fri, 24 Oct 2008 17:37:09 +0300

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

-- 

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti
FINLAND

mobile: +358 40 7796297

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Fri, 24 Oct 2008 17:26:26 +0200

Hi Zach, 

[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,

> 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.
> 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.
> 

-- 

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti
FINLAND

mobile: +358 40 7796297