[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-goyal-roll-p2p-measurement) 00 01 02 03 04 05 06 07 08 09 10 RFC 6998

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


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

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 March 21, 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



Goyal, et al.            Expires March 21, 2013                 [Page 1]

Internet-Draft     draft-ietf-roll-p2p-measurement-06     September 2012


   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
     3.2.  Secure MO  . . . . . . . . . . . . . . . . . . . . . . . .  9
   4.  Originating a Measurement Request  . . . . . . . . . . . . . .  9
     4.1.  To Measure A Hop-by-hop Route with a Global
           RPLInstanceID  . . . . . . . . . . . . . . . . . . . . . . 10
     4.2.  To Measure A Hop-by-hop Route with a Local
           RPLInstanceID  . . . . . . . . . . . . . . . . . . . . . . 10
     4.3.  To Measure A Source Route  . . . . . . . . . . . . . . . . 11
   5.  Processing a Measurement Request at an Intermediate Router . . 12
     5.1.  Determining Next Hop For An MO Measuring A Source Route  . 14
     5.2.  Determining Next Hop For An MO Measuring A Hop-by-hop
           Route  . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   6.  Processing a Measurement Request at the Target . . . . . . . . 15
   7.  Processing a Measurement Reply at the Origin . . . . . . . . . 16
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
     11.2. Informative References . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
















Goyal, et al.            Expires March 21, 2013                 [Page 2]

Internet-Draft     draft-ietf-roll-p2p-measurement-06     September 2012


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 IPv6 Routing
   Protocol for LLNs, 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



Goyal, et al.            Expires March 21, 2013                 [Page 3]

Internet-Draft     draft-ietf-roll-p2p-measurement-06     September 2012


   router to decide if it wants to discover a better route using P2P-RPL
   and determine the routing constraints to be used for this purpose.

1.1.  Terminology

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

   Additionally, this document uses terminology from [RFC6550] 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 RPL router that initiates the
   measurement process defined in this document and is the start point
   of the P2P route being measured.

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

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


2.  Overview

   The mechanism described in this document can be used by an Origin in
   an LLN to measure the aggregated values of some routing metrics along
   a P2P route to a Target within the LLN.  The route is measured in the
   direction from the Origin to the Target.  Such a route could be a
   source route or a hop-by-hop route established using RPL [RFC6550] or
   P2P-RPL [I-D.ietf-roll-p2p-rpl].  The Origin 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 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.
   Upon receiving the Measurement Request, the Target unicasts a
   Measurement Reply message, carrying the accumulated values of the
   routing metrics, back to the Origin.  Optionally, the Origin may
   allow an Intermediate Router to generate the Measurement Reply if it
   already knows the relevant routing metric values along rest of the
   route.






Goyal, et al.            Expires March 21, 2013                 [Page 4]

Internet-Draft     draft-ietf-roll-p2p-measurement-06     September 2012


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 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: 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 the RPLInstanceID
      field in the outgoing MO packet to the same value that it had in



Goyal, et al.            Expires March 21, 2013                 [Page 5]

Internet-Draft     draft-ietf-roll-p2p-measurement-06     September 2012


      the corresponding incoming MO packet unless it is the root of a
      non-storing global DAG, identified by the RPLInstanceID, 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 it towards the Target.  In that case, the router MUST set
      the RPLInstanceID field in the outgoing MO packet to binary value
      10000000.

   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 Address fields
      and the Address vector.  The "Compr" field, a 4-bit unsigned
      integer, is set by the Origin to specify the number of prefix
      octets that are elided from the IPv6 addresses in Origin/Target
      Address fields and the Address vector.  An Intermediate Router
      MUST set the Compr field in the outgoing MO packet to the same
      value that it had in the corresponding incoming MO packet.  The
      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
      set the Compr value to zero if full IPv6 addresses are to be
      carried in the Origin Address/Target 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 MUST set this flag to one if the route
      being measured is a hop-by-hop route.  In that case, the hop-by-
      hop route is identified by the RPLInstanceID and, if the
      RPLInstanceID is a local value, the Origin Address and Target
      Address fields inside the message.  The Origin MUST set this flag
      to zero if the route being measured is a source route specified in
      the Address vector.  An Intermediate Router MUST set the H flag in
      an outgoing MO packet to the same value that it had in the
      corresponding incoming MO packet unless the router is the root of
      the non-storing global DAG, identified by the RPLInstanceID, along
      which the MO packet had been traveling so far and the router
      intends to insert a source route inside the Address vector to
      direct it towards the Target.  In that case, the router MUST reset
      the H flag to zero in the outgoing MO packet.

   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



Goyal, et al.            Expires March 21, 2013                 [Page 6]

