--- 1/draft-ietf-roll-p2p-rpl-13.txt 2012-10-17 11:14:17.909424994 +0200 +++ 2/draft-ietf-roll-p2p-rpl-14.txt 2012-10-17 11:14:17.985425580 +0200 @@ -1,26 +1,26 @@ Internet Engineering Task Force M. Goyal, Ed. Internet-Draft University of Wisconsin Intended status: Experimental Milwaukee -Expires: December 6, 2012 E. Baccelli +Expires: April 20, 2013 E. Baccelli M. Philipp INRIA A. Brandt Sigma Designs J. Martocci Johnson Controls - June 4, 2012 + October 17, 2012 Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks - draft-ietf-roll-p2p-rpl-13 + draft-ietf-roll-p2p-rpl-14 Abstract This document specifies a point-to-point route discovery mechanism, complementary to the RPL core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in the LLN such that the discovered routes meet specified metrics constraints. Status of this Memo @@ -31,21 +31,21 @@ 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 December 6, 2012. + This Internet-Draft will expire on April 20, 2013. Copyright Notice Copyright (c) 2012 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 @@ -81,27 +81,27 @@ 9.7. Processing a DRO At The Origin . . . . . . . . . . . . . . 27 10. The Discovery Reply Object Acknowledgement (DRO-ACK) . . . . . 28 11. Packet Forwarding Along a Route Discovered Using P2P-RPL . . . 29 12. Interoperability with Core RPL . . . . . . . . . . . . . . . . 29 13. Security Considerations . . . . . . . . . . . . . . . . . . . 30 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 14.1. Additions to Mode of Operation . . . . . . . . . . . . . . 31 14.2. Additions to RPL Control Message Options . . . . . . . . . 31 14.3. Additions to RPL Control Codes . . . . . . . . . . . . . . 32 14.4. New Registry for Upper Layer Protocol Types Inside - Data Option . . . . . . . . . . . . . . . . . . . . . . . 32 + Data Option . . . . . . . . . . . . . . . . . . . . . . . 33 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 - 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 - 16.1. Normative References . . . . . . . . . . . . . . . . . . . 33 + 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 + 16.1. Normative References . . . . . . . . . . . . . . . . . . . 34 16.2. Informative References . . . . . . . . . . . . . . . . . . 34 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 1. Introduction Targeting Low power and Lossy Networks (LLNs), the RPL routing protocol [RFC6550] provides paths along a Directed Acyclic Graph (DAG) rooted at a single router in the network. Establishment and maintenance of a DAG is performed by routers in the LLN using DODAG Information Object (DIO) messages. When two arbitrary routers (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. @@ -373,25 +373,25 @@ flag in the DRO message to let the nodes in the LLN know about the completion of the route discovery process. The routers receiving such a DRO should not generate any more 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 received for this temporary DAG. 6. P2P Route Discovery Mode Of Operation This section specifies a new RPL Mode of Operation (MOP), P2P Route - 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 - 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 - Discovery Option (specified in Section 7.1). + Discovery Mode (or P2P mode, for short), with value TBD1. A DIO + message, listing P2P mode as the MOP, is 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 Discovery Option (specified in + Section 7.1). 6.1. Setting a P2P Mode DIO The Base Object in a P2P mode DIO message MUST be set in the following manner: o RPLInstanceID: RPLInstanceID MUST be a local value as described in Section 5.1 of [RFC6550]. The Origin MUST NOT use the same RPLInstanceID in two or more concurrent route discoveries. When initiating a new route discovery to a particular Target, the @@ -524,41 +524,41 @@ This document defines two new RPL control message options: the P2P Route Discovery Option and the Data Option. 7.1. P2P Route Discovery Option (P2P-RDO) - 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type = 10 | Option Length |R|H| N | Compr | L |MaxRank/NH | + | Type = TBD2 | Option Length |R|H| N | Compr | L |MaxRank/NH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Target | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Address[1..n] | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Format of P2P Route Discovery Option (P2P-RDO) The format of a P2P Route Discovery Option (P2P-RDO) is illustrated in Figure 1. A P2P mode DIO and a DRO (defined in Section 8) message MUST carry one and at most one P2P-RDO. A P2P-RDO consists of the following fields: - o Option Type: 0x0A (to be confirmed by IANA). + o Option Type: TBD2. o Option Length: 8-bit unsigned integer, representing the length in octets of the option, not including the Option Type and Option Length fields. o Reply (R): The Origin sets this flag to one to allow the Target(s) to send DRO messages back to the Origin. If this flag is zero, a Target MUST NOT generate any DRO message. o Hop-by-hop (H): This flag is valid only if the R flag is set to @@ -664,30 +664,30 @@ specifying a complete route in the Address vector MUST ensure that the vector does not contain any address more than once. * The Address vector MUST NOT contain any multicast addresses. 7.2. Data Option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type = 11 | Option Length | UpperLayerPrt | Data | + | Type = TBD3 | Option Length | UpperLayerPrt | Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... Figure 2: Format of Data Option The format of a Data Option is illustrated in Figure 2. A P2P mode DIO and a DRO (defined in Section 8) message MAY carry one Data Option. A P2P-RDO consists of the following fields: - o Option Type: 0x0B (to be confirmed by IANA). + o Option Type: TBD3. o Option Length: An 8-bit unsigned integer, representing the length in octets of the option, not including the Option Type and Option Length fields. o Upper Layer Protocol: An 8-bit field that identifies the upper layer protocol header with which the information in the Data field starts. A value 0x00 in this field identifies UDP as the upper layer protocol while the value 0xFF is reserved for Private Use as defined in [RFC5226]. The other values are Unassigned [RFC5226] @@ -709,23 +709,22 @@ it MUST include the same Data Option in all retransmissions of this DRO message and MUST NOT include a different Data Option in any other DRO messages it generates for this route discovery. Also, an Intermediate Router, which needs to forward a received DRO message further, MUST include in the forwarded message a verbatim copy of the Data Option found inside the received message. 8. The Discovery Reply Object (DRO) This section defines two new RPL Control Message types, the Discovery - Reply Object (DRO), with code 0x04 (to be confirmed by IANA), and the - Secure DRO, with code 0x84 (to be confirmed by IANA). A DRO serves - one of the following functions: + Reply Object (DRO), with code TBD4, and the Secure DRO, with code + TBD5. A DRO serves one of the following functions: o Carry a discovered Source Route from a Target to the Origin; o Establish a Hop-by-hop Route as it travels from a Target to the Origin. A DRO message MAY serve the function of letting the routers in the LLN know that a P2P-RPL route discovery is complete and no more DIO messages need to be generated for the corresponding temporary DAG. A DRO message MAY also carry time-critical application data from the @@ -1274,30 +1273,29 @@ Intermediate Router may drop the DRO message (e.g., because of its inability to store the state for the Hop-by-hop Route the DRO is establishing). To protect against the potential failure of a DRO message to reach the Origin, the Target MAY request the Origin to send back a DRO Acknowledgement (DRO-ACK) message on receiving a DRO message. Failure to receive such an acknowledgement within the DRO_ACK_WAIT_TIME interval of sending the DRO message forces the Target to resend the message. This section defines two new RPL Control Message types: DRO - Acknowledgement (DRO-ACK; with code 0x05; to be confirmed by IANA) - and Secure DRO-ACK (with code 0x85; to be confirmed by IANA). A DRO- - ACK message MUST travel as a unicast message from the Origin to the - Target. The format of a base DRO-ACK message is shown in Figure 4. - Various fields in a DRO-ACK message MUST have the same values as the - corresponding fields in the DRO message. The field marked as - "Reserved" MUST be set to zero on transmission and MUST be ignored on - reception. A Secure DRO-ACK message follows the format in Figure 7 - of [RFC6550], where the base format is same as the base DRO-ACK shown - in Figure 4. + Acknowledgement (DRO-ACK; with code TBD6) and Secure DRO-ACK (with + code TBD7). A DRO-ACK message MUST travel as a unicast message from + the Origin to the Target. The format of a base DRO-ACK message is + shown in Figure 4. Various fields in a DRO-ACK message MUST have the + same values as the corresponding fields in the DRO message. The + field marked as "Reserved" MUST be set to zero on transmission and + MUST be ignored on reception. A Secure DRO-ACK message follows the + format in Figure 7 of [RFC6550], where the base format is same as the + base DRO-ACK shown in Figure 4. 11. Packet Forwarding Along a Route Discovered Using P2P-RPL An Origin MAY use a Source Routing Header (SRH) [RFC6554] to send a packet along a Source Route discovered using P2P-RPL. Travel along a Hop-by-hop Route, established using P2P-RPL, requires specifying the RPLInstanceID and the DODAGID (of the temporary DAG used for the route discovery) to identify the route. This is because a P2P-RPL route discovery does not use globally unique RPLInstanceID @@ -1379,90 +1377,113 @@ before the router could forward the message further. As specified in Section 9.6, this check involves the router making sure that its IPv6 addresses do not appear multiple times inside the Source Route with one or more other IPv6 addresses in between. 14. IANA Considerations 14.1. Additions to Mode of Operation This document defines a new Mode of Operation, entitled "P2P Route - Discovery Mode" (see Section 6), assigned a value of 4 from the "Mode + Discovery Mode" (see Section 6), assigned a value TBD1 from the "Mode of Operation" space [to be removed upon publication: - http://www.iana.org/assignments/rpl/rpl.xml#mop] [RFC6550]. + http://www.iana.org/assignments/rpl/rpl.xml#mop] [RFC6550]. IANA is + requested to allocate a suitable value to TBD1. The string TBD1 in + this document should be replaced by the allocated value. The + previous two sentences should be removed before publication. +-------+---------------------------------------+---------------+ | Value | Description | Reference | +-------+---------------------------------------+---------------+ - | 4 | P2P Route Discovery Mode of Operation | This document | + | TBD1 | P2P Route Discovery Mode of Operation | This document | +-------+---------------------------------------+---------------+ Mode of Operation 14.2. Additions to RPL Control Message Options This document defines two new RPL options: 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]. + TBD2 from the "RPL Control Message Options" space [to be removed + upon publication: http://www.iana.org/assignments/rpl/ + rpl.xml#control-message-options] [RFC6550]. IANA is requested to + allocate a suitable value to TBD2. The string TBD2 in this + document should be replaced by the allocated value. The previous + two sentences should be removed before publication. - o "Data Option" (see Section 7.2), assigned a value of 0x0B from the + o "Data Option" (see Section 7.2), assigned a value TBD3 from the "RPL Control Message Options" space [to be removed upon publication: http://www.iana.org/assignments/rpl/ - rpl.xml#control-message-options] [RFC6550]. + rpl.xml#control-message-options] [RFC6550]. IANA is requested to + allocate a suitable value to TBD3. The string TBD3 in this + document should be replaced by the allocated value. The previous + two sentences should be removed before publication. +-------+---------------------+---------------+ | Value | Meaning | Reference | +-------+---------------------+---------------+ - | 0x0A | P2P Route Discovery | This document | - | 0x0B | Data | This document | + | TBD2 | P2P Route Discovery | This document | + | TBD3 | Data | This document | +-------+---------------------+---------------+ RPL Control Message Options 14.3. Additions to RPL Control Codes This document defines the following new RPL messages: - o "Discovery Reply Object" (see Section 8), assigned a value of 0x04 + o "Discovery Reply Object" (see Section 8), assigned a value TBD4 from the "RPL Control Codes" space [to be removed upon publication: http://www.iana.org/assignments/rpl/rpl.xml#control-codes] - [RFC6550]. + [RFC6550]. IANA is requested to allocate TBD4 from the range + 0x00-0x7F to indicate a message without security enabled. The + string TBD4 in this document should be replaced by the allocated + value. The previous two sentences should be removed before + publication. - o "Discovery Reply Object Acknowledgement" (see Section 10), - assigned a value of 0x05 from the "RPL Control Codes" space [to be - removed upon publication: + o "Secure Discovery Reply Object" (see Section 8.1), assigned a + value TBD5 from the "RPL Control Codes" space [to be removed upon + publication: http://www.iana.org/assignments/rpl/rpl.xml#control-codes] - [RFC6550]. + [RFC6550]. IANA is requested to allocate TBD5 from the range + 0x80-0xFF to indicate a message with security enabled. The string + TBD5 in this document should be replaced by the allocated value. + The previous two sentences should be removed before publication. - 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: + o "Discovery Reply Object Acknowledgement" (see Section 10), + assigned a value TBD6 from the "RPL Control Codes" space [to be + removed upon publication: http://www.iana.org/assignments/rpl/rpl.xml#control-codes] - [RFC6550]. + [RFC6550]. IANA is requested to allocate TBD6 from the range + 0x00-0x7F to indicate a message without security enabled. The + string TBD6 in this document should be replaced by the allocated + value. The previous two sentences should be removed before + publication. o "Secure Discovery Reply Object Acknowledgement" (see Section 10), - assigned a value of 0x85 from the "RPL Control Codes" space [to be + assigned a value TBD7 from the "RPL Control Codes" space [to be removed upon publication: http://www.iana.org/assignments/rpl/rpl.xml#control-codes] - [RFC6550]. + [RFC6550]. IANA is requested to allocate TBD7 from the range + 0x80-0xFF to indicate a message with security enabled. The string + TBD7 in this document should be replaced by the allocated value. + The previous two sentences should be removed before publication. +------+--------------------------------------------+---------------+ | Code | Description | Reference | +------+--------------------------------------------+---------------+ - | 0x04 | Discovery Reply Object | This document | - | 0x05 | Discovery Reply Object Acknowledgement | This document | - | 0x84 | Secure Discovery Reply Object | This document | - | 0x85 | Secure Discovery Reply Object | This document | + | TBD4 | Discovery Reply Object | This document | + | TBD5 | Secure Discovery Reply Object | This document | + | TBD6 | Discovery Reply Object Acknowledgement | This document | + | TBD7 | Secure Discovery Reply Object | This document | | | Acknowledgement | | +------+--------------------------------------------+---------------+ RPL Control Codes 14.4. New Registry for Upper Layer Protocol Types Inside Data Option The Data Option (see Section 7.2) defines an 8-bit "Upper Layer Protocol" field, for which IANA is requested to create and maintain a new registry titled "Upper Layer Protocol Types Inside RPL Data @@ -1519,22 +1540,22 @@ [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. Barthel, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks", RFC 6551, March 2012. 16.2. Informative References [I-D.ietf-roll-p2p-measurement] Goyal, M., Baccelli, E., Brandt, A., and J. Martocci, "A Mechanism to Measure the Quality of a Point-to-point Route in a Low Power and Lossy Network", - draft-ietf-roll-p2p-measurement-05 (work in progress), - May 2012. + draft-ietf-roll-p2p-measurement-06 (work in progress), + September 2012. [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, December 2007. [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,