ietf
[Top] [All Lists]

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

2012-01-03 09:20:45
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: ietf-announce-bounces(_at_)ietf(_dot_)org 
[mailto:ietf-announce-bounces(_at_)ietf(_dot_)org] On Behalf Of The IESG
Sent: vendredi 16 décembre 2011 22:02
To: IETF-Announce
Cc: 6lowpan(_at_)lists(_dot_)ietf(_dot_)org
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 
ietf(_at_)ietf(_dot_)org mailing lists by 2012-01-04. Exceptionally, comments 
may be sent to iesg(_at_)ietf(_dot_)org 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
IETF-Announce(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>
  • RE: Last Call: <draft-ietf-6lowpan-nd-18.txt> (Neighbor DiscoveryOptimization for Low Power and Lossy Networks (6LoWPAN)) toProposed Standard, Pascal Thubert (pthubert) <=