Zach Shelby a écrit :
[ER discussion left apart]
But when we talk the picture of 6lowpan/roll router, it seemingly
does not need to make any such IP routing decision:
---------------- new "subnet" |if0 ---- / \ / \ / Sensor \
\ Router / \ / \----/
This is correct, 6LoWPAN nodes have a single interface participating
in a LoWPAN.
Ok.
If a node has multiple interfaces each operates independently.
Ok, I get this part, it's often the case anyways in non-6lowpan.
What would be the critical SensorRouter operation? It would look
at which fields of an incoming packet? And it would match it how?
Into a table of what?
It matches the IPv6 destination address, with an IP route table which
logically contains Destination.Address, Next-hop.Address tuples.
Something like this?
IP route table
----------------------------------------
| Destination.Address | Next-hop.Address |
|----------------------------------------|
search | address1(128bit) | nexthop1(128bit) |
dst(128bit) ---------->| address2(128bit) | nexthop2(128bit) |
(IP dst field of | ... | ... |
the incoming packet's | addressn(128bit) | nexthopn(128bit) |
base header.) ----------------------------------------
If yes, an IP route table has additional necessary fields: prefix
lengths and interface. I would like to picture them to make sure we're
in concordance with implementations - do you think I could?
If there is no match the router uses a default next-hop route up to
an ER (it may keep secondary next-hop defaults).
I think this is very important. First, when saying there may be no
match it implies that we have a precise idea about what a match is, i.e.
the search method is clearly defined. Until now that search method was
longest-prefix match (with various implementations on various types of
data structures, but always a longest-prefix match).
Second, it means there are special routes in the routing table, called
default, that I would like to picture like this:
IP route table
----------------------------------------
| Destination.Address | Next-hop.Address |
|----------------------------------------|
search | address1(128bit) | nexthop1(128bit) |
dst(128bit) ---------->| address2(128bit) | nexthop2(128bit) |
(IP dst field of | ... | ... |
the incoming packet's | addressn(128bit) | nexthopn(128bit) |
base header.) | ::/0 | nexthopd(128bit) |
| ::/0 | nexthope(128bit) |
----------------------------------------
If there is some reactive routing algorithm it may also trigger some
kind of route request action (e.g. DYMO) which would then find a
next-hop for that destination.
I agree, that would be the ROLL part...
A host uses a default next-hop router (the one it sends RR messages
to). It may also use secondary default next-hop routers.
I agree, I've pictured the two default routes above.
A table of MAC addresses? (dst of the received packet, exact match
search).
No, the link-layer dst address would be that of the SensorRouter
receiving the packet. Link-layer src/dst are only for that hop.
Pictorially,
if0----- eth0
-----------------------------| ER |---Internet
|if1 |if2 mac0-----
|mac1 |mac2
---- ----
/ \ / \
/ \ / \
/ Sensor \ / Sensor \
\ Router1/ \ Router2/
\ / \ /
\----/ \----/
How would one see the use of MAC addresses in this picture? A
means coming to mind is typical ND resolving IP addresses into MAC
addresses. But.
Draft says:
Link-layer information should be used to maintain the neighbor cahce
whenever possible rather than using ND traffic.
What is the 'link-layer information' used and how? Once I know that, I
can draw the respective tables of MAC addresses and the ways they are used.
A table of IP addresses? (with a new exact match search).
Yes, it uses an IP route table doing an exact match search on the
IPv6 dst.
Ok, in this case I know what to picture as search algorithm in the
routing table: an exact match search, and answers some questions above.
I want also to stress that this is completely different than the
typical IP routing table using a longest-prefix match search.
I'm open to accept this is something new, and I would like to stress
this requires new implementation effort, which may raise compatibility
issues too, which I could discuss separately. (would a 6lowpan node work
ok when adding a WiFi interface to it? which needs typical routing table).
However, as there is a direct mapping between IID and the L2 address
This mapping could be concluded as true conceptually... It is a very
strong assumption in 6lowpan which should be stated upfront somewhere
very early in the draft. Because it is not assumed anywhere else, or
otherwise I can't remember.
in 6LoWPAN it is actually the L2 address it is matching if the
destination address is in the LoWPAN. This has no importance on the
IP routing operation though. If the address is outside the LoWPAN a
default route to an ER is used.
What is the IP routing model assumed by the single-interface
router?
The text in 6lowpan ND is not clear about this, because at several
places it uses old terms with new assumed meanings (for example it
says there's a single subnet, a single link-scope multicast scope,
but at the same time comments say IP routing and subnet is not what
used to be).
We are going to stop using the "subnet" term as it does not describe
what we have here. We tried to define LoWPAN Subnet, but subnet is
too overloaded with restrictions and presumptions. In
draft-ietf-6lowpan-nd-03 we are just calling it a LoWPAN, and a
LoWPAN is defined by a shared prefix across the interfaces of nodes.
But a shared prefix across the interfaces of nodes is a subnet, why
calling it a "LoWPAN"?
For me until now the radical differences of LoWPAN vs typical subnet and
IP routing are the following:
-no longest-prefix match, but always exact match.
-an IID is always related to a unique MAC address and vice-versa.
-use ND as least as possible, and "link-layer information" as much as
possible.
So, instead of a LoWPAN I'd call it an EMIMLIND like in
"ExactMatch-IidisMac-LinkLayerInforatherthanND". (excuses, no offence,
just to say a more suggestive name should be found which better
illustrates this in terms of its implementation traits).
We don't have subnets as the links are so unstable they can't support
subnets as defined by IPv6.
Well this is a long discussion about links which are unstable... if
links are unstable then IP can't make them more stable... whatever
energy is spent on it.
Based on your comments we do need to describe a few things better for
newcomers:
1. That LoWPAN routers route on a single interface, and the model for
routing with that single interface should be described in some more
detail. draft-ietf-6lowpan-nd and architecture doc. Can use a figure
like that above.
Yes, I could help describe that.
2. The LoWPAN model, sharing a prefix which you may do IP routing
within. This is not an IPv6 subnet. draft-ietf-6lowpan-nd and
architecture doc.
3. How does next-hop determination work with this model. We already
describe this in draft-ietf-6lowpan-nd under Host (Node in -03)
Operations. Can be improved, with more detailed description and an
example.
WEll yes, it could be improved, and I hope it clarifies what "link-layer
information" is, how it allows a node to safely get rid of using ND
(as02 says).
4. How does an IP routing algorithm work in such a network? This is a
job for ROLL, although an architecture doc for 6lowpan may give a
simple example?
IP routing algorithm... I think this encompasses many things, among
which at least the search method in the routing table is relevant to
6lowpan documents as well.
Most MANET protocols work fine in such a network from
practical experience.
Well yes, I guess they do in particular cases, but even those MANET
protocols do have some issues about how IPv6 addresses are allocated and
what the subnet structure is, for example, see the AUTOCONF WG.
Alex
- Zach
Alex
_______________________________________________ 6lowpan mailing
list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
