Internet DRAFT - draft-thubert-roll-asymlink
draft-thubert-roll-asymlink
ROLL P. Thubert, Ed.
Internet-Draft Cisco Systems
Intended status: Standards Track December 9, 2011
Expires: June 11, 2012
RPL adaptation for asymmetrical links
draft-thubert-roll-asymlink-02
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 June 11, 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 June 11, 2012 [Page 1]
Internet-Draft draft-thubert-roll-asymlink December 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. Backwards 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 June 11, 2012 [Page 2]
Internet-Draft draft-thubert-roll-asymlink December 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 specification or guidance, 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.
On one hand, RPL requires bi-directional links for the control, but
on the other hand, 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) such as
wireless radio or power-line links.
Some initial implementations require that the quality of both
directions of a link is evaluated as operational at an acceptable
level so that the link can be used for control and data in both
directions. This eliminates asymmetrical links that are not
operational at an acceptable level in one 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 a RPL instance that is
optimal for sending traffic towards the root, though may be usable
but suboptimal for traffic coming from the direction of the root.
The term downwards qualifies the same wording, only for opposite
directions.
Thubert Expires June 11, 2012 [Page 3]
Internet-Draft draft-thubert-roll-asymlink December 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 is confirmed
possible in both directions, in a fashion that is sufficient to
operate RPL control.
asymmetric: A link is asymmetric if it is bi-directional, yet
exhibits major differences in link characteristics for both
directions.
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 operational at an acceptable level
for both upwards and downwards traffic; otherwise, traffic between
two nodes in the RPL 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, cannot
participate to the routing topology. This results in an sub-optimal
bandwidth utilization 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.
On the other hand, 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
Thubert Expires June 11, 2012 [Page 4]
Internet-Draft draft-thubert-roll-asymlink December 2011
permitted. As a result, the 2 DAGs solution would penalize Peer to
peer traffic 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 mode.
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 a RPL instance onto another, e.g. from
an upwards RPL instance onto the downwards RPL instance.
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, fallback 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
Thubert Expires June 11, 2012 [Page 5]
Internet-Draft draft-thubert-roll-asymlink December 2011
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)...
+-+-+-+-+-+-+-+-+
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 is
reset otherwise. When the Directional (D) flag is set a value
of 0 for the MOP field indicates upwards whereas any other
value specified in [I-D.ietf-roll-rpl] indicates downwards.
All other values of MOP shall 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
Thubert Expires June 11, 2012 [Page 6]
Internet-Draft draft-thubert-roll-asymlink December 2011
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 set to a value
0 means upwards and any other setting indicates 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 is
desirable for Point to Point communication within a RPL domain.
Other forms of transfer do not denote a classical operation of the
protocol and as a general guidance they SHOULD be avoided. It is
possible, though, that such transfer becomes useful in a
controlled environment, for instance in the case of a transfer
onto a last resort spanning instance. Policies MAY be put in
place to override the general guidance and allow such transfers.
7. Backwards Compatibility
An OF is generally designed to compute a Rank of a directional link
in a fashion that is different from a bidirectional link, and in
particular will not use the same metrics and thus obtain 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
Thubert Expires June 11, 2012 [Page 7]
Internet-Draft draft-thubert-roll-asymlink December 2011
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 by 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 are
calculated and can be compared.
8. IANA Considerations
This specification requires that a bit in DIO shall be assigned to
indicate directional link operations as specified in Section 5
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, Thomas Clausen and Yoav Ben-
Yehezkel for their various contributions.
11. References
11.1. Normative References
[I-D.ietf-roll-rpl]
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
Thubert Expires June 11, 2012 [Page 8]
Internet-Draft draft-thubert-roll-asymlink December 2011
Lossy Networks", draft-ietf-roll-rpl-19 (work in
progress), March 2011.
[I-D.ietf-roll-terminology]
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.
11.2. Informative References
[I-D.ietf-roll-of0]
Thubert, P., "RPL Objective Function Zero",
draft-ietf-roll-of0-20 (work in progress), September 2011.
[I-D.tsao-roll-security-framework]
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.
Thubert Expires June 11, 2012 [Page 9]
Internet-Draft draft-thubert-roll-asymlink December 2011
Author's Address
Pascal Thubert (editor)
Cisco Systems
Village d'Entreprises Green Side
400, Avenue de Roumanille
Batiment T3
Biot - Sophia Antipolis 06410
FRANCE
Phone: +33 497 23 26 34
Email: pthubert@cisco.com
Thubert Expires June 11, 2012 [Page 10]
