Internet Engineering Task Force                            M. Goyal, Ed.
Internet-Draft                                   University of Wisconsin
Intended status: Experimental                                  Milwaukee
Expires: March 21, June 27, 2013                                       E. Baccelli
                                                                   INRIA
                                                               A. Brandt
                                                           Sigma Designs
                                                             J. Martocci
                                                        Johnson Controls
                                                      September 17,
                                                       December 24, 2012

A Mechanism to Measure the Quality of Routing Metrics along a Point-to-point Route
                    in a Low Power and Lossy Network
                   draft-ietf-roll-p2p-measurement-06
                   draft-ietf-roll-p2p-measurement-07

Abstract

   This document specifies a mechanism that enables an RPL router to
   measure the quality aggregated values of given routing metrics along an
   existing route towards another RPL router in a low power and lossy
   network, thereby allowing the router to decide if it wants to
   initiate the discovery of a better route.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 21, June 27, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  The Measurement Object (MO)  . . . . . . . . . . . . . . . . .  5
     3.1.  Format of the base MO  . . . . . . . . . . . . . . . . . .  5  6
     3.2.  Secure MO  . . . . . . . . . . . . . . . . . . . . . . . .  9 10
   4.  Originating a Measurement Request  . . . . . . . . . . . . . .  9 10
     4.1.  To Measure  When Measuring A Hop-by-hop Route with a Global
           RPLInstanceID  . . . . . . . . . . . . . . . . . . . . . . 10 11
     4.2.  To Measure  When Measuring A Hop-by-hop Route with a Local
           RPLInstanceID With Route Accumulation Off  . . . . . . . . 12
     4.3.  When Measuring A Hop-by-hop Route with a Local
           RPLInstanceID With Route Accumulation On . . . . . . . . . . . . . . 10
     4.3.  To Measure 13
     4.4.  When Measuring A Source Route  . . . . . . . . . . . . . . . . 11 14
   5.  Processing a Measurement Request at an Intermediate Router Point  . . 12 15
     5.1.  Determining Next Hop For An MO  When Measuring A Source Hop-by-hop Route with a Global
           RPLInstanceID  . 14 . . . . . . . . . . . . . . . . . . . . . 16
     5.2.  Determining Next Hop For An MO  When Measuring A Hop-by-hop Route with a Local
           RPLInstanceID With Route Accumulation Off  . . . . . . . . 17
     5.3.  When Measuring A Hop-by-hop Route with a Local
           RPLInstanceID With Route Accumulation On . . . . . . . . . 18
     5.4.  When Measuring A Source Route  . . . . . . . . . . . . . 14 . 19
     5.5.  Final Processing . . . . . . . . . . . . . . . . . . . . . 19
   6.  Processing a Measurement Request at the Target End Point  . . . . . . 20
     6.1.  Generating the Measurement Reply . . . . 15 . . . . . . . . . 20
   7.  Processing a Measurement Reply at the Origin . . . Start Point  . . . . . . 16 21
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16 21
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17 23
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 23
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 23
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 23
     11.2. Informative References . . . . . . . . . . . . . . . . . . 18 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 24

