Subject: [6lowpan] Thoughts on draft-ietf-6lowpan-nd-07

From: Ralph Droms <[email-masked]>
Date: Mon, 16 Nov 2009 00:43:27 -0500

I have some comments on draft-ietf-6lowpan-nd-07.  I know there has
been discussion of this draft during the IETF meeting in Hiroshima,
and plans to split draft-ietf-6lowpan-nd-07 into two pieces have been
suggested.  I think my comments can be viewed as either complementary
to or independent of those plans.

I have two questions based on reading draft-ietf-6lowpan-nd-07:

1. In a mesh-under network, the L2 characteristics of the lowpan are
close to those usually assumed for implementation of IPv6; in
particular, there are no "lowpan routers" at L3 and L3 messages *can*
be delivered (perhaps with lower probability of success) directly
between lowpan nodes.  Why is ND not sufficient in this model?  Would
proxy ND be sufficient?

2. In a route-over network, all nodes are routers and forwarding
information is carried in the routing protocol, eliminating the need
for default router information and address resolution functions.  Why
is lowpan-ND needed in a route-over network?

To answer these questions, draft-ietf-6lowpan-nd-07 needs a
description of the components of a lowpan, the traffic delivery
functions provided by the individual components and by the lowpan as a
whole.  RFC 4944 considers just the mesh-under case, while
draft-ietf-6lowpan-nd-07 considers both mesh under and route over
network.  draft-ietf-6lowpan-nd-07 introduces new concepts like
"lowpan router" and "edge router", and "IP routing" and "Relaying"
without a clear architectural model and definition of how these
components and functions operate in practice.

For example, from the presentation at the 6lowpan WG in Hiroshima, I
understand that all of the nodes in a 6lowpan network are considered
to be in one subnet (more precisely, the subnet is "the interfaces of
LoWPAN Nodes and Edge Routers sharing the same subnet prefix') and all
sharing one IPv6 prefix.  A 6lowpan router "forwards datagrams between
arbitrary source-destination pairs using a single 6LoWPAN interface
performing IP routing on that interface".  As this forwarding paradigm
is not the usual router behavior of forwarding IP traffic between
interfaces attached to different links, some explanation is required
for how the forwarding paradigm works.

In some places in the document, I think this forwarding function is
called "relaying".  What is "relaying" and how does it relate to
"forwarding" as mentioned in the definition of "6lowpan router"?

Any description of 6lowpan needs to differentiate between mesh-under
and router-over behavior, or explain which parts of the document apply
to which form of lowpan.  I can understand how a mesh-under lowpan has
datagram delivery behavior that approximates wired ethernet, and how
additional functions are required because of the differences in lowpan
delivery reliability, node sleep/available cycles and
broadcast/multicast/unicast semantics.  I would expect that a
mesh-under lowpan does not use lowpan routers, and uses some
additional machinery to work around differences between a mesh-under
lowpan and the more usual link-layer delivery characteristics assumed
by IP-over-foo documents.

Is the route-over architecture, using nodes and lowpan routers, shared
with any other lowpan architectures like the work in the roll,
autoconf or manet WGs?  If so, it would be good to coordinate closely
with those models; if not, the new route-over architecture needs a
more detailed description.  It's also at least a little surprising to
me that the IEEE 802.15.4 spec isn't referenced directly; are there
some architectural notions that can be shared from that spec?

My suggestion is to add some text that describes the model and
behavior of the various lowpan components that are used to build a
lowpan protocol that provides the functions of RFC 4861 ND.  The
fundamental datagram machinery needs to be formulated and described
first and then the new protocol can be built on that machinery.

- Ralph

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 16 Nov 2009 07:05:52 +0100

Quick answers:

On Nov 16, 2009, at 06:43, Ralph Droms wrote:

> between lowpan nodes.  Why is ND not sufficient in this model?  

RFC 4861 ND works in a pure RFC 4944 mesh-under network if:
1) the mesh-under (L2) routing protocol provides subnet-wide multicast,
2) that is efficient enough to be used for routine ND messages,
3) nodes are awake often enough to detect and reply to NS messages.

Such networks do exist, but these assumptions are not necessarily compatible with many application scenarios we have in mind; this is the reason we started with ND optimizations.

> Would

I haven't seen such a design yet, so I don't know.

> 2. In a route-over network, all nodes are routers

