--- 1/draft-ietf-roll-p2p-rpl-10.txt 2012-05-06 19:13:59.587087739 +0200 +++ 2/draft-ietf-roll-p2p-rpl-11.txt 2012-05-06 19:13:59.655088158 +0200 @@ -1,26 +1,26 @@ Internet Engineering Task Force M. Goyal, Ed. Internet-Draft University of Wisconsin Intended status: Experimental Milwaukee -Expires: November 6, 2012 E. Baccelli +Expires: November 7, 2012 E. Baccelli M. Philipp INRIA A. Brandt Sigma Designs J. Martocci Johnson Controls - May 5, 2012 + May 6, 2012 Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks - draft-ietf-roll-p2p-rpl-10 + draft-ietf-roll-p2p-rpl-11 Abstract This document specifies a point-to-point route discovery mechanism, complementary to the RPL core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in the LLN such that the discovered routes meet specified metrics constraints. Status of this Memo @@ -31,21 +31,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on November 6, 2012. + This Internet-Draft will expire on November 7, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -66,36 +66,36 @@ 6.1. Setting a P2P Mode DIO . . . . . . . . . . . . . . . . . . 9 7. New RPL Control Message Options . . . . . . . . . . . . . . . 11 7.1. P2P Route Discovery Option (P2P-RDO) . . . . . . . . . . . 12 7.2. Data Option . . . . . . . . . . . . . . . . . . . . . . . 15 8. The Discovery Reply Object (DRO) . . . . . . . . . . . . . . . 15 8.1. Secure DRO . . . . . . . . . . . . . . . . . . . . . . . . 17 8.2. Setting a P2P-RDO Carried in a Discovery Reply Object . . 18 9. P2P-RPL Route Discovery By Creating a Temporary DAG . . . . . 18 9.1. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 18 9.2. Trickle Operation For P2P Mode DIOs . . . . . . . . . . . 19 - 9.3. Processing a P2P Mode DIO . . . . . . . . . . . . . . . . 20 + 9.3. Processing a P2P Mode DIO . . . . . . . . . . . . . . . . 21 9.4. Additional Processing of a P2P Mode DIO At An - Intermediate Router . . . . . . . . . . . . . . . . . . . 21 + Intermediate Router . . . . . . . . . . . . . . . . . . . 22 9.5. Additional Processing of a P2P Mode DIO At The Target . . 22 9.6. Processing a DRO At An Intermediate Router . . . . . . . . 24 9.7. Processing a DRO At The Origin . . . . . . . . . . . . . . 25 - 10. The Discovery Reply Object Acknowledgement (DRO-ACK) . . . . . 26 + 10. The Discovery Reply Object Acknowledgement (DRO-ACK) . . . . . 27 11. Packet Forwarding Along a Route Discovered Using P2P-RPL . . . 27 12. Interoperability with Core RPL . . . . . . . . . . . . . . . . 28 - 13. Security Considerations . . . . . . . . . . . . . . . . . . . 28 + 13. Security Considerations . . . . . . . . . . . . . . . . . . . 29 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 14.1. Additions to DIO Mode of Operation . . . . . . . . . . . . 29 - 14.2. Additions to RPL Control Message Options . . . . . . . . . 29 + 14.2. Additions to RPL Control Message Options . . . . . . . . . 30 14.3. Additions to RPL Control Codes . . . . . . . . . . . . . . 30 14.4. New Registry for Upper Layer Headers inside Data Option . 30 - 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 + 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 16.1. Normative References . . . . . . . . . . . . . . . . . . . 31 16.2. Informative References . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 1. Introduction Targeting Low power and Lossy Networks (LLNs), the RPL routing protocol [RFC6550] provides paths along a Directed Acyclic Graph (DAG) rooted at a single router in the network. Establishment and @@ -453,35 +453,43 @@ the DODAG Configuration Option in the outgoing P2P mode DIOs to the values they had in the incoming P2P mode DIOs for this DAG. A default DODAG Configuration Option comes in effect if a P2P mode DIO does not carry an explicit one. The default DODAG Configuration Option has the following parameter values: o Authentication Enabled: 0 o DIOIntervalMin: 6, which translates to 64ms as the value for Imin - parameter in Trickle operation. + parameter in Trickle operation. This value is roughly one order + of magnitude larger than the typical transmission delay on IEEE + 802.15.4 links and corresponds to the recommendation in + Section 9.2 for well-connected topologies. - o DIORedundancyConstant: 1 + o DIORedundancyConstant: 1. See the discussion in Section 9.2. - o MaxRankIncrease: 0 + o MaxRankIncrease: 0 (to disable local repair of the temporary DAG). - o Default Lifetime: 0xFF + o Default Lifetime: 0xFF, to correspond to infinity. + + o Lifetime Unit: 0xFFFF, to correspond to infinity. - o Lifetime Unit: 0xFFFF o Objective Code Point: 0, i.e., OF0 [RFC6552] is the default objective function. o The remaining parameters have default values as specified in [RFC6550]. + Individual P2P-RPL deployments are encouraged to share their + experience with these default values with ROLL working group to help + guide the development of standards track version of the protocol. + The routing metrics and constraints [RFC6551] used in P2P-RPL route discovery are included in one or more Metric Container Options [RFC6550] inside the P2P mode DIO. Note that a DIO need not include a Metric Container if OF0 is the objective function in effect. In that case, a P2P mode DIO may still specify an upper limit on the maximum rank, that a router may have in the temporary DAG, inside the P2P Route Discovery Option (described in Section 7.1). A P2P mode DIO: @@ -578,24 +586,27 @@ * 0x01: 4 seconds; * 0x02: 16 seconds; * 0x03: 64 seconds; The Origin sets this field based on its expectation regarding the time required for the route discovery to complete, which includes the time required for the DIOs to reach the Target(s) and the DROs - to travel back to the Origin. While deciding the temporary DAG's - lifetime, the Origin should also take in account the fact that all - nodes joining the temporary DAG would need to stay in the DAG for - at least this much time. + to travel back to the Origin. The time required for the DIOs to + reach the Target(s) would in turn depend on the Trickle parameters + (Imin and the redundancy constant) as well as the expected + distance (in terms of hops and/or ETX) to the Target(s). While + deciding the temporary DAG's lifetime, the Origin should also take + in account the fact that all nodes joining the temporary DAG would + need to stay in the DAG for at least this much time. o MaxRank/NH: * When a P2P-RDO is included in a P2P mode DIO, this field indicates the upper limit on the integer portion of the rank (calculated using the DAGRank() macro defined in [RFC6550]) that a router may have in the temporary DAG being created. An Intermediate Router MUST NOT join a temporary DAG being created by a P2P mode DIO if the integer portion of its rank would be equal to or higher (in numerical value) than the MaxRank limit. @@ -893,39 +904,52 @@ their DIOs within Imin interval and cause additional routers to reset their trickle timers and generate more DIOs. Thus, for highly connected networks, the Imin parameter SHOULD be set to a value at least one order of magnitude larger than the typical transmission delay for a DIO. For sparsely connected networks, the Imin parameter can be set to a value that is a small multiple of the typical transmission delay for a DIO. Note that the Imin value has a direct impact on the time required for a P2P-RPL route discovery to complete. In general, the time required for a P2P- RPL route discovery would increase approximately linearly with the - value of the Imin parameter. + value of the Imin parameter. Since the route discovery must + complete within the lifetime of the temporary DAG created for the + purpose, the Origin should set this lifetime 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 of magnitude higher than the Imin value) and is unlikely to be critical for P2P-RPL operation. This is because the first receipt of a P2P mode DIO for a particular temporary DAG is considered an inconsistent event and would lead to resetting of Trickle timer duration to the Imin value. Given the temporary nature of the DAGs used in P2P-RPL, Trickle timer may not get a chance to increase much. o The recommended value of redundancy constant "k" is 1. With this value of "k", a DIO transmission will be suppressed if the router receives even a single "consistent" DIO during a timer interval. This setting for the redundancy constant is designed to reduce the number of messages generated during a route discovery process and is suitable for environments with low or moderate packet loss - rates. In environments with high packet loss rates, a higher - value for the redundancy constant may be more suitable. + rates. A higher value for the redundancy constant may be more + suitable in environments with high packet loss rates or in + deployments where specific destinations are reachable only through + specific intermediate routers (and hence these intermediate + routers should not suppress their DIOs). A particular deployment + should take in account typical loss rates, the topological + characteristics of the LLN (the average/typical connectivity of + the nodes and the variance in connectivity: whether some + destinations have only a small set of neighbors) and the need to + contain the message overhead of the route discovery when deciding + the value of the redundancy constant. 9.3. Processing a P2P Mode DIO The rules for DIO processing and transmission, described in Section 8 of RPL [RFC6550], apply to P2P mode DIOs as well except as modified in this document. The following rules for processing a received P2P mode DIO apply to both Intermediate Routers and the Target. @@ -1169,22 +1192,22 @@ the P2P mode DIOs used for this route discovery. This lifetime could be extended (or shortened) appropriately following a hint from an upper-layer protocol. o If the P2P-RDO inside the DRO identifies the discovered route as a Hop-by-hop Route (H=1), the Origin MUST store in its memory the state for the discovered route in the manner described in Section 9.6. This hop-by-hop routing state MUST expire at the end of the lifetime specified by the Default Lifetime and Lifetime Unit parameters inside the DODAG Configuration Option used in P2P - mode DIOs for this route discovery. A future version of this - document may consider specifying a signaling mechanism that will + mode DIOs for this route discovery. The standards track version + of P2P-RPL may consider specifying a signaling mechanism that will allow the Origin to extend (or shorten) the lifetime of a P2P-RPL Hop-by-hop Route following a suitable hint from an upper-layer protocol. o If the received DRO message contains one or more Metric Container Options, the Origin MAY store the values of the routing metrics associated with the discovered route in its memory. This information may be useful in formulating the constraints for any future P2P-RPL route discovery to the Target.