draft-ietf-6man-rpl-option-00.txt   draft-ietf-6man-rpl-option-01.txt 
6MAN J. Hui 6MAN J. Hui
Internet-Draft Arch Rock Corporation Internet-Draft Arch Rock Corporation
Intended status: Standards Track JP. Vasseur Intended status: Standards Track JP. Vasseur
Expires: January 27, 2011 Cisco Systems, Inc Expires: April 26, 2011 Cisco Systems, Inc
July 26, 2010 October 23, 2010
RPL Option for Carrying RPL Information in Data-Plane Datagrams RPL Option for Carrying RPL Information in Data-Plane Datagrams
draft-ietf-6man-rpl-option-00 draft-ietf-6man-rpl-option-01
Abstract Abstract
The RPL protocol requires data-plane datagrams to carry RPL routing The RPL protocol requires data-plane datagrams to carry RPL routing
information that is processed by RPL routers when forwarding those information that is processed by RPL routers when forwarding those
datagrams. This document describes the RPL option for use within a datagrams. This document describes the RPL option for use within a
RPL domain. RPL domain.
Status of this Memo Status of this Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 January 27, 2011. This Internet-Draft will expire on April 26, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Format of the RPL Option . . . . . . . . . . . . . . . . . . . 6 3. Format of the RPL Option . . . . . . . . . . . . . . . . . . . 5
4. RPL Router Behavior . . . . . . . . . . . . . . . . . . . . . 7 4. RPL Router Behavior . . . . . . . . . . . . . . . . . . . . . 7
5. RPL Border Router Behavior . . . . . . . . . . . . . . . . . . 8 5. RPL Border Router Behavior . . . . . . . . . . . . . . . . . . 8
6. Usage of the RPL Option . . . . . . . . . . . . . . . . . . . 9 6. Usage of the RPL Option . . . . . . . . . . . . . . . . . . . 9
7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 10 7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . . 14 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 12.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
RPL is a distance vector IPv6 routing protocol designed for low power RPL is a distance vector IPv6 routing protocol designed for low power
and lossy networks [I-D.ietf-roll-rpl]. Such networks are typically and lossy networks [I-D.ietf-roll-rpl]. Such networks are typically
constrained in energy and/or channel capacity. To conserve precious constrained in energy and/or channel capacity. To conserve precious
resources, a routing protocol must generate control traffic resources, a routing protocol must generate control traffic
sparingly. However, this is at odds with the need to quickly sparingly. However, this is at odds with the need to quickly
propagate any new routing information to resolve routing propagate any new routing information to resolve routing
inconsistencies quickly. inconsistencies quickly.
To help minimize resource consumption, RPL uses a slow proactive To help minimize resource consumption, RPL uses a slow proactive
process to construct and maintain a routing topology but a reactive process to construct and maintain a routing topology but a reactive
and dynamic approach to resolving routing inconsistencies. In the and dynamic approach to resolving routing inconsistencies. In the
steady state, RPL maintains the routing topology using a low-rate steady state, RPL maintains the routing topology using a low-rate
beaconing process. However, when RPL detects inconsistencies that beaconing process. However, when RPL detects inconsistencies that
may prevent proper datagram delivery, RPL temporarily increases the may prevent proper datagram delivery, RPL temporarily increases the
beacon rate to quickly resolve those inconsistencies. Such a dynamic beacon rate to quickly resolve those inconsistencies. Such a dynamic
rate of control packets operation is governed by the use of dynamic rate of control packets operation is governed by the use of dynamic
timers also referred to as "trickle" timers and defined in timers also referred to as "trickle" timers and defined in
[I-D.levis-roll-trickle]. By contrast with other routing protocols [I-D.ietf-roll-trickle]. By contrast with other routing protocols
such as OSPF ([RFC2328]), RPL detects routing inconsistencies using such as OSPF ([RFC2328]), RPL detects routing inconsistencies using
data-path verification, by including routing information within the data-path verification, by including routing information within the
datagram itself. Data-path verification quickly detects and resolves datagram itself. Data-path verification quickly detects and resolves
inconsistencies when routes are needed by the data flow itself. In inconsistencies when routes are needed by the data flow itself. In
doing so, repair mechanisms operate only as needed, allowing the doing so, repair mechanisms operate only as needed, allowing the
control and data planes to operate on similar time scales. The main control and data planes to operate on similar time scales. The main
motivation for data path verification in Low power and Lossy Networks motivation for data path verification in Low power and Lossy Networks
(LLNs) is that control plane traffic should be carefully bounded with (LLNs) is that control plane traffic should be carefully bounded with
respect to the data traffic: there is no need to solve a routing respect to the data traffic: there is no need to solve a routing
issues (which may be temporary) in the absence of data traffic. issues (which may be temporary) in the absence of data traffic.
The RPL protocol constructs a DAG that attempts to minimize path The RPL protocol constructs a Directed Acyclic Graph (DAG) that
costs to the DAG root according to a set of metric and objective attempts to minimize path costs to the DAG root according to a set of
functions. There are circumstances where loops may occur, and RPL is metric and objective functions. There are circumstances where loops
designed to use a data-path loop detection method. This is one of may occur, and RPL is designed to use a data-path loop detection
the known requirements of RPL and other data-path usage might be method. This is one of the known requirements of RPL and other data-
defined in the future. path usage might be defined in the future.
To that end, this document proposes a new IPv6 option called the RPL To that end, this document proposes a new IPv6 option called the RPL
Option to be carried within the IPv6 Hop-by-Hop header. The RPL Option to be carried within the IPv6 Hop-by-Hop header. The RPL
Option is for use only within a RPL domain. Routers on the edge of Option is for use only within a RPL domain.
the domain MAY insert the RPL Option into datagrams entering the RPL
domain but MUST remove the RPL Option from datagrams exiting the RPL
domains, if one exists.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Overview 2. Overview
Datagrams being forwarded within a RPL domain MUST include a RPL Datagrams being forwarded within a RPL domain MUST include a RPL
skipping to change at page 6, line 16 skipping to change at page 5, line 16
The RPL option is carried in an IPv6 Hop-by-Hop Options header, The RPL option is carried in an IPv6 Hop-by-Hop Options header,
immediately following the IPv6 header. The RPL option has the immediately following the IPv6 header. The RPL option has the
following format: following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len | | Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|R|F|0|0|0|0|0| RPLInstanceID | SenderRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-TLVs) | | (sub-TLVs) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RPL Option Figure 1: RPL Option
The Opt Data Len MUST NOT exceed RPL_OPTION_MAX_SIZE octets. Option Type: TBD
The Option Data of the RPL option is expected to change en-route. Opt Data Len:
Nodes that do not understand the RPL option MUST skip over this
option and continue processing the header. Thus, according to Down 'O': 1-bit flag indicating whether the packet is expected to
[RFC2460] the two high order bits of the Option Type must be equal progress Up or Down. A router sets the 'O' flag when the
set to zero and the third bit is equal to 1. The RPL Option Data packet is expected to progress Down (using DAO routes), and
Length is variable. clears it when forwarding toward the DODAG root (to a node with
a lower rank). A host or RPL leaf node MUST set the 'O' flag
to 0.
Rank-Error 'R': 1-bit flag indicating whether a rank error was
detected. A rank error is detected when there is a mismatch in
the relative ranks and the direction as indicated in the 'O'
bit. A host or RPL leaf node MUST set the 'R' bit to 0.
Forwarding-Error 'F': 1-bit flag indicating that this node can not
forward the packet further towards the destination. The 'F'
bit might be set by a child node that does not have a route to
destination for a packet with the Down 'O' bit set. A host or
RPL leaf node MUST set the 'F' bit to 0.
RPLInstanceID: 8-bit field indicating the DODAG instance along which
the packet is sent.
SenderRank: 16-bit field set to zero by the source and to
DAGRank(rank) by a router that forwards inside the RPL network.
Values within the RPL option are expected to change en-route. Nodes
that do not understand the RPL option MUST discard the packet. Thus,
according to [RFC2460] the two high order bits of the Option Type
must be equal set to '01' and the third bit is equal to '1'. The RPL
Option Data Length is variable.
The action taken by using the RPL Option and the potential set of The action taken by using the RPL Option and the potential set of
sub-TLVs carried within the RPL Option MUST be specified by the RFC sub-TLVs carried within the RPL Option MUST be specified by the RFC
of the protocol that use that option. No TLVs are currently defined. of the protocol that use that option. No TLVs are currently defined.
4. RPL Router Behavior 4. RPL Router Behavior
Routers MUST include a RPL Option when forwarding datagrams that do Routers MUST include a RPL Option when forwarding datagrams that do
not already contain a RPL Option. If one does not already exist, not already contain a RPL Option. If one does not already exist,
routers MUST use IPv6-in-IPv6 tunneling, as specified in [RFC2473] to routers MUST use IPv6-in-IPv6 tunneling, as specified in [RFC2473] to
skipping to change at page 9, line 11 skipping to change at page 9, line 11
For datagrams exiting the RPL domain, RPL Border Routers MUST remove For datagrams exiting the RPL domain, RPL Border Routers MUST remove
the RPL Option from the datagram and update the IPv6 Payload Length the RPL Option from the datagram and update the IPv6 Payload Length
field accordingly. field accordingly.
6. Usage of the RPL Option 6. Usage of the RPL Option
The RPL option is only for use within a RPL domain. RPL routers MUST The RPL option is only for use within a RPL domain. RPL routers MUST
process and include the RPL option when forwarding datagrams to other process and include the RPL option when forwarding datagrams to other
nodes within the RPL domain. Routers on the edge of a RPL domain nodes within the RPL domain. Routers on the edge of a RPL domain
MUST remove the RPL option when forwarding datagrams to nodes outside MUST remove the RPL option when forwarding datagrams to nodes outside
the RPL domain. The final destination of the datagram MAY ignore the the RPL domain.
RPL option.
7. Protocol Constants 7. Protocol Constants
RPL_OPTION_MAX_SIZE 128 RPL_OPTION_MAX_SIZE 128
8. Acknowledgements 8. Acknowledgements
The authors thank Vishwas Manral and Erik Nordmark for their comments The authors thank Richard Kelsey, Vishwas Manral, Erik Nordmark,
and suggestions that helped shape this document. Pascal Thubert, and Tim Winter, for their comments and suggestions
that helped shape this document.
9. IANA Considerations 9. IANA Considerations
The RPL option requires an IPv6 Option Number. The RPL option requires an IPv6 Option Number.
HEX act chg rest HEX act chg rest
--- --- --- ----- --- --- --- -----
1 00 1 01011 1 01 1 01011
The first two bits indicate that the IPv6 node may skip over this The first two bits indicate that the IPv6 node MUST discard the
option and continue processing the header if it doesn't recognize the packet if it doesn't recognize the option type, and the third bit
option type, and the third bit indicates that the Option Data may indicates that the Option Data may change en-route.
change en-route.
This document also creates a new IANA registry for the sub-TLVs. No
sub-TLVs are defined in this specification. The policy for this
registry [RFC5226] is IETF Review.
10. Security Considerations 10. Security Considerations
This option may be used a several potential attacks since routers may This option may be used a several potential attacks since routers may
be flooded by bogus datagram containing the RPL option. It is thus be flooded by bogus datagram containing the RPL option. It is thus
RECOMMENDED for routers to implement a rate limiter for datagrams RECOMMENDED for routers to implement a rate limiter for datagrams
using the RPL option. using the RPL option.
11. References 11. Changes
11.1. Normative References (This section to be removed by the RFC editor.)
Draft 01:
- Specify that a node must discard the packet if it doesn't
recognize the RPL option.
- Include RPL loop detection bits in the base header such that an
IPv6 Hop-by-Hop Option header with the minimal RPL option consumes
only 8 octets.
12. References
12.1. Normative References
[I-D.ietf-roll-rpl] [I-D.ietf-roll-rpl]
Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
Protocol for Low power and Lossy Networks", Kelsey, R., Levis, P., Networks, D., Struik, R., and J.
draft-ietf-roll-rpl-10 (work in progress), June 2010. Vasseur, "RPL: IPv6 Routing Protocol for Low power and
Lossy Networks", draft-ietf-roll-rpl-13 (work in
progress), October 2010.
[I-D.levis-roll-trickle] [I-D.ietf-roll-trickle]
Levis, P. and T. Clausen, "The Trickle Algorithm", Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
draft-levis-roll-trickle-00 (work in progress), "The Trickle Algorithm", draft-ietf-roll-trickle-04 (work
February 2010. in progress), August 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998. IPv6 Specification", RFC 2473, December 1998.
11.2. Informative References [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
12.2. Informative References
[I-D.ietf-roll-terminology] [I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-03 (work in Networks", draft-ietf-roll-terminology-04 (work in
progress), March 2010. progress), September 2010.
Authors' Addresses Authors' Addresses
Jonathan W. Hui Jonathan W. Hui
Arch Rock Corporation Arch Rock Corporation
501 2nd St. Ste. 410 501 2nd St. Ste. 410
San Francisco, California 94107 San Francisco, California 94107
USA USA
Phone: +415 692 0828 Phone: +415 692 0828
 End of changes. 21 change blocks. 
50 lines changed or deleted 97 lines changed or added

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