That is not the assumption: The assumption is that there are hosts and routers, and that the forwarding function is performed by the routers.  There needs to be a protocol that enables hosts to register themselves to routers, independent of the routing protocol.
Since the host-router relationship is somewhat ephemeral due to the nature of the wireless links, address assignment needs to be lowpan-wide instead of per host-router relationship.
As ND-07 is not by itself supporting host-host communication, address resolution only happens between hosts and routers.

Re one other term: "relaying" is the term ND-07 is using for what routers do between themselves to process host NR messages; it is not IP forwarding.
It is probably more appropriate to give the inter-router message a different name (e.g., relayed NR, RNR), so the confusion between this relaying process and IP forwarding is reduced; this is the part that will move to the second document after the split.

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 16 Nov 2009 08:08:24 +0100

Hi Ralph

>Such networks do exist, but these assumptions are not necessarily
compatible with many application
>scenarios we have in mind; this is the reason we started with ND
optimizations.

Another way of saying this is that mesh under is more often than not
akin to NBMA. Fully mesh might exist and multicast emulation might exist
though I've seen neither so far. 

But there are actual networks out there where the model is really that
of virtual circuits, established either hub and spoke (to a sink) or
point to point (control loop).
So the model is closer to Frame Relay, for which as we all know 4861 is
not better suited than ARP was for IPv4. Issues:
* non transitive: A has a circuit to B and B has a circuit to C does not
mean A has a circuit to C. Direct (one hop) multicast emulation cannot
do DAD.
* local addressing: A might not see B with the same address (VC nb) as C
sees B. So A could not send redirects to C for B. And SLLAO is useless
(same as 3122) if VCs are switched.

Our draft can act as a complement to 4861 in transit links (to grant the
right to use an address) and a complement to 3122 on NBMA. Our draft is
enough for host to router, and the existing ND operation still provide
value for host to host.

>I haven't seen such a design yet, so I don't know.

Recursing proxy ND demands a strict hierarchy / spanning tree. Could be
done but probably difficult and inefficient. 
This is certainly incapable to handle movement - there were drafts like
this in NEMO long ago.

Cheers,

Pascal

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Mon, 16 Nov 2009 10:06:03 +0100

Hi Carsten, Ralph,

I think indeed it is important to consider mesh under and route over
separately, as this has strong impact on the L2 behavior: in mesh under,
- links are transitive, multicast can be costly
In route over links are not transitive and multicast is not that costly.
More comments inline.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Carsten Bormann
> Sent: lundi 16 novembre 2009 07:06
> To: Ralph Droms (rdroms)
> Cc: 6lowpan
> Subject: Re: [6lowpan] Thoughts on draft-ietf-6lowpan-nd-07
> 
> Quick answers:
> 
> Such networks do exist, but these assumptions are not 
> necessarily compatible with many application scenarios we 
> have in mind; this is the reason we started with ND optimizations.
> 
> > Would
> > proxy ND be sufficient?
> 
> That is not the assumption: The assumption is that there are 
> hosts and routers, and that the forwarding function is 
> performed by the routers.  There needs to be a protocol that 
> enables hosts to register themselves to routers, independent 
> of the routing protocol.
I may be missing a shortcut. Where does the need for registration come
from? In e.g. an ethernet IPv6 network hosts do not register (RS/RA).

> Since the host-router relationship is somewhat ephemeral due 
> to the nature of the wireless links, address assignment needs 
> to be lowpan-wide instead of per host-router relationship.
If you have one prefix per router you do not need this. What are your
major concerns about this model?

Julien
> As ND-07 is not by itself supporting host-host communication, 
> address resolution only happens between hosts and routers.
> 
> Re one other term: "relaying" is the term ND-07 is using for 
> what routers do between themselves to process host NR 
> messages; it is not IP forwarding.
> It is probably more appropriate to give the inter-router 
> message a different name (e.g., relayed NR, RNR), so the 
> confusion between this relaying process and IP forwarding is 
> reduced; this is the part that will move to the second 
> document after the split.
> 
> Gruesse, Carsten
> 
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan
>

---

From: Ralph Droms <[email-masked]>
Date: Mon, 16 Nov 2009 14:30:17 -0500

Responses - well, mostly more questions - inline...

On Nov 16, 2009, at 1:05 AM 11/16/09, Carsten Bormann wrote:

> compatible with many application scenarios we have in mind; this is  
> the reason we started with ND optimizations.

OK, and I understand you're working on application scenarios.  I think  
you need a digest from the applications scenarios into a set of  
characteristics of the underlying L2 services that is explicitly  
written down somewhere.

Can you reuse the scenario work from the roll WG?

