doc: Add RFC documents

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]
+