--- 1/draft-ietf-roll-p2p-measurement-02.txt 2012-03-04 20:13:57.510805526 +0100 +++ 2/draft-ietf-roll-p2p-measurement-03.txt 2012-03-04 20:13:57.546809773 +0100 @@ -1,25 +1,25 @@ Internet Engineering Task Force M. Goyal, Ed. Internet-Draft University of Wisconsin Intended status: Experimental Milwaukee -Expires: May 1, 2012 E. Baccelli +Expires: September 5, 2012 E. Baccelli INRIA A. Brandt Sigma Designs J. Martocci Johnson Controls - October 29, 2011 + March 4, 2012 A Mechanism to Measure the Quality of a Point-to-point Route in a Low Power and Lossy Network - draft-ietf-roll-p2p-measurement-02 + draft-ietf-roll-p2p-measurement-03 Abstract This document specifies a mechanism that enables an RPL router to measure the quality of an existing route towards another RPL router in a low power and lossy network, thereby allowing the router to decide if it wants to initiate the discovery of a better route. Status of this Memo @@ -29,150 +29,154 @@ 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 May 1, 2012. + This Internet-Draft will expire on September 5, 2012. Copyright Notice - Copyright (c) 2011 IETF Trust and the persons identified as the + 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The Measurement Object (MO) . . . . . . . . . . . . . . . . . 4 3.1. Format of the base MO . . . . . . . . . . . . . . . . . . 5 - 3.2. Secure MO . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.2. Secure MO . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Originating a Measurement Request . . . . . . . . . . . . . . 9 4.1. To Measure A Hop-by-hop Route with a Global - RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 9 + RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 10 4.2. To Measure A Hop-by-hop Route with a Local - RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 9 + RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 10 4.3. To Measure A Source Route . . . . . . . . . . . . . . . . 11 5. Processing a Measurement Request at an Intermediate Router . . 12 5.1. Determining Next Hop For An MO Measuring A Source Route . 13 5.2. Determining Next Hop For An MO Measuring A Hop-by-hop Route . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Processing a Measurement Request at the Target . . . . . . . . 14 7. Processing a Measurement Reply at the Origin . . . . . . . . . 15 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction Point to point (P2P) communication between arbitrary routers in a Low power and Lossy Network (LLN) is a key requirement for many applications [RFC5826][RFC5867]. RPL [I-D.ietf-roll-rpl], the IPv6 Routing Protocol for LLNs, constrains the LLN topology to a Directed - Acyclic Graph (DAG) built to optimize routing costs to reach the - DAG's root and requires the P2P routes to use the DAG links only. - Such P2P routes may potentially be suboptimal and may lead to traffic - congestion near the DAG root. Additionally, RPL is a proactive - routing protocol and hence all P2P routes must be established ahead - of the time they are used. + Acyclic Graph (DAG) built to optimize the routing costs to reach the + DAG's root. The P2P routing functionality, available under RPL, has + the following key limitations: - To ameliorate situations, where RPL's P2P routing functionality does - not meet the requirements, [I-D.ietf-roll-p2p-rpl] describes a - reactive mechanism to discover P2P routes that meet the specified - performance criteria. This mechanism, henceforth referred to as the - reactive P2P route discovery, allows the specification of routing - constraints [I-D.ietf-roll-routing-metrics], that the discovered - routes must satisfy. In some cases, the application requirements or - the LLN's topological features allow a router to infer the routing - constraints intrinsically. For example, the application may require - the end-to-end loss rate and/or latency on the route to be below - certain thresholds or the LLN topology may be such that a router can - safely assume its destination to be less than a certain number of - hops away from itself. + o The P2P routes are restricted to use the DAG links only. Such P2P + routes may potentially be suboptimal and may lead to traffic + congestion near the DAG root. + + o RPL is a proactive routing protocol and hence requires all P2P + routes to be established ahead of the time they are used. Many + LLN applications require the ability to establish P2P routes "on + demand". + + To ameliorate situations, where the core RPL's P2P routing + functionality does not meet the application requirements, + [I-D.ietf-roll-p2p-rpl] describes P2P-RPL, an extension to core RPL. + P2P-RPL provides a reactive mechanism to discover P2P routes that + meet the specified routing constraints + [I-D.ietf-roll-routing-metrics]. In some cases, the application + requirements or the LLN's topological features allow a router to + infer these routing constraints implicitly. For example, the + application may require the end-to-end loss rate and/or latency along + the route to be below certain thresholds or the LLN topology may be + such that a router can safely assume its destination to be less than + a certain number of hops away from itself. When the existing routes are deemed unsatisfactory but the router - does not intrinsically know the routing constraints to be used in P2P - route discovery, it may be necessary for the router to determine the - aggregated values of the routing metrics along the existing route. - This knowledge will allow the router to frame reasonable routing - constraints for use in P2P route discovery to determine a better - route. For example, if the router determines the aggregate ETX + does not implicitly know the routing constraints to be used in P2P- + RPL route discovery, it may be necessary for the router to measure + the aggregated values of the routing metrics along the existing + route. This knowledge will allow the router to frame reasonable + routing constraints to discover a better route using P2P-RPL. For + example, if the router determines the aggregate ETX [I-D.ietf-roll-routing-metrics] along an existing route to be "x", it can use "ETX < x*y", where y is a certain fraction, as the routing - constraint for use in P2P route discovery. Note that it is important - that the routing constraints are not overly strict; otherwise the P2P - route discovery may fail even though a route, much better than the - one currently being used, exists. + constraint for use in P2P-RPL route discovery. Note that it is + important that the routing constraints are not overly strict; + otherwise the P2P-RPL route discovery may fail even though a route, + much better than the one currently being used, exists. This document specifies a mechanism that enables an RPL router to measure the aggregated values of the routing metrics along an existing route to another RPL router in an LLN, thereby allowing the - router to decide if it wants to initiate the reactive discovery of a - more optimal route and determine the routing constraints to be used - for this purpose. + router to decide if it wants to discover a better route using P2P-RPL + and determine the routing constraints to be used for this purpose. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Additionally, this document uses terminology from [I-D.ietf-roll-terminology], [I-D.ietf-roll-rpl] and [I-D.ietf-roll-p2p-rpl]. The following terms, originally defined in [I-D.ietf-roll-p2p-rpl], are redefined in the following manner. - Origin: The origin refers to the router that initiates the + Origin: The origin refers to the RPL router that initiates the measurement process defined in this document and is the start point of the P2P route being measured. - Target: The target refers to the router at the end point of the P2P - route being measured. + Target: The target refers to the RPL router at the end point of the + P2P route being measured. - Intermediate Router: A router, other than the origin and the target, - on the P2P route being measured. + Intermediate Router: An RPL router, other than the origin and the + target, on the P2P route being measured. 2. Overview The mechanism described in this document can be used by an origin in - an RPL domain to measure the aggregated values of the routing metrics - along a P2P route to a target within the same RPL domain. Such a - route could be a source route or a hop-by-hop route established using - RPL [I-D.ietf-roll-rpl] or the reactive P2P route discovery - [I-D.ietf-roll-p2p-rpl]. The origin sends a Measurement Request - message along the route. The Measurement Request accumulates the - values of the routing metrics as it travels towards the target. Upon - receiving the Measurement Request, the target unicasts a Measurement - Reply message, carrying the accumulated values of the routing - metrics, back to the origin. Optionally, the origin may allow an - intermediate route to generate the Measurement Reply if it already - knows the relevant routing metric values along rest of the route. + an LLN to measure the aggregated values of the routing metrics along + a P2P route to a target within the LLN. Such a route could be a + source route or a hop-by-hop route established using RPL + [I-D.ietf-roll-rpl] or P2P-RPL [I-D.ietf-roll-p2p-rpl]. The origin + sends a Measurement Request message along the route. The Measurement + Request accumulates the values of the routing metrics as it travels + towards the target. Upon receiving the Measurement Request, the + target unicasts a Measurement Reply message, carrying the accumulated + values of the routing metrics, back to the origin. Optionally, the + origin may allow an intermediate router to generate the Measurement + Reply if it already knows the relevant routing metric values along + rest of the route. 3. The Measurement Object (MO) This document defines two new RPL Control Message types, the Measurement Object (MO), with code 0x06 (to be confirmed by IANA), and the Secure MO, with code 0x86 (to be confirmed by IANA). An MO serves as both Measurement Request and Measurement Reply. 3.1. Format of the base MO @@ -200,344 +204,355 @@ . Metric Container Option(s) . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Format of the base Measurement Object (MO) The format of a base MO is shown in Figure 1. A base MO consists of the following fields: - o RPLInstanceID: Relevant only if the MO travels along a hop-by-hop - route. This field identifies the RPLInstanceID of the hop-by-hop - route being measured. If the route being measured is a source - route, this field MUST be set to 10000000 on transmission and - ignored on reception. + o RPLInstanceID: The origin sets this field to indicate the + RPLInstanceID of the route being measured. An intermediate router + MUST discard the received MO message if it is not aware of the RPL + Instance specified by the RPLInstanceID value. If the + RPLInstanceID is a local value, the RPL Instance is identified by + both the RPLInstanceID and the Origin Address fields. An + intermediate router MUST set the RPLInstanceID field in the + outgoing MO packet to the same value that it had in the + corresponding incoming MO packet. o Compr: In many LLN deployments, IPv6 addresses share a well known, common prefix. In such cases, the common prefix can be elided - when specifying IPv6 addresses in Origin/Target Address fields and - the Address vector. The "Compr" field is a 4-bit unsigned integer - that indicates the number of prefix octets that are elided from - the IPv6 addresses in Origin/Target Address fields and the Address - vector. The Compr value will be 0 if full IPv6 addresses are - carried in the Origin/Target Address fields and the Address - vector. + when specifying IPv6 addresses in the Origin/Target Address fields + and the Address vector. The "Compr" field, a 4-bit unsigned + integer, is set by the origin to specify the number of prefix + octets that are elided from the IPv6 addresses in Origin/Target + Address fields and the Address vector. An intermediate router + MUST set the Compr field in the outgoing MO packet to the same + value that it had in the corresponding incoming MO packet. The + Compr value will be 0 if full IPv6 addresses are carried in the + Origin/Target Address fields and the Address vector. - o Type (T): This flag is set if the MO represents a Measurement - Request. The flag is cleared if the MO is a Measurement Reply. + o Type (T): This flag is set to 1 if the MO represents a Measurement + Request. The flag is cleared to 0 if the MO is a Measurement + Reply. - o Hop-by-hop (H): This flag is set if the MO travels along a hop-by- - hop route. In that case, the hop-by-hop route is identified by - the RPLInstanceID and, if the RPLInstanceID is a local value, the - Origin Address serving as the DODAGID. This flag is cleared if - the MO travels along a source route specified in the Address - vector. Note that, in case the P2P route being measured lies - along a non-storing DAG, an MO message may travel along a hop-by- - hop route till it reaches the DAG's root, which then sends it - along a source route to its destination. In that case, the DAG - root will reset the H flag and also insert the source route to the - destination inside the Address vector. + o Hop-by-hop (H): The origin sets this flag to 1 if the route being + measured is a hop-by-hop route. In that case, the hop-by-hop + route is identified by the RPLInstanceID and, if the RPLInstanceID + is a local value, the Origin Address serving as the DODAGID. The + origin resets this flag to 0 if the route being measured is a + source route specified in the Address vector. An intermediate + router MUST set the H flag in an outgoing MO packet to the same + value that it had in the corresponding incoming MO packet unless + the router is the root of the non-storing global DAG, identified + by the RPLInstanceID, along which the MO packet had been traveling + so far. In that case, the DAG root MUST reset the H flag to 0 in + the outgoing MO packet if it intends to insert a source route in + the Address vector to direct the MO packet towards the target. o Accumulate Route (A): This flag is relevant only if the MO represents a Measurement Request that travels along a hop-by-hop route represented by a local RPLInstanceID. In other words, this - flag MAY be set only if T = 1, H = 1 and the RPLInstanceID field - has a local value. Otherwise, this flag MUST be cleared. A value - 1 in this flag indicates that the Measurement Request MUST - accumulate a source route for use by the target to send the - Measurement Reply back to the origin. In this case, the - intermediate routers MUST add their IPv6 addresses (after eliding - Compr number of prefix octets) to the Address vector in the manner - specified later. + flag MAY be set to 1 only if T = 1, H = 1 and the RPLInstanceID + field has a local value. Otherwise, this flag MUST be cleared to + 0. A value 1 in this flag indicates that the Measurement Request + MUST accumulate a source route for use by the target to send the + Measurement Reply back to the origin. In this case, an + intermediate router MUST add its unicast IPv6 address (after + eliding Compr number of prefix octets) to the Address vector in + the manner specified later. Route accumulation is not allowed + when the Measurement Request travels along a hop-by-hop route with + a global RPLInstanceID, i.e., along a global DAG, because: + + * The DAG's root may need the Address vector to insert a source + route to the target; and + + * The target can presumably reach the origin along this global + DAG. o Reverse (R): This flag is relevant only if the MO represents a Measurement Request that travels along a source route, specified in the Address vector, to the target. In other words, this flag - MAY be set only if T = 1 and H = 0. Otherwise, this flag MUST be - cleared. A value 1 in the flag indicates that the Address vector - contains a complete source route from the origin to the target, - which can be used, after reversal, by the target to source route - the Measurement Reply message back to the origin. + MAY be set to 1 only if T = 1 and H = 0. Otherwise, this flag + MUST be cleared to 0. A value 1 in the flag indicates that the + Address vector contains a complete source route from the origin to + the target, which can be used, after reversal, by the target to + source route the Measurement Reply message back to the origin. o Back Request (B): This flag serves as a request to the target to send a Measurement Request towards the origin. The origin MAY set - this flag if it wants to make such a request to the target. On - receiving this request, the target MAY generate a Measurement - Request to measure the cost of its current (or the most preferred) - route to the origin. Receipt of this Measurement Request would - allow the origin to know the cost of the back route from the - target to itself and thus determine the round-trip cost of - reaching the target. + this flag to 1 if it wants to make such a request to the target. + An intermediate router MUST set the B flag in an outgoing MO + packet to the same value that it had in the corresponding incoming + MO packet. On receiving a Measurement Request with the B flag set + to 1, the target SHOULD generate a Measurement Request to measure + the cost of its current (or the most preferred) route to the + origin. Receipt of this Measurement Request would allow the + origin to know the cost of the back route from the target to + itself and thus determine the round-trip cost of reaching the + target. o Intermediate Reply (I): Relevant only if a hop-by-hop route is being measured, this flag serves as a permission to an intermediate router to generate a Measurement Reply if it knows the cost of the rest of the route being measured. The origin MAY - set this flag if a hop-by-hop route is being measured (i.e., H = - 1) and the origin wants to allow the intermediate routers to + set this flag to 1 if a hop-by-hop route is being measured (i.e., + H = 1) and the origin wants to allow an intermediate router to generate the Measurement Reply in response to this Measurement - Request. Setting this flag may be useful in scenarios where Hop - Count [I-D.ietf-roll-routing-metrics] is the routing metric of + Request. Setting this flag may be useful in scenarios where the + Hop Count [I-D.ietf-roll-routing-metrics] is the routing metric of interest and the origin expects an intermediate router (e.g. the root of a non-storing DAG or a common ancestor of the origin and the target in a storing DAG) to know the Hop Count of the remainder of the route to the target. This flag MUST be cleared - if the route being measured is a source route (i.e., H = 0). + to 0 if the route being measured is a source route (i.e., H = 0). o SequenceNo: A 6-bit sequence number, assigned by the origin, that allows the origin to uniquely identify a Measurement Request and - the corresponding Measurement Reply. + the corresponding Measurement Reply. An intermediate router MUST + set this field in the outgoing MO packet to the same value that it + had in the corresponding incoming MO packet. The target MUST set + this field in a Measurement Reply message to the same value that + it had in the corresponding Measurement Request message. - o Num: This field indicates the number of fields in the Address - vector. If the value of this field is zero, the Address vector is - not present in the MO. + o Num: The origin sets this field to indicate the number of fields + in the Address vector. If the value of this field is zero, the + Address vector is not present in the MO. o Index: If the Measurement Request is traveling along a source route contained in the Address vector (T=1,H=0), this field indicates the index in the Address vector of the next hop on the route. If the Measurement Request is traveling along a hop-by-hop route with a local RPLInstanceID and the A flag is set (T=1,H=1,A=1 and RPLInstanceID field has a local value), this field indicates the index in the Address vector where an intermediate router receiving the MO message must store its IPv6 address. Otherwise, this field MUST be set to zero on transmission and ignored on reception. - o Origin Address: An IPv6 address of the origin after eliding Compr - number of prefix octets. If the MO is traveling along a hop-by- - hop route and the RPLInstanceID field indicates a local value, the - Origin Address field MUST contain the DODAGID value that, along - with the RPLInstanceID, uniquely identifies within the RPL domain - the hop-by-hop route being measured. + o Origin Address: A unicast IPv6 address of the origin after eliding + Compr number of prefix octets. If the MO is traveling along a + hop-by-hop route and the RPLInstanceID field indicates a local + value, the Origin Address field MUST specify the DODAGID value + that, along with the RPLInstanceID, uniquely identifies the hop- + by-hop route being measured. - o Target Address: An IPv6 address of the target after eliding Compr - number of prefix octets. + o Target Address: A unicast IPv6 address of the target after eliding + Compr number of prefix octets. - o Address[1..Num]: A vector of IPv6 addresses (with Compr number of - prefix octets elided) representing a source route to the target: + o Address[1..Num]: A vector of unicast IPv6 addresses (with Compr + number of prefix octets elided) representing a source route to the + target: * Each element in the vector has size (16 - Compr) octets. * The total number of elements inside the Address vector is given by the Num field. * When the Measurement Request is traveling along a hop-by-hop route with local RPLInstanceID and has the A flag set, the Address vector is used to accumulate a source route to be used by the target to send the Measurement Reply back to the origin. In this case, the route MUST be accumulated in the forward direction, i.e., from the origin to the target. The target router would reverse this route to obtain a source route from itself to the origin. The IPv6 addresses in the accumulated - route MUST be accessible in the backward direction. An - intermediate router adding its address to the Address vector - MUST ensure that its address does not already exist in the - vector. + route MUST be accessible in the backward direction, i.e., from + the target to the origin. An intermediate router adding its + address to the Address vector MUST ensure that its address does + not already exist in the vector. * When the Measurement Request is traveling along a source route, the Address vector MUST contain a complete route to the target and the IPv6 addresses in the Address vector MUST be accessible in the forward direction, i.e., from the origin to the target. A router (origin or an intermediate router) inserting an Address vector inside an MO MUST ensure that no address appears more than once inside the vector. Each router on the way MUST ensure that the loops do not exist within the source route. - The origin may set the R flag in the MO if the route in the + The origin MAY set the R flag in the MO if the route in the Address vector represents a complete route from the origin to the target and this route can be used after reversal by the target to send the Measurement Reply message back to the origin. * The origin and target addresses MUST NOT be included in the Address vector. * The Address vector MUST NOT contain any multicast addresses. o Metric Container Options: An MO MUST contain one or more Metric - Container options to accumulate routing metric values for the + Container options to accumulate the routing metric values for the route being measured. 3.2. Secure MO A Secure MO message follows the format in Figure 7 of [I-D.ietf-roll-rpl], where the base format is the base MO shown in Figure 1. 4. Originating a Measurement Request If an origin needs to measure the routing metric values along a P2P route towards a target, it generates an MO message and sets its - fields in the manner described below. Additionally, the origin MUST - set the T flag to 1 to indicate that the MO represents a Measurement + fields as described in Section 3.1. The setting of MO fields in + specific cases is described below. In all cases, the origin MUST set + the T flag to 1 to indicate that the MO represents a Measurement Request. The origin MUST also include one or more Metric Container - options inside the MO that carry the routing metric objects of - interest. If required, the origin must also initiate these routing - metric objects by including the values of the routing metrics for the - first hop on the P2P route being measured. + options inside the MO to carry the routing metric objects of + interest. Depending on the metrics being measured, the origin must + also initiate these routing metric objects by including the values of + the routing metrics for the first hop on the P2P route being + measured. - After setting the MO fields as described below, the origin MUST - unicast the MO message to the next hop on the P2P route. + After setting the MO fields appropriately, the origin MUST unicast + the MO message to the next hop on the P2P route. 4.1. To Measure A Hop-by-hop Route with a Global RPLInstanceID If a hop-by-hop route with a global RPLInstanceID is being measured, the MO message MUST NOT contain the Address vector and the following MO fields MUST be set in the manner specified below: - o Hop-by-hop (H): This flag MUST be set; - - o Accumulate Route (A): This flag MUST be cleared; - - o Reverse (R): This flag MUST be cleared; + o Hop-by-hop (H): This flag MUST be set to 1. - o Back Request (B): This flag MAY be set if the origin wants to - request the target to generate a Measurement Request back to - itself; + o Accumulate Route (A): This flag MUST be cleared to 0. - o Intermediate Reply (I): This flag MAY be set if the origin wants - to permit the intermediate routers to generate the Measurement - Reply on the target's behalf; + o Reverse (R): This flag MUST be cleared to 0. - o Num: This field MUST be set to zero; + o Num: This field MUST be cleared to 0. - o Index: This field MUST be set to zero. + o Index: This field MUST be cleared to 0. 4.2. To Measure A Hop-by-hop Route with a Local RPLInstanceID If a hop-by-hop route with a local RPLInstanceID is being measured and the MO is not accumulating a source route for the target's use, the MO message MUST NOT contain the Address vector and the following MO fields MUST be set in the manner specified below: - o Hop-by-hop (H): This flag MUST be set; - o Accumulate Route (A): This flag MUST be cleared; - - o Reverse (R): This flag MUST be cleared; + o Hop-by-hop (H): This flag MUST be set to 1. - o Back Request (B): This flag MAY be set if the origin wants to - request the target to generate a Measurement Request back to - itself; + o Accumulate Route (A): This flag MUST be cleared to 0. - o Intermediate Reply (I): This flag MAY be set if the origin wants - to permit the intermediate routers to generate the Measurement - Reply on the target's behalf; + o Reverse (R): This flag MUST be cleared to 0. - o Num: This field MUST be set to zero; + o Num: This field MUST be cleared to 0. - o Index: This field MUST be set to zero; + o Index: This field MUST be cleared to 0. o Origin Address: This field MUST contain the DODAGID value (after eliding Compr number of prefix octets) associated with the route being measured. If a hop-by-hop route with a local RPLInstanceID is being measured and the origin desires the MO to accumulate a source route for the target to send the Measurement Reply message back, it MUST set the following MO fields in the manner specified below: - o Hop-by-hop (H): This flag MUST be set; - - o Accumulate Route (A): This flag MUST be set; + o Hop-by-hop (H): This flag MUST be set to 1. - o Reverse (R): This flag MUST be cleared; + o Accumulate Route (A): This flag MUST be set to 1. - o Back Request (B): This flag MAY be set if the origin wants to - request the target to generate a Measurement Request back to - itself; + o Reverse (R): This flag MUST be cleared to 0. - o Intermediate Reply (I): This flag MAY be set if the origin wants - to permit the intermediate routers to generate the Measurement - Reply on the target's behalf; + o Intermediate Reply (I): This flag MUST be cleared to 0. o Address vector: The Address vector must be large enough to accomodate a complete source route from the origin to the target. - All the bits in the Address vector field MUST be set to zero; + All the bits in the Address vector field MUST be cleared to 0. o Num: This field MUST specify the number of address elements that - can fit inside the Address vector; + can fit inside the Address vector. + + o Index: This field MUST be set to 1. - o Index: This field MUST be set to 1; o Origin Address: This field MUST contain the DODAGID value (after eliding Compr number of prefix octets) associated with the route being measured. 4.3. To Measure A Source Route If a source route is being measured, the origin MUST set the following MO fields in the manner specified below: - o RPLInstanceID: This field MUST be set to 10000000; - - o Hop-by-hop (H): This flag MUST be cleared; - - o Accumulate Route (A): This flag MUST be cleared; + o Hop-by-hop (H): This flag MUST be cleared to 0. - o Reverse (R): This flag MUST be set if the source route in the - Address vector can be reversed and used by the target to source - route the Measurement Reply message back to the origin. - Otherwise, this flag MUST be cleared; + o Accumulate Route (A): This flag MUST be cleared to 0. - o Back Request (B): This flag MAY be set if the origin wants to - request the target to generate a Measurement Request back to - itself; + o Reverse (R): This flag SHOULD be set to 1 if the source route in + the Address vector can be reversed and used by the target to + source route the Measurement Reply message back to the origin. + Otherwise, this flag MUST be cleared to 0. - o Intermediate Reply (I): This flag MUST be cleared. + o Intermediate Reply (I): This flag MUST be cleared to 0. o Address vector: * The Address vector MUST contain a complete route from the - origin to the target (excluding the origin and the target); + origin to the target (excluding the origin and the target). * The IPv6 addresses (with Compr prefix octets elided) in the Address vector MUST be accessible in the forward direction, - i.e., from the origin to the target; + i.e., from the origin to the target. * To prevent loops in the source route, the origin MUST ensure - that + compliance to the following rules: + Any IPv6 address MUST NOT appear more than once in the - Address vector; + Address vector. + If the Address vector includes multiple IPv6 addresses assigned to the origin's interfaces, such addresses MUST appear back to back inside the Address vector. * Each address appearing in the Address vector MUST be a unicast address. o Num: This field MUST be set to indicate the number of elements in - the Address vector; + the Address vector. o Index: This field MUST be set to 1. The origin MUST NOT send the packet further if the next hop address on the source route is not on-link. 5. Processing a Measurement Request at an Intermediate Router - A router MAY discard a received MO with no further processing to meet - any policy-related goal. Such policy goals may include the need to - reduce the router's CPU load or to enhance its battery life. + A router (an intermediate router or the target) MAY discard a + received MO with no further processing to meet any policy-related + goal. Such policy goals may include the need to reduce the router's + CPU load or to enhance its battery life. + + A router MUST discard a received MO with no further processing: + + o If the router is not aware of the RPL Instance identified by the + RPLInstanceID (and the Origin Address, if RPLInstanceID is a local + value) field in the message. + + o If the Compr field is not same as what the router considers as the + length of the common prefix used in IPv6 addresses in the LLN. On receiving an MO, if a router chooses to process the packet further, it MUST check if one of its IPv6 addresses is listed as - either the Origin or the Target Address. If not, the router + either the Origin or the Target Address. If neither, the router considers itself an Intermediate Router and MUST process the received MO in the following manner. An intermediate router MUST discard the packet with no further processing if the received MO is not a Measurement Request. - If the I flag is set in the received MO and the intermediate router - knows the values of the routing metrics, specified in the Metric - Container, for the remainder of the route, it MAY generate a + If the I flag is set to 1 in the received MO and the intermediate + router knows the values of the routing metrics, specified in the + Metric Container, for the remainder of the route, it MAY generate a Measurement Reply on the target's behalf in the manner specified in Section 6 (after including in the Measurement Reply the relevant routing metric values for the complete route being measured). Otherwise, the intermediate router MUST process the received MO in the following manner. The router MUST determine the next hop on the P2P route being measured in the manner described below. The router MUST drop the MO with no further processing and MAY send an ICMPv6 Destination Unreachable (with Code 0 - No Route To Destination) error message to @@ -546,59 +561,64 @@ After determining the next hop, the router MUST update the routing metric objects, contained in the Metric Container options inside the MO, either by updating the aggregated value for the routing metric or by attaching the local values for the metric inside the object. After updating the routing metrics, the router MUST unicast the MO to the next hop. 5.1. Determining Next Hop For An MO Measuring A Source Route - In case the received MO is measuring a source route (H=0), the router - MUST increment the Index field and use the Address[Index] element as - the next hop. If Index is greater than Num, the router MUST use the - Target Address as the next hop. + In case the received MO is measuring a source route (H=0), + + o The router MUST verify that the Address[Index] element lists one + of its unicast IPv6 addresses, failing which the router MUST + discard the MO packet with no further processing; + + o The router MUST then increment the Index field and use the + Address[Index] element as the next hop. If Index is greater than + Num, the router MUST use the Target Address as the next hop. An intermediate router MUST discard the MO packet with no further processing if the next hop address is not on-link or is not a unicast address. To prevent loops, an intermediate router MUST check if the Address vector includes multiple IPv6 addresses assigned to the router's interfaces and if such addresses do not appear back to back inside the Address vector. In this case, the router MUST discard the - MO packet with no further processing. An MO message MUST NOT leave - the RPL domain where it originated. Hence, an intermediate router - MUST discard an MO message traveling along a source route if the next - hop on the way does not lie within the RPL domain. + MO packet with no further processing. 5.2. Determining Next Hop For An MO Measuring A Hop-by-hop Route If the received MO is measuring a hop-by-hop route (H=1), the router MUST use the RPLInstanceID, the Target Address and, if RPLInstanceID - is a local value, the DODAGID (same as the Origin Address) to - determine the next hop for the MO. Moreover, + is a local value, the Origin Address to determine the next hop for + the MO. Moreover, o If the RPLInstanceID of the hop-by-hop route is a local value and the A flag is set, the router MUST check if the Address vector already contains one of its IPv6 addresses. If yes, the router MUST discard the packet with no further processing. Otherwise, the router MUST store one of its IPv6 addresses (after eliding Compr prefix octets) at location Address[Index] and then increment the Index field. o If the router is the root of the non-storing DAG along which the - received MO message has been traveling, the router MUST do the - following: + received MO message has been traveling so far, the router MUST do + the following: * Reset the H, A and R flags. - * Insert a source route to the target inside the Address vector - as per the following rules: + * Remove any existing Address vector inside the MO. + + * Insert a new Address vector inside the MO and specify a source + route to the target inside the Address vector as per the + following rules: + The Address vector MUST contain a complete route from the router to the target (excluding the router and the target); + The IPv6 addresses (with Compr prefix octets elided) in the Address vector MUST be accessible in the forward direction, i.e., towards the target; + To prevent loops in the source route, the router MUST ensure that @@ -614,156 +634,166 @@ unicast address. * Specify in the Num field the number of address elements in the Address vector. * Set the Index field to 1. 6. Processing a Measurement Request at the Target On receiving an MO, if a router chooses to process the packet further - and finds one of its IPv6 addresses listed as the Target Address, it - MUST process the received MO in the following manner. + and finds one of its unicast IPv6 addresses listed as the Target + Address, the router considers itself the target and MUST process the + received MO in the following manner. The target MUST discard the packet with no further processing if the received MO is not a Measurement Request. The target MUST update the routing metric objects in the Metric Container options if required and MAY note the measured values for - the complete route if desired. + the complete route (especially, if the received Measurement Request + is likely a response to an earlier Measurement Request that the + target had sent to the origin with B flag set to 1). - The target MUST generate a Measurement Reply message. The received - Measurement Request message can be trivially converted into the - Measurement Reply by reseting the T flag to zero. The target MAY - remove the Address vector from the Measurement Reply if desired. The - target MUST then unicast the Measurement Reply back to the origin: + The target MUST generate a Measurement Reply message. The + Measurement Reply message MUST have the same SequenceNo field as the + received Measurement Request message. The received Measurement + Request message can be trivially converted into the Measurement Reply + by reseting the T flag to zero. The target MAY remove the Address + vector from the Measurement Reply if desired. The target MUST then + unicast the Measurement Reply back to the origin: o If the Measurement Request traveled along a DAG with a global RPLInstanceID, the Measurement Reply MAY be unicast back to the origin along the same DAG. o If the Measurement Request traveled along a hop-by-hop route with a local RPLInstanceID and the A flag inside the received message - is set, the target MAY reverse the source route contained in the - Address vector and use it to send the Measurement Reply back to - the origin. + is set to 1, the target MAY reverse the source route contained in + the Address vector and use it to send the Measurement Reply back + to the origin. o If the Measurement Request traveled along a source route and the R - flag inside the received message is set, the target MAY reverse - the source route contained in the Address vector and use it to - send the Measurement Reply back to the origin. + flag inside the received message is set to 1, the target MAY + reverse the source route contained in the Address vector and use + it to send the Measurement Reply back to the origin. - If the B flag is set in the received Measurement Request, the target - MAY generate a new Measurement Request to measure the cost of its - current (or the most preferred) route to the origin. The routing + If the B flag in the received Measurement Request is set to 1, the + target MAY generate a new Measurement Request to measure the cost of + its current (or the most preferred) route to the origin. The routing metrics used in the new Measurement Request MUST include the routing metrics specified in the received Measurement Request. 7. Processing a Measurement Reply at the Origin - When a router receives an MO, it examines if one of its IPv6 - addresses is listed as the Origin Address. If yes, the router MUST - process the received message in the following manner. + When a router receives an MO, it examines if one of its unicast IPv6 + addresses is listed as the Origin Address. If yes, the router is the + origin and MUST process the received message in the following manner. The origin MUST discard the packet with no further processing if the received MO is not a Measurement Reply or if the origin has no recollection of sending a Measurement Request with the sequence number listed in the received MO. - The origin SHOULD examine the routing metric objects inside the - Metric Container options to evaluate the quality of the measured P2P - route. If a routing metric object contains local metric values - recorded by routers on the route, the origin MAY aggregate these - local values into an end-to-end value as per the aggregation rules - for the metric. + The origin MUST examine the routing metric objects inside the Metric + Container options to evaluate the quality of the measured P2P route. + If a routing metric object contains local metric values recorded by + routers on the route, the origin MUST aggregate these local values + into an end-to-end value as per the aggregation rules for the metric. 8. Security Considerations The mechanism defined in this document can potentially be used by a - compromised router to generate bogus measurement requests to - arbitrary target routers. Such bogus measurement requests may cause + compromised router to generate bogus Measurement Requests to + arbitrary target routers. Such Measurement Requests may cause processing overload in the routers in the network, drain their batteries and cause traffic congestion in the network. Note that some of these problems would occur even if the compromised router were to generate bogus data traffic to arbitrary destinations. Since a Measurement Request can travel along a source route specified in the Address vector, some of the security concerns that led to the deprecation of Type 0 routing header [RFC5095] may be valid here. To address such concerns, the mechanism described in this document includes several remedies: o This document requires that a route inserted inside the Address vector must be a strict source route and must not include any multicast addresses. o This document requires that an MO message must not cross the - boundaries of the RPL domain where it is originated. Hence, any - security problems associated with the mechanism would be limited - to the RPL domain where the MO message is generated. + boundaries of the RPL Instance where it originated. A router must + drop a received MO message if it is not aware of the RPL Instance + referred to in the message. Hence, any security problems + associated with the mechanism would be limited to one RPL + Instance. - o A router must drop a received MO message if the next hop address - is not on-link or if it is not a unicast address. + o This document requires that a router must drop a received MO + message if the next hop address is not on-link or if it is not a + unicast address. - o A router must check the source route inside the Address vector of - each received MO message to ensure that it does not contain a loop - involving the router. The router must drop the received packet if - the source route does contain such a loop. This and the previous - rule protect the network against some of the security concerns - even if a compromised node inserts the Address vector inside the - MO message. + o This document requires that a router must check the source route + inside the Address vector of each received MO message to ensure + that it does not contain a loop involving the router. The router + must drop the received packet if the source route does contain + such a loop. This and the previous two rules protect the network + against some of the security concerns even if a compromised node + inserts a malformed Address vector inside the MO message. 9. IANA Considerations - IANA is requested to allocate a new code point in the "RPL Control - Codes" registry for the "Measurement Object" described in this - document. + IANA is requested to allocate new code points in the "RPL Control + Codes" registry for the "Measurement Object" and "Secure Measurement + Object" described in this document. +------+---------------------------+---------------+ | Code | Description | Reference | +------+---------------------------+---------------+ | 0x06 | Measurement Object | This document | | 0x86 | Secure Measurement Object | This document | +------+---------------------------+---------------+ RPL Control Codes 10. Acknowledgements - Authors gratefully acknowledge the contributions of Pascal Thubert, - Richard Kelsey and Zach Shelby in the development of this document. + Authors gratefully acknowledge the contributions of Matthias Philipp, + Pascal Thubert, Richard Kelsey and Zach Shelby in the development of + this document. 11. References + 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11.2. Informative References [I-D.ietf-roll-p2p-rpl] - Goyal, M., Baccelli, E., Philipp, M., Brandt, A., Cragie, - R., and J. Martocci, "Reactive Discovery of Point-to-Point - Routes in Low Power and Lossy Networks", - draft-ietf-roll-p2p-rpl-04 (work in progress), July 2011. + Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. + Martocci, "Reactive Discovery of Point-to-Point Routes in + Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-08 + (work in progress), March 2012. [I-D.ietf-roll-routing-metrics] - Vasseur, J., Kim, M., Pister, K., Dejean, N., and D. - Barthel, "Routing Metrics used for Path Calculation in Low + Barthel, D., Vasseur, J., Pister, K., Kim, M., and N. + Dejean, "Routing Metrics used for Path Calculation in Low Power and Lossy Networks", draft-ietf-roll-routing-metrics-19 (work in progress), March 2011. [I-D.ietf-roll-rpl] - Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., - Kelsey, R., Levis, P., Pister, K., Struik, R., and J. - Vasseur, "RPL: IPv6 Routing Protocol for Low power and + Brandt, A., Vasseur, J., Hui, J., Pister, K., Thubert, P., + Levis, P., Struik, R., Kelsey, R., Clausen, T., and T. + + Winter, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", draft-ietf-roll-rpl-19 (work in progress), March 2011. [I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-06 (work in progress), September 2011. [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095,