Subject: [6lowpan] proposed changes for ND

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 22 May 2010 16:09:20 +0200

Hi Zach:

Please find hereafter some proposed editorial changes to the ND spec to cover the issues I reported so far:

1)      Naming the registry. The ND spec has a registry in every router that is called ND cache in 08, and then one master in the 6LBR, called DAD table.

The former naming might be confusing if the registry cohabits with a ND cache that obeys RFC4861. Also, the close relation of the 2 tables is not obvious per their names

ð  I suggest we call the registry a registry. In all 6LR routers, that would be the Neighbors Registry and the aggregation in the 6LBR, that would be the Master Neighbor Registry.

My text below will assume that naming

2)      ARO sequence counter

The sequence counter is useful to correlate a request with a response, in particular between the 6LR and the 6LBR, which can take some time and retries may cross. 

We als know from earlier work that the seq nb will play a role to handle mobility over the backbone. My suggestion is to place it back in the spec.

3)      Relation between the Neighbors Registry and other tables in the router

ð  The NR can be injected in the RIB(s) to be redistributed in routing protocols. (inject)

ð  When an entry is created in the NR, it can be gleaned in the Neighbor Cache. (glean)

ð  When an entry is NUDed, it can be cleaned from the Neighbors Registry. (clean)

New section (3.3?)

Interaction between the Neighbor cache and other Tables

   A typical IPv6 router handles one or more Routing Tables 

  (aka Routing Information Bases) and one Neighbor Cache per 

interface. At a strict minimum, a 6LR might have default 

route via the 6LBR, and no Neighbor Cache, if it relies only 

on the ARO process described in this spec to discover its

neighboring host. More complex situations may arise where 

the ND cache and or the RIBs play their full role. This section

explores the relationship between the NR and those tables.

Master Neighbor Registry

  -------------------------

   In a subnet with more than one router, it is expected that one

   Router is an 6LBR whereas all the other routers are 6LRs. All

   the routers are expected to maintain a Neighbor Registry. All 

   the entries in the Neighbor Registry MUST be injected into the 

   Master Neighbor Registry as specified in section 8, whether they

   are subject to DAD or not. This enables the 6LBR to protect those

   addresses and to expose them to the outside, for example over 

   a backhaul or a backbone, in a manner that is outside the scope

   of this document.

  +-------------+                  +-------------+              

  |             |        Inject    |             |               

  |             |--+               |             |               

  |             |  |      ===>     |             |               

  |             |  |--+            |             |               

  |             |  |  |            |             |               

  |             |  |  |            |             |               

  +-------------+  |  |            +-------------+               

     |             |  |

     +-------------+  |

        |             |

       +-------------+

  Neighbor Registry in              Master Neighbor Registry

  6LR and 6LBR                      in 6LBR

  When an entry has to be removed from the Neighbor Registry, the entry

   must first be removed from the Master Neighbor Registry. This is

   confirmed by an ARO message with a successful status and a null lifetime

   on a sequence that matches the request. < note to add the sequence nb in ARO > 

RIBs

  -----

Being a router, the 6LR/6LBR maintain one or more RIBs. In route-over,

the RIB is used to route inside the subnet as well as outside. 

With RPL <draft-roll…> it is possible that the router maintains multiple

RIBs (or VRFs) in order to support more than one instance.

Because of the way the Neighbor Registry is maintained proactively,

it is possible to inject the information in the Neighbor Registry

as host routes in the RIB(s). The host routes are installed as connected

routes. When the Neighbor Registry entry is removed, the route in the RIB

must be removed as well.

  +-------------+                  +-------------+              

  |             |        Inject    |             |               

  |             |--+               |             |               

  |             |  |      <===     |             |               

  |             |  |--+            |             |               

  |             |  |  |            |             |               

  |             |  |  |            |             |               

  +-------------+  |  |            +-------------+               

     |             |  |

     +-------------+  |

        |             |

        +-------------+

  RIBs in a                          Neighbor Registry

  6LR or 6LBR                        same router

The 6LBR may aggregate the host routes as one connected route to the 

whole prefix on its 6LoWPAN interface that serves the subnet.

Routing protocols such as RPL may then redistribute the connected route

from the RIB(s) that they serve an thus inject the host or prefix routes

