Internet Engineering Task Force                            M. Goyal, Ed.
Internet-Draft                                   University of Wisconsin
Intended status: Standards Track                               Milwaukee
Expires: October 13, 2011 January 12, 2012                               E. Baccelli, Ed.
                                                                   INRIA
                                                               A. Brandt
                                                           Sigma Designs
                                                               R. Cragie
                                                           Gridmerge Ltd
                                                             J. Martocci
                                                        Johnson Controls
							      C. Perkins
							     Tellabs Inc
                                                          April
                                                           July 11, 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-00
                   draft-ietf-roll-p2p-measurement-01

Abstract

   This document specifies a mechanism that enables an RPL node router to
   measure the quality of an existing route to/from to another RPL node router in a
   low power and lossy network, thereby allowing the node router to decide if
   it wants to initiate the discovery of a more optimal 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 October 13, 2011. January 12, 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
   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.  Functional Overview  . . . . . . . . . . . . . . . . . . . . .  4
   3.  The Measurement Object (MO)  . . . . . . . . . . . . . . . . .  5
   4.  Originating an MO To Measure a P2P Route . . . . . . . . . . .  6
     4.1.  From the Origin Node to the Target Node  . . . . Measurement Request  . . . . .  7
     4.2.  From the Target Node to the Origin Node . . . . . . . . .  8
   5.  Processing a Received MO Measurement Request at an Intermediate Router . . . . . .  8  9
   6.  Processing a Received MO Measurement Request at the Target Node  . . . . . . . . .  9 10
   7.  Processing a Received MO Measurement Reply at the Origin Node . . . . . . . . . 11
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   10. Acknowledgement  . . . . Authors and Contributors . . . . . . . . . . . . . . . . . . . 11
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 12
     11.2. Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12

1.  Introduction

   Point to point (P2P) communication between arbitrary nodes 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 characteristics. criteria.  This mechanism, henceforth referred to as the
   reactive P2P route discovery, requires the specification of
   "good enough criteria", in terms of constraints on aggregated values
   of the relevant routing metrics
   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 node router to infer the good enough criteria 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 P2P routes are deemed unsatisfactory by the
   application layer but the node router
   does not intrinsically know the good
   enough criteria, routing constraints to be used in P2P
   route discovery, it may be necessary for the node router to determine the
   aggregated values of relevant the routing metrics along the existing
   routes. route.
   This knowledge will allow the node router to frame a reasonable
   good enough criteria and initiate a reactive routing
   constraints for use in P2P route discovery to determine a better routes.
   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
   a the routing
   constraint for use in the good enough criteria. P2P route discovery.  Note that it is important
   that the good enough criteria is routing constraints are not overly strict; otherwise the P2P
   route discovery may fail even though routes, a route, much better than the
   ones being
   one currently being used, exist. exists.

   This document specifies a mechanism that enables an RPL node router to
   measure the aggregated values of the routing metrics along an
   existing route to/from to another RPL node router in an LLN, thereby allowing the node
   router to decide if it wants to initiate the reactive discovery of a
   more optimal route and determine the good enough criteria 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
   [I-D.ietf-roll-terminology], [I-D.ietf-roll-rpl] and
   [I-D.ietf-roll-p2p-rpl].  Specifically, the term node refers to an
   RPL router or an RPL host as defined in [I-D.ietf-roll-rpl].  The following terms, originally defined in
   [I-D.ietf-roll-p2p-rpl], are redefined in the following manner.

   Origin Node:

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

   Target Node:

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

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

2.  Functional Overview

   The mechanism described in this document can be used by an origin
   node to
   measure the aggregated values of the routing metrics along a P2P
   route to/from to a target node in the LLN.  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].

   When an  The origin node desires to measure the aggregated values of the
   routing metrics along a P2P route from itself to a target node, it
   sends a Measurement Request message along that the route.  The Measurement
   Request message accumulates the values of the relevant routing metrics as it travels
   towards the target node. target.  Upon receiving the Measurement Request message, Request, the
   target node unicasts a Measurement Reply message, carrying the accumulated
   values of the routing metrics, back to the origin node.

   When an origin node desires to measure the aggregated values of the
   routing metrics along a P2P route from a target node to itself, it
   unicasts a Measurement Request message, specifying the routing
   metrics to be measured, to the target node.  On receiving the
   Measurement Request message, the target node sends a Measurement
   Reply message to the origin node along the P2P route to be measured.
   The Measurement Reply message accumulates the values of the relevant
   routing metrics as it travels towards the origin node.

