In section 8.2.6 of 6LowPAN-ND-10, it is the responsibility of the 6LR
to retry if forwarding a special NS message to the 6LBR does not result
in a corresponding NA.
I think it would be more efficient if the host were responsible for the
retry. The host will need to retry the special NS message anyway, to
cover the case where the message is lost between the host and the 6LR or
the forwarded NA is lost in the other direction.
If the 6LR didn't need to retry on behalf of the host, it wouldn't need
a table of pending nodes. It could implement NS/NA forwarding in a
stateless manner, much like a REST HTTP implementation. This would not
require any other change to the specification because the state
information (the SLLAO of the host) is already carried in the messages.
Daniel.
Zach Shelby wrote:
We finished up all the open tickets and known issues around ND and posted a new
version, bon appetit! Thanks to everyone for the helpful comments and ideas,
we're getting there.
http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-nd-10.txt
Changes from -09 to -10:
o Clarifications made to Section 8.2 (#66)
o Explained behavior of Neighbor Cache (#67)
o Clarified use of SLLAO in RS and NS messages (#68)
o Added new term 6LN (#69)
o Small clarification on 6CO flag (#70)
o Defined host behavior on ARO failure better (#72)
o Added bootstrapping example for a host (#73)
o Added new Neighbor Cache Full ARO error (#74)
o Added rule on the use of the M flag (#75)
Begin forwarded message:
From: IETF I-D Submission Tool <[email protected]>
Date: June 17, 2010 6:15:47 PM GMT+03:00
To: [email protected]
Cc: [email protected],[email protected]
Subject: New Version Notification for draft-ietf-6lowpan-nd-10
A new version of I-D, draft-ietf-6lowpan-nd-10.txt has been successfully
submitted by Zach Shelby and posted to the IETF repository.
Filename: draft-ietf-6lowpan-nd
Revision: 10
Title: Neighbor Discovery Optimization for Low-power and Lossy
Networks
Creation_date: 2010-06-17
WG ID: 6lowpan
Number_of_pages: 46
Abstract:
The IETF 6LoWPAN working group defines IPv6 for low-power and lossy
networks (LLNs) 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 IETF Secretariat.
--
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 Registered In England
http://www.jennic.com
__________________________________________________
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