in their own routing fabric.

ND cache

--------

A 6LR/6LBR may support this specification and Neighbor Discovery as specified

in RFC 4861 on a same interface. In that case, ND cache entries can be gleaned

from the registration process, and entries that are subject to NUD might be 

cleaned from the Neighbor Registry.

  +-------------+                  +-------------+              

  |             |                  |             |               

  |             |--+     Glean     |             |               

  |             |  |      <===     |             |               

  |             |  |--+            |             |               

  |             |  |  |  Clean                  |               

  |             |  |  |   ===>     |             |               

  +-------------+  |  |            +-------------+               

     |             |  |

     +-------------+  |

        |             |

        +-------------+

  Neighbor Cache pre

  Interface in a                      Neighbor Registry

  6LR and 6LBR                        same router

In a network where node might be sleeping for a long time, NUD might wrongly

determine that a node is unreachable so it  must be possible to turn off

   the cleaning operation. In most cases, though, it is expected that sleeping nodes

   end up receiving their traffic, and should stay awake long enough to answer the

   polling. 

 

 

4)      Topology supported 

The doc could be more clear about what’s in what’s out. In particular, it appears to me that we better say that we support only one LBR and that the support to scale to more than one LBR, for instance using a backbone, is out of scope. We can also say that the LBR knows all the addresses in the subnet that it covers, and that it can either represent them over a backhaul or a backbone, or aggregate them.

“

   In a mesh-under configuration a 6LBR is acting as the IPv6 router

   where all the hosts in the LoWPAN are on the same link, thus they are

   only one IP hop away.  No 6LoWPAN Routers exist in this topology as

   forwarding is handled by a link-layer mesh routing protocol.

“

=>

“

   Mesh-under configurations vary a lot, do not guarantee any to any 

   direct connectivity, and may grow very large. It is expected that 

   a host is one mesh under hop away from at least one 6LR, and that

   all the 6LRs have a mesh under connection to the 6LBRs. Configurations

   with more than one 6LBR are not supported by this specification.

“

“

   o  A new optional mechanism to perform Duplicate Address Detection
      across a route-over 6LoWPAN reusing the above Address Registration
      option.

“

=>

“

   o  A new optional mechanism to perform Duplicate Address Detection
      across a large 6LoWPAN with multiple 6LRs reusing the above Address 
      Registration option.

“

“

   Optionally the Router Advertisement messages can be used to
   disseminate prefixes to all the 6LRs in a route-over topology.  This
   is optional because there are likely to be other mechanisms for such
   information distribution.

“

=>

“

   Optionally the Router Advertisement messages can be used to
   disseminate prefixes to all the 6LRs. This
   is optional because there are likely to be other mechanisms for such
   information distribution.

“

“

   When a 6LR that implements the optional multihop DAD receives an NS
   from a host (the ARO has Length = 2) and the 6LR does not already
   have a Neighbor Cache entry for the host's IPv6 address, then the 6LR
   forms and sends an NS to at least one 6LBR. 

“

=>

“

   When a 6LR that implements the optional multihop DAD receives an NS
   from a host (the ARO has Length = 2) and the 6LR does not already
   have a Neighbor Cache entry for the host's IPv6 address, then the 6LR
   forms and sends an NS to the 6LBR. A configuration with multiple 6LBRs
   is not supported by this specification. It is expected that the 6LBRs 
   would synchronize proactively or reactively their Master Neighbor 
   registries between themselves with not additional action by the 6LR.

“

5)      merging the dissemination process with the registration process may slow down the adoption of the latter. 

Also, some configurations using an alternate dissemination process might not require that feature from ND. 

So I’d suggest we make it a separate spec and we focus deeply on the registration for the time being.

Cheers,

Pascal Thubert
Engineer.software Engineering
Product Development
[email-masked] <mailto:[email-masked]> 
Phone: +33 4 9723 2634
Mobile: +33 6 1998 2985

Cisco Systems France
Village d'Entreprises Green Side
400 Avenue de Roumanille 
Batiment T 3 
06410 
BIOT - SOPHIA ANTIPOLIS
France
Cisco.com <http://www.cisco.com/global/FR/> 

 Think before you print.

Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone, For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html <http://www.cisco.com/web/about/doing_business/legal/cri/index.html>