RPL adaptation for asymmetrical links
draft-thubert-roll-asymlink-00

Abstract

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 associated.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 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 April 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 (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
• 2. Terminology
• 3. The asymmetrical link problem
• 4. Solution Overview
• 5. Modified DODAG Information Object (DIO)
• 6. Operations
• 7. Backward compatibility
• 8. IANA Considerations
• 9. Security Considerations
• 10. Acknowledgements
• 11. References
• 11.1. Normative References
• 11.2. Informative References
• Author's Address

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 bidirectional 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, such a symmetry is rarely present in 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 bidirectional 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.

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

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.

A simple approach to address bidirectional but asymmetrical links with RPL is to construct two DAGs, one for upwards traffic and one for downwards traffic, each DAG a separate instance, and then bind the two together. In order to benefit from both instances for a same packet, this solution extends RPL to allow traffic to be transferred from one instance to the next.

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 instance 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 must be dropped. In order to limit that risk, 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 superior Directed Acyclic Graph, and enforce that inter-DAG transfers occur only within that superior super-DAG of DAG instances.

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.

     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)...
    +-+-+-+-+-+-+-+-+

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 otherwise.

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,

• 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 instance.
• 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 guidance.

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 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, [I-D.tsao-roll-security-framework].

10. Acknowledgements

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

11. References

11.1. Normative References

11.2. Informative References

Author's Address