draft-ietf-roll-p2p-rpl-11.txt   draft-ietf-roll-p2p-rpl-12.txt 
Internet Engineering Task Force M. Goyal, Ed. Internet Engineering Task Force M. Goyal, Ed.
Internet-Draft University of Wisconsin Internet-Draft University of Wisconsin
Intended status: Experimental Milwaukee Intended status: Experimental Milwaukee
Expires: November 7, 2012 E. Baccelli Expires: November 9, 2012 E. Baccelli
M. Philipp M. Philipp
INRIA INRIA
A. Brandt A. Brandt
Sigma Designs Sigma Designs
J. Martocci J. Martocci
Johnson Controls Johnson Controls
May 6, 2012 May 8, 2012
Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Reactive Discovery of Point-to-Point Routes in Low Power and Lossy
Networks Networks
draft-ietf-roll-p2p-rpl-11 draft-ietf-roll-p2p-rpl-12
Abstract Abstract
This document specifies a point-to-point route discovery mechanism, This document specifies a point-to-point route discovery mechanism,
complementary to the RPL core functionality. This mechanism allows complementary to the RPL core functionality. This mechanism allows
an IPv6 router to discover "on demand" routes to one or more IPv6 an IPv6 router to discover "on demand" routes to one or more IPv6
routers in the LLN such that the discovered routes meet specified routers in the LLN such that the discovered routes meet specified
metrics constraints. metrics constraints.
Status of this Memo Status of this Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 November 7, 2012. This Internet-Draft will expire on November 9, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 34 skipping to change at page 2, line 34
7.2. Data Option . . . . . . . . . . . . . . . . . . . . . . . 15 7.2. Data Option . . . . . . . . . . . . . . . . . . . . . . . 15
8. The Discovery Reply Object (DRO) . . . . . . . . . . . . . . . 15 8. The Discovery Reply Object (DRO) . . . . . . . . . . . . . . . 15
8.1. Secure DRO . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Secure DRO . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2. Setting a P2P-RDO Carried in a Discovery Reply Object . . 18 8.2. Setting a P2P-RDO Carried in a Discovery Reply Object . . 18
9. P2P-RPL Route Discovery By Creating a Temporary DAG . . . . . 18 9. P2P-RPL Route Discovery By Creating a Temporary DAG . . . . . 18
9.1. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 18 9.1. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 18
9.2. Trickle Operation For P2P Mode DIOs . . . . . . . . . . . 19 9.2. Trickle Operation For P2P Mode DIOs . . . . . . . . . . . 19
9.3. Processing a P2P Mode DIO . . . . . . . . . . . . . . . . 21 9.3. Processing a P2P Mode DIO . . . . . . . . . . . . . . . . 21
9.4. Additional Processing of a P2P Mode DIO At An 9.4. Additional Processing of a P2P Mode DIO At An
Intermediate Router . . . . . . . . . . . . . . . . . . . 22 Intermediate Router . . . . . . . . . . . . . . . . . . . 22
9.5. Additional Processing of a P2P Mode DIO At The Target . . 22 9.5. Additional Processing of a P2P Mode DIO At The Target . . 23
9.6. Processing a DRO At An Intermediate Router . . . . . . . . 24 9.6. Processing a DRO At An Intermediate Router . . . . . . . . 24
9.7. Processing a DRO At The Origin . . . . . . . . . . . . . . 25 9.7. Processing a DRO At The Origin . . . . . . . . . . . . . . 25
10. The Discovery Reply Object Acknowledgement (DRO-ACK) . . . . . 27 10. The Discovery Reply Object Acknowledgement (DRO-ACK) . . . . . 27
11. Packet Forwarding Along a Route Discovered Using P2P-RPL . . . 27 11. Packet Forwarding Along a Route Discovered Using P2P-RPL . . . 27
12. Interoperability with Core RPL . . . . . . . . . . . . . . . . 28 12. Interoperability with Core RPL . . . . . . . . . . . . . . . . 28
13. Security Considerations . . . . . . . . . . . . . . . . . . . 29 13. Security Considerations . . . . . . . . . . . . . . . . . . . 29
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
14.1. Additions to DIO Mode of Operation . . . . . . . . . . . . 29 14.1. Additions to Mode of Operation . . . . . . . . . . . . . . 29
14.2. Additions to RPL Control Message Options . . . . . . . . . 30 14.2. Additions to RPL Control Message Options . . . . . . . . . 30
14.3. Additions to RPL Control Codes . . . . . . . . . . . . . . 30 14.3. Additions to RPL Control Codes . . . . . . . . . . . . . . 30
14.4. New Registry for Upper Layer Headers inside Data Option . 30 14.4. New Registry for Upper Layer Headers inside Data Option . 31
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
16.1. Normative References . . . . . . . . . . . . . . . . . . . 31 16.1. Normative References . . . . . . . . . . . . . . . . . . . 32
16.2. Informative References . . . . . . . . . . . . . . . . . . 31 16.2. Informative References . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
Targeting Low power and Lossy Networks (LLNs), the RPL routing Targeting Low power and Lossy Networks (LLNs), the RPL routing
protocol [RFC6550] provides paths along a Directed Acyclic Graph protocol [RFC6550] provides paths along a Directed Acyclic Graph
(DAG) rooted at a single router in the network. Establishment and (DAG) rooted at a single router in the network. Establishment and
maintenance of a DAG is performed by routers in the LLN using DODAG maintenance of a DAG is performed by routers in the LLN using DODAG
Information Object (DIO) messages. When two arbitrary routers Information Object (DIO) messages. When two arbitrary routers
(neither of which is the DAG's root) need to communicate, the data (neither of which is the DAG's root) need to communicate, the data
packets are restricted to travel only along the links in the DAG. packets are restricted to travel only along the links in the DAG.
skipping to change at page 9, line 8 skipping to change at page 9, line 8
flag in the DRO message to let the nodes in the LLN know about the flag in the DRO message to let the nodes in the LLN know about the
completion of the route discovery process. The routers receiving completion of the route discovery process. The routers receiving
such a DRO should not generate any more DIOs for this temporary DAG. such a DRO should not generate any more DIOs for this temporary DAG.
Neither should they process any received DIOs for this temporary DAG Neither should they process any received DIOs for this temporary DAG
in future. However, such routers must still process the DROs in future. However, such routers must still process the DROs
received for this temporary DAG. received for this temporary DAG.
6. P2P Route Discovery Mode Of Operation 6. P2P Route Discovery Mode Of Operation
This section specifies a new RPL Mode of Operation (MOP), P2P Route This section specifies a new RPL Mode of Operation (MOP), P2P Route
Discovery mode (or P2P mode, for short), with value 4 (to be Discovery Mode (or P2P mode, for short), with value 4 (to be
confirmed by IANA). A DIO message, listing P2P mode as the MOP, is confirmed by IANA). A DIO message, listing P2P mode as the MOP, is
identified as performing a P2P-RPL route discovery by creating a identified as performing a P2P-RPL route discovery by creating a
temporary DAG. A P2P mode DIO MUST carry one and only one P2P Route temporary DAG. A P2P mode DIO MUST carry one and only one P2P Route
Discovery Option (specified in Section 7.1). Discovery Option (specified in Section 7.1).
6.1. Setting a P2P Mode DIO 6.1. Setting a P2P Mode DIO
The Base Object in a P2P mode DIO message MUST be set in the The Base Object in a P2P mode DIO message MUST be set in the
following manner: following manner:
skipping to change at page 15, line 30 skipping to change at page 15, line 30
o Option Length: An 8-bit unsigned integer, representing the length o Option Length: An 8-bit unsigned integer, representing the length
in octets of the option, not including the Option Type and Option in octets of the option, not including the Option Type and Option
Length fields. Length fields.
o SeqNo: A 4-bit field representing the sequence number of the data o SeqNo: A 4-bit field representing the sequence number of the data
carried by the Data Option. carried by the Data Option.
o Upper: A 4-bit field that identifies the upper layer protocol o Upper: A 4-bit field that identifies the upper layer protocol
header with which the information in the Data field starts. A header with which the information in the Data field starts. A
value 0x00 in this field identifies UDP as the upper layer value 0x0 in this field identifies UDP as the upper layer protocol
protocol. The other values are reserved at present. while the value 0xF is reserved for Private Use as defined in
[RFC5226]. The other values are Unassigned [RFC5226] at present.
o Data: If the Data Option is contained in a DIO, this field o Data: If the Data Option is contained in a DIO, this field
contains application data to be delivered to the Target(s). If contains application data to be delivered to the Target(s). If
the Data Option is contained in a DRO, this field contains the Data Option is contained in a DRO, this field contains
application data to be delivered to the Origin. application data to be delivered to the Origin.
8. The Discovery Reply Object (DRO) 8. The Discovery Reply Object (DRO)
This section defines two new RPL Control Message types, the Discovery This section defines two new RPL Control Message types, the Discovery
Reply Object (DRO), with code 0x04 (to be confirmed by IANA), and the Reply Object (DRO), with code 0x04 (to be confirmed by IANA), and the
skipping to change at page 21, line 8 skipping to change at page 21, line 8
deployments where specific destinations are reachable only through deployments where specific destinations are reachable only through
specific intermediate routers (and hence these intermediate specific intermediate routers (and hence these intermediate
routers should not suppress their DIOs). A particular deployment routers should not suppress their DIOs). A particular deployment
should take in account typical loss rates, the topological should take in account typical loss rates, the topological
characteristics of the LLN (the average/typical connectivity of characteristics of the LLN (the average/typical connectivity of
the nodes and the variance in connectivity: whether some the nodes and the variance in connectivity: whether some
destinations have only a small set of neighbors) and the need to destinations have only a small set of neighbors) and the need to
contain the message overhead of the route discovery when deciding contain the message overhead of the route discovery when deciding
the value of the redundancy constant. the value of the redundancy constant.
Applicability Statements that specify the use of P2P-RPL MUST provide
guidance for setting Trickle parameters, particularly Imin and the
redundancy constant.
9.3. Processing a P2P Mode DIO 9.3. Processing a P2P Mode DIO
The rules for DIO processing and transmission, described in Section 8 The rules for DIO processing and transmission, described in Section 8
of RPL [RFC6550], apply to P2P mode DIOs as well except as modified of RPL [RFC6550], apply to P2P mode DIOs as well except as modified
in this document. in this document.
The following rules for processing a received P2P mode DIO apply to The following rules for processing a received P2P mode DIO apply to
both Intermediate Routers and the Target. both Intermediate Routers and the Target.
A router SHOULD discard a received P2P mode DIO with no further A router SHOULD discard a received P2P mode DIO with no further
skipping to change at page 29, line 45 skipping to change at page 29, line 45
of a DRO message traveling in a routing loop, this document requires of a DRO message traveling in a routing loop, this document requires
each Intermediate Router to confirm that the Source Route listed each Intermediate Router to confirm that the Source Route listed
inside the message does not contain any routing loop involving itself inside the message does not contain any routing loop involving itself
before the router could forward the message further. As specified in before the router could forward the message further. As specified in
Section 9.6, this check involves the router making sure that its IPv6 Section 9.6, this check involves the router making sure that its IPv6
addresses do not appear multiple times inside the Source Route with addresses do not appear multiple times inside the Source Route with
one or more other IPv6 addresses in between. one or more other IPv6 addresses in between.
14. IANA Considerations 14. IANA Considerations
14.1. Additions to DIO Mode of Operation 14.1. Additions to Mode of Operation
IANA is requested to allocate a new value in the "DIO Mode of This document defines a new Mode of Operation, entitled "P2P Route
Operation" registry for the "P2P Route Discovery Mode" described in Discovery Mode" (see Section 6), assigned a value of 4 from the "Mode
this document. of Operation" space [to be removed upon publication:
+----------+-----------------------------------------+--------------+ http://www.iana.org/assignments/rpl/rpl.xml#mop] [RFC6550].
| MOP | Description | Reference |
| Value | | |
+----------+-----------------------------------------+--------------+
| 4 | Reactive P2P route discovery mode of | This |
| | operation | document |
+----------+-----------------------------------------+--------------+
DIO Mode of Operation +-------+---------------------------------------+---------------+
| Value | Description | Reference |
+-------+---------------------------------------+---------------+
| 4 | P2P Route Discovery Mode of Operation | This document |
+-------+---------------------------------------+---------------+
Mode of Operation
14.2. Additions to RPL Control Message Options 14.2. Additions to RPL Control Message Options
IANA is requested to allocate new values in the "RPL Control Message This document defines two new RPL options:
Options" registry for the "P2P Route Discovery Option" and the "Data
Option" described in this document. o "P2P Route Discovery Option" (see Section 7.1), assigned a value
of 0x0A from the "RPL Control Message Options" space [to be
removed upon publication: http://www.iana.org/assignments/rpl/
rpl.xml#control-message-options] [RFC6550].
o "Data Option" (see Section 7.2), assigned a value of 0x0B from the
"RPL Control Message Options" space [to be removed upon
publication: http://www.iana.org/assignments/rpl/
rpl.xml#control-message-options] [RFC6550].
+-------+---------------------+---------------+ +-------+---------------------+---------------+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+-------+---------------------+---------------+ +-------+---------------------+---------------+
| 10 | P2P Route Discovery | This document | | 0x0A | P2P Route Discovery | This document |
| 11 | Data | This document | | 0x0B | Data | This document |
+-------+---------------------+---------------+ +-------+---------------------+---------------+
RPL Control Message Options RPL Control Message Options
14.3. Additions to RPL Control Codes 14.3. Additions to RPL Control Codes
IANA is requested to allocate new code points in the "RPL Control This document defines the following new RPL messages:
Codes" registry for the "Discovery Reply Object" and "Discovery Reply
Object Acknowledgement" (and their secure versions) described in this o "Discovery Reply Object" (see Section 8), assigned a value of 0x04
document. from the "RPL Control Codes" space [to be removed upon
publication:
http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
[RFC6550].
o "Discovery Reply Object Acknowledgement" (see Section 10),
assigned a value of 0x05 from the "RPL Control Codes" space [to be
removed upon publication:
http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
[RFC6550].
o "Secure Discovery Reply Object" (see Section 8.1), assigned a
value of 0x84 from the "RPL Control Codes" space [to be removed
upon publication:
http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
[RFC6550].
o "Secure Discovery Reply Object Acknowledgement" (see Section 10),
assigned a value of 0x85 from the "RPL Control Codes" space [to be
removed upon publication:
http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
[RFC6550].
+------+--------------------------------------------+---------------+ +------+--------------------------------------------+---------------+
| Code | Description | Reference | | Code | Description | Reference |
+------+--------------------------------------------+---------------+ +------+--------------------------------------------+---------------+
| 0x04 | Discovery Reply Object | This document | | 0x04 | Discovery Reply Object | This document |
| 0x05 | Discovery Reply Object Acknowledgement | This document | | 0x05 | Discovery Reply Object Acknowledgement | This document |
| 0x84 | Secure Discovery Reply Object | This document | | 0x84 | Secure Discovery Reply Object | This document |
| 0x85 | Secure Discovery Reply Object | This document | | 0x85 | Secure Discovery Reply Object | This document |
| | Acknowledgement | | | | Acknowledgement | |
+------+--------------------------------------------+---------------+ +------+--------------------------------------------+---------------+
RPL Control Codes RPL Control Codes
14.4. New Registry for Upper Layer Headers inside Data Option 14.4. New Registry for Upper Layer Headers inside Data Option
This document creates a new IANA registry for the Upper Layer Header The Data Option (see Section 7.2) defines a 4-bit "Upper" field, for
type inside the RPL Data Option, with the following initial content: which IANA is requested to create and maintain a new registry titled
"Upper Layer Header Type Inside RPL Data Option". New codes may be
allocated in this registry only by an IETF Review [RFC5226]. Each
code is tracked with the following characteristics:
+-------+-------------+---------------+ o Value
| Value | Description | Reference |
+-------+-------------+---------------+
| 0x00 | UDP Header | This document |
+-------+-------------+---------------+
Upper Layer Header Types inside RPL Data Option o Description
o Reference
The following codes are currently defined:
+---------+-------------+---------------+
| Value | Description | Reference |
+---------+-------------+---------------+
| 0x0 | UDP Header | This document |
| 0x1-0xE | Unassigned | |
| 0xF | Private Use | This document |
+---------+-------------+---------------+
Upper Layer Header Types Inside RPL Data Option
15. Acknowledgements 15. Acknowledgements
Authors gratefully acknowledge the contributions of the following Authors gratefully acknowledge the contributions of the following
individuals (in alphabetical order) in the development of this individuals (in alphabetical order) in the development of this
document: Dominique Barthel, Jakob Buron, Thomas Clausen, Richard document: Dominique Barthel, Jakob Buron, Thomas Clausen, Richard
Kelsey, Phil Levis, Zach Shelby, Pascal Thubert, Hristo Valev and JP Kelsey, Phil Levis, Zach Shelby, Pascal Thubert, Hristo Valev and JP
Vasseur. Vasseur.
16. References 16. References
16.1. Normative References 16.1. Normative References
[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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", RFC 6206, March 2011. "The Trickle Algorithm", RFC 6206, March 2011.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012. Lossy Networks", RFC 6550, March 2012.
[RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D.
Barthel, "Routing Metrics Used for Path Calculation in Barthel, "Routing Metrics Used for Path Calculation in
 End of changes. 21 change blocks. 
44 lines changed or deleted 95 lines changed or added

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