If you're routing, why do you need proxy ND?

["Pascal Thubert (pthubert)" <[e-mail]>]

Hi Lorenzo:

Some context here. The topic of this thread is *not* the registration mechanism in WiND. The topic is the proposed structure of the multilink subnet that 6TiSCH needs to scale an IPv6 subnet to tens of thousands, and specifically the topic is the operation over the backbone. That operation is discussed page 6 of http://tools.ietf.org/html/draft-ietf-6tisch-architecture  and way we figure it will work is refined in http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router. I plan to propose the draft to 6MAN so we share a common strategy for the whole story.

[cid:image002.png@01CEEB87.4AFE5FA0]

The 6TiSCH architecture proposes a mix of L2 routing in the backbone (Ethernet) and L3 routing (RPL) in the attached fringe LLNs. And the question is why should we use routing in the attached links and bridging in the backbone? I presented that same case at the IEEE plenary in Dallas the week after Vancouver. From my slides:

Case for Layer-2 Backbone

*        L2 Routing optimizes any-to-any (all set)
-       Integration of existing IPv4 and IPv6 hosts
-       IPv6 ND and ARP over limited size broadcast domains
*        TBD: Avoid leaking LLN MAC addresses
-       IPv6 proxy ND operation for attached LLNs
-       IPv6 aggregation and routing at the Backbone Router
*        Possible work items:
-       Highly scalable multicast routing to support discovery
-       MTU harmonization and Time synchronization

Case for L3 Attached LLNs
*        L3 Abstracts Complex LLNs
-       Multiple PHYs, very different properties
-       End-to-end path optimization vs. Sequence of L2 paths.
-       Cost and latency of the backbone usually negligible
*        RPL (RFC 6550) designed for Fringe Networking
-       Optimized for traffic to/from the backbone.
-       Objective Functions to adapt to any MAC/PHY
*        Low Power Lossy Networks fringe
-       Incompatible with flooding - no broadcast (sleeping node + energy constraints)
-       Multicast routing done in RPL (using unicast replications)
-       Controlled dissemination done in MPL (gossiping technique based on trickle)
*        Possible work items:
-       Wireless ND to proxy IPv6 ND for LLN attached devices
-       802.15.4 Objective Function defined at IEEE


It boils down to the fact that the effort that it would take to design a routing protocol that would fit the needs on the backbone - a highly scalable MANET - is not cost effective.
The Ethernet is a well-known problem and well-addressed at IEEE with IS-IS. Rather, we should focus on limiting the impacts of wireless / mobility on that established technology.
In the case of 6TiSCH, the idea is to proxy ND operations, redistribute RPL DAO as NA(O) is you like. In that case the mobility is entirely an L3 problem since the backbone routers proxy with their own MAC address so there is no MAC address movement and the MAC address of the LLN devices do not leak in the backbone so there is no scalability issue at layer 2.

Let's talk about this in London. I can resubmit the backbone router draft by then with the focus on that operation.

Cheers,

Pascal

From: Lorenzo Colitti [mailto:[e-mail]]
Sent: jeudi 21 novembre 2013 09:10
To: Pascal Thubert (pthubert)
Cc: Erik Kline; Ole Troan; 6man Chairs; 6man WG
Subject: Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04

On Thu, Nov 21, 2013 at 3:40 AM, Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>> wrote:
So clearly, as we build a multilink subnet with 802.15.4 at the edge, we must place a router - called backbone router in ISA100.11a - between the .1 and the .15.4 links. You will note that even in that case, we need the registration mechanism to perform DAD - RFC 6775 was initially designed in that context -, and that proxy ND can be used at the backbone router, as discussed in the original ML subnet draft by Dave and Christian.

If you're routing, why do you need proxy ND? Just give the 802.15.4 network a separate /64 and run 6LoWPAN ND inside it.

I think that's when Erik says "merging two link types is not the solution", that's what he means. I think he's just suggesting that you use existing standard ND in the high-powered network and existing 6LowPAN ND in the low-power network, and just route between them. That way you don't have to define a new ND protocol.

Now, WiFi does not qualify as 'a different link type' that would require routing to Ethernet; on a same AP, some clients may be low power

Well, but isn't wifi fundamentally unsuited for low-power networks anyway? It's got beacons going all the time, it has multicast, etc.

We do not want to renumber each time a device re-associates to the next AP, so we care for a rather large subnet. And there, it is not just a problem of implementing multicast at layer 2 in a fashion  that serves solicited node mcast addresses, placing the burden on another layer that, as it goes, does not have the adapted support in place...

You don't have to change ND to do that. All you need to do is either use solicited-multicast node addresses over the multicast channel or, if the subnet is SO large that ND requests are overwhelming (but that seems like a LOT of ND traffic - how many clients do you need before this starts happening?), use MLDv2 snooping and send the NS packets L2 unicast to their destination.

There is also the need for much faster DAD (not based on timing out)

What's the use case for faster DAD if you have optimistic DAD?