> I haven't seen such a design yet, so I don't know.

Might be good to consider it...

> That is not the assumption: The assumption is that there are hosts  
> and routers, and that the forwarding function is performed by the  
> routers.  There needs to be a protocol that enables hosts to  
> register themselves to routers, independent of the routing protocol.

Is it commonly assumed in lowpans that there are both hosts and  
routers or is that architectural assumption specific to the 6lowpan/ 
802.15.4 work?

> Since the host-router relationship is somewhat ephemeral due to the  
> nature of the wireless links, address assignment needs to be lowpan- 
> wide instead of per host-router relationship.

Do you mean that the only address resolution is for a router to  
resolve the MAC address of a destination host?

> Re one other term: "relaying" is the term ND-07 is using for what  
> routers do between themselves to process host NR messages; it is not  
> IP forwarding.

Is this relaying specific to ND-07; i.e., does ND-07 require a  
forwarding overlay?

> It is probably more appropriate to give the inter-router message a  
> different name (e.g., relayed NR, RNR), so the confusion between  
> this relaying process and IP forwarding is reduced; this is the part  
> that will move to the second document after the split.
>
> Gruesse, Carsten
>

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Mon, 16 Nov 2009 14:33:56 -0500

Responses in line...

> (same as 3122) if VCs are switched.

OK, so these models really need to be documented so we can all start  
on the same page.  Which model(s) are you expecting for 6lowpan?

> enough for host to router, and the existing ND operation still provide

"host to router"?  What address resolutions does ND-07 provide?

> This is certainly incapable to handle movement - there were drafts  

Why would recursing proxy ND be necessary?  If the mesh-under provides  
hub-and-spoke reachability, why not put proxy ND at the hub?

- Ralph

---

From: "Colin O'Flynn" <[email-masked]>
Date: Tue, 17 Nov 2009 10:44:26 -0000

>though I've seen neither so far.

FYI 802.15.5 does have multicast support (15.5 being the mesh standard). If
you have IEEE Xplore you can get 15.5 from there, otherwise it should be out
around Dec 8th at http://standards.ieee.org/getieee802/802.15.html by my
count if they keep up with the '6 months after publication in PDF it's
free'.

Multicast is done with a combination of broadcast & unicasting messages. It
has systems to avoid a forwarding loop and some considerations to low-power.

Despite the addition of the multicasting support, it does remain wasteful of
network air time & node power. So even when we do have support for
Multicasting at the mesh layer, there are significant advantages to avoiding
it.

Regards,

  -Colin O'Flynn

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Pascal Thubert (pthubert)
Sent: November 16, 2009 7:08 AM
To: Carsten Bormann; Ralph Droms (rdroms)
Cc: 6lowpan
Subject: Re: [6lowpan] Thoughts on draft-ietf-6lowpan-nd-07

Hi Ralph

optimizations.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 17 Nov 2009 13:03:09 +0100

Hi Ralph

>on the same page.  Which model(s) are you expecting for 6lowpan?

I think it is done quite well in the draft, and in particular the fact
that we address non-transitive links, that 4861 explicitly does not
cover.
Since the draft wants to be more generic than IP-over-foo, it makes no
assumption on what the switching operation does. Some conserve the MAC
address, but others do not.

For instance, Frame relay switches the DLCI. Our draft is well suited
for Frame Relay as long as the FR is structured as a core of routers
(doing some sub-routing between them to route the host addresses) with
hosts always one DLCI away from a router. Host to host direct
connectivity in FR would be covered by RFC 3122, just the way host to
host would be covered by RFC 4861 on ethernet.

>"host to router"?  What address resolutions does ND-07 provide?

Only host to router. 

>hub-and-spoke reachability, why not put proxy ND at the hub?

We already have included proxy ND when there a backbone like an ethernet
or a TRILL network.

But the radio mesh itself is more complex than just hosts one hop away
from the backbone. That's a mesh in which we are doing some mesh under
or route over.
I thought that you idea was to do proxy ND there. If so, if you figure
that mesh as a tree, you'd need proxying at each level. All I'm saying
is that it is not a good idea.
But maybe that was not your point.

Cheers,

Pascal

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 17 Nov 2009 16:08:10 +0100

Colin O'Flynn a écrit :
>> Another way of saying this is that mesh under is more often than 
>> not akin to NBMA. Fully mesh might exist and multicast emulation 
>> might exist though I've seen neither so far.
> 
> FYI 802.15.5 does have multicast support (15.5 being the mesh 
> standard). If you have IEEE Xplore you can get 15.5 from there, 
> otherwise it should be out around Dec 8th at 
> http://standards.ieee.org/getieee802/802.15.html by my count if they 
> keep up with the '6 months after publication in PDF it's free'.