Internet-Draft     draft-ietf-roll-p2p-measurement-06     September 2012


      zero.  A value 1 in this flag indicates that the Measurement
      Request MUST accumulate a source route for use by the Target to
      send the Measurement Reply back to the Origin.  In this case, an
      Intermediate Router MUST add its unicast IPv6 address (after
      eliding Compr number of prefix octets) to the Address vector in
      the manner specified later.  Route accumulation is not allowed
      when the Measurement Request travels along a hop-by-hop route with
      a global RPLInstanceID, i.e., along a global DAG, because:

      *  The DAG's root may need the Address vector to insert a source
         route to the Target; and

      *  The Target can presumably reach the Origin along this global
         DAG.

   o  Reverse (R): This flag is relevant only if the MO represents a
      Measurement Request that travels along a source route, specified
      in the Address vector, to the Target.  In other words, this flag
      MAY be set to one only if T = 1 and H = 0.  Otherwise, this flag
      MUST be set to zero.  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 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.  On receiving a Measurement Request with the B flag set to
      one, the Target SHOULD generate a Measurement Request to measure
      the cost of its current (or the most preferred) route to the
      Origin.  Receipt of this Measurement Request would allow the
      Origin to know the cost of the back route from the Target to
      itself and thus determine the round-trip cost of reaching the
      Target.

   o  Intermediate Reply (I): Relevant only if a hop-by-hop route is
      being measured, this flag serves as a permission to an
      Intermediate Router to generate a Measurement Reply if it knows
      the cost of the rest of the route being measured.  The Origin MAY
      set this flag to one if a hop-by-hop route is being measured
      (i.e., H = 1) and the Origin wants to allow an Intermediate Router
      to generate the Measurement Reply in response to this Measurement
      Request.  Setting this flag 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 (e.g. the root of a
      non-storing DAG or a common ancestor of the Origin and the Target



Goyal, et al.            Expires March 21, 2013                 [Page 7]

Internet-Draft     draft-ietf-roll-p2p-measurement-06     September 2012


      in a storing DAG) to know the Hop Count of the remainder of the
      route to the Target.  This flag MUST be set to zero 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.  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 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: A unicast IPv6 address of the Origin after eliding
      Compr number of prefix octets.  If the MO is traveling along a
      hop-by-hop route and the RPLInstanceID field indicates a local
      value, the Origin Address field MUST specify the DODAGID value
      that, along with the RPLInstanceID and the Target Address,
      uniquely identifies the hop-by-hop route being measured.

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

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

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

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

      *  When the Measurement Request is traveling along a hop-by-hop
         route with local RPLInstanceID and has the A flag set, the



Goyal, et al.            Expires March 21, 2013                 [Page 8]

Internet-Draft     draft-ietf-roll-p2p-measurement-06     September 2012


         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 reachable in the backward direction, i.e., from
         the Target to the Origin.  An Intermediate Router adding its
         address to the Address vector MUST ensure that its address does
         not already exist in the vector.

      *  When the Measurement Request is traveling along a source route,
         the Address vector MUST contain a complete route to the Target
         and the IPv6 addresses in the Address vector MUST be reachable
         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
         (i.e., the IPv6 addresses in the Address vector are reachable
         in the backward direction - from the Target 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 the routing metric values for the
      route being measured.

3.2.  Secure MO

   A Secure MO message 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 the routing metric values along a P2P
   route towards a Target, it generates an MO message and sets its
   fields as described in Section 3.1.  The setting of MO fields in
   specific cases is described below.  In all cases, the Origin MUST set
   the T flag to one to indicate that the MO represents a Measurement



Goyal, et al.            Expires March 21, 2013                 [Page 9]

Internet-Draft     draft-ietf-roll-p2p-measurement-06     September 2012


   Request.  The Origin MUST also include the routing metric objects 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 determines the
   next hop on the P2P route being measured.  If a hop-by-hop route is
   being measured (i.e., the H flag is set to one), the next hop is
   determined using the RPLInstanceID, the Target Address and, if
   RPLInstanceID is a local value, the Origin Address fields in the MO.
   If a source route is being measured (i.e., the H flag is set to
   zero), the Address[1] element contains the next hop address.

   The Origin MUST discard the MO message 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.

   Otherwise, 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 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: 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:




Goyal, et al.            Expires March 21, 2013                [Page 10]

Internet-Draft     draft-ietf-roll-p2p-measurement-06     September 2012


   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: 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 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): This flag MUST be set to zero.

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

   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  Hop-by-hop (H): This flag MUST be set to zero.





Goyal, et al.            Expires March 21, 2013                [Page 11]

Internet-Draft     draft-ietf-roll-p2p-measurement-06     September 2012


   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 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 set to zero.

   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 the Target (excluding the Origin and the Target).

      *  The IPv6 addresses (with Compr prefix octets elided) in the
         Address vector MUST be reachable in the forward direction,
         i.e., from the Origin to the Target.

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

      *  To prevent loops in the source route, the Origin 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 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

   A router (an Intermediate Router or the Target) 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.



