[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

ROLL                                                     P. Thubert, Ed.
Internet-Draft                                             Cisco Systems
Intended status: Standards Track                       November 16, 2011
Expires: May 19, 2012

                 RPL adaptation for asymmetrical links


   The Routing Protocol for Low Power and Lossy Networks defines a
   generic Distance Vector protocol for Low Power and Lossy Networks,
   many of which exhibit strongly asymmetrical characteristics.  This
   draft proposes an extension for that optimizes RPL operations whereby
   upwards and downwards direction-optimized RPL instances are

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 19, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents

Thubert                   Expires May 19, 2012                  [Page 1]

Internet-Draft         draft-thubert-roll-asymlink         November 2011

   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  The asymmetrical link problem . . . . . . . . . . . . . . . . . 4
   4.  Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Modified DODAG Information Object (DIO) . . . . . . . . . . . . 5
   6.  Operations  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Backward compatibility  . . . . . . . . . . . . . . . . . . . . 7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   9.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     11.1.  Normative References . . . . . . . . . . . . . . . . . . . 8
     11.2.  Informative References . . . . . . . . . . . . . . . . . . 9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 9

Thubert                   Expires May 19, 2012                  [Page 2]

Internet-Draft         draft-thubert-roll-asymlink         November 2011

1.  Introduction

   The IETF ROLL Working Group has defined application-specific routing
   requirements for a Low Power and Lossy Network (LLN) routing
   protocol, specified in [RFC5548], [RFC5673], [RFC5826], and
   [RFC5867], many of which explicitly or implicitly refer to links with
   asymmetrical properties.

   Upon those requirements, the Routing Protocol for Low Power and Lossy
   Network [I-D.ietf-roll-rpl] was designed as a platform that can be
   extended by further specifications or guidances, by adding new
   metrics, Objective Functions, or additional options.

   RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs)
   within instances of the protocol.  Each instance is associated with
   an Objective Function that is designed to solve the problem that is
   addressed by that instance.

   In one hand, RPL requires bi-directional links for the control, but
   on the other, there is no requirement that the properties of a link
   are the same in both directions.  In fact, a perfect symmetry is
   rarely present in Low Power and Lossy Networks (LLNs), whether links
   are based on radios or power-line.

   Some initial implementations require that the quality of both
   directions of a link is evaluated as very good so that the link can
   be used for control and data in both directions.  This eliminates
   asymmetrical links that are very good in one direction, but only good
   enough for scarce activity in the other direction.

   In practice, a DAG that is built to optimize upwards traffic is
   generally not congruent with a DAG that is built to optimize
   downwards traffic.  This is why this specification is designed to
   enable asymmetrical routing DAGs that are bound together to get the
   maximum benefits of all types of bi-directional links.