I also have access to it.

> Multicast is done with a combination of broadcast & unicasting 
> messages. It has systems to avoid a forwarding loop and some 
> considerations to low-power.
> 
> 
> Despite the addition of the multicasting support, it does remain 
> wasteful of network air time & node power. So even when we do have 
> support for Multicasting at the mesh layer, there are significant 
> advantages to avoiding it.

And what makes one think that the implementation of multicast at IP
layer (instead of reusing the 802.15.5 link-layer multicast support) is
less wasteful?

For example, one version of the 6lowpan-ND spec (the current?) said at
one point that the Edge Router performs the link-layer multicasted ND
messages on the backbone (supposedly link-layer multicast capable), on
behalf of the 6lowpan nodes, which don't speak link-layer multicast - is
it efficient to have these numerous MLD messages on the backbone for
nodes which are not on the backbone?

I mean this paragraph:
> In the Extended LoWPAN case, the Edge Router also performs proxy ND 
> operations over the Backbone Link on behalf of the LoWPAN Nodes that 
> are registered to it.

Is it efficient for the Edge Router to send a myriad of Neighbor
Advertisement messages (which are addressed to a link-layer multicast
address, and a L3 multicast address) on the backbone?

Why cluttering the backbone?

Alex

> 
> Regards,
> 
> -Colin O'Flynn
> 
> 
> -----Original Message----- From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Pascal Thubert 
> (pthubert) Sent: November 16, 2009 7:08 AM To: Carsten Bormann; Ralph
>  Droms (rdroms) Cc: 6lowpan Subject: Re: [6lowpan] Thoughts on 
> draft-ietf-6lowpan-nd-07
> 
> Hi Ralph
> 
>>> 1. In a mesh-under network, the L2 characteristics of the lowpan 
>>> are close to those usually assumed for implementation of IPv6; in
>>>  particular, there are no "lowpan routers" at L3 and L3 messages 
>>> *can* be delivered (perhaps with lower probability of success) 
>>> directly between lowpan nodes.  Why is ND not sufficient in this 
>>> model?
>> RFC 4861 ND works in a pure RFC 4944 mesh-under network if: 1) the 
>> mesh-under (L2) routing protocol provides subnet-wide multicast, 2)
>>  that is efficient enough to be used for routine ND messages, 3) 
>> nodes are awake often enough to detect and reply to NS messages.
>> 
> _______________________________________________ 6lowpan mailing list
>  [email-masked] https://www.ietf.org/mailman/listinfo/6lowpan
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 17 Nov 2009 17:49:08 +0100

> address, and a L3 multicast address) on the backbone?

Well, we try to be fully 4861-compliant on the backbone.
The backbone is supposed to be an Ethernet or a similar high-capacity link, so it should have little problem with that load.

> Why cluttering the backbone?

Because that's what 4861 does to you? :-)

Of course, the ERs could speak a different protocol between themselves, but the idea was to enable other nodes to live on the backbone link and communicate with the 6lowpan nodes without requiring any 6lowpan-specific code.  Those other nodes will speak 4861 only.

Gruesse, Carsten

---

From: "Colin O'Flynn" <[email-masked]>
Date: Tue, 17 Nov 2009 16:55:26 -0000

Hello,

> The backbone is supposed to be an Ethernet or a similar high-capacity
> link, so it should have little problem with that load.

Agreed.

> the idea was to enable other nodes to live on the backbone link and ?
> communicate with the 6lowpan nodes without requiring any 6lowpan-specific 
> code.  Those other nodes will speak 4861 only.

Is the NA/NS solely to exchange information about the whiteboard between the
ERs?

If so, they could perform a proxy-ND to respond to NS directed at nodes on
the 6LoWPAN.

Then some other method to keep whiteboards up to date could be used.

I'm not advocating such a thing, just saying if the clutter of 4861 traffic
on the Ethernet side of the ER was an issue I would think there would be
other solutions!

Regards,

  -Colin

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: November 17, 2009 4:49 PM
To: Alexandru Petrescu
Cc: Colin O'Flynn; 'Pascal Thubert (pthubert)'; 'Ralph Droms (rdroms)';
'6lowpan'

