< draft-thubert-roll-asymlink-00.txt   draft-thubert-roll-asymlink-01.txt >
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track October 17, 2011 Intended status: Standards Track November 16, 2011
Expires: April 19, 2012 Expires: May 19, 2012
RPL adaptation for asymmetrical links RPL adaptation for asymmetrical links
draft-thubert-roll-asymlink-00 draft-thubert-roll-asymlink-01
Abstract Abstract
The Routing Protocol for Low Power and Lossy Networks defines a The Routing Protocol for Low Power and Lossy Networks defines a
generic Distance Vector protocol for Low Power and Lossy Networks, generic Distance Vector protocol for Low Power and Lossy Networks,
many of which exhibit strongly asymmetrical characteristics. This many of which exhibit strongly asymmetrical characteristics. This
draft proposes an extension for that optimizes RPL operations whereby draft proposes an extension for that optimizes RPL operations whereby
upwards and downwards direction-optimized RPL instances are upwards and downwards direction-optimized RPL instances are
associated. associated.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 19, 2012. This Internet-Draft will expire on May 19, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The asymmetrical link problem . . . . . . . . . . . . . . . . . 4 3. The asymmetrical link problem . . . . . . . . . . . . . . . . . 4
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 4 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 4
5. Modified DODAG Information Object (DIO) . . . . . . . . . . . . 5 5. Modified DODAG Information Object (DIO) . . . . . . . . . . . . 5
6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Backward compatibility . . . . . . . . . . . . . . . . . . . . 6 7. Backward compatibility . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . . 8 11.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The IETF ROLL Working Group has defined application-specific routing The IETF ROLL Working Group has defined application-specific routing
requirements for a Low Power and Lossy Network (LLN) routing requirements for a Low Power and Lossy Network (LLN) routing
protocol, specified in [RFC5548], [RFC5673], [RFC5826], and protocol, specified in [RFC5548], [RFC5673], [RFC5826], and
[RFC5867], many of which explicitly or implicitly refer to links with [RFC5867], many of which explicitly or implicitly refer to links with
asymmetrical properties. asymmetrical properties.
Upon those requirements, the Routing Protocol for Low Power and Lossy 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 Network [I-D.ietf-roll-rpl] was designed as a platform that can be
extended by further specifications or guidances, by adding new extended by further specifications or guidances, by adding new
metrics, Objective Functions, or additional options. metrics, Objective Functions, or additional options.
RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs) RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs)
within instances of the protocol. Each instance is associated with within instances of the protocol. Each instance is associated with
an Objective Function that is designed to solve the problem that is an Objective Function that is designed to solve the problem that is
addressed by that instance. addressed by that instance.
In one hand, RPL requires bidirectional links for the control, but on In one hand, RPL requires bi-directional links for the control, but
the other, there is no requirement that the properties of a link are on the other, there is no requirement that the properties of a link
the same in both directions. In fact, such a symmetry is rarely are the same in both directions. In fact, a perfect symmetry is
present in LLNs, whether links are based on radios or power-line. 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 Some initial implementations require that the quality of both
directions of a link is evaluated as very good so that the link can 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 be used for control and data in both directions. This eliminates
asymmetrical links that are very good in one direction, but only good asymmetrical links that are very good in one direction, but only good
enough for scarce activity in the other direction. enough for scarce activity in the other direction.
In practice, a DAG that is built to optimize upwards traffic is In practice, a DAG that is built to optimize upwards traffic is
generally not congruent with a DAG that is built to optimize generally not congruent with a DAG that is built to optimize
downwards traffic. This is why this specification is designed to downwards traffic. This is why this specification is designed to
enable asymmetrical routing DAGs that are bound together to get the enable asymmetrical routing DAGs that are bound together to get the
maximum benefits of all bidirectional links. maximum benefits of all types of bi-directional links.
2. Terminology 2. Terminology
The terminology used in this document is consistent with and The terminology used in this document is consistent with and
incorporates that described in `Terminology in Low power And Lossy incorporates that described in `Terminology in Low power And Lossy
Networks' [I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl]. 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 The term upwards qualifies a link, a DODAG or an instance that is
optimal for sending traffic in the general direction of the root, optimal for sending traffic in the general direction of the root,
though may be usable but suboptimal for traffic coming form the though may be usable but suboptimal for traffic coming form the
direction of the root. The term downwards qualifies the same words direction of the root. The term downwards qualifies the same words
for the opposite direction. for the opposite direction.
The term parenting applied to instances refers to the directional The term parenting applied to instances refers to the directional
association of two instances. The graph formed by parented instances association of two instances. The meta graph formed by parented
must be a DAG. Traffic may be transferred from an instance onto a instances must be a DAG. Traffic may be transferred from an instance
parent instance under specified circumstances. 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
directions.
3. The asymmetrical link problem 3. The asymmetrical link problem
4. Solution Overview 4. Solution Overview
With the core RPL specification, [I-D.ietf-roll-rpl] each instance is With the core RPL specification, [I-D.ietf-roll-rpl] each instance is
a separate routing topology, and packets must be forwarded within the a separate routing topology, and packets must be forwarded within the
same topology / same instance. One direct consequence of that design same topology / same instance. One direct consequence of that design
choice is that a topology must be very good for both upwards and choice is that a topology must be very good for both upwards and
downwards traffic; otherwise, traffic between two nodes in the downwards traffic; otherwise, traffic between two nodes in the
instance may suffer. instance may suffer.
A simple approach to address bidirectional but asymmetrical links RPL is designed to operate on bi-directional links. When the link
with RPL is to construct two DAGs, one for upwards traffic and one properties do not widely differ between the upwards and the downwards
for downwards traffic, each DAG a separate instance, and then bind directions, a single DAG is adequate as the routing topology for both
the two together. In order to benefit from both instances for a same upwards and downwards traffic. In that case, an asymmetrical link,
packet, this solution extends RPL to allow traffic to be transferred that can only be used for traffic in one direction, can not
from one instance to the next. 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
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 an instance onto another.
It can be noted at this point that with [I-D.ietf-roll-rpl], traffic 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 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 traffic within a DODAG might go up to a common parent and then down
to the destination. In terms of instance relationship, this means to the destination. In terms of instance relationship, this means
that when an upwards and a downwards instance are bound together, that when an upwards and a downwards instances are bound together,
traffic from the former may be transferred to the latter, but not the 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 other way around. In other words, there is an order, a parent-child
relationship, between the two instances. relationship, between the two instances.
Additionally, if there is no next-hop for a packet going down within 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 the instance, then with [I-D.ietf-roll-rpl] the packet will be
dropped. In order to limit that risk, it is tempting though dropped or sent back with an error along the wrong direction of an
inefficient to lower the constraints that are applied to build the asymmetric link. In order to avoid those unwanted behaviors, it is
topology. It can be more efficient to actually keep the constraints tempting though inefficient to lower the constraints that are applied
as they should be, but, instead, enable a less constrained, more to build the topology. It can be more efficient to actually keep the
spanning, fall-back topology into which traffic can be transferred. 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 For that reason, this solution allows for more complex instance
relationships than plain child-parent associations. In order to relationships than plain child-parent associations. In order to
avoids loops which could be created when transferring packets from avoids loops which could be created when transferring packets from
one instance to the next, this solution requires that the instances one instance to the next, this solution requires that the instances
be themselves organized as a superior Directed Acyclic Graph, and be themselves organized as a Directed Acyclic Graph, and enforce that
enforce that inter-DAG transfers occur only within that superior inter-DAG transfers occur only within that meta DAG.
super-DAG of DAG instances.
5. Modified DODAG Information Object (DIO) 5. Modified DODAG Information Object (DIO)
The DODAG Information Object [I-D.ietf-roll-rpl] carries information The DODAG Information Object [I-D.ietf-roll-rpl] carries information
that allows a node to discover a RPL Instance, learn its that allows a node to discover a RPL Instance, learn its
configuration parameters, select a DODAG parent set, and maintain the configuration parameters, select a DODAG parent set, and maintain the
DODAG. This specification defines a new flag bit to indicate that DODAG. This specification defines a new flag bit to indicate that
the DAG is directional. the DAG is directional.
0 1 2 3 0 1 2 3
skipping to change at page 7, line 40 skipping to change at page 8, line 27
9. Security Considerations 9. Security Considerations
Security Considerations for this proposal are to be developed in Security Considerations for this proposal are to be developed in
accordance with recommendations laid out in, for example, accordance with recommendations laid out in, for example,
[I-D.tsao-roll-security-framework]. [I-D.tsao-roll-security-framework].
10. Acknowledgements 10. Acknowledgements
The author wishes to recognize Richard Kelsey, JP Vasseur, Tom The author wishes to recognize Richard Kelsey, JP Vasseur, Tom
Phinney, Robert Assimiti, Don Sturek and Yoav Ben-Yehezkel for their Phinney, Robert Assimiti, Don Sturek, Thomas Clausen and Yoav Ben-
various contributions. Yehezkel for their various contributions.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-roll-rpl] [I-D.ietf-roll-rpl]
Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
Vasseur, "RPL: IPv6 Routing Protocol for Low power and Vasseur, "RPL: IPv6 Routing Protocol for Low power and
Lossy Networks", draft-ietf-roll-rpl-19 (work in Lossy Networks", draft-ietf-roll-rpl-19 (work in
progress), March 2011. progress), March 2011.
[I-D.ietf-roll-terminology] [I-D.ietf-roll-terminology]
 End of changes. 14 change blocks. 
37 lines changed or deleted 77 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/