On 06/14/10 01:29 AM, Daniel Gavelle wrote:
Samita,
An appendix describing typical use cases for the ABRO and context /
prefix distribution is a very good idea.
I also think the text around section 8.1.3 and 8.1.4 could be clarified.
The lines below imply that if two 6LBRs are sending different context
information then the 6LR needs to store and forward both sets of contexts.
"The router keeps state for each 6LBR that it sees with an ABRO. This
includes the version number, and the complete set of Prefix
Information options and 6LoWPAN Context options. "
From the discussions we have had, there should only ever be one set of
contexts in a correctly configured network and the 6LR only needs to
store (and forward) one set of context information.
When multihop prefix and context distribution is used, then
each 6LR needs to be able to forward all the information it receives
from other routers. Otherwise the multihop distribution mechanism
doesn't work.
That means tracking prefix and context information per ABRO. Thus the
quoted text above is required. Anything else would require either
tossing out the multihop distribution from the spec, or having the
protocol only be capable to support a single 6LBR (which means that
routing would have a single point of failure.)
For compression to work the compression context information must be in
synch (to the degree required by section 7.2 - it takes a while for
changes to propagate through the network), hence the management of the
context information that is being distributed needs care. But this is an
external management problem and not a protocol problem. Of course, out
of scope, there could be a management protocol to keep the 6LBRs in synch.
We're trying to make this more clear with this text:
8.1. Multihop Prefix and Context Distribution
The multihop distribution relies on Router Solicitation messages and
Router Advertisement (RA) messages sent between routers, and using
the ABRO version number to control the propagation of the information
(prefixes and context information) that is being sent in the RAs.
This multihop distribution mechanism can handle arbitrary information
from an arbitrary number of 6LBRs. However, the semantics of the
context information requires that all the 6LNs use the same
information, whether they send, forward, or receive compressed
packets. Thus the manager of the 6LBRs need to somehow ensure that
the context information is in synchrony across the 6LBRs. One way to
do that is to treat the context and prefix information as originating
from some logical and virtual source, which in essence means that it
looks like the information is distributed from a single source.
If a set of 6LBRs behave as a single one (using mechanisms out of
scope of this document) so that the prefixes and contexts and ABRO
version number will be the same from all the 6LBRs, then those 6LBRs
can pick a single IP address to use in the ABRO option.
Does that make sense?
Should we specify other examples than this "one way"?
Erik
Daniel.
Samita Chakrabarti wrote:
Hi,
From the discussions on this thread, it seems that there is a room
for some
mis-configuration or mis-interpretation of the intent of usage of the
current low-power-nd draft in case of multiple 6LBRs.
I agree that in the body of specification, we may not want to impose too
much restrictions based on a specific deployment, however, if it helps
the
implementors and early adopters to provide some guideline on possible
problem avoidance - it makes sense to provide such examples/guidelines in
the Appendix section. Will that be a workable solution?
We know that the separation of two LoWPANs are expected to happen in L2 [
assuming the lowpower networks are configured with proper
L2-security]. Also
implementation of 6LRs can have knobs to reject/ignore mismatched
prefixes
from different 6LBRs.
I have heard some discussions in a deployment where they might want to do
ND-09 RS in a unsecured link to get RA first to find out the
default-router
address and use PANA authentication mechanism to get a group key for
L2-security. This breaks the assumption that LLN-ND operation will be
done
on a secured l2-link.
Anyway, I think discussing possible deployment issues and known
solutions in
the Appendix would be helpful for interoperability and adoption of the
specification.
Thanks,
-Samita
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf
Of Erik Nordmark
Sent: Friday, June 11, 2010 5:59 AM
To: Zach Shelby
Cc: [email protected]
Subject: Re: [6lowpan] Multiple 6LBRs
On 06/11/10 02:48 AM, Zach Shelby wrote:
Yep, I agree with Erik here. In an enterprise environment you will be
able to manage the whole 6LBR infrastructure (and the contexts), so we
are OK there. In home environments you will probably keep LoWPANs
separate using L2 encryption.
OK
However as public/urban 6LoWPAN networks become more common (we are
deploying one right now in Oulu, Finland), there will be situations
where a 6LR will hear RAs originated from different authoritative
border routers with different points of attachment to the Internet
(and different sets of context). We have two choices what to do in
this situation:
I think it is hard to discuss what technical approaches we should take
here
without understanding something about the envisioned usage and
associated
business model.
The notion of having devices that pick up on any (wireless) connectivity
and
just try to use it isn't something that we've seen anywhere else.
For instance, for a cell phone there is a business arrangement with an
operator, combined with roaming agreements between operators, which
ensure
that the cell phone connects to a predictable set of operator networks.
(And
in many cases the user can control the selection.) For free WiFi
networks
there is normally a user interface where the user can choose which
network
to associate with.
In both of those cases there isn't likely to be a radical change just
because the radio connectivity changed.
What mechanisms will there be in this public 6LoWPAN for devices to
select
which 6lowpans they will participate in? What prevents the public
6LoWPAN
from interfering with devices that are part of a (private) factory or
building 6LoWPAN?
a) Say nothing about it. Here we have a risk that a poor 6LR
implementation will start mixing contexts, or will even advertise two
sets of RAs - which is obviously broken. This is the case Daniel (and
myself) are concerned about.
b) Explicitly say what the 6LR should do in this case. If we
explicitly forbid a 6LR from attaching to two different LoWPANs at the
same time, then this fixes this potential problem (it can obviously
still attach to multiple default routers in the same LoWPAN). This way
the host -> 6LR -> 6LBR attachments are always under the same
authoritative border router (which might be a coordinated one as
pointed out above).
I don't think the fact that the network is route-over and we have 6LRs
introduces anything fundamentally new. A single-hop network where the
hosts
hear RAs from multiple routers is just as problematic. For example, the
host
might configure an IP address from the prefix of operator A, and the
packets
get routed via operator B, and ingress filtering blocks all those
packets.
(That is a fundamental issue in what could be called "ad-hoc
multihoming";
nothing specific to wireless or 6LoWPAN here.)
You say "forbid a 6LR from attaching ..." but there isn't any notion of
attaching to a network in IP. This is something that is handled below IP
(802.11 associations, PPP authentication, VLANs, or early stages of IP
configuration in the case of PANA.)
The issue is that at whatever level that association happens, the same
level
needs to provide sufficient isolation with respect to routing.
That is necessary to avoid the mismatch between the addresses a node
configures and where its packets are routed.
Erik
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
