[Roll] Document Action: 'Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks' to Experimental RFC (draft-ietf-roll-p2p-rpl-17.txt)

[The IESG <[e-mail]>]

The IESG has approved the following document:
- 'Reactive Discovery of Point-to-Point Routes in Low Power and Lossy
   Networks'
  (draft-ietf-roll-p2p-rpl-17.txt) as Experimental RFC

This document is the product of the Routing Over Low power and Lossy
networks Working Group.

The IESG contact persons are Adrian Farrel and Stewart Bryant.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-roll-p2p-rpl/




Technical Summary

  Targeting Low power and Lossy Networks (LLNs), the RPL routing 
  protocol [RFC6550] provides paths along a Directed Acyclic Graph 
  (DAG) rooted at a single router in the network.  Establishment and 
  maintenance of a DAG is performed by routers in the LLN using DODAG 
  Information Object (DIO) messages.  When two arbitrary routers 
  (neither of which is the DAG's root) need to communicate, the data 
  packets are restricted to travel only along the links in the DAG. 
  Such point-to-point (P2P) routing functionality may not be sufficient 
  for several Home and Building Automation applications [RFC5826] 
  [RFC5867] due to the following reasons: 

  o  The need to pre-establish routes: each potential destination in 
      the network must declare itself as such ahead of the time a source 
      needs to reach it. 

  o  The need to route only along the links in the DAG: A DAG is built 
      to optimize the routing cost to reach the root.  Restricting P2P 
      routes to use only the in-DAG links may result in significantly 
      suboptimal routes and severe traffic congestion near the DAG root. 

  This document describes an extension to core RPL that enables an IPv6 
  router in the LLN to discover routes to one or more IPv6 routers in 
  the LLN "on demand", such that the discovered routes meet the 
  specified metrics constraints, without necessarily going along the 
  links in an existing DAG.  This reactive P2P route discovery 
  mechanism is henceforth referred to as P2P-RPL.  P2P-RPL does not 
  guarantee discovery of a route.  Also, the discovered routes may not 
  be optimal.  However, any discovered routes are guaranteed to satisfy 
  the desired constraints in terms of the routing metrics and are thus 
  considered "good enough" from the application's perspective. 

  A mechanism to measure the end-to-end cost of an existing route is 
  specified in [I-D.ietf-roll-p2p-measurement].  As discussed in 
  Section 4, measuring the end-to-end cost of an existing route may 
  help decide whether to initiate the discovery of a better route using 
  P2P-RPL and the metric constraints to be used for this purpose. 

Working Group Summary: 

  No discontent. Once again, few comments, request for clarifications
  that have all been addressed in this revision. 

Document Quality: 

  Yes there are several known implementations of these specification,
  with interop testing. 

  An interoperability event was carried out Oct 2012 with INRIA's
  implementation against Sigma Design's implementation. The 
  report can be found: 
     http://hal.inria.fr/docs/00/66/16/29/PDF/RR-7864.pdf 

  Experiments with P2P-RPL have also taken place on the Senslab
  testbed gathering boards based on MSP430 and 802.15.4 at
  2.4GHz: 
    http://hal.archives-ouvertes.fr/docs/00/65/16/03/PDF/SOFTCOM-2011.pdf 

Personnel: 

  The Document Shepherd is JP Vasseur ([e-mail])
  The responsible AD is Adrian Farrel ([e-mail]) 

RFC Editor Note

  The reference to RFC 5226 may be removed.

---

Section 6.1 New bullet on page 13.
In the list of bullets under
   The DODAG Configuration Option, inside a P2P mode DIO MUST be set in
   the following manner:
Add a new penultimate bullet as follows:

o  As discussed in Section 14, P2P-RPL does not distinguish between
      the "preinstalled" and "authenticated" security modes described in
      [RFC6550].  Consequently, the Origin MUST set the Authentication
      Enabled (A) flag to zero.  A received P2P mode DIO MUST be
      discarded if the A flag inside the DODAG Configuration Option is
      not zero.

---

Section 6.1 New bullet on page 14
In the list of bullets under
   A P2P mode DIO:
Add a new bullet to the end of the list as follows:

o  MAY carry one DODAG Configuration Option.  If a P2P mode DIO does
      not carry an explicit DODAG Configuration Option, the default
      DODAG Configuration Option defined in this section is considered
      to be in effect.