--- 1/draft-ietf-roll-p2p-rpl-15.txt 2013-02-03 23:35:04.420041584 +0100 +++ 2/draft-ietf-roll-p2p-rpl-16.txt 2013-02-03 23:35:04.488041180 +0100 @@ -1,26 +1,26 @@ Internet Engineering Task Force M. Goyal, Ed. Internet-Draft University of Wisconsin Intended status: Experimental Milwaukee -Expires: June 15, 2013 E. Baccelli +Expires: August 7, 2013 E. Baccelli M. Philipp INRIA A. Brandt Sigma Designs J. Martocci Johnson Controls - December 12, 2012 + February 3, 2013 Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks - draft-ietf-roll-p2p-rpl-15 + draft-ietf-roll-p2p-rpl-16 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,25 +31,25 @@ 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 15, 2013. + This Internet-Draft will expire on August 7, 2013. Copyright Notice - Copyright (c) 2012 IETF Trust and the persons identified as the + Copyright (c) 2013 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 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 @@ -58,47 +58,47 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Functional Overview . . . . . . . . . . . . . . . . . . . . . 6 6. P2P Route Discovery Mode Of Operation . . . . . . . . . . . . 9 6.1. Setting a P2P Mode DIO . . . . . . . . . . . . . . . . . . 9 7. New RPL Control Message Options . . . . . . . . . . . . . . . 12 - 7.1. P2P Route Discovery Option (P2P-RDO) . . . . . . . . . . . 12 - 7.2. Data Option . . . . . . . . . . . . . . . . . . . . . . . 15 - 8. The Discovery Reply Object (DRO) . . . . . . . . . . . . . . . 16 + 7.1. P2P Route Discovery Option (P2P-RDO) . . . . . . . . . . . 13 + 7.2. Data Option . . . . . . . . . . . . . . . . . . . . . . . 16 + 8. The Discovery Reply Object (DRO) . . . . . . . . . . . . . . . 17 8.1. Secure DRO . . . . . . . . . . . . . . . . . . . . . . . . 19 8.2. Setting a P2P-RDO Carried in a Discovery Reply Object . . 19 - 9. P2P-RPL Route Discovery By Creating a Temporary DAG . . . . . 19 - 9.1. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 19 + 9. P2P-RPL Route Discovery By Creating a Temporary DAG . . . . . 20 + 9.1. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 20 9.2. Trickle Operation For P2P Mode DIOs . . . . . . . . . . . 20 - 9.3. Processing a P2P Mode DIO . . . . . . . . . . . . . . . . 22 + 9.3. Processing a P2P Mode DIO . . . . . . . . . . . . . . . . 23 9.4. Additional Processing of a P2P Mode DIO At An - Intermediate Router . . . . . . . . . . . . . . . . . . . 23 - 9.5. Additional Processing of a P2P Mode DIO At The Target . . 24 - 9.6. Processing a DRO At An Intermediate Router . . . . . . . . 25 - 9.7. Processing a DRO At The Origin . . . . . . . . . . . . . . 26 - 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 - 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 - 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 - 16.1. Normative References . . . . . . . . . . . . . . . . . . . 33 - 16.2. Informative References . . . . . . . . . . . . . . . . . . 34 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 + Intermediate Router . . . . . . . . . . . . . . . . . . . 24 + 9.5. Additional Processing of a P2P Mode DIO At The Target . . 25 + 9.6. Processing a DRO At An Intermediate Router . . . . . . . . 26 + 9.7. Processing a DRO At The Origin . . . . . . . . . . . . . . 28 + 10. The Discovery Reply Object Acknowledgement (DRO-ACK) . . . . . 29 + 11. Packet Forwarding Along a Route Discovered Using P2P-RPL . . . 30 + 12. Interoperability with Core RPL . . . . . . . . . . . . . . . . 30 + 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 + 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 + 14.1. Additions to Mode of Operation . . . . . . . . . . . . . . 32 + 14.2. Additions to RPL Control Message Options . . . . . . . . . 32 + 14.3. Additions to RPL Control Codes . . . . . . . . . . . . . . 33 + 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 + 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 + 16.1. Normative References . . . . . . . . . . . . . . . . . . . 34 + 16.2. Informative References . . . . . . . . . . . . . . . . . . 35 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 1. Introduction Targeting Low power and Lossy Networks (LLNs), the IPv6 Routing Protocol for LLNs (RPL) [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 Destination-Oriented DAG (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 @@ -109,56 +109,64 @@ o The need to pre-establish routes: each potential destination in the network must declare itself as such ahead of the time a source needs to reach it. o The need to route only along the links in the DAG: A DAG is built to optimize the routing cost to reach the root. Restricting P2P routes to use only the in-DAG links may result in significantly suboptimal routes and severe traffic congestion near the DAG root. - This document describes an extension to core RPL that enables an IPv6 - router in the LLN to discover routes to one or more IPv6 routers in - the LLN "on demand", such that the discovered routes meet the - specified metrics constraints, without necessarily going along the - links in an existing DAG. This reactive P2P route discovery - mechanism is henceforth referred to as P2P-RPL. P2P-RPL does not - guarantee discovery of a route. Also, the discovered routes might - not be optimal. However, any discovered routes are guaranteed to - satisfy the desired constraints in terms of the routing metrics and - are thus considered "good enough" from the application's perspective. + This document describes an extension to core RPL (i.e., the RPL + functionality described in [RFC6550]) that enables an IPv6 router in + the LLN to discover routes to one or more IPv6 routers in the LLN "on + demand". The discovered routes may not be the best available but are + guaranteed to meet the specified routing metric constraints. Thus, + such routes are considered "good enough" from the application's + perspective. This reactive P2P route discovery mechanism is + henceforth referred to as P2P-RPL. A mechanism to measure the end-to-end cost of an existing route is specified in [I-D.ietf-roll-p2p-measurement]. As discussed in Section 4, measuring the end-to-end cost of an existing route may help decide whether to initiate the discovery of a better route using P2P-RPL and the metric constraints to be used for this purpose. This document is presented as an Experimental specification to facilitate P2P-RPL's deployment in LLN scenarios where reactive P2P route discovery is considered useful or necessary. It is anticipated that, once sufficient operational experience has been gained, this specification will be revised to progress it on to the Standards Track. Experience reports regarding P2P-RPL implementation and - deployment are encouraged particularly with respect to the values in - the default DODAG Configuration Option (Section 6.1) and the rules - governing Trickle operation (Section 9.2). + deployment are encouraged particularly with respect to: + + o The values in the default DODAG Configuration Option + (Section 6.1); + + o The rules governing Trickle operation (Section 9.2); + + o The utility and the implementation complexity of the Data Option + (Section 7.2) that provides a facility to piggyback time-critical + application data on the routing messages; + + o The utility and the implementation complexity of allowing multiple + Target addresses in a P2P-RPL route discovery. 2. The Use Cases - One use case, common in home and commercial building environments, - involves a device (say a remote control or an airduct controller) - that suddenly needs to communicate with another device (say a lamp or - a humidity sensor) to which it does not already have a route. In - this case, the remote control (or the airduct controller) must be - able to discover a route to the lamp (or the humidity sensor) "on - demand". + One use case, common in home [RFC5826] and commercial building + [RFC5867] environments, involves a device (say a remote control or an + airduct controller) that suddenly needs to communicate with another + device (say a lamp or a humidity sensor) to which it does not already + have a route. In this case, the remote control (or the airduct + controller) must be able to discover a route to the lamp (or the + humidity sensor) "on demand". Another use case, common in a commercial building environment, involves a large LLN deployment where P2P communication along a particular DAG among hundreds (or thousands) of routers creates severe traffic congestion near that DAG's root, and thus routes across this DAG are desirable. Other use cases involve scenarios where energy or latency constraints are not satisfied by the P2P routes along an existing DAG because they involve traversing many more intermediate routers than necessary @@ -178,28 +186,28 @@ Target : The IPv6 router at the other end point of the P2P route(s) to be discovered. A P2P-RPL route discovery can discover routes to multiple Targets at the same time. Intermediate Router: An IPv6 router that is neither the Origin nor a Target. Forward direction: The direction from the Origin to the Target. - Backward direction: The direction from the Target to the Origin. + Reverse direction: The direction from the Target to the Origin. Forward Route: A route in the Forward direction. - Backward Route: A route in the Backward direction. + Reverse Route: A route in the Reverse direction. Bidirectional Route: A route that can be used in both Forward and - Backward directions. + Reverse directions. Source Route: A complete and ordered list of routers that can be used by a packet to travel from a source to a destination node. Hop-by-hop Route: The route characterized by each router on the route using its routing table to determine the next hop on the route. 4. Applicability A route discovery using P2P-RPL may be performed by an Origin when no @@ -244,23 +252,29 @@ discovery by carefully setting the routing constraints, the Trickle parameters (that govern the DIO generation) and the lifetime of the temporary DAG created for the route discovery. A network designer may take into consideration both the benefits (potentially better routes; no need to maintain routes proactively; avoid congestion near the global DAG's root) and costs when using P2P-RPL. The latency associated with a P2P-RPL route discovery again depends on the distance between the Origin and the Target and the Trickle parameters. - Note that the participation in a P2P-RPL route discovery is limited - to the routers with IPv6 addresses that are reachable in both Forward - and Backward directions. + Like core RPL [RFC6550], P2P-RPL operation requires links to have + bidirectional reachability. Routers participating in a P2P-RPL route + discovery must ensure that + + o Links that do not have bidirectional reachability do not become + part of the route being discovered; and + + o IPv6 addresses belonging to egress-only or ingress-only interfaces + do not become part of the route being discovered. 5. Functional Overview This section contains a high level description of P2P-RPL. A P2P-RPL route discovery takes place by forming a DAG rooted at the Origin. As is the case with core RPL, P2P-RPL uses IPv6 link-local multicast DIO messages to establish a DAG. However, unlike core RPL, this DAG is temporary in nature and routers in the DAG leave once the DAG's life time is over. The sole purpose of DAG creation is to @@ -269,45 +283,44 @@ for itself in the DAG and ignores the subsequent DIOs received from lower (higher in numerical value) ranked neighbors. Thus, the route discovery messages propagate away from the Origin rather than return back to it. As in core RPL, DIO generation at a router is controlled by a Trickle timer [RFC6206] that allows a router to avoid generating unnecessary messages while providing protection against packet loss. P2P-RPL also uses the routing metrics [RFC6551], objective functions and packet forwarding framework [RFC6554][RFC6553] developed for core RPL. - An Origin may use P2P-RPL to discover routes to one or more Targets + An Origin may use P2P-RPL to discover routes to one or more Target(s) identified by one or more unicast/multicast addresses. P2P-RPL allows for the discovery of one Hop-by-hop Route or up to four Source - Routes per Target. P2P-RPL allows an Origin to piggyback time- - critical application data on the DIO messages for delivery to the - Target(s). P2P-RPL does not guarantee discovery of a route to a - Target. Also, the discovered routes might not be the best available. - However, any discovered routes are guaranteed to satisfy the desired - constraints in terms of the routing metrics and are thus considered - "good enough" from the application's perspective. + Routes per Target. The discovered routes are guaranteed to meet the + specified routing metric constraints but may not be the best + available. P2P-RPL may fail to discover any route if the specified + routing constraints are overly strict. P2P-RPL allows an Origin to + piggyback time-critical application data on the DIO messages for + delivery to the Target(s). - A P2P-RPL route discovery takes place by forming a temporary DAG - rooted at the Origin. The DIOs, used to create the temporary DAG, - are identified by a new Mode of Operation (P2P Route Discovery mode - defined in Section 6). The DIOs, listing the P2P Route Discovery - mode as the Mode of Operation, are henceforth referred to as the P2P - mode DIOs. A P2P mode DIO always carries one P2P Route Discovery + The Origin initiates a P2P-RPL route discovery by forming a temporary + DAG rooted at itself. The DIOs used to create the temporary DAG are + identified by a new Mode of Operation (P2P Route Discovery mode + defined in Section 6). The DIOs listing the P2P Route Discovery mode + as the Mode of Operation are henceforth referred to as the P2P mode + DIOs. A P2P mode DIO always carries exactly one P2P Route Discovery Option (defined in Section 7.1) in which the Origin specifies the following information: o The IPv6 address of a Target. This could be a unicast address or - a multicast one. Any additional Targets may be specified by + a multicast address. Any additional Targets may be specified by including one or more RPL Target Options [RFC6550] inside the DIO. - o The nature of the route(s) to be discovered: hop-by-hop or Source + o The nature of the route(s) to be discovered: Hop-by-hop or Source Routes. This specification allows for the discovery of one Hop- by-hop Route or up to four Source Routes per Target. o The desired number of routes (if Source Routes are being discovered). o Whether the Target(s) should send Discovery Reply Object (DRO) messages (defined in Section 8) back to the Origin on receiving a DIO message. A DRO message carries a discovered Source Route back to the Origin or establishes a Hop-by-hop Route between the Origin @@ -327,56 +340,55 @@ * The constraints that the discovered route must satisfy. These constraints also limit how far the DIOs message may travel. o One or more RPL Target options to specify additional unicast or multicast Targets. o One Data Option (defined in Section 7.2) to carry time-critical application-level data to be delivered to the Target(s). As the routers join the temporary DAG, they keep track of the best - (partial) route(s) they have seen and advertise these routes, along - with the corresponding routing metrics, in their P2P mode DIOs. A - router, including the Target(s), discards a received P2P mode DIO if - the aggregated routing metrics on the route advertised by the DIO do - not satisfy the listed constraints. These constraints can be used to - limit the propagation of P2P mode DIO messages. A router may also - discard a received P2P mode DIO if it does not wish to be a part of - the discovered route due to limited resources or due to policy - reasons. + route(s) (so far from the Origin) they have seen and advertise these + routes, along with the corresponding routing metrics, in their P2P + mode DIOs. A router, including the Target(s), discards a received + P2P mode DIO if the aggregated routing metrics on the route + advertised by the DIO do not satisfy the listed constraints. These + constraints can be used to limit the propagation of P2P mode DIO + messages. A router may also discard a received P2P mode DIO if it + does not wish to be a part of the discovered route due to limited + resources or due to policy reasons. When a Target receives a P2P mode DIO, it forwards the data in the - Data Option, if present, to the higher layer. Since the IPv6 - addresses making up the discovered route are reachable in both - Forward and Backward directions (Section 7.1), the Target may - remember the discovered route for use as a Source Route to reach the - Origin. If the Origin has requested DRO messages to be sent back, - the Target may select the route contained in the received DIO for - further processing as described next. This document does not specify - a particular method for the Target to use to select a route for - further processing. Example methods include selecting any route that - meets the constraints or selecting the best route(s) discovered over - a certain time period. + Data Option, if present, to the higher layer. Since the links in the + discovered route have bidirectional reachability (Section 7.1), the + Target may remember the discovered route for use as a Source Route to + reach the Origin. If the Origin has requested DRO messages to be + sent back, the Target may select the route contained in the received + DIO for further processing as described next. This document does not + specify a particular method for the Target to use to select a route + for further processing. Example methods include selecting any route + that meets the constraints or selecting the best route(s) discovered + over a certain time period. - If one or more Source Routes are being discovered, the Target sends - the selected Source Routes to the Origin via DRO messages with one + If one or more Source Route(s) are being discovered, the Target sends + the selected Source Route(s) to the Origin via DRO messages with one DRO message carrying one discovered route. On receiving a DRO message, the Origin stores the discovered route in its memory. This specification allows the Origin to discover up to four Source Routes per Target, thereby allowing the Origin to have sufficient ready-to- use alternatives should one or more of these routes fail. If a Hop- by-hop Route is being discovered, the Target sends a DRO message containing the selected route to the Origin. The DRO message travels back to the Origin along the selected route, establishing state for - this route in the routers on the path. The Target may include a Data - Option in a DRO message to deliver any time-critical application data - to the Origin. + the Forward Route in the routers on the path. The Target may include + a Data Option in a DRO message to deliver any time-critical + application data to the Origin. The Target may request the Origin to acknowledge the receipt of a DRO message by sending back a DRO Acknowledgement (DRO-ACK) message (defined in Section 10). The Origin unicasts a DRO-ACK message to the Target. If the Target does not receive the requested DRO-ACK within a certain time interval of sending a DRO, it resends the DRO message (up to a certain number of times) carrying the same route as before. The use of trickle timers to delay the propagation of DIO messages @@ -389,45 +401,53 @@ 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 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 + MUST carry exactly 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 - Origin MUST NOT reuse the RPLInstanceID used in a previous route - discovery to this Target if the previously discovered routes might - still exist. The Default Lifetime and Lifetime Unit parameters in - the DODAG Configuration Option specify the lifetime of the state - the routers, including the Origin and the Target, maintain for a - hop-by-hop or a Source Route discovered using P2P-RPL. Thus, an - Origin can safely reuse an RPLInstanceID to discover a new route - to a Target if the lifetime of all previously discovered routes to - this Target using this RPLInstanceID is over. + Section 5.1 of [RFC6550]. The Origin MUST NOT reuse an + RPLInstanceID for a route discovery if its previous route + discovery using this RPLInstanceID might still be going on. As + described in Section 7.1, the Life Time parameter in the P2P Route + Discovery Option specifies the time duration the route discovery + lasts. So, the Origin MUST NOT reuse an RPLInstanceID in a route + discovery until the Life Time of its previous route discovery + using this RPLInstanceID is over. When initiating a new route + discovery to a particular Target, the Origin MUST NOT reuse the + RPLInstanceID used in a previous route discovery to this Target if + the previously discovered routes might still exist. The Default + Lifetime and Lifetime Unit parameters in the DODAG Configuration + Option specify the lifetime of the state the routers, including + the Origin and the Target, maintain for a Hop-by-hop or a Source + Route discovered using P2P-RPL. Thus, an Origin can safely reuse + an RPLInstanceID to discover a new route to a Target if the + lifetime of all previously discovered routes to this Target using + this RPLInstanceID is over. o Version Number: MUST be set to zero. The temporary DAG used for P2P-RPL route discovery does not exist long enough to have new - versions. + versions (the Life Time parameter inside the P2P Route Discovery + Option, defined in Section 7.1, specifies the life time of the + temporary DAG). o Grounded (G) Flag: This flag MUST be set to one. Unlike a global RPL instance, the concept of a floating DAG, used to provide connectivity within a sub-DAG detached from a grounded DAG, does not apply to a local RPL instance. Hence, an Origin MUST always set the G flag to one when initiating a P2P-RPL route discovery. Further, clause 3 of Section 8.2.2.2 in [RFC6550] does not apply and a node MUST NOT initiate a new DAG if it does not have any parent left in a P2P-RPL DAG. @@ -456,21 +476,21 @@ disable local repair of the temporary DAG. A received P2P mode DIO MUST be discarded if the MaxRankIncrease parameter inside the DODAG Configuration Option is not zero. o The Origin SHOULD set the Trickle parameters (DIOIntervalDoublings, DIOIntervalMin, DIORedundancyConstant) as recommended in Section 9.2. o The Origin sets the Default Lifetime and Lifetime Unit parameters to indicate the lifetime of the state the routers, including the - Origin and the Target(s), maintain for a hop-by-hop or a Source + Origin and the Target(s), maintain for a Hop-by-hop or a Source Route discovered using P2P-RPL. o The Origin sets the other fields in the DODAG Configuration Option, including the OCP identifying the Objective function, in the desired fashion as per the rules described in [RFC6550]. o An Intermediate Router (or a Target) MUST set various fields in the DODAG Configuration Option in the outgoing P2P mode DIOs to the values they had in the incoming P2P mode DIOs for this DAG. @@ -546,78 +566,79 @@ 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 = TBD2 | Option Length |R|H| N | Compr | L |MaxRank/NH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | - | Target | + | TargetAddr | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 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: + MUST carry exactly one P2P-RDO. A P2P-RDO consists of the following + fields: 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 one. The Origin sets this flag to one if it desires Hop-by-hop Routes. The Origin sets this flag to zero if it desires Source Routes. This specification allows for the establishment of one - hop-by-hop route or up to four Source Routes per Target. The Hop- + Hop-by-hop route or up to four Source Routes per Target. The Hop- by-hop Route is established in the Forward direction, i.e. from the Origin to the Target. This specification does not allow for - the establishment of Hop-by-hop Routes in the Backward direction. + the establishment of Hop-by-hop Routes in the Reverse direction. o Number of Routes (N): This field is valid only if the R flag is one and H flag is zero, i.e. the Targets are allowed to generate DRO messages carrying discovered Source Routes back to the Origin. In this case, the value in the N field plus one indicates the number of Source Routes that each Target should convey to the Origin. When Hop-by-hop Routes are being discovered, the N field MUST be set to zero on transmission and ignored on reception. o Compr: 4-bit unsigned integer indicating the number of prefix octets that are elided from the Target field and the Address vector. For example, Compr value will be zero if full IPv6 addresses are carried in the Target field and the Address vector. - o Life Time (L): A 2-bit field that indicates the minimum life time - of the temporary DAG, i.e., the minimum duration a router joining - the temporary DAG MUST maintain its membership in the DAG. The + o Life Time (L): A 2-bit field that indicates the life time of the + temporary DAG, i.e., the exact duration a router joining the + temporary DAG MUST maintain its membership in the DAG. The mapping between the values in this field and the life time of the temporary DAG is as follows: * 0x00: 1 second; * 0x01: 4 seconds; + * 0x02: 16 seconds; * 0x03: 64 seconds; The Origin sets this field based on its expectation regarding the time required for the route discovery to complete, which includes the time required for the DIOs to reach the Target(s) and the DROs to travel back to the Origin. The time required for the DIOs to reach the Target(s) would in turn depend on the Trickle parameters (Imin and the redundancy constant) as well as the expected @@ -616,76 +637,76 @@ * 0x03: 64 seconds; The Origin sets this field based on its expectation regarding the time required for the route discovery to complete, which includes the time required for the DIOs to reach the Target(s) and the DROs to travel back to the Origin. The time required for the DIOs to reach the Target(s) would in turn depend on the Trickle parameters (Imin and the redundancy constant) as well as the expected distance (in terms of hops and/or ETX) to the Target(s). While deciding the temporary DAG's lifetime, the Origin should also take - in account the fact that all nodes joining the temporary DAG would - need to stay in the DAG for at least this much time. + in account the fact that all routers joining the temporary DAG + would need to stay in the DAG for this much time. o MaxRank/NH: * When a P2P-RDO is included in a P2P mode DIO, this field indicates the upper limit on the integer portion of the rank (calculated using the DAGRank() macro defined in [RFC6550]) that a router may have in the temporary DAG being created. An Intermediate Router MUST NOT join a temporary DAG being created by a P2P mode DIO if the integer portion of its rank would be equal to or higher (in numerical value) than the MaxRank limit. A Target can join the temporary DAG at a rank whose integer portion is equal to the MaxRank. A router MUST discard a received P2P mode DIO if the integer part of the advertized rank equals or exceeds the MaxRank limit. A value 0 in this field indicates that the MaxRank is infinity. * When a P2P-RDO is included in a DRO message, this field indicates the index of the next hop address inside the Address vector. - o Target: An IPv6 address of the Target after eliding Compr number - of prefix octets. When the P2P-RDO is included in a P2P mode DIO, - this field may contain a unicast address or a multicast one. Any - additional Target addresses can be specified by including one or - more RPL Target Options [RFC6550] in the DIO. When the P2P-RDO is - included in a DRO, this field MUST contain a unicast IPv6 address - of the Target generating the DRO. + o TargetAddr: An IPv6 address of the Target after eliding Compr + number of prefix octets. When the P2P-RDO is included in a P2P + mode DIO, this field may contain a unicast address or a multicast + address. Any additional Target addresses can be specified by + including one or more RPL Target Options [RFC6550] in the DIO. + When the P2P-RDO is included in a DRO, this field MUST contain a + unicast IPv6 address of the Target generating the DRO. - o Address[1..n]: A vector of IPv6 addresses representing a (partial) - route in the Forward direction: + o Address[1..n]: A vector of IPv6 addresses representing a complete + route so far in the Forward direction: * Each element in the Address vector has size (16 - Compr) octets and MUST contain a valid IPv6 address with first Compr octets elided. * The total number of elements inside the Address vector is given by n = (Option Length - 2 - (16 - Compr))/(16 - Compr). - * The IPv6 addresses in the Address vector MUST be reachable in - both Forward and Backward directions. Reachability in the - Backward direction allows a DRO message to use the route - accumulated in the Address vector to travel from the Target to - the Origin. + * IPv6 addresses of ingress-only (or egress-only) router + interfaces MUST NOT be added to the Address vector. This + allows the route accumulated in the Address vector to be a + Bidirectional Route that can be used by a Target to send a DRO + message to the Origin. * The Address vector MUST carry the accumulated route in the Forward direction, i.e., the first element in the Address vector must contain the IPv6 address of the router next to the Origin and so on. * The Origin and Target addresses MUST NOT be included in the Address vector. * A router adding its address to the vector MUST ensure that any - of its addresses do not already exist in the vector. A router + of its addresses do not already exist in the vector. A Target 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -745,24 +766,25 @@ 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 Target to the Origin in a Data Option. A DRO message MUST carry one - (and only one) P2P-RDO whose Target field MUST contain a unicast IPv6 - address of the Target that generated the DRO. A DRO message travels - from the Target to the Origin via link-local multicast along the - route specified inside the Address vector in the P2P-RDO. + (and only one) P2P-RDO whose TargetAddr field MUST contain a unicast + IPv6 address of the Target that generates the DRO. A DRO message + travels from the Target to the Origin via link-local multicast along + the route specified inside the Address vector in the P2P-RDO, as + included in the DRO. 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 |S|A|Seq| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | DODAGID | | | | | @@ -794,21 +816,23 @@ * SHOULD cancel any pending DIO transmission for this temporary DAG. Note that the Stop flag serves to stop further DIO generation/ processing for a P2P-RPL route discovery but it does not affect the processing of DRO messages at either the Origin or the Intermediate Routers. In other words, a router (the Origin or an Intermediate Router) MUST continue to process the DRO messages even if an earlier DRO message (with the same RPLInstanceID and - DODAGID fields) had the Stop flag set to one. + DODAGID fields) had the Stop flag set to one. When set to zero, + this flag does not imply any thing and MUST be ignored on + reception. o Ack Required (A): This flag, when set to one by the Target, indicates that the Origin MUST unicast a DRO-ACK message (defined in Section 10) to the Target when it receives the DRO. o Sequence Number (Seq): This 2-bit field indicates the sequence number for the DRO. This field is relevant when the A flag is set to one, i.e., the Target requests an acknowledgement from the Origin for a received DRO. The Origin includes the RPLInstanceID, the DODAGID and the Sequence Number of the received DRO inside the @@ -871,48 +895,47 @@ transmission and ignored on reception. o Life Time (L): This field MUST be set to zero on transmission and ignored on reception. o MaxRank/NH: This field indicates the index of the next hop address in the Address vector. When a Target generates a DRO message, the NH field is set to n = (Option Length - 2 - (16 - Compr))/(16 - Compr). - o Target: This field MUST contain a unicast IPv6 address of the + o TargetAddr: This field MUST contain a unicast IPv6 address of the Target generating the DRO. o Address[1..n]: The Address vector MUST contain a complete route between the Origin and the Target such that the first element in the vector contains the IPv6 address of the router next to the Origin and the last element contains the IPv6 address of the router next to the Target. 9. P2P-RPL Route Discovery By Creating a Temporary DAG This section details the P2P-RPL route discovery operation. 9.1. Joining a Temporary DAG All the routers participating in a P2P-RPL route discovery, including the Origin and the Target(s), MUST join the temporary DAG being created for the purpose. When a router joins a temporary DAG - advertized by a P2P mode DIO, it SHOULD maintain its membership in - the temporary DAG for the suggested Life Time duration listed in the - P2P-RDO. The only purpose of a temporary DAG's existence is to - facilitate the P2P-RPL route discovery process. The temporary DAG - MUST NOT be used to route packets. A router SHOULD detach from the - temporary DAG once the duration of its membership in the DAG has - exceeded the DAG's life time. After receiving a DRO with the Stop - flag set to one, a router SHOULD NOT send or receive any more DIOs - for this temporary DAG and SHOULD also cancel any pending DIO - transmission. + advertized by a P2P mode DIO, it MUST maintain its membership in the + temporary DAG for the Life Time duration listed in the P2P-RDO. The + only purpose of a temporary DAG's existence is to facilitate the P2P- + RPL route discovery process. The temporary DAG MUST NOT be used to + route packets. A router MUST detach from the temporary DAG once the + duration of its membership in the DAG has reached the DAG's life + time. After receiving a DRO with the Stop flag set to one, a router + SHOULD NOT send or receive any more DIOs for this temporary DAG and + SHOULD also cancel any pending DIO transmission. 9.2. Trickle Operation For P2P Mode DIOs An RPL router uses a Trickle timer [RFC6206] to control DIO transmissions. The Trickle control of DIO transmissions provides quick resolution of any "inconsistency" while avoiding redundant DIO transmissions. The Trickle algorithm also imparts protection against loss of DIOs due to inherent lack of reliability in LLNs. When controlling the transmissions of a P2P mode DIO, a Trickle timer SHOULD follow the following rules: @@ -935,22 +958,22 @@ o The receipt of a P2P mode DIO is considered "consistent" if the source of the DIO is not a parent in the temporary DAG and either of the following conditions is true: * The DIO advertises a better route than the router but does not allow the router to advertise a better route itself; or * The DIO advertises a route as good as the route (to be) advertised by the router. - Note that Trickle algorithm's DIO suppression rules are in effect - at all times. Hence, a P2P-RPL router may suppress a DIO + Note that the Trickle algorithm's DIO suppression rules are in + effect at all times. Hence, a P2P-RPL router may suppress a DIO transmission even if it has not made any DIO transmission yet. o The receipt of a P2P mode DIO, that advertises a worse route than what the router advertises (or would advertise when it gets a chance to generate its DIO), is considered neither "consistent" nor "inconsistent", i.e., the receipt of such a DIO has no impact on the Trickle operation. o The Imin parameter SHOULD be set taking in account the connectivity within the network. For highly connected networks, a @@ -981,32 +1004,36 @@ inconsistent event and would lead to resetting of Trickle timer duration to the Imin value. Given the temporary nature of the DAGs used in P2P-RPL, Trickle timer may not get a chance to increase much. o The recommended value of redundancy constant "k" is 1. With this value of "k", a DIO transmission will be suppressed if the router receives even a single "consistent" DIO during a timer interval. This setting for the redundancy constant is designed to reduce the number of messages generated during a route discovery process and - is suitable for environments with low or moderate packet loss - rates. A higher value for the redundancy constant may be more - suitable in environments with high packet loss rates or in - deployments where specific destinations are reachable only through - specific intermediate routers (and hence these intermediate - routers should not suppress their DIOs). A particular deployment - should take in account typical loss rates, the topological - characteristics of the LLN (the average/typical connectivity of - the nodes and the variance in connectivity: whether some - destinations have only a small set of neighbors) and the need to - contain the message overhead of the route discovery when deciding - the value of the redundancy constant. + is suitable for the environments with low or moderate packet loss + rates. However, this setting may result in an increase in the + time required for the route discovery process to complete. A + higher value for the redundancy constant may be more suitable in + + * Environments with high packet loss rates; or + + * Deployments where the time required for the route discovery + process to complete needs to be as small as possible; or + + * Deployments where specific destinations are reachable only + through specific intermediate routers (and hence these + intermediate routers should not suppress their DIOs). + + A particular deployment should take in account the above mentioned + factors when deciding the value of the redundancy constant. Individual P2P-RPL deployments are encouraged to share their experience with these rules with ROLL working group to help guide the development of standards track version of the protocol. 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 @@ -1019,38 +1046,40 @@ The following rules for processing a received P2P mode DIO apply to both Intermediate Routers and the Target. A router SHOULD discard a received P2P mode DIO with no further processing if it does not have bidirectional reachability with the neighbor that generated the received DIO. Note that bidirectional reachability does not mean that the link must have the same values for a routing metric in both directions. A router SHOULD calculate the values of the link-level routing metrics included in the received - DIO taking in account the metric's value in both Forward and Backward + DIO taking in account the metric's value in both Forward and Reverse directions. Bidirectional reachability along a discovered route allows the Target to use this route to reach the Origin. In particular, the DRO messages travel from the Target to the Origin along a discovered route. A router MUST discard a received P2P mode DIO with no further processing: - o If the DIO advertises INFINITE_RANK as defined in [RFC6550]. + o If the DIO advertises INFINITE_RANK as defined in Section 17 of + [RFC6550]. o If the integer part of the rank advertised in the DIO equals or exceeds the MaxRank limit listed in the P2P Route Discovery Option. - o If the router cannot evaluate the mandatory route constraints - listed in the DIO or if the routing metric values do not satisfy - one or more of the mandatory constraints. + o If the routing metric values do not satisfy one or more of the + mandatory route constraints listed in the DIO or if the router + cannot evaluate the mandatory route constraints, e.g., if the + router does not support the metrics used in the constraints. o If the router previously received a DRO message with the same RPLInstanceID and DODAGID as the received DIO and with the Stop flag set to one. The router MUST check the Target addresses listed in the P2P-RDO and any RPL Target Options included in the received DIO. If one of its IPv6 addresses is listed as a Target address or if it belongs to the multicast group specified as one of the Target addresses, the router considers itself a Target and processes the received DIO as specified @@ -1075,31 +1104,32 @@ would allow the router to advertise a better route than before. Accordingly, the router SHOULD consider this DIO as consistent/ inconsistent from Trickle perspective as described in Section 9.2. Note that the route comparison in a P2P-RPL route discovery is performed using the parent selection rules of the OF in use as specified in Section 14 of RPL [RFC6550]. If the received DIO would allow the router to advertise a better route, the router MUST remember the route advertised (inside the P2P-RDO) in the DIO (after adding its own IPv6 address to the route) for inclusion in its future DIOs. When an Intermediate Router adds itself to a - route, it MUST ensure that the IPv6 address added to the route is - reachable in both Forward and Backward directions. To improve the - diversity of the routes being discovered, an Intermediate Router - SHOULD keep track of multiple partial routes to be advertised in - the P2P-RDO inside its DIO. When the router generates its DIO, it - SHOULD randomly select the partial route to be included in the - P2P-RDO. Note that the route accumulation in a P2P mode DIO MUST - take place even if the Origin does not want any DRO messages to be - generated (i.e., the R flag inside the P2P-RDO is set to zero). - This is because the Target may still be able to use the - accumulated route as a source route to reach the Origin. + route, it MUST ensure that the IPv6 address added to the route + does not belong to an ingress-only or an egress-only interface. + To improve the diversity of the routes being discovered, an + Intermediate Router SHOULD keep track of multiple routes (as long + as all these routes are the best seen so far), one of which SHOULD + be selected in a uniform random manner for inclusion in the P2P- + RDO inside the router's next DIO. Note that the route + accumulation in a P2P mode DIO MUST take place even if the Origin + does not want any DRO messages to be generated (i.e., the R flag + inside the P2P-RDO is set to zero). This is because the Target + may still be able to use the accumulated route as a source route + to reach the Origin. o The router MUST copy any Data Option (to be included in its future DIO transmissions) if the received DIO comes from a parent and is the first parent-originated DIO received with a Data Option inside. 9.5. Additional Processing of a P2P Mode DIO At The Target The Target MUST determine if the received DIO contains a Data Option and deliver the data to the specified upper layer protocol unless it @@ -1147,35 +1177,35 @@ based on the characteristics of individual deployments. Note that all DRO transmissions and retransmissions MUST take place while the Target is still a part of the temporary DAG created for the route discovery. A Target MUST NOT transmit a DRO if it no longer belongs to this DAG. The Target MAY set the Stop flag inside the DRO message to one if o this router is the only Target specified in the corresponding DIO, i.e., the corresponding DIO specified a unicast address of the - router as the Target inside the P2P-RDO with no additional Targets - specified via RPL Target Options; and + router as the TargetAddr inside the P2P-RDO with no additional + Targets specified via RPL Target Options; and o the Target has already selected the desired number of routes. The Target MAY include a Metric Container Option in the DRO message. This Metric Container contains the end-to-end routing metric values for the route specified in the P2P-RDO. The Target MAY include one Data Option in the DRO message to carry time-critical application data for the Origin, subject to the conditions listed in Section 8. The Target MUST transmit the DRO message via a link-local multicast. A Target MUST NOT forward a P2P mode DIO any further if no other Targets are to be discovered, i.e., if a unicast IPv6 address (of - this Target) is specified as the Target inside the P2P-RDO and no + this Target) is specified as the TargetAddr inside the P2P-RDO and no additional Targets are specified via RPL Target Options inside the DIOs for this route discovery. Otherwise, the Target MUST generate DIOs for this route discovery as an Intermediate Router would. 9.6. Processing a DRO At An Intermediate Router If the DODAGID field in the received DRO does not list a router's own IPv6 address, the router considers itself an Intermediate Router and MUST process the received message in the following manner: @@ -1190,58 +1220,68 @@ o The router MUST ignore any Metric Container and Data Options contained in the DRO message. o If Address[NH] element inside the P2P-RDO lists the router's own unicast IPv6 address, the router is a part of the route carried in the P2P-RDO. In this case, the router MUST do the following: * To prevent loops, the router MUST discard the DRO message with no further processing if the Address vector in the P2P-RDO includes multiple IPv6 addresses assigned to the router's - interfaces and if such addresses do not appear back to back - inside the Address vector. + interfaces. * If the H flag inside the P2P-RDO is one, the router MUST store - the state for the forward hop-by-hop route carried inside the + the state for the Forward Hop-by-hop route carried inside the P2P-RDO. This state consists of: + The RPLInstanceID and the DODAGID fields of the DRO. - + The route's destination, the Target (identified by Target - field inside P2P-RDO). + + The route's destination, the Target (identified by + TargetAddr field inside P2P-RDO). + The IPv6 address of the next hop, Address[NH+1] (unless NH value equals the number of elements in the Address vector, in which case the Target itself is the next hop). - This hop-by-hop routing state MUST expire at the end of the + This Hop-by-hop routing state MUST expire at the end of the lifetime specified by the Default Lifetime and Lifetime Unit parameters inside the DODAG Configuration Option used in P2P mode DIOs for this route discovery. - * If the router already maintains a hop-by-hop state listing the + * If the router already maintains a Hop-by-hop state listing the Target as the destination and carrying same RPLInstanceID and DODAGID fields as the received DRO and the next hop information in the state does not match the next hop indicated in the received DRO, the router MUST discard the DRO message with no - further processing. + further processing. Note that this situation would occur in + the following two cases: + + + When the route listed in the Address vector inside the P2P- + RDO contains a previously undetected loop. In this case, + the rule above causes the DRO messages to be discarded. + + + When a Hop-by-hop Route between the Origin and the Target, + previously established using the same RPLInstanceID and + DODAGID as the route currently being established, still + exists and at least partially overlaps the route currently + being established. * The router MUST decrement the NH field inside the P2P-RDO and send the DRO message further via link-local multicast. 9.7. Processing a DRO At The Origin When a router receives a DRO message that lists its IPv6 address in the DODAGID field, the router recognizes itself as the Origin for the corresponding P2P-RPL route discovery, notes the Target that - originated this message (from the Target field inside the P2P-RDO) - and processes the message in the following manner: + originated this message (from the TargetAddr field inside the P2P- + RDO) and processes the message in the following manner: o The Origin MUST discard the received DRO with no further processing if it no longer belongs to the temporary DAG identified by the RPLInstanceID and the DODAGID fields in the DRO. o If the received DRO contains a Data Option and if it has not already done so following the receipt of an earlier DRO from this Target, the Origin MUST deliver the data inside the Data Option to the specified upper layer protocol. @@ -1254,21 +1294,21 @@ and the Origin MUST store this Source Route in its memory. The lifetime of this Source Route is specified by the Default Lifetime and Lifetime Unit parameters inside the DODAG Configuration Option in the P2P mode DIOs used for this route discovery. This lifetime could be extended (or shortened) appropriately following a hint from an upper-layer protocol. o If the P2P-RDO inside the DRO has the H flag set to 1, the DRO message is establishing a Hop-by-hop Route to this Target and the Origin MUST store in its memory the state for this Hop-by-hop - Route in the manner described in Section 9.6. This hop-by-hop + Route in the manner described in Section 9.6. This Hop-by-hop routing state MUST expire at the end of the lifetime specified by the Default Lifetime and Lifetime Unit parameters inside the DODAG Configuration Option used in P2P mode DIOs for this route discovery. The standards track version of P2P-RPL may consider specifying a signaling mechanism that will allow the Origin to extend (or shorten) the lifetime of a P2P-RPL Hop-by-hop Route following a suitable hint from an upper-layer protocol. o If the received DRO message contains one or more Metric Container Options, the Origin MAY store the values of the routing metrics @@ -1555,24 +1595,24 @@ Lossy Networks", RFC 6550, March 2012. [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-06 (work in progress), - September 2012. + Mechanism to Measure the Routing Metrics along a Point-to- + point Route in a Low Power and Lossy Network", + draft-ietf-roll-p2p-measurement-08 (work in progress), + January 2013. [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,