Zach Shelby a écrit :
Hi,
Thread now on 6lowpan only.
Jonathan Hui wrote:
Hi Richard,
If both egress routers are advertising default routes, then I see
no problem with the stub network deciding which to choose. If they
have different costs, then definitely the two should be advertising
different costs. If the meter network only wants to accept traffic
to a particular prefix, then it should only be advertising that.
Agreed.
I do think we need to better define what exactly is an Edge Router
in and out of a 6lowpan context. In general, I think of an Edge
Router as nothing more than a router that routes between an L2N
network to a non-L2N network. In the 6lowpan context, we typically
associate an Edge Router with one that also maintains the
"whiteboard" for nodes in the 6lowpan network. However, I'm not
sure we need to bind them together.
Yep, I agree it needs to be a generic term usable in both 6LoWPAN and
IP contexts (e.g. in roll).
Proposal 1: We call it an Access Router (AR) and agree to share that
term with ROLL. An AR is simply a router that routes between L2N and
non-L2N networks.
I agree with the term AR, and it simply routes between L2N and non-L2N
networks. In this sense it would (1) no longer state its egress and the
L2N interface share the same IPv6 subnet (as the current 6lowpan ND
document states) and (2) would need a definition at least distinguishing
it from the AR of rfc3753 "mobility terminology".
Proposal 2: We define Whiteboard as an additional feature that SHOULD
be implemented in an Access Router but MAY be implemented on any
other node in the network (e.g. in the ad-hoc LoWPAN case).
I'm interested in the 'whiteboard' conceptual data structure.
Specific to the 6LoWPAN ND draft, you do bring up an important case
- one where two or more Edge Routers are not connected by a
"backbone" network. I think there are interesting questions there
that are not dealt with in the current 6LoWPAN ND draft (e.g. how
is the whiteboard information distributed between edge routers if
at all? can we have a particular whiteboard specific for a prefix
maintained at only the Edge Router that advertises that prefix? do
whiteboards have to be maintained at edge routers?). We should
probably open a new thread on this topic in the 6LoWPAN ML...
The Whiteboard is specific to a LoWPAN (= a prefix). Whiteboard
information is not distributed between different LoWPANs (there is no
point). In an extended LoWPAN multiple whiteboards on ARs are part
of the same LoWPAN (same prefix) and use a backbone link to perform
DAD and claim/defend node addresses across the whole LoWPAN.
A Whiteboard does not need to be located at an AR, but it is a
logical place in most cases. In the Extended LoWPAN case the
whiteboard needs to be located on nodes which have a shared backbone
link (usually ARs).
We discuss that a little in the ND draft but I think it can be
expanded to make that clear with an example.
YEs, 'whiteboard' is presented at length in the ND draft. Reading it
let me represent what I understand:
One entry in the whiteboard is for one unique node, and contains these
fields:
IPv6 Prefix
IPv6 address1(128bit)
IPv6 address2(128bit)
Interface ID (64bit)
Owner Interface Identifier(64bit)
Transaction ID1 (16bit)
Transaction ID2 (16bit)
Transaction ID3 (16bit)
Transaction ID4 (16bit)
Lifetime(32bit)
I've put an entry "IPv6 Prefix" because you mentioned it above, and
makes sense to have a unique prefix for all nodes in the lowpan, be it a
subnet. But it would be helpful to say whether it is a 'prefix length'
attached to the IPv6 address1/2 fields below it, or is it an independent
bitstring (of what length?), etc.
There are two IPv6 addresses in each entry because the draft says
whiteboard is similar to a MIPv6 Binding Cache, which has 2, but I'm not
sure this was the intention.
Also the draft says that the node may have several addresses, but I'm
not sure the intention to have n IPv6 addresses in each entry - or is it?
Also there's an IID and an OII, but I doubt the intention is to have two
64bit identifiers.
At times it is _implied_ that a MAC address could be in the whiteboard,
but it is not clear whether yes or no, and whether a 48bit address or a
16bit 'short' address.
I think this could be clarified further. I personally see the en entry
in the whiteboard conceptual data structure to contain only the following:
IPv6 address
Prefix length
MAC short address
MAC address
lifetime
TID1
TID2
TID3
TID4
Alex
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
