Carsten, Geoff, et al.
>This is not saying that we want to actually standardize all three of
>these backends. But we should at least do proof-of-concept ("napkin")
>versions of all three to ensure the host-router interface works well
>with either of them.
>From a standards point of view, I am really fine with clear, limited
>specifications which do not leave a lot of features optional. While 99% of
>6lowPan systems in my corner of this business will have no risk of creating
>duplicate IP addresses, I do believe that a relevant fraction of the systems
>may benefit from redundant / geographically distributed edge routers to get
1) Short routes to the backbone when everything works
2) Maintain connectivity when one edge router goes away for whatever reason -
maintenance included.
In short, yes, there is a need for backbone-coordinated edge routers. I also
believe it should be kept really simple to be interesting for low-end market
solutions. This points towards simple multicast advertisement - but: and this
is the important part: I would hate three options. This would require all
vendors to implement all three to be on the safe side.
Thus: One acceptable compromise is more important than an optimized approach
which rules out 50% of potential system deployments. And yes, please: Let this
be defined in a companion spec, which vendors MAY decide to implement.
- Anders
________________________________
Fra: [email protected] på vegne af Carsten Bormann
Sendt: to 12-11-2009 03:50
Til: 6lowpan
Emne: [6lowpan] Way forward for 6LoWPAN-ND, consensus call
After the 6LoWPAN meeting, there have been some hallway conversations
on the need for DAD vs. the expense of DAD. Clearly, the 4861 way of
involving potentially all hosts in that process is not applicable in
most interesting 6LoWPAN configurations. More generally speaking,
whatever we do here, it should not involve the hosts.
The remaining discussions essentially were about how the "fabric"
(please excuse me using that term, which I'll use for the set of nodes
that are not just hosts) might achieve proper address allocation
and/or validation (DAD). The right answer seems to depend on the
specific areas of application, network configurations, and
characteristics of that fabric. For some cases, the centralized
approach with one or more edge routers is the right way to do this;
for others, the additional messages needed for a distributed approach
may be justified by the increased flexibility possible with that.
But the important point is that whatever the fabric does here, the
hosts do not care. They want to register their addresses with the
fabric (not just for allocation/DAD, but foremost to get routed to),
and couldn't care less how that oracle comes up with "yes" or "no", or
how it derives any allocations requested. 6LoWPAN-ND differs from
4861 in that the host-router interface is fully node-initiated, which
is the only appropriate way to do this with potentially sleeping
nodes.
Keeping that host-router interface simple and interoperable is the
most important concern: There will be billions of these 6LoWPAN host
nodes, and their interface to the network should be based on a stable
specification and isolated from the specifics of the intra-fabric
algorithms.
So the (in hindsight very obvious) way forward is:
-- split off the host-router interface part of 6LoWPAN-ND into one
document of its own. This document will contain the router
discovery and node registration protocol components of
draft-ietf-6lowpan-nd-07.txt (NR/NC with code != 1, the RA
parameters/options). Based on the input from 6man, the ADs and the
IAB, this will also now make use of the terminology in
draft-ietf-autoconf-adhoc-addr-model-00.txt that is quickly
becoming the new consensus for this kind of network. This part of
the split is the document that will update RFC 4944 in the way
envisioned by RFC 4861 section 1.
-- rename the rest of draft-ietf-6lowpan-nd-07.txt, i.e. the
fabric-side part (relayed NR/NC, Edge Router operation, OIIO) into
"6LoWPAN Edge Router backend", as a draft separate from the
above common router discovery/node registration protocol.
-- go ahead and define other backends for those cases that merit it.
Three types of backends beyond the existing Edge-Router based backend
have been mulled over in various hallways so far:
-- a multicast-based backend where all 6LoWPAN routers announce and
defend their client hosts' addresses between themselves (without
involving the hosts). A degenerate case is the simple star
network, where the single hub node can do all this all by itself.
-- a routing-system based backend, where the management of addresses
is integrated into the routing protocol (e.g., in RPL by adding
information to DAO type messages and processing rules).
-- a DHCP-based backend (which could use either of the above for DAD).
This is not saying that we want to actually standardize all three of
these backends. But we should at least do proof-of-concept ("napkin")
versions of all three to ensure the host-router interface works well
with either of them.
Many thanks to Geoff Mulligan and Thomas Clausen for their help in
identifying this approach, and to Ralph Droms, Jari Arkko, and Dave
Thaler for supplying the missing links.
Geoff Mulligan, who is acting as the chair for this document (because
I'm a co-author), has requested me to announce this and ask the
working group for consensus on this approach. Please reply by
November 18, 24:00 UTC
with your concerns, comments, or just plain support that this is
indeed the way forward.
Gruesse, Carsten
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
