Subject: [6lowpan] Single-interface routers...

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Apr 2009 20:29:02 +0200

Dear 6LoWPANners,

This is clarification discussion issued from recent exchanges on ROLL 
list, and in private with some co-authors - I thank for having taken the 
time.

Often was mentioned that 6lowpan/roll router would have a single 
interface, that subnet and routing is different than  my understanding, 
and exact match (non-longest-prefix) match and host-based routes are 
relevant to this new IP routing model.

Let me picture what I understand by an IP router:

          if1 ------ if2
     --------|Router|-------
      subnet1 ------ subnet2

              Router forwards by inspecting dst field and longest-prefix
              matching it in the routing table.

Moreover, a router decides to forward a packet to only one outgoing 
interface, among two, like this:

                     _______
                    /
             ------/if0
        ----|Router|
             ------\
                    \if1
                     ------

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 /
             \      /
              \----/

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?

A table of MAC addresses?  (dst of the received packet, exact match search).

A table of IP addresses? (with a new exact match search).

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).

Alex

---

From: Zach Shelby <[email-masked]>
Date: Sat, 11 Apr 2009 11:27:22 +0300

Alex,

I do not agree that this is that new of an IP routing model. In wireless 
mesh networks it surely is not. For a decade MANET has been doing IP 
routing in a similar way, and those of us involved with embedded IP have 
been doing IP routing like this for just as long. We have several 
commercial and open-source 6LoWPAN implementations, and plenty of MANET 
implementations doing this. Other non-IP embedded wireless network 
solutions do L3 routing using the same paradigm - for example ZigBee 
uses a variation of AODV style routing.

If it really that hard to understand, then we will just have to describe 
it better. Some suggestions below on how to do that.

> interface, among two, like this:

Yep, we only have this in edge routers connected to other IP networks. 
In that case if0 maye be an Ethernet interface, and if1 a 6lowpan 
wireless interface. The edge router does IP routing between these 
interfaces.

>       ---------------- new "subnet"

This is correct, 6LoWPAN nodes have a single interface participating in 
a LoWPAN. If a node has multiple interfaces each operates independently.

> which fields of an incoming packet?  And it would match it how?  Into a 

It matches the IPv6 destination address, with an IP route table which 
logically contains Destination.Address, Next-hop.Address tuples. If 
there is no match the router uses a default next-hop route up to an ER 
(it may keep secondary next-hop defaults). 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.

A host uses a default next-hop router (the one it sends RR messages to). 
It may also use secondary default next-hop routers.

> A table of MAC addresses?  (dst of the received packet, exact match 

No, the link-layer dst address would be that of the SensorRouter 
receiving the packet. Link-layer src/dst are only for that hop.

> 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. However, as there is a direct mapping between IID and the L2 
address 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.

> 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. We don't 
have subnets as the links are so unstable they can't support subnets as 
defined by IPv6.

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.

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.

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? Most MANET protocols work fine in such a network from practical 
experience.

- Zach

> Alex
> 
> 
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

-- 
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain 
legally privileged information. If you are not the intended recipient, 
please contact the sender and delete the e-mail from your system without 
producing, distributing or retaining copies thereof.

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 11 Apr 2009 15:10:41 +0200

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?
> 
>  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.

> 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.

> 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.
> 
>>  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).
> 
>  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.

>  detail. draft-ietf-6lowpan-nd and architecture doc. Can use a figure

Yes, I could help describe that.

> Operations. Can be improved, with more detailed description and an

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).

>  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-masked] https://www.ietf.org/mailman/listinfo/6lowpan
>> 
>