Well, we try to be fully 4861-compliant on the backbone.
The backbone is supposed to be an Ethernet or a similar high-capacity link,
so it should have little problem with that load.

Of course, the ERs could speak a different protocol between themselves, but
the idea was to enable other nodes to live on the backbone link and
communicate with the 6lowpan nodes without requiring any 6lowpan-specific
code.  Those other nodes will speak 4861 only.

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 17 Nov 2009 18:36:37 +0100

Hi Colin:

I think you're describing the draft. Basically the edge router does
proxy-ND over the backbone.
So if a node on the backbone looks up a 6LoWPAN device, the edge router
answers NS with NA on behalf of the device.
So the node sends packets via the edge router. The edge router forwards
back to the device over the lowpan.
As you figures, this is why the device needs to periodically maintain
the binding with the edge router.

This is somewhat similar to mobile IPv6 though there's no tunnel.

Pascal

>From: Colin O'Flynn [mailto:[email-masked]]
>Sent: mardi 17 novembre 2009 17:55
>To: 'Carsten Bormann'; 'Alexandru Petrescu'
>Cc: Pascal Thubert (pthubert); Ralph Droms (rdroms); '6lowpan'
>Subject: RE: [6lowpan] Thoughts on draft-ietf-6lowpan-nd-07
>
>Hello,
>
link,

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Nov 2009 00:03:46 +0100

> back to the device over the lowpan.

I don't understand why the ER needs to do proxy ND on behalf of a 
6LoWPAN node.

If a node on the backbone wants to talk to a 6LoWPAN node then it talks 
to its default route which will ICMP Redirect towards ER, and then pure 
NS/NA about the ER.

No need for ER to do proxy ND for 6LoWPAN nodes for this to work.

> This is somewhat similar to mobile IPv6 though there's no tunnel.

Moreover, in Mobile IPv6 the nodes are not behind the HA - they simply 
are gone and away.  Whereas here your nodes _are_ behind the ER yet the 
ER proxies for them - why the troubling noise and clutter?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Nov 2009 00:13:31 +0100

Carsten Bormann a écrit :
>> Advertisement messages (which are addressed to a link-layer 
>> multicast address, and a L3 multicast address) on the backbone?
> 

Sure, that's good.

>  link, so it should have little problem with that load.

Hmm... every link has its limit.  Are you sure an Ethernet would support
periodic NAs about the potentially very large number of nodes in the
6LoWPAN network?

Do we have numbers to compare?

> Because that's what 4861 does to you? :-)

:-) well not quite.  4861 does require all nodes physically connected to
a link to do this periodic NS/NA but here you require the ER to do the
periodic NS/NA on behalf of potentially very large number of nodes which
are behind it.

Ethernet uses different cables from each machine, through a hub/switch,
etc. which does scales.  But here we talk ER doing this stuff on a
single cable (is it 802.1q btw? how many VLANs on it?)  Are we sure it
scales?

> Of course, the ERs could speak a different protocol between 
> themselves,

Well no need of new protocol, just put the appropriate routes on them.

> but the idea was to enable other nodes to live on the backbone link
> and communicate with the 6lowpan nodes without requiring any
> 6lowpan-specific code.  Those other nodes will speak 4861 only.

YEs, that's good for backbone nodes to talk to 6LoWPAN nodes through ER,
but there are much simpler ways of achieving that, other than proxy-ND:
it's either to put a route on these towards the prefix valid on the
lowpan network, or to put a default route towards the border router (not 
ER) which will subsequently ICMP Redirect to it.

Now I know that's a long phrase, but it's simple in practice.  I can
picture it if you wish.

Alex

---

From: "Colin O'Flynn" <[email-masked]>
Date: Wed, 18 Nov 2009 07:21:41 -0000

Hello,

> Are you sure an Ethernet would support

>From RFC4861:
   In such cases a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT
   unsolicited Neighbor Advertisement messages to the all-nodes
   multicast address.  These advertisements MUST be separated by at
   least RetransTimer seconds.

Since they are a MAY we could just not transmit any. There probably isn't
any advantage to sending them, as I doubt ERs will store a large enough
table of previously received NAs, but just do a NS when they need to find
something.

> etc. which does scales.  

ND messages would be multicast anyway, so almost everyone would see them
through a switch. Hence I don't see the difference between 10000 computers
in a local subnet and 10000 sensor nodes in a local subnet.

Assume we are at 10Mbits/second on Ethernet, through a hub so everything is
broadcast.