Goyal, et al.            Expires March 21, 2013                [Page 12]

Internet-Draft     draft-ietf-roll-p2p-measurement-06     September 2012


   A router MUST discard a received MO with no further processing if the
   Compr field inside the received message is not same as 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 or the Target Address.  If neither, the router
   considers itself an Intermediate Router and MUST process the received
   MO in the following manner.

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

   If the H and I flags are set to one 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.  The router MUST drop the MO with no further processing:

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

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

   o  If the next hop is not in the same RPL routing domain as the
      router.

   Next, the router MUST update the routing metric objects, contained in
   the Metric Container option(s) 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.  An Intermediate Router can
   only update the existing metric objects and MUST NOT add any new
   routing metric object to the Metric Container.  An Intermediate
   Router MUST drop the MO if it cannot update a routing metric object
   specified inside the Metric Container.

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



Goyal, et al.            Expires March 21, 2013                [Page 13]

Internet-Draft     draft-ietf-roll-p2p-measurement-06     September 2012


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

   In case the received MO is measuring a source route (H=0),

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

   o  The router MUST then increment the Index field and use the
      Address[Index] element as the next hop.  If Index is greater than
      Num, the router MUST use the Target Address as the next hop.

   To prevent loops, an Intermediate Router MUST discard the MO packet
   with no further processing 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.

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 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 global DAG along
      which the received MO message had been traveling so far,

      *  The router discards the MO packet with no further processing if
         it does not know of a source route to reach the Target
         (specified by the Target Address listed in the packet).

      *  Otherwise, the router MUST do the following:

         +  Set the H, A and R flags to zero and the RPLInstanceID field
            to binary value 10000000.

         +  Remove any existing Address vector inside the MO.

         +  Insert a new Address vector inside the MO and specify a
            source route to the Target inside the Address vector as per



Goyal, et al.            Expires March 21, 2013                [Page 14]

Internet-Draft     draft-ietf-roll-p2p-measurement-06     September 2012


            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 reachable in the forward
               direction, i.e., towards the Target;

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

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

               o  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 one.


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 unicast IPv6 addresses listed as the Target
   Address, the router considers itself the Target and MUST process the
   received MO in the following manner.

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

   The Target MUST update the routing metric objects in the Metric
   Container options if required and MAY note the measured values for
   the complete route (especially, if the received Measurement Request
   is likely a response to an earlier Measurement Request that the
   Target had sent to the Origin with B flag set to one).

   The Target MUST generate a Measurement Reply message.  The
   Measurement Reply message MUST have the same SequenceNo field as the
   received Measurement Request message.  The received Measurement



Goyal, et al.            Expires March 21, 2013                [Page 15]

Internet-Draft     draft-ietf-roll-p2p-measurement-06     September 2012


   Request message can be trivially converted into the Measurement Reply
   by setting 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 global DAG (i.e., one
      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 to one, the Target MAY reverse the source route contained
      in the Address vector and use it to send the Measurement Reply
      back to the Origin.

   o  If the Measurement Request traveled along a source route and the R
      flag inside the received message is set to one, 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 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.


7.  Processing a Measurement Reply at the Origin

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

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

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


8.  Security Considerations

   The mechanism defined in this document can potentially be used by a



Goyal, et al.            Expires March 21, 2013                [Page 16]

Internet-Draft     draft-ietf-roll-p2p-measurement-06     September 2012


   compromised router to generate bogus Measurement Requests to
   arbitrary Target routers.  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 specified
   in the Address vector, some of the security concerns that led to the
   deprecation of Type 0 routing header [RFC5095] may be valid here.  To
   address such concerns, the mechanism described in this document
   includes several remedies:

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

   o  This document requires that an MO message must not cross the
      boundaries of the RPL 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
      inside the Address vector of each received MO message to ensure
      that it does not contain a loop involving the router.  The router
      must drop the received packet if the source route does contain
      such a loop.  This and the previous two rules protect the network
      against some of the security concerns even if a compromised node
      inserts a malformed Address vector inside the MO message.


9.  IANA Considerations

   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



Goyal, et al.            Expires March 21, 2013                [Page 17]

Internet-Draft     draft-ietf-roll-p2p-measurement-06     September 2012


      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
              (work in progress), June 2012.

   [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



Goyal, et al.            Expires March 21, 2013                [Page 18]

Internet-Draft     draft-ietf-roll-p2p-measurement-06     September 2012


              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






Goyal, et al.            Expires March 21, 2013                [Page 19]

Internet-Draft     draft-ietf-roll-p2p-measurement-06     September 2012


   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 March 21, 2013                [Page 20]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/