2.  Terminology

   The terminology used in this document is consistent with and
   incorporates that described in `Terminology in Low power And Lossy
   Networks' [I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl].

   The term upwards qualifies a link, a DODAG or an instance that is
   optimal for sending traffic in the general direction of the root,
   though may be usable but suboptimal for traffic coming form the
   direction of the root.  The term downwards qualifies the same words
   for the opposite direction.

Thubert                   Expires May 19, 2012                  [Page 3]

Internet-Draft         draft-thubert-roll-asymlink         November 2011

   The term parenting applied to instances refers to the directional
   association of two instances.  The meta graph formed by parented
   instances must be a DAG.  Traffic may be transferred from an instance
   onto a parent instance under specified circumstances.

   The draft also uses the following terminology:

   bi-directional:  A link is bi-directional when traffic confirmed
      possible in both direction, in a fashion that is sufficient to
      operate RPL control.

   asymmetric:  A link is assymetric if it is bi-directional, but
      exhibits important differences in link characteristics for both

3.  The asymmetrical link problem

4.  Solution Overview

   With the core RPL specification, [I-D.ietf-roll-rpl] each instance is
   a separate routing topology, and packets must be forwarded within the
   same topology / same instance.  One direct consequence of that design
   choice is that a topology must be very good for both upwards and
   downwards traffic; otherwise, traffic between two nodes in the
   instance may suffer.

   RPL is designed to operate on bi-directional links.  When the link
   properties do not widely differ between the upwards and the downwards
   directions, a single DAG is adequate as the routing topology for both
   upwards and downwards traffic.  In that case, an asymmetrical link,
   that can only be used for traffic in one direction, can not
   participate to the routing topology.  This results in an unoptimized
   use of bandwidth and/or a reduction of the possible path diversity.

   This issue can be addressed with [I-D.ietf-roll-rpl], by constructing
   two DAGs, one that is used for upwards traffic and one that is used
   for downwards traffic.  This solves the issue for all traffic that
   transits through the root of the DODAG, whether it is originated in
   the DODAG going out or is injected into the DODAG from the outside,
   since in both cases a packet will mostly use the asymmetric links in
   the appropriate direction.

   OTOH, with RPL as it is specified, a packet follows the topology that
   is generated for its instance all the way through a DAG, and
   transferring a packet from an instance to another is not permitted.
   As a result, the 2 DAGs solution would penalize Peer to peer traffic

Thubert                   Expires May 19, 2012                  [Page 4]

Internet-Draft         draft-thubert-roll-asymlink         November 2011

   that would have to go through the root in order to leave the upward
   instance and then reenter at the root in order to join the downwards
   instance.  This is not an issue in non-storing mode since the packet
   has to go through the root to load the routing header downwards
   anyway, but going through the root stretches the path in storing

   In order to benefit from both instances and yet avoid extra stretch
   through the root in storing mode, it is required to extend RPL rules
   so as to allow traffic to be transferred from one instance to the
   next before reaching the root on the way up.  This document specifies
   conditions under which 2 instances can be bound together so that a
   node may transfer traffic from an instance onto another.

   It can be noted at this point that with [I-D.ietf-roll-rpl], traffic
   that goes down does not generally go back up again, whereas P2P
   traffic within a DODAG might go up to a common parent and then down
   to the destination.  In terms of instance relationship, this means
   that when an upwards and a downwards instances are bound together,
   traffic from the former may be transferred to the latter, but not the
   other way around.  In other words, there is an order, a parent-child
   relationship, between the two instances.

   Additionally, if there is no next-hop for a packet going down within
   the instance, then with [I-D.ietf-roll-rpl] the packet will be
   dropped or sent back with an error along the wrong direction of an
   asymmetric link.  In order to avoid those unwanted behaviors, it is
   tempting though inefficient to lower the constraints that are applied
   to build the topology.  It can be more efficient to actually keep the
   constraints as they should be, but, instead, enable a less
   constrained, more spanning, fall-back topology into which traffic can
   be transferred.

   For that reason, this solution allows for more complex instance
   relationships than plain child-parent associations.  In order to
   avoids loops which could be created when transferring packets from
   one instance to the next, this solution requires that the instances
   be themselves organized as a Directed Acyclic Graph, and enforce that
   inter-DAG transfers occur only within that meta DAG.

5.  Modified DODAG Information Object (DIO)

   The DODAG Information Object [I-D.ietf-roll-rpl] carries information
   that allows a node to discover a RPL Instance, learn its
   configuration parameters, select a DODAG parent set, and maintain the
   DODAG.  This specification defines a new flag bit to indicate that
   the DAG is directional.

Thubert                   Expires May 19, 2012                  [Page 5]

Internet-Draft         draft-thubert-roll-asymlink         November 2011

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       | RPLInstanceID |Version Number |             Rank              |
       |G|D| MOP | Prf |     DTSN      |     Flags     |   Reserved    |
       |                                                               |
       +                                                               +
       |                                                               |
       +                            DODAGID                            +
       |                                                               |
       +                                                               +
       |                                                               |
       |   Option(s)...

                       Figure 1: The DIO Base Object

   Directional (D):  The Directional (D) flag is set to indicate that
         the instance is intended for directional operation, and reset
         otherwise.  When it is set, a MOP of 0 indicates the upwards
         direction whereas any other value specified in
         [I-D.ietf-roll-rpl] indicates downwards.  All other values of
         MOP will be considered downwards unless explicitly specified

6.  Operations

   This specification allows an organization of Instances as follows:

      Instances MUST be organized as a Directed Acyclic Graph.  This
      information MUST be commissioned into the devices so they know
      both which instances they should participate in, and which
      direction of transfer is allowed between instances.

      A spanning instance using OF0 [I-D.ietf-roll-of0] MAY be used as
      root in that instance DAG.

   This specification defines a new bit in the RPL [I-D.ietf-roll-rpl]
   DODAG Information Object (DIO) with the Directional (D) flag that
   indicates a directional operation for a given instance.  An
   implementation that does not support that new bit will not be able to
   propagate it.

   In case of a directional operation,

Thubert                   Expires May 19, 2012                  [Page 6]

Internet-Draft         draft-thubert-roll-asymlink         November 2011

      The direction is indicated by the MOP field, a MOP of 0 means
      upwards and otherwise is downwards.

      Links are still REQUIRED to allow bidirectional operations

      Only the metrics that correspond to the DAG direction are used for
      the parent selection.

      An upward instance SHOULD install routes that lead to the root and
      beyond - typically the default route.

      A downwards instance MAY ONLY install more specific routes that
      are injected by nodes in the DODAG through the DAO process.

      P2P operations are achieved by associating a child upwards
      instance with a parent downwards instance.

      A packet MUST NOT be transferred from a parent instance to a child

      A packet MAY be transferred from a child instance to its parent
      instance if and only if the child instance does not provide a
      route to the destination, or the parent instance provides a more
      specific route (longer match) to the destination.

      Transferring from an upwards instance to a downwards instance if
      generally desirable.  Other forms of transfers are generally not
      desirable.  Policies MAY be put in place to ovreride that general

7.  Backward compatibility

   An OF is generally designed to compute a Rank of a directional link
   in a fashion that is diffent from a bidirectional link, and in
   particular will not use the same metrics and thusobtain different
   ranks for a same situation.  For that reason, it is important that
   the OF is aware that an instance is supposed to define a directional
   DODAG, and it is RECOMMENDED that only devices that support
   directional DODAGs are allowed in a directional instance.

   It might happen that for some purposes like higher availability, an
   implementation that does not support directional links is
   administratively allowed to join a directional DODAG.  In that case,
   the extension of the DODAG that starts at that device will not be
   directional, but the instance will still be functional.

   In that case, it might also happen that a device that supports

Thubert                   Expires May 19, 2012                  [Page 7]

Internet-Draft         draft-thubert-roll-asymlink         November 2011

   directional DODAGs per this specification sees candidate neighbors
   that expose the Directional flag and some others that do not.  An OF
   that supports directional links SHOULD favor directional links over
   non directional links, in a fashion that is to be specified with the
   OF.  In the case of OF0 [I-D.ietf-roll-of0], the 'D' flag should be
   accounted for before the computation of item 8 in the "Selection Of
   The Preferred Parent" section 4.2.1., that is before Ranks and be
   calculated and compared.

8.  IANA Considerations

   This specification requires that a bit in DIO be assigned to indicate
   directional link operations as specified in section

9.  Security Considerations

   Security Considerations for this proposal are to be developed in
   accordance with recommendations laid out in, for example,

10.  Acknowledgements

   The author wishes to recognize Richard Kelsey, JP Vasseur, Tom
   Phinney, Robert Assimiti, Don Sturek, Thomas Clausen and Yoav Ben-
   Yehezkel for their various contributions.

11.  References

11.1.  Normative References

              Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
              Vasseur, "RPL: IPv6 Routing Protocol for Low power and
              Lossy Networks", draft-ietf-roll-rpl-19 (work in
              progress), March 2011.

              Vasseur, J., "Terminology in Low power And Lossy
              Networks", draft-ietf-roll-terminology-06 (work in
              progress), September 2011.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Thubert                   Expires May 19, 2012                  [Page 8]

Internet-Draft         draft-thubert-roll-asymlink         November 2011

11.2.  Informative References

              Thubert, P., "RPL Objective Function Zero",
              draft-ietf-roll-of0-20 (work in progress), September 2011.

              Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A
              Security Framework for Routing over Low Power and Lossy
              Networks", draft-tsao-roll-security-framework-02 (work in
              progress), March 2010.

   [RFC5548]  Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
              "Routing Requirements for Urban Low-Power and Lossy
              Networks", RFC 5548, May 2009.

   [RFC5673]  Pister, K., Thubert, P., Dwars, S., and T. Phinney,
              "Industrial Routing Requirements in Low-Power and Lossy
              Networks", RFC 5673, October 2009.

   [RFC5826]  Brandt, A., Buron, J., and G. Porcu, "Home Automation
              Routing Requirements in Low-Power and Lossy Networks",
              RFC 5826, April 2010.

   [RFC5867]  Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
              "Building Automation Routing Requirements in Low-Power and
              Lossy Networks", RFC 5867, June 2010.

Author's Address

   Pascal Thubert (editor)
   Cisco Systems
   Village d'Entreprises Green Side
   400, Avenue de Roumanille
   Batiment T3
   Biot - Sophia Antipolis  06410

   Phone: +33 497 23 26 34
   Email: pthubert@cisco.com

Thubert                   Expires May 19, 2012                  [Page 9]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/