| < draft-ietf-roll-p2p-rpl-16.txt | draft-ietf-roll-p2p-rpl-17.txt > | |||
|---|---|---|---|---|
| Internet Engineering Task Force M. Goyal, Ed. | Internet Engineering Task Force M. Goyal, Ed. | |||
| Internet-Draft University of Wisconsin | Internet-Draft University of Wisconsin | |||
| Intended status: Experimental Milwaukee | Intended status: Experimental Milwaukee | |||
| Expires: August 7, 2013 E. Baccelli | Expires: September 21, 2013 E. Baccelli | |||
| M. Philipp | M. Philipp | |||
| INRIA | INRIA | |||
| A. Brandt | A. Brandt | |||
| Sigma Designs | Sigma Designs | |||
| J. Martocci | J. Martocci | |||
| Johnson Controls | Johnson Controls | |||
| February 3, 2013 | March 20, 2013 | |||
| Reactive Discovery of Point-to-Point Routes in Low Power and Lossy | Reactive Discovery of Point-to-Point Routes in Low Power and Lossy | |||
| Networks | Networks | |||
| draft-ietf-roll-p2p-rpl-16 | draft-ietf-roll-p2p-rpl-17 | |||
| Abstract | Abstract | |||
| This document specifies a point-to-point route discovery mechanism, | This document specifies a point-to-point route discovery mechanism, | |||
| complementary to the RPL core functionality. This mechanism allows | complementary to the RPL core functionality. This mechanism allows | |||
| an IPv6 router to discover "on demand" routes to one or more IPv6 | an IPv6 router to discover "on demand" routes to one or more IPv6 | |||
| routers in the LLN such that the discovered routes meet specified | routers in the LLN such that the discovered routes meet specified | |||
| metrics constraints. | metrics constraints. | |||
| Status of this Memo | Status of this Memo | |||
| skipping to change at page 1, line 42 ¶ | skipping to change at page 1, line 42 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on August 7, 2013. | This Internet-Draft will expire on September 21, 2013. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2013 IETF Trust and the persons identified as the | Copyright (c) 2013 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 2. The Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.1. Known Issues/Future Work . . . . . . . . . . . . . . . . . 4 | |||
| 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. The Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 5. Functional Overview . . . . . . . . . . . . . . . . . . . . . 6 | 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 6. P2P Route Discovery Mode Of Operation . . . . . . . . . . . . 9 | 5. Functional Overview . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 6.1. Setting a P2P Mode DIO . . . . . . . . . . . . . . . . . . 9 | 6. P2P Route Discovery Mode Of Operation . . . . . . . . . . . . 10 | |||
| 7. New RPL Control Message Options . . . . . . . . . . . . . . . 12 | 6.1. Setting a P2P Mode DIO . . . . . . . . . . . . . . . . . . 11 | |||
| 7.1. P2P Route Discovery Option (P2P-RDO) . . . . . . . . . . . 13 | 7. P2P Route Discovery Option (P2P-RDO) . . . . . . . . . . . . . 14 | |||
| 7.2. Data Option . . . . . . . . . . . . . . . . . . . . . . . 16 | 8. The P2P Discovery Reply Object (P2P-DRO) . . . . . . . . . . . 18 | |||
| 8. The Discovery Reply Object (DRO) . . . . . . . . . . . . . . . 17 | 8.1. Secure P2P-DRO . . . . . . . . . . . . . . . . . . . . . . 20 | |||
| 8.1. Secure DRO . . . . . . . . . . . . . . . . . . . . . . . . 19 | 8.2. Setting a P2P-RDO Carried in a P2P Discovery Reply | |||
| 8.2. Setting a P2P-RDO Carried in a Discovery Reply Object . . 19 | Object . . . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
| 9. P2P-RPL Route Discovery By Creating a Temporary DAG . . . . . 20 | 9. P2P-RPL Route Discovery By Creating a Temporary DAG . . . . . 21 | |||
| 9.1. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 20 | 9.1. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 21 | |||
| 9.2. Trickle Operation For P2P Mode DIOs . . . . . . . . . . . 20 | 9.2. Trickle Operation For P2P Mode DIOs . . . . . . . . . . . 22 | |||
| 9.3. Processing a P2P Mode DIO . . . . . . . . . . . . . . . . 23 | 9.3. Processing a P2P Mode DIO . . . . . . . . . . . . . . . . 24 | |||
| 9.4. Additional Processing of a P2P Mode DIO At An | 9.4. Additional Processing of a P2P Mode DIO At An | |||
| Intermediate Router . . . . . . . . . . . . . . . . . . . 24 | Intermediate Router . . . . . . . . . . . . . . . . . . . 25 | |||
| 9.5. Additional Processing of a P2P Mode DIO At The Target . . 25 | 9.5. Additional Processing of a P2P Mode DIO At The Target . . 26 | |||
| 9.6. Processing a DRO At An Intermediate Router . . . . . . . . 26 | 9.6. Processing a P2P-DRO At An Intermediate Router . . . . . . 27 | |||
| 9.7. Processing a DRO At The Origin . . . . . . . . . . . . . . 28 | 9.7. Processing a P2P-DRO At The Origin . . . . . . . . . . . . 29 | |||
| 10. The Discovery Reply Object Acknowledgement (DRO-ACK) . . . . . 29 | 10. The P2P Discovery Reply Object Acknowledgement | |||
| 11. Packet Forwarding Along a Route Discovered Using P2P-RPL . . . 30 | (P2P-DRO-ACK) . . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
| 12. Interoperability with Core RPL . . . . . . . . . . . . . . . . 30 | 11. Secure P2P-RPL Operation . . . . . . . . . . . . . . . . . . . 31 | |||
| 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 | 12. Packet Forwarding Along a Route Discovered Using P2P-RPL . . . 32 | |||
| 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 | 13. Interoperability with Core RPL . . . . . . . . . . . . . . . . 33 | |||
| 14.1. Additions to Mode of Operation . . . . . . . . . . . . . . 32 | 14. Security Considerations . . . . . . . . . . . . . . . . . . . 33 | |||
| 14.2. Additions to RPL Control Message Options . . . . . . . . . 32 | 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 | |||
| 14.3. Additions to RPL Control Codes . . . . . . . . . . . . . . 33 | 15.1. Additions to Mode of Operation . . . . . . . . . . . . . . 35 | |||
| 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 | 15.2. Additions to RPL Control Message Options . . . . . . . . . 35 | |||
| 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 | 15.3. Additions to RPL Control Codes . . . . . . . . . . . . . . 36 | |||
| 16.1. Normative References . . . . . . . . . . . . . . . . . . . 34 | 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 | |||
| 16.2. Informative References . . . . . . . . . . . . . . . . . . 35 | 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 | 17.1. Normative References . . . . . . . . . . . . . . . . . . . 37 | |||
| 17.2. Informative References . . . . . . . . . . . . . . . . . . 38 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 | ||||
| 1. Introduction | 1. Introduction | |||
| Targeting Low power and Lossy Networks (LLNs), the IPv6 Routing | Targeting Low power and Lossy Networks (LLNs), the IPv6 Routing | |||
| Protocol for LLNs (RPL) [RFC6550] provides paths along a Directed | Protocol for LLNs (RPL) [RFC6550] provides paths along a Directed | |||
| Acyclic Graph (DAG) rooted at a single router in the network. | Acyclic Graph (DAG) rooted at a single router in the network. | |||
| Establishment and maintenance of a DAG is performed by routers in the | Establishment and maintenance of a DAG is performed by routers in the | |||
| LLN using Destination-Oriented DAG (DODAG) Information Object (DIO) | LLN using Destination-Oriented DAG (DODAG) Information Object (DIO) | |||
| messages. When two arbitrary routers (neither of which is the DAG's | messages. When two arbitrary routers (neither of which is the DAG's | |||
| root) need to communicate, the data packets are restricted to travel | root) need to communicate, the data packets are restricted to travel | |||
| skipping to change at page 3, line 43 ¶ | skipping to change at page 4, line 43 ¶ | |||
| such routes are considered "good enough" from the application's | such routes are considered "good enough" from the application's | |||
| perspective. This reactive P2P route discovery mechanism is | perspective. This reactive P2P route discovery mechanism is | |||
| henceforth referred to as P2P-RPL. | henceforth referred to as P2P-RPL. | |||
| A mechanism to measure the end-to-end cost of an existing route is | 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 | specified in [I-D.ietf-roll-p2p-measurement]. As discussed in | |||
| Section 4, measuring the end-to-end cost of an existing route may | 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 | help decide whether to initiate the discovery of a better route using | |||
| P2P-RPL and the metric constraints to be used for this purpose. | P2P-RPL and the metric constraints to be used for this purpose. | |||
| 1.1. Known Issues/Future Work | ||||
| This document is presented as an Experimental specification to | This document is presented as an Experimental specification to | |||
| facilitate P2P-RPL's deployment in LLN scenarios where reactive P2P | facilitate P2P-RPL's deployment in LLN scenarios where reactive P2P | |||
| route discovery is considered useful or necessary. It is anticipated | route discovery is considered useful or necessary. It is anticipated | |||
| that, once sufficient operational experience has been gained, this | that, once sufficient operational experience has been gained, this | |||
| specification will be revised to progress it on to the Standards | specification will be revised to progress it on to the Standards | |||
| Track. Experience reports regarding P2P-RPL implementation and | Track. Experience reports regarding P2P-RPL implementation and | |||
| deployment are encouraged particularly with respect to: | deployment are encouraged particularly with respect to: | |||
| o The values in the default DODAG Configuration Option | o Secure P2P-RPL operation (Section 11); | |||
| (Section 6.1); | ||||
| o The rules governing Trickle operation (Section 9.2); | o Rules governing Trickle operation (Section 9.2); | |||
| o The utility and the implementation complexity of the Data Option | o Values in the default DODAG Configuration Option (Section 6.1); | |||
| (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 | o The RPLInstanceID reuse policy (Section 6.1); | |||
| Target addresses in a P2P-RPL route discovery. | ||||
| o Utility and implementation complexity of allowing multiple Target | ||||
| addresses in a P2P-RPL route discovery. | ||||
| 2. The Use Cases | 2. The Use Cases | |||
| One use case, common in home [RFC5826] and commercial building | One use case, common in home [RFC5826] and commercial building | |||
| [RFC5867] environments, involves a device (say a remote control or an | [RFC5867] environments, involves a device (say a remote control) that | |||
| airduct controller) that suddenly needs to communicate with another | suddenly needs to communicate with another device (say a lamp) to | |||
| device (say a lamp or a humidity sensor) to which it does not already | which it does not already have a route (and whose network address it | |||
| have a route. In this case, the remote control (or the airduct | knows apriory). In this case, the remote control must be able to | |||
| controller) must be able to discover a route to the lamp (or the | discover a route to the lamp "on demand". | |||
| humidity sensor) "on demand". | ||||
| Another use case, common in a commercial building environment, | Another use case, common in a commercial building environment, | |||
| involves a large LLN deployment where P2P communication along a | involves a large LLN deployment where P2P communication along a | |||
| particular DAG among hundreds (or thousands) of routers creates | particular DAG among hundreds (or thousands) of routers creates | |||
| severe traffic congestion near that DAG's root, and thus routes | severe traffic congestion near that DAG's root. In this case, it is | |||
| across this DAG are desirable. | 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 | Other use cases involve scenarios where energy or latency constraints | |||
| are not satisfied by the P2P routes along an existing DAG because | are not satisfied by the P2P routes along an existing DAG because | |||
| they involve traversing many more intermediate routers than necessary | they involve traversing many more intermediate routers than necessary | |||
| to reach the destination. | to reach the destination. | |||
| 3. Terminology | 3. Terminology | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
| [RFC2119]. | [RFC2119]. | |||
| Additionally, this document uses terminology from [RFC6550]. This | Additionally, this document uses terminology from [RFC6550] and | |||
| document introduces the following terms: | [I-D.ietf-roll-terminology]. This document introduces the following | |||
| terms: | ||||
| Origin : The IPv6 router initiating the P2P-RPL route discovery. | Origin : The IPv6 router initiating the P2P-RPL route discovery. | |||
| Target : The IPv6 router at the other end point of the P2P route(s) | 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 | to be discovered. A P2P-RPL route discovery can discover routes to | |||
| multiple Targets at the same time. | multiple Targets at the same time. | |||
| Intermediate Router: An IPv6 router that is neither the Origin nor a | Intermediate Router: An IPv6 router that is neither the Origin nor a | |||
| Target. | Target. | |||
| skipping to change at page 5, line 19 ¶ | skipping to change at page 6, line 21 ¶ | |||
| Reverse 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. | Forward Route: A route in the Forward direction. | |||
| Reverse Route: A route in the Reverse direction. | Reverse Route: A route in the Reverse direction. | |||
| Bidirectional Route: A route that can be used in both Forward and | Bidirectional Route: A route that can be used in both Forward and | |||
| Reverse directions. | Reverse directions. | |||
| Ingress-only Interface: A network interface that can only receive | ||||
| packets. | ||||
| Egress-only Interface: A network interface that can only send | ||||
| packets. | ||||
| Source Route: A complete and ordered list of routers that can be used | 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. | 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 | 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. | using its routing table to determine the next hop on the route. | |||
| RPL Security Configuration: The values for Counter is Time, Security | ||||
| Algorithm, Key Identifier Mode and Security Level fields, defined in | ||||
| Section 6.1 of [RFC6550], inside the Security section of a secure RPL | ||||
| control message. | ||||
| 4. Applicability | 4. Applicability | |||
| A route discovery using P2P-RPL may be performed by an Origin when no | 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 | route exists between itself and the Target(s) or when the existing | |||
| routes do not satisfy the application requirements. P2P-RPL is | routes do not satisfy the application requirements. P2P-RPL is | |||
| designed to discover Hop-by-hop or Source Routes to one or more | designed to discover Hop-by-hop or Source Routes to one or more | |||
| Targets such that the discovered routes meet the specified | Targets such that the discovered routes meet the specified | |||
| constraints. In some application contexts, the constraints that the | constraints. In some application contexts, the constraints that the | |||
| discovered routes must satisfy are intrinsically known or can be | discovered routes must satisfy are intrinsically known or can be | |||
| specified by the application. For example, an Origin that expects | specified by the application. For example, an Origin that expects | |||
| skipping to change at page 6, line 19 ¶ | skipping to change at page 7, line 33 ¶ | |||
| Target are nearby. Similarly, a P2P-RPL route may not be much better | 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 | 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 | 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 | those along a global DAG, P2P-RPL routes may still be able to avoid | |||
| congestion that might occur near the root if the routing takes place | congestion that might occur near the root if the routing takes place | |||
| only along a global DAG. In general, the costs associated with a | only along a global DAG. In general, the costs associated with a | |||
| P2P-RPL route discovery (in terms of the control messages, mostly | P2P-RPL route discovery (in terms of the control messages, mostly | |||
| DIOs, generated) increases with the distance between the Origin and | DIOs, generated) increases with the distance between the Origin and | |||
| the Target. However, it is possible to limit the cost of route | the Target. However, it is possible to limit the cost of route | |||
| discovery by carefully setting the routing constraints, the Trickle | discovery by carefully setting the routing constraints, the Trickle | |||
| parameters (that govern the DIO generation) and the lifetime of the | parameters (that govern the DIO generation) and the time duration for | |||
| temporary DAG created for the route discovery. A network designer | which a router maintains its membership in the temporary DAG created | |||
| may take into consideration both the benefits (potentially better | for the route discovery. A network designer may take into | |||
| routes; no need to maintain routes proactively; avoid congestion near | consideration both the benefits (potentially better routes; no need | |||
| the global DAG's root) and costs when using P2P-RPL. The latency | to maintain routes proactively; avoid congestion near the global | |||
| associated with a P2P-RPL route discovery again depends on the | DAG's root) and costs when using P2P-RPL. The latency associated | |||
| distance between the Origin and the Target and the Trickle | with a P2P-RPL route discovery again depends on the distance between | |||
| parameters. | the Origin and the Target and the Trickle parameters. | |||
| Like core RPL [RFC6550], P2P-RPL operation requires links to have | Like core RPL [RFC6550], P2P-RPL operation requires links to have | |||
| bidirectional reachability. Routers participating in a P2P-RPL route | bidirectional reachability. For this reason, the routers | |||
| discovery must ensure that | participating in a P2P-RPL route discovery must ensure that | |||
| o Links that do not have bidirectional reachability do not become | o Links that do not have bidirectional reachability do not become | |||
| part of the route being discovered; and | part of the route being discovered; and | |||
| o IPv6 addresses belonging to egress-only or ingress-only interfaces | o IPv6 addresses belonging to Ingress-only (or Egress-only) | |||
| do not become part of the route being discovered. | Interfaces do not become part of the route being discovered. | |||
| 5. Functional Overview | 5. Functional Overview | |||
| This section contains a high level description of P2P-RPL. | This section contains a high level description of P2P-RPL. | |||
| A P2P-RPL route discovery takes place by forming a DAG rooted at the | 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 | 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, | 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 | this DAG is temporary in nature. The routes are discovered and | |||
| DAG's life time is over. The sole purpose of DAG creation is to | installed while the DAG is alive. Once the specified duration of | |||
| discover routes to the Target(s) and DIOs serve as the route | their membership in the DAG is over, the routers leave the DAG and | |||
| discovery messages. Each router joining the DAG determines a rank | hence the DAG ceases to exist. However, the installed routes are | |||
| for itself in the DAG and ignores the subsequent DIOs received from | retained for their specified life time (which is different than the | |||
| lower (higher in numerical value) ranked neighbors. Thus, the route | specified duration of a router's membership in the DAG) even though | |||
| discovery messages propagate away from the Origin rather than return | the DAG that caused their installation no longer exists. In P2P-RPL, | |||
| back to it. As in core RPL, DIO generation at a router is controlled | the sole purpose of DAG creation is to discover routes to the | |||
| by a Trickle timer [RFC6206] that allows a router to avoid generating | Target(s) and DIOs serve as the route discovery messages. Each | |||
| unnecessary messages while providing protection against packet loss. | router joining the DAG determines a rank for itself in the DAG and | |||
| P2P-RPL also uses the routing metrics [RFC6551], objective functions | ignores the subsequent DIOs received from lower (higher in numerical | |||
| and packet forwarding framework [RFC6554][RFC6553] developed for core | 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. | RPL. | |||
| An Origin may use P2P-RPL to discover routes to one or more Target(s) | 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 | 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 | 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 | Routes per Target. The discovered routes are guaranteed to meet the | |||
| specified routing metric constraints but may not be the best | specified routing metric constraints but may not be the best | |||
| available. P2P-RPL may fail to discover any route if the specified | available. P2P-RPL may fail to discover any route if the specified | |||
| routing constraints are overly strict. P2P-RPL allows an Origin to | routing constraints are overly strict. | |||
| piggyback time-critical application data on the DIO messages for | ||||
| delivery to the Target(s). | ||||
| The Origin initiates a P2P-RPL route discovery by forming a temporary | 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 | DAG rooted at itself. The DIOs used to create the temporary DAG are | |||
| identified by a new Mode of Operation (P2P Route Discovery mode | identified by a new Mode of Operation (P2P Route Discovery mode | |||
| defined in Section 6). The DIOs listing the 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 | 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 | DIOs. A P2P mode DIO always carries exactly one P2P Route Discovery | |||
| Option (defined in Section 7.1) in which the Origin specifies the | Option (P2P-RDO, defined in Section 7) in which the Origin specifies | |||
| following information: | the following information: | |||
| o The IPv6 address of a Target. This could be a unicast address or | o The IPv6 address of a Target. This could be a unicast address or | |||
| a multicast address. 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. | 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- | Routes. This specification allows for the discovery of one Hop- | |||
| by-hop Route or up to four Source Routes per Target. | by-hop Route or up to four Source Routes per Target. | |||
| o The desired number of routes (if Source Routes are being | o The desired number of routes (if Source Routes are being | |||
| discovered). | discovered). | |||
| o Whether the Target(s) should send Discovery Reply Object (DRO) | o Whether the Target(s) should send P2P Discovery Reply Object (P2P- | |||
| messages (defined in Section 8) back to the Origin on receiving a | DRO) messages (defined in Section 8) back to the Origin on | |||
| DIO message. A DRO message carries a discovered Source Route back | receiving a DIO message. A P2P-DRO message carries a discovered | |||
| to the Origin or establishes a Hop-by-hop Route between the Origin | Source Route back to the Origin or establishes a Hop-by-hop Route | |||
| and the Target. By not allowing the generation of DRO messages, | between the Origin and the Target. | |||
| an Origin can use P2P-RPL as purely a mechanism to deliver time- | ||||
| critical application data to the Target(s). | ||||
| A P2P Route Discovery Option also accumulates a route from the Origin | A P2P-RDO also includes the best route from the Origin that the | |||
| to a Target as the routers join the temporary DAG. | router, generating the P2P mode DIO, has seen so far. | |||
| A P2P mode DIO MAY also carry: | A P2P mode DIO MAY also carry: | |||
| o One or more Metric Container Options to specify: | o One or more Metric Container Options to specify: | |||
| * The relevant routing metrics. | * The relevant routing metrics. | |||
| * The constraints that the discovered route must satisfy. These | * The constraints that the discovered route must satisfy. These | |||
| constraints also limit how far the DIOs message may travel. | constraints also limit how far the DIOs message may travel. | |||
| o One or more RPL Target options to specify additional unicast or | o One or more RPL Target options to specify additional unicast or | |||
| multicast Targets. | 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 | 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 | route(s) (so far from the Origin) they have seen and advertise these | |||
| routes, along with the corresponding routing metrics, in their P2P | routes, along with the corresponding routing metrics, in their P2P | |||
| mode DIOs. A router, including the Target(s), discards a received | mode DIOs. A router, including the Target(s), discards a received | |||
| P2P mode DIO if the aggregated routing metrics on the route | P2P mode DIO if the aggregated routing metrics on the route | |||
| advertised by the DIO do not satisfy the listed constraints. These | advertised by the DIO do not satisfy the listed constraints. These | |||
| constraints can be used to limit the propagation of P2P mode DIO | 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 | 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 | does not wish to be a part of the discovered route due to limited | |||
| resources or due to policy reasons. | resources or due to policy reasons. | |||
| When a Target receives a P2P mode DIO, it forwards the data in the | When a Target receives a P2P mode DIO, it contains inside the P2P-RDO | |||
| Data Option, if present, to the higher layer. Since the links in the | a complete Source Route from the Origin to this Target. Since the | |||
| discovered route have bidirectional reachability (Section 7.1), the | links in the discovered route have bidirectional reachability | |||
| Target may remember the discovered route for use as a Source Route to | (Section 7), the Target may use the discovered route to reach the | |||
| reach the Origin. If the Origin has requested DRO messages to be | Origin. Thus, a router that provides a particular service in the LLN | |||
| sent back, the Target may select the route contained in the received | (e.g. an outside temperature server) could initiate a P2P-RPL route | |||
| DIO for further processing as described next. This document does not | discovery listing all its potential clients as Targets, thereby | |||
| specify a particular method for the Target to use to select a route | allowing the clients to discover a Source Route back to the server. | |||
| for further processing. Example methods include selecting any route | In this case, the Origin (the server) might want to disable the | |||
| that meets the constraints or selecting the best route(s) discovered | generation of P2P-DRO messages by the Targets (the clients). If the | |||
| over a certain time period. | Origin has requested P2P-DRO messages to 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 Route(s) are being discovered, the Target sends | 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 | the selected Source Route(s) to the Origin via P2P-DRO messages with | |||
| DRO message carrying one discovered route. On receiving a DRO | one P2P-DRO message carrying one discovered route. On receiving a | |||
| message, the Origin stores the discovered route in its memory. This | P2P-DRO message, the Origin stores the discovered route in its | |||
| specification allows the Origin to discover up to four Source Routes | memory. This specification allows the Origin to discover up to four | |||
| per Target, thereby allowing the Origin to have sufficient ready-to- | Source Routes per Target, thereby allowing the Origin to have | |||
| use alternatives should one or more of these routes fail. If a Hop- | sufficient ready-to-use alternatives should one or more of these | |||
| by-hop Route is being discovered, the Target sends a DRO message | routes fail. If a Hop-by-hop Route is being discovered, the Target | |||
| containing the selected route to the Origin. The DRO message travels | sends a P2P-DRO message containing the selected route to the Origin. | |||
| back to the Origin along the selected route, establishing state for | The P2P-DRO message travels back to the Origin along the selected | |||
| the Forward Route in the routers on the path. The Target may include | route, establishing state for the Forward Route in the routers on the | |||
| a Data Option in a DRO message to deliver any time-critical | path. | |||
| application data to the Origin. | ||||
| The Target may request the Origin to acknowledge the receipt of a DRO | The Target may request the Origin to acknowledge the receipt of a | |||
| message by sending back a DRO Acknowledgement (DRO-ACK) message | P2P-DRO message by sending back a P2P-DRO Acknowledgement (P2P-DRO- | |||
| (defined in Section 10). The Origin unicasts a DRO-ACK message to | ACK) message (defined in Section 10). The Origin unicasts a P2P-DRO- | |||
| the Target. If the Target does not receive the requested DRO-ACK | ACK message to the Target. If the Target does not receive the | |||
| within a certain time interval of sending a DRO, it resends the DRO | requested P2P-DRO-ACK within a certain time interval of sending a | |||
| message (up to a certain number of times) carrying the same route as | P2P-DRO, it resends the P2P-DRO message (up to a certain number of | |||
| before. | times) carrying the same route as before. | |||
| The use of trickle timers to delay the propagation of DIO messages | The use of trickle timers to delay the propagation of DIO messages | |||
| may cause some nodes to generate these messages even when the desired | may cause some nodes to generate these messages even when the desired | |||
| routes have already been discovered. In order to preempt the | routes have already been discovered. In order to preempt the | |||
| generation of such unnecessary messages, the Target may set a "Stop" | generation of such unnecessary messages, the Target may set a "Stop" | |||
| flag in the DRO message to let the nodes in the LLN know about the | flag in the P2P-DRO message to let the nodes in the LLN know about | |||
| completion of the route discovery process. The routers receiving | the completion of the route discovery process. The routers receiving | |||
| such a DRO should not generate any more DIOs for this temporary DAG. | such a P2P-DRO should not generate any more DIOs for this temporary | |||
| Neither should they process any received DIOs for this temporary DAG | DAG. Neither should they process any received DIOs for this | |||
| in future. However, such routers must still process the DROs | temporary DAG in future. However, such routers must still process | |||
| received for this temporary DAG. | the P2P-DROs received for this temporary DAG. | |||
| 6. P2P Route Discovery Mode Of Operation | 6. P2P Route Discovery Mode Of Operation | |||
| This section specifies a new RPL Mode of Operation (MOP), P2P Route | This section specifies a new RPL Mode of Operation (MOP), P2P Route | |||
| Discovery Mode (or P2P mode, for short), with value TBD1. A DIO | Discovery Mode (or P2P mode, for short), with value TBD1. A DIO | |||
| message, listing P2P mode as the MOP, is identified as performing a | 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 | P2P-RPL route discovery by creating a temporary DAG. A P2P mode DIO | |||
| MUST carry exactly one P2P Route Discovery Option (specified in | MUST carry exactly one P2P Route Discovery Option (P2P-RDO, specified | |||
| Section 7.1). | in Section 7). | |||
| 6.1. Setting a P2P Mode DIO | 6.1. Setting a P2P Mode DIO | |||
| The Base Object in a P2P mode DIO message MUST be set in the | The Base Object in a P2P mode DIO message MUST be set in the | |||
| following manner: | following manner: | |||
| o RPLInstanceID: RPLInstanceID MUST be a local value as described in | o RPLInstanceID: RPLInstanceID MUST be a local value as described in | |||
| Section 5.1 of [RFC6550]. The Origin MUST NOT reuse an | Section 5.1 of [RFC6550]. The Origin chooses the RPLInstanceID to | |||
| RPLInstanceID for a route discovery if its previous route | be used for a particular route discovery in accordance with the | |||
| discovery using this RPLInstanceID might still be going on. As | following rules: | |||
| described in Section 7.1, the Life Time parameter in the P2P Route | ||||
| Discovery Option specifies the time duration the route discovery | * The Origin SHOULD NOT reuse an RPLInstanceID for a route | |||
| lasts. So, the Origin MUST NOT reuse an RPLInstanceID in a route | discovery if some routers might still maintain membership in | |||
| discovery until the Life Time of its previous route discovery | the DAG the Origin had initiated for the previous route | |||
| using this RPLInstanceID is over. When initiating a new route | discovery using this RPLInstanceID. As described in Section 7, | |||
| discovery to a particular Target, the Origin MUST NOT reuse the | a router's membership in a DAG created for a P2P-RPL route | |||
| RPLInstanceID used in a previous route discovery to this Target if | discovery lasts for the time duration (say 'l' seconds) | |||
| the previously discovered routes might still exist. The Default | indicated by the L field inside the P2P-RDO. In general, there | |||
| Lifetime and Lifetime Unit parameters in the DODAG Configuration | is no upper bound on the time duration by when all the routers | |||
| Option specify the lifetime of the state the routers, including | have left the DAG created for a P2P-RPL route discovery. In | |||
| the Origin and the Target, maintain for a Hop-by-hop or a Source | the specific case where the discovered route must be at most | |||
| Route discovered using P2P-RPL. Thus, an Origin can safely reuse | 'n' hops in length, all the routers must have left the DAG | |||
| an RPLInstanceID to discover a new route to a Target if the | "(n+1)*l" seconds after its initiation by the Origin. In | |||
| lifetime of all previously discovered routes to this Target using | practice, all the routers should have joined the DAG within 'l' | |||
| this RPLInstanceID is over. | 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*l" 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 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 the | ||||
| routers, including the Origin and the Target, maintain for a | ||||
| Hop-by-hop or a 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*l" seconds of its initiation. Hence, it is | ||||
| sufficient that the Origin lets a time duration equal to | ||||
| "X+2*l" 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: MUST be set to zero. The temporary DAG used for | 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 | P2P-RPL route discovery does not exist long enough to have new | |||
| versions (the Life Time parameter inside the P2P Route Discovery | versions. | |||
| 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 | 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 | RPL instance, the concept of a floating DAG, used to provide | |||
| connectivity within a sub-DAG detached from a grounded DAG, does | connectivity within a sub-DAG detached from a grounded DAG, does | |||
| not apply to a local RPL instance. Hence, an Origin MUST always | 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. | 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 | 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 | and a node MUST NOT initiate a new DAG if it does not have any | |||
| parent left in a P2P-RPL DAG. | parent left in a P2P-RPL DAG. | |||
| skipping to change at page 11, line 51 ¶ | skipping to change at page 13, line 49 ¶ | |||
| o Lifetime Unit: 0xFFFF, to correspond to infinity. | o Lifetime Unit: 0xFFFF, to correspond to infinity. | |||
| o Objective Code Point: 0, i.e., OF0 [RFC6552] is the default | o Objective Code Point: 0, i.e., OF0 [RFC6552] is the default | |||
| objective function. | objective function. | |||
| o The remaining parameters have default values as specified in | o The remaining parameters have default values as specified in | |||
| [RFC6550]. | [RFC6550]. | |||
| Individual P2P-RPL deployments are encouraged to share their | Individual P2P-RPL deployments are encouraged to share their | |||
| experience with these default values with ROLL working group to help | experience with these default values to help guide the development of | |||
| guide the development of standards track version of the protocol. | standards track version of the protocol. | |||
| The routing metrics and constraints [RFC6551] used in P2P-RPL route | The routing metrics and constraints [RFC6551] used in P2P-RPL route | |||
| discovery are included in one or more Metric Container Options | discovery are included in one or more Metric Container Options | |||
| [RFC6550] inside the P2P mode DIO. Note that a DIO need not include | [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 | 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 | 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 | maximum rank, that a router may have in the temporary DAG, inside the | |||
| P2P Route Discovery Option (described in Section 7.1). | P2P-RDO. | |||
| A P2P mode DIO: | A P2P mode DIO: | |||
| o MUST carry one (and only one) P2P Route Discovery Option | o MUST carry one (and only one) P2P-RDO. The P2P-RDO allows for the | |||
| (described in Section 7.1). The P2P Route Discovery Option allows | specification of one unicast or multicast address for the Target. | |||
| for the specification of one unicast or multicast address for the | A received P2P mode DIO MUST be discarded if it does not contain | |||
| Target. A received P2P mode DIO MUST be discarded if it does not | exactly one P2P-RDO. | |||
| contain exactly one P2P Route Discovery Option. | ||||
| o MAY carry one or more RPL Target Options to specify additional | o MAY carry one or more RPL Target Options to specify additional | |||
| unicast/multicast addresses for the Target. | 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 | o MAY carry one or more Metric Container Options to specify routing | |||
| metrics and constraints. | metrics and constraints. | |||
| o MAY carry one Data Option (described in Section 7.2) containing | ||||
| time-critical application data to be delivered to the Target(s). | ||||
| A received P2P mode DIO MUST be discarded if it contains multiple | ||||
| Data Options. | ||||
| o MAY carry one or more Route Information Options [RFC6550]. In the | o MAY carry one or more Route Information Options [RFC6550]. In the | |||
| context of P2P-RPL, a Route Information Option advertizes to the | context of P2P-RPL, a Route Information Option advertizes to the | |||
| Target(s) the Origin's connectivity to the prefix specified in the | Target(s) the Origin's connectivity to the prefix specified in the | |||
| option. | option. | |||
| o MAY carry one or more Prefix Information Options subject to the | An RPL Option, besides the ones listed above, MUST be ignored when | |||
| usage and rules specified in Section 6.7.10 in [RFC6550]. | found inside a received P2P mode DIO and MUST NOT be included in the | |||
| P2P mode DIOs the receiving router generates. | ||||
| 7. New RPL Control Message Options | 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 domain | ||||
| [I-D.ietf-roll-terminology]. | ||||
| This document defines two new RPL control message options: the P2P | 7. P2P Route Discovery Option (P2P-RDO) | |||
| Route Discovery Option and the Data Option. | ||||
| 7.1. 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 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type = TBD2 | Option Length |R|H| N | Compr | L |MaxRank/NH | | | Type = TBD2 | Option Length |R|H| N | Compr | L |MaxRank/NH | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | | |||
| | TargetAddr | | | TargetAddr | | |||
| | | | | | | |||
| skipping to change at page 13, line 27 ¶ | skipping to change at page 15, line 25 ¶ | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | | |||
| | Address[1..n] | | | Address[1..n] | | |||
| | | | | | | |||
| | | | | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 1: Format of P2P Route Discovery Option (P2P-RDO) | Figure 1: Format of P2P Route Discovery Option (P2P-RDO) | |||
| The format of a P2P Route Discovery Option (P2P-RDO) is illustrated | 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 | in Figure 1. A P2P mode DIO and a P2P-DRO (defined in Section 8) | |||
| MUST carry exactly one P2P-RDO. A P2P-RDO consists of the following | message MUST carry exactly one P2P-RDO. A P2P-RDO consists of the | |||
| fields: | following fields: | |||
| o Option Type: TBD2. | o Option Type: TBD2. | |||
| o Option Length: 8-bit unsigned integer, representing the length in | o Option Length: 8-bit unsigned integer, representing the length in | |||
| octets of the option, not including the Option Type and Option | octets of the option, not including the Option Type and Option | |||
| Length fields. | Length fields. | |||
| o Reply (R): The Origin sets this flag to one to allow the Target(s) | 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 | to send P2P-DRO messages back to the Origin. If this flag is | |||
| Target MUST NOT generate any DRO message. | zero, a Target MUST NOT generate any P2P-DRO message. | |||
| o Hop-by-hop (H): This flag is valid only if the R flag is set to | 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 | 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. The Origin sets this flag to zero if it desires Source | |||
| Routes. This specification allows for the establishment of one | 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 | by-hop Route is established in the Forward direction, i.e. from | |||
| the Origin to the Target. This specification does not allow for | the Origin to the Target. This specification does not allow for | |||
| the establishment of Hop-by-hop Routes in the Reverse 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 | 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 | one and H flag is zero, i.e. the Targets are allowed to generate | |||
| DRO messages carrying discovered Source Routes back to the Origin. | P2P-DRO messages carrying discovered Source Routes back to the | |||
| In this case, the value in the N field plus one indicates the | Origin. In this case, the value in the N field plus one indicates | |||
| number of Source Routes that each Target should convey to the | the number of Source Routes that each Target should convey to the | |||
| Origin. When Hop-by-hop Routes are being discovered, the N field | Origin. When Hop-by-hop Routes are being discovered, the N field | |||
| MUST be set to zero on transmission and ignored on reception. | MUST be set to zero on transmission and ignored on reception. | |||
| o Compr: 4-bit unsigned integer indicating the number of prefix | o Compr: 4-bit unsigned integer indicating the number of prefix | |||
| octets that are elided from the Target field and the Address | octets that are elided from the Target field and the Address | |||
| vector. For example, Compr value will be zero if full IPv6 | vector. For example, Compr value will be zero if full IPv6 | |||
| addresses are carried in the Target field and the Address vector. | addresses are carried in the Target field and the Address vector. | |||
| o Life Time (L): A 2-bit field that indicates the life time of the | o Life Time (L): A 2-bit field that indicates the exact duration a | |||
| temporary DAG, i.e., the exact duration a router joining the | router joining the temporary DAG, including the Origin and the | |||
| temporary DAG MUST maintain its membership in the DAG. The | Target(s), MUST maintain its membership in the DAG. A router MUST | |||
| mapping between the values in this field and the life time of the | leave the temporary DAG once the time elapsed since it joined | |||
| temporary DAG is as follows: | 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; | * 0x00: 1 second; | |||
| * 0x01: 4 seconds; | * 0x01: 4 seconds; | |||
| * 0x02: 16 seconds; | * 0x02: 16 seconds; | |||
| * 0x03: 64 seconds; | * 0x03: 64 seconds; | |||
| The Origin sets this field based on its expectation regarding the | The Origin sets this field based on its expectation regarding the | |||
| time required for the route discovery to complete, which includes | time required for the route discovery to complete, which includes | |||
| the time required for the DIOs to reach the Target(s) and the DROs | the time required for the DIOs to reach the Target(s) and the P2P- | |||
| to travel back to the Origin. The time required for the DIOs to | DROs to travel back to the Origin. The time required for the DIOs | |||
| reach the Target(s) would in turn depend on the Trickle parameters | to reach the Target(s) would in turn depend on the Trickle | |||
| (Imin and the redundancy constant) as well as the expected | parameters (Imin and the redundancy constant) as well as the | |||
| distance (in terms of hops and/or ETX) to the Target(s). While | expected distance (in terms of hops and/or ETX) to the Target(s). | |||
| deciding the temporary DAG's lifetime, the Origin should also take | While deciding the value in this field, the Origin should also | |||
| in account the fact that all routers joining the temporary DAG | take in account the fact that all routers joining the temporary | |||
| would need to stay in the DAG for this much time. | DAG would need to stay in the DAG for this much time. | |||
| o MaxRank/NH: | o MaxRank/NH: | |||
| * When a P2P-RDO is included in a P2P mode DIO, this field | * When a P2P-RDO is included in a P2P mode DIO, this field | |||
| indicates the upper limit on the integer portion of the rank | indicates the upper limit on the integer portion of the rank | |||
| (calculated using the DAGRank() macro defined in [RFC6550]) | (calculated using the DAGRank() macro defined in [RFC6550]) | |||
| that a router may have in the temporary DAG being created. An | that a router may have in the temporary DAG being created. An | |||
| Intermediate Router MUST NOT join a temporary DAG being created | Intermediate Router MUST NOT join a temporary DAG being created | |||
| by a P2P mode DIO if the integer portion of its rank would be | 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. | equal to or higher (in numerical value) than the MaxRank limit. | |||
| A Target can join the temporary DAG at a rank whose integer | A Target can join the temporary DAG at a rank whose integer | |||
| portion is equal to the MaxRank. A router MUST discard a | portion is equal to the MaxRank. A router MUST discard a | |||
| received P2P mode DIO if the integer part of the advertized | received P2P mode DIO if the integer part of the advertized | |||
| rank equals or exceeds the MaxRank limit. A value 0 in this | rank equals or exceeds the MaxRank limit. A value 0 in this | |||
| field indicates that the MaxRank is infinity. | field indicates that the MaxRank is infinity. | |||
| * When a P2P-RDO is included in a DRO message, this field | * When a P2P-RDO is included in a P2P-DRO message, this field | |||
| indicates the index of the next hop address inside the Address | indicates the index of the next hop address inside the Address | |||
| vector. | vector. | |||
| o TargetAddr: An IPv6 address of the Target after eliding Compr | o TargetAddr: An IPv6 address of the Target after eliding Compr | |||
| number of prefix octets. When the P2P-RDO is included in a P2P | 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 | mode DIO, this field may contain a unicast address or a multicast | |||
| address. Any additional Target addresses can be specified by | address. If a unicast address is specified, it MUST be a global | |||
| including one or more RPL Target Options [RFC6550] in the DIO. | address or a unique local address. Any additional Target | |||
| When the P2P-RDO is included in a DRO, this field MUST contain a | addresses can be specified by including one or more RPL Target | |||
| unicast IPv6 address of the Target generating the DRO. | 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]: A vector of IPv6 addresses representing a complete | o Address[1..n]: A vector of IPv6 addresses representing a complete | |||
| route so far in the Forward direction: | route so far in the Forward direction: | |||
| * Each element in the Address vector has size (16 - Compr) octets | * Each element in the Address vector has size (16 - Compr) octets | |||
| and MUST contain a valid IPv6 address with first Compr octets | and MUST contain a valid global or unique local IPv6 address | |||
| elided. | with first Compr octets elided. | |||
| * The total number of elements inside the Address vector is given | * The total number of elements inside the Address vector is given | |||
| by n = (Option Length - 2 - (16 - Compr))/(16 - Compr). | by n = (Option Length - 2 - (16 - Compr))/(16 - Compr). | |||
| * IPv6 addresses of ingress-only (or egress-only) router | * The IPv6 address that a router adds to the vector MUST belong | |||
| interfaces MUST NOT be added to the Address vector. This | to the interface on which the router received the DIO | |||
| allows the route accumulated in the Address vector to be a | containing this P2P-RDO. Further, this interface MUST NOT be | |||
| Bidirectional Route that can be used by a Target to send a DRO | an Ingress-only Interface. This allows the route accumulated | |||
| message to the Origin. | 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. | ||||
| * The Address vector MUST carry the accumulated route in the | * The Address vector MUST carry the accumulated route in the | |||
| Forward direction, i.e., the first element in the Address | Forward direction, i.e., the first element in the Address | |||
| vector must contain the IPv6 address of the router next to the | vector must contain the IPv6 address of the router next to the | |||
| Origin and so on. | Origin and so on. | |||
| * The Origin and Target addresses MUST NOT be included in the | * The Origin and Target addresses MUST NOT be included in the | |||
| Address vector. | Address vector. | |||
| * A router adding its address to the vector MUST ensure that any | * A router adding its address to the vector MUST ensure that any | |||
| of its addresses do not already exist in the vector. A Target | of its addresses do not already exist in the vector. A Target | |||
| specifying a complete route in the Address vector MUST ensure | specifying a complete route in the Address vector MUST ensure | |||
| that the vector does not contain any address more than once. | that the vector does not contain any address more than once. | |||
| * The Address vector MUST NOT contain any multicast addresses. | * The Address vector MUST NOT contain any multicast addresses. | |||
| 7.2. Data Option | 8. The P2P Discovery Reply Object (P2P-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 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Type = TBD3 | Option Length | UpperLayerPrt | Data | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | ||||
| Figure 2: Format of Data Option | ||||
| The format of a Data Option is illustrated in Figure 2. A P2P mode | ||||
| DIO and a DRO (defined in Section 8) message MAY carry one Data | ||||
| Option. A P2P-RDO consists of the following fields: | ||||
| o Option Type: TBD3. | ||||
| o Option Length: An 8-bit unsigned integer, representing the length | ||||
| in octets of the option, not including the Option Type and Option | ||||
| Length fields. | ||||
| o Upper Layer Protocol: An 8-bit field that identifies the upper | ||||
| layer protocol header with which the information in the Data field | ||||
| starts. The protocol identifiers used in this field are same as | ||||
| those defined in IANA's "Protocol Numbers" registry [PROTOCOL]. | ||||
| o Data: If the Data Option is contained in a DIO, this field | ||||
| contains application data to be delivered to the Target(s). If | ||||
| the Data Option is contained in a DRO, this field contains | ||||
| application data to be delivered to the Origin. | ||||
| If the Origin chooses to include a Data Option inside its DIO, it | ||||
| MUST include the same Data Option in all its future DIO transmissions | ||||
| for this temporary DAG. An Intermediate Router MUST NOT modify the | ||||
| Data Option received inside a parent's DIO and MUST include this Data | ||||
| Option in all its future DIO transmissions for this temporary DAG. | ||||
| The same is true for a Target that needs to propagate the DIOs | ||||
| further (required when the route discovery involves multiple | ||||
| Targets). If a Target chooses to include a Data Option inside a DRO, | ||||
| it MUST include the same Data Option in all retransmissions of this | ||||
| DRO message and MUST NOT include a different Data Option in any other | ||||
| DRO messages it generates for this route discovery. Also, an | ||||
| Intermediate Router, which needs to forward a received DRO message | ||||
| further, MUST include in the forwarded message a verbatim copy of the | ||||
| Data Option found inside the received message. | ||||
| Note that the data inside a Data Option has the same level of | ||||
| security as the DIO/DRO message it is part of. A P2P-RPL deployment | ||||
| SHOULD take in consideration the security requirements of the data | ||||
| being sent inside the Data Options when deciding the overall security | ||||
| requirements. Further, note that P2P-RPL does not guarantee | ||||
| successful delivery of the data contained in a Data Option. | ||||
| 8. The Discovery Reply Object (DRO) | ||||
| This section defines two new RPL Control Message types, the Discovery | This section defines two new RPL Control Message types, the P2P | |||
| Reply Object (DRO), with code TBD4, and the Secure DRO, with code | Discovery Reply Object (P2P-DRO), with code TBD3, and the Secure P2P- | |||
| TBD5. A DRO serves one of the following functions: | DRO, with code TBD4. A P2P-DRO serves one of the following | |||
| functions: | ||||
| o Carry a discovered Source Route from a Target to the Origin; | 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 | o Establish a Hop-by-hop Route as it travels from a Target to the | |||
| Origin. | Origin. | |||
| A DRO message MAY serve the function of letting the routers in the | A P2P-DRO message can also serve the function of letting the routers | |||
| LLN know that a P2P-RPL route discovery is complete and no more DIO | in the LLN know that a P2P-RPL route discovery is complete and no | |||
| messages need to be generated for the corresponding temporary DAG. A | more DIO messages need to be generated for the corresponding | |||
| DRO message MAY also carry time-critical application data from the | temporary DAG. A P2P-DRO message MUST carry one (and only one) P2P- | |||
| Target to the Origin in a Data Option. A DRO message MUST carry one | RDO whose TargetAddr field MUST contain a unicast IPv6 address of the | |||
| (and only one) P2P-RDO whose TargetAddr field MUST contain a unicast | Target that generates the P2P-DRO. A P2P-DRO message MUST travel | |||
| IPv6 address of the Target that generates the DRO. A DRO message | from the Target to the Origin via link-local multicast along the | |||
| travels from the Target to the Origin via link-local multicast along | route specified inside the Address vector in the P2P-RDO, as included | |||
| the route specified inside the Address vector in the P2P-RDO, as | in the P2P-DRO. The IPv6 source address in a P2P-DRO message MUST be | |||
| included in the DRO. | 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 domain [I-D.ietf-roll-terminology]. | ||||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | RPLInstanceID | Version |S|A|Seq| Reserved | | | RPLInstanceID | Version |S|A|Seq| Reserved | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | | |||
| | DODAGID | | | DODAGID | | |||
| | | | | | | |||
| | | | | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Option(s)... | | Option(s)... | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | |||
| Figure 3: Format of the base Discovery Reply Object (DRO) | Figure 2: Format of the base P2P Discovery Reply Object (P2P-DRO) | |||
| The format of the base Discovery Reply Object (DRO) is shown in | The format of the base P2P Discovery Reply Object (P2P-DRO) is shown | |||
| Figure 3. A base DRO consists of the following fields: | in Figure 2. A base P2P-DRO consists of the following fields: | |||
| o RPLInstanceID: The RPLInstanceID of the temporary DAG used for | o RPLInstanceID: The RPLInstanceID of the temporary DAG used for | |||
| route discovery. | route discovery. | |||
| o Version: The Version of the temporary DAG used for route | o Version: The Version of the temporary DAG used for route | |||
| discovery. Since a temporary DAG always has value zero for the | discovery. Since a temporary DAG always has value zero for the | |||
| Version, this field MUST always be set to zero. | Version, this field MUST always be set to zero. | |||
| o Stop (S): This flag, when set to one by a Target, indicates that | 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 | the P2P-RPL route discovery is over. All the routers receiving | |||
| such a DRO, including the ones not listed in the route carried | such a P2P-DRO, including the ones not listed in the route carried | |||
| inside P2P-RDO, | inside P2P-RDO, | |||
| * SHOULD NOT process any more DIOs received for this temporary | * SHOULD NOT process any more DIOs received for this temporary | |||
| DAG; | DAG; | |||
| * SHOULD NOT generate any more DIOs for this temporary DAG; | * SHOULD NOT generate any more DIOs for this temporary DAG; | |||
| * SHOULD cancel any pending DIO transmission for this temporary | * SHOULD cancel any pending DIO transmission for this temporary | |||
| DAG. | DAG. | |||
| Note that the Stop flag serves to stop further DIO generation/ | Note that the Stop flag serves to stop further DIO generation/ | |||
| processing for a P2P-RPL route discovery but it does not affect | processing for a P2P-RPL route discovery but it does not affect | |||
| the processing of DRO messages at either the Origin or the | the processing of P2P-DRO messages at either the Origin or the | |||
| Intermediate Routers. In other words, a router (the Origin or an | Intermediate Routers. In other words, a router (the Origin or an | |||
| Intermediate Router) MUST continue to process the DRO messages | Intermediate Router) MUST continue to process the P2P-DRO messages | |||
| even if an earlier DRO message (with the same RPLInstanceID and | even if an earlier P2P-DRO message (with the same RPLInstanceID | |||
| DODAGID fields) had the Stop flag set to one. When set to zero, | and DODAGID fields) had the Stop flag set to one. When set to | |||
| this flag does not imply any thing and MUST be ignored on | zero, this flag does not imply any thing and MUST be ignored on | |||
| reception. | reception. | |||
| o Ack Required (A): This flag, when set to one by the Target, | o Ack Required (A): This flag, when set to one by the Target, | |||
| indicates that the Origin MUST unicast a DRO-ACK message (defined | indicates that the Origin MUST unicast a P2P-DRO-ACK message | |||
| in Section 10) to the Target when it receives the DRO. | (defined in Section 10) to the Target when it receives the P2P- | |||
| DRO. | ||||
| o Sequence Number (Seq): This 2-bit field indicates the sequence | 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 | number for the P2P-DRO. This field is relevant when the A flag is | |||
| to one, i.e., the Target requests an acknowledgement from the | set to one, i.e., the Target requests an acknowledgement from the | |||
| Origin for a received DRO. The Origin includes the RPLInstanceID, | Origin for a received P2P-DRO. The Origin includes the | |||
| the DODAGID and the Sequence Number of the received DRO inside the | RPLInstanceID, the DODAGID and the Sequence Number of the received | |||
| DRO-ACK message it sends back to the Target. | 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 | o Reserved: These bits are reserved for future use. These bits MUST | |||
| be set to zero on transmission and MUST be ignored on reception. | be set to zero on transmission and MUST be ignored on reception. | |||
| o DODAGID: The DODAGID of the temporary DAG used for route | o DODAGID: The DODAGID of the temporary DAG used for route | |||
| discovery. The DODAGID also identifies the Origin. The | discovery. The DODAGID also identifies the Origin. The | |||
| RPLInstanceID, the Version and the DODAGID together uniquely | RPLInstanceID, the Version and the DODAGID together uniquely | |||
| identify the temporary DAG used for route discovery and can be | identify the temporary DAG used for route discovery and can be | |||
| copied from the DIO message advertizing the temporary DAG. | copied from the DIO message advertizing the temporary DAG. | |||
| o Options: The DRO message: | o Options: The P2P-DRO message: | |||
| * MUST carry one (and only one) P2P-RDO that MUST specify a | * MUST carry one (and only one) P2P-RDO that MUST specify a | |||
| complete route between the Target and the Origin; | 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 contains | * MAY carry one or more Metric Container Options that contains | |||
| the aggregated routing metrics values for the route specified | the aggregated routing metrics values for the route specified | |||
| in P2P-RDO; | in P2P-RDO. | |||
| * MAY carry one Data Option to carry any time-critical | ||||
| application data to the Origin, subject to the following | ||||
| conditions: if a Target chooses to include a Data Option inside | ||||
| a DRO, | ||||
| + it MUST include the same Data Option in all retransmissions | ||||
| of this DRO message and | ||||
| + it MUST NOT include a different Data Option in any other DRO | ||||
| messages it generates for this route discovery. | ||||
| The Target MAY repeat the same Data Option in multiple DRO | ||||
| messages it generates for a particular route discovery. | ||||
| A received DRO message MUST be discarded if it does not contain | An RPL Option, besides the ones listed above, MUST be ignored when | |||
| exactly one P2P-RDO or if it contains multiple Data Options. | found inside a received P2P-DRO message. | |||
| 8.1. Secure DRO | 8.1. Secure P2P-DRO | |||
| A Secure DRO message follows the format in Figure 7 of [RFC6550], | A Secure P2P-DRO message follows the format in Figure 7 of [RFC6550], | |||
| where the base format is the base DRO shown in Figure 3. | where the base format is the base P2P-DRO shown in Figure 2. | |||
| 8.2. Setting a P2P-RDO Carried in a Discovery Reply Object | 8.2. Setting a P2P-RDO Carried in a P2P Discovery Reply Object | |||
| A Discovery Reply Object MUST carry one (and only one) P2P-RDO, which | A P2P Discovery Reply Object MUST carry one (and only one) P2P-RDO, | |||
| MUST be set as defined in Section 7.1. Specifically, the following | which MUST be set as defined in Section 7. Specifically, the | |||
| fields MUST be set as specified next: | following fields MUST be set as specified next: | |||
| o Reply (R): This flag MUST be set to zero on transmission and | o Reply (R): This flag MUST be set to zero on transmission and | |||
| ignored on reception. | ignored on reception. | |||
| o Hop-by-Hop (H): The H flag in the P2P-RDO included in a DRO | 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 | message MUST have the same value as the H flag in the P2P-RDO | |||
| inside the corresponding DIO message. | inside the corresponding DIO message. | |||
| o Number of Routes (N): This field MUST be set to zero on | o Number of Routes (N): This field MUST be set to zero on | |||
| transmission and ignored on reception. | transmission and ignored on reception. | |||
| o Life Time (L): This field MUST be set to zero on transmission and | o Life Time (L): This field MUST be set to zero on transmission and | |||
| ignored on reception. | ignored on reception. | |||
| o MaxRank/NH: This field indicates the index of the next hop address | 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 | in the Address vector. When a Target generates a P2P-DRO message, | |||
| NH field is set to n = (Option Length - 2 - (16 - Compr))/(16 - | the NH field is set to n = (Option Length - 2 - (16 - Compr))/(16 | |||
| Compr). | - Compr). | |||
| o TargetAddr: This field MUST contain a unicast IPv6 address of the | o TargetAddr: This field MUST contain a unicast global or unique | |||
| Target generating the DRO. | local IPv6 address of the Target generating the P2P-DRO. | |||
| o Address[1..n]: The Address vector MUST contain a complete route | o Address[1..n]: The Address vector MUST contain a complete route | |||
| between the Origin and the Target such that the first element in | between the Origin and the Target such that the first element in | |||
| the vector contains the IPv6 address of the router next to the | the vector contains the IPv6 address of the router next to the | |||
| Origin and the last element contains the IPv6 address of the | Origin and the last element contains the IPv6 address of the | |||
| router next to the Target. | router next to the Target. | |||
| 9. P2P-RPL Route Discovery By Creating a Temporary DAG | 9. P2P-RPL Route Discovery By Creating a Temporary DAG | |||
| This section details the P2P-RPL route discovery operation. | This section details the P2P-RPL route discovery operation. | |||
| 9.1. Joining a Temporary DAG | 9.1. Joining a Temporary DAG | |||
| All the routers participating in a P2P-RPL route discovery, including | All the routers participating in a P2P-RPL route discovery, including | |||
| the Origin and the Target(s), MUST join the temporary DAG being | the Origin and the Target(s), MUST join the temporary DAG being | |||
| created for the purpose. When a router joins a temporary DAG | created for the purpose. When a router joins a temporary DAG | |||
| advertized by a P2P mode DIO, it MUST maintain its membership in the | 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 | temporary DAG for the duration indicated by the L field inside the | |||
| only purpose of a temporary DAG's existence is to facilitate the P2P- | P2P-RDO. The only purpose of a temporary DAG's existence is to | |||
| RPL route discovery process. The temporary DAG MUST NOT be used to | facilitate the P2P-RPL route discovery process. The temporary DAG | |||
| route packets. A router MUST detach from the temporary DAG once the | MUST NOT be used to route data packets. In other words, joining a | |||
| duration of its membership in the DAG has reached the DAG's life | temporary DAG does not allow a router to provision routing table | |||
| time. After receiving a DRO with the Stop flag set to one, a router | entries listing the router's parents in the temporary DAG as the next | |||
| SHOULD NOT send or receive any more DIOs for this temporary DAG and | hops (i.e., the last bullet point in Section 3.2.8 of [RFC6550] is | |||
| SHOULD also cancel any pending DIO transmission. | 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 that 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 transmission. | ||||
| 9.2. Trickle Operation For P2P Mode DIOs | 9.2. Trickle Operation For P2P Mode DIOs | |||
| An RPL router uses a Trickle timer [RFC6206] to control DIO | An RPL router uses a Trickle timer [RFC6206] to control DIO | |||
| transmissions. The Trickle control of DIO transmissions provides | transmissions. The Trickle control of DIO transmissions provides | |||
| quick resolution of any "inconsistency" while avoiding redundant DIO | quick resolution of any "inconsistency" while avoiding redundant DIO | |||
| transmissions. The Trickle algorithm also imparts protection against | transmissions. The Trickle algorithm also imparts protection against | |||
| loss of DIOs due to inherent lack of reliability in LLNs. When | loss of DIOs due to inherent lack of reliability in LLNs. When | |||
| controlling the transmissions of a P2P mode DIO, a Trickle timer | controlling the transmissions of a P2P mode DIO, a Trickle timer | |||
| SHOULD follow the following rules: | SHOULD follow the following rules: | |||
| skipping to change at page 22, line 8 ¶ | skipping to change at page 23, line 18 ¶ | |||
| reset their trickle timers and generate more DIOs. Thus, for | reset their trickle timers and generate more DIOs. Thus, for | |||
| highly connected networks, the Imin parameter SHOULD be set to a | highly connected networks, the Imin parameter SHOULD be set to a | |||
| value at least one order of magnitude larger than the typical | value at least one order of magnitude larger than the typical | |||
| transmission delay for a DIO. For sparsely connected networks, | transmission delay for a DIO. For sparsely connected networks, | |||
| the Imin parameter can be set to a value that is a small multiple | 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 | 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 | 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- | discovery to complete. In general, the time required for a P2P- | |||
| RPL route discovery would increase approximately linearly with the | RPL route discovery would increase approximately linearly with the | |||
| value of the Imin parameter. Since the route discovery must | value of the Imin parameter. Since the route discovery must | |||
| complete within the lifetime of the temporary DAG created for the | complete while the Origin still belongs to the temporary DAG | |||
| purpose, the Origin should set this lifetime to a large enough | created for the purpose, the Origin should set the time duration a | |||
| value taking in account the Imin value as well as the expected | router maintains its membership in the temporary DAG (indicated by | |||
| distance (in terms of hops and/or ETX) to the Target(s). | the L field inside the P2P-RDO) to a large enough value taking in | |||
| account the Imin value as well as the expected distance (in terms | ||||
| of hops and/or ETX) to the Target(s). | ||||
| o The Imax parameter SHOULD be set to a large value (several orders | 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 | of magnitude higher than the Imin value) and is unlikely to be | |||
| critical for P2P-RPL operation. This is because the first receipt | critical for P2P-RPL operation. This is because the first receipt | |||
| of a P2P mode DIO for a particular temporary DAG is considered an | of a P2P mode DIO for a particular temporary DAG is considered an | |||
| inconsistent event and would lead to resetting of Trickle timer | inconsistent event and would lead to resetting of Trickle timer | |||
| duration to the Imin value. Given the temporary nature of the | duration to the Imin value. Given the temporary nature of the | |||
| DAGs used in P2P-RPL, Trickle timer may not get a chance to | DAGs used in P2P-RPL, Trickle timer may not get a chance to | |||
| increase much. | increase much. | |||
| skipping to change at page 22, line 45 ¶ | skipping to change at page 24, line 9 ¶ | |||
| process to complete needs to be as small as possible; or | process to complete needs to be as small as possible; or | |||
| * Deployments where specific destinations are reachable only | * Deployments where specific destinations are reachable only | |||
| through specific intermediate routers (and hence these | through specific intermediate routers (and hence these | |||
| intermediate routers should not suppress their DIOs). | intermediate routers should not suppress their DIOs). | |||
| A particular deployment should take in account the above mentioned | A particular deployment should take in account the above mentioned | |||
| factors when deciding the value of the redundancy constant. | factors when deciding the value of the redundancy constant. | |||
| Individual P2P-RPL deployments are encouraged to share their | Individual P2P-RPL deployments are encouraged to share their | |||
| experience with these rules with ROLL working group to help guide the | experience with these rules to help guide the development of | |||
| development of standards track version of the protocol. | standards track version of the protocol. Applicability Statements | |||
| Applicability Statements that specify the use of P2P-RPL MUST provide | that specify the use of P2P-RPL MUST provide guidance for setting | |||
| guidance for setting Trickle parameters, particularly Imin and the | Trickle parameters, particularly Imin and the redundancy constant. | |||
| redundancy constant. | ||||
| 9.3. Processing a P2P Mode DIO | 9.3. Processing a P2P Mode DIO | |||
| The rules for DIO processing and transmission, described in Section 8 | The rules for DIO processing and transmission, described in Section 8 | |||
| of RPL [RFC6550], apply to P2P mode DIOs as well except as modified | of RPL [RFC6550], apply to P2P mode DIOs as well except as modified | |||
| in this document. In particular, in accordance with Section 8.2.3 of | 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 | RPL [RFC6550], a received P2P mode DIO MUST be discarded if it is | |||
| malformed according to the rules specified in this document and in | malformed according to the rules specified in this document and in | |||
| [RFC6550]. | [RFC6550]. | |||
| skipping to change at page 23, line 26 ¶ | skipping to change at page 24, line 35 ¶ | |||
| A router SHOULD discard a received P2P mode DIO with no further | A router SHOULD discard a received P2P mode DIO with no further | |||
| processing if it does not have bidirectional reachability with the | processing if it does not have bidirectional reachability with the | |||
| neighbor that generated the received DIO. Note that bidirectional | neighbor that generated the received DIO. Note that bidirectional | |||
| reachability does not mean that the link must have the same values | reachability does not mean that the link must have the same values | |||
| for a routing metric in both directions. A router SHOULD calculate | for a routing metric in both directions. A router SHOULD calculate | |||
| the values of the link-level routing metrics included in the received | the values of the link-level routing metrics included in the received | |||
| DIO taking in account the metric's value in both Forward and Reverse | DIO taking in account the metric's value in both Forward and Reverse | |||
| directions. Bidirectional reachability along a discovered route | directions. Bidirectional reachability along a discovered route | |||
| allows the Target to use this route to reach the Origin. In | allows the Target to use this route to reach the Origin. In | |||
| particular, the DRO messages travel from the Target to the Origin | particular, the P2P-DRO messages travel from the Target to the Origin | |||
| along a discovered route. | along a discovered route. | |||
| A router MUST discard a received P2P mode DIO with no further | A router MUST discard a received P2P mode DIO with no further | |||
| processing: | processing: | |||
| o If the DIO advertises INFINITE_RANK as defined in Section 17 of | o If the DIO advertises INFINITE_RANK as defined in Section 17 of | |||
| [RFC6550]. | [RFC6550]. | |||
| o If the integer part of the rank advertised in the DIO equals or | o If the integer part of the rank advertised in the DIO equals or | |||
| exceeds the MaxRank limit listed in the P2P Route Discovery | exceeds the MaxRank limit listed in the P2P Route Discovery | |||
| Option. | Option. | |||
| o If the routing metric values do not satisfy one or more of the | 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 | mandatory route constraints listed in the DIO or if the router | |||
| cannot evaluate the mandatory route constraints, e.g., if the | cannot evaluate the mandatory route constraints, e.g., if the | |||
| router does not support the metrics used in the constraints. | router does not support the metrics used in the constraints. | |||
| o If the router previously received a DRO message with the same | o If the router previously received a P2P-DRO message with the same | |||
| RPLInstanceID and DODAGID as the received DIO and with the Stop | RPLInstanceID and DODAGID as the received DIO and with the Stop | |||
| flag set to one. | flag set to one. | |||
| The router MUST check the Target addresses listed in the P2P-RDO and | 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 | 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 | 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 | multicast group specified as one of the Target addresses, the router | |||
| considers itself a Target and processes the received DIO as specified | considers itself a Target and processes the received DIO as specified | |||
| in Section 9.5. Otherwise, the router considers itself an | in Section 9.5. Otherwise, the router considers itself an | |||
| Intermediate Router and processes the received DIO as specified in | Intermediate Router and processes the received DIO as specified in | |||
| Section 9.4. | Section 9.4. | |||
| 9.4. Additional Processing of a P2P Mode DIO At An Intermediate Router | 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 | An Intermediate Router MUST discard a received P2P mode DIO with no | |||
| further processing if the router cannot elide Compr (as specified in | further processing | |||
| the P2P-RDO) prefix octets from its IPv6 address or if adding its | ||||
| IPv6 address to the Address vector (inside the P2P-RDO) would result | o if the DIO is received on an Ingress-only Interface; or | |||
| in the Address vector containing multiple, non-back-to-back addresses | ||||
| belonging to this router. | 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 can not 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 | On receiving a P2P mode DIO, an Intermediate Router MUST do the | |||
| following: | 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 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. | ||||
| o The router MUST determine whether this DIO advertises a better | When an Intermediate Router adds an IPv6 address to a route, it MUST | |||
| route than the router itself and whether the receipt of the DIO | ensure that | |||
| 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 | ||||
| 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 | o the IPv6 address is a unicast global or unique local IPv6 address | |||
| DIO transmissions) if the received DIO comes from a parent and is | assigned to the interface on which the DIO containing the route | |||
| the first parent-originated DIO received with a Data Option | was received; | |||
| inside. | ||||
| 9.5. Additional Processing of a P2P Mode DIO At The Target | o the IPv6 address was configured with the address prefix implied by | |||
| the Compr field in the P2P-RDO inside the received DIO; | ||||
| The Target MUST determine if the received DIO contains a Data Option | To improve the diversity of the routes being discovered, an | |||
| and deliver the data to the specified upper layer protocol unless it | Intermediate Router SHOULD keep track of multiple routes (as long as | |||
| has already done so in response to a previously received DIO. If | all these routes are the best seen so far), one of which SHOULD be | |||
| this route discovery involves multiple Targets, the Target MUST | selected in a uniform random manner for inclusion in the P2P-RDO | |||
| remember this Data Option for inclusion in its own DIOs. | 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. | ||||
| The Target MAY store the route contained in the P2P-RDO in the | 9.5. Additional Processing of a P2P Mode DIO At The Target | |||
| 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 zero, the | The Target MAY remember the discovered route contained in the P2P-RDO | |||
| Target MUST discard the received DIO with no further processing. | in the received DIO for use as a Source Route to reach the Origin. | |||
| Otherwise, the Target MAY select the route contained in the P2P-RDO | The lifetime of this Source Route is specified by the Default | |||
| to send a DRO message back to the Origin. If the H flag inside the | Lifetime and Lifetime Unit parameters inside the DODAG Configuration | |||
| P2P-RDO is one, the Target needs to select one route and send a DRO | Option currently in effect. This lifetime can be extended (or | |||
| message along this route back to the Origin. If the H flag is zero, | shortened) appropriately following a hint from an upper-layer | |||
| the number of routes to be selected (and the number of DRO messages | protocol. | |||
| to be sent back) is given by one plus the value of the N field in the | ||||
| P2P-RDO. This document does not prescribe a particular method for | If the Reply flag inside the P2P-RDO in the received DIO is set to | |||
| the Target to select the routes. Example methods include selecting | one, the Target MUST select one or more discovered routes and send | |||
| each route that meets the specified routing constraints until the | one or more P2P-DRO messages, carrying one discovered route each, | |||
| desired number have been selected or selecting the best routes | back to the Origin. If the H flag inside the P2P-RDO is set to one, | |||
| discovered over a certain time period. If multiple routes are to be | the Target needs to select one route and send a P2P-DRO message along | |||
| selected, the Target SHOULD avoid selecting routes that have large | this route back to the Origin. As this P2P-DRO message travels back | |||
| segments in common. | to the Origin, the routers on the path establish 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 of) the route(s) 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 have 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 | If the Target selects the route contained in the P2P-RDO in the | |||
| received DIO, it sends a DRO message back to the Origin (identified | received DIO, it sends a P2P-DRO message back to the Origin | |||
| by the DODAGID field in the DIO). The DRO message MUST include a | (identified by the DODAGID field in the DIO). The P2P-DRO message | |||
| P2P-RDO that contains the selected route inside the Address vector. | MUST include a P2P-RDO that contains the selected route inside the | |||
| Various fields inside the P2P-RDO MUST be set as specified in | Address vector. Various fields inside the P2P-RDO MUST be set as | |||
| Section 8.2. The Target MAY set the A flag inside the DRO message to | specified in Section 8.2. The Target MAY set the A flag inside the | |||
| one if it desires the Origin to send back a DRO-ACK message on | P2P-DRO message to one if it desires the Origin to send back a P2P- | |||
| receiving the DRO. In this case, the Target waits for | DRO-ACK message on receiving the P2P-DRO. In this case, the Target | |||
| DRO_ACK_WAIT_TIME duration for the DRO-ACK message to arrive. | waits for P2P_DRO_ACK_WAIT_TIME duration for the P2P-DRO-ACK message | |||
| Failure to receive the DRO-ACK message within this time duration | to arrive. Failure to receive the P2P-DRO-ACK message within this | |||
| causes the Target to retransmit the DRO message. The Target MAY | time duration causes the Target to retransmit the P2P-DRO message. | |||
| retransmit the DRO message in this fashion up to | The Target MAY retransmit the P2P-DRO message in this fashion up to | |||
| MAX_DRO_RETRANSMISSIONS times. Both DRO_ACK_WAIT_TIME and | MAX_P2P_DRO_RETRANSMISSIONS times. Both P2P_DRO_ACK_WAIT_TIME and | |||
| MAX_DRO_RETRANSMISSIONS are configurable parameters to be decided | MAX_P2P_DRO_RETRANSMISSIONS are configurable parameters to be decided | |||
| based on the characteristics of individual deployments. Note that | based on the characteristics of individual deployments. Note that | |||
| all DRO transmissions and retransmissions MUST take place while the | all P2P-DRO transmissions and retransmissions MUST take place while | |||
| Target is still a part of the temporary DAG created for the route | 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 | discovery. A Target MUST NOT transmit a P2P-DRO if it no longer | |||
| to this DAG. | belongs to this DAG. | |||
| The Target MAY set the Stop flag inside the DRO message to one if | 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, | o this router is the only Target specified in the corresponding DIO, | |||
| i.e., the corresponding DIO specified a unicast address of the | i.e., the corresponding DIO specified a unicast address of the | |||
| router as the TargetAddr inside the P2P-RDO with no additional | router as the TargetAddr inside the P2P-RDO with no additional | |||
| Targets specified via RPL Target Options; and | Targets specified via RPL Target Options; and | |||
| o the Target has already selected the desired number of routes. | o the Target has already selected the desired number of routes. | |||
| The Target MAY include a Metric Container Option in the DRO message. | The Target MAY include a Metric Container Option in the P2P-DRO | |||
| This Metric Container contains the end-to-end routing metric values | message. This Metric Container contains the end-to-end routing | |||
| for the route specified in the P2P-RDO. The Target MAY include one | metric values for the route specified in the P2P-RDO. The Target | |||
| Data Option in the DRO message to carry time-critical application | MUST transmit the P2P-DRO message via a link-local multicast. | |||
| 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 | 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 | 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 | this Target) is specified as the TargetAddr inside the P2P-RDO and no | |||
| additional Targets are specified via RPL Target Options inside the | 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. Otherwise, the Target MUST generate | |||
| DIOs for this route discovery as an Intermediate Router would. | DIOs for this route discovery as an Intermediate Router would. | |||
| 9.6. Processing a DRO At An Intermediate Router | 9.6. Processing a P2P-DRO At An Intermediate Router | |||
| If the DODAGID field in the received DRO does not list a router's own | If the DODAGID field in the received P2P-DRO does not list a router's | |||
| IPv6 address, the router considers itself an Intermediate Router and | own IPv6 address, the router considers itself an Intermediate Router | |||
| MUST process the received message in the following manner: | and MUST process the received message in the following manner: | |||
| o The router MUST discard the received DRO with no further | o The router MUST discard the received P2P-DRO with no further | |||
| processing if it does not belong to the temporary DAG identified | processing if it does not belong to the temporary DAG identified | |||
| by the RPLInstanceID and the DODAGID fields in the DRO. | by the RPLInstanceID and the DODAGID fields in the P2P-DRO. | |||
| o If the Stop flag inside the received DRO is set to one, the router | o If the Stop flag inside the received P2P-DRO is set to one, the | |||
| SHOULD NOT send or receive any more DIOs for this temporary DAG | router SHOULD NOT send or receive any more DIOs for this temporary | |||
| and SHOULD cancel any pending DIO transmission. | DAG and SHOULD cancel any pending DIO transmission. | |||
| o The router MUST ignore any Metric Container and Data Options | o The router MUST ignore any Metric Container Options contained in | |||
| contained in the DRO message. | the P2P-DRO message. | |||
| o If Address[NH] element inside the P2P-RDO lists the router's own | 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 | 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: | the P2P-RDO. In this case, the router MUST do the following: | |||
| * To prevent loops, the router MUST discard the DRO message with | * To prevent loops, the router MUST discard the P2P-DRO message | |||
| no further processing if the Address vector in the P2P-RDO | with no further processing if the Address vector in the P2P-RDO | |||
| includes multiple IPv6 addresses assigned to the router's | includes multiple IPv6 addresses assigned to the router's | |||
| interfaces. | interfaces. | |||
| * If the H flag inside the P2P-RDO is one, the router MUST store | * 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: | P2P-RDO. This state consists of: | |||
| + The RPLInstanceID and the DODAGID fields of the DRO. | + The RPLInstanceID and the DODAGID fields of the P2P-DRO. | |||
| + The route's destination, the Target (identified by | + The route's destination, the Target (identified by | |||
| TargetAddr field inside P2P-RDO). | TargetAddr field inside P2P-RDO). | |||
| + The IPv6 address of the next hop, Address[NH+1] (unless NH | + The IPv6 address of the next hop, Address[NH+1] (unless NH | |||
| value equals the number of elements in the Address vector, | value equals the number of elements in the Address vector, | |||
| in which case the Target itself is the next hop). | 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 | lifetime specified by the Default Lifetime and Lifetime Unit | |||
| parameters inside the DODAG Configuration Option used in P2P | parameters inside the DODAG Configuration Option used in P2P | |||
| mode DIOs for this route discovery. | 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 | Target as the destination and carrying same RPLInstanceID and | |||
| DODAGID fields as the received DRO and the next hop information | DODAGID fields as the received P2P-DRO and the next hop | |||
| in the state does not match the next hop indicated in the | information in the state does not match the next hop indicated | |||
| received DRO, the router MUST discard the DRO message with no | in the received P2P-DRO, the router MUST discard the P2P-DRO | |||
| further processing. Note that this situation would occur in | message with no further processing. Note that this situation | |||
| the following two cases: | would occur in the following two cases: | |||
| + When the route listed in the Address vector inside the P2P- | + When the route listed in the Address vector inside the P2P- | |||
| RDO contains a previously undetected loop. In this case, | RDO contains a previously undetected loop. In this case, | |||
| the rule above causes the DRO messages to be discarded. | the rule above causes the P2P-DRO messages to be discarded. | |||
| + When a Hop-by-hop Route between the Origin and the Target, | + When a Hop-by-hop Route between the Origin and the Target, | |||
| previously established using the same RPLInstanceID and | previously established using the same RPLInstanceID and | |||
| DODAGID as the route currently being established, still | DODAGID as the route currently being established, still | |||
| exists and at least partially overlaps the route currently | exists and at least partially overlaps the route currently | |||
| being established. | being established. | |||
| * The router MUST decrement the NH field inside the P2P-RDO and | * The router MUST decrement the NH field inside the P2P-RDO and | |||
| send the DRO message further via link-local multicast. | send the P2P-DRO message further via link-local multicast. | |||
| 9.7. Processing a DRO At The Origin | 9.7. Processing a P2P-DRO At The Origin | |||
| When a router receives a DRO message that lists its IPv6 address in | When a router receives a P2P-DRO message that lists its IPv6 address | |||
| the DODAGID field, the router recognizes itself as the Origin for the | in the DODAGID field, the router recognizes itself as the Origin for | |||
| corresponding P2P-RPL route discovery, notes the Target that | the corresponding P2P-RPL route discovery, notes the Target that | |||
| originated this message (from the TargetAddr field inside the P2P- | originated this message (from the TargetAddr field inside the P2P- | |||
| RDO) and processes the message in the following manner: | RDO) and processes the message in the following manner: | |||
| o The Origin MUST discard the received DRO with no further | o The Origin MUST discard the received P2P-DRO with no further | |||
| processing if it no longer belongs to the temporary DAG identified | processing if it no longer belongs to the temporary DAG identified | |||
| by the RPLInstanceID and the DODAGID fields in the DRO. | by the RPLInstanceID and the DODAGID fields in the P2P-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. | ||||
| o If the Stop flag inside the received DRO is set to one, the Origin | o If the Stop flag inside the received P2P-DRO is set to one, the | |||
| SHOULD NOT generate any more DIOs for this temporary DAG and | Origin SHOULD NOT generate any more DIOs for this temporary DAG | |||
| SHOULD cancel any pending DIO transmission. | and SHOULD cancel any pending DIO transmission. | |||
| o If the P2P-RDO inside the DRO has the H flag set to 0, the Address | o If the P2P-RDO inside the P2P-DRO has the H flag set to 0, the | |||
| vector inside the P2P-RDO contains a Source Route to this Target | Address vector inside the P2P-RDO contains a Source Route to this | |||
| and the Origin MUST store this Source Route in its memory. The | Target. The Origin MUST set the lifetime of this Source Route to | |||
| lifetime of this Source Route is specified by the Default Lifetime | the value specified by the Default Lifetime and Lifetime Unit | |||
| and Lifetime Unit parameters inside the DODAG Configuration Option | parameters inside the DODAG Configuration Option in the P2P mode | |||
| in the P2P mode DIOs used for this route discovery. This lifetime | DIOs used for this route discovery. This lifetime could be | |||
| could be extended (or shortened) appropriately following a hint | extended (or shortened) appropriately following a hint from an | |||
| from an upper-layer protocol. | upper-layer protocol. | |||
| o If the P2P-RDO inside the DRO has the H flag set to 1, the DRO | o If the P2P-RDO inside the P2P-DRO has the H flag set to 1, the | |||
| message is establishing a Hop-by-hop Route to this Target and the | P2P-DRO message is establishing a Hop-by-hop Route to this Target | |||
| Origin MUST store in its memory the state for this Hop-by-hop | and the Origin MUST store in its memory the state for this Hop-by- | |||
| Route in the manner described in Section 9.6. This Hop-by-hop | 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 | routing state MUST expire at the end of the lifetime specified by | |||
| the Default Lifetime and Lifetime Unit parameters inside the DODAG | the Default Lifetime and Lifetime Unit parameters inside the DODAG | |||
| Configuration Option used in P2P mode DIOs for this route | Configuration Option used in P2P mode DIOs for this route | |||
| discovery. The standards track version of P2P-RPL may consider | discovery. The standards track version of P2P-RPL may consider | |||
| specifying a signaling mechanism that will allow the Origin to | specifying a signaling mechanism that will allow the Origin to | |||
| extend (or shorten) the lifetime of a P2P-RPL Hop-by-hop Route | extend (or shorten) the lifetime of a P2P-RPL Hop-by-hop Route | |||
| following a suitable hint from an upper-layer protocol. | following a suitable hint from an upper-layer protocol. | |||
| o If the received DRO message contains one or more Metric Container | o If the received P2P-DRO message contains one or more Metric | |||
| Options, the Origin MAY store the values of the routing metrics | Container Options, the Origin MAY store the values of the routing | |||
| associated with the discovered route in its memory. This | metrics associated with the discovered route in its memory. This | |||
| information may be useful in formulating the constraints for any | information may be useful in formulating the constraints for any | |||
| future P2P-RPL route discovery to this Target. | future P2P-RPL route discovery to this Target. | |||
| o If the A flag is set to one in the received DRO message, the | o If the A flag is set to one in the received P2P-DRO message, the | |||
| Origin MUST generate a DRO-ACK message as described in Section 10 | Origin MUST generate a P2P-DRO-ACK message as described in | |||
| and unicast the message to the Target. The Origin MAY use the | Section 10 and unicast the message to the Target. The Origin MAY | |||
| route just discovered to send the DRO-ACK message to the Target. | use the route just discovered to send the P2P-DRO-ACK message to | |||
| Section 11 describes how a packet may be forwarded along a Source/ | the Target. Section 12 describes how a packet may be forwarded | |||
| Hop-by-hop Route discovered using P2P-RPL. | along a Source/Hop-by-hop Route discovered using P2P-RPL. | |||
| 10. The Discovery Reply Object Acknowledgement (DRO-ACK) | 10. The P2P Discovery Reply Object Acknowledgement (P2P-DRO-ACK) | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | RPLInstanceID | Version |Seq| Reserved | | | RPLInstanceID | Version |Seq| Reserved | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | | |||
| | DODAGID | | | DODAGID | | |||
| | | | | | | |||
| | | | | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 4: Format of the base Discovery Reply Object Acknowledgement | Figure 3: Format of the base P2P Discovery Reply Object | |||
| (DRO-ACK) | Acknowledgement (P2P-DRO-ACK) | |||
| A DRO message may fail to reach the Origin due to a number of | A P2P-DRO message may fail to reach the Origin due to a number of | |||
| reasons. Unlike the DIO messages that benefit from Trickle- | reasons. Unlike the DIO messages that benefit from Trickle- | |||
| controlled retransmissions, the DRO messages are prone to loss due to | controlled retransmissions, the P2P-DRO messages are prone to loss | |||
| unreliable packet transmission in LLNs. Since a DRO message travels | due to unreliable packet transmission in LLNs. Since a P2P-DRO | |||
| via link-local multicast, it cannot use link-level acknowledgements | message travels via link-local multicast, it cannot use link-level | |||
| to improve the reliability of its transmission. Also, an | acknowledgements to improve the reliability of its transmission. | |||
| Intermediate Router may drop the DRO message (e.g., because of its | Also, an Intermediate Router may drop the P2P-DRO message (e.g., | |||
| inability to store the state for the Hop-by-hop Route the DRO is | because of its inability to store the state for the Hop-by-hop Route | |||
| establishing). To protect against the potential failure of a DRO | the P2P-DRO is establishing). To protect against the potential | |||
| message to reach the Origin, the Target MAY request the Origin to | failure of a P2P-DRO message to reach the Origin, the Target MAY | |||
| send back a DRO Acknowledgement (DRO-ACK) message on receiving a DRO | request the Origin to send back a P2P-DRO Acknowledgement (P2P-DRO- | |||
| message. Failure to receive such an acknowledgement within the | ACK) message on receiving a P2P-DRO message. Failure to receive such | |||
| DRO_ACK_WAIT_TIME interval of sending the DRO message forces the | an acknowledgement within the P2P_DRO_ACK_WAIT_TIME interval of | |||
| Target to resend the message. | 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: DRO | This section defines two new RPL Control Message types: P2P-DRO | |||
| Acknowledgement (DRO-ACK; with code TBD6) and Secure DRO-ACK (with | Acknowledgement (P2P-DRO-ACK; with code TBD5) and Secure P2P-DRO-ACK | |||
| code TBD7). A DRO-ACK message MUST travel as a unicast message from | (with code TBD6). A P2P-DRO-ACK message MUST travel as a unicast | |||
| the Origin to the Target. The format of a base DRO-ACK message is | message from the Origin to the Target. The IPv6 source and | |||
| shown in Figure 4. Various fields in a DRO-ACK message MUST have the | destination addresses used in a P2P-DRO-ACK message MUST be global or | |||
| same values as the corresponding fields in the DRO message. The | unique local. The format of a base P2P-DRO-ACK message is shown in | |||
| field marked as "Reserved" MUST be set to zero on transmission and | Figure 3. Various fields in a P2P-DRO-ACK message MUST have the same | |||
| MUST be ignored on reception. A Secure DRO-ACK message follows the | 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 | ||||
| ignored on reception. A Secure P2P-DRO-ACK message follows the | ||||
| format in Figure 7 of [RFC6550], where the base format is same as the | format in Figure 7 of [RFC6550], where the base format is same as the | |||
| base DRO-ACK shown in Figure 4. | base P2P-DRO-ACK shown in Figure 3. | |||
| 11. Packet Forwarding Along a Route Discovered Using P2P-RPL | 11. Secure P2P-RPL Operation | |||
| An Origin MAY use a Source Routing Header (SRH) [RFC6554] to send a | Each RPL control message type, including the ones 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 Figure 7 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 | ||||
| routers participating in a P2P-RPL route discovery to 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 decides so | ||||
| 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 can not use the Security Configuration found in the Secure DIOs | ||||
| pertaining to this route discovery. | ||||
| 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 Secured 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 message | ||||
| (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. | packet along a Source Route discovered using P2P-RPL. | |||
| Travel along a Hop-by-hop Route, established using P2P-RPL, requires | Travel along a Hop-by-hop Route, established using P2P-RPL, requires | |||
| specifying the RPLInstanceID and the DODAGID (of the temporary DAG | specifying the RPLInstanceID and the DODAGID (of the temporary DAG | |||
| used for the route discovery) to identify the route. This is because | used for the route discovery) to identify the route. This is because | |||
| a P2P-RPL route discovery does not use globally unique RPLInstanceID | a P2P-RPL route discovery does not use globally unique RPLInstanceID | |||
| values and hence both the RPLInstanceID (a local value assigned by | values and hence both the RPLInstanceID (a local value assigned by | |||
| the Origin) and the DODAGID (an IPv6 address of the Origin) are | 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 | required to uniquely identify a P2P-RPL Hop-by-hop Route to a | |||
| particular destination. | particular destination. | |||
| An Origin MAY include an RPL option [RFC6553] inside the IPv6 hop-by- | An Origin includes an RPL option [RFC6553] inside the IPv6 hop-by-hop | |||
| hop options header of a packet to send it along a Hop-by-hop Route | 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 | established using P2P-RPL. For this purpose, the Origin MUST set the | |||
| DODAGID of the temporary DAG used for the route discovery as the | DODAGID of the temporary DAG used for the route discovery as the | |||
| source IPv6 address of the packet. Further, the Origin MUST specify | source IPv6 address of the packet. Further, the Origin MUST specify | |||
| inside the RPL option the RPLInstanceID of the temporary DAG used for | 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. | 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 | On receiving this packet, an Intermediate Router checks the O flag | |||
| and correctly infer the source IPv6 address of the packet as the | and correctly infer the source IPv6 address of the packet as the | |||
| DODAGID of the Hop-by-hop Route. The router then uses the DODAGID, | DODAGID of the Hop-by-hop Route. The router then uses the DODAGID, | |||
| the RPLInstanceID and the destination address to identify the routing | the RPLInstanceID and the destination address to identify the routing | |||
| state to be used to forward the packet further. | state to be used to forward the packet further. | |||
| 12. Interoperability with Core RPL | 13. Interoperability with Core RPL | |||
| This section describes how RPL routers that implement P2P-RPL | This section describes how RPL routers that implement P2P-RPL | |||
| interact with RPL routers that do not. In general, P2P-RPL operation | 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 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 | 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, an RPL | understand the Mode of Operation (MOP) used in the DAG. Thus, an RPL | |||
| router that does not implement P2P-RPL may conceivably join a | router that does not implement P2P-RPL may conceivably join a | |||
| temporary DAG being created for a P2P-RPL route discovery as a leaf | temporary DAG being created for a P2P-RPL route discovery as a leaf | |||
| node and maintain its membership even though the DAG no longer | node and maintain its membership even though the DAG no longer | |||
| exists. This may impose a drain on the router's memory. However, | exists. This may impose a drain on the router's memory. However, | |||
| skipping to change at page 31, line 13 ¶ | skipping to change at page 33, line 34 ¶ | |||
| join a DAG whose MOP it does not understand. Moreover, RPL routers | join a DAG whose MOP it does not understand. Moreover, RPL routers | |||
| in a particular deployment may have strict restrictions on the DAGs | in a particular deployment may have strict restrictions on the DAGs | |||
| they may join, thereby mitigating the problem. | they may join, thereby mitigating the problem. | |||
| The P2P-RPL mechanism described in this document works best when all | The P2P-RPL mechanism described in this document works best when all | |||
| the RPL routers in the LLN implement P2P-RPL. In general, the | the RPL routers in the LLN implement P2P-RPL. In general, the | |||
| ability to discover routes as well as the quality of discovered | ability to discover routes as well as the quality of discovered | |||
| routes would deteriorate with the fraction of RPL routers that | routes would deteriorate with the fraction of RPL routers that | |||
| implement P2P-RPL. | implement P2P-RPL. | |||
| 13. Security Considerations | 14. Security Considerations | |||
| A P2P-RPL deployment may be susceptible to denial of service attacks | ||||
| by rogue routers that initiate fake route discoveries. A rogue | ||||
| router could join a temporary DAG and advertise false information in | ||||
| its DIOs in order to include itself in the discovered route(s). It | ||||
| could generate bogus DRO messages carrying bad routes or maliciously | ||||
| modify genuine DRO messages it receives. | ||||
| In general, the security considerations for the operation of P2P-RPL | In general, the security considerations for the operation of P2P-RPL | |||
| are similar to the ones for the operation of RPL (as described in | are similar to the ones for the operation of RPL (as described in | |||
| Section 19 of [RFC6550]). Section 10 of RPL specification [RFC6550] | Section 19 of [RFC6550]). Sections 6.1 and 10 of RPL specification | |||
| describes a variety of security mechanisms that provide data | [RFC6550] describe RPL's security framework that provides data | |||
| confidentiality, authentication, replay protection and delay | confidentiality, authentication, replay protection and delay | |||
| protection services. Each RPL control message has a secure version | protection services. This security framework can also be used in | |||
| that allows the specification of the level of security and the | P2P-RPL after taking in account the constraints specified in | |||
| algorithms used to secure the message. The mechanism defined in this | Section 11. P2P-RPL requires all routers participating in a secure | |||
| document is based on the use of DIOs to form a temporary DAG and | route discovery to use the Security Configuration decided by the | |||
| discover P2P routes. These DIOs can be used in their secure versions | Origin. The intention is to avoid compromising the overall security | |||
| if desired. New RPL control messages defined in this document (DRO | of a route discovery due to some routers using a weaker Security | |||
| and DRO-ACK) have secure versions as well. In addition, a P2P-RPL | Configuration. With "lock down" mechanism, described in Section 11, | |||
| deployment may use the security features provided by the link layer | in effect, it is unlikely that an Origin would accept a route | |||
| in use. Thus, a particular P2P-RPL deployment can analyze its | discovered under a Security Configuration other than the one it | |||
| security requirements and use the appropriate set of RPL (or link | intended. Any attempt to use a different Security Configuration | |||
| layer) security mechanisms that meet those requirements. Note that | (than the one the Origin intended) is likely to result, in the worst | |||
| the contents of the Data Option, if used, has the same level of | case, in the failure of the route discovery process. In the best | |||
| security as the DIO/DRO message it is part of. Hence, a P2P-RPL | case scenario, any such attempt by a rogue router would result in its | |||
| deployment SHOULD take in consideration the security requirements of | neighbors entering the "lock down" mode and acting as firewalls to | |||
| the data being sent inside the Data Options when deciding the overall | allow the route discovery to proceed in the remaining network. | |||
| security requirements. | ||||
| Since a DRO message travels along a Source Route specified inside the | RPL specification describes three modes of security: unsecured, pre- | |||
| message, some of the security concerns that led to the deprecation of | installed and authenticated. In the unsecured mode, secure control | |||
| Type 0 routing header [RFC5095] may apply. To avoid the possibility | messages are not used and the only available security is the one | |||
| of a DRO message traveling in a routing loop, this document requires | provided by the link layer protocols. In the pre-installed mode, all | |||
| each Intermediate Router to confirm that the Source Route listed | the nodes use a pre-installed group key to join a secure DAG as the | |||
| inside the message does not contain any routing loop involving itself | "routers" or "hosts", where the term "router" means a node that is | |||
| before the router could forward the message further. As specified in | capable of forwarding packets received from its parents or children | |||
| Section 9.6, this check involves the router making sure that its IPv6 | in the DAG and the term "host" refers to nodes that can not function | |||
| addresses do not appear multiple times inside the Source Route with | as "routers". In the authenticated mode, the nodes can join a secure | |||
| one or more other IPv6 addresses in between. | DAG as "hosts" using the pre-installed 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 can not 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 pre-installed 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 pre-installed or dynamically acquired. The router must have | ||||
| the key in use before it can join the DAG beiing created for a secure | ||||
| P2P-RPL route discovery. | ||||
| 14. IANA Considerations | If a rogue router can support the Security Configuration in use (in | |||
| particular, it knows the key in use), it can join the secure P2P-RPL | ||||
| route discovery and cause a variety 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. Here, RPL's authenticated | ||||
| mode operation would be useful, where a node can obtain the key to | ||||
| use for a P2P-RPL route discovery only after proper authentication. | ||||
| 14.1. Additions to Mode of Operation | 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 header [RFC5095] may apply. To avoid | ||||
| the possibility of a P2P-DRO message traveling in a routing loop, | ||||
| this document requires each Intermediate Router to 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. | ||||
| 15. IANA Considerations | ||||
| 15.1. Additions to Mode of Operation | ||||
| This document defines a new Mode of Operation, entitled "P2P Route | This document defines a new Mode of Operation, entitled "P2P Route | |||
| Discovery Mode" (see Section 6), assigned a value TBD1 from the "Mode | Discovery Mode" (see Section 6), assigned a value TBD1 from the "Mode | |||
| of Operation" space [to be removed upon publication: | of Operation" space [to be removed upon publication: | |||
| http://www.iana.org/assignments/rpl/rpl.xml#mop] [RFC6550]. IANA is | http://www.iana.org/assignments/rpl/rpl.xml#mop] [RFC6550]. IANA is | |||
| requested to allocate a suitable value to TBD1. The string TBD1 in | requested to allocate a suitable value to TBD1. The string TBD1 in | |||
| this document should be replaced by the allocated value. The | this document should be replaced by the allocated value. The | |||
| previous two sentences should be removed before publication. | previous two sentences should be removed before publication. | |||
| +-------+---------------------------------------+---------------+ | +-------+---------------------------------------+---------------+ | |||
| | Value | Description | Reference | | | Value | Description | Reference | | |||
| +-------+---------------------------------------+---------------+ | +-------+---------------------------------------+---------------+ | |||
| | TBD1 | P2P Route Discovery Mode of Operation | This document | | | TBD1 | P2P Route Discovery Mode of Operation | This document | | |||
| +-------+---------------------------------------+---------------+ | +-------+---------------------------------------+---------------+ | |||
| Mode of Operation | Mode of Operation | |||
| 14.2. Additions to RPL Control Message Options | 15.2. Additions to RPL Control Message Options | |||
| This document defines two new RPL options: | ||||
| o "P2P Route Discovery Option" (see Section 7.1), assigned a value | ||||
| TBD2 from the "RPL Control Message Options" space [to be removed | ||||
| upon publication: http://www.iana.org/assignments/rpl/ | ||||
| rpl.xml#control-message-options] [RFC6550]. IANA is requested to | ||||
| allocate a suitable value to TBD2. The string TBD2 in this | ||||
| document should be replaced by the allocated value. The previous | ||||
| two sentences should be removed before publication. | ||||
| o "Data Option" (see Section 7.2), assigned a value TBD3 from the | This document defines a new RPL option: "P2P Route Discovery Option" | |||
| "RPL Control Message Options" space [to be removed upon | (see Section 7), assigned a value TBD2 from the "RPL Control Message | |||
| publication: http://www.iana.org/assignments/rpl/ | Options" space [to be removed upon publication: | |||
| rpl.xml#control-message-options] [RFC6550]. IANA is requested to | http://www.iana.org/assignments/rpl/rpl.xml#control-message-options] | |||
| allocate a suitable value to TBD3. The string TBD3 in this | [RFC6550]. IANA is requested to allocate a suitable value to TBD2. | |||
| document should be replaced by the allocated value. The previous | The string TBD2 in this document should be replaced by the allocated | |||
| two sentences should be removed before publication. | value. The previous two sentences should be removed before | |||
| publication. | ||||
| +-------+---------------------+---------------+ | +-------+---------------------+---------------+ | |||
| | Value | Meaning | Reference | | | Value | Meaning | Reference | | |||
| +-------+---------------------+---------------+ | +-------+---------------------+---------------+ | |||
| | TBD2 | P2P Route Discovery | This document | | | TBD2 | P2P Route Discovery | This document | | |||
| | TBD3 | Data | This document | | ||||
| +-------+---------------------+---------------+ | +-------+---------------------+---------------+ | |||
| RPL Control Message Options | RPL Control Message Options | |||
| 14.3. Additions to RPL Control Codes | 15.3. Additions to RPL Control Codes | |||
| This document defines the following new RPL messages: | This document defines the following new RPL messages: | |||
| o "Discovery Reply Object" (see Section 8), assigned a value TBD4 | o "P2P Discovery Reply Object" (see Section 8), assigned a value | |||
| from the "RPL Control Codes" space [to be removed upon | TBD3 from the "RPL Control Codes" space [to be removed upon | |||
| publication: | publication: | |||
| http://www.iana.org/assignments/rpl/rpl.xml#control-codes] | http://www.iana.org/assignments/rpl/rpl.xml#control-codes] | |||
| [RFC6550]. IANA is requested to allocate TBD4 from the range | [RFC6550]. IANA is requested to allocate TBD3 from the range | |||
| 0x00-0x7F to indicate a message without security enabled. The | 0x00-0x7F to indicate a message without security enabled. The | |||
| string TBD4 in this document should be replaced by the allocated | string TBD3 in this document should be replaced by the allocated | |||
| value. The previous two sentences should be removed before | value. The previous two sentences should be removed before | |||
| publication. | publication. | |||
| o "Secure Discovery Reply Object" (see Section 8.1), assigned a | o "Secure P2P Discovery Reply Object" (see Section 8.1), assigned a | |||
| value TBD5 from the "RPL Control Codes" space [to be removed upon | value TBD4 from the "RPL Control Codes" space [to be removed upon | |||
| publication: | publication: | |||
| http://www.iana.org/assignments/rpl/rpl.xml#control-codes] | http://www.iana.org/assignments/rpl/rpl.xml#control-codes] | |||
| [RFC6550]. IANA is requested to allocate TBD5 from the range | [RFC6550]. IANA is requested to allocate TBD4 from the range | |||
| 0x80-0xFF to indicate a message with security enabled. The string | 0x80-0xFF to indicate a message with security enabled. The string | |||
| TBD5 in this document should be replaced by the allocated value. | TBD4 in this document should be replaced by the allocated value. | |||
| The previous two sentences should be removed before publication. | The previous two sentences should be removed before publication. | |||
| o "Discovery Reply Object Acknowledgement" (see Section 10), | o "P2P Discovery Reply Object Acknowledgement" (see Section 10), | |||
| assigned a value TBD6 from the "RPL Control Codes" space [to be | assigned a value TBD5 from the "RPL Control Codes" space [to be | |||
| removed upon publication: | removed upon publication: | |||
| http://www.iana.org/assignments/rpl/rpl.xml#control-codes] | http://www.iana.org/assignments/rpl/rpl.xml#control-codes] | |||
| [RFC6550]. IANA is requested to allocate TBD6 from the range | [RFC6550]. IANA is requested to allocate TBD5 from the range | |||
| 0x00-0x7F to indicate a message without security enabled. The | 0x00-0x7F to indicate a message without security enabled. The | |||
| string TBD6 in this document should be replaced by the allocated | string TBD5 in this document should be replaced by the allocated | |||
| value. The previous two sentences should be removed before | value. The previous two sentences should be removed before | |||
| publication. | publication. | |||
| o "Secure Discovery Reply Object Acknowledgement" (see Section 10), | o "Secure P2P Discovery Reply Object Acknowledgement" (see | |||
| assigned a value TBD7 from the "RPL Control Codes" space [to be | Section 10), assigned a value TBD6 from the "RPL Control Codes" | |||
| removed upon publication: | space [to be removed upon publication: | |||
| http://www.iana.org/assignments/rpl/rpl.xml#control-codes] | http://www.iana.org/assignments/rpl/rpl.xml#control-codes] | |||
| [RFC6550]. IANA is requested to allocate TBD7 from the range | [RFC6550]. IANA is requested to allocate TBD6 from the range | |||
| 0x80-0xFF to indicate a message with security enabled. The string | 0x80-0xFF to indicate a message with security enabled. The string | |||
| TBD7 in this document should be replaced by the allocated value. | TBD6 in this document should be replaced by the allocated value. | |||
| The previous two sentences should be removed before publication. | The previous two sentences should be removed before publication. | |||
| +------+--------------------------------------------+---------------+ | +------+---------------------------------------------+--------------+ | |||
| | Code | Description | Reference | | | Code | Description | Reference | | |||
| +------+--------------------------------------------+---------------+ | +------+---------------------------------------------+--------------+ | |||
| | TBD4 | Discovery Reply Object | This document | | | TBD3 | P2P Discovery Reply Object | This | | |||
| | TBD5 | Secure Discovery Reply Object | This document | | | | | document | | |||
| | TBD6 | Discovery Reply Object Acknowledgement | This document | | | TBD4 | Secure P2P Discovery Reply Object | This | | |||
| | TBD7 | Secure Discovery Reply Object | This document | | | | | document | | |||
| | | Acknowledgement | | | | TBD5 | P2P Discovery Reply Object Acknowledgement | This | | |||
| +------+--------------------------------------------+---------------+ | | | | document | | |||
| | TBD6 | Secure P2P Discovery Reply Object | This | | ||||
| | | Acknowledgement | document | | ||||
| +------+---------------------------------------------+--------------+ | ||||
| RPL Control Codes | RPL Control Codes | |||
| 15. Acknowledgements | 16. Acknowledgements | |||
| Authors gratefully acknowledge the contributions of the following | Authors gratefully acknowledge the contributions of the following | |||
| individuals (in alphabetical order) in the development of this | individuals (in alphabetical order) in the development of this | |||
| document: Dominique Barthel, Jakob Buron, Cedric Chauvenet, Thomas | document: Dominique Barthel, Jakob Buron, Cedric Chauvenet, Thomas | |||
| Clausen, Robert Cragie, Ted Humpal, Richard Kelsey, Phil Levis, | Clausen, Robert Cragie, Ralph Droms, Adrian Farrel, Stephen Farrell, | |||
| Charles Perkins, Joseph Reddy, Michael Richardson, Zach Shelby, | Brian Haberman, Ted Humpal, Richard Kelsey, Phil Levis, Charles | |||
| Pascal Thubert, Hristo Valev and JP Vasseur. | Perkins, Joseph Reddy, Michael Richardson, Zach Shelby, Martin | |||
| Stiemerling, Pascal Thubert, Hristo Valev and JP Vasseur. | ||||
| 16. References | 17. References | |||
| 16.1. Normative References | 17.1. Normative References | |||
| [PROTOCOL] | [I-D.ietf-roll-terminology] | |||
| "Protocol Numbers", <http://www.iana.org/assignments/ | Vasseur, J., "Terminology in Low power And Lossy | |||
| protocol-numbers/protocol-numbers.xml>. | Networks", draft-ietf-roll-terminology-10 (work in | |||
| progress), January 2013. | ||||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
| [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
| IANA Considerations Section in RFCs", BCP 26, RFC 5226, | IANA Considerations Section in RFCs", BCP 26, RFC 5226, | |||
| May 2008. | May 2008. | |||
| [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, | [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, | |||
| "The Trickle Algorithm", RFC 6206, March 2011. | "The Trickle Algorithm", RFC 6206, March 2011. | |||
| skipping to change at page 34, line 48 ¶ | skipping to change at page 38, line 4 ¶ | |||
| [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
| IANA Considerations Section in RFCs", BCP 26, RFC 5226, | IANA Considerations Section in RFCs", BCP 26, RFC 5226, | |||
| May 2008. | May 2008. | |||
| [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, | [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, | |||
| "The Trickle Algorithm", RFC 6206, March 2011. | "The Trickle Algorithm", RFC 6206, March 2011. | |||
| [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., | [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., | |||
| Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. | Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. | |||
| Alexander, "RPL: IPv6 Routing Protocol for Low-Power and | Alexander, "RPL: IPv6 Routing Protocol for Low-Power and | |||
| Lossy Networks", RFC 6550, March 2012. | Lossy Networks", RFC 6550, March 2012. | |||
| [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. | [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. | |||
| Barthel, "Routing Metrics Used for Path Calculation in | Barthel, "Routing Metrics Used for Path Calculation in | |||
| Low-Power and Lossy Networks", RFC 6551, March 2012. | Low-Power and Lossy Networks", RFC 6551, March 2012. | |||
| 16.2. Informative References | 17.2. Informative References | |||
| [I-D.ietf-roll-p2p-measurement] | [I-D.ietf-roll-p2p-measurement] | |||
| Goyal, M., Baccelli, E., Brandt, A., and J. Martocci, "A | Goyal, M., Baccelli, E., Brandt, A., and J. Martocci, "A | |||
| Mechanism to Measure the Routing Metrics along a Point-to- | Mechanism to Measure the Routing Metrics along a Point-to- | |||
| point Route in a Low Power and Lossy Network", | point Route in a Low Power and Lossy Network", | |||
| draft-ietf-roll-p2p-measurement-08 (work in progress), | draft-ietf-roll-p2p-measurement-09 (work in progress), | |||
| January 2013. | February 2013. | |||
| [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation | [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation | |||
| of Type 0 Routing Headers in IPv6", RFC 5095, | of Type 0 Routing Headers in IPv6", RFC 5095, | |||
| December 2007. | December 2007. | |||
| [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation | [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation | |||
| Routing Requirements in Low-Power and Lossy Networks", | Routing Requirements in Low-Power and Lossy Networks", | |||
| RFC 5826, April 2010. | RFC 5826, April 2010. | |||
| [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, | [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, | |||
| End of changes. 149 change blocks. | ||||
| 609 lines changed or deleted | 715 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||