summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6998.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6998.txt')
-rw-r--r--doc/rfc/rfc6998.txt1627
1 files changed, 1627 insertions, 0 deletions
diff --git a/doc/rfc/rfc6998.txt b/doc/rfc/rfc6998.txt
new file mode 100644
index 0000000..b8ed024
--- /dev/null
+++ b/doc/rfc/rfc6998.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) M. Goyal, Ed.
+Request for Comments: 6998 Univ. of Wisconsin Milwaukee
+Category: Experimental E. Baccelli
+ISSN: 2070-1721 INRIA
+ A. Brandt
+ Sigma Designs
+ J. Martocci
+ Johnson Controls
+ August 2013
+
+
+A Mechanism to Measure the Routing Metrics along a Point-to-Point Route
+ in a Low-Power and Lossy Network
+
+Abstract
+
+ This document specifies a mechanism that enables a Routing Protocol
+ for Low-power and Lossy Networks (RPL) router to measure the
+ aggregated values of given routing metrics along an existing route
+ towards another RPL router, thereby allowing the router to decide if
+ it wants to initiate the discovery of a better route.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for examination, experimental implementation, and
+ evaluation.
+
+ This document defines an Experimental Protocol for the Internet
+ community. This document is a product of the Internet Engineering
+ Task Force (IETF). It represents the consensus of the IETF
+ community. It has received public review and has been approved for
+ publication by the Internet Engineering Steering Group (IESG). Not
+ all documents approved by the IESG are a candidate for any level of
+ Internet Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6998.
+
+
+
+
+
+
+
+
+
+
+
+
+Goyal, et al. Experimental [Page 1]
+
+RFC 6998 Measurement of Routing Metrics in LLNs August 2013
+
+
+Copyright Notice
+
+ Copyright (c) 2013 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Goyal, et al. Experimental [Page 2]
+
+RFC 6998 Measurement of Routing Metrics in LLNs August 2013
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 1.1. Terminology ................................................5
+ 2. Overview ........................................................6
+ 3. The Measurement Object (MO) .....................................7
+ 3.1. Format of the Base MO ......................................8
+ 3.2. Secure MO .................................................12
+ 4. Originating a Measurement Request ..............................13
+ 4.1. When Measuring a Hop-by-Hop Route with a Global
+ RPLInstanceID .............................................14
+ 4.2. When Measuring a Hop-by-Hop Route with a Local
+ RPLInstanceID with Route Accumulation Off .................15
+ 4.3. When Measuring a Hop-by-Hop Route with a Local
+ RPLInstanceID with Route Accumulation On ..................16
+ 4.4. When Measuring a Source Route .............................17
+ 5. Processing a Measurement Request at an Intermediate Point ......19
+ 5.1. When Measuring a Hop-by-Hop Route with a Global
+ RPLInstanceID .............................................19
+ 5.2. When Measuring a Hop-by-Hop Route with a Local
+ RPLInstanceID with Route Accumulation Off .................21
+ 5.3. When Measuring a Hop-by-Hop Route with a Local
+ RPLInstanceID with Route Accumulation On ..................21
+ 5.4. When Measuring a Source Route .............................22
+ 5.5. Final Processing ..........................................23
+ 6. Processing a Measurement Request at the End Point ..............23
+ 6.1. Generating the Measurement Reply ..........................24
+ 7. Processing a Measurement Reply at the Start Point ..............25
+ 8. Security Considerations ........................................25
+ 9. IANA Considerations ............................................27
+ 10. Acknowledgements ..............................................27
+ 11. References ....................................................28
+ 11.1. Normative References .....................................28
+ 11.2. Informative References ...................................28
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Goyal, et al. Experimental [Page 3]
+
+RFC 6998 Measurement of Routing Metrics in LLNs August 2013
+
+
+1. Introduction
+
+ Point-to-point (P2P) communication between arbitrary routers in a
+ Low-power and Lossy Network (LLN) is a key requirement for many home
+ and commercial building automation applications [RFC5826] [RFC5867].
+ The IPv6 Routing Protocol for LLNs (RPL) [RFC6550] constrains the LLN
+ topology to a Directed 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:
+
+ 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 that all
+ P2P routes 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 an application's requirements, [RFC6997]
+ describes P2P-RPL, an extension to core RPL. P2P-RPL provides a
+ reactive mechanism to discover P2P routes that meet the specified
+ routing constraints [RFC6551]. In some cases, the application's
+ requirements or the LLN's topological features allow a router to
+ infer these routing constraints implicitly. For example, the
+ application may require that the end-to-end loss rate and/or latency
+ along the route be below certain thresholds, or the LLN topology may
+ be such that a router can safely assume that its destination is less
+ than a certain number of hops away from itself.
+
+ When the existing routes are deemed unsatisfactory but the router
+ 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
+ (expected transmission count) [RFC6551] 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-RPL route discovery. Note that it
+ is important that the routing constraints not be overly strict;
+ otherwise, the P2P-RPL route discovery may fail even though a route
+ exists that is much better than the one currently being used.
+
+
+
+
+
+
+Goyal, et al. Experimental [Page 4]
+
+RFC 6998 Measurement of Routing Metrics in LLNs August 2013
+
+
+ This document specifies a mechanism that enables a 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 discover a better route using P2P-RPL
+ and determine the routing constraints to be used for this purpose.
+ Thus, the utility of this mechanism is dependent on the existence of
+ P2P-RPL [RFC6997]. The hope is that experiments with P2P-RPL and the
+ mechanism defined in this document will result in feedback on the
+ utility and benefits of this document, so that a Standards Track
+ version of this document can then be developed.
+
+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 [RFC6550],
+ [RFC6554], and [RFC6997]. Further terminology may be found in
+ [ROLL-TERMS]. This document defines the following terms:
+
+ Start Point: The RPL router that initiates the measurement process
+ defined in this document and that is the start point of the P2P
+ route being measured.
+
+ End Point: The RPL router at the end point of the P2P route being
+ measured.
+
+ Intermediate Point: A RPL router, other than the Start Point and the
+ End Point, on the P2P route being measured.
+
+ The following terms, as already defined in [RFC6997], are redefined
+ in this document in the following manner:
+
+ Forward direction: The direction from the Start Point to the
+ End Point.
+
+ Reverse direction: The direction from the End Point to the
+ Start Point.
+
+
+
+
+
+
+
+
+
+
+
+Goyal, et al. Experimental [Page 5]
+
+RFC 6998 Measurement of Routing Metrics in LLNs August 2013
+
+
+2. Overview
+
+ The mechanism described in this document can be used by a Start Point
+ in an LLN to measure the aggregated values of selected routing
+ metrics along a P2P route to an End Point within the LLN. The route
+ is measured in the Forward direction. Such a route could be a Source
+ Route or a Hop-by-hop Route established using RPL [RFC6550] or
+ P2P-RPL [RFC6997]. Such a route could also be a "mixed" route, with
+ the initial part consisting of hop-by-hop ascent to the root of a
+ non-storing DAG [RFC6550] and the final part consisting of a source-
+ routed descent to the End Point. The Start Point decides what
+ metrics to measure and sends a Measurement Request message, carrying
+ the desired routing metric objects, along the route. If a Source
+ Route is being measured, the Measurement Request carries the route
+ inside an Address vector. If a Hop-by-hop Route is being measured,
+ the Measurement Request identifies the route by its RPLInstanceID
+ [RFC6550] (and, if the RPLInstanceID is a local value, the
+ Start Point's IPv6 address associated with the route). On receiving
+ a Measurement Request, an Intermediate Point updates the routing
+ metric values inside the message and forwards it to the next hop on
+ the route. Thus, the Measurement Request accumulates the values of
+ the routing metrics for the complete route as it travels towards the
+ End Point. Upon receiving the Measurement Request, the End Point
+ unicasts a Measurement Reply message, carrying the accumulated values
+ of the routing metrics, back to the Start Point. Optionally, the
+ Start Point may allow an Intermediate Point to generate the
+ Measurement Reply if the Intermediate Point already knows the
+ relevant routing metric values along the rest of the route.
+
+ The Measurement Request may include an Address vector that serves one
+ of the following functions:
+
+ o To accumulate a Source Route for the End Point's use: If a Hop-by-
+ hop Route with a local RPLInstanceID is being measured, the
+ Start Point may require that each Intermediate Point add its
+ global or unique-local IPv6 address to an Address vector inside
+ the Measurement Request. The Source Route, thus accumulated, can
+ be used by the End Point to reach the Start Point. In particular,
+ the End Point may use the accumulated Source Route to send the
+ Measurement Reply back to the Start Point. In this case, the
+ Start Point includes a suitably sized Address vector in the
+ Measurement Request. The size of the Address vector puts a hard
+ limit on the length of the accumulated route. An Intermediate
+ Point is not allowed to modify the size of the Address vector and
+ must discard a received Measurement Request if the Address vector
+ is not large enough to contain the complete route.
+
+
+
+
+
+Goyal, et al. Experimental [Page 6]
+
+RFC 6998 Measurement of Routing Metrics in LLNs August 2013
+
+
+ o To carry the Source Route being measured: The Start Point may
+ insert an Address vector inside the Measurement Request to carry
+ the Source Route being measured. Also, the root of a global
+ non-storing DAG may insert an Address vector, carrying a Source
+ Route from itself to the End Point, inside a Measurement Request
+ message if this message had been traveling along this DAG so far.
+ This Source Route must consist of global or unique-local IPv6
+ addresses. An Intermediate Point is not allowed to modify an
+ existing Address vector before forwarding the Measurement Request
+ further. In other words, an Intermediate Point must not modify
+ the Source Route along which the Measurement Request is currently
+ traveling.
+
+3. The Measurement Object (MO)
+
+ This document defines two new RPL control message types: the
+ Measurement Object (MO), with code 0x06; and the Secure MO, with
+ code 0x86. An MO serves as both Measurement Request and
+ Measurement Reply.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Goyal, et al. Experimental [Page 7]
+
+RFC 6998 Measurement of Routing Metrics in LLNs August 2013
+
+
+3.1. Format of the Base MO
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | RPLInstanceID | Compr |T|H|A|R|B|I| SeqNo | Num | Index |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ . Start Point Address .
+ . .
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ . End Point Address .
+ . .
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ . Address[0..Num-1] .
+ . .
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ . 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: This field specifies the RPLInstanceID of the
+ Hop-by-hop Route along which the Measurement Request travels
+ (or traveled initially until it switched over to a Source Route).
+
+ 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 the Start Point/End Point
+ Address fields and the Address vector. The "Compr" field, a 4-bit
+ unsigned integer, is set by the Start Point to specify the number
+ of prefix octets that are elided from the IPv6 addresses in
+ Start Point/End Point Address fields and the Address vector. The
+ Start Point will set the Compr value to zero if full IPv6
+ addresses are to be carried in the Start Point Address/End Point
+ Address fields and the Address vector.
+
+
+
+
+Goyal, et al. Experimental [Page 8]
+
+RFC 6998 Measurement of Routing Metrics in LLNs August 2013
+
+
+ o Type (T): This flag is set to one if the MO represents a
+ Measurement Request. The flag is set to zero if the MO is a
+ Measurement Reply.
+
+ o Hop-by-hop (H): The Start Point MUST set this flag to one if (at
+ least the initial part of) the route being measured is hop by hop.
+ In that case, the Hop-by-hop Route is identified by the
+ RPLInstanceID, the End Point Address, and, if the RPLInstanceID is
+ a local value, the Start Point Address fields inside the
+ Measurement Request. Here, the Start Point Address field is
+ required to be the same as the DODAGID (the identifier of the
+ Destination-Oriented DAG (DODAG) root) [RFC6550] of the route
+ being measured. The Start Point MUST set the H flag to zero if
+ the route being measured is a Source Route specified in the
+ Address vector. An Intermediate Point MUST set the H flag in an
+ outgoing Measurement Request to the same value that it had in the
+ corresponding incoming Measurement Request, except under the
+ following circumstance: If the Intermediate Point is the root of
+ the non-storing global DAG along which the Measurement Request had
+ been traveling so far and it intends to insert a Source Route
+ inside the Address vector to direct the Measurement Request
+ towards the End Point, then it MUST set the H flag to zero.
+
+ o Accumulate Route (A): A value of 1 in this flag indicates that the
+ Measurement Request is accumulating a Source Route for use by the
+ End Point to send the Measurement Reply back to the Start Point.
+ Route accumulation MUST NOT be used (i.e., this flag MUST NOT be
+ set to one) inside a Measurement Request, unless it travels along
+ a Hop-by-hop Route represented by a local RPLInstanceID (i.e., H =
+ 1 and RPLInstanceID has a local value). Route accumulation MAY be
+ used (i.e., this flag MAY be set to one) if the Measurement
+ Request is traveling along a Hop-by-hop Route with a local
+ RPLInstanceID. In this case, if the route accumulation is on, an
+ Intermediate Point adds its unicast global/unique-local IPv6
+ address (after eliding Compr number of prefix octets) to the
+ Address vector in the manner specified in Section 5.3. In other
+ cases, this flag MUST be set to zero on transmission and ignored
+ on reception. 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 End Point; and
+
+ * The End Point can presumably reach the Start Point along this
+ global DAG (identified by the RPLInstanceID field).
+
+
+
+
+
+Goyal, et al. Experimental [Page 9]
+
+RFC 6998 Measurement of Routing Metrics in LLNs August 2013
+
+
+ o Reverse (R): A value of 1 in this flag inside a Measurement
+ Request indicates that the Address vector contains a complete
+ Source Route from the Start Point to the End Point, which can be
+ used, after reversal, by the End Point to send the Measurement
+ Reply back to the Start Point. This flag MAY be set to one inside
+ a Measurement Request only if a Source Route, from the Start Point
+ to the End Point, is being measured. Otherwise, this flag MUST be
+ set to zero on transmission and ignored on reception.
+
+ o Back Request (B): A value of 1 in this flag serves as a request to
+ the End Point to send a Measurement Request towards the
+ Start Point. On receiving a Measurement Request with the B flag
+ set to one, the End Point SHOULD generate a Measurement Request to
+ measure the cost of its current (or the most preferred) route to
+ the Start Point. Receipt of this Measurement Request would allow
+ the Start Point to know the cost of the back route from the
+ End Point to itself and thus determine the round-trip cost of
+ reaching the End Point.
+
+ o Intermediate Reply (I): A value of 1 in this flag serves as
+ permission to an Intermediate Point to generate a Measurement
+ Reply if it knows the aggregated values of the routing metrics
+ being measured for the rest of the route. Setting this flag to
+ one may be useful in scenarios where the Hop Count [RFC6551] is
+ the routing metric of interest and an Intermediate Point (e.g.,
+ the root of a non-storing global DAG or a common ancestor of the
+ Start Point and the End Point in a storing global DAG) may know
+ the Hop Count of the remainder of the route to the End Point.
+ This flag MAY be set to one only if a Hop-by-hop Route with a
+ global RPLInstanceID is being measured (i.e., H = 1 and
+ RPLInstanceID has a global value). Otherwise, this flag MUST be
+ set to zero on transmission and ignored on reception.
+
+ o SeqNo: This is a 6-bit sequence number, assigned by the
+ Start Point, that allows the Start Point to uniquely identify a
+ Measurement Request and the corresponding Measurement Reply.
+
+ o Num: This field indicates the number of elements, each
+ (16 - Compr) octets in size, inside 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 (i.e., 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 route accumulation is on
+ (i.e., H = 1, RPLInstanceID has a local value, and A = 1), this
+
+
+
+Goyal, et al. Experimental [Page 10]
+
+RFC 6998 Measurement of Routing Metrics in LLNs August 2013
+
+
+ field indicates the index in the Address vector where an
+ Intermediate Point receiving the Measurement Request must store
+ its IPv6 address. Otherwise, this field MUST be set to zero on
+ transmission and ignored on reception.
+
+ o Start Point Address: This is a unicast global or unique-local IPv6
+ address of the Start Point after eliding Compr number of prefix
+ octets. If the Measurement Request is traveling along a Hop-by-
+ hop Route and the RPLInstanceID field indicates a local value, the
+ Start Point Address field MUST specify the DODAGID value that,
+ along with the RPLInstanceID and the End Point Address, uniquely
+ identifies the Hop-by-hop Route being measured.
+
+ o End Point Address: This is a unicast global or unique-local IPv6
+ address of the End Point after eliding Compr number of prefix
+ octets.
+
+ o Address[0..Num-1]: This field is a vector of unicast global or
+ unique-local IPv6 addresses (with Compr number of prefix octets
+ elided) representing a Source Route:
+
+ * 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.
+
+ * The Start Point and End Point addresses MUST NOT be included in
+ the Address vector.
+
+ * The Address vector MUST NOT contain any multicast addresses.
+
+ * If the Start Point wants to measure a Hop-by-hop Route with a
+ local RPLInstanceID and accumulate a Source Route for the
+ End Point's use (i.e., the Measurement Request has the H flag
+ set to one, RPLInstanceID set to a local value, and the A flag
+ set to one), it MUST include a suitably sized Address vector in
+ the Measurement Request. As the Measurement Request travels
+ over the route being measured, the Address vector accumulates a
+ Source Route that can be used by the End Point, after reversal,
+ to reach (and, in particular, to send the Measurement Reply
+ back to) the Start Point. The route MUST be accumulated in the
+ Forward direction, but the IPv6 addresses in the accumulated
+ route MUST be reachable in the Reverse direction. An
+ Intermediate Point MUST add only a global or unique-local IPv6
+ address to the Address vector and MUST NOT modify the size of
+ the Address vector.
+
+
+
+
+
+Goyal, et al. Experimental [Page 11]
+
+RFC 6998 Measurement of Routing Metrics in LLNs August 2013
+
+
+ * If the Start Point wants to measure a Source Route, it MUST
+ include an Address vector, containing the route being measured,
+ inside the Measurement Request. Similarly, if the Measurement
+ Request had been traveling along a global non-storing DAG so
+ far, the root of this DAG may insert an Address vector,
+ containing a Source Route from itself to the End Point, inside
+ the Measurement Request. In both cases, the Source Route
+ inside the Address vector MUST consist only of global or
+ unique-local IPv6 addresses that are reachable in the Forward
+ direction. Further, in both cases, an Intermediate Point MUST
+ NOT modify the contents of the existing Address vector before
+ forwarding the Measurement Request further. In other words, an
+ Intermediate Point MUST NOT modify the Source Route along which
+ the Measurement Request is currently traveling. The
+ Start Point MAY set the R flag in the Measurement Request to
+ one if the Source Route inside the Address vector can be used
+ by the End Point, after reversal, to reach (and, in particular,
+ to send the Measurement Reply back to) the Start Point. In
+ other words, the Start Point MAY set the R flag to one only if
+ all the IPv6 addresses in the Address vector are reachable in
+ the Reverse direction.
+
+ o Metric Container Options: A Measurement Request MUST contain one
+ or more Metric Container options [RFC6550] to accumulate the
+ values of the selected routing metrics in the manner described in
+ [RFC6551] for the route being measured.
+
+ Section 4 describes how a Start Point sets various fields inside a
+ Measurement Request in different cases. Section 5 describes how an
+ Intermediate Point processes a received Measurement Request before
+ forwarding it further. Section 6 describes how the End Point
+ processes a received Measurement Request and generates a Measurement
+ Reply. Finally, Section 7 describes how the Start Point processes a
+ received Measurement Reply. In the following discussion, any
+ reference to discarding a received Measurement Request/Reply with "no
+ further processing" does not preclude updating the appropriate error
+ counters or any similar actions.
+
+3.2. Secure MO
+
+ A Secure MO follows the format shown in Figure 7 of [RFC6550], where
+ the base format is the base MO shown in Figure 1. Sections 6.1, 10,
+ and 19 of [RFC6550] describe the RPL security framework. These
+ sections are applicable to the use of Secure MO messages as well,
+ except as constrained in this section. An LLN deployment MUST
+ support the use of Secure MO messages so that it has the ability to
+ invoke RPL-provided security mechanisms and prevent misuse of the
+ measurement mechanism by unauthorized routers.
+
+
+
+Goyal, et al. Experimental [Page 12]
+
+RFC 6998 Measurement of Routing Metrics in LLNs August 2013
+
+
+ The Start Point determines whether Secure MO messages are to be used
+ in a particular route measurement and, if yes, the Security
+ Configuration (see definition in [RFC6997]) to be used for that
+ purpose. The Start Point MUST NOT set the "Key Identifier Mode"
+ field to a value of 1 inside this Security Configuration, since this
+ setting indicates the use of a per-pair key, which is not suitable
+ for securing the Measurement Request messages that travel over
+ multiple hops. A router (an Intermediate Point or the End Point)
+ participating in a particular route measurement
+
+ o MUST generate a Secure MO message (a Measurement Request or a
+ Measurement Reply) if the received Measurement Request is a Secure
+ MO. The Security Configuration used in generating a Secure MO
+ message MUST be the same as the one used in the received message.
+
+ o MUST NOT generate a Secure MO message if the received Measurement
+ Request is not a Secure MO.
+
+ A router MUST discard a received Measurement Request if it cannot
+ follow the above-mentioned rules. If the Start Point sends a
+ Measurement Request in a Secure MO message using a particular
+ Security Configuration, it MUST discard the corresponding Measurement
+ Reply it receives with no further processing, unless the Measurement
+ Reply is received in a Secure MO message generated with the same
+ Security Configuration as the one used in the Measurement Request.
+
+ In the following discussion, any reference to an MO message is also
+ applicable to a Secure MO message, unless noted otherwise.
+
+4. Originating a Measurement Request
+
+ A Start Point sets various fields inside the Measurement Request it
+ generates in the manner described below. The Start Point MUST also
+ include the routing metric objects [RFC6551] of interest inside one
+ or more Metric Container options inside the Measurement Request. The
+ Start Point then determines the next hop on the route being measured.
+ If a Hop-by-hop Route is being measured (i.e., H = 1), the next hop
+ is determined using the RPLInstanceID, the End Point Address, and, if
+ RPLInstanceID is a local value, the Start Point Address fields in the
+ Measurement Request. If a Source Route is being measured (i.e.,
+ H = 0), the Address[0] element inside the Measurement Request
+ contains the next-hop address. The Start Point MUST ensure that
+
+ o the next-hop address is a unicast address, and
+
+ o the next hop is on-link, and
+
+
+
+
+
+Goyal, et al. Experimental [Page 13]
+
+RFC 6998 Measurement of Routing Metrics in LLNs August 2013
+
+
+ o the next hop is in the same RPL routing domain [RFC6554] as the
+ Start Point,
+
+ failing which the Start Point MUST discard the Measurement Request
+ without sending. Depending on the routing metrics, the Start Point
+ must initiate the routing metric objects inside the Metric Container
+ options by including the routing metric values for the first hop on
+ the route being measured. Finally, the Start Point MUST unicast the
+ Measurement Request to the next hop on the route being measured.
+
+ The Start Point MUST maintain state for a just-transmitted
+ Measurement Request, for a lifetime duration that is large enough to
+ allow the corresponding Measurement Reply to return. This state
+ consists of the RPLInstanceID, the SeqNo, and the End Point Address
+ fields of the Measurement Request. The lifetime duration for this
+ state is locally determined by the Start Point and may be deployment
+ specific. This state expires when the corresponding Measurement
+ Reply is received or when the lifetime is over, whichever occurs
+ first. Failure to receive the corresponding Measurement Reply before
+ the expiry of a state may occur due to a number of reasons, including
+ the unwillingness on the part of an Intermediate Point or the
+ End Point to process the Measurement Request. The Start Point should
+ take such possibilities into account when deciding whether to
+ generate another Measurement Request for this route. The Start Point
+ MUST discard a received Measurement Reply with no further processing
+ if the state for the corresponding Measurement Request has already
+ expired.
+
+4.1. When Measuring a Hop-by-Hop Route with a Global RPLInstanceID
+
+ If a Hop-by-hop Route with a global RPLInstanceID is being measured
+ (i.e., H = 1 and RPLInstanceID has a global value), the MO MUST NOT
+ contain an Address vector, and various MO fields MUST be set in the
+ following manner:
+
+ o RPLInstanceID: This field MUST be set to the RPLInstanceID of the
+ route being measured.
+
+ o Compr: This field MUST be set to specify the number of prefix
+ octets that are elided from the IPv6 addresses in Start Point/
+ End Point Address fields.
+
+ o Type (T): This flag MUST be set to one, since the MO represents a
+ Measurement Request.
+
+ o Hop-by-hop (H): This flag MUST be set to one.
+
+ o Accumulate Route (A): This flag MUST be set to zero.
+
+
+
+Goyal, et al. Experimental [Page 14]
+
+RFC 6998 Measurement of Routing Metrics in LLNs August 2013
+
+
+ o Reverse (R): This flag MUST be set to zero.
+
+ o Back Request (B): This flag MAY be set to one to request that the
+ End Point send a Measurement Request to the Start Point.
+
+ o Intermediate Reply (I): This flag MAY be set to one if the
+ Start Point expects an Intermediate Point to know the values of
+ the routing metrics being measured for the remainder of the route.
+
+ o SeqNo: This is assigned by the Start Point so that it can uniquely
+ identify the Measurement Request and the corresponding
+ Measurement Reply.
+
+ o Num: This field MUST be set to zero.
+
+ o Index: This field MUST be set to zero.
+
+ o Start Point Address: This field MUST be set to a unicast
+ global/unique-local IPv6 address of the Start Point after eliding
+ Compr number of prefix octets.
+
+ o End Point Address: This field MUST be set to a unicast
+ global/unique-local IPv6 address of the End Point after eliding
+ Compr number of prefix octets.
+
+4.2. When Measuring a Hop-by-Hop Route with a Local RPLInstanceID with
+ Route Accumulation Off
+
+ If a Hop-by-hop Route with a local RPLInstanceID is being measured
+ and the Start Point does not want the MO to accumulate a Source Route
+ for the End Point's use, the MO MUST NOT contain the Address vector,
+ and various MO fields MUST be set in the following manner:
+
+ o RPLInstanceID: This field MUST be set to the RPLInstanceID of the
+ route being measured.
+
+ o Compr: This field MUST be set to specify the number of prefix
+ octets that are elided from the IPv6 addresses in Start Point/
+ End Point Address fields.
+
+ o Type (T): This flag MUST be set to one, since the MO represents a
+ Measurement Request.
+
+ o Hop-by-hop (H): This flag MUST be set to one.
+
+ o Accumulate Route (A): This flag MUST be set to zero.
+
+ o Reverse (R): This flag MUST be set to zero.
+
+
+
+Goyal, et al. Experimental [Page 15]
+
+RFC 6998 Measurement of Routing Metrics in LLNs August 2013
+
+
+ o Back Request (B): This flag MAY be set to one to request that the
+ End Point send a Measurement Request to the Start Point.
+
+ o Intermediate Reply (I): This flag MUST be set to zero.
+
+ o SeqNo: This is assigned by the Start Point so that it can uniquely
+ identify the Measurement Request and the corresponding
+ Measurement Reply.
+
+ o Num: This field MUST be set to zero.
+
+ o Index: This field MUST be set to zero.
+
+ o Start Point Address: This field MUST contain the DODAGID value
+ (after eliding Compr number of prefix octets) associated with the
+ route being measured. This DODAGID MUST also be a global or
+ unique-local IPv6 address of the Start Point.
+
+ o End Point Address: This field MUST be set to a unicast global or
+ unique-local IPv6 address of the End Point after eliding Compr
+ number of prefix octets.
+
+4.3. When Measuring a Hop-by-Hop Route with a Local RPLInstanceID with
+ Route Accumulation On
+
+ If a Hop-by-hop Route with a local RPLInstanceID is being measured
+ and the Start Point desires the MO to accumulate a Source Route for
+ the End Point to send the Measurement Reply message back, the MO MUST
+ contain a suitably sized Address vector, and various MO fields MUST
+ be set in the following manner:
+
+ o RPLInstanceID: This field MUST be set to the RPLInstanceID of the
+ route being measured.
+
+ o Compr: This field MUST be set to specify the number of prefix
+ octets that are elided from the IPv6 addresses in Start Point/
+ End Point Address fields and the Address vector.
+
+ o Type (T): This flag MUST be set to one, since the MO represents a
+ Measurement Request.
+
+ o Hop-by-hop (H): This flag MUST be set to one.
+
+ o Accumulate Route (A): This flag MUST be set to one.
+
+ o Reverse (R): This flag MUST be set to zero.
+
+
+
+
+
+Goyal, et al. Experimental [Page 16]
+
+RFC 6998 Measurement of Routing Metrics in LLNs August 2013
+
+
+ o Back Request (B): This flag MAY be set to one to request that the
+ End Point send a Measurement Request to the Start Point.
+
+ o Intermediate Reply (I): This flag MUST be set to zero.
+
+ o SeqNo: This is assigned by the Start Point so that it can uniquely
+ identify the Measurement Request and the corresponding
+ Measurement Reply.
+
+ o Num: This field MUST specify the number of address elements, each
+ (16 - Compr) octets in size, that can fit inside the Address
+ vector.
+
+ o Index: This field MUST be set to zero to indicate the position in
+ the Address vector where the next hop must store its IPv6 address.
+
+ o Start Point Address: This field MUST contain the DODAGID value
+ (after eliding Compr number of prefix octets) associated with the
+ route being measured. This DODAGID MUST also be a global or
+ unique-local IPv6 address of the Start Point.
+
+ o End Point Address: This field MUST be set to a unicast global or
+ unique-local IPv6 address of the End Point after eliding Compr
+ number of prefix octets.
+
+ o Address vector: The Address vector must be large enough to
+ accommodate a complete Source Route from the End Point to the
+ Start Point. All the bits in the Address vector field MUST be set
+ to zero.
+
+4.4. When Measuring a Source Route
+
+ If a Source Route is being measured, the Start Point MUST set various
+ MO fields in the following manner:
+
+ o RPLInstanceID: This field does not have any significance when a
+ Source Route is being measured and hence can be set to any value.
+
+ o Compr: This field MUST be set to specify the number of prefix
+ octets that are elided from the IPv6 addresses in Start Point/
+ End Point Address fields and the Address vector.
+
+ o Type (T): This flag MUST be set to one, since the MO represents a
+ Measurement Request.
+
+ o Hop-by-hop (H): This flag MUST be set to zero.
+
+ o Accumulate Route (A): This flag MUST be set to zero.
+
+
+
+Goyal, et al. Experimental [Page 17]
+
+RFC 6998 Measurement of Routing Metrics in LLNs August 2013
+
+
+ o Reverse (R): This flag SHOULD be set to one if the Source Route in
+ the Address vector can be reversed and used by the End Point to
+ send the Measurement Reply message back to the Start Point.
+ Otherwise, this flag MUST be set to zero.
+
+ o Back Request (B): This flag MAY be set to one to request that the
+ End Point send a Measurement Request to the Start Point.
+
+ o Intermediate Reply (I): This flag MUST be set to zero.
+
+ o SeqNo: This is assigned by the Start Point so that it can uniquely
+ identify the Measurement Request and the corresponding
+ Measurement Reply.
+
+ o Num: This field MUST specify the number of address elements, each
+ (16 - Compr) octets in size, inside the Address vector.
+
+ o Index: This field MUST be set to zero to indicate the position in
+ the Address vector of the next hop on the route.
+
+ o Start Point Address: This field MUST be set to a unicast global or
+ unique-local IPv6 address of the Start Point after eliding Compr
+ number of prefix octets.
+
+ o End Point Address: This field MUST be set to a unicast global or
+ unique-local IPv6 address of the End Point after eliding Compr
+ number of prefix octets.
+
+ o Address vector:
+
+ * The Address vector MUST contain a complete Source Route from
+ the Start Point to the End Point (excluding the Start Point and
+ the End Point).
+
+ * Each address appearing in the Address vector MUST be a unicast
+ global or unique-local IPv6 address. Further, each address
+ MUST have the same prefix as the Start Point Address and the
+ End Point Address. This prefix, whose length in octets is
+ specified in the Compr field, MUST be elided from each address.
+
+ * The IPv6 addresses in the Address vector MUST be reachable in
+ the Forward direction.
+
+ * If the R flag is set to one, the IPv6 addresses in the Address
+ vector MUST also be reachable in the Reverse direction.
+
+
+
+
+
+
+Goyal, et al. Experimental [Page 18]
+
+RFC 6998 Measurement of Routing Metrics in LLNs August 2013
+
+
+5. Processing a Measurement Request at an Intermediate Point
+
+ A router (an Intermediate Point or the End Point) MAY discard a
+ received MO with no processing, in order to meet any policy-related
+ goals. Such policy goals may include the need to reduce the router's
+ CPU load, or to enhance its battery life, or to prevent the misuse of
+ this mechanism by unauthorized nodes.
+
+ A router MUST discard a received MO with no further processing if the
+ value in the Compr field inside the received message is more than
+ what the router considers to be 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 determine whether or not one of its IPv6 addresses
+ is listed as either the Start Point or the End Point Address. If
+ not, the router considers itself an Intermediate Point and MUST
+ process the received MO in the following manner.
+
+ An Intermediate Point MUST discard the packet with no further
+ processing if the received MO is not a Measurement Request (i.e.,
+ T = 0). This is because the End Point unicasts a Measurement Reply
+ directly to the Start Point. So, the Intermediate Point treats a
+ transiting Measurement Reply as a data packet and not a RPL control
+ message.
+
+ Next, the Intermediate Point determines the type of the route being
+ measured (by checking the values of the H flag and the RPLInstanceID
+ field) and processes the received MO accordingly, in the manner
+ specified next.
+
+5.1. When Measuring a Hop-by-Hop Route with a Global RPLInstanceID
+
+ If a Hop-by-hop Route with a global RPLInstanceID is being measured
+ (i.e., H = 1 and RPLInstanceID has a global value), the Intermediate
+ Point MUST process the received Measurement Request in the following
+ manner.
+
+ If the Num field inside the received Measurement Request is not set
+ to zero, thereby implying that an Address vector is present, the
+ Intermediate Point MUST discard the received message with no further
+ processing.
+
+ If the Intermediate Reply (I) flag is set to one in the received
+ Measurement Request and the Intermediate Point knows the values of
+ the routing metrics (as specified in the Metric Container options)
+ for the remainder of the route, it MAY generate a Measurement Reply
+ on the End Point's behalf in the manner specified in Section 6.1
+
+
+
+Goyal, et al. Experimental [Page 19]
+
+RFC 6998 Measurement of Routing Metrics in LLNs August 2013
+
+
+ (after including in the Measurement Reply the relevant routing metric
+ values for the complete route being measured). Otherwise, the
+ Intermediate Point MUST process the received message in the following
+ manner.
+
+ The Intermediate Point MUST determine the next hop on the route being
+ measured using the RPLInstanceID and the End Point Address. If the
+ Intermediate Point is the root of the non-storing global DAG along
+ which the received Measurement Request had been traveling so far, it
+ MUST process the received Measurement Request in the following
+ manner:
+
+ o If the router does not know how to reach the End Point, it MUST
+ discard the Measurement Request with no further processing and MAY
+ send an ICMPv6 Destination Unreachable (with Code 0 -- No Route To
+ Destination) error message [RFC4443] to the Start Point.
+
+ o Otherwise, unless the router determines the End Point itself to be
+ the next hop, the router MUST make the following changes in the
+ received Measurement Request:
+
+ * Set the H, A, R, and I flags to zero (the A and R flags should
+ already be zero in the received message).
+
+ * Leave the remaining fields unchanged (the Num field would be
+ modified in the next steps). Note that the RPLInstanceID field
+ identifies the non-storing global DAG along which the
+ Measurement Request traveled so far. This information MUST be
+ preserved so that the End Point may use this DAG to send the
+ Measurement Reply back to the Start Point.
+
+ * Insert a new Address vector inside the Measurement Request, and
+ specify a Source Route to the End Point inside the Address
+ vector as per the following rules:
+
+ + The Address vector MUST contain a complete route from the
+ router to the End Point (excluding the router and the
+ End Point).
+
+ + Each address appearing in the Address vector MUST be a
+ unicast global or unique-local IPv6 address. Further, each
+ address MUST have the same prefix as the Start Point Address
+ and the End Point Address. This prefix, whose length in
+ octets is specified in the Compr field, MUST be elided from
+ each address.
+
+ + The IPv6 addresses in the Address vector MUST be reachable
+ in the Forward direction.
+
+
+
+Goyal, et al. Experimental [Page 20]
+
+RFC 6998 Measurement of Routing Metrics in LLNs August 2013
+
+
+ If the router cannot insert an Address vector satisfying the
+ rules mentioned above, it MUST discard the Measurement Request
+ with no further processing and MAY send an ICMPv6 Destination
+ Unreachable (with Code 0 -- No Route To Destination) error
+ message [RFC4443] to the Start Point.
+
+ * Specify in the Num field the number of address elements in the
+ Address vector.
+
+ * Set the Index field to zero to indicate the position in the
+ Address vector of the next hop on the route. Thus, the
+ Address[0] element contains the address of the next hop on the
+ route.
+
+ The Intermediate Point MUST then complete the processing of the
+ received Measurement Request as specified in Section 5.5.
+
+5.2. When Measuring a Hop-by-Hop Route with a Local RPLInstanceID with
+ Route Accumulation Off
+
+ If a Hop-by-hop Route with a local RPLInstanceID is being measured
+ and the route accumulation is off (i.e., H = 1, RPLInstanceID has a
+ local value, and A = 0), the Intermediate Point MUST process the
+ received Measurement Request in the following manner.
+
+ If the Num field inside the received Measurement Request is not set
+ to zero, thereby implying that an Address vector is present, the
+ Intermediate Point MUST discard the received message with no further
+ processing.
+
+ The Intermediate Point MUST then determine the next hop on the route
+ being measured using the RPLInstanceID, the End Point Address, and
+ the Start Point Address (which represents the DODAGID of the route
+ being measured). If the Intermediate Point cannot determine the next
+ hop, it MUST discard the Measurement Request with no further
+ processing and MAY send an ICMPv6 Destination Unreachable (with
+ Code 0 -- No Route To Destination) error message [RFC4443] to the
+ Start Point. Otherwise, the Intermediate Point MUST complete the
+ processing of the received Measurement Request as specified in
+ Section 5.5.
+
+5.3. When Measuring a Hop-by-Hop Route with a Local RPLInstanceID with
+ Route Accumulation On
+
+ If a Hop-by-hop Route with a local RPLInstanceID is being measured
+ and the route accumulation is on (i.e., H = 1, RPLInstanceID has a
+ local value, and A = 1), the Intermediate Point MUST process the
+ received Measurement Request in the following manner.
+
+
+
+Goyal, et al. Experimental [Page 21]
+
+RFC 6998 Measurement of Routing Metrics in LLNs August 2013
+
+
+ If the Num field inside the received Measurement Request is set to
+ zero, thereby implying that an Address vector is not present, the
+ Intermediate Point MUST discard the received message with no further
+ processing.
+
+ The Intermediate Point MUST then determine the next hop on the route
+ being measured using the RPLInstanceID, the End Point Address, and
+ the Start Point Address (which represents the DODAGID of the route
+ being measured). If the Intermediate Point cannot determine the next
+ hop, it MUST discard the Measurement Request with no further
+ processing and MAY send an ICMPv6 Destination Unreachable (with
+ Code 0 -- No Route To Destination) error message [RFC4443] to the
+ Start Point. If the index field has value Num - 1 and the next hop
+ is not the same as the End Point, the Intermediate Point MUST drop
+ the received Measurement Request with no further processing. In this
+ case, the next hop would have no space left in the Address vector to
+ store its address. Otherwise, the router MUST store one of its IPv6
+ addresses at location Address[Index] and then increment the Index
+ field. The IPv6 address added to the Address vector MUST have the
+ following properties:
+
+ o This address MUST be a unicast global or unique-local address.
+
+ o This address MUST have the same prefix as the Start Point Address
+ and the End Point Address. This prefix, whose length in octets is
+ specified in the Compr field, MUST be elided before the address is
+ added to the Address vector.
+
+ o This address MUST be reachable in the Reverse direction.
+
+ If the router does not have an IPv6 address that satisfies the
+ properties mentioned above, it MUST discard the Measurement Request
+ with no further processing.
+
+ The Intermediate Point MUST then complete the processing of the
+ received Measurement Request as specified in Section 5.5.
+
+5.4. When Measuring a Source Route
+
+ If a Source Route is being measured (i.e., H = 0), the Intermediate
+ Point MUST process the received Measurement Request in the following
+ manner.
+
+ If the Num field inside the received Measurement Request is set to
+ zero, thereby implying that an Address vector is not present, the
+ Intermediate Point MUST discard the received message with no further
+ processing.
+
+
+
+
+Goyal, et al. Experimental [Page 22]
+
+RFC 6998 Measurement of Routing Metrics in LLNs August 2013
+
+
+ The Intermediate Point MUST verify that the Address[Index] element
+ lists one of its unicast global or unique-local IPv6 addresses (minus
+ the prefix whose length in octets is specified in the Compr field),
+ failing which it MUST discard the Measurement Request with no further
+ processing. The Intermediate Point MUST then increment the Index
+ field and use the Address[Index] element as the next hop (unless the
+ Index value is now Num). If the Index value is now Num, the
+ Intermediate Point MUST use the End Point Address as the next hop.
+
+ The Intermediate Point MUST then complete the processing of the
+ received Measurement Request as specified in Section 5.5.
+
+5.5. Final Processing
+
+ The Intermediate Point MUST drop the received Measurement Request
+ with no further processing:
+
+ o if the next-hop address is not a unicast address; or
+
+ o if the next hop is not on-link; or
+
+ o if the next hop is not in the same RPL routing domain as the
+ Intermediate Point.
+
+ Next, the Intermediate Point MUST update the routing metric objects,
+ inside the Metric Container option(s) inside the Measurement Request,
+ either by updating the aggregated value for the routing metric or by
+ attaching the local values for the metric inside the object. An
+ Intermediate Point can only update the existing metric objects and
+ MUST NOT add any new routing metric objects to the Metric Container.
+ An Intermediate Point MUST drop the Measurement Request with no
+ further processing if it cannot update a routing metric object
+ specified inside the Metric Container.
+
+ Finally, the Intermediate Point MUST unicast the Measurement Request
+ to the next hop.
+
+6. Processing a Measurement Request at the End Point
+
+ On receiving an MO, if a router chooses to process the message
+ further and finds one of its unicast global or unique-local IPv6
+ addresses (minus the prefix whose length in octets is specified in
+ the Compr field) listed as the End Point Address, the router
+ considers itself the End Point and MUST process the received MO in
+ the following manner.
+
+ The End Point MUST discard the received message with no further
+ processing if it is not a Measurement Request (i.e., T = 0).
+
+
+
+Goyal, et al. Experimental [Page 23]
+
+RFC 6998 Measurement of Routing Metrics in LLNs August 2013
+
+
+ If the received Measurement Request traveled on a Hop-by-hop Route
+ with a local RPLInstanceID with route accumulation on (i.e., H = 1,
+ RPLInstanceID has a local value, and A = 1), elements Address[0]
+ through Address[Index - 1] in the Address vector contain a complete
+ Source Route from the Start Point to the End Point, which the
+ End Point MAY use, after reversal, to reach the Start Point. Note
+ that the Source Route in the Address vector does not include the
+ Start Point and the End Point addresses, and that the individual
+ addresses do not include the common prefix whose length in octets is
+ specified in the Compr field.
+
+ If the received Measurement Request traveled on a Source Route and
+ the Reverse flag is set to one (i.e., H = 0 and R = 1), elements
+ Address[0] through Address[Num - 1] in the Address vector contain a
+ complete Source Route from the Start Point to the End Point, which
+ the End Point MAY use, after reversal, to reach the Start Point.
+ Again, the Source Route in the Address vector does not include the
+ Start Point and the End Point addresses, and the individual addresses
+ do not include the common prefix whose length in octets is specified
+ in the Compr field.
+
+ The End Point MUST update the routing metric objects in the Metric
+ Container options if required and MAY note the measured values for
+ the complete route (especially if the received Measurement Request is
+ likely a response to an earlier Measurement Request that the
+ End Point had sent to the Start Point with the B flag set to one).
+
+ The End Point MUST generate a Measurement Reply message as specified
+ in Section 6.1. If the B flag is set to one in the received
+ Measurement Request, the End Point SHOULD generate a new Measurement
+ Request to measure the cost of its current (or the most preferred)
+ route to the Start Point. The routing metrics used in the new
+ Measurement Request MUST include the routing metrics specified in the
+ received Measurement Request.
+
+6.1. Generating the Measurement Reply
+
+ A Measurement Reply MUST have the Type (T) flag set to zero and need
+ not contain the Address vector. The following fields inside a
+ Measurement Reply MUST have the same values as they had inside the
+ corresponding Measurement Request: RPLInstanceID, Compr, SeqNo,
+ Start Point Address, End Point Address, and Metric Container
+ option(s). The remaining fields inside a Measurement Reply may have
+ any value and MUST be ignored on reception at the Start Point; the
+ received Measurement Request can, therefore, trivially be converted
+ into a Measurement Reply by setting the Type (T) flag to zero.
+
+
+
+
+
+Goyal, et al. Experimental [Page 24]
+
+RFC 6998 Measurement of Routing Metrics in LLNs August 2013
+
+
+ A Measurement Reply MUST be unicast back to the Start Point:
+
+ o If the Measurement Request traveled along a global DAG, identified
+ by the RPLInstanceID field, the Measurement Reply MAY be unicast
+ back to the Start Point along the same DAG.
+
+ o If the Measurement Request traveled along a Hop-by-hop Route with
+ a local RPLInstanceID and accumulated a Source Route from the
+ Start Point to the End Point, this Source Route MAY be used after
+ reversal to send the Measurement Reply back to the Start Point.
+
+ o If the Measurement Request traveled along a Source Route and the
+ R flag inside the received message is set to one, the End Point
+ MAY reverse the Source Route contained in the Address vector and
+ use it to send the Measurement Reply back to the Start Point.
+
+7. Processing a Measurement Reply at the Start Point
+
+ When a router receives an MO, it examines the MO to see if one of its
+ unicast IPv6 addresses is listed as the Start Point Address. If yes,
+ the router is the Start Point and MUST process the received message
+ in the following manner.
+
+ If the Start Point discovers that the received MO is not a
+ Measurement Reply, or if it no longer maintains state for the
+ corresponding Measurement Request, it MUST discard the received
+ message with no further processing.
+
+ The Start Point can use the routing metric objects inside the Metric
+ Container to evaluate the metrics for the measured P2P route. If a
+ routing metric object contains local metric values recorded by
+ routers on the route, the Start Point can make use of these local
+ values by aggregating them into an end-to-end metric, according to
+ the aggregation rules for the specific metric. A Start Point is then
+ free to interpret the metrics for the route, according to its local
+ policy.
+
+8. Security Considerations
+
+ In general, the security considerations for the route measurement
+ mechanism described in this document are similar to those for RPL (as
+ described in Section 19 of the RPL specification [RFC6550]).
+ Sections 6.1 and 10 of [RFC6550] describe RPL's security framework,
+ which provides data confidentiality, authentication, replay
+ protection, and delay protection services. This security framework
+ is applicable to the route measurement mechanism described here as
+ well, after taking into account the constraints specified in
+ Section 3.2.
+
+
+
+Goyal, et al. Experimental [Page 25]
+
+RFC 6998 Measurement of Routing Metrics in LLNs August 2013
+
+
+ This document requires that all routers participating in a secure
+ invocation of the route measurement process use the Security
+ Configuration chosen by the Start Point. The intention is to avoid
+ compromising the overall security of the route measurement due to
+ some routers using a weaker Security Configuration. A router is
+ allowed to participate in a "secure" route measurement only if it can
+ support the Security Configuration in use, which also specifies the
+ key in use. It does not matter whether the key is preinstalled or
+ dynamically acquired after proper authentication. The router must
+ have the key in use before it can process or generate Secure MO
+ messages. Hence, from the perspective of the route measurement
+ mechanism, there is no distinction between the "preinstalled" and
+ "authenticated" security modes described in the RPL specification
+ [RFC6550]. Of course, if a compromised router has the key being
+ used, it could cause the route measurement to fail, or worse, insert
+ wrong information in Secure MO messages.
+
+ A rogue router acting as the Start Point could use the route
+ measurement mechanism defined in this document to measure routes from
+ itself to other routers and thus find out key information about the
+ LLN, e.g., the topological features of the LLN (such as the identity
+ of the key routers in the topology) or the remaining energy levels
+ [RFC6551] in the routers. This information can potentially be used
+ to attack the LLN. A rogue router could also use this mechanism to
+ send bogus Measurement Requests to arbitrary End Points. If
+ sufficient Measurement Requests are sent, then it may cause CPU
+ 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.
+
+ To protect against such misuse, this document allows RPL routers
+ implementing this mechanism to not process MO messages (or process
+ such messages selectively), based on a local policy. For example, an
+ LLN deployment might require the use of Secure MO messages generated
+ using a key that could be obtained only after proper authentication.
+ Note that this document requires that an LLN deployment support
+ Secure MO messages so that such policies can be enforced where
+ considered essential.
+
+ 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 headers [RFC5095] may be valid here.
+ To address such concerns, the mechanism described in this document
+ includes several remedies, in the form of the following requirements:
+
+ o A route inserted inside the Address vector must be a strict Source
+ Route and must not include any multicast addresses.
+
+
+
+Goyal, et al. Experimental [Page 26]
+
+RFC 6998 Measurement of Routing Metrics in LLNs August 2013
+
+
+ o An MO message must not cross the boundaries of the RPL routing
+ domain where it originated. A router must not forward a received
+ MO message further if the next hop belongs to a different RPL
+ routing domain. Hence, any security problems associated with the
+ mechanism would be limited to one RPL routing domain.
+
+ o A router must drop a received Measurement Request if the next-hop
+ address is not on-link or if it is not a unicast address.
+
+9. IANA Considerations
+
+ This document defines two new RPL messages:
+
+ o "Measurement Object" (see Section 3.1), assigned a value of 0x06
+ from the "RPL Control Codes" space [RFC6550].
+
+ o "Secure Measurement Object" (see Section 3.2), assigned a value of
+ 0x86 from the "RPL Control Codes" space [RFC6550].
+
+ +------+---------------------------+---------------+
+ | Code | Description | Reference |
+ +------+---------------------------+---------------+
+ | 0x06 | Measurement Object | This document |
+ | 0x86 | Secure Measurement Object | This document |
+ +------+---------------------------+---------------+
+
+ RPL Control Codes
+
+10. Acknowledgements
+
+ The authors gratefully acknowledge the contributions of Ralph Droms,
+ Adrian Farrel, Joel Halpern, Matthias Philipp, Pascal Thubert,
+ Richard Kelsey, and Zach Shelby in the development of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Goyal, et al. Experimental [Page 27]
+
+RFC 6998 Measurement of Routing Metrics in LLNs August 2013
+
+
+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.
+
+ [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
+ Message Protocol (ICMPv6) for the Internet Protocol
+ Version 6 (IPv6) Specification", RFC 4443, March 2006.
+
+ [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
+ Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
+ Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
+ Lossy Networks", RFC 6550, March 2012.
+
+ [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
+ Routing Header for Source Routes with the Routing Protocol
+ for Low-Power and Lossy Networks (RPL)", RFC 6554,
+ March 2012.
+
+ [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
+ J. Martocci, "Reactive Discovery of Point-to-Point Routes
+ in Low-Power and Lossy Networks", RFC 6997, August 2013.
+
+11.2. Informative References
+
+ [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
+ of Type 0 Routing Headers in IPv6", RFC 5095,
+ December 2007.
+
+ [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
+ Routing Requirements in Low-Power and Lossy Networks",
+ RFC 5826, April 2010.
+
+ [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
+ "Building Automation Routing Requirements in Low-Power and
+ Lossy Networks", RFC 5867, June 2010.
+
+ [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D.
+ Barthel, "Routing Metrics Used for Path Calculation in
+ Low-Power and Lossy Networks", RFC 6551, March 2012.
+
+ [ROLL-TERMS]
+ Vasseur, JP., "Terminology in Low power And Lossy
+ Networks", Work in Progress, March 2013.
+
+
+
+
+
+Goyal, et al. Experimental [Page 28]
+
+RFC 6998 Measurement of Routing Metrics in LLNs August 2013
+
+
+Authors' Addresses
+
+ Mukul Goyal (editor)
+ University of Wisconsin Milwaukee
+ 3200 N. Cramer St.
+ Milwaukee, WI 53201
+ USA
+
+ Phone: +1-414-229-5001
+ EMail: mukul@uwm.edu
+
+
+ Emmanuel Baccelli
+ INRIA
+
+ Phone: +33-169-335-511
+ EMail: Emmanuel.Baccelli@inria.fr
+ URI: http://www.emmanuelbaccelli.org/
+
+
+ Anders Brandt
+ Sigma Designs
+ Emdrupvej 26A, 1.
+ Copenhagen, Dk-2100
+ Denmark
+
+ Phone: +45-29609501
+ EMail: abr@sdesigns.dk
+
+
+ Jerald Martocci
+ Johnson Controls
+ 507 E. Michigan Street
+ Milwaukee, WI 53202
+ USA
+
+ Phone: +1-414-524-4010
+ EMail: jerald.p.martocci@jci.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Goyal, et al. Experimental [Page 29]
+