NS is 24 bytes. Let's add some options to bring it up to 40 bytes. Add IPv6
header for 80 bytes. Add Ethernet header for 96 bytes. Assume some overhead
for CRC, retransmission, sync, etc etc, let's say 2x overhead so I can't be
accused of underestimating: 192 bytes. 192 bytes = 1536 bits.

10E6 / 1536 = 6510 NS messages/second. Yikes! Sure it's not a good estimate,
but it's so far above our requirements I don't see a need to get a better
estimate. 

I'm assuming the proper deployment for a extended LOWPAN network is to put
the entire LOWPAN behind a router. The only traffic to worry about is LOWPAN
traffic, which would pale in comparison to the traffic generated by even one
or two computers, with users watching YouTube and studiously downloading
copyrighted material. 

> ER) which will subsequently ICMP Redirect to it.

This works great for a single router, it's how we are doing it at Atmel. I
have a DD-WRT programmed as the default route; it is then programmed with a
re-direct to the ER device, works perfect! 

But a very good reason to do NA/NS is so that when you have two or more edge
routers in the same physicalish zone you don't end up with address
collisions. Take the following from
http://tools.ietf.org/html/draft-ietf-6lowpan-nd-07#page-12 (in case
ASCII-art is lost):

         Infrastructure Cloud
                  |
                  |
               +-----+                 +-----+
               |     | Router          |     | Host
               |     |                 |     |
               +-----+                 +-----+
                  |                       |
                  |     Backbone link     |
            +--------------------+------------------+
            |                    |                  |
         +-----+             +-----+             +-----+
         |     | Edge        |     | Edge        |     | Edge
         |     | Router 1    |     | Router 2    |     | Router 3
         +-----+             +-----+             +-----+
            o         o       o   o  o      o        o o
        o o   o  o  o  o  o o   o  o  o  o  o   o  o  o  o
       o  o o  o o   o    o   o  o  o  o     o   o  o  o o
       o   o  o  o     o    o    o  o     o      o  o   o
         o   o o     o          o  o      o    o       o

                         Extended LoWPAN

There are three edge routers, with a bunch of nodes. Assume that IPv6
addresses of nodes are based on short addresses (aka: L2 address). 

When the nodes power up, each edge router must assign each one a short
address. If IPv6 addresses are to remain based on L2 addresses, each short
address across the entire lowpan must be different. 

Running proxy-ND along the backbone is primarily so that you end up with
unique short addresses. Using NA/NS is a very clean way of doing this, each
ER can check if the other ER's have assigned an address.

The other option is to have each router on a unique subnet, so that each
router knows it will not have a global address collision. However when nodes
move from router 1 to router 2, they will suddenly need to change IP
addresses. If people are using hardcoded IP addresses, this will break
connectivity.

Maintaining connectivity in the unique-subnet-per-ER case would require DNS
servers on the ER, which (1) would increase complexity of ER code, and (2)
bring up a whole bunch of other problems with name management. 

Sorry if I have misunderstood your e-mail or the point of 6lowpan-ND! This
is how I see it anyway...

  -Colin

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: November 17, 2009 11:14 PM
To: Carsten Bormann
Cc: Alexandru Petrescu; Colin O'Flynn; 'Pascal Thubert (pthubert)'; 'Ralph
Droms (rdroms)'; '6lowpan'
Subject: Re: [6lowpan] Thoughts on draft-ietf-6lowpan-nd-07

Sure, that's good.

Alex

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 18 Nov 2009 08:48:34 +0100

Hi Colin:

I'd say that the backbone must be dimensioned to the needs, like any
network.

For mission critical deployments, technologies like virtual switching
system (VSS) provide high availability and aggregated bandwidth to scale
to the needs.

And you'll find that TRILL provides immense scaling properties, and that
ND proxy make a lot of sense there. For all I know, edge routers can do
TRILL on the back end.
 
More below...

>or two computers, with users watching YouTube and studiously
downloading

We do not need such assumptions. We need a proper network design with 
The backbone technology dimensioned to the needs. 

Also, we want and need a node to be able to move transparently within
the LoWPAN.
In particular the node might change its neighbors and even its edge
router over time.

So as you remarked, all the addresses should be globally unique across
the domain 
defined by the subnet. 

Pascal

---

From: Zach Shelby <[email-masked]>
Date: Wed, 18 Nov 2009 10:19:43 +0200

Hi,

On Nov 16, 2009, at 21:30 , Ralph Droms wrote:

> OK, and I understand you're working on application scenarios.  I think you need a digest from the applications scenarios into a set of characteristics of the underlying L2 services that is explicitly written down somewhere.

