diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc6997.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc6997.txt')
| -rw-r--r-- | doc/rfc/rfc6997.txt | 2243 |
1 files changed, 2243 insertions, 0 deletions
diff --git a/doc/rfc/rfc6997.txt b/doc/rfc/rfc6997.txt new file mode 100644 index 0000000..1446e2c --- /dev/null +++ b/doc/rfc/rfc6997.txt @@ -0,0 +1,2243 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Goyal, Ed. +Request for Comments: 6997 Univ. of Wisconsin Milwaukee +Category: Experimental E. Baccelli +ISSN: 2070-1721 M. Philipp + INRIA + A. Brandt + Sigma Designs + J. Martocci + Johnson Controls + August 2013 + + + Reactive Discovery of Point-to-Point Routes + in Low-Power and Lossy Networks + +Abstract + + This document specifies a point-to-point route discovery mechanism, + complementary to the Routing Protocol for Low-power and Lossy + Networks (RPL) core functionality. This mechanism allows an IPv6 + router to discover "on demand" routes to one or more IPv6 routers in + a Low-power and Lossy Network (LLN) such that the discovered routes + meet specified metrics constraints. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Engineering + Task Force (IETF). It represents the consensus of the IETF + community. It has received public review and has been approved for + publication by the Internet Engineering Steering Group (IESG). Not + all documents approved by the IESG are a candidate for any level of + Internet Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6997. + + + + + + + + + + +Goyal, et al. Experimental [Page 1] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + +Copyright Notice + + 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 + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Goyal, et al. Experimental [Page 2] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + +Table of Contents + + 1. Introduction ....................................................4 + 2. The Use Cases ...................................................4 + 3. Terminology .....................................................5 + 4. Applicability ...................................................6 + 5. Functional Overview .............................................7 + 6. P2P Route Discovery Mode of Operation ..........................10 + 6.1. Setting a P2P Mode DIO ....................................10 + 7. P2P Route Discovery Option (P2P-RDO) ...........................15 + 8. The P2P Discovery Reply Object (P2P-DRO) .......................18 + 8.1. Secure P2P-DRO ............................................20 + 8.2. Setting a P2P-RDO Carried in a P2P Discovery Reply + Object ....................................................21 + 9. P2P-RPL Route Discovery by Creating a Temporary DAG ............21 + 9.1. Joining a Temporary DAG ...................................21 + 9.2. Trickle Operation for P2P Mode DIOs .......................22 + 9.3. Processing a P2P Mode DIO .................................24 + 9.4. Additional Processing of a P2P Mode DIO at an + Intermediate Router .......................................26 + 9.5. Additional Processing of a P2P Mode DIO at the Target .....27 + 9.6. Processing a P2P-DRO at an Intermediate Router ............28 + 9.7. Processing a P2P-DRO at the Origin ........................30 + 10. The P2P Discovery Reply Object Acknowledgement (P2P-DRO-ACK) ..31 + 11. Secure P2P-RPL Operation ......................................32 + 12. Packet Forwarding along a Route Discovered Using P2P-RPL ......33 + 13. Interoperability with Core RPL ................................34 + 14. Security Considerations .......................................34 + 15. IANA Considerations ...........................................36 + 15.1. Additions to Mode of Operation ...........................36 + 15.2. Additions to RPL Control Message Options .................36 + 15.3. Additions to RPL Control Codes ...........................36 + 16. Known Issues and Future Work ..................................37 + 17. Acknowledgements ..............................................37 + 18. References ....................................................38 + 18.1. Normative References .....................................38 + 18.2. Informative References ...................................38 + + + + + + + + + + + + + + +Goyal, et al. Experimental [Page 3] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + +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 are 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 only along the links in the DAG. Such point-to-point (P2P) + routing functionality may not be sufficient for several home + automation [RFC5826] and building automation [RFC5867] applications, + due to the following reasons: + + 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 (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 [RFC6998]. As discussed in Section 4, measuring the + end-to-end cost of an existing route may help in deciding whether to + initiate the discovery of a better route using P2P-RPL and the metric + constraints to be used for this purpose. + +2. The Use Cases + + One use case, common in home [RFC5826] and commercial building + [RFC5867] environments, involves a device (say, a remote control) + that suddenly needs to communicate with another device (say, a lamp) + to which it does not already have a route (and whose network address + it knows a priori). In this case, the remote control must be able to + discover a route to the lamp "on demand". + + + + + +Goyal, et al. Experimental [Page 4] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + + 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. In this case, it is + desirable to discover direct routes between various source- + destination pairs that do not pass through the DAG's root. + + 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 routers than necessary to reach the + destination. + +3. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + + Additionally, this document uses terminology from [RFC6550] and + [RFC6554]. Further terminology may be found in [ROLL-TERMS]. This + document introduces the following terms: + + Origin: The IPv6 router initiating the P2P-RPL route discovery. + + 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. + + Reverse direction: The direction from the Target to the Origin. + + Forward Route: A route in the Forward direction. + + Reverse Route: A route in the Reverse direction. + + Bidirectional Route: A route that can be used in both Forward and + Reverse directions. + + Ingress-only Interface: A network interface that can only receive + packets. + + Egress-only Interface: A network interface that can only send + packets. + + + +Goyal, et al. Experimental [Page 5] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + + 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. + + RPL Security Configuration: The values for the Counter is Time, + Security Algorithm, Key Identifier Mode, and Security Level + fields, as defined in Section 6.1 of [RFC6550], inside the + Security section of a secure RPL control message. + +4. Applicability + + A route discovery using P2P-RPL may be performed by an Origin when no + route exists between itself and the Target(s) or when the existing + routes do not satisfy the application requirements. P2P-RPL is + designed to discover Hop-by-hop or Source Routes to one or more + Targets such that the discovered routes meet the specified + constraints. In some application contexts, the constraints that the + discovered routes must satisfy are intrinsically known or can be + specified by the application. For example, an Origin that expects + its Targets to be less than 5 hops away may use "hop-count < 5" as + the constraint. In other application contexts, the Origin may need + to measure the cost of the existing route to a Target to determine + the constraints. For example, an Origin that measures the total + expected transmission count (ETX) along its current route to a Target + to be 20 may use "ETX < x*20", where x is a fraction that the Origin + chooses, as the constraint. A mechanism to measure the cost of an + existing route between two IPv6 routers is specified in [RFC6998]. + If there is no existing route between the Origin and the Target(s) or + the cost measurement for the existing routes fails, the Origin will + have to guess the constraints to be used in the initial route + discovery. Once the initial route discovery succeeds or fails, the + Origin will have a better estimate for the constraints to be used in + the subsequent route discovery. + + P2P-RPL may result in discovery of better P2P routes than those + available along a global DAG designed to optimize routing cost to the + DAG's root. The improvement in route quality depends on a number of + factors, including the network topology, the "distance" between the + Origin and the Target (in terms of the routing metrics in use), and + the prevalent conditions in the network. In general, a P2P-RPL route + may be better than the one along a global DAG if the Origin and the + Target are nearby. Similarly, a P2P-RPL route may not be much better + than the one along a global DAG if the Origin and the Target are far + apart. Note that even when P2P-RPL routes are not much better than + those along a global DAG, P2P-RPL routes may still be able to avoid + + + +Goyal, et al. Experimental [Page 6] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + + congestion that might occur near the root if the routing takes place + only along a global DAG. In general, the cost associated with a + P2P-RPL route discovery (in terms of the control messages -- mostly + DIOs -- generated) increases with the distance between the Origin and + the Target. However, it is possible to limit the cost of route + discovery by carefully setting the routing constraints, the Trickle + parameters (which govern DIO generation), and the time duration for + which a router maintains its membership in 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 on the Trickle parameters. + + Like core RPL [RFC6550], P2P-RPL operation requires that links have + bidirectional reachability. For this reason, the 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 Ingress-only (or Egress-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. The routes are discovered and + installed while the DAG is alive. Once the specified duration of + their membership in the DAG is over, the routers leave the DAG, and + hence the DAG ceases to exist. However, the installed routes are + retained for their specified lifetime (which is different than the + specified duration of a router's membership in the DAG) even though + the DAG that caused their installation no longer exists. In P2P-RPL, + the sole purpose of DAG creation is to discover routes to the + Target(s), and DIOs serve as the route discovery messages. Each + router joining the DAG determines a rank for itself in the DAG and + ignores the subsequent DIOs received from lower-ranked (higher in + numerical value) neighbors. Thus, the route discovery messages + propagate away from the Origin rather than return to it. As in core + RPL, DIO generation at a router is controlled by a Trickle timer + [RFC6206], which allows a router to avoid generating unnecessary + messages while providing protection against packet loss. P2P-RPL + + + +Goyal, et al. Experimental [Page 7] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + + 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 + 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. 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. + + 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 (P2P-RDO, defined in Section 7) in which the Origin specifies + the following information: + + o The IPv6 address of a Target. This could be a unicast address or + 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 + 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 P2P Discovery Reply Object + (P2P-DRO) messages (defined in Section 8) back to the Origin on + receiving a DIO message. A P2P-DRO message carries a discovered + Source Route back to the Origin or establishes a Hop-by-hop Route + between the Origin and the Target. + + A P2P-RDO also includes the best route from the Origin that the + router, generating the P2P mode DIO, has seen so far. + + + + + + + + + + + +Goyal, et al. Experimental [Page 8] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + + A P2P mode DIO MAY also carry: + + o One or more Metric Container options to specify: + + * The relevant routing metrics. + + * The constraints that the discovered route must satisfy. These + constraints also limit how far the DIO messages may travel. + + o One or more RPL Target options to specify additional unicast or + multicast Targets. + + As the routers join the temporary DAG, they keep track of the best + 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 contains inside the P2P-RDO + a complete Source Route from the Origin to this Target. Since the + links in the discovered route have bidirectional reachability + (Section 7), the Target may use the discovered route to reach the + Origin. Thus, a router that provides a particular service in the LLN + (e.g., an outside temperature server) could initiate a P2P-RPL route + discovery listing all its potential clients as Targets, thereby + allowing the clients to discover a Source Route back to the server. + In this case, the Origin (the server) might want to disable the + generation of P2P-DRO messages by the Targets (the clients). If the + Origin has requested that P2P-DRO messages be sent back, the Target + may select the discovered route 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 Route(s) to the Origin via P2P-DRO messages, with + one P2P-DRO message carrying one discovered route. On receiving a + P2P-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 + + + +Goyal, et al. Experimental [Page 9] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + + routes fail. If a Hop-by-hop Route is being discovered, the Target + sends a P2P-DRO message containing the selected route to the Origin. + The P2P-DRO message travels back to the Origin along the selected + route, establishing state for the Forward Route in the routers on + the path. + + The Target may request that the Origin acknowledge the receipt of a + P2P-DRO message by sending back a P2P-DRO Acknowledgement + (P2P-DRO-ACK) message (defined in Section 10). The Origin unicasts a + P2P-DRO-ACK message to the Target. If the Target does not receive + the requested P2P-DRO-ACK within a certain time interval of sending a + P2P-DRO, it resends the P2P-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 + may cause some nodes to generate these messages even when the desired + routes have already been discovered. In order to preempt the + generation of such unnecessary messages, the Target may set a "Stop" + flag in the P2P-DRO message to let the nodes in the LLN know about + the completion of the route discovery process. The routers receiving + such a P2P-DRO should not generate any more DIOs for this temporary + DAG, nor should they process any received DIOs for this temporary DAG + in the future. However, such routers must still process the P2P-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. 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 exactly one P2P Route Discovery Option (P2P-RDO, specified in + Section 7). + +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 chooses the RPLInstanceID to + be used for a particular route discovery in accordance with the + following rules: + + * The Origin SHOULD NOT reuse a RPLInstanceID for a route + discovery if some routers might still maintain membership in + the DAG that the Origin had initiated for the previous route + discovery using this RPLInstanceID. As described in Section 7, + + + +Goyal, et al. Experimental [Page 10] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + + a router's membership in a DAG created for a P2P-RPL route + discovery lasts for the time duration (say, 't' seconds) + indicated by the L field inside the P2P-RDO. In general, there + is no upper bound on the time duration by when all the routers + have left the DAG created for a P2P-RPL route discovery. In + the specific case where the discovered route must be at most + 'n' hops in length, all the routers must have left the DAG + "(n+1)*t" seconds after its initiation by the Origin. In + practice, all the routers should have joined the DAG within 't' + seconds of its initiation (since the route discovery must + complete while the Origin still belongs to the DAG), and hence + all the routers should have left the DAG within "2*t" seconds + of its initiation. Hence, it is usually sufficient that the + Origin wait for twice the duration indicated by the L field + inside the P2P-RDO used for the previous route discovery before + reusing the RPLInstanceID for a new route discovery. + Individual P2P-RPL deployments are encouraged to share their + experience with various RPLInstanceID reuse policies to help + guide the development of a Standards Track version of the + protocol. + + * 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 state created during the + previous route discovery might still exist in some routers. + Note that it is possible that the previous route discovery did + not succeed yet some routers still ended up creating state. + The Default Lifetime and Lifetime Unit parameters in the DODAG + Configuration Option specify the lifetime of the state that the + routers, including the Origin and the Target, maintain for a + Hop-by-hop or Source Route discovered using P2P-RPL. Suppose + this lifetime is 'X' seconds. As discussed above, any state + created during the previous route discovery was likely created + within "2*t" seconds of its initiation. Hence, it is + sufficient that the Origin lets a time duration equal to + "X+2*t" seconds pass since the initiation of the previous route + discovery before initiating a new route discovery to the same + Target using the same RPLInstanceID. + + o Version Number: This field MUST be set to zero. The temporary DAG + used for P2P-RPL route discovery does not exist long enough to + have new versions. + + 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. + + + +Goyal, et al. Experimental [Page 11] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + + Further, item 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. + + o Mode of Operation (MOP): This field MUST be set to four, + corresponding to P2P Route Discovery mode. + + o Destination Advertisement Trigger Sequence Number (DTSN): This + field MUST be set to zero on transmission and ignored on + reception. + + o DODAGPreference (Prf): This field MUST be set to zero (least + preferred). + + o DODAGID: This field MUST be set to an IPv6 address of the Origin. + + o The other fields in the DIO Base object can be set in the desired + fashion as per the rules described in [RFC6550]. + + A received P2P mode DIO MUST be discarded if it does not follow the + above-listed rules regarding the RPLInstanceID, Version Number, + G flag, MOP, and Prf fields inside the Base object. + + The DODAG Configuration Option inside a P2P mode DIO MUST be set in + the following manner: + + o The Origin MUST set the MaxRankIncrease parameter to zero to + 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 that the routers, including + the Origin and the Target(s), maintain for a Hop-by-hop or Source + Route discovered using P2P-RPL. + + o The Origin sets the other fields in the DODAG Configuration + Option, including the Objective Code Point (OCP) identifying the + Objective Function, in the desired fashion as per the rules + described in [RFC6550]. + + + + + + + +Goyal, et al. Experimental [Page 12] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + + o As discussed in Section 14, P2P-RPL does not distinguish between + the "preinstalled" and "authenticated" security modes described in + [RFC6550]. Consequently, the Origin MUST set the Authentication + Enabled (A) flag to zero. A received P2P mode DIO MUST be + discarded if the A flag inside the DODAG Configuration Option is + not zero. + + 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. + + A default DODAG Configuration Option takes effect if a P2P mode DIO + does not carry an explicit one. The default DODAG Configuration + Option has the following parameter values: + + o Authentication Enabled: 0 + + o DIOIntervalMin: 6, which translates to 64 ms as the value for the + Imin parameter in a Trickle operation. This value is roughly one + order of magnitude larger than the typical transmission delay on + IEEE 802.15.4 links and corresponds to the recommendation in + Section 9.2 for well-connected topologies. + + o DIORedundancyConstant: 1. See the discussion in Section 9.2. + + o MaxRankIncrease: 0 (to disable local repair of the temporary DAG). + + o Default Lifetime: 0xFF, to correspond to infinity. + + o Lifetime Unit: 0xFFFF, to correspond to infinity. + + o Objective Code Point: 0, i.e., OF0 [RFC6552] is the default + Objective Function (OF). + + o The remaining parameters have default values as specified in + [RFC6550]. + + Individual P2P-RPL deployments are encouraged to share their + experience with these default values to help guide the development of + a Standards Track version of the protocol. + + The routing metrics and constraints [RFC6551] used in P2P-RPL route + discovery are included in one or more Metric Container options + [RFC6550] inside the P2P mode DIO. Note that a DIO need not include + a Metric Container if OF0 is the Objective Function in effect. In + that case, a P2P mode DIO may still specify an upper limit on the + maximum rank, that a router may have in the temporary DAG, inside + the P2P-RDO. + + + +Goyal, et al. Experimental [Page 13] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + + A P2P mode DIO: + + o MUST carry one (and only one) P2P-RDO. The P2P-RDO allows for the + specification of one unicast or multicast address for the Target. + A received P2P mode DIO MUST be discarded if it does not contain + exactly one P2P-RDO. + + o MAY carry one or more RPL Target options to specify additional + unicast/multicast addresses for the Target. If a unicast address + is specified, it MUST be a global address or a unique-local + address. + + o MAY carry one or more Metric Container options to specify routing + metrics and constraints. + + o MAY carry one or more Route Information Options [RFC6550]. In the + context of P2P-RPL, a Route Information Option advertises to the + Target(s) the Origin's connectivity to the prefix specified in the + option. + + o MAY carry one DODAG Configuration Option. If a P2P mode DIO does + not carry an explicit DODAG Configuration Option, the default + DODAG Configuration Option defined in this section is considered + to be in effect. + + A RPL option other than those listed above MUST be ignored when found + inside a received P2P mode DIO and MUST NOT be included in the P2P + mode DIOs that the receiving router generates. + + In accordance with core RPL, a P2P mode DIO MUST propagate via link- + local multicast. The IPv6 source address in a P2P mode DIO MUST be a + link-local address, and the IPv6 destination address MUST be the + link-local multicast address all-RPL-nodes [RFC6550]. A P2P mode DIO + MUST be transmitted on all interfaces the router has in this RPL + routing domain [RFC6554]. + + + + + + + + + + + + + + + + +Goyal, et al. Experimental [Page 14] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + +7. P2P Route Discovery Option (P2P-RDO) + + This section defines a new RPL control message option: the 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 = 0x0a | Option Length |R|H| N | Compr | L |MaxRank/NH | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | TargetAddr | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Address[1..n] | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: Format of the 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 P2P-DRO message (defined in + Section 8) MUST carry exactly one P2P-RDO. A P2P-RDO consists of the + following fields: + + o Option Type: 0x0a. + + o Option Length: This field is an 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 P2P-DRO messages back to the Origin. If this flag is set + to zero, a Target MUST NOT generate any P2P-DRO messages. + + 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-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 Reverse + direction. + + + + +Goyal, et al. Experimental [Page 15] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + + o Number of Routes (N): This field is valid only if the R flag is + set to one and the H flag is set to zero, i.e., the Targets are + allowed to generate P2P-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: This field is a 4-bit unsigned integer indicating the + number of prefix octets that are elided from the Target field and + the Address vector. For example, the Compr value will be zero if + full IPv6 addresses are carried in the Target field and the + Address vector. + + o Lifetime (L): This is a 2-bit field that indicates the exact + duration that a router joining the temporary DAG, including the + Origin and the Target(s), MUST maintain its membership in the DAG. + A router MUST leave the temporary DAG once the time elapsed since + it joined reaches the value indicated by this field. The mapping + between the value in this field and the duration of the router's + membership in 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 + P2P-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 on the value in this field, the Origin should also + take into account the fact that all routers joining the temporary + DAG would need to stay in the DAG for this much time. + + + + + + + + + + +Goyal, et al. Experimental [Page 16] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + + 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 advertised + rank equals or exceeds the MaxRank limit. A value of 0 in this + field indicates that the MaxRank is infinity. + + * When a P2P-RDO is included in a P2P-DRO message, this field + indicates the index of the next-hop (NH) address inside the + Address vector. + + o TargetAddr: This is 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. If a unicast address is specified, it MUST be + a global address or a unique-local 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 + P2P-DRO, this field MUST contain a unicast global or unique-local + IPv6 address of the Target generating the P2P-DRO. + + o Address[1..n]: This is 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 global or unique-local IPv6 address + with the 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 address that a router adds to the vector MUST belong + to the interface on which the router received the DIO + containing this P2P-RDO. Further, this interface MUST NOT be + an Ingress-only Interface. This allows the route accumulated + in the Address vector to be a Bidirectional Route that can be + used by a Target to send a P2P-DRO message to the Origin. + + + + + + +Goyal, et al. Experimental [Page 17] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + + * 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 none + of its addresses 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. + +8. The P2P Discovery Reply Object (P2P-DRO) + + This section defines two new RPL control message types: the P2P + Discovery Reply Object (P2P-DRO), with code 0x04; and the Secure + P2P-DRO, with code 0x84. A P2P-DRO serves one of the following + functions: + + o carries a discovered Source Route from a Target to the Origin; + + o establishes a Hop-by-hop Route as it travels from a Target to the + Origin. + + A P2P-DRO message can also 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 P2P-DRO message MUST carry one (and only one) + P2P-RDO whose TargetAddr field MUST contain a unicast IPv6 address of + the Target that generates the P2P-DRO. A P2P-DRO message MUST travel + 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 P2P-DRO. The IPv6 source address in a P2P-DRO message MUST be + a link-local address, and the IPv6 destination address MUST be the + link-local multicast address all-RPL-nodes [RFC6550]. A P2P-DRO + message MUST be transmitted on all interfaces the router has in this + RPL routing domain [RFC6554]. + + + + + + + + + + + +Goyal, et al. Experimental [Page 18] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + + 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 | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Option(s)... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... + + Figure 2: Format of the Base P2P Discovery Reply Object (P2P-DRO) + + The format of the base P2P Discovery Reply Object (P2P-DRO) is shown + in Figure 2. A base P2P-DRO consists of the following fields: + + o RPLInstanceID: This field provides the RPLInstanceID of the + temporary DAG used for route discovery. + + o Version: This field provides the Version of the temporary DAG used + for route discovery. Since a temporary DAG always has value zero + for the Version, this field MUST always be set to zero. + + o Stop (S): This flag, when set to one by a Target, indicates that + the P2P-RPL route discovery is over. All the routers receiving + such a P2P-DRO, including those not listed in the route carried + inside a P2P-RDO, + + * SHOULD NOT process any more DIOs received for this + temporary DAG; + + * SHOULD NOT generate any more DIOs for this temporary DAG; + + * SHOULD cancel any pending DIO transmissions for this + temporary DAG. + + Note that the Stop flag serves to stop further DIO + generation/processing for a P2P-RPL route discovery but does not + affect the processing of P2P-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 P2P-DRO + messages even if an earlier P2P-DRO message (with the same + RPLInstanceID and DODAGID fields) had the Stop flag set to one. + When set to zero, this flag does not imply anything and MUST be + ignored on reception. + + + + +Goyal, et al. Experimental [Page 19] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + + o Ack Required (A): This flag, when set to one by the Target, + indicates that the Origin MUST unicast a P2P-DRO-ACK message + (defined in Section 10) to the Target when it receives the + P2P-DRO. + + o Sequence Number (Seq): This 2-bit field indicates the sequence + number for the P2P-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 P2P-DRO. The Origin includes the + RPLInstanceID, the DODAGID, and the Sequence Number of the + received P2P-DRO inside the P2P-DRO-ACK message it sends back to + the Target. + + o Reserved: These bits are reserved for future use. These bits MUST + be set to zero on transmission and MUST be ignored on reception. + + o DODAGID: This field provides the DODAGID of the temporary DAG used + for route discovery. The DODAGID also identifies the Origin. The + RPLInstanceID, the Version, and the DODAGID together uniquely + identify the temporary DAG used for route discovery and can be + copied from the DIO message advertising the temporary DAG. + + o Options: The P2P-DRO message: + + * MUST carry one (and only one) P2P-RDO that MUST specify a + complete route between the Target and the Origin. A received + P2P-DRO message MUST be discarded if it does not contain + exactly one P2P-RDO. + + * MAY carry one or more Metric Container options that contain the + aggregated routing metrics values for the route specified in + the P2P-RDO. + + A RPL option other than those listed above MUST be ignored when + found inside a received P2P-DRO message. + +8.1. Secure P2P-DRO + + A Secure P2P-DRO message follows the format shown in Figure 7 of + [RFC6550], where the base format is the base P2P-DRO shown in + Figure 2. + + + + + + + + + + +Goyal, et al. Experimental [Page 20] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + +8.2. Setting a P2P-RDO Carried in a P2P Discovery Reply Object + + A P2P Discovery Reply Object MUST carry one (and only one) P2P-RDO, + which MUST be set as defined in Section 7. Specifically, the + following fields MUST be set as follows: + + o Reply (R): This flag MUST be set to zero on transmission and + ignored on reception. + + o Hop-by-Hop (H): The H flag in the P2P-RDO included in a P2P-DRO + message MUST have the same value as the H flag in the P2P-RDO + inside the corresponding DIO message. + + o Number of Routes (N): This field MUST be set to zero on + transmission and ignored on reception. + + o Lifetime (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 P2P-DRO message, + the NH field is set to n = (Option Length - 2 - (16 - Compr))/ + (16 - Compr). + + o TargetAddr: This field MUST contain a unicast global or unique- + local IPv6 address of the Target generating the P2P-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 that purpose. When a router joins a temporary DAG + advertised by a P2P mode DIO, it MUST maintain its membership in the + temporary DAG for the duration indicated by the L field inside 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 data packets. In other words, joining a + temporary DAG does not allow a router to provision routing table + + + +Goyal, et al. Experimental [Page 21] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + + entries listing the router's parents in the temporary DAG as the next + hops (i.e., the last bullet point in Section 3.2.8 of [RFC6550] is + not applicable when the DAG is a temporary DAG created for the + purpose of a P2P-RPL route discovery). + + Given the nature of a temporary DAG created for a P2P-RPL route + discovery, this document disallows the solicitation of P2P mode DIOs + using DODAG Information Solicitation (DIS) messages as described in + [RFC6550]. A router participating in a P2P-RPL route discovery MUST + NOT reset its Trickle timer, which controls the transmission of P2P + mode DIOs in response to a multicast DIS. Also, the router MUST NOT + send a P2P mode DIO in response to a unicast DIS. In other words, + the rules in Section 8.3 of [RFC6550] regarding a router's response + to a multicast/unicast DIS are not applicable for P2P mode DIOs. + + A router MUST detach from the temporary DAG created for a P2P-RPL + route discovery once the duration of its membership in the DAG has + reached the value indicated by the L field inside the P2P-RDO. After + receiving a P2P-DRO with the Stop flag set to one, a router SHOULD + NOT send or process any more DIOs for this temporary DAG and SHOULD + also cancel any pending DIO transmissions. + +9.2. Trickle Operation for P2P Mode DIOs + + A 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: + + o The receipt of a P2P mode DIO that allows the router to advertise + a better route (in terms of the routing metrics and the OF in use) + than before is considered "inconsistent" and hence resets the + Trickle timer. Note that the first receipt of a P2P mode DIO + advertising a particular temporary DAG is always considered an + "inconsistent" event. + + o The receipt of a P2P mode DIO from a parent in the temporary DAG + is considered neither "consistent" nor "inconsistent" if it does + not allow the router to advertise a better route than before. + Thus, the receipt of such DIOs has no impact on the Trickle + operation. Note that this document does not impose any + requirements on how a router might choose its parents in the + temporary DAG. + + + + + +Goyal, et al. Experimental [Page 22] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + + 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 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 transmissions 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 into account the + connectivity within the network. For highly connected networks, a + small Imin value (on the order of the typical transmission delay + for a DIO) may lead to congestion in the network as a large number + of routers reset their Trickle timers in response to the first + receipt of a DIO from the Origin. These routers would generate + their DIOs within the Imin interval and cause additional routers + to reset their Trickle timers and generate more DIOs. Thus, for + highly connected networks, the Imin parameter SHOULD be set to a + value at least one order of magnitude larger than the typical + transmission delay for a DIO. For sparsely connected networks, + the Imin parameter can be set to a value that is a small multiple + of the typical transmission delay for a DIO. Note that the Imin + value has a direct impact on the time required for a P2P-RPL route + discovery to complete. In general, the time required for a + P2P-RPL route discovery would increase approximately linearly with + the value of the Imin parameter. Since the route discovery must + complete while the Origin still belongs to the temporary DAG + created for that purpose, the Origin should set the time duration + for which a router maintains its membership in the temporary DAG + (indicated by the L field inside the P2P-RDO) to a large enough + value, taking into account the Imin value as well as the expected + distance (in terms of hops and/or ETX) to the Target(s). + + + + + + + + +Goyal, et al. Experimental [Page 23] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + + o The Imax parameter SHOULD be set to a large value (several orders + of magnitude higher than the Imin value) and is unlikely to be + critical for P2P-RPL operation. This is because the first receipt + of a P2P mode DIO for a particular temporary DAG is considered an + inconsistent event and would lead to the resetting of the Trickle + timer duration to the Imin value. Given the temporary nature of + the DAGs used in P2P-RPL, the 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. 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 into account the above- + mentioned factors when deciding on the value of the redundancy + constant. + + Individual P2P-RPL deployments are encouraged to share their + experience with these rules to help guide the development of a + 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 + + The rules for DIO processing and transmission as described in + Section 8 of RPL [RFC6550] apply to P2P mode DIOs as well, except as + modified in this document. In particular, in accordance with + Section 8.2.3 of RPL [RFC6550], a received P2P mode DIO MUST be + discarded if it is malformed, according to the rules specified in + this document and in [RFC6550]. + + + + + +Goyal, et al. Experimental [Page 24] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + + 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 into 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 P2P-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 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 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 P2P-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 + in Section 9.5. Otherwise, the router considers itself an + Intermediate Router and processes the received DIO as specified in + Section 9.4. + + + + + + + + + + +Goyal, et al. Experimental [Page 25] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + +9.4. Additional Processing of a P2P Mode DIO at an Intermediate Router + + An Intermediate Router MUST discard a received P2P mode DIO with no + further processing + + o if the DIO is received on an Ingress-only Interface; or + + o if the receiving interface does not have a global or unique-local + IPv6 address configured with the address prefix implied by the + Compr field in the P2P-RDO inside the received DIO; or + + o if the router cannot uniquely identify the address prefix implied + by the Compr field in the P2P-RDO (this might happen if the + receiving interface has multiple global/unique-local IPv6 + addresses, each configured with a different address prefix); or + + o if adding its IPv6 address to the route in the Address vector + inside the P2P-RDO would result in the route containing multiple + addresses belonging to this router. + + On receiving a P2P mode DIO, an Intermediate Router MUST do the + following. The router MUST determine whether this DIO advertises a + better route than the router itself and whether the receipt of the + DIO would allow the router to advertise a better route than before. + Accordingly, the router SHOULD consider this DIO as + consistent/inconsistent from the 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 + add a unicast IPv6 address of the receiving interface (after eliding + Compr prefix octets) to the route in the Address vector inside the + P2P-RDO and remember this route for inclusion in its future DIOs. + + When an Intermediate Router adds an IPv6 address to a route, it MUST + ensure that + + o the IPv6 address is a unicast global or unique-local IPv6 address + assigned to the interface on which the DIO containing the route + was received; + + o the IPv6 address was configured with the address prefix implied by + the Compr field in the P2P-RDO inside the received DIO. + + 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 + + + +Goyal, et al. Experimental [Page 26] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + + 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 + P2P-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. + +9.5. Additional Processing of a P2P Mode DIO at the Target + + The Target MAY remember the discovered route contained in the P2P-RDO + in the received DIO for use as a Source Route to reach the Origin. + The lifetime of this Source Route is specified by the Default + Lifetime and Lifetime Unit parameters inside the DODAG Configuration + Option currently in effect. This lifetime can be extended (or + shortened) appropriately, following a hint from an upper-layer + protocol. + + If the Reply flag inside the P2P-RDO in the received DIO is set to + one, the Target MUST select one or more discovered routes and send + one or more P2P-DRO messages, carrying one discovered route each, + back to the Origin. If the H flag inside the P2P-RDO is set to one, + the Target needs to select one route and send a P2P-DRO message along + this route back to the Origin. As this P2P-DRO message travels back + to the Origin, the routers on the path establish a hop-by-hop routing + state, thereby establishing a Hop-by-hop Route in the Forward + direction. If the H flag is set to zero, the number of Source Routes + to be selected (and the number of P2P-DRO messages to be sent back) + is given by one plus the value of the N field in the P2P-RDO. The + Target may select the discovered route inside the received DIO as one + or more of the routes that would be carried inside a P2P-DRO message + back to the Origin. This document does not prescribe a particular + method for the Target to select the routes. Example methods include + selecting each route that meets the specified routing constraints + until the desired number of routes has been selected, or selecting + the best routes discovered over a certain time period. If multiple + routes are to be selected, the Target SHOULD avoid selecting routes + that have large segments in common. + + If the Target selects the route contained in the P2P-RDO in the + received DIO, it sends a P2P-DRO message back to the Origin + (identified by the DODAGID field in the DIO). The P2P-DRO message + MUST include a P2P-RDO that contains the selected route inside the + Address vector. Various fields inside the P2P-RDO MUST be set as + specified in Section 8.2. The Target MAY set the A flag inside the + P2P-DRO message to one if it desires the Origin to send back a + P2P-DRO-ACK message on receiving the P2P-DRO. In this case, the + Target waits for the duration of P2P_DRO_ACK_WAIT_TIME for the + P2P-DRO-ACK message to arrive. Failure to receive the P2P-DRO-ACK + message within this time duration causes the Target to retransmit the + + + +Goyal, et al. Experimental [Page 27] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + + P2P-DRO message. The Target MAY retransmit the P2P-DRO message in + this fashion up to MAX_P2P_DRO_RETRANSMISSIONS times. Both + P2P_DRO_ACK_WAIT_TIME and MAX_P2P_DRO_RETRANSMISSIONS are + configurable parameters to be chosen based on the characteristics of + individual deployments. Note that all P2P-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 P2P-DRO if it no longer belongs to this DAG. + + The Target MAY set the Stop flag inside the P2P-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 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 P2P-DRO + message. This Metric Container contains the end-to-end routing + metric values for the route specified in the P2P-RDO. The Target + MUST transmit the P2P-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 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 P2P-DRO at an Intermediate Router + + If the DODAGID field in the received P2P-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: + + o The router MUST discard the received P2P-DRO with no further + processing if it does not belong to the temporary DAG identified + by the RPLInstanceID and the DODAGID fields in the P2P-DRO. + + o If the Stop flag inside the received P2P-DRO is set to one, the + router SHOULD NOT send or receive any more DIOs for this temporary + DAG and SHOULD cancel any pending DIO transmissions. + + o The router MUST ignore any Metric Container options contained in + the P2P-DRO message. + + + + + +Goyal, et al. Experimental [Page 28] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + + o If an 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 P2P-DRO message + with no further processing if the Address vector in the P2P-RDO + includes multiple IPv6 addresses assigned to the router's + interfaces. + + * If the H flag inside the P2P-RDO is set to one, the router MUST + store 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 P2P-DRO + + + the route's destination, the Target (identified by the + TargetAddr field inside the P2P-RDO) + + + the IPv6 address of the next hop, Address[NH+1] (unless the + 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 + 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 + Target as the destination and carrying the same RPLInstanceID + and DODAGID fields as the received P2P-DRO, and the next-hop + information in the state does not match the next hop indicated + in the received P2P-DRO, the router MUST discard the P2P-DRO + message with no 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, this rule causes the P2P-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 P2P-DRO message further via link-local multicast. + + + +Goyal, et al. Experimental [Page 29] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + +9.7. Processing a P2P-DRO at the Origin + + When a router receives a P2P-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 TargetAddr field inside the + P2P-RDO), and processes the message in the following manner: + + o The Origin MUST discard the received P2P-DRO with no further + processing if it no longer belongs to the temporary DAG identified + by the RPLInstanceID and the DODAGID fields in the P2P-DRO. + + o If the Stop flag inside the received P2P-DRO is set to one, the + Origin SHOULD NOT generate any more DIOs for this temporary DAG + and SHOULD cancel any pending DIO transmissions. + + o If the P2P-RDO inside the P2P-DRO has the H flag set to zero, the + Address vector inside the P2P-RDO contains a Source Route to this + Target. The Origin MUST set the lifetime of this Source Route to + the value 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 P2P-DRO has the H flag set to one, the + P2P-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 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. A 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 P2P-DRO message contains one or more Metric + Container options, the Origin MAY store the values of the routing + metrics associated with the discovered route in its memory. This + information may be useful in formulating the constraints for any + future P2P-RPL route discovery to this Target. + + + + + + + + + +Goyal, et al. Experimental [Page 30] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + + o If the A flag is set to one in the received P2P-DRO message, the + Origin MUST generate a P2P-DRO-ACK message as described in + Section 10 and unicast the message to the Target. The Origin MAY + use the route just discovered to send the P2P-DRO-ACK message to + the Target. Section 12 describes how a packet may be forwarded + along a Source/Hop-by-hop Route discovered using P2P-RPL. + +10. The P2P Discovery Reply Object Acknowledgement (P2P-DRO-ACK) + + 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 |Seq| Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | DODAGID | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: Format of the Base P2P Discovery Reply Object + Acknowledgement (P2P-DRO-ACK) + + A P2P-DRO message may fail to reach the Origin due to a number of + reasons. Unlike the DIO messages, which benefit from Trickle- + controlled retransmissions, the P2P-DRO messages are prone to loss + due to unreliable packet transmission in LLNs. Since a P2P-DRO + message travels via link-local multicast, it cannot use link-level + acknowledgements to improve the reliability of its transmission. + Also, an Intermediate Router may drop the P2P-DRO message (e.g., + because of its inability to store the state for the Hop-by-hop Route + that the P2P-DRO is establishing). To protect against the potential + failure of a P2P-DRO message to reach the Origin, the Target MAY + request that the Origin send back a P2P-DRO Acknowledgement + (P2P-DRO-ACK) message on receiving a P2P-DRO message. Failure to + receive such an acknowledgement within the P2P_DRO_ACK_WAIT_TIME + interval of sending the P2P-DRO message forces the Target to resend + the message (as described in Section 9.5). + + This section defines two new RPL control message types: the P2P-DRO + Acknowledgement (P2P-DRO-ACK), with code 0x05; and the Secure + P2P-DRO-ACK, with code 0x85. A P2P-DRO-ACK message MUST travel as a + unicast message from the Origin to the Target. The IPv6 source and + destination addresses used in a P2P-DRO-ACK message MUST be global or + unique-local. The format of a base P2P-DRO-ACK message is shown in + Figure 3. Various fields in a P2P-DRO-ACK message MUST have the same + values as the corresponding fields in the P2P-DRO message. The field + marked as "Reserved" MUST be set to zero on transmission and MUST be + + + +Goyal, et al. Experimental [Page 31] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + + ignored on reception. A Secure P2P-DRO-ACK message follows the + format shown in Figure 7 of [RFC6550], where the base format is the + same as the base P2P-DRO-ACK shown in Figure 3. + +11. Secure P2P-RPL Operation + + Each RPL control message type, including those defined in this + document, has a secure version. A secure RPL control message is + identified by the value 1 in the most significant bit of the Code + field. Each secure RPL control message contains a Security section + (see Figures 7 and 8 of [RFC6550]) whose contents are described in + Section 6.1 of [RFC6550]. Sections 6.1, 10, and 19 of [RFC6550] + describe core RPL's security apparatus. These sections are + applicable to P2P-RPL's secure operation as well, except as + constrained in this section. + + Core RPL allows a router to decide locally on a per-packet basis + whether to use security and, if yes, what Security Configuration (see + definition in Section 3) to use (the only exception being the + requirement to send a Secure DIO in response to a Secure DIS; see + Section 10.2 of [RFC6550]). In contrast, this document requires that + routers participating in a P2P-RPL route discovery follow the + Origin's lead regarding security. The Origin decides whether to use + security, and the particular Security Configuration to be used for + this purpose. All the routers participating in this route discovery + MUST generate only secure control messages if the Origin so decides + and MUST use for this purpose the Security Configuration that the + Origin chose. The Origin MUST NOT set the "Key Identifier Mode" + field inside the chosen Security Configuration to value 1, since this + setting indicates the use of a per-pair key, which is not suitable + for securing messages that travel by (link-local) multicast (e.g., + DIOs) or that travel over multiple hops (e.g., P2P-DROs). The Origin + MUST use the chosen Security Configuration to secure all the control + messages (DIOs and P2P-DRO-ACKs) it generates. + + A router MUST NOT join the temporary DAG being created for a P2P-RPL + route discovery if: + + o it receives both secure and unsecure DIOs or Secure DIOs with + different Security Configurations pertaining to this route + discovery (i.e., referring to the same RPLInstanceID and DODAGID + combination) prior to joining; or + + o it cannot use the Security Configuration found in the Secure DIOs + pertaining to this route discovery. + + + + + + +Goyal, et al. Experimental [Page 32] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + + When a router (an Intermediate Router or a Target) joins a temporary + DAG being created using Secure DIOs, it MUST remember the common + Security Configuration used in the received Secure DIOs and MUST use + this configuration to secure all the control messages (DIOs and + P2P-DROs) it generates. + + If an Intermediate Router (or a Target) encounters a control message + (a DIO or a P2P-DRO or a P2P-DRO-ACK) pertaining to this route + discovery that is either not secure or does not follow the Security + Configuration the router remembers for this route discovery, the + router MUST enter the "lock down" mode for the remainder of its stay + in this temporary DAG. An Intermediate Router (or a Target) in the + "lock down" mode MUST NOT generate or process any control messages + (irrespective of the Security Configuration used) pertaining to this + route discovery. If the Origin receives a control message (a + P2P-DRO) that does not follow the Security Configuration the Origin + has chosen for this route discovery, it MUST discard the received + message with no further processing. + +12. Packet Forwarding along a Route Discovered Using P2P-RPL + + An Origin uses the 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 + values, and hence both the RPLInstanceID (a local value assigned by + the Origin) and the DODAGID (an IPv6 address of the Origin) are + required to uniquely identify a P2P-RPL Hop-by-hop Route to a + particular destination. + + An Origin includes a RPL option [RFC6553] inside the IPv6 Hop-by-Hop + Options header of a packet to send it along a Hop-by-hop Route + established using P2P-RPL. For this purpose, the Origin MUST set the + DODAGID of the temporary DAG used for the route discovery as the + source IPv6 address of the packet. Further, the Origin MUST specify + inside the RPL option the RPLInstanceID of the temporary DAG used for + the route discovery and set the O flag inside the RPL option to one. + On receiving this packet, an Intermediate Router checks the O flag + and correctly infers the source IPv6 address of the packet as the + DODAGID of the Hop-by-hop Route. The router then uses the DODAGID, + the RPLInstanceID, and the destination address to identify the + routing state to be used to forward the packet further. + + + + + + +Goyal, et al. Experimental [Page 33] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + +13. Interoperability with Core RPL + + This section describes how RPL routers that implement P2P-RPL + interact with RPL routers that do not. In general, P2P-RPL operation + does not affect core RPL operation, and vice versa. However, core + RPL does allow a router to join a DAG as a leaf node even if it does + not understand the Mode of Operation (MOP) used in the DAG. Thus, a + RPL router that does not implement P2P-RPL may conceivably join a + temporary DAG being created for a P2P-RPL route discovery as a leaf + node and maintain its membership even though the DAG no longer + exists. This may impose a drain on the router's memory. However, + such RPL-only leaf nodes do not interfere with P2P-RPL route + discovery, since a leaf node may only generate a DIO advertising an + INFINITE_RANK and all routers implementing P2P-RPL are required to + discard such DIOs. Note that core RPL does not require that a router + join a DAG whose MOP it does not understand. Moreover, RPL routers + in a particular deployment may have strict restrictions on the DAGs + they may join, thereby mitigating the problem. + + The P2P-RPL mechanism described in this document works best when all + the RPL routers in the LLN implement P2P-RPL. In general, the + ability to discover routes, as well as the quality of discovered + routes, would deteriorate with the fraction of RPL routers that + implement P2P-RPL. + +14. Security Considerations + + In general, the security considerations for the operation of P2P-RPL + are similar to those for the operation of RPL (as described in + Section 19 of the RPL specification [RFC6550]). Sections 6.1 and 10 + of [RFC6550] describe RPL's security framework, which provides data + confidentiality, authentication, replay protection, and delay + protection services. This security framework can also be used in + P2P-RPL after taking into account the constraints specified in + Section 11. P2P-RPL requires that all routers participating in a + secure route discovery use the Security Configuration chosen by the + Origin. The intention is to avoid compromising the overall security + of a route discovery due to some routers using a weaker Security + Configuration. With the "lock down" mechanism as described in + Section 11 in effect, it is unlikely that an Origin would accept a + route discovered under a Security Configuration other than the one it + intended. Any attempt to use a different Security Configuration + (than the one the Origin intended) is likely to result, in the worst + case, in the failure of the route discovery process. In the best- + case scenario, any such attempt by a rogue router would result in its + neighbors entering the "lock down" mode and acting as firewalls to + allow the route discovery to proceed in the remaining network. + + + + +Goyal, et al. Experimental [Page 34] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + + The RPL specification [RFC6550] describes three modes of security: + unsecured, preinstalled, and authenticated. In the unsecured mode, + secure control messages are not used, and the only available security + is the security provided by the link-layer protocols. In the + preinstalled mode, all the nodes use a preinstalled group key to join + a secure DAG as the "routers" or "hosts", where the term "router" + means a node that is capable of forwarding packets received from its + parents or children in the DAG, and the term "host" refers to nodes + that cannot function as "routers". In the authenticated mode, the + nodes can join a secure DAG as "hosts" using the preinstalled key but + then need to authenticate themselves to a key server to obtain the + key that will allow them to work as "routers". The temporary DAG + created for a P2P-RPL discovery cannot be used for routing packets. + Hence, it is not meaningful to say that a node joins this DAG as a + "router" or a "host" in the sense defined above. Hence, in P2P-RPL, + there is no distinction between the preinstalled and authenticated + modes. A router can join a temporary DAG created for a secure + P2P-RPL route discovery only if it can support the Security + Configuration in use, which also specifies the key in use. It does + not matter whether the key is preinstalled or dynamically acquired. + The router must have the key in use before it can join the DAG being + created for a secure P2P-RPL route discovery. + + If a rogue router can support the Security Configuration in use (in + particular, if it knows the key in use), it can join the secure + P2P-RPL route discovery and cause various types of damage. Such a + rogue router could advertise false information in its DIOs in order + to include itself in the discovered route(s). It could generate + bogus P2P-DRO messages carrying bad routes or maliciously modify + genuine P2P-DRO messages it receives. A rogue router acting as the + Origin could launch denial-of-service attacks against the LLN + deployment by initiating fake P2P-RPL route discoveries; in this type + of scenario, RPL's authenticated mode of operation, where a node can + obtain the key to use for a P2P-RPL route discovery only after proper + authentication, would be useful. + + Since a P2P-DRO message travels along a Source Route specified inside + the message, some of the security concerns that led to the + deprecation of Type 0 routing headers [RFC5095] may apply. To avoid + the possibility of a P2P-DRO message traveling in a routing loop, + this document requires that each Intermediate Router confirm that the + Source Route listed inside the message does not contain any routing + loop involving itself 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. + + + + +Goyal, et al. Experimental [Page 35] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + +15. IANA Considerations + +15.1. Additions to Mode of Operation + + This document defines a new Mode of Operation, entitled "P2P Route + Discovery Mode of Operation" (see Section 6), assigned a value of 4 + from the "Mode of Operation" space [RFC6550]. + + +-------+---------------------------------------+---------------+ + | Value | Description | Reference | + +-------+---------------------------------------+---------------+ + | 4 | P2P Route Discovery Mode of Operation | This document | + +-------+---------------------------------------+---------------+ + + Mode of Operation + +15.2. Additions to RPL Control Message Options + + This document defines a new RPL option: "P2P Route Discovery" (see + Section 7), assigned a value of 0x0a from the "RPL Control Message + Options" space [RFC6550]. + + +-------+---------------------+---------------+ + | Value | Meaning | Reference | + +-------+---------------------+---------------+ + | 0x0a | P2P Route Discovery | This document | + +-------+---------------------+---------------+ + + RPL Control Message Options + +15.3. Additions to RPL Control Codes + + This document defines the following new RPL messages: + + o "P2P Discovery Reply Object" (see Section 8), assigned a value of + 0x04 from the "RPL Control Codes" space [RFC6550]. + + o "Secure P2P Discovery Reply Object" (see Section 8.1), assigned a + value of 0x84 from the "RPL Control Codes" space [RFC6550]. + + o "P2P Discovery Reply Object Acknowledgement" (see Section 10), + assigned a value of 0x05 from the "RPL Control Codes" + space [RFC6550]. + + o "Secure P2P Discovery Reply Object Acknowledgement" (see + Section 10), assigned a value of 0x85 from the "RPL Control Codes" + space [RFC6550]. + + + + +Goyal, et al. Experimental [Page 36] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + + +--------+----------------------------------------+-----------------+ + | Code | Description | Reference | + +--------+----------------------------------------+-----------------+ + | 0x04 | P2P Discovery Reply Object | This document | + | 0x84 | Secure P2P Discovery Reply Object | This document | + | 0x05 | P2P Discovery Reply Object | This document | + | | Acknowledgement | | + | 0x85 | Secure P2P Discovery Reply Object | This document | + | | Acknowledgement | | + +--------+----------------------------------------+-----------------+ + + RPL Control Codes + +16. Known Issues and Future Work + + 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: + + o Secure P2P-RPL operation (Section 11); + + o Rules governing Trickle operation (Section 9.2); + + o Values in the default DODAG Configuration Option (Section 6.1); + + o The RPLInstanceID reuse policy (Section 6.1); + + o Utility and implementation complexity of allowing multiple Target + addresses in a P2P-RPL route discovery. + +17. Acknowledgements + + The authors gratefully acknowledge the contributions of the following + individuals (in alphabetical order) in the development of this + document: Dominique Barthel, Jakob Buron, Cedric Chauvenet, Thomas + Clausen, Robert Cragie, Ralph Droms, Adrian Farrel, Stephen Farrell, + Brian Haberman, Ted Humpal, Richard Kelsey, Phil Levis, Charles + Perkins, Joseph Reddy, Michael Richardson, Zach Shelby, Martin + Stiemerling, Pascal Thubert, Hristo Valev, and JP Vasseur. + + + + + + + + +Goyal, et al. Experimental [Page 37] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + +18. References + +18.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, + "The Trickle Algorithm", RFC 6206, March 2011. + + [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., + Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. + Alexander, "RPL: IPv6 Routing Protocol for Low-Power and + 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. + + [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 + Routing Header for Source Routes with the Routing Protocol + for Low-Power and Lossy Networks (RPL)", RFC 6554, + March 2012. + +18.2. Informative References + + [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, + "Building Automation Routing Requirements in Low-Power and + Lossy Networks", RFC 5867, June 2010. + + [RFC6552] Thubert, P., "Objective Function Zero for the Routing + Protocol for Low-Power and Lossy Networks (RPL)", + RFC 6552, March 2012. + + [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- + Power and Lossy Networks (RPL) Option for Carrying RPL + Information in Data-Plane Datagrams", RFC 6553, + March 2012. + + + + + +Goyal, et al. Experimental [Page 38] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + + [RFC6998] Goyal, M., Ed., Baccelli, E., Brandt, A., and J. Martocci, + "A Mechanism to Measure the Routing Metrics along a Point- + to-Point Route in a Low-Power and Lossy Network", + RFC 6998, August 2013. + + [ROLL-TERMS] + Vasseur, JP., "Terminology in Low power And Lossy + Networks", Work in Progress, March 2013. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Goyal, et al. Experimental [Page 39] + +RFC 6997 Reactive P2P Route Discovery: P2P-RPL August 2013 + + +Authors' Addresses + + Mukul Goyal (editor) + University of Wisconsin Milwaukee + 3200 N. Cramer St. + Milwaukee, WI 53201 + USA + + Phone: +1-414-229-5001 + EMail: mukul@uwm.edu + + + Emmanuel Baccelli + INRIA + + Phone: +33-169-335-511 + EMail: Emmanuel.Baccelli@inria.fr + URI: http://www.emmanuelbaccelli.org/ + + + Matthias Philipp + INRIA + + Phone: +33-169-335-511 + EMail: matthias-philipp@gmx.de + + + Anders Brandt + Sigma Designs + Emdrupvej 26A, 1. + Copenhagen, Dk-2100 + Denmark + + Phone: +45-29609501 + EMail: abr@sdesigns.dk + + + Jerald Martocci + Johnson Controls + 507 E. Michigan Street + Milwaukee, WI 53202 + USA + + Phone: +1-414-524-4010 + EMail: jerald.p.martocci@jci.com + + + + + + +Goyal, et al. Experimental [Page 40] + |