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