We are not working with application scenarios as such, but you could say that we are working with link-layer scenarios. And I agree those could be documented better than just talking about mesh-under and route-over. 

> Can you reuse the scenario work from the roll WG?

It might not hurt to reference the work done there? We can definitely look at that and see what is related to our work there. I think most of us have related scenarios in mind for 6LoWPAN anyways.

> Is it commonly assumed in lowpans that there are both hosts and routers or is that architectural assumption specific to the 6lowpan/802.15.4 work?

This is a common assumption for low-power embedded devices, especially wireless ones. In order to keep a node as simple as possible, and to save battery power you would configure it as a host. This also allows for nodes that can not participate in the particular routing algorithm in use. In 6lowpan this becomes even more important as we are dealing with simple autonomous nodes which are often battery powered. There will surely be LoWPANs deployed with no routing at all - in which case we only have an ER and hosts. 

> Do you mean that the only address resolution is for a router to resolve the MAC address of a destination host?

You could say we don't actually do address resolution (as in a mechanism initiated when you don't know the link-layer address). Instead the node registration exchange between nodes and routers includes sufficient link-layer address information. Therefore nodes know the L2 addresses of their default routers, and routers know the L2 addresses of the nodes registered with them. 

> Is this relaying specific to ND-07; i.e., does ND-07 require a forwarding overlay?

This is specific to nd-07 and only when a router performs registration on behalf of a node. The nice thing about the document split, is that the base document would no longer have to deal with or talk about relaying.

>> It is probably more appropriate to give the inter-router message a different name (e.g., relayed NR, RNR), so the confusion between this relaying process and IP forwarding is reduced; this is the…

Exactly! The other nice thing is that the split allows us to treat mesh-under and route-over in a very similar way as we only have to deal with the host-router interface over one hop. We can also treat an ER and a Router equally in the base document. So it would go a long ways towards simplifying the terminology, architecture etc. in the base document. 

Zach

-- 
http://www.sensinode.com
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: Zach Shelby <[email-masked]>
Date: Wed, 18 Nov 2009 10:46:15 +0200

Ralph,

A couple more thing I wanted to touch on below.

> by IP-over-foo documents.

Correct, in the current document the only difference is that there are no LoWPAN Routers in mesh-under - only hosts and an ER. 

The nice thing about splitting the document, is that it makes explaining the architecture and dealing with mesh-under vs. route-over much easier as we are only discussing the host-router interface which we have over both kinds of link layers. It also allows us to deal with a router and an ER in basically the same way in a base document. 

There are good reasons for generalizing the characteristics of these link-layers, whether performing L2 mesh or not. This kind of L2 technology turns out to be very heterogeneous. There is no de-facto L2 mesh technique, and there are (too) many ways of setting up IEEE 802.15.4. We have also learned that 6LoWPAN is used over many other L2 technologies including Sub-GHz radios, Z-wave, PLC etc. What we have been doing is finding the common characteristics of these, and applying a host-router mechanism that always works. We should better document the assumptions made about the link for this mechanism to work, but I think this is the right approach. We need to allow stack developers to support 6LoWPAN over suitable link-layer setups.

> some architectural notions that can be shared from that spec?

I am currently working with autoconf people to share the addressing model, and we work very closely with roll already. The autoconf model should let us avoid having to define our own "route-over" at least, and to simplify terminology. 

The problem with IEEE 802.15.4 is that there are so many variations of it. I do think that the IP notion of host/router is similar to the IEEE 802.15.4 notion of RFD/FFD. But right, we could reference 802.15.4 as a good example link and explain how this works over a few different 802.15.4 configurations in the base document?

> first and then the new protocol can be built on that machinery.

OK, we can do that.

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Nov 2009 19:57:45 +0100

Colin O'Flynn a écrit :
> Since they are a MAY we could just not transmit any.

WEll - yes for NA, but MLD?  I guess ER will _have_ to transmit at least 
one MLD message for each lowpan node for which ER joins the 
solicited-node IP multicast address.

> There probably isn't

Well, link-layer multicast of Ethernet works good when it has good 
support in switches.  10000 computers on a LAN are supposedly separated 
by switches.(I didn't see a cable holding together 10000 computers).

Here you propose 10000computers proxied on a single interface of that 
LAN, i.e. no switch.

> NS is 24 bytes.
> Let's add some options to bring it up to 40 bytes. Add IPv6

I don't get it: do you say that roughly an ER is ok to send proxy NAs 
for 10000 lowpan nodes on a 10mbit Ethernet (just checking I understand 
you).

> or two computers, with users watching YouTube and studiously downloading

:-)

