draft-ietf-roll-p2p-measurement-09.txt   draft-ietf-roll-p2p-measurement-10.txt 
Internet Engineering Task Force M. Goyal, Ed. Internet Engineering Task Force M. Goyal, Ed.
Internet-Draft University of Wisconsin Internet-Draft University of Wisconsin
Intended status: Experimental Milwaukee Intended status: Experimental Milwaukee
Expires: August 8, 2013 E. Baccelli Expires: October 3, 2013 E. Baccelli
INRIA INRIA
A. Brandt A. Brandt
Sigma Designs Sigma Designs
J. Martocci J. Martocci
Johnson Controls Johnson Controls
February 4, 2013 April 1, 2013
A Mechanism to Measure the Routing Metrics along a Point-to-point Route A Mechanism to Measure the Routing Metrics along a Point-to-point Route
in a Low Power and Lossy Network in a Low Power and Lossy Network
draft-ietf-roll-p2p-measurement-09 draft-ietf-roll-p2p-measurement-10
Abstract Abstract
This document specifies a mechanism that enables an RPL router to This document specifies a mechanism that enables an RPL router to
measure the aggregated values of given routing metrics along an measure the aggregated values of given routing metrics along an
existing route towards another RPL router, thereby allowing the existing route towards another RPL router, thereby allowing the
router to decide if it wants to initiate the discovery of a better router to decide if it wants to initiate the discovery of a better
route. route.
Status of this Memo Status of this Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 8, 2013. This Internet-Draft will expire on October 3, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The Measurement Object (MO) . . . . . . . . . . . . . . . . . 6 3. The Measurement Object (MO) . . . . . . . . . . . . . . . . . 6
3.1. Format of the base MO . . . . . . . . . . . . . . . . . . 6 3.1. Format of the base MO . . . . . . . . . . . . . . . . . . 6
3.2. Secure MO . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Secure MO . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Originating a Measurement Request . . . . . . . . . . . . . . 11 4. Originating a Measurement Request . . . . . . . . . . . . . . 11
4.1. When Measuring A Hop-by-hop Route with a Global 4.1. When Measuring A Hop-by-hop Route with a Global
RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 12 RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 12
4.2. When Measuring A Hop-by-hop Route with a Local 4.2. When Measuring A Hop-by-hop Route with a Local
RPLInstanceID With Route Accumulation Off . . . . . . . . 13 RPLInstanceID With Route Accumulation Off . . . . . . . . 13
4.3. When Measuring A Hop-by-hop Route with a Local 4.3. When Measuring A Hop-by-hop Route with a Local
RPLInstanceID With Route Accumulation On . . . . . . . . . 14 RPLInstanceID With Route Accumulation On . . . . . . . . . 14
4.4. When Measuring A Source Route . . . . . . . . . . . . . . 15 4.4. When Measuring A Source Route . . . . . . . . . . . . . . 16
5. Processing a Measurement Request at an Intermediate Point . . 16 5. Processing a Measurement Request at an Intermediate Point . . 17
5.1. When Measuring A Hop-by-hop Route with a Global 5.1. When Measuring A Hop-by-hop Route with a Global
RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 17 RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 18
5.2. When Measuring A Hop-by-hop Route with a Local 5.2. When Measuring A Hop-by-hop Route with a Local
RPLInstanceID With Route Accumulation Off . . . . . . . . 18 RPLInstanceID With Route Accumulation Off . . . . . . . . 19
5.3. When Measuring A Hop-by-hop Route with a Local 5.3. When Measuring A Hop-by-hop Route with a Local
RPLInstanceID With Route Accumulation On . . . . . . . . . 19 RPLInstanceID With Route Accumulation On . . . . . . . . . 20
5.4. When Measuring A Source Route . . . . . . . . . . . . . . 19 5.4. When Measuring A Source Route . . . . . . . . . . . . . . 21
5.5. Final Processing . . . . . . . . . . . . . . . . . . . . . 20 5.5. Final Processing . . . . . . . . . . . . . . . . . . . . . 21
6. Processing a Measurement Request at the End Point . . . . . . 20 6. Processing a Measurement Request at the End Point . . . . . . 22
6.1. Generating the Measurement Reply . . . . . . . . . . . . . 21 6.1. Generating the Measurement Reply . . . . . . . . . . . . . 23
7. Processing a Measurement Reply at the Start Point . . . . . . 22 7. Processing a Measurement Reply at the Start Point . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
Point to point (P2P) communication between arbitrary routers in a Low Point to point (P2P) communication between arbitrary routers in a Low
power and Lossy Network (LLN) is a key requirement for many power and Lossy Network (LLN) is a key requirement for many
applications [RFC5826][RFC5867]. The IPv6 Routing Protocol for LLNs applications [RFC5826][RFC5867]. The IPv6 Routing Protocol for LLNs
(RPL) [RFC6550] constrains the LLN topology to a Directed Acyclic (RPL) [RFC6550] constrains the LLN topology to a Directed Acyclic
Graph (DAG) built to optimize the routing costs to reach the DAG's Graph (DAG) built to optimize the routing costs to reach the DAG's
root. The P2P routing functionality, available under RPL, has the root. The P2P routing functionality, available under RPL, has the
following key limitations: following key limitations:
o The P2P routes are restricted to use the DAG links only. Such P2P o The P2P routes are restricted to use the DAG links only. Such P2P
routes may potentially be suboptimal and may lead to traffic routes may potentially be suboptimal and may lead to traffic
congestion near the DAG root. congestion near the DAG root.
o RPL is a proactive routing protocol and hence requires all P2P o RPL is a proactive routing protocol and hence requires all P2P
routes to be established ahead of the time they are used. Many routes to be established ahead of the time they are used. Many
LLN applications require the ability to establish P2P routes "on LLN applications require the ability to establish P2P routes "on
demand". demand".
To ameliorate situations, where the core RPL's P2P routing To ameliorate situations where the core RPL's P2P routing
functionality does not meet the application requirements, functionality does not meet the application requirements
[I-D.ietf-roll-p2p-rpl] describes P2P-RPL, an extension to core RPL. [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 P2P-RPL provides a reactive mechanism to discover P2P routes that
meet the specified routing constraints [RFC6551]. In some cases, the meet the specified routing constraints [RFC6551]. In some cases, the
application requirements or the LLN's topological features allow a application requirements or the LLN's topological features allow a
router to infer these routing constraints implicitly. For example, router to infer these routing constraints implicitly. For example,
the application may require the end-to-end loss rate and/or latency 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 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 may be such that a router can safely assume its destination to be
less than a certain number of hops away from itself. less than a certain number of hops away from itself.
skipping to change at page 4, line 21 skipping to change at page 4, line 21
the utility and benefits of this document and it will be revised and the utility and benefits of this document and it will be revised and
progressed on the Standards Track based on this feedback. progressed on the Standards Track based on this feedback.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
This document uses terminology from [RFC6550] and This document uses terminology from [RFC6550],
[I-D.ietf-roll-p2p-rpl]. Additionally, this document defines the [I-D.ietf-roll-terminology] and [I-D.ietf-roll-p2p-rpl].
following terms. Additionally, this document defines the following terms.
Start Point: The Start Point refers to the RPL router that initiates Start Point: The Start Point refers to the RPL router that initiates
the measurement process defined in this document and is the start the measurement process defined in this document and is the start
point of the P2P route being measured. point of the P2P route being measured.
End Point: The End Point refers to the RPL router at the end point of End Point: The End Point refers to the RPL router at the end point of
the P2P route being measured. the P2P route being measured.
Intermediate Point: An RPL router, other than the Start Point and the Intermediate Point: An RPL router, other than the Start Point and the
End Point, on the P2P route being measured. End Point, on the P2P route being measured.
skipping to change at page 4, line 50 skipping to change at page 4, line 50
Reverse direction: The direction from the End Point to the Start Reverse direction: The direction from the End Point to the Start
Point. Point.
2. Overview 2. Overview
The mechanism described in this document can be used by a Start Point The mechanism described in this document can be used by a Start Point
in an LLN to measure the aggregated values of selected routing in an LLN to measure the aggregated values of selected routing
metrics along a P2P route to an End Point within the LLN. The route metrics along a P2P route to an End Point within the LLN. The route
is measured in the Forward direction. Such a route could be a Source is measured in the Forward direction. Such a route could be a Source
Route [I-D.ietf-roll-p2p-rpl] or a Hop-by-hop Route Route or a Hop-by-hop Route established using RPL [RFC6550] or P2P-
RPL [I-D.ietf-roll-p2p-rpl]. Such a route could also be a "mixed"
[I-D.ietf-roll-p2p-rpl] established using RPL [RFC6550] or P2P-RPL route with the initial part consisting of hop-by-hop ascent to the
[I-D.ietf-roll-p2p-rpl]. Such a route could also be a "mixed" route root of a non-storing DAG [RFC6550] and the final part consisting of
with the initial part consisting of hop-by-hop ascent to the root of a source-routed descent to the End Point. The Start Point decides
a non-storing DAG [RFC6550] and the final part consisting of a what metrics to measure and sends a Measurement Request message,
source-routed descent to the End Point. The Start Point decides what carrying the desired routing metric objects, along the route. If a
metrics to measure and sends a Measurement Request message, carrying Source Route is being measured, the Measurement Request carries the
the desired routing metric objects, along the route. If a Source route inside an Address vector. If a Hop-by-hop Route is being
Route is being measured, the Measurement Request carries the route measured, the Measurement Request identifies the route by its
inside an Address vector. If a Hop-by-hop Route is being measured, RPLInstanceID [RFC6550] (and, in case the RPLInstanceID is a local
the Measurement Request identifies the route by its RPLInstanceID value, the Start Point's IPv6 address associated with the route). On
[RFC6550] (and, in case the RPLInstanceID is a local value, the Start receiving a Measurement Request, an Intermediate Point updates the
Point's IPv6 address associated with the route). On receiving a routing metric values inside the message and forwards it to the next
Measurement Request, an Intermediate Point updates the routing metric hop on the route. Thus, the Measurement Request accumulates the
values inside the message and forwards it to the next hop on the values of the routing metrics for the complete route as it travels
route. Thus, the Measurement Request accumulates the values of the towards the End Point. Upon receiving the Measurement Request, the
routing metrics for the complete route as it travels towards the End End Point unicasts a Measurement Reply message, carrying the
Point. Upon receiving the Measurement Request, the End Point accumulated values of the routing metrics, back to the Start Point.
unicasts a Measurement Reply message, carrying the accumulated values Optionally, the Start Point may allow an Intermediate Point to
of the routing metrics, back to the Start Point. Optionally, the generate the Measurement Reply if the Intermediate Point already
Start Point may allow an Intermediate Point to generate the knows the relevant routing metric values along rest of the route.
Measurement Reply if the Intermediate Point already knows the
relevant routing metric values along rest of the route.
The Measurement Request may include an Address vector that serves one The Measurement Request may include an Address vector that serves one
of the following functions: of the following functions:
o To accumulate a Source Route for End Point's use: If a Hop-by-hop o To accumulate a Source Route for End Point's use: If a Hop-by-hop
Route with a local RPLInstanceID is being measured, the Start Route with a local RPLInstanceID is being measured, the Start
Point may require each Intermediate Point to add its IPv6 address Point may require each Intermediate Point to add its global or
to an Address vector inside the Measurement Request. The Source unique local IPv6 address to an Address vector inside the
Route, thus accumulated, can be used by the End Point to reach the Measurement Request. The Source Route, thus accumulated, can be
Start Point. In particular, the End Point may use the accumulated used by the End Point to reach the Start Point. In particular,
Source Route to send the Measurement Reply back to the Start the End Point may use the accumulated Source Route to send the
Point. In this case, the Start Point includes a suitably-sized Measurement Reply back to the Start Point. In this case, the
Address vector in the Measurement Request. The size of the Start Point includes a suitably-sized Address vector in the
Address vector puts a hard limit on the length of the accumulated Measurement Request. The size of the Address vector puts a hard
route. An Intermediate Point is not allowed to modify the size of limit on the length of the accumulated route. An Intermediate
the Address vector and must discard a received Measurement Request Point is not allowed to modify the size of the Address vector and
if the Address vector is not large enough to contain the complete must discard a received Measurement Request if the Address vector
route. is not large enough to contain the complete route.
o To carry the Source Route being measured: The Start Point may o To carry the Source Route being measured: The Start Point may
insert an Address vector inside the Measurement Request to carry insert an Address vector inside the Measurement Request to carry
the Source Route being measured. Also, the root of a global non- the Source Route being measured. Also, the root of a global non-
storing DAG may insert an Address vector, carrying a Source Route storing DAG may insert an Address vector, carrying a Source Route
from itself to the End Point, inside a Measurement Request message from itself to the End Point, inside a Measurement Request message
if this message had been traveling along this DAG so far. In both if this message had been traveling along this DAG so far. This
cases, an Intermediate Point is not allowed to modify an existing Source Route must consist of global or unique local IPv6
Address vector before forwarding the Measurement Request further. addresses. An Intermediate Point is not allowed to modify an
In other words, an Intermediate Point is not allowed to modify the existing Address vector before forwarding the Measurement Request
Source Route along which the Measurement Request is currently further. In other words, an Intermediate Point must not modify
the Source Route along which the Measurement Request is currently
traveling. traveling.
3. The Measurement Object (MO) 3. The Measurement Object (MO)
This document defines two new RPL Control Message types, the This document defines two new RPL Control Message types, the
Measurement Object (MO), with code TBD1, and the Secure MO, with code Measurement Object (MO), with code TBD1, and the Secure MO, with code
TBD2. An MO serves as both Measurement Request and Measurement TBD2. An MO serves as both Measurement Request and Measurement
Reply. Reply.
3.1. Format of the base MO 3.1. Format of the base MO
0 1 2 3 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 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 | | RPLInstanceID | Compr |T|H|A|R|B|I| SeqNo | Num | Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Start Point Address . . Start Point Address .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. End Point Address . . End Point Address .
. . . .
| | | |
skipping to change at page 7, line 46 skipping to change at page 7, line 46
corresponding incoming Measurement Request unless it is the root corresponding incoming Measurement Request unless it is the root
of the non-storing global DAG, identified by the RPLInstanceID, of the non-storing global DAG, identified by the RPLInstanceID,
along which the Measurement Request had been traveling so far and along which the Measurement Request had been traveling so far and
the Intermediate Point intends to insert a Source Route inside the the Intermediate Point intends to insert a Source Route inside the
Address vector to direct it towards the End Point. In that case, Address vector to direct it towards the End Point. In that case,
the Intermediate Point MUST set the H flag to zero. the Intermediate Point MUST set the H flag to zero.
o Accumulate Route (A): A value 1 in this flag indicates that the o Accumulate Route (A): A value 1 in this flag indicates that the
Measurement Request is accumulating a Source Route for use by the Measurement Request is accumulating a Source Route for use by the
End Point to send the Measurement Reply back to the Start Point. End Point to send the Measurement Reply back to the Start Point.
Route accumulation is allowed (i.e., this flag MAY be set to one) Route accumulation MUST NOT be used (i.e., this flag MUST NOT be
inside a Measurement Request only if it travels along a Hop-by-hop set to 1) inside a Measurement Request unless it travels along a
Route represented by a local RPLInstanceID (i.e., H = 1, Hop-by-hop Route represented by a local RPLInstanceID (i.e., H =
RPLInstanceID has a local value). In this case, an Intermediate 1, RPLInstanceID has a local value). Route accumulation MAY be
Point adds its unicast IPv6 address (after eliding Compr number of used (i.e., this flag MAY be set to 1) if the Measurement Request
prefix octets) to the Address vector in the manner specified in is traveling along a Hop-by-hop Route with a local RPLInstanceID.
Section 5.3. In other cases, this flag MUST be set to zero on In this case if the route accumulation is on, an Intermediate
transmission and ignored on reception. Route accumulation is not Point adds its unicast global/unique-local IPv6 address (after
allowed when the Measurement Request travels along a Hop-by-hop eliding Compr number of prefix octets) to the Address vector in
Route with a global RPLInstanceID, i.e., along a global DAG, the manner specified in Section 5.3. In other cases, this flag
because: MUST be set to zero on transmission and ignored on reception.
Route accumulation is not allowed when the Measurement Request
travels along a Hop-by-hop Route with a global RPLInstanceID,
i.e., along a global DAG, because:
* The DAG's root may need the Address vector to insert a Source * The DAG's root may need the Address vector to insert a Source
Route to the End Point; and Route to the End Point; and
* The End Point can presumably reach the Start Point along this * The End Point can presumably reach the Start Point along this
global DAG (identified by the RPLInstanceID field). global DAG (identified by the RPLInstanceID field).
o Reverse (R): A value 1 in this flag inside a Measurement Request o Reverse (R): A value 1 in this flag inside a Measurement Request
indicates that the Address vector contains a complete Source Route indicates that the Address vector contains a complete Source Route
from the Start Point to the End Point, which can be used, after from the Start Point to the End Point, which can be used, after
skipping to change at page 8, line 48 skipping to change at page 9, line 5
one may be useful in scenarios where the Hop Count [RFC6551] is one may be useful in scenarios where the Hop Count [RFC6551] is
the routing metric of interest and an Intermediate Point (e.g. the the routing metric of interest and an Intermediate Point (e.g. the
root of a non-storing global DAG or a common ancestor of the Start root of a non-storing global DAG or a common ancestor of the Start
Point and the End Point in a storing global DAG) may know the Hop Point and the End Point in a storing global DAG) may know the Hop
Count of the remainder of the route to the End Point. This flag Count of the remainder of the route to the End Point. This flag
MAY be set to one only if a Hop-by-hop Route with a global MAY be set to one only if a Hop-by-hop Route with a global
RPLInstanceID is being measured (i.e., H = 1, RPLInstanceID has a RPLInstanceID is being measured (i.e., H = 1, RPLInstanceID has a
global value). Otherwise, this flag MUST be set to zero on global value). Otherwise, this flag MUST be set to zero on
transmission and ignored on reception. transmission and ignored on reception.
o SequenceNo: A 6-bit sequence number, assigned by the Start Point, o SeqNo: A 6-bit sequence number, assigned by the Start Point, that
that allows the Start Point to uniquely identify a Measurement allows the Start Point to uniquely identify a Measurement Request
Request and the corresponding Measurement Reply. and the corresponding Measurement Reply.
o Num: This field indicates the number of elements, each (16 - o Num: This field indicates the number of elements, each (16 -
Compr) octets in size, inside the Address vector. If the value of 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. this field is zero, the Address vector is not present in the MO.
o Index: If the Measurement Request is traveling along a Source o Index: If the Measurement Request is traveling along a Source
Route contained in the Address vector (i.e., H = 0), this field Route contained in the Address vector (i.e., H = 0), this field
indicates the index in the Address vector of the next hop on the 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. If the Measurement Request is traveling along a Hop-by-hop
Route with a local RPLInstanceID and the Route Accumulation is on Route with a local RPLInstanceID and the Route Accumulation is on
(i.e., H = 1, RPLInstanceID has a local value, A = 1), this field (i.e., H = 1, RPLInstanceID has a local value, A = 1), this field
indicates the index in the Address vector where an Intermediate indicates the index in the Address vector where an Intermediate
Point receiving the Measurement Request must store its IPv6 Point receiving the Measurement Request must store its IPv6
address. Otherwise, this field MUST be set to zero on address. Otherwise, this field MUST be set to zero on
transmission and ignored on reception. transmission and ignored on reception.
o Start Point Address: A unicast IPv6 address of the Start Point o Start Point Address: A unicast global or unique local IPv6 address
after eliding Compr number of prefix octets. If the Measurement of the Start Point after eliding Compr number of prefix octets.
Request is traveling along a Hop-by-hop Route and the If the Measurement Request is traveling along a Hop-by-hop Route
RPLInstanceID field indicates a local value, the Start Point and the RPLInstanceID field indicates a local value, the Start
Address field MUST specify the DODAGID value that, along with the Point Address field MUST specify the DODAGID value that, along
RPLInstanceID and the End Point Address, uniquely identifies the with the RPLInstanceID and the End Point Address, uniquely
Hop-by-hop Route being measured. identifies the Hop-by-hop Route being measured.
o End Point Address: A unicast IPv6 address of the End Point after o End Point Address: A unicast global or unique local IPv6 address
eliding Compr number of prefix octets. of the End Point after eliding Compr number of prefix octets.
o Address[0..Num-1]: A vector of unicast IPv6 addresses (with Compr o Address[0..Num-1]: A vector of unicast global or unique local IPv6
number of prefix octets elided) representing a Source Route: addresses (with Compr number of prefix octets elided) representing
a Source Route:
* Each element in the vector has size (16 - Compr) octets. * Each element in the vector has size (16 - Compr) octets.
* The total number of elements inside the Address vector is given * The total number of elements inside the Address vector is given
by the Num field. by the Num field.
* The Start Point and End Point addresses MUST NOT be included in * The Start Point and End Point addresses MUST NOT be included in
the Address vector. the Address vector.
* The Address vector MUST NOT contain any multicast addresses. * The Address vector MUST NOT contain any multicast addresses.
skipping to change at page 10, line 7 skipping to change at page 10, line 12
Point's use (i.e., the Measurement Request has the H flag set Point's use (i.e., the Measurement Request has the H flag set
to 1, RPLInstanceID set to a local value and the A flag set to to 1, RPLInstanceID set to a local value and the A flag set to
1), it MUST include a suitably-sized Address vector in the 1), it MUST include a suitably-sized Address vector in the
Measurement Request. As the Measurement Request travels over Measurement Request. As the Measurement Request travels over
the route being measured, the Address vector accumulates a the route being measured, the Address vector accumulates a
Source Route that can be used by the End Point, after reversal, Source Route that can be used by the End Point, after reversal,
to reach (and, in particular, to send the Measurement Reply to reach (and, in particular, to send the Measurement Reply
back to) the Start Point. The route MUST be accumulated in the back to) the Start Point. The route MUST be accumulated in the
Forward direction but the IPv6 addresses in the accumulated Forward direction but the IPv6 addresses in the accumulated
route MUST be reachable in the Reverse direction. An route MUST be reachable in the Reverse direction. An
Intermediate Point adding its address to the Address vector Intermediate Point MUST add only a global or unique local IPv6
MUST NOT modify the size of the Address vector. address to the Address vector and MUST NOT modify the size of
the Address vector.
* If the Start Point wants to measure a Source Route, it MUST * If the Start Point wants to measure a Source Route, it MUST
include an Address vector, containing the route being measured, include an Address vector, containing the route being measured,
inside the Measurement Request. Similarly, if the Measurement inside the Measurement Request. Similarly, if the Measurement
Request had been traveling along a global non-storing DAG so Request had been traveling along a global non-storing DAG so
far, the root of this DAG may insert an Address vector, far, the root of this DAG may insert an Address vector,
containing a Source Route from itself to the End Point, inside containing a Source Route from itself to the End Point, inside
the Measurement Request. In both cases, the Source Route the Measurement Request. In both cases, the Source Route
inside the Address vector MUST consist of IPv6 addresses inside the Address vector MUST consist only of global or unique
reachable in the Forward direction. Further, in both cases, an local IPv6 addresses that are reachable in the Forward
Intermediate Point MUST NOT modify the contents of the existing direction. Further, in both cases, an Intermediate Point MUST
Address vector before forwarding the Measurement Request NOT modify the contents of the existing Address vector before
further. In other words, an Intermediate Point MUST NOT modify forwarding the Measurement Request further. In other words, an
the Source Route along which the Measurement Request is Intermediate Point MUST NOT modify the Source Route along which
currently traveling. The Start Point MAY set the R flag in the the Measurement Request is currently traveling. The Start
Measurement Request to one if the Source Route inside the Point MAY set the R flag in the Measurement Request to one if
Address vector can be used by the End Point, after reversal, to the Source Route inside the Address vector can be used by the
reach (and, in particular, to send the Measurement Reply back End Point, after reversal, to reach (and, in particular, to
to) the Start Point. In other words, the Start Point MAY set send the Measurement Reply back to) the Start Point. In other
the R flag to one only if all the IPv6 addresses in the Address words, the Start Point MAY set the R flag to one only if all
vector are reachable in the Reverse direction. the IPv6 addresses in the Address vector are reachable in the
Reverse direction.
o Metric Container Options: A Measurement Request MUST contain one o Metric Container Options: A Measurement Request MUST contain one
or more Metric Container options [RFC6550] to accumulate the or more Metric Container options [RFC6550] to accumulate the
values of the selected routing metrics in the manner described in values of the selected routing metrics in the manner described in
[RFC6551] for the route being measured. [RFC6551] for the route being measured.
Section 4 describes how a Start Point sets various fields inside a Section 4 describes how a Start Point sets various fields inside a
Measurement Request in different cases. Section 5 describes how an Measurement Request in different cases. Section 5 describes how an
Intermediate Point processes a received Measurement Request before Intermediate Point processes a received Measurement Request before
forwarding it further. Section 6 describes how the End Point forwarding it further. Section 6 describes how the End Point
processes a received Measurement Request and generate a Measurement processes a received Measurement Request and generate a Measurement
Reply. Finally, Section 7 describes how the Start Point processes a Reply. Finally, Section 7 describes how the Start Point processes a
received Measurement Reply. In the following discussion, any received Measurement Reply. In the following discussion, any
reference to discarding a received Measurement Request/Reply with "no reference to discarding a received Measurement Request/Reply with "no
further processing" does not preclude updating the appropriate error further processing" does not preclude updating the appropriate error
counters or any similar actions. counters or any similar actions.
3.2. Secure MO 3.2. Secure MO
A Secure MO follows the format in Figure 7 of [RFC6550], where the A Secure MO follows the format in Figure 7 of [RFC6550], where the
base format is the base MO shown in Figure 1. base format is the base MO shown in Figure 1. Sections 6.1, 10 and
19 of [RFC6550] describe RPL security framework. These sections are
applicable to the use of Secure MO messages as well except as
constrained in this section. An LLN deployment MUST support the use
of Secure MO messages so that it has the ability to invoke RPL-
provided security mechanisms and prevent misuse of the measurement
mechanism by unauthorized routers.
An LLN deployment MUST support the use of Secure MO messages to have The Start Point determines whether Secure MO messages are to be used
the ability to invoke RPL-provided security mechanisms and prevent in a particular route measurement and if yes the Security
misuse of the measurement mechanism by unauthorized routers. Configuration (see definition in [I-D.ietf-roll-p2p-rpl]) to be used
for the purpose. The Start Point MUST NOT set the "Key Identifier
Mode" field to value 1 inside this Security Configuration since this
setting indicates the use of a per-pair key which is not suitable for
securing the Measurement Request messages that travel over multiple
hops. A router (an Intermediate Point or the End Point),
participating in a particular route measurement,
In the following discussion, any reference to MO message is also o MUST generate a Secure MO message (a Measurement Request or a
applicable to Secure MO message unless noted otherwise. Measurement Reply) if the received Measurement Request is a Secure
MO. The Security Configuration used in generating a Secure MO
message MUST be same as the one used in the received message.
o MUST NOT generate a Secure MO message if the received Measurement
Request is not a Secure MO.
A router MUST discard a received Measurement Request if it cannot
follow the above mentioned rules. If the Start Point sends a
Measurement Request in a Secure MO message using a particular
Security Configuration, it MUST discard the corresponding Measurement
Reply it receives with no further processing unless the Measurement
Reply is received in a Secure MO message generated with same Security
Configuration as the one used in the Measurement Request.
In the following discussion, any reference to an MO message is also
applicable to a Secure MO message unless noted otherwise.
4. Originating a Measurement Request 4. Originating a Measurement Request
A Start Point sets various fields inside the Measurement Request it A Start Point sets various fields inside the Measurement Request it
generates in the manner described below. The Start Point MUST also generates in the manner described below. The Start Point MUST also
include the routing metric objects [RFC6551] of interest inside one include the routing metric objects [RFC6551] of interest inside one
or more Metric Container options inside the Measurement Request. The or more Metric Container options inside the Measurement Request. The
Start Point then determines the next hop on the route being measured. Start Point then determines the next hop on the route being measured.
If a Hop-by-hop route is being measured (i.e., H = 1), the next hop If a Hop-by-hop route is being measured (i.e., H = 1), the next hop
is determined using the RPLInstanceID, the End Point Address and, if is determined using the RPLInstanceID, the End Point Address and, if
RPLInstanceID is a local value, the Start Point Address fields in the RPLInstanceID is a local value, the Start Point Address fields in the
Measurement Request. If a Source Route is being measured (i.e., H = Measurement Request. If a Source Route is being measured (i.e., H =
0), the Address[0] element inside the Measurement Request contains 0), the Address[0] element inside the Measurement Request contains
the next hop address. The Start Point MUST ensure that the next hop address. The Start Point MUST ensure that
o the next hop address is a unicast address; and o the next hop address is a unicast address; and
o the next hop is on-link; and o the next hop is on-link; and
o the next hop is in the same RPL routing domain as the Start Point; o the next hop is in the same RPL routing domain
[I-D.ietf-roll-terminology] as the Start Point;
failing which the Start Point MUST discard the Measurement Request failing which the Start Point MUST discard the Measurement Request
without sending. Depending on the routing metrics, the Start Point without sending. Depending on the routing metrics, the Start Point
must initiate the routing metric objects inside the Metric Container must initiate the routing metric objects inside the Metric Container
options by including the routing metric values for the first hop on options by including the routing metric values for the first hop on
the route being measured. Finally, the Start Point MUST unicast the the route being measured. Finally, the Start Point MUST unicast the
Measurement Request to the next hop on the route being measured. Measurement Request to the next hop on the route being measured.
The Start Point MUST maintain state for just transmitted Measurement The Start Point MUST maintain state for just transmitted Measurement
Request for a life time duration that is large enough to allow the Request for a life time duration that is large enough to allow the
corresponding Measurement Reply to return. This state consists of corresponding Measurement Reply to return. This state consists of
the RPLInstanceID, the SequenceNo and the End Point Address fields of the RPLInstanceID, the SeqNo and the End Point Address fields of the
the Measurement Request. The life time duration for this state is Measurement Request. The life time duration for this state is
locally determined by the Start Point and may be deployment specific. locally determined by the Start Point and may be deployment specific.
This state expires when the corresponding Measurement Reply is This state expires when the corresponding Measurement Reply is
received or when the life time is over, whichever occurs first. received or when the life time is over, whichever occurs first.
Failure to receive the corresponding Measurement Reply before the Failure to receive the corresponding Measurement Reply before the
expiry of a state may occur due to a number of reasons including expiry of a state may occur due to a number of reasons including
unwillingness on part of an Intermediate Point or the End Point to unwillingness on part of an Intermediate Point or the End Point to
process the Measurement Request. The Start Point should take such process the Measurement Request. The Start Point should take such
possibilities in account when deciding whether to generate another possibilities in account when deciding whether to generate another
Measurement Request for this route. The Start Point MUST discard a Measurement Request for this route. The Start Point MUST discard a
received Measurement Reply with no further processing if the state received Measurement Reply with no further processing if the state
skipping to change at page 12, line 38 skipping to change at page 13, line 28
o Reverse (R): This flag MUST be set to zero. o Reverse (R): This flag MUST be set to zero.
o Back Request (B): This flag MAY be set to one to request the End o Back Request (B): This flag MAY be set to one to request the End
Point to send a Measurement Request to the Start Point. Point to send a Measurement Request to the Start Point.
o Intermediate Reply (I): This flag MAY be set to one if the Start o Intermediate Reply (I): This flag MAY be set to one if the Start
Point expects an Intermediate Point to know the values of the Point expects an Intermediate Point to know the values of the
routing metrics being measured for the remainder of the route. routing metrics being measured for the remainder of the route.
o SequenceNo: Assigned by the Start Point so that it can uniquely o SeqNo: Assigned by the Start Point so that it can uniquely
identify the Measurement Request and the corresponding Measurement identify the Measurement Request and the corresponding Measurement
Reply. Reply.
o Num: This field MUST be set to zero. o Num: This field MUST be set to zero.
o Index: This field MUST be set to zero. o Index: This field MUST be set to zero.
o Start Point Address: MUST be set to a unicast IPv6 address of the o Start Point Address: MUST be set to a unicast global/unique-local
Start Point after eliding Compr number of prefix octets. IPv6 address of the Start Point after eliding Compr number of
prefix octets.
o End Point Address: MUST be set to a unicast IPv6 address of the o End Point Address: MUST be set to a unicast global/unique-local
End Point after eliding Compr number of prefix octets. IPv6 address of the End Point after eliding Compr number of prefix
octets.
4.2. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With 4.2. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With
Route Accumulation Off Route Accumulation Off
If a Hop-by-hop Route with a local RPLInstanceID is being measured If a Hop-by-hop Route with a local RPLInstanceID is being measured
and the Start Point does not want the MO to accumulate a Source Route and the Start Point does not want the MO to accumulate a Source Route
for the End Point's use, the MO MUST NOT contain the Address vector for the End Point's use, the MO MUST NOT contain the Address vector
and various MO fields MUST be set in the following manner: and various MO fields MUST be set in the following manner:
o RPLInstanceID: MUST be set to the RPLInstanceID of the route being o RPLInstanceID: MUST be set to the RPLInstanceID of the route being
skipping to change at page 13, line 34 skipping to change at page 14, line 26
o Accumulate Route (A): This flag MUST be set to zero. o Accumulate Route (A): This flag MUST be set to zero.
o Reverse (R): This flag MUST be set to zero. o Reverse (R): This flag MUST be set to zero.
o Back Request (B): This flag MAY be set to one to request the End o Back Request (B): This flag MAY be set to one to request the End
Point to send a Measurement Request to the Start Point. Point to send a Measurement Request to the Start Point.
o Intermediate Reply (I): This flag MUST be set to zero. o Intermediate Reply (I): This flag MUST be set to zero.
o SequenceNo: Assigned by the Start Point so that it can uniquely o SeqNo: Assigned by the Start Point so that it can uniquely
identify the Measurement Request and the corresponding Measurement identify the Measurement Request and the corresponding Measurement
Reply. Reply.
o Num: This field MUST be set to zero. o Num: This field MUST be set to zero.
o Index: This field MUST be set to zero. o Index: This field MUST be set to zero.
o Start Point Address: This field MUST contain the DODAGID value o Start Point Address: This field MUST contain the DODAGID value
(after eliding Compr number of prefix octets) associated with the (after eliding Compr number of prefix octets) associated with the
route being measured. route being measured. This DODAGID MUST also be a global or
unique local IPv6 address of the Start Point.
o End Point Address: MUST be set to a unicast IPv6 address of the o End Point Address: MUST be set to a unicast global or unique local
End Point after eliding Compr number of prefix octets. IPv6 address of the End Point after eliding Compr number of prefix
octets.
4.3. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With 4.3. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With
Route Accumulation On Route Accumulation On
If a Hop-by-hop Route with a local RPLInstanceID is being measured If a Hop-by-hop Route with a local RPLInstanceID is being measured
and the Start Point desires the MO to accumulate a Source Route for and the Start Point desires the MO to accumulate a Source Route for
the End Point to send the Measurement Reply message back, the MO MUST the End Point to send the Measurement Reply message back, the MO MUST
contain a suitably-sized Address vector and various MO fields MUST be contain a suitably-sized Address vector and various MO fields MUST be
set in the following manner: set in the following manner:
skipping to change at page 14, line 35 skipping to change at page 15, line 26
o Accumulate Route (A): 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 Reverse (R): This flag MUST be set to zero.
o Back Request (B): This flag MAY be set to one to request the End o Back Request (B): This flag MAY be set to one to request the End
Point to send a Measurement Request to the Start Point. Point to send a Measurement Request to the Start Point.
o Intermediate Reply (I): This flag MUST be set to zero. o Intermediate Reply (I): This flag MUST be set to zero.
o SequenceNo: Assigned by the Start Point so that it can uniquely o SeqNo: Assigned by the Start Point so that it can uniquely
identify the Measurement Request and the corresponding Measurement identify the Measurement Request and the corresponding Measurement
Reply. Reply.
o Num: This field MUST specify the number of address elements, each o Num: This field MUST specify the number of address elements, each
(16 - Compr) octets in size, that can fit inside the Address (16 - Compr) octets in size, that can fit inside the Address
vector. vector.
o Index: This field MUST be set to zero to indicate the position in o Index: This field MUST be set to zero to indicate the position in
the Address vector where the next hop must store its IPv6 address. the Address vector where the next hop must store its IPv6 address.
o Start Point Address: This field MUST contain the DODAGID value o Start Point Address: This field MUST contain the DODAGID value
(after eliding Compr number of prefix octets) associated with the (after eliding Compr number of prefix octets) associated with the
route being measured. route being measured. This DODAGID MUST also be a global or
unique local IPv6 address of the Start Point.
o End Point Address: MUST be set to a unicast IPv6 address of the o End Point Address: MUST be set to a unicast global or unique local
End Point after eliding Compr number of prefix octets. IPv6 address of the End Point after eliding Compr number of prefix
octets.
o Address vector: The Address vector must be large enough to o Address vector: The Address vector must be large enough to
accomodate a complete Source Route from the End Point to the Start accomodate a complete Source Route from the End Point to the Start
Point. All the bits in the Address vector field MUST be set to Point. All the bits in the Address vector field MUST be set to
zero. zero.
4.4. When Measuring A Source Route 4.4. When Measuring A Source Route
If a Source Route is being measured, the Start Point MUST set various If a Source Route is being measured, the Start Point MUST set various
MO fields in the following manner: MO fields in the following manner:
o RPLInstanceID: MUST be set to the binary value 10000000. o RPLInstanceID: This field does not have any significance when a
Source Route is being measured and hence can be set to any value.
o Compr: MUST be set to specify the number of prefix octets that are o Compr: MUST be set to specify the number of prefix octets that are
elided from the IPv6 addresses in Start Point/End Point Address elided from the IPv6 addresses in Start Point/End Point Address
fields and the Address vector. fields and the Address vector.
o Type (T): MUST be set to one since the MO represents a Measurement o Type (T): MUST be set to one since the MO represents a Measurement
Request. Request.
o Hop-by-hop (H): MUST be set to zero. o Hop-by-hop (H): MUST be set to zero.
skipping to change at page 15, line 38 skipping to change at page 16, line 34
o Reverse (R): This flag SHOULD be set to one if the Source Route in o Reverse (R): This flag SHOULD be set to one if the Source Route in
the Address vector can be reversed and used by the End Point to the Address vector can be reversed and used by the End Point to
send the Measurement Reply message back to the Start Point. send the Measurement Reply message back to the Start Point.
Otherwise, this flag MUST be set to zero. Otherwise, this flag MUST be set to zero.
o Back Request (B): This flag MAY be set to one to request the End o Back Request (B): This flag MAY be set to one to request the End
Point to send a Measurement Request to the Start Point. Point to send a Measurement Request to the Start Point.
o Intermediate Reply (I): This flag MUST be set to zero. o Intermediate Reply (I): This flag MUST be set to zero.
o SequenceNo: Assigned by the Start Point so that it can uniquely o SeqNo: Assigned by the Start Point so that it can uniquely
identify the Measurement Request and the corresponding Measurement identify the Measurement Request and the corresponding Measurement
Reply. Reply.
o Num: This field MUST specify the number of address elements, each o Num: This field MUST specify the number of address elements, each
(16 - Compr) octets in size, inside the Address vector. (16 - Compr) octets in size, inside the Address vector.
o Index: This field MUST be set to zero to indicate the position in o Index: This field MUST be set to zero to indicate the position in
the Address vector of the next hop on the route. the Address vector of the next hop on the route.
o Start Point Address: MUST be set to a unicast IPv6 address of the o Start Point Address: MUST be set to a unicast global or unique
Start Point after eliding Compr number of prefix octets. local IPv6 address of the Start Point after eliding Compr number
of prefix octets.
o End Point Address: MUST be set to a unicast IPv6 address of the o End Point Address: MUST be set to a unicast global or unique local
End Point after eliding Compr number of prefix octets. IPv6 address of the End Point after eliding Compr number of prefix
octets.
o Address vector: o Address vector:
* The Address vector MUST contain a complete Source Route from * The Address vector MUST contain a complete Source Route from
the Start Point to the End Point (excluding the Start Point and the Start Point to the End Point (excluding the Start Point and
the End Point). the End Point).
* The IPv6 addresses (with Compr prefix octets elided) in the * Each address appearing in the Address vector MUST be a unicast
Address vector MUST be reachable in the Forward direction. global or unique local IPv6 address. Further, each address
MUST have the same prefix as the Start Point Address and the
End Point Address. This prefix, whose length in octets is
specified in the Compr field, MUST be elided from each address.
* If the R flag is set to one, the IPv6 addresses (with Compr * The IPv6 addresses in the Address vector MUST be reachable in
prefix octets elided) in the Address vector MUST also be the Forward direction.
reachable in the Reverse direction.
* Each address appearing in the Address vector MUST be a unicast * If the R flag is set to one, the IPv6 addresses in the Address
address. vector MUST also be reachable in the Reverse direction.
5. Processing a Measurement Request at an Intermediate Point 5. Processing a Measurement Request at an Intermediate Point
A router (an Intermediate Point or the End Point) MAY discard a A router (an Intermediate Point or the End Point) MAY discard a
received MO with no processing to meet any policy-related goal. Such 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 policy goals may include the need to reduce the router's CPU load or
to enhance its battery life or to prevent misuse of this mechanism by to enhance its battery life or to prevent misuse of this mechanism by
unauthorized nodes. unauthorized nodes.
A router MUST discard a received MO with no further processing if the A router MUST discard a received MO with no further processing if the
skipping to change at page 16, line 42 skipping to change at page 17, line 44
IPv6 addresses in the LLN to be. IPv6 addresses in the LLN to be.
On receiving an MO, if a router chooses to process the packet 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 further, it MUST check if one of its IPv6 addresses is listed as
either the Start Point or the End Point Address. If neither, the either the Start Point or the End Point Address. If neither, the
router considers itself an Intermediate Point and MUST process the router considers itself an Intermediate Point and MUST process the
received MO in the following manner. received MO in the following manner.
An Intermediate Point MUST discard the packet with no further An Intermediate Point MUST discard the packet with no further
processing if the received MO is not a Measurement Request (i.e., T = processing if the received MO is not a Measurement Request (i.e., T =
0). 0). This is because the End Point unicasts a Measurement Reply
directly to the Start Point. So, the Intermediate Point treats a
transiting Measurement Reply as a data packet and not an RPL control
message.
Next, the Intermediate Point determines the type of the route being Next, the Intermediate Point determines the type of the route being
measured (by checking the values of the H flag and the RPLInstanceID measured (by checking the values of the H flag and the RPLInstanceID
field) and processes the received MO accordingly in the manner field) and processes the received MO accordingly in the manner
specified next. specified next.
5.1. When Measuring A Hop-by-hop Route with a Global RPLInstanceID 5.1. When Measuring A Hop-by-hop Route with a Global RPLInstanceID
If a Hop-by-hop Route with a global RPLInstanceID is being measured If a Hop-by-hop Route with a global RPLInstanceID is being measured
(i.e. H = 1 and RPLInstanceID has a global value), the Intermediate (i.e. H = 1 and RPLInstanceID has a global value), the Intermediate
skipping to change at page 18, line 13 skipping to change at page 19, line 13
Measurement Reply back to the Start Point. Measurement Reply back to the Start Point.
* Insert a new Address vector inside the Measurement Request and * Insert a new Address vector inside the Measurement Request and
specify a Source Route to the End Point inside the Address specify a Source Route to the End Point inside the Address
vector as per the following rules: vector as per the following rules:
+ The Address vector MUST contain a complete route from the + The Address vector MUST contain a complete route from the
router to the End Point (excluding the router and the End router to the End Point (excluding the router and the End
Point); Point);
+ The IPv6 addresses (with Compr prefix octets elided) in the
Address vector MUST be reachable in the Forward direction;
+ Each address appearing in the Address vector MUST be a + Each address appearing in the Address vector MUST be a
unicast address. unicast global or unique local IPv6 address. Further, each
address MUST have the same prefix as the Start Point Address
and the End Point Address. This prefix, whose length in
octets is specified in the Compr field, MUST be elided from
each address.
+ The IPv6 addresses in the Address vector MUST be reachable
in the Forward direction;
If the router cannot insert an Address vector satisfying the
rules mentioned above, it MUST discard the Measurement Request
with no further processing and MAY send an ICMPv6 Destination
Unreachable (with Code 0 - No Route To Destination) error
message [RFC4443] to the Start Point.
* Specify in the Num field the number of address elements in the * Specify in the Num field the number of address elements in the
Address vector. Address vector.
* Set the Index field to zero to indicate the position in the * Set the Index field to zero to indicate the position in the
Address vector of the next hop on the route. Thus, Address[0] Address vector of the next hop on the route. Thus, Address[0]
element contains the address of the next hop on the route. element contains the address of the next hop on the route.
The Intermediate Point MUST then complete the processing of the The Intermediate Point MUST then complete the processing of the
received Measurement Request as specified in Section 5.5. received Measurement Request as specified in Section 5.5.
skipping to change at page 19, line 9 skipping to change at page 20, line 17
it MUST discard the Measurement Request with no further processing it MUST discard the Measurement Request with no further processing
and MAY send an ICMPv6 Destination Unreachable (with Code 0 - No and MAY send an ICMPv6 Destination Unreachable (with Code 0 - No
Route To Destination) error message [RFC4443] to the Start Point. Route To Destination) error message [RFC4443] to the Start Point.
Otherwise, the Intermediate Point MUST complete the processing of the Otherwise, the Intermediate Point MUST complete the processing of the
received Measurement Request as specified in Section 5.5. received Measurement Request as specified in Section 5.5.
5.3. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With 5.3. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With
Route Accumulation On Route Accumulation On
If a Hop-by-hop Route with a local RPLInstanceID is being measured If a Hop-by-hop Route with a local RPLInstanceID is being measured
and the route accumulation in on (i.e., H = 1, RPLInstanceID has a and the route accumulation is on (i.e., H = 1, RPLInstanceID has a
local value, A = 1), the Intermediate Point MUST process the received local value, A = 1), the Intermediate Point MUST process the received
Measurement Request in the following manner. Measurement Request in the following manner.
If the Num field inside the received Measurement Request is set to If the Num field inside the received Measurement Request is set to
zero, thereby implying that an Address vector is not present, the zero, thereby implying that an Address vector is not present, the
Intermediate Point MUST discard the received message with no further Intermediate Point MUST discard the received message with no further
processing. processing.
The Intermediate Point MUST then determine the next hop on the route The Intermediate Point MUST then determine the next hop on the route
being measured using the RPLInstanceID, the End Point Address and the being measured using the RPLInstanceID, the End Point Address and the
Start Point Address (which represents the DODAGID of the route being Start Point Address (which represents the DODAGID of the route being
measured). If the Intermediate Point can not determine the next hop, measured). If the Intermediate Point can not determine the next hop,
it MUST discard the Measurement Request with no further processing it MUST discard the Measurement Request with no further processing
and MAY send an ICMPv6 Destination Unreachable (with Code 0 - No and MAY send an ICMPv6 Destination Unreachable (with Code 0 - No
Route To Destination) error message [RFC4443] to the Start Point. If Route To Destination) error message [RFC4443] to the Start Point. If
the index field has value Num - 1 and the next hop is not same as the the index field has value Num - 1 and the next hop is not same as the
End Point, the Intermediate Point MUST drop the received Measurement End Point, the Intermediate Point MUST drop the received Measurement
Request with no further processing. In this case, the next hop would Request with no further processing. In this case, the next hop would
have no space left in the Address vector to store its address. have no space left in the Address vector to store its address.
Otherwise, the router MUST store one of its unicast IPv6 addresses Otherwise, the router MUST store one of its IPv6 addresses at
(after eliding Compr prefix octets) at location Address[Index] and location Address[Index] and then increment the Index field. The IPv6
then increment the Index field. The IPv6 address added to the address added to the Address vector MUST have the following
Address vector MUST be reachable in the Reverse direction. properties:
o This address MUST be a unicast global or unique local address.
o This address MUST have the same prefix as the Start Point Address
and the End Point Address. This prefix, whose length in octets is
specified in the Compr field, MUST be elided before the address is
added to the Address vector.
o This address MUST be reachable in the Reverse direction.
If the router does not have an IPv6 address that satisfies the
properties mentioned above, it MUST discard the Measurement Request
with no further processing.
The Intermediate Point MUST then complete the processing of the The Intermediate Point MUST then complete the processing of the
received Measurement Request as specified in Section 5.5. received Measurement Request as specified in Section 5.5.
5.4. When Measuring A Source Route 5.4. When Measuring A Source Route
If a Source Route is being measured (i.e., H = 0), the Intermediate If a Source Route is being measured (i.e., H = 0), the Intermediate
Point MUST process the received Measurement Request in the following Point MUST process the received Measurement Request in the following
manner. manner.
If the Num field inside the received Measurement Request is set to If the Num field inside the received Measurement Request is set to
zero, thereby implying that an Address vector is not present, the zero, thereby implying that an Address vector is not present, the
Intermediate Point MUST discard the received message with no further Intermediate Point MUST discard the received message with no further
processing. processing.
The Intermediate Point MUST verify that the Address[Index] element The Intermediate Point MUST verify that the Address[Index] element
lists one of its unicast IPv6 addresses, failing which it MUST lists one of its unicast global or unique local IPv6 addresses (minus
discard the Measurement Request with no further processing. The the prefix whose length in octets is specified in the Compr field),
Intermediate Point MUST then increment the Index field and use the failing which it MUST discard the Measurement Request with no further
Address[Index] element as the next hop (unless Index value is now processing. The Intermediate Point MUST then increment the Index
Num). If the Index value is now Num, the Intermediate Point MUST use field and use the Address[Index] element as the next hop (unless
the End Point Address as the next hop. Index value is now Num). If the Index value is now Num, the
Intermediate Point MUST use the End Point Address as the next hop.
The Intermediate Point MUST then complete the processing of the The Intermediate Point MUST then complete the processing of the
received Measurement Request as specified in Section 5.5. received Measurement Request as specified in Section 5.5.
5.5. Final Processing 5.5. Final Processing
The Intermediate Point MUST drop the received Measurement Request The Intermediate Point MUST drop the received Measurement Request
with no further processing: with no further processing:
o If the next hop address is not a unicast address; or o If the next hop address is not a unicast address; or
skipping to change at page 20, line 38 skipping to change at page 22, line 13
An Intermediate Point MUST drop the Measurement Request with no An Intermediate Point MUST drop the Measurement Request with no
further processing if it cannot update a routing metric object further processing if it cannot update a routing metric object
specified inside the Metric Container. specified inside the Metric Container.
Finally, the Intermediate Point MUST unicast the Measurement Request Finally, the Intermediate Point MUST unicast the Measurement Request
to the next hop. to the next hop.
6. Processing a Measurement Request at the End Point 6. Processing a Measurement Request at the End Point
On receiving an MO, if a router chooses to process the message On receiving an MO, if a router chooses to process the message
further and finds one of its unicast IPv6 addresses listed as the End further and finds one of its unicast global or unique local IPv6
Point Address, the router considers itself the End Point and MUST addresses (minus the prefix whose length in octets is specified in
process the received MO in the following manner. the Compr field) listed as the End Point Address, the router
considers itself the End Point and MUST process the received MO in
the following manner.
The End Point MUST discard the received message with no further The End Point MUST discard the received message with no further
processing if it is not a Measurement Request (i.e., T = 0). processing if it is not a Measurement Request (i.e., T = 0).
If the received Measurement Request traveled on a Hop-by-hop Route If the received Measurement Request traveled on a Hop-by-hop Route
with a local RPLInstanceID with route accumulation on (i.e., H = 1, with a local RPLInstanceID with route accumulation on (i.e., H = 1,
RPLInstanceID has a local value and A = 1), elements Address[0] RPLInstanceID has a local value and A = 1), elements Address[0]
through Address[Index - 1] in the Address vector contain a complete through Address[Index - 1] in the Address vector contain a complete
Source Route from the Start Point to the End Point (excluding the Source Route from the Start Point to the End Point, which the End
Start Point and the End Point), which the End Point MAY use, after Point MAY use, after reversal, to reach the Start Point. Note that
reversal, to reach the Start Point. the Source Route in the Address vector does not include the Start
Point and the End Point addresses and the individual addresses do not
include the common prefix whose length in octets is specified in the
Compr field.
If the received Measurement Request traveled on a Source Route and If the received Measurement Request traveled on a Source Route and
the Reverse flag is set to one (i.e., H = 0, R = 1), elements the Reverse flag is set to one (i.e., H = 0, R = 1), elements
Address[0] through Address[Num - 1] in the Address vector contain a Address[0] through Address[Num - 1] in the Address vector contain a
complete Source Route from the Start Point to the End Point complete Source Route from the Start Point to the End Point, which
(excluding the Start Point and the End Point), which the End Point the End Point MAY use, after reversal, to reach the Start Point.
MAY use, after reversal, to reach the Start Point. Again, the Source Route in the Address vector does not include the
Start Point and the End Point addresses and the individual addresses
do not include the common prefix whose length in octets is specified
in the Compr field.
The End Point MUST update the routing metric objects in the Metric The End Point MUST update the routing metric objects in the Metric
Container options if required and MAY note the measured values for Container options if required and MAY note the measured values for
the complete route (especially, if the received Measurement Request the complete route (especially, if the received Measurement Request
is likely a response to an earlier Measurement Request that the End is likely a response to an earlier Measurement Request that the End
Point had sent to the Start Point with B flag set to one). Point had sent to the Start Point with B flag set to one).
The End Point MUST generate a Measurement Reply message as specified The End Point MUST generate a Measurement Reply message as specified
in Section 6.1. If the B flag is set to one in the received in Section 6.1. If the B flag is set to one in the received
Measurement Request, the End Point SHOULD generate a new Measurement Measurement Request, the End Point SHOULD generate a new Measurement
Request to measure the cost of its current (or the most preferred) Request to measure the cost of its current (or the most preferred)
route to the Start Point. The routing metrics used in the new route to the Start Point. The routing metrics used in the new
Measurement Request MUST include the routing metrics specified in the Measurement Request MUST include the routing metrics specified in the
received Measurement Request. received Measurement Request.
6.1. Generating the Measurement Reply 6.1. Generating the Measurement Reply
A Measurement Reply MUST have the Type (T) flag set to zero and need A Measurement Reply MUST have the Type (T) flag set to zero and need
not contain the Address vector. The following fields inside a not contain the Address vector. The following fields inside a
Measurement Reply MUST have the same values as they had inside the Measurement Reply MUST have the same values as they had inside the
corresponding Measurement Request: RPLInstanceID, Compr, SequenceNo, corresponding Measurement Request: RPLInstanceID, Compr, SeqNo, Start
Start Point Address, End Point Address and Metric Container Point Address, End Point Address and Metric Container Option(s). The
Option(s). The remaining fields inside a Measurement Reply may have remaining fields inside a Measurement Reply may have any value and
any value and MUST be ignored on reception at the Start Point; the MUST be ignored on reception at the Start Point; the received
received Measurement Request can, therefore, trivially be converted Measurement Request can, therefore, trivially be converted into a
into a Measurement Reply by setting the Type (T) flag to zero. Measurement Reply by setting the Type (T) flag to zero.
A Measurement Reply MUST be unicast back to the Start Point: A Measurement Reply MUST be unicast back to the Start Point:
o If the Measurement Request traveled along a global DAG, identified o If the Measurement Request traveled along a global DAG, identified
by the RPLInstanceID field, the Measurement Reply MAY be unicast by the RPLInstanceID field, the Measurement Reply MAY be unicast
back to the Start Point along the same DAG. back to the Start Point along the same DAG.
o If the Measurement Request traveled along a Hop-by-hop Route with o If the Measurement Request traveled along a Hop-by-hop Route with
a local RPLInstanceID and accumulated a Source Route from the a local RPLInstanceID and accumulated a Source Route from the
Start Point to the End Point, this Source Route MAY be used after Start Point to the End Point, this Source Route MAY be used after
skipping to change at page 22, line 30 skipping to change at page 24, line 14
Container to evaluate the metrics for the measured P2P route. If a Container to evaluate the metrics for the measured P2P route. If a
routing metric object contains local metric values recorded by routing metric object contains local metric values recorded by
routers on the route, the Start Point can make use of these local routers on the route, the Start Point can make use of these local
values by aggregating them into an end-to-end metric according to the values by aggregating them into an end-to-end metric according to the
aggregation rules for the specific metric. A Start Point is then aggregation rules for the specific metric. A Start Point is then
free to interpret the metrics for the route according to its local free to interpret the metrics for the route according to its local
policy. policy.
8. Security Considerations 8. Security Considerations
The mechanism defined in this document can potentially be used by a In general, the security considerations for the route measurement
compromised router to send bogus Measurement Requests to arbitrary mechanism described in this document are similar to the ones for RPL
End Points. If sufficient Measurement Requests are sent, then it may (as described in Section 19 of [RFC6550]). Sections 6.1 and 10 of
cause CPU overload in the routers in the network, drain their RPL specification [RFC6550] describe RPL's security framework that
batteries and cause traffic congestion in the network. Note that provides data confidentiality, authentication, replay protection and
some of these problems would occur even if the compromised router delay protection services. This security framework is applicable to
were to generate bogus data traffic to arbitrary destinations. the route measurement mechanism described here as well after taking
in account the constraints specified in Section 3.2.
This document requires all routers participating in a secure
invocation of the route measurement process to use the Security
Configuration decided by the Start Point. The intention is to avoid
compromising the overall security of the route measurement due to
some routers using a weaker Security Configuration. A router is
allowed to participate in a "secure" route measurement only if it can
support the Security Configuration in use, which also specifies the
key in use. It does not matter whether the key is pre-installed or
dynamically acquired after proper authentication. The router must
have the key in use before it can process or generate Secure MO
messages. Hence, from the perspective of the route measurement
mechanism, there is no distinction between the "preinstalled" and
"authenticated" security modes described in RPL specification
[RFC6550]. Ofcourse if a compromised router has the key being used,
it could cause the route measurement to fail, or worse, insert wrong
information in Secure MO messages.
A rogue router acting as the Start Point could use the route
measurement mechanism defined in this document to measure routes from
itself to other routers and thus find out key information about the
LLN, e.g., the topological features of the LLN (such as the identity
of the key routers in the topology) or the remaining energy levels
[RFC6551] in the routers. This information can potentially be used
to attack the LLN. A rogue router could also use this mechanism to
send bogus Measurement Requests to arbitrary End Points. If
sufficient Measurement Requests are sent, then it may cause CPU
overload in the routers in the network, drain their batteries and
cause traffic congestion in the network. Note that some of these
problems would occur even if the compromised router were to generate
bogus data traffic to arbitrary destinations.
To protect against such misuse, this document allows RPL routers
implementing this mechanism to not process MO messages (or process
such messages selectively) based on a local policy. For example, an
LLN deployment might require the use of Secure MO messages generated
using a key that could be obtained only after proper authentication.
Note that this document requires an LLN deployment to support Secure
MO messages so that such policies can be enforced where considered
essential.
Since a Measurement Request can travel along a Source Route specified Since a Measurement Request can travel along a Source Route specified
in the Address vector, some of the security concerns that led to the 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 deprecation of Type 0 routing header [RFC5095] may be valid here. To
address such concerns, the mechanism described in this document address such concerns, the mechanism described in this document
includes several remedies: includes several remedies:
o This document requires that a route inserted inside the Address o This document requires that a route inserted inside the Address
vector must be a strict Source Route and must not include any vector must be a strict Source Route and must not include any
multicast addresses. multicast addresses.
skipping to change at page 23, line 13 skipping to change at page 25, line 37
boundaries of the RPL routing domain where it originated. A boundaries of the RPL routing domain where it originated. A
router must not forward a received MO message further if the next router must not forward a received MO message further if the next
hop belongs to a different RPL routing domain. Hence, any hop belongs to a different RPL routing domain. Hence, any
security problems associated with the mechanism would be limited security problems associated with the mechanism would be limited
to one RPL routing domain. to one RPL routing domain.
o This document requires that a router must drop a received o This document requires that a router must drop a received
Measurement Request if the next hop address is not on-link or if Measurement Request if the next hop address is not on-link or if
it is not a unicast address. it is not a unicast address.
The measurement mechanism described in this document may potentially
be used by a rogue router to measure routes from itself to other
routers and thus find out key information about the LLN, e.g., the
topological features of the LLN (such as the identity of the key
routers in the topology) or the remaining energy levels [RFC6551] in
the routers. This information can potentially be used to attack the
LLN. To protect against such misuse, this document allows RPL
routers implementing this mechanism to not process MO messages (or
process such messages selectively) based on a local policy. Further,
an LLN deployment is required to support Secure MO (Section 3.2)
messages to have the ability to invoke RPL-provided security
mechanisms and prevent misuse of the measurement mechanism by
unauthorized routers.
9. IANA Considerations 9. IANA Considerations
This document defines two new RPL messages: This document defines two new RPL messages:
o "Measurement Object" (see Section 3.1), assigned a value TBD1 from o "Measurement Object" (see Section 3.1), assigned a value TBD1 from
the "RPL Control Codes" space [to be removed upon publication: the "RPL Control Codes" space [to be removed upon publication:
http://www.iana.org/assignments/rpl/rpl.xml#control-codes] http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
[RFC6550]. IANA is requested to allocate TBD1 from the range [RFC6550]. IANA is requested to allocate TBD1 from the range
0x00-0x7F to indicate a message without security enabled. The 0x00-0x7F to indicate a message without security enabled. The
string TBD1 in this document should be replaced by the allocated string TBD1 in this document should be replaced by the allocated
skipping to change at page 24, line 16 skipping to change at page 26, line 25
| Code | Description | Reference | | Code | Description | Reference |
+------+---------------------------+---------------+ +------+---------------------------+---------------+
| TBD1 | Measurement Object | This document | | TBD1 | Measurement Object | This document |
| TBD2 | Secure Measurement Object | This document | | TBD2 | Secure Measurement Object | This document |
+------+---------------------------+---------------+ +------+---------------------------+---------------+
RPL Control Codes RPL Control Codes
10. Acknowledgements 10. Acknowledgements
Authors gratefully acknowledge the contributions of Adrian Farrel, Authors gratefully acknowledge the contributions of Ralph Droms,
Joel Halpern, Matthias Philipp, Pascal Thubert, Richard Kelsey and Adrian Farrel, Joel Halpern, Matthias Philipp, Pascal Thubert,
Zach Shelby in the development of this document. Richard Kelsey and Zach Shelby in the development of this document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-roll-p2p-rpl] [I-D.ietf-roll-p2p-rpl]
Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J.
Martocci, "Reactive Discovery of Point-to-Point Routes in Martocci, "Reactive Discovery of Point-to-Point Routes in
Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-16 Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-17
(work in progress), February 2013. (work in progress), March 2013.
[I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-12 (work in
progress), March 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006. Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
 End of changes. 57 change blocks. 
201 lines changed or deleted 313 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/