3.  The origin.

3.  The Measurement Object (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 |  SequenceNo              |T|H|I|D| Resvd   | Compr |T|H|A|R|  Num  | Index |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                       Origin Address                          |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                       Target Address                          |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                   Source Route Option(*)                       Address[1..Num]                         .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                   Metric Container Options Option(s)                  .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 1: Format of the Measurement Object (MO)

   This document defines a new RPL Control Message type, the Measurement
   Object (MO) (MO), with code 0x05 0x06 (to be confirmed by IANA) that serves as
   both Measurement Request and Measurement Reply.  The format of an MO
   is shown in Figure 1.  An 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.
      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  SequenceNo: A 16-bit An 8-bit sequence number that uniquely identifies a
      Measurement Request and the corresponding Measurement Reply to Reply.

   o  Compr: A 4-bit unsigned integer indicating the
      origin node. number of prefix
      octets that are elided from the IPv6 addresses in Origin/Target
      Address fields and the Address vector.  For example, Compr value
      will be 0 if full IPv6 addresses are carried in the Origin/Target
      Address fields and the Address vector.

   o  T: The type flag.  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  H:  Hop-by-hop (H): This flag is set if the MO travels along a hop-by-hop hop-by-
      hop route.  In that case, the hop-by-hop route is identified by
      the RPLInstanceID and, if required, the Origin/Target RPLInstanceID is a local value, the
      Origin Address serving as the DODAGID.  This flag is cleared if
      the MO travels along a source route.  In that case, route specified in the MO MUST contain a Source Route
      option [I-D.ietf-roll-p2p-rpl]. Address
      vector.  Note that, in case of a the P2P route being measured lies
      along a non-storing DAG, it is possible that an MO message travels may travel along a hop-by-hop 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 a Source Route option
      in the MO.

   o  I: A flag that indicates which of the two - source route to the Origin Address and
      destination inside the Target Address - indicates the DODAGID for the hop-by-hop
      route. vector.

   o  Accumulate Route (A): This flag is relevant only if the MO
      represents a Measurement Request that travels along a hop-
      by-hop hop-by-hop
      route (i.e., H flag is set) and represented by a local RPLInstanceID has
      been specified to identify the hop-by-hop route.  This RPLInstanceID.  When this flag is set
      if
      relevant, a value 1 in the Origin Address flag indicates that the DODAGID; Measurement
      Request MUST accumulate a source route for use by the flag is cleared
      if target to
      send the Target Address indicates Measurement Reply back to the DODAGID.

   o  D: A flag that indicates origin.  In this case, the direction
      intermediate routers MUST add their IPv6 addresses (after eliding
      Compr number of prefix octets) to the P2P route. Address vector in the manner
      specified later.

   o  Reverse (R): This flag is set when relevant only if the route to be measured is from MO represents a
      Measurement Request that travels along a source route, specified
      in the Address vector, to the target.  When this flag is relevant,
      a value 1 in the flag indicates that the Address vector contains a
      complete source route from the origin node to the target, which can be
      used, after reversal, by the target node.  Otherwise, to source route the flag
      Measurement Reply message back to the origin.

   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 cleared.
      not present in the MO.

   o  Reserved: These bits are reserved for future use.  These bits  Index: If the Measurement Request is traveling along a source
      route contained in the Address vector, 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, 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 MUST be ignored on
      reception.

   o  Origin Address: The An IPv6 address of the origin node.

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

   o  Source Route Option: An MO MUST contain one Source Route option if
      it travels is traveling along a source route.

   o  Metric Container Options: An MO MUST contain one or more Metric
      Container options to carry hop-by-
      hop route and the routing metric objects
      [I-D.ietf-roll-routing-metrics].

4.  Originating an MO To Measure RPLInstanceID field indicates a P2P Route
4.1.  From local value, the
      Origin Node to Address field MUST contain the Target Node

   If DODAGID value that, along
      with the origin node intends to measure RPLInstanceID, uniquely identifies the routing metric values along
   a P2P hop-by-hop route towards a target node, it generates an MO message and
   sets its fields as follows:
      being measured.

   o  RPLInstanceID: If  Target Address: An IPv6 address of the P2P route is 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 hop-by-hop route, (partial) route from the
      origin
      node specifies to the target:

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

      *  The total number of elements inside the RPLInstanceID to identify Address vector is given
         by the route in this Num field.  This field is not relevant if

      *  When the P2P route Measurement Request is traveling along a source hop-by-hop
         route specified in with local RPLInstanceID and has the Source Route option.  This document
      RECOMMENDS a value 10000000 for this field if A flag set, the P2P route
         Address vector is used to accumulate a
      source route.

   o  SequenceNo: The origin node assigns a sequence number route to be used by the MO
         target to
      uniquely identify send the corresponding Measurement Reply.

   o  T: The T flag is set Reply back to indicate that MO represents a Measurement
      Request.

   o  H: The H flag is set if the MO travels along a hop-by-hop route.

   o  I: This field origin.  In
         this case, the route MUST be accumulated in relevant only if the H flag is set and forward
         direction, i.e., from the
      RPLInstanceID is a local value.  The origin node sets this flag if
      the Origin Address indicates to the DODAGID. target.  The origin node clears target
         router would reverse this flag if 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 Target Address indicates vector
         MUST ensure that its address does not already exist in the DODAGID.

   o  D: This flag
         vector.

      *  When the Measurement Request is set.

   o  Origin Address, Target Address: These fields are set traveling along a source route,
         the Address vector MUST contain a complete route to the target
         and the IPv6 addresses of in the origin and target nodes respectively.  If Address vector MUST be accessible
         in the H
      flag is set and forward direction, i.e., from the RPLInstanceID is a local value, origin to the Origin
      Address target.
         A router (the origin or an intermediate router) specifying a
         route to the target in the Target Address vector MUST also indicate ensure that the DODAGID value
      required to identify
         vector does not contain any address more than once.  The origin
         may set the hop-by-hop route.

   o  Source Route Option: If R flag in the MO if the P2P route is in the Address vector
         represents a source complete route (i.e., from the
      H flag is cleared), origin to the Source Route option MUST be present target and
      MUST include a complete source
         this route to can be used after reversal by the target node in forward
      direction (excluding to send the addresses of
         Measurement Reply message back to the origin.

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

      *  The Address vector MUST NOT contain any multicast addresses.

   o  Metric Container Options: The origin node An MO MUST also include contain one or more Metric
      Container options containing relevant routing metric
      objects to accumulate the costs routing metric values for these metrics along the P2P
      route.  The
      route being measured.

4.  Originating a Measurement Request

   If an origin node also initiates needs to measure the routing metric objects
      by including the local values of the routing metrics for the first
      hop on the along a P2P route.

   After setting the
   route towards a target, it generates an MO message and sets its
   fields as in the manner described above, above.  Specifically, the origin node MUST
   unicast
   set the MO message T flag to 1 to indicate that the next hop on MO represents a Measurement
   Request.

   If a source route is being measured, the P2P route.  The origin
   node MAY include a Record Route IPv6 Extension Header, proposed MUST do the
   following:

   o  specify the complete source route to the target inside the Address
      vector;

   o  specify in
   [I-D.thubert-6man-reverse-routing-header], the Num field the number of address elements in the MO message
      Address vector;

   o  set the Index field to
   accumulate a reverse value zero;

   o  set the R flag if the route that in the target node Address vector can use be used
      after reversal by the target to send source route the Measurement Reply
      message back to the origin node.

4.2.  From the Target Node to the Origin Node

   If the origin node intends to measure the routing metric values along origin.

   If a P2P hop-by-hop route from with a target node to itself, it generates an MO message local RPLInstanceID is being measured
   and sets its fields as follows:

   o  SequenceNo: The the origin node assigns a sequence number to desires the MO to
      uniquely identify accumulate a source route for the corresponding Measurement Reply.

   o  T: The T flag is set
   target to indicate that MO represents a send the Measurement
      Request. Reply message back, it MUST do the
   following:

   o  D: This  set A flag is cleared. to 1;

   o  Origin Address, Target Address: These fields are  include a suitably sized, empty Address vector (with all bits set
      to zero) in the IPv6
      addresses MO;

   o  specify in the Num field the number of address elements that can
      fit inside the origin and target nodes respectively. Address vector;

   o  Source Route Option: In this case,  set the MO SHOULD NOT include any
      Source Route option.

   o  Metric Container Options: Index field to value zero.

   The origin node MUST include one or more Metric Container options containing relevant inside
   the MO that carry the routing metric objects to accumulate of interest.  If
   required, the costs for origin must also initiate these metrics along the P2P
      route.  These routing metric objects MUST be empty.

   The other fields in
   by including the MO are not relevant in this case and SHOULD
   be set to zero. values of the routing metrics for the first hop on
   the P2P route being measured.

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

5.  Processing a Received MO Measurement Request at an Intermediate Router

   When a node router receives an MO, it examines if one of its IPv6
   addresses is listed as the Origin Address or the Target Address.  If not, the
   node checks if H bit is clear (i.e., the MO is traveling along a
   source route).  If yes, the node checks the Address[0] field inside
   the Source Route Option contained in the MO.  The node MUST drop the
   MO with no further processing and send an ICMPv6 Destination
   Unreachable error message to the source of
   router processes the received message (the Origin
   Address if the MO is a Measurement Request; otherwise the Target
   Address) if in the received MO has a clear H bit but does not contain a
   Source Route Option or if following manner.

   An intermediate router MUST discard the Address[0] inside packet with no further
   processing if the Source Route
   option does received MO is not match one of the node's IPv6 address. a Measurement Request.

   The node router then determines the next hop on the P2P route being
   measured.  In case the received MO has a clear H flag, the Address[1]
   field (the second element in router
   increments the Address vector) inside Index field and uses the Source
   Route Option is taken Address[Index] element as the
   next hop.  If the Source Route Option this element does not contain Address[1] element, the node checks the T flag
   inside exist, the MO.  If T flag is set, i.e., MO is a Measurement Request, router uses the Target
   Address is taken as the next hop; otherwise the Origin
   Address is the next hop.

   If the received MO has H flag set, set to 1, the node router uses the
   RPLInstanceID, the ultimate destination of the MO (Target Target Address if T flag is set; otherwise the Origin Address) and, if RPLInstanceID is a local
   value, the DODAGID (the Origin Address if I
   flag is set; otherwise (same as the Target Origin Address) to determine the next
   hop for the MO.  Also,

   o  If the H flag in RPLInstanceID of the MO hop-by-hop route is set a local value and
      the A flag is set, the router MUST store one of its IPv6 addresses
      (after eliding Compr bytes and making sure that the Address vector
      does not already contains one of its IPv6 addresses) at location
      Address[Index] and then increments the Index field.

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

      *  reset the H flag H, A and R flags;

      *  insert a Source Route option in the MO to
   indicate a source route along which to the MO should travel on rest target inside the Address vector;

      *  specify in the Num field the number of
   its way address elements in the
         Address vector;

      *  set the Index field to its destination. value zero;

   The node router MUST drop the MO with no further processing and send an
   ICMPv6 Destination Unreachable 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 node router updates 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.  The
   node
   router MUST drop the MO with no further processing and send a
   suitable ICMPv6 error message to the source of the message if the node
   router does not know the relevant routing metric values for the next
   hop.

   After updating the routing metrics, the node router MUST unicast the MO to
   the next hop.  If the MO to be forwarded has a clear H flag, the node
   MUST ensure that the Address vector in the Source Route option
   contains the next hop address as the first element.

6.  Processing a Received MO Measurement Request at the Target Node

   When a node router receives an MO, it examines if one of its IPv6
   addresses is listed as the Target Address.  If yes, the node checks router
   processes the T flag.
   The node received message in the following manner.

   An intermediate router MUST drop discard the MO packet with no further processing and optionally
   log an error if the T flag is clear (i.e. further
   processing if the received MO is not a Measurement Reply). Request.

   The target node then checks the D flag to determine the direction of
   the P2P route to be measured.  If the D flag is set (i.e., the P2P
   route to be measured is from the origin node to the target node), the
   target node updates the routing metrics objects in the Metric
   Container options if required, removes the Source Route Option if
   present required and clears the T bit thereby converting the MO into generates a Measurement Reply.  The target node then unicasts the updated MO back
   to the origin node.  For this purpose, the target node MAY use the
   reverse route accumulated in the Record Route IPv6 Extension Header
   [I-D.thubert-6man-reverse-routing-header] if present in the received
   MO Reply
   message.

   If the D flag in the  The received MO Measurement Request message is clear (i.e., the P2P
   route to can be measured is from trivially
   converted into the target node Measurement Reply by reseting the T flag to zero.
   The target MAY remove the origin node), Address vector from the Measurement Reply
   if desired.  The target node selects then unicasts the P2P route Measurement Reply back to be measured and modifies
   the
   following MO fields: origin:

   o  RPLInstanceID:  If the P2P route is Measurement Request traveled along a hop-by-hop route, the target
      node specifies in this field the RPLInstanceID associated DAG with the
      route.  This field is not relevant if the P2P route is a source
      route.  This document RECOMMENDS a value 10000000 for this field
      if global
      RPLInstanceID, the P2P route is a source route.

   o  T: The T flag is cleared to indicate that MO represents a Measurement Reply.

   o  H: The H flag is set if the P2P route is a hop-by-hop one.

   o  I: If the H flag is set and the RPLInstanceID is a local value,
      the target node sets this flag if the Origin Address indicates the
      DODAGID.  The target node clears this flag if the Target Address
      indicates Reply MAY be unicast back to the DODAGID.

   o  D: This flag is cleared.
      origin along the same DAG.

   o  Source Route Option:  If the P2P Measurement Request traveled along a hop-by-hop route is with
      a source route, the
      Source Route option MUST be present local RPLInstanceID and MUST include a complete the A flag inside the received message
      is set, the target MAY reverse the source route from contained in the target node
      Address vector and use it to send the origin node (excluding Measurement Reply back to
      the addresses of origin.

   o  If the target Measurement Request traveled along a source route and origin nodes).

   o  Metric Container Options: The target node MUST initiate the
      routing metric objects R
      flag inside the Metric Container options by
      including the local values of the routing metrics for the first
      hop on received message it set, the P2P route.

   The target node need not modify MAY reverse
      the other fields source route contained in the received MO.
   After these modifications, the target node MUST unicast the MO
   message Address vector and use it to
      send the next hop on Measurement Reply back to the P2P route. origin.

7.  Processing a Received MO Measurement Reply at the Origin Node

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

   The node origin MUST drop discard the MO packet with no further processing and optionally
   log an error if the T flag is set (i.e. the
   received MO is not a Measurement Request) Reply or if the node origin has no
   recollection of sending a Measurement Request with the sequence
   number listed in the received MO.

   If the D flag in the received MO is clear (i.e., the P2P route to be
   measured is from the target node to the origin node), the origin node
   MUST update the routing metrics objects in the Metric Container
   options if required.

   The origin node can now examine then examines 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
   enroute nodes, routers, the origin node MAY aggregate these local values into an
   end-to-end value as per the aggregation rules for the metric.

8.  Security Considerations

   TBA

9.  IANA Considerations

   TBA

10.  Acknowledgement  Authors and Contributors

   In addition to the editors, the authors of this document include the
   following individuals (listed in alphabetical order).

   Anders Brandt, Sigma Designs, Emdrupvej 26A, 1., Copenhagen, Dk-2100,
   Denmark.  Phone: +45 29609501; Email: abr@sdesigns.dk

   Robert Cragie, Gridmerge Ltd, 89 Greenfield Crescent, Wakefieldm WF4
   4WA, UK.  Phone: +44 1924910888; Email: robert.cragie@gridmerge.com

   Jerald Martocci, Johnson Controls, Milwaukee, WI 53202, USA.  Phone:
   +1 414 524 4010; Email:jerald.p.martocci@jci.com

   Charles Perkins, Tellabs Inc., USA.  Email:charliep@computer.org

   Authors gratefully acknowledge the contributions of 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., Brandt, A., Cragie, R., Martocci,
              J., and C. Perkins, J.
              Martocci, "Reactive Discovery of Point-to-Point Routes in
              Low Power and Lossy Networks",
              draft-ietf-roll-p2p-rpl-02 draft-ietf-roll-p2p-rpl-03
              (work in progress),
              February May 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-05 (work in
              progress), March 2011.

   [I-D.thubert-6man-reverse-routing-header]
              Thubert, P., "Reverse Routing Header",
              draft-thubert-6man-reverse-routing-header-01 (work in
              progress), December 2010.

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

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 (editor)
   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

   Robert Cragie
   Gridmerge Ltd
   89 Greenfield Crescent
   Wakefield  WF4 4WA
   UK

   Phone: +44-1924910888
   Email: robert.cragie@gridmerge.com
   Jerald Martocci
   Johnson Controls
   507 E Michigan St
   Milwaukee, WI  53202
   USA

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

   Charles Perkins
   Tellabs Inc

   Email: charliep@computer.org