1.  Introduction

   Point to point (P2P) communication between arbitrary routers in a Low
   power and Lossy Network (LLN) is a key requirement for many
   applications [RFC5826][RFC5867].  RPL [RFC6550], the  The IPv6 Routing Protocol for LLNs, 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 all P2P
      routes to be established ahead of the time they are used.  Many
      LLN applications require the ability to establish P2P routes "on
      demand".

   To ameliorate situations, where the core RPL's P2P routing
   functionality does not meet the application requirements,
   [I-D.ietf-roll-p2p-rpl] describes P2P-RPL, an extension to core RPL.
   P2P-RPL provides a reactive mechanism to discover P2P routes that
   meet the specified routing constraints [RFC6551].  In some cases, the
   application requirements or the LLN's topological features allow a
   router to infer these routing constraints implicitly.  For example,
   the application may require the end-to-end loss rate and/or latency
   along the route to be below certain thresholds or the LLN topology
   may be such that a router can safely assume its destination to be
   less than a certain number of hops away from itself.

   When the existing routes are deemed unsatisfactory but the router
   does not 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 [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
   are not overly strict; otherwise the P2P-RPL route discovery may fail
   even though a route, much better than the one currently being used,
   exists.

   This document specifies a mechanism that enables an RPL router to
   measure the aggregated values of the routing metrics along an
   existing route to another RPL router in an LLN, thereby allowing the
   router to decide if it wants to 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, which is targeting publication as an Experimental RFC.  It
   makes sense, therefore, for this document also to target publication
   as an Experimental RFC.  As more operational experience is gained
   using P2P-RPL, it is hoped that the mechanism described in this
   document will also be used, and feedback will be provided to the ROLL
   working group on the utility and benefits of this document.

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

   This document uses terminology from [RFC6550] and
   [I-D.ietf-roll-p2p-rpl].  The following terms, originally defined in
   [I-D.ietf-roll-p2p-rpl], are redefined in  Additionally, this document defines the
   following manner.

   Origin: terms.

   Start Point: The Origin Start Point refers to the RPL router that initiates
   the measurement process defined in this document and is the start
   point of the P2P route being measured.

   Target:

   End Point: The Target End Point refers to the RPL router at the end point of
   the P2P route being measured.

   Intermediate Router: Point: An RPL router, other than the Origin Start Point and the
   Target,
   End Point, on the P2P route being measured.

   The following terms, already defined in [I-D.ietf-roll-p2p-rpl], have
   been redefined in this document in the following manner.

   Forward direction: The direction from the Start Point to the End
   Point.

   Backward direction: The direction from the End Point to the Start
   Point.

2.  Overview

   The mechanism described in this document can be used by an Origin a Start Point
   in an LLN to measure the aggregated values of some selected routing
   metrics along a P2P route to a Target an End Point within the LLN.  The route
   is measured in the
   direction from the Origin to the Target. Forward direction.  Such a route could be a
   source route Source
   Route [I-D.ietf-roll-p2p-rpl] or a hop-by-hop route Hop-by-hop Route

   [I-D.ietf-roll-p2p-rpl] established using RPL [RFC6550] or P2P-RPL
   [I-D.ietf-roll-p2p-rpl].  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 Origin Start Point decides what
   metrics to measure and sends a Measurement Request message, carrying
   the desired routing metric objects, along the route.  On receiving a
   Measurement Request, an Intermediate Router 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 Target. End
   Point.  The Measurement Request may also accumulate a Source Route
   that the End Point may use to reach the Start Point.  Upon receiving
   the Measurement Request, the Target End Point unicasts a Measurement Reply
   message, carrying the accumulated values of the routing metrics, back
   to the Origin. Start Point.  Optionally, the Origin Start Point may allow an
   Intermediate Router Point to generate the Measurement Reply if it the
   Intermediate Point already knows the relevant routing metric values
   along rest of the route.

3.  The Measurement Object (MO)

   This document defines two new RPL Control Message types, the
   Measurement Object (MO), with code TBD1, and the Secure MO, with code
   TBD2.  An MO serves as both Measurement Request and Measurement
   Reply.

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| SequenceNo|  Num  | Index |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                       Origin                       Start Point Address                     |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                       Target                       End Point Address                       |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                       Address[1..Num]                         .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                   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 is relevant only if a hop-by-hop route
      is being measured, i.e., the H flag, described subsequently, is
      set to one.  In this case, the Origin MUST set this field to the
      RPLInstanceID of the hop-by-hop route being measured.  If a source
      route is being measured, the Origin MUST set this field to binary
      value 10000000.  An Intermediate Router MUST set specifies the RPLInstanceID
      field in the outgoing MO packet to the same value that it had in
      the corresponding incoming MO packet unless it is the root of a
      non-storing global DAG, identified by the RPLInstanceID, Hop-
      by-hop Route along which the MO packet had been traveling so far and the router
      intends to insert a source route inside the Address vector to
      direct Measurement Request travels (or
      traveled initially until it towards the Target.  In that case, the router MUST set
      the RPLInstanceID field in the outgoing MO packet switched over to binary value
      10000000. 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 Origin/Target Start Point/End Point
      Address fields and the Address vector.  The "Compr" field, a 4-bit
      unsigned integer, is set by the Origin Start Point to specify the number
      of prefix octets that are elided from the IPv6 addresses in Origin/Target Start
      Point/End Point Address fields and the Address vector.  An Intermediate Router
      MUST set the Compr field in the outgoing MO packet to the same
      value that it had in the corresponding incoming MO packet.  The
      Intermediate Router MUST drop the received MO message if the Compr
      value specified in the message does not match what the router
      considers the length of the common prefix to be.  The Origin will  The Start
      Point will set the Compr value to zero if full IPv6 addresses are
      to be carried in the Origin Address/Target Start Point Address/End Point Address fields
      and the Address vector.

   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 Origin Start Point MUST set this flag to one if (at
      least the initial part of) the route being measured is a hop-by-hop route. hop-by-hop.
      In that case, the hop-by-
      hop route Hop-by-hop Route is identified by the RPLInstanceID
      RPLInstanceID, the End Point Address and, if the RPLInstanceID is
      a local value, the Origin Address and Target Start Point Address (required to be same as the
      DODAGID of the route being measured) fields inside the message. Measurement
      Request.  The Origin Start Point MUST set this flag to zero if the route
      being measured is a source route Source Route specified in the Address vector.
      An Intermediate Router Point MUST set the H flag in an outgoing MO packet
      Measurement Request to the same value that it had in the
      corresponding incoming MO packet Measurement Request unless the router it is the root
      of the non-storing global DAG, identified by the RPLInstanceID,
      along which the MO packet Measurement Request had been traveling so far and
      the router Intermediate Point intends to insert a source route Source Route inside the
      Address vector to direct it towards the Target. End Point.  In that case,
      the router Intermediate Point MUST reset set the H flag to zero in the outgoing MO packet. zero.

   o  Accumulate Route (A): This flag is relevant only if the MO
      represents a Measurement Request that travels along a hop-by-hop
      route represented by a local RPLInstanceID.  In other words, this
      flag MAY be set to one only if T = 1, H = 1 and the RPLInstanceID
      field has a local value.  Otherwise, this flag MUST be set to
      zero. A value 1 in this flag indicates that the
      Measurement Request MUST accumulate is accumulating a source route Source Route for use by the Target
      End Point to send the Measurement Reply back to the Origin. Start Point.
      Route accumulation is allowed (i.e., this flag MAY be set to one)
      inside a Measurement Request only if it travels along a Hop-by-hop
      Route represented by a local RPLInstanceID (i.e., H = 1,
      RPLInstanceID has a local value).  In this case, an Intermediate Router MUST add
      Point adds its unicast IPv6 address (after eliding Compr number of
      prefix octets) to the Address vector in the manner specified later. 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 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 Source
         Route to the Target; End Point; and

      *  The Target End Point can presumably reach the Origin Start Point along this
         global
         DAG. DAG (identified by the RPLInstanceID field).

   o  Reverse (R): This flag is relevant only if the MO represents a
      Measurement Request that travels along a source route, specified
      in the Address vector, to the Target.  In other words, this flag
      MAY be set to one only if T = 1 and H = 0.  Otherwise, this flag
      MUST be set to zero. A value 1 in the this flag inside a Measurement Request
      indicates that the Address vector contains a complete source route Source Route
      from the Origin Start Point to the Target, End Point, which can be used, after
      reversal, by the Target End Point to
      source route send the Measurement Reply message back to
      the Origin. 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): This A value 1 in this flag serves as a request to
      the Target End Point to send a Measurement Request towards the Origin.  The Origin MAY set
      this flag to one to make such a request to the Target.  An
      Intermediate Router MUST set the B flag in an outgoing MO packet
      to the same value that it had in the corresponding incoming MO
      packet. Start
      Point.  On receiving a Measurement Request with the B flag set to
      one, the Target End Point SHOULD generate a Measurement Request to
      measure the cost of its current (or the most preferred) route to
      the
      Origin. Start Point.  Receipt of this Measurement Request would allow
      the
      Origin Start Point to know the cost of the back route from the Target End
      Point to itself and thus determine the round-trip cost of reaching
      the
      Target. End Point.

   o  Intermediate Reply (I): Relevant only if a hop-by-hop route is
      being measured, A value 1 in this flag serves as a
      permission to an Intermediate Router Point to generate a Measurement
      Reply if it knows the cost of the rest aggregated values of the route being measured.  The Origin MAY
      set this flag to one if a hop-by-hop route is routing metrics
      being measured
      (i.e., H = 1) and for the Origin wants to allow an Intermediate Router
      to generate rest of the Measurement Reply in response to this Measurement
      Request. route.  Setting this flag to
      one may be useful in scenarios where the Hop Count [RFC6551] is
      the routing metric of interest and the Origin expects an Intermediate Router Point (e.g. the
      root of a non-storing global DAG or a common ancestor of the Origin Start
      Point and the Target End Point in a storing global DAG) to may know the Hop
      Count of the remainder of the route to the Target. End Point.  This flag MUST
      MAY be set to zero one only if the route a Hop-by-hop Route with a global
      RPLInstanceID is being measured is a source route (i.e., H = 0). 1, RPLInstanceID has a
      global value).  Otherwise, this flag MUST be set to zero on
      transmission and ignored on reception.

   o  SequenceNo: A 6-bit sequence number, assigned by the Origin, Start Point,
      that allows the Origin Start Point to uniquely identify a Measurement
      Request and the corresponding Measurement Reply.  An Intermediate Router MUST
      set this field in the outgoing MO packet to the same value that it
      had in the corresponding incoming MO packet.  The Target MUST set
      this field in a Measurement Reply message to the same value that
      it had in the corresponding Measurement Request message.

   o  Num: This field indicates the number of 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 Source
      Route contained in the Address vector (T=1,H=0), (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 Hop-by-hop
      Route with a local RPLInstanceID and the A flag Route Accumulation is set
      (T=1,H=1,A=1 and on
      (i.e., H = 1, RPLInstanceID field has a local value), value, A = 1), this field
      indicates the index in the Address vector where an Intermediate Router
      Point receiving the MO message Measurement Request must store its IPv6
      address.  Otherwise, this field MUST be set to zero on
      transmission and ignored on reception.

   o  Origin  Start Point Address: A unicast IPv6 address of the Origin Start Point
      after eliding Compr number of prefix octets.  If the MO Measurement
      Request is traveling along a
      hop-by-hop route Hop-by-hop Route and the
      RPLInstanceID field indicates a local value, the Origin Start Point
      Address field MUST specify the DODAGID value that, along with the
      RPLInstanceID and the Target End Point Address, uniquely identifies the hop-by-hop route
      Hop-by-hop Route being measured.

   o  Target  End Point Address: A unicast IPv6 address of the Target End Point after
      eliding Compr number of prefix octets.

   o  Address[1..Num]:  Address[0..Num-1]: A vector of unicast IPv6 addresses (with Compr
      number of prefix octets elided) representing a source route to the
      Target: 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.

      *  When the Measurement Request is traveling along a hop-by-hop
         route Hop-by-hop
         Route with local RPLInstanceID and has the A flag set, set to one
         (i.e., H = 1, RPLInstanceID has a local value, A = 1), the
         Address vector is used to accumulate a source route to Source Route that can be
         used by the Target End Point, after reversal, to send the Measurement
         Reply back to the Origin.
         In this case, the Start Point.  The route MUST be accumulated
         in the forward
         direction, i.e., from the Origin to the Target.  The Target
         router would reverse this route to obtain a source route from
         itself to Forward direction but the Origin.  The IPv6 addresses in the
         accumulated route MUST be reachable in the backward direction, i.e., from
         the Target to the Origin. Backward direction.
         An Intermediate Router Point adding its address to the Address vector
         MUST ensure that its address a routing loop involving this router does not already
         exist in the vector. accumulated route.

      *  When the Measurement Request is traveling along a source route, Source Route
         (i.e., H = 0), the Address vector MUST contain a complete route
         to the Target End Point and the IPv6 addresses in the Address vector
         MUST be reachable in the forward direction, i.e., from the Origin to the Target. Forward direction.  A router (Origin (the
         Start Point or an Intermediate Router) Point) inserting an Address
         vector inside an MO a Measurement Request MUST ensure that no address
         appears more than once inside the vector.  Each router on the
         way MUST ensure that the loops do a routing loop involving this router does
         not exist within the source route. Source Route.  The Origin Start Point MAY set the
         R flag in the MO Measurement Request if the route in the Address
         vector represents a complete route from the Origin Start Point to the Target
         End Point and this route can be used after reversal by the
         Target End Point, after
         reversal, to send the Measurement Reply message back to the Origin
         Start Point (i.e., the IPv6 addresses in the Address vector are
         reachable in the backward direction - from the Target to the Origin). Backward direction).

      *  The Origin Start Point and Target End Point addresses MUST NOT be included in
         the Address vector.

      *  The Address vector MUST NOT contain any multicast addresses.

   o  Metric Container Options: An MO A Measurement Request MUST contain one
      or more Metric Container options [RFC6550] to accumulate the routing metric
      values of the selected routing metrics in the manner described in
      [RFC6551] for the route being measured.

3.2.  Secure MO

   A Secure MO message follows the format

   Section 4 describes how does a Start Point set various fields inside
   a Measurement Request in Figure 7 of different cases.  Section 5 describes how
   does an Intermediate Point process a received Measurement Request
   before forwarding it further.  Section 6 describes how does the End
   Point process a received Measurement Request and generate a
   Measurement Reply.  Finally, Section 7 describes how does the Start
   Point process a received Measurement Reply.

3.2.  Secure MO

   A Secure MO follows the format in Figure 7 of [RFC6550], where the
   base format is the base MO shown in Figure 1.

4.  Originating a Measurement Request

   If an Origin needs to measure

   A Start Point sets various fields inside the routing metric values along a P2P
   route towards a Target, Measurement Request it
   generates an MO message and sets its
   fields as described in Section 3.1.  The setting of MO fields in
   specific cases is the manner described below.  In all cases, the Origin MUST set
   the T flag to one to indicate that the MO represents a Measurement
   Request.  The Origin Start Point MUST also
   include the routing metric objects [RFC6551] of interest inside one
   or more Metric Container options inside the MO.
   Depending on the metrics being measured, the Origin must also
   initiate these routing metric objects by including the values of the
   routing metrics for the first hop on the P2P route being measured.

   After setting the MO fields appropriately, the Origin Measurement Request.  The
   Start Point then determines the next hop on the P2P route being measured.
   If a hop-by-hop Hop-by-hop route is being measured (i.e., the H flag is set to one), = 1), the next hop
   is determined using the RPLInstanceID, the Target End Point Address and, if
   RPLInstanceID is a local value, the Origin Start Point Address fields in the MO.
   Measurement Request.  If a source route Source Route is being measured (i.e., the H flag is set to
   zero), =
   0), the Address[1] Address[0] element inside the Measurement Request contains
   the next hop address.  The Origin Start Point MUST discard the MO message Measurement
   Request if:

   o  the next hop address is not a unicast address; or

   o  the next hop is not on-link; or

   o  the next hop is not in the same RPL routing domain as the Origin. Start
      Point.

   Otherwise, 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 Origin Start Point MUST unicast the MO message
   Measurement Request to the next hop on the P2P route. route being measured.

4.1.  To Measure  When Measuring A Hop-by-hop Route with a Global RPLInstanceID

   If a hop-by-hop route Hop-by-hop Route with a global RPLInstanceID is being measured, measured
   (i.e., H = 1, RPLInstanceID has a global value), the MO message MUST NOT
   contain the an Address vector and the following various MO fields MUST be set in the manner specified below:
   following manner:

   o  RPLInstanceID: MUST be set to the RPLInstanceID of the route being
      measured.

   o  Compr: 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): 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.

   o  Back Request (B): This flag MAY be set to one to request the End
      Point to 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  SequenceNo: 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: MUST be set to a unicast IPv6 address of the
      Start Point after eliding Compr number of prefix octets.

   o  End Point Address: MUST be set to a unicast IPv6 address of the
      End Point after eliding Compr number of prefix octets.

4.2.  To Measure  When Measuring A Hop-by-hop Route with a Local RPLInstanceID With
      Route Accumulation Off

   If a hop-by-hop route Hop-by-hop Route with a local RPLInstanceID is being measured
   and the MO is Start Point does not accumulating want the MO to accumulate a source route Source Route
   for the Target's End Point's use, the MO message MUST NOT contain the Address vector
   and the following various MO fields MUST be set in the manner specified below: following manner:

   o  RPLInstanceID: MUST be set to the RPLInstanceID of the route being
      measured.

   o  Compr: 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): 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.

   o  Num:  Back Request (B): This field flag MAY be set to one to request the End
      Point to send a Measurement Request to the Start Point.

   o  Intermediate Reply (I): This flag MUST be set to zero.

   o  SequenceNo: 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  Origin  Start Point Address: This field MUST contain the DODAGID value
      (after eliding Compr number of prefix octets) associated with the
      route being measured.

   o  End Point Address: MUST be set to a unicast 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 Hop-by-hop Route with a local RPLInstanceID is being measured
   and the Origin Start Point desires the MO to accumulate a source route Source Route for
   the
   Target End Point to send the Measurement Reply message back, it the MO MUST
   contain an Address vector and various MO fields MUST be set in the
   following MO fields manner:

   o  RPLInstanceID: MUST be set to the RPLInstanceID of the route being
      measured.

   o  Compr: 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 manner specified below: Address vector.

   o  Type (T): 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.

   o  Intermediate Reply (I):  Back Request (B): This flag MUST MAY be set to zero.

   o  Address vector: The Address vector must be large enough one to
      accomodate a complete source route from request the Origin End
      Point to send a Measurement Request to the Target.
      All the bits in the Address vector field Start Point.

   o  Intermediate Reply (I): This flag MUST be set to zero.

   o  SequenceNo: 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 elements, each
      (16 - Compr) octets in size, that can fit inside the Address
      vector.

   o  Index: This field MUST be set to one.

   o  Origin Address: This field MUST contain zero to indicate the DODAGID value (after
      eliding Compr number of 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.

4.3.  To Measure

   o  End Point Address: MUST be set to a unicast IPv6 address of the
      End Point after eliding Compr number of prefix octets.

   o  Address vector: The Address vector must be large enough to
      accomodate 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 Source Route is being measured, the Origin Start Point MUST set the
   following various
   MO fields in the manner specified below: following manner:

   o  RPLInstanceID: MUST be set to the binary value 10000000.

   o  Compr: 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): 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.

   o  Reverse (R): This flag SHOULD be set to one if the source route Source Route in
      the Address vector can be reversed and used by the Target End Point to
      source route
      send the Measurement Reply message back to the Origin. Start Point.
      Otherwise, this flag MUST be set to zero.

   o  Back Request (B): This flag MAY be set to one to request the End
      Point to send a Measurement Request to the Start Point.

   o  Intermediate Reply (I): This flag MUST be set to zero.

   o  Address vector:

      *  The Address vector MUST contain a complete route from the
         Origin to  SequenceNo: Assigned by the Target (excluding Start Point so that it can uniquely
      identify the Origin Measurement Request and the Target).

      *  The IPv6 addresses (with Compr prefix corresponding Measurement
      Reply.

   o  Num: This field MUST specify the number of address elements, each
      (16 - Compr) octets elided) in size, inside the Address vector vector.

   o  Index: This field MUST be reachable set to zero to indicate the position in
      the forward direction,
         i.e., from Address vector of the Origin to next hop on the Target.

      * route.

   o  Start Point Address: MUST be set to a unicast IPv6 address of the
      Start Point after eliding Compr number of prefix octets.

   o  End Point Address: MUST be set to a unicast 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).

      *  The IPv6 addresses (with Compr prefix octets elided) in the
         Address vector MUST be reachable in the Forward direction.

      *  If the R flag is set to one, the IPv6 addresses (with Compr
         prefix octets elided) in the Address vector MUST also be
         reachable in the backward direction, i.e., from the Target to
         the Origin. Backward direction.

      *  To prevent avoid loops in the source route, Source Route, the Origin Start Point MUST ensure
         compliance to the following rules:

         +  Any IPv6 address MUST NOT appear more than once in the
            Address vector.

         +  If the Address vector includes multiple IPv6 addresses
            assigned to the Origin's Start Point's interfaces, such addresses
            MUST appear back to back inside the Address vector.

      *  Each address appearing in the Address vector MUST be a unicast
         address.

   o  Num: This field MUST be set to indicate the number of elements in
      the Address vector.

   o  Index: This field MUST be set to one.

5.  Processing a Measurement Request at an Intermediate Router Point

   A router (an Intermediate Router Point or the Target) End Point) MAY discard a
   received MO with no processing to meet any policy-related goal.  Such
   policy goals may include the need to reduce the router's CPU load or
   to enhance its battery life. life or to prevent 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 not same as more than
   what the router considers the length of the common prefix used in
   IPv6 addresses in the LLN to be.

   On receiving an MO, if a router chooses to process the packet
   further, it MUST check if one of its IPv6 addresses is listed as
   either the Origin Start Point or the Target End Point Address.  If neither, the
   router considers itself an Intermediate Router Point and MUST process the
   received MO in the following manner.

   An Intermediate Router Point MUST discard the packet with no further
   processing if the received MO is not a Measurement Request.

   If the H and I flags are set to one in the received MO and Request (i.e., T =
   0).

   Next, the Intermediate Router knows Point determines the values type of the routing metrics,
   specified in the Metric Container, for route being
   measured (by checking the remainder values of the route, it
   MAY generate a Measurement Reply on H flag and the Target's behalf RPLInstanceID
   field) and processes the received MO accordingly in the manner
   specified in Section 6 (after including in the Measurement Reply the
   relevant routing metric values for the complete route 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).  Otherwise, measured
   (i.e.  H = 1 and RPLInstanceID has a global value), the Intermediate Router
   Point MUST process the received MO Measurement Request in the following
   manner.

   The router Intermediate Point MUST determine discard the next received Measurement Request
   with no further processing if the Num field is not set to zero or if
   the Address vector is present in the received message.

   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, 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 (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 then determine the next hop on the P2P 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 manner described below.
   following manner:

   o  The router MUST drop discard the MO Measurement Request with no further
      processing and MAY send an ICMPv6 Destination Unreachable (with
      Code 0 - No Route To Destination) error message to the source of the message Start Point
      if it can does not determine the next hop for
   the message.  The router MUST drop know how to reach the MO with no further processing: End Point.

   o  If  Otherwise, unless the next hop address is not a unicast address; or

   o  If router determines the next hop is not on-link; or

   o  If End Point itself to be
      the next hop is not in the same RPL routing domain as the
      router.

   Next, hop, the router MUST update make the routing metric objects, contained following changes in the Metric Container option(s) inside the MO, either by updating the
   aggregated value for
      received Measurement Request:

      *  Set the routing metric or by attaching H, A, R and I flags to zero (the A and R flags should
         already be zero in the local
   values for received message).

      *  Leave remaining fields unchanged (the Num field would be
         modified in next steps).  Note that the metric inside RPLInstanceID field
         identifies the object.  An Intermediate Router can
   only update non-storing global DAG along which the existing metric objects and
         Measurement Request traveled so far.  This information MUST NOT add any new
   routing metric object be
         preserved so that the End Point may use this DAG to send the Metric Container.  An Intermediate
   Router MUST drop
         Measurement Reply back to the MO if it cannot update Start Point.

      *  Insert a routing metric object
   specified new Address vector inside the Metric Container.

   After updating the routing metrics, the router MUST unicast the MO to
   the next hop.

5.1.  Determining Next Hop For An MO Measuring A Measurement Request and
         specify a Source Route

   In case to the received MO is measuring End Point inside the Address
         vector as per the following rules:

         +  The Address vector MUST contain a source complete route (H=0),

   o  The from the
            router MUST verify that to the Address[Index] element lists one
      of its unicast IPv6 addresses, failing which End Point (excluding the router MUST
      discard and the MO packet with no further processing;

   o End
            Point);

         +  The router MUST then increment IPv6 addresses (with Compr prefix octets elided) in the Index field and use
            Address vector MUST be reachable in the
      Address[Index] element as Forward direction;

         +  To avoid loops in the next hop.  If Index is greater than
      Num, Source Route, the router MUST use the Target Address as the next hop.

   To prevent loops, an Intermediate Router ensure
            that

            -  Any IPv6 address MUST discard NOT appear more than once in the MO packet
   with no further processing if
               Address vector;

            -  If the Address vector includes multiple IPv6 addresses
               assigned to the router's interfaces and if interfaces, such addresses do not MUST
               appear back to back inside the Address vector.

5.2.  Determining Next Hop For An MO Measuring A Hop-by-hop Route

   If

         +  Each address appearing in the received MO is measuring Address vector MUST be a hop-by-hop route (H=1),
            unicast address.

      *  Specify in the router
   MUST use Num field the RPLInstanceID, number of address elements in the Target
         Address and, if RPLInstanceID
   is a local value, vector.

      *  Set the Origin Address Index field to determine zero to indicate the position in the
         Address vector of the next hop for on the MO.  Moreover,

   o  If route.  Thus, Address[0]
         element contains the RPLInstanceID address of the hop-by-hop route is a local value and
      the A flag is set, next hop on the router route.

   The Intermediate Point MUST check if then complete the Address vector
      already contains one processing of its IPv6 addresses.  If yes, the router
      MUST discard the packet
   received Measurement Request as specified in Section 5.5.

5.2.  When Measuring A Hop-by-hop Route with no further processing.  Otherwise,
      the router MUST store one of its IPv6 addresses (after eliding
      Compr prefix octets) at location Address[Index] and then increment
      the Index field.

   o a Local RPLInstanceID With
      Route Accumulation Off

   If the router a Hop-by-hop Route with a local RPLInstanceID is being measured
   and the root of route accumulation is off (i.e., H = 1, RPLInstanceID has a
   local value, A = 0), the non-storing global DAG along
      which Intermediate Point MUST process the received MO message had been traveling so far,

      *
   Measurement Request in the following manner.

   The router discards Intermediate Point MUST discard the MO packet received Measurement Request
   with no further processing if
         it does not know of a source route to reach the Target
         (specified by Num field is not zero or if the Target
   Address listed vector is present in the packet).

      *  Otherwise, the router received message.

   The Intermediate Point MUST do then determine the following:

         +  Set 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).  The Intermediate Point 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 to
   the Start Point if it can not determine the next hop.  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 in on (i.e., H = 1, RPLInstanceID has a
   local value, A = 1), the Intermediate Point MUST process the received
   Measurement Request in the following manner.

   The Intermediate Point MUST discard the received Measurement Request
   with no further processing if the Num field is set to zero or if the
   Address vector is not present in the received message.

   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).  The Intermediate Point 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 to
   the Start Point if it can not determine the next hop.  The
   Intermediate Point MUST drop the received Measurement Request with no
   further processing if the index field has value Num - 1 and the next
   hop is not same as the End Point.  In this case, the next hop would
   have no space left in the Address vector to store its address.

   Otherwise, the Intermediate Point MUST check if adding one of its
   IPv6 addresses to the the Address vector would create a routing loop
   in the accumulated route.  If yes, the router MUST discard the packet
   with no further processing.  Otherwise, the router MUST store one of
   its unicast IPv6 addresses (after eliding Compr prefix octets) at
   location Address[Index] and then increment the Index field.  The IPv6
   address added to the Address vector MUST be reachable in the Backward
   direction.

   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.

   The Intermediate Point MUST discard the received Measurement Request
   with no further processing if the Num field is set to zero or if the
   Address vector is not present in the received message.

   The Intermediate Point MUST then determine the next hop on the H, A and R flags to zero and route
   being measured in the manner described below.  The Intermediate Point
   MUST verify that the Address[Index] element lists one of its unicast
   IPv6 addresses, failing which it MUST discard the Measurement Request
   with no further processing.  To prevent loops, the Intermediate Point
   MUST discard the Measurement Request with no further processing if
   the RPLInstanceID field
            to binary value 10000000.

         +  Remove any existing Address vector includes multiple IPv6 addresses assigned to its
   interfaces and if such addresses do not appear back to back inside
   the MO.

         +  Insert a new Address vector inside vector.  The Intermediate Point MUST then increment the MO
   Index field and specify a
            source route to use the Target inside Address[Index] element as the next hop
   (unless Index value is now Num).  If the Index value is now Num, the
   Intermediate Point MUST use the End Point Address vector as per the following rules:

            - next hop.

   The Address vector Intermediate Point MUST contain a then complete route from the
               router to processing of the Target (excluding
   received Measurement Request as specified in Section 5.5.

5.5.  Final Processing

   The Intermediate Point MUST drop the router and received Measurement Request
   with no further processing:

   o  If the
               Target);

            -  The IPv6 addresses (with Compr prefix octets elided) 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 Address vector same RPL routing domain as the
      Intermediate Point.

   Next, the Intermediate Point MUST be reachable in 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 forward
               direction, i.e., towards local values for the Target;

            -  To prevent loops in metric inside the source route, object.  An
   Intermediate Point can only update the router MUST
               ensure that

               o  Any IPv6 address existing metric objects and
   MUST NOT appear more than once in the
                  Address vector;

               o  If the Address vector includes multiple IPv6 addresses
                  assigned add any new routing metric object to the router's interfaces, such addresses Metric Container.
   An Intermediate Point MUST appear back to back drop the Measurement Request with no
   further processing if it cannot update a routing metric object
   specified inside the Address vector.

            -  Each address appearing in Metric Container.

   Finally, the Address vector Intermediate Point MUST be a unicast address.

         +  Specify in the Num field the number of address elements in
            the Address vector.

         +  Set the Index field Measurement Request
   to one. the next hop.

6.  Processing a Measurement Request at the Target End Point

   On receiving an MO, if a router chooses to process the packet message
   further and finds one of its unicast IPv6 addresses listed as the Target
   Address, 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).

   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 (excluding the
   Start Point and the End Point), which the End Point MAY use, after
   reversal, to reach the Start Point.

   If the received Measurement Request traveled on a Source Route and
   the Reverse flag is set to one (i.e., H = 0, R = 1), elements
   Address[0] through Address[Num - 1] in the Address vector contain a
   complete Source Route from the router considers itself Start Point to the Target and MUST process End Point
   (excluding the
   received MO in Start Point and the following manner.

   The Target MUST discard End Point), which the packet with no further processing if End Point
   MAY use, after reversal, to reach the
   received MO is not a Measurement Request. Start Point.

   The Target 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
   Target End
   Point had sent to the Origin Start Point with B flag set to one).

   The Target End Point MUST generate a Measurement Reply message. 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 message MUST have the same SequenceNo field values as they had inside the
   received
   corresponding Measurement Request message. Request: RPLInstanceID, Compr, SequenceNo,
   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 message can be MAY trivially be converted into the a
   Measurement Reply by setting the T Type (T) flag to zero.  The Target MAY remove the Address
   vector from the

   A Measurement Reply if desired.  The Target MUST then be unicast the Measurement Reply back to the Origin: Start Point:

   o  If the Measurement Request traveled along a global DAG (i.e., one
      with a global RPLInstanceID), DAG, identified
      by the RPLInstanceID field, the Measurement Reply MAY be unicast
      back to the Origin Start Point along the same DAG.

   o  If the Measurement Request traveled along a hop-by-hop route Hop-by-hop Route with
      a local RPLInstanceID and accumulated a Source Route from the A flag inside the received message
      is set
      Start Point to one, the Target End Point, this Source Route MAY reverse the source route contained
      in the Address vector and use it be used after
      reversal to send the Measurement Reply back to the Origin. Start Point.

   o  If the Measurement Request traveled along a source route Source Route and the R
      flag inside the received message is set to one, the Target End Point MAY
      reverse the source route Source Route contained in the Address vector and use
      it to send the Measurement Reply back to the Origin.

   If the B flag in the received Measurement Request is set to one, the
   Target SHOULD generate a new Measurement Request to measure the cost
   of its current (or the most preferred) route to the Origin.  The
   routing metrics used in the new Measurement Request MUST include the
   routing metrics specified in the received Measurement Request. Start Point.

7.  Processing a Measurement Reply at the Origin Start Point

   When a router receives an MO, it examines if one of its unicast IPv6
   addresses is listed as the Origin Start Point Address.  If yes, the router
   is the
   Origin Start Point and MUST process the received message in the
   following manner.

   The Origin Start Point MUST discard the packet with no further processing if
   the received MO is not a Measurement Reply or if the Origin Start Point has
   no recollection of sending a Measurement Request with the sequence
   number listed in the received MO. corresponding Measurement Request.

   The Origin MUST examine Start Point can use the routing metric objects inside the Metric
   Container options to evaluate the quality of metrics for the measured P2P route.  If a
   routing metric object contains local metric values recorded by
   routers on the route, the Origin MUST aggregate Start Point can make use of these local
   values by aggregating them into an end-to-end value as per 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

   The mechanism defined in this document can potentially be used by a
   compromised router to generate send bogus Measurement Requests to arbitrary Target routers.
   End Points.  Such Measurement Requests 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.

   Since a Measurement Request can travel along a source route Source Route specified
   in the Address vector, some of the security concerns that led to the
   deprecation of Type 0 routing header [RFC5095] may be valid here.  To
   address such concerns, the mechanism described in this document
   includes several remedies:

   o  This document requires that a route inserted inside the Address
      vector must be a strict source route Source Route and must not include any
      multicast addresses.

   o  This document requires that an MO message must not cross the
      boundaries of the RPL 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  This document requires that a router must drop a received MO
      message if the next hop address is not on-link or if it is not a
      unicast address.

   o  This document requires that a router must check the source route Source Route
      inside the Address vector of each received MO message to ensure
      that it does not contain a loop involving the router.  The router
      must drop the received packet if the source route Source Route does contain
      such a loop.  This and the previous two rules protect the network
      against some of the security concerns even if a compromised node
      inserts a malformed Address vector inside the MO message.

   The measurement mechanism described in this document may potentially
   be used by a rogue node to find out key information about the LLN,
   e.g., the topological features of the LLN (such as the identity of
   the key nodes in the topology) or the remaining energy levels
   [RFC6551] in the LLN routers.  This information can potentially be
   used to attack the LLN.  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.  Further, an LLN deployment may use Secure MO
   Section 3.2 messages to invoke RPL-provided security mechanisms and
   prevent misuse of the measurement mechanism by unauthorized nodes.

9.  IANA Considerations

   This document defines two new RPL messages:

   o  "Measurement Object" (see Section 3.1), assigned a value TBD1 from
      the "RPL Control Codes" space [to be removed upon publication:
      http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
      [RFC6550].  IANA is requested to allocate TBD1 from the range
      0x00-0x7F to indicate a message without security enabled.  The
      string TBD1 in this document should be replaced by the allocated
      value.  These last two sentences should be removed before
      publication.

   o  "Secure Measurement Object" (see Section 3.2), assigned a value
      TBD2 from the "RPL Control Codes" space [to be removed upon
      publication:
      http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
      [RFC6550].  IANA is requested to allocate TBD2 from the range
      0x80-0xFF to indicate a message with security enabled.  The string
      TBD2 in this document should be replaced by the allocated value.
      These last two sentences should be removed before publication.

           +------+---------------------------+---------------+
           | Code |        Description        |   Reference   |
           +------+---------------------------+---------------+
           | TBD1 |     Measurement Object    | This document |
           | TBD2 | Secure Measurement Object | This document |
           +------+---------------------------+---------------+

                             RPL Control Codes

10.  Acknowledgements

   Authors gratefully acknowledge the contributions of Matthias Philipp,
   Pascal Thubert, Richard Kelsey and Zach Shelby in the development of
   this document.

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

11.2.  Informative References

   [I-D.ietf-roll-p2p-rpl]
              Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J.
              Martocci, "Reactive Discovery of Point-to-Point Routes in
              Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-13 draft-ietf-roll-p2p-rpl-15
              (work in progress), June December 2012.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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.

   [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.

   [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.

Authors' Addresses

   Mukul Goyal (editor)
   University of Wisconsin Milwaukee
   3200 N Cramer St
   Milwaukee, WI  53211
   USA

   Phone: +1 414 2295001
   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  53202
   USA

   Phone: +1 414 524 4010
   Email: jerald.p.martocci@jci.com