> collisions.

BEfore detecting collisions one would make sure the network doesn't 
helpp them happen.  E.g. have different subnets on different lowpan ERs 
and different prefixes on each lowpan.

> Take the following from

Have you thought IPv6 link-local addresses too?

I mean to have a lowpan subnet attached to ER1 different than the lowpan 
subnet of ER2, each with its own distinct link-local scope.

> address across the entire lowpan must be different. 

Could the IPv6 address be based on the long version of the L2 address?

If not - then you really risk collisions, regardless of them being 
detected by proxying ERs or by the lowpan nodes themselves.

What are you going to do when a collision is detected?  Generate another 
short address?  Or generate another IP address?

(you==somebody, in general)

> ER can check if the other ER's have assigned an address.

I think it is to end up with unique IP addresses, not short addresses 
(which are L2).

What happens when such a duplicate is found - who sees it and who takes 
what action?

> The other option is to have each router on a unique subnet,

I believe it makes sense to have each lowpan attached to eah ER 
constitute a distinct subnet.

> so that each

Hmmm... connectivity.  Some applications do restart after connectivity 
is lost and the IP address was changed.

> bring up a whole bunch of other problems with name management.

But I agree yes, DNS in the system should be considered.  Where is the 
DNS server in 6LoWPAN?

> is how I see it anyway...

Sorry, it's fine, for me it's just that I don't see the need for 
proxy-ND on ER.

Thank you for the Atmel explanation.

Alex

---

From: "Colin O'Flynn" <[email-masked]>
Date: Wed, 18 Nov 2009 19:26:32 -0000

Hi Alex,

Ah, the fun of Lowpan-ND discussion :)

> solicited-node IP multicast address.

Yes, very true! As well since DAD is done across the backbone, I'm not
trying to claim there would be no traffic from each node. Each node will
generate a few NS at least...

> Here you propose 10000computers proxied on a single interface of that 

I am assuming each ER is somewhat dumb, and of limited range. At 2.4 GHz you
are talking a few hunded metres, at 900 MHz maybe a km or so. So each ER
would only have maybe a hundred nodes. Between ER we are connected by
switches etc. 

> for 10000 lowpan nodes on a 10mbit Ethernet (just checking I understand 

No, and that would never happen. The limit on each ER is going to be the
802.15.4 side, both number of nodes joining (see previous), and speed which
nodes join. Further if proxy-ND is going on in the router, it will have
timers going to keep track of each DAD process. Realistically routers are
only going to run so many DAD processes concurrently.

So the quick 'how many NS can we do' was just to prove that everything else
limits our speed, not ethernet's speed. Also as you can guess I'm not a
networking guy per-say, so if that calculation was way off-base let me know
;-)  

> short address?  Or generate another IP address?

Ideally generate a new short address. So a router does the DAD to check if
anyone owns the address, if so it gives it to the end node. Otherwise the ER
assigns a new address.

Which of course brings up an issue: if the first ER has a hundred nodes
attached, it will use addresses ::1 - ::100. The second ER will then do DAD
on addresses ::1 to ::100 until it find a free address! 

> I think it is to end up with unique IP addresses, not short addresses 

6lowpan-HC assumes that for best compression IP addresses are based on the
L2 address you are using. So if you are using 64-bit addresses, the address
is based on that. But if you are using 16-bit addresses, the IPv6 address is
based on that + the PANID.

For efficiency reasons you want to use 16-bit addresses, as you go from 16
total bytes to 4 total bytes (dest + src). 

It is up to the PAN coordinator (aka: edge router) to assign short addresses
as it sees fit, they are not preset like long ones. To keep everything
efficient we want (need) IPv6 addresses based on 802.15.4 short addresses.
Hence the ER should assign an end node a short address with the intention
that short address results in a unique IPv6 address. 

> But I agree yes, DNS in the system should be considered.  Where is the 

Has it come up before? Not sure myself!

Regards,

  -Colin

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: November 18, 2009 6:58 PM
To: Colin O'Flynn
Cc: 'Alexandru Petrescu'; 'Carsten Bormann'; 'Pascal Thubert (pthubert)';
'Ralph Droms (rdroms)'; '6lowpan'
Subject: Re: [6lowpan] Thoughts on draft-ietf-6lowpan-nd-07

:-)

Alex