I've attached some comments in-lined in sections of the nd-15 draft. It's
almost all smaller editorial-style comments.
Regards,
-Colin
Shelby, et al. Expires June 20, 2011
[Page 7]
Internet-Draft ND Optimization for LLNs
December 2010
1.3. Applicability, Goals and Assumptions
This document specifies a set of behaviors between hosts and
routers.
An implementation that adheres to this document MUST
implement those
behaviors. The document also specifies a set of behaviors
(multihop
prefix or context dissemination, and separately multihop
duplicate
address detection) which are OPTIONAL to use. An
implementation of
this specification SHOULD implement those optional to use
pieces.
The optimizations described in this document apply to
different
topologies. They are most useful for route-over and
mesh-under
configurations in Mesh topologies. However, Star topology
configurations will also benefit from the optimizations due
to
minimized signaling, robust handling of the non-transitive
link, and
header compression context information.
The document has the following main goals and assumptions.
Goals:
o Optimize Neighbor Discovery with a mechanism that is
minimal yet
sufficient for the operation in both mesh-under and
route-over
configurations.
o Make the host to router interaction the same whether
mesh-under or
route-over is used.
*These last two points could probably be consolidated into one point.
o Minimize signaling by avoiding the use of multicast
flooding and
reducing the use of link-scope multicast messages.
o Optimize the interfaces between hosts and their default
routers.
*This could also also be fit in with the first two points I think
o Support for sleeping hosts.
o Minimize the complexity of nodes.
*Point can be deleted, nobody wants complex nodes, and it's already a goal to
make the mechanism 'minimal', which implies to me the nodes are not as complex
o Disseminate context information to hosts as needed by
[I-D.ietf-6lowpan-hc].
o Optionally disseminate context information and prefix
information
from the border to all routers in a LoWPAN.
o Optional duplicate address detection mechanism suitable
for route-
over LoWPANs.
Assumptions:
Shelby, et al. Expires June 20, 2011
[Page 8]
Internet-Draft ND Optimization for LLNs
December 2010
o EUI-64 addresses are globally unique.
EUI-64 ARE globally unique by definition. This should not be an assumption.
Shelby, et al. Expires June 20, 2011
[Page 9]
Internet-Draft ND Optimization for LLNs
December 2010
sending a registration message with zero lifetime and
then
registers with a new default router that is
reachable. If the
node loses connectivity with the default router
involunterily,
then the default router does not know the node has
moved until it
runs the unreachability detection. In order to
optimize the time
for detecting unreachability of a run-away node, a
default-router
may use link-layer indication or configure a lower
NCE life-time
*NCE is not defined yet
*life-time shoudl probably be 'lifetime', as that is what is used elsewhere
value and low registration life-time value - so that
it can remove
*life-time/lifetime again
the NCE of the run-away node as soon as possible.
*This is not so much an assumption as a best practice. Can a SHOULD be in
the assumptions section? Maybe should move this to the relevant section of
6lowpan-nd
Shelby, et al. Expires June 20, 2011
[Page 15]
Internet-Draft ND Optimization for LLNs
December 2010
this results in a Tentative NCE. Once a node successfully
registers
*Should specify where the Tenative NCE is. e.g.: "...in a Tenative NCE in the
router."
with a Router the result is a Registered NCE. As Routers
send RAs to
hosts, and when routers optionally receive RA messages or
receive
multicast NS messages from other Routers the result is
Garbage-
collectible NCEs. There can only be one kind of NCE for an
IP
address at a time.
Neighbor Cache entries on Routers can additionally be added
or
*Either 'entires' should have a capitcal E (for NCE), or cahce should have a
low-case 'c'
deleted by a routing protocol used in the 6LoWPAN. This is
useful if
the routing protocol carries the link-layer addresses of the
neighboring routers. Depending on the details of such
routing
*such twice in the same sentance, maybe change first one to 'the' for better
flow
protocols such NCEs could be either Registered or Garbage-
collectible.
Shelby, et al. Expires June 20, 2011
[Page 31]
Internet-Draft ND Optimization for LLNs
December 2010
maintain on-link information about its registered neighbors.
Tentative NCEs MUST NOT be used to maintain on-link status.
*Should this reference 5.6, to say it extends that logic only? So an
unregistered
but link-local address is still on-link.
6.5.5. Address Resolution between Routers
There needs to be a mechanism somewhere for the routers to
discover
each other's link-layer addresses. If the routing protocol
used
Shelby, et al. Expires June 20, 2011
[Page 36]
Internet-Draft ND Optimization for LLNs
December 2010
8.2. Multihop Duplicate Address Detection
The ARO can be used, in addition to registering an address
in a 6LR,
to have the 6LR verify that the address isn't used by some
other host
known to the 6LR. However, that isn't sufficient in a
route-over
topology (or in a LoWPAN with multiple 6LBRs) since some host
attached to another 6LR could be using the same address.
There might
be different ways for the 6LRs to coordinate such Duplicate
Address
Detection in the future, or addresses could be assigned
using a
DHCPv6 server that verifies uniqueness as part of the
assignment.
This specification offers an optional and simple technique
for 6LRs
and 6LBRs to perform Duplicate Address Detection that reuses
the
information from Address Registration option in the DAR and
DAC
messages. This technique is not needed when the Interface
ID in the
address is based on an EUI-64, since those are assumed to be
globally
unique. The technique assumes that the 6LRs either register
with all
the 6LBRs, or that the network uses some out-of-scope
mechanism to
keep the DAD tables in the 6LBRs synchronized.
The multihop DAD mechanism is used synchronously the first
time an
address is registered with a particular 6LR. That is, the
ARO option
is not returned to the host until multihop DAD has been
completed
against the 6LBRs. For existing registrations in the 6LR the
multihop DAD needs to be repeated against the 6LBRs to
ensure that
the entry for the address in the 6LBRs does not time out,
but that
can be done asynchronously with the response to the hosts.
For
instance, by tracking how much is left of the lifetime the
6LR
registered with the 6LBRs and re-registering with the 6LBR
when this
lifetime is about to run out.
For the synchronous multihop DAD the 6LR performs some
additional
checks to ensure that it has a Neighbor Cache entry it can
use to
respond to the host when it receives a response from a 6LBR.
This
consists of checking for an already existing (Tentative or
Registered) Neighbor Cache entry for the registered address
with a
different EUI-64. If such a Registered NCE exists, then the
6LR
SHOULD respond that the address is a duplicate. If such a
Tentative
NCE exists, then the 6LR SHOULD silently ignore the ARO
thereby
relying on the host retransmitting the ARO. (This is needed
to
handle the case when multiple hosts try to register the same
IPv6
address at the same time.) If no Neighbor Cache entry
exists, then
* The entire sentance '(This is needed...same time.)' is inside brackets. Do
not need the brackets.
the 6LR MUST create a Tentative Neighbor Cache entry with
the EUI-64
and the SLLAO. This entry will be used to send the response
to the
host when the 6LBR responds positively.
When a 6LR receives a Neighbor Solicitation containing an
Address
Registration option with a non-zero Registration Lifetime
and it has
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
