Subject: RE: Last Call: <draft-ietf-6lowpan-nd-18.txt> (Neighbor DiscoveryOptimization for Low Power and Lossy Networks (6LoWPAN)) toProposed Standard

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 2 Jan 2012 17:42:16 +0100

Hi:

I posted support for this draft to the WG mailing list. At the same time, I regretted the lack of a sequence counter in the registration mechanism. Ralph suggested that I share my concerns in this step of the review process.

The sequence counter existed in earlier versions of the draft and was called a TID (see http://tools.ietf.org/html/draft-ietf-6lowpan-nd-08#page-18). Similar sequence counters exist in other registration mechanisms such as MIPv6. 

The sequence counter is useful for:
1) anti-replay
2) correlation of requests and responses in case messages cross (e.g. in mesh under)
3) mobility support (when radio conditions change, a device might need to select an alternate router)

Items 1 and 2 were not enough to convince the authors to keep the TID, and item 3 is somewhat an external to the specification. Yet, item 3 is the one I'm most concerned with, because it is required in order to inject the registration in a routing protocol such as RPL, or over a backbone in an ND proxy operation as was supported in earlier versions of the draft (till 8).

In the case of RPL, the path sequence in the transit option is used to determine which path is stale after a movement as described in http://tools.ietf.org/html/draft-ietf-roll-rpl-19#section-9.2.1 .  The TID would be trivially mapped into that path sequence but cannot be regenerated by the attachment router should the device move. IOW, without a TID, a device must be hardwired to its router for RPL to operate properly. RPL is very explicit about that limitation in section 7.1:
" If a host does not pass a  counter to its router, then the router is in charge of computing the Path Sequence on behalf of the host and the host  can only register to one router for that purpose. "

In the case of the backbone router that is now discussed separately from ND in http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router-02, we want a transparent mobility for the constrained device, so we need a mechanism to determine the freshest of conflicting registrations. The backbone routers would use the TID to figure which registration is freshest and determine which router should proxy over the backbone. 

In any case, it appears that though the ND mechanism could probably live without a sequence counter in most cases, a sequence counter is quite critical for the global integration of the protocol in a multi-hop radio infrastructure.

What do you think?

 Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of The IESG
Sent: vendredi 16 décembre 2011 22:02
To: IETF-Announce
Cc: [email-masked]
Subject: Last Call: <draft-ietf-6lowpan-nd-18.txt> (Neighbor DiscoveryOptimization for Low Power and Lossy Networks (6LoWPAN)) toProposed Standard

The IESG has received a request from the IPv6 over Low power WPAN WG
(6lowpan) to consider the following document:
- 'Neighbor Discovery Optimization for Low Power and Lossy Networks
   (6LoWPAN)'
  <draft-ietf-6lowpan-nd-18.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [email-masked] mailing lists by 2012-01-04. Exceptionally, comments may be sent to [email-masked] instead. In either case, please retain the beginning of the Subject line to allow automated sorting.

Abstract

   The IETF 6LoWPAN working group defines IPv6 over Low-power Wireless
   Personal Area Networks such as IEEE 802.15.4.  This and other similar
   link technologies have limited or no usage of multicast signaling due
   to energy conservation.  In addition, the wireless network may not
   strictly follow traditional concept of IP subnets and IP links.  IPv6
   Neighbor Discovery was not designed for non-transitive wireless
   links.  The traditional IPv6 link concept and heavy use of multicast
   make the protocol inefficient and sometimes impractical in a low
   power and lossy network.  This document describes simple
   optimizations to IPv6 Neighbor Discovery, addressing mechanisms and
   duplicate address detection for 6LoWPAN and similar networks.  The
   document, thus updates RFC 4944 to specify the use of the
   optimizations defined here.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-6lowpan-nd/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-6lowpan-nd/

No IPR declarations have been submitted directly on this I-D.

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce