Skip to main content

A Mechanism to Measure the Quality of a Point-to-point Route in a Low Power and Lossy Network
draft-ietf-roll-p2p-measurement-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 6998.
Authors Mukul Goyal , Emmanuel Baccelli , Anders Brandt , Jerry Martocci
Last updated 2011-10-29 (Latest revision 2011-07-11)
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 6998 (Experimental)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-roll-p2p-measurement-02
Internet Engineering Task Force                            M. Goyal, Ed.
Internet-Draft                                   University of Wisconsin
Intended status: Experimental                                  Milwaukee
Expires: May 1, 2012                                         E. Baccelli
                                                                   INRIA
                                                               A. Brandt
                                                           Sigma Designs
                                                             J. Martocci
                                                        Johnson Controls
                                                        October 29, 2011

 A Mechanism to Measure the Quality of a Point-to-point Route in a Low
                        Power and Lossy Network
                   draft-ietf-roll-p2p-measurement-02

Abstract

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

Status of this Memo

   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 May 1, 2012.

Copyright Notice

   Copyright (c) 2011 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

Goyal, et al.              Expires May 1, 2012                  [Page 1]
Internet-Draft     draft-ietf-roll-p2p-measurement-02       October 2011

   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  The Measurement Object (MO)  . . . . . . . . . . . . . . . . .  4
     3.1.  Format of the base MO  . . . . . . . . . . . . . . . . . .  5
     3.2.  Secure MO  . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Originating a Measurement Request  . . . . . . . . . . . . . .  9
     4.1.  To Measure A Hop-by-hop Route with a Global
           RPLInstanceID  . . . . . . . . . . . . . . . . . . . . . .  9
     4.2.  To Measure A Hop-by-hop Route with a Local
           RPLInstanceID  . . . . . . . . . . . . . . . . . . . . . .  9
     4.3.  To Measure A Source Route  . . . . . . . . . . . . . . . . 11
   5.  Processing a Measurement Request at an Intermediate Router . . 12
     5.1.  Determining Next Hop For An MO Measuring A Source Route  . 13
     5.2.  Determining Next Hop For An MO Measuring A Hop-by-hop
           Route  . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   6.  Processing a Measurement Request at the Target . . . . . . . . 14
   7.  Processing a Measurement Reply at the Origin . . . . . . . . . 15
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     11.2. Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17

Goyal, et al.              Expires May 1, 2012                  [Page 2]
Internet-Draft     draft-ietf-roll-p2p-measurement-02       October 2011

1.  Introduction

   Point to point (P2P) communication between arbitrary routers in a Low
   power and Lossy Network (LLN) is a key requirement for many
   applications [RFC5826][RFC5867].  RPL [I-D.ietf-roll-rpl], the IPv6
   Routing Protocol for LLNs, constrains the LLN topology to a Directed
   Acyclic Graph (DAG) built to optimize routing costs to reach the
   DAG's root and requires the P2P routes to use the DAG links only.
   Such P2P routes may potentially be suboptimal and may lead to traffic
   congestion near the DAG root.  Additionally, RPL is a proactive
   routing protocol and hence all P2P routes must be established ahead
   of the time they are used.

   To ameliorate situations, where RPL's P2P routing functionality does
   not meet the requirements, [I-D.ietf-roll-p2p-rpl] describes a
   reactive mechanism to discover P2P routes that meet the specified
   performance criteria.  This mechanism, henceforth referred to as the
   reactive P2P route discovery, allows the specification of routing
   constraints [I-D.ietf-roll-routing-metrics], that the discovered
   routes must satisfy.  In some cases, the application requirements or
   the LLN's topological features allow a router to infer the routing
   constraints intrinsically.  For example, the application may require
   the end-to-end loss rate and/or latency on the route to be below
   certain thresholds or the LLN topology may be such that a router can
   safely assume its destination to be less than a certain number of
   hops away from itself.

   When the existing routes are deemed unsatisfactory but the router
   does not intrinsically know the routing constraints to be used in P2P
   route discovery, it may be necessary for the router to determine the
   aggregated values of the routing metrics along the existing route.
   This knowledge will allow the router to frame reasonable routing
   constraints for use in P2P route discovery to determine a better
   route.  For example, if the router determines the aggregate ETX
   [I-D.ietf-roll-routing-metrics] along an existing route to be "x", it
   can use "ETX < x*y", where y is a certain fraction, as the routing
   constraint for use in P2P route discovery.  Note that it is important
   that the routing constraints are not overly strict; otherwise the P2P
   route discovery may fail even though a route, much better than the
   one currently being used, exists.

   This document specifies a mechanism that enables an RPL router to
   measure the aggregated values of the routing metrics along an
   existing route to another RPL router in an LLN, thereby allowing the
   router to decide if it wants to initiate the reactive discovery of a
   more optimal route and determine the routing constraints to be used
   for this purpose.

Goyal, et al.              Expires May 1, 2012                  [Page 3]
Internet-Draft     draft-ietf-roll-p2p-measurement-02       October 2011

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

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

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

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

   Intermediate Router: A router, other than the origin and the target,
   on the P2P route being measured.

2.  Overview

   The mechanism described in this document can be used by an origin in
   an RPL domain to measure the aggregated values of the routing metrics
   along a P2P route to a target within the same RPL domain.  Such a
   route could be a source route or a hop-by-hop route established using
   RPL [I-D.ietf-roll-rpl] or the reactive P2P route discovery
   [I-D.ietf-roll-p2p-rpl].  The origin sends a Measurement Request
   message along the route.  The Measurement Request accumulates the
   values of the routing metrics as it travels towards the target.  Upon
   receiving the Measurement Request, the target unicasts a Measurement
   Reply message, carrying the accumulated values of the routing
   metrics, back to the origin.  Optionally, the origin may allow an
   intermediate route to generate the Measurement Reply if it already
   knows the relevant routing metric values along rest of the route.

3.  The Measurement Object (MO)

   This document defines two new RPL Control Message types, the
   Measurement Object (MO), with code 0x06 (to be confirmed by IANA),
   and the Secure MO, with code 0x86 (to be confirmed by IANA).  An MO
   serves as both Measurement Request and Measurement Reply.

Goyal, et al.              Expires May 1, 2012                  [Page 4]
Internet-Draft     draft-ietf-roll-p2p-measurement-02       October 2011

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 Address                          |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                       Target 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: Relevant only if the MO travels along a hop-by-hop
      route.  This field identifies the RPLInstanceID of the hop-by-hop
      route being measured.  If the route being measured is a source
      route, this field MUST be set to 10000000 on transmission and
      ignored on reception.

   o  Compr: In many LLN deployments, IPv6 addresses share a well known,
      common prefix.  In such cases, the common prefix can be elided
      when specifying IPv6 addresses in Origin/Target Address fields and
      the Address vector.  The "Compr" field is a 4-bit unsigned integer
      that indicates the number of prefix octets that are elided from
      the IPv6 addresses in Origin/Target Address fields and the Address
      vector.  The Compr value will be 0 if full IPv6 addresses are
      carried in the Origin/Target Address fields and the Address

Goyal, et al.              Expires May 1, 2012                  [Page 5]
Internet-Draft     draft-ietf-roll-p2p-measurement-02       October 2011

      vector.

   o  Type (T): This flag is set if the MO represents a Measurement
      Request.  The flag is cleared if the MO is a Measurement Reply.

   o  Hop-by-hop (H): This flag is set if the MO travels along a hop-by-
      hop route.  In that case, the hop-by-hop route is identified by
      the RPLInstanceID and, if the RPLInstanceID is a local value, the
      Origin Address serving as the DODAGID.  This flag is cleared if
      the MO travels along a source route specified in the Address
      vector.  Note that, in case the P2P route being measured lies
      along a non-storing DAG, an MO message may travel along a hop-by-
      hop route till it reaches the DAG's root, which then sends it
      along a source route to its destination.  In that case, the DAG
      root will reset the H flag and also insert the source route to the
      destination inside the Address vector.

   o  Accumulate Route (A): This flag is relevant only if the MO
      represents a Measurement Request that travels along a hop-by-hop
      route represented by a local RPLInstanceID.  In other words, this
      flag MAY be set only if T = 1, H = 1 and the RPLInstanceID field
      has a local value.  Otherwise, this flag MUST be cleared.  A value
      1 in this flag indicates that the Measurement Request MUST
      accumulate a source route for use by the target to send the
      Measurement Reply back to the origin.  In this case, the
      intermediate routers MUST add their IPv6 addresses (after eliding
      Compr number of prefix octets) to the Address vector in the manner
      specified later.

   o  Reverse (R): This flag is relevant only if the MO represents a
      Measurement Request that travels along a source route, specified
      in the Address vector, to the target.  In other words, this flag
      MAY be set only if T = 1 and H = 0.  Otherwise, this flag MUST be
      cleared.  A value 1 in the flag indicates that the Address vector
      contains a complete source route from the origin to the target,
      which can be used, after reversal, by the target to source route
      the Measurement Reply message back to the origin.

   o  Back Request (B): This flag serves as a request to the target to
      send a Measurement Request towards the origin.  The origin MAY set
      this flag if it wants to make such a request to the target.  On
      receiving this request, the target MAY generate a Measurement
      Request to measure the cost of its current (or the most preferred)
      route to the origin.  Receipt of this Measurement Request would
      allow the origin to know the cost of the back route from the
      target to itself and thus determine the round-trip cost of
      reaching the target.

Goyal, et al.              Expires May 1, 2012                  [Page 6]
Internet-Draft     draft-ietf-roll-p2p-measurement-02       October 2011

   o  Intermediate Reply (I): Relevant only if a hop-by-hop route is
      being measured, this flag serves as a permission to an
      intermediate router to generate a Measurement Reply if it knows
      the cost of the rest of the route being measured.  The origin MAY
      set this flag if a hop-by-hop route is being measured (i.e., H =
      1) and the origin wants to allow the intermediate routers to
      generate the Measurement Reply in response to this Measurement
      Request.  Setting this flag may be useful in scenarios where Hop
      Count [I-D.ietf-roll-routing-metrics] is the routing metric of
      interest and the origin expects an intermediate router (e.g. the
      root of a non-storing DAG or a common ancestor of the origin and
      the target in a storing DAG) to know the Hop Count of the
      remainder of the route to the target.  This flag MUST be cleared
      if the route being measured is a source route (i.e., H = 0).

   o  SequenceNo: A 6-bit sequence number, assigned by the origin, that
      allows the origin to uniquely identify a Measurement Request and
      the corresponding Measurement Reply.

   o  Num: This field indicates the number of fields in the Address
      vector.  If the value of this field is zero, the Address vector is
      not present in the MO.

   o  Index: If the Measurement Request is traveling along a source
      route contained in the Address vector (T=1,H=0), this field
      indicates the index in the Address vector of the next hop on the
      route.  If the Measurement Request is traveling along a hop-by-hop
      route with a local RPLInstanceID and the A flag is set
      (T=1,H=1,A=1 and RPLInstanceID field has a local value), this
      field indicates the index in the Address vector where an
      intermediate router receiving the MO message must store its IPv6
      address.  Otherwise, this field MUST be set to zero on
      transmission and ignored on reception.

   o  Origin Address: An IPv6 address of the origin after eliding Compr
      number of prefix octets.  If the MO is traveling along a hop-by-
      hop route and the RPLInstanceID field indicates a local value, the
      Origin Address field MUST contain the DODAGID value that, along
      with the RPLInstanceID, uniquely identifies within the RPL domain
      the hop-by-hop route being measured.

   o  Target Address: An IPv6 address of the target after eliding Compr
      number of prefix octets.

   o  Address[1..Num]: A vector of IPv6 addresses (with Compr number of
      prefix octets elided) representing a source route to the target:

Goyal, et al.              Expires May 1, 2012                  [Page 7]
Internet-Draft     draft-ietf-roll-p2p-measurement-02       October 2011

      *  Each element in the vector has size (16 - Compr) octets.

      *  The total number of elements inside the Address vector is given
         by the Num field.

      *  When the Measurement Request is traveling along a hop-by-hop
         route with local RPLInstanceID and has the A flag set, the
         Address vector is used to accumulate a source route to be used
         by the target to send the Measurement Reply back to the origin.
         In this case, the route MUST be accumulated in the forward
         direction, i.e., from the origin to the target.  The target
         router would reverse this route to obtain a source route from
         itself to the origin.  The IPv6 addresses in the accumulated
         route MUST be accessible in the backward direction.  An
         intermediate router adding its address to the Address vector
         MUST ensure that its address does not already exist in the
         vector.

      *  When the Measurement Request is traveling along a source route,
         the Address vector MUST contain a complete route to the target
         and the IPv6 addresses in the Address vector MUST be accessible
         in the forward direction, i.e., from the origin to the target.
         A router (origin or an intermediate router) inserting an
         Address vector inside an MO MUST ensure that no address appears
         more than once inside the vector.  Each router on the way MUST
         ensure that the loops do not exist within the source route.
         The origin may set the R flag in the MO if the route in the
         Address vector represents a complete route from the origin to
         the target and this route can be used after reversal by the
         target to send the Measurement Reply message back to the
         origin.

      *  The origin and target addresses MUST NOT be included in the
         Address vector.

      *  The Address vector MUST NOT contain any multicast addresses.

   o  Metric Container Options: An MO MUST contain one or more Metric
      Container options to accumulate routing metric values for the
      route being measured.

3.2.  Secure MO

   A Secure MO message follows the format in Figure 7 of
   [I-D.ietf-roll-rpl], where the base format is the base MO shown in
   Figure 1.

Goyal, et al.              Expires May 1, 2012                  [Page 8]
Internet-Draft     draft-ietf-roll-p2p-measurement-02       October 2011

4.  Originating a Measurement Request

   If an origin needs to measure the routing metric values along a P2P
   route towards a target, it generates an MO message and sets its
   fields in the manner described below.  Additionally, the origin MUST
   set the T flag to 1 to indicate that the MO represents a Measurement
   Request.  The origin MUST also include one or more Metric Container
   options inside the MO that carry the routing metric objects of
   interest.  If required, the origin must also initiate these routing
   metric objects by including the values of the routing metrics for the
   first hop on the P2P route being measured.

   After setting the MO fields as described below, the origin MUST
   unicast the MO message to the next hop on the P2P route.

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

   If a hop-by-hop route with a global RPLInstanceID is being measured,
   the MO message MUST NOT contain the Address vector and the following
   MO fields MUST be set in the manner specified below:

   o  Hop-by-hop (H): This flag MUST be set;

   o  Accumulate Route (A): This flag MUST be cleared;

   o  Reverse (R): This flag MUST be cleared;

   o  Back Request (B): This flag MAY be set if the origin wants to
      request the target to generate a Measurement Request back to
      itself;

   o  Intermediate Reply (I): This flag MAY be set if the origin wants
      to permit the intermediate routers to generate the Measurement
      Reply on the target's behalf;

   o  Num: This field MUST be set to zero;

   o  Index: This field MUST be set to zero.

4.2.  To Measure A Hop-by-hop Route with a Local RPLInstanceID

   If a hop-by-hop route with a local RPLInstanceID is being measured
   and the MO is not accumulating a source route for the target's use,
   the MO message MUST NOT contain the Address vector and the following
   MO fields MUST be set in the manner specified below:

   o  Hop-by-hop (H): This flag MUST be set;

Goyal, et al.              Expires May 1, 2012                  [Page 9]
Internet-Draft     draft-ietf-roll-p2p-measurement-02       October 2011

   o  Accumulate Route (A): This flag MUST be cleared;

   o  Reverse (R): This flag MUST be cleared;

   o  Back Request (B): This flag MAY be set if the origin wants to
      request the target to generate a Measurement Request back to
      itself;

   o  Intermediate Reply (I): This flag MAY be set if the origin wants
      to permit the intermediate routers to generate the Measurement
      Reply on the target's behalf;

   o  Num: This field MUST be set to zero;

   o  Index: This field MUST be set to zero;

   o  Origin Address: This field MUST contain the DODAGID value (after
      eliding Compr number of prefix octets) associated with the route
      being measured.

   If a hop-by-hop route with a local RPLInstanceID is being measured
   and the origin desires the MO to accumulate a source route for the
   target to send the Measurement Reply message back, it MUST set the
   following MO fields in the manner specified below:

   o  Hop-by-hop (H): This flag MUST be set;

   o  Accumulate Route (A): This flag MUST be set;

   o  Reverse (R): This flag MUST be cleared;

   o  Back Request (B): This flag MAY be set if the origin wants to
      request the target to generate a Measurement Request back to
      itself;

   o  Intermediate Reply (I): This flag MAY be set if the origin wants
      to permit the intermediate routers to generate the Measurement
      Reply on the target's behalf;

   o  Address vector: The Address vector must be large enough to
      accomodate a complete source route from the origin to the target.
      All the bits in the Address vector field MUST be set to zero;

   o  Num: This field MUST specify the number of address elements that
      can fit inside the Address vector;

   o  Index: This field MUST be set to 1;

Goyal, et al.              Expires May 1, 2012                 [Page 10]
Internet-Draft     draft-ietf-roll-p2p-measurement-02       October 2011

   o  Origin Address: This field MUST contain the DODAGID value (after
      eliding Compr number of prefix octets) associated with the route
      being measured.

4.3.  To Measure A Source Route

   If a source route is being measured, the origin MUST set the
   following MO fields in the manner specified below:

   o  RPLInstanceID: This field MUST be set to 10000000;

   o  Hop-by-hop (H): This flag MUST be cleared;

   o  Accumulate Route (A): This flag MUST be cleared;

   o  Reverse (R): This flag MUST be set if the source route in the
      Address vector can be reversed and used by the target to source
      route the Measurement Reply message back to the origin.
      Otherwise, this flag MUST be cleared;

   o  Back Request (B): This flag MAY be set if the origin wants to
      request the target to generate a Measurement Request back to
      itself;

   o  Intermediate Reply (I): This flag MUST be cleared.

   o  Address vector:

      *  The Address vector MUST contain a complete route from the
         origin to the target (excluding the origin and the target);

      *  The IPv6 addresses (with Compr prefix octets elided) in the
         Address vector MUST be accessible in the forward direction,
         i.e., from the origin to the target;

      *  To prevent loops in the source route, the origin MUST ensure
         that

         +  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 interfaces, such addresses MUST
            appear back to back inside the Address vector.

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

Goyal, et al.              Expires May 1, 2012                 [Page 11]
Internet-Draft     draft-ietf-roll-p2p-measurement-02       October 2011

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

   The origin MUST NOT send the packet further if the next hop address
   on the source route is not on-link.

5.  Processing a Measurement Request at an Intermediate Router

   A router MAY discard a received MO with no further processing to meet
   any policy-related goal.  Such policy goals may include the need to
   reduce the router's CPU load or to enhance its battery life.

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

   An intermediate router MUST discard the packet with no further
   processing if the received MO is not a Measurement Request.

   If the I flag is set in the received MO and the intermediate router
   knows the values of the routing metrics, specified in the Metric
   Container, for the remainder of the route, it MAY generate a
   Measurement Reply on the target's behalf in the manner specified in
   Section 6 (after including in the Measurement Reply the relevant
   routing metric values for the complete route being measured).
   Otherwise, the intermediate router MUST process the received MO in
   the following manner.

   The router MUST determine the next hop on the P2P route being
   measured in the manner described below.  The router MUST drop the MO
   with no further processing and MAY send an ICMPv6 Destination
   Unreachable (with Code 0 - No Route To Destination) error message to
   the source of the message if it can not determine the next hop for
   the message.

   After determining the next hop, the router MUST update the routing
   metric objects, contained in the Metric Container options inside the
   MO, either by updating the aggregated value for the routing metric or
   by attaching the local values for the metric inside the object.
   After updating the routing metrics, the router MUST unicast the MO to
   the next hop.

Goyal, et al.              Expires May 1, 2012                 [Page 12]
Internet-Draft     draft-ietf-roll-p2p-measurement-02       October 2011

5.1.  Determining Next Hop For An MO Measuring A Source Route

   In case the received MO is measuring a source route (H=0), the router
   MUST increment the Index field and use the Address[Index] element as
   the next hop.  If Index is greater than Num, the router MUST use the
   Target Address as the next hop.

   An intermediate router MUST discard the MO packet with no further
   processing if the next hop address is not on-link or is not a unicast
   address.  To prevent loops, an intermediate router MUST check if the
   Address vector includes multiple IPv6 addresses assigned to the
   router's interfaces and if such addresses do not appear back to back
   inside the Address vector.  In this case, the router MUST discard the
   MO packet with no further processing.  An MO message MUST NOT leave
   the RPL domain where it originated.  Hence, an intermediate router
   MUST discard an MO message traveling along a source route if the next
   hop on the way does not lie within the RPL domain.

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

   If the received MO is measuring a hop-by-hop route (H=1), the router
   MUST use the RPLInstanceID, the Target Address and, if RPLInstanceID
   is a local value, the DODAGID (same as the Origin Address) to
   determine the next hop for the MO.  Moreover,

   o  If the RPLInstanceID of the hop-by-hop route is a local value and
      the A flag is set, the router MUST check if the Address vector
      already contains one of its IPv6 addresses.  If yes, the router
      MUST discard the packet with no further processing.  Otherwise,
      the router MUST store one of its IPv6 addresses (after eliding
      Compr prefix octets) at location Address[Index] and then increment
      the Index field.

   o  If the router is the root of the non-storing DAG along which the
      received MO message has been traveling, the router MUST do the
      following:

      *  Reset the H, A and R flags.

      *  Insert a source route to the target inside the Address vector
         as per the following rules:

         +  The Address vector MUST contain a complete route from the
            router to the target (excluding the router and the target);

         +  The IPv6 addresses (with Compr prefix octets elided) in the
            Address vector MUST be accessible in the forward direction,
            i.e., towards the target;

Goyal, et al.              Expires May 1, 2012                 [Page 13]
Internet-Draft     draft-ietf-roll-p2p-measurement-02       October 2011

         +  To prevent loops in the source route, the router MUST ensure
            that

            -  Any IPv6 address MUST NOT appear more than once in the
               Address vector;

            -  If the Address vector includes multiple IPv6 addresses
               assigned to the router'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.

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

      *  Set the Index field to 1.

6.  Processing a Measurement Request at the Target

   On receiving an MO, if a router chooses to process the packet further
   and finds one of its IPv6 addresses listed as the Target Address, it
   MUST process the received MO in the following manner.

   The target MUST discard the packet with no further processing if the
   received MO is not a Measurement Request.

   The target MUST update the routing metric objects in the Metric
   Container options if required and MAY note the measured values for
   the complete route if desired.

   The target MUST generate a Measurement Reply message.  The received
   Measurement Request message can be trivially converted into the
   Measurement Reply by reseting the T flag to zero.  The target MAY
   remove the Address vector from the Measurement Reply if desired.  The
   target MUST then unicast the Measurement Reply back to the origin:

   o  If the Measurement Request traveled along a DAG with a global
      RPLInstanceID, the Measurement Reply MAY be unicast back to the
      origin along the same DAG.

   o  If the Measurement Request traveled along a hop-by-hop route with
      a local RPLInstanceID and the A flag inside the received message
      is set, the target MAY reverse the source route contained in the
      Address vector and use it to send the Measurement Reply back to
      the origin.

Goyal, et al.              Expires May 1, 2012                 [Page 14]
Internet-Draft     draft-ietf-roll-p2p-measurement-02       October 2011

   o  If the Measurement Request traveled along a source route and the R
      flag inside the received message is set, the target MAY reverse
      the source route contained in the Address vector and use it to
      send the Measurement Reply back to the origin.

   If the B flag is set in the received Measurement Request, the target
   MAY generate a new Measurement Request to measure the cost of its
   current (or the most preferred) route to the origin.  The routing
   metrics used in the new Measurement Request MUST include the routing
   metrics specified in the received Measurement Request.

7.  Processing a Measurement Reply at the Origin

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

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

   The origin SHOULD examine the routing metric objects inside the
   Metric Container options to evaluate the quality of the measured P2P
   route.  If a routing metric object contains local metric values
   recorded by routers on the route, the origin MAY aggregate these
   local values into an end-to-end value as per the aggregation rules
   for the metric.

8.  Security Considerations

   The mechanism defined in this document can potentially be used by a
   compromised router to generate bogus measurement requests to
   arbitrary target routers.  Such bogus measurement requests may cause
   processing overload in the routers in the network, drain their
   batteries and cause traffic congestion in the network.  Note that
   some of these problems would occur even if the compromised router
   were to generate bogus data traffic to arbitrary destinations.

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

Goyal, et al.              Expires May 1, 2012                 [Page 15]
Internet-Draft     draft-ietf-roll-p2p-measurement-02       October 2011

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

   o  This document requires that an MO message must not cross the
      boundaries of the RPL domain where it is originated.  Hence, any
      security problems associated with the mechanism would be limited
      to the RPL domain where the MO message is generated.

   o  A router must drop a received MO message if the next hop address
      is not on-link or if it is not a unicast address.

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

9.  IANA Considerations

   IANA is requested to allocate a new code point in the "RPL Control
   Codes" registry for the "Measurement Object" described in this
   document.

           +------+---------------------------+---------------+
           | Code |        Description        |   Reference   |
           +------+---------------------------+---------------+
           | 0x06 |     Measurement Object    | This document |
           | 0x86 | Secure Measurement Object | This document |
           +------+---------------------------+---------------+

                             RPL Control Codes

10.  Acknowledgements

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

11.  References

Goyal, et al.              Expires May 1, 2012                 [Page 16]
Internet-Draft     draft-ietf-roll-p2p-measurement-02       October 2011

11.1.  Normative References

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

11.2.  Informative References

   [I-D.ietf-roll-p2p-rpl]
              Goyal, M., Baccelli, E., Philipp, M., Brandt, A., Cragie,
              R., and J. Martocci, "Reactive Discovery of Point-to-Point
              Routes in Low Power and Lossy Networks",
              draft-ietf-roll-p2p-rpl-04 (work in progress), July 2011.

   [I-D.ietf-roll-routing-metrics]
              Vasseur, J., Kim, M., Pister, K., Dejean, N., and D.
              Barthel, "Routing Metrics used for Path Calculation in Low
              Power and Lossy Networks",
              draft-ietf-roll-routing-metrics-19 (work in progress),
              March 2011.

   [I-D.ietf-roll-rpl]
              Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
              Vasseur, "RPL: IPv6 Routing Protocol for Low power and
              Lossy Networks", draft-ietf-roll-rpl-19 (work in
              progress), March 2011.

   [I-D.ietf-roll-terminology]
              Vasseur, J., "Terminology in Low power And Lossy
              Networks", draft-ietf-roll-terminology-06 (work in
              progress), September 2011.

   [RFC5095]  Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
              of Type 0 Routing Headers in IPv6", RFC 5095,
              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.

Goyal, et al.              Expires May 1, 2012                 [Page 17]
Internet-Draft     draft-ietf-roll-p2p-measurement-02       October 2011

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

Goyal, et al.              Expires May 1, 2012                 [Page 18]