draft-ietf-roll-p2p-measurement-06.txt   draft-ietf-roll-p2p-measurement-07.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: March 21, 2013 E. Baccelli Expires: June 27, 2013 E. Baccelli
INRIA INRIA
A. Brandt A. Brandt
Sigma Designs Sigma Designs
J. Martocci J. Martocci
Johnson Controls Johnson Controls
September 17, 2012 December 24, 2012
A Mechanism to Measure the Quality of a Point-to-point Route in a Low A Mechanism to Measure the Routing Metrics along a Point-to-point Route
Power and Lossy Network in a Low Power and Lossy Network
draft-ietf-roll-p2p-measurement-06 draft-ietf-roll-p2p-measurement-07
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 quality of an existing route towards another RPL router measure the aggregated values of given routing metrics along an
in a low power and lossy network, thereby allowing the router to existing route towards another RPL router in a low power and lossy
decide if it wants to initiate the discovery of a better route. network, thereby allowing the router to decide if it wants to
initiate the discovery of a better route.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 March 21, 2013. This Internet-Draft will expire on June 27, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 17 skipping to change at page 2, line 18
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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) . . . . . . . . . . . . . . . . . 5 3. The Measurement Object (MO) . . . . . . . . . . . . . . . . . 5
3.1. Format of the base MO . . . . . . . . . . . . . . . . . . 5 3.1. Format of the base MO . . . . . . . . . . . . . . . . . . 6
3.2. Secure MO . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Secure MO . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Originating a Measurement Request . . . . . . . . . . . . . . 9 4. Originating a Measurement Request . . . . . . . . . . . . . . 10
4.1. To Measure A Hop-by-hop Route with a Global 4.1. When Measuring A Hop-by-hop Route with a Global
RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 10 RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 11
4.2. To Measure A Hop-by-hop Route with a Local 4.2. When Measuring A Hop-by-hop Route with a Local
RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 10 RPLInstanceID With Route Accumulation Off . . . . . . . . 12
4.3. To Measure A Source Route . . . . . . . . . . . . . . . . 11 4.3. When Measuring A Hop-by-hop Route with a Local
5. Processing a Measurement Request at an Intermediate Router . . 12 RPLInstanceID With Route Accumulation On . . . . . . . . . 13
5.1. Determining Next Hop For An MO Measuring A Source Route . 14 4.4. When Measuring A Source Route . . . . . . . . . . . . . . 14
5.2. Determining Next Hop For An MO Measuring A Hop-by-hop 5. Processing a Measurement Request at an Intermediate Point . . 15
Route . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. When Measuring A Hop-by-hop Route with a Global
6. Processing a Measurement Request at the Target . . . . . . . . 15 RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 16
7. Processing a Measurement Reply at the Origin . . . . . . . . . 16 5.2. When Measuring A Hop-by-hop Route with a Local
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 RPLInstanceID With Route Accumulation Off . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 5.3. When Measuring A Hop-by-hop Route with a Local
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 RPLInstanceID With Route Accumulation On . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.4. When Measuring A Source Route . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 5.5. Final Processing . . . . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . . 18 6. Processing a Measurement Request at the End Point . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 6.1. Generating the Measurement Reply . . . . . . . . . . . . . 20
7. Processing a Measurement Reply at the Start Point . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
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]. RPL [RFC6550], the IPv6 Routing applications [RFC5826][RFC5867]. The IPv6 Routing Protocol for LLNs
Protocol for LLNs, 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
skipping to change at page 4, line 6 skipping to change at page 4, line 6
discovery. Note that it is important that the routing constraints discovery. Note that it is important that the routing constraints
are not overly strict; otherwise the P2P-RPL route discovery may fail are not overly strict; otherwise the P2P-RPL route discovery may fail
even though a route, much better than the one currently being used, even though a route, much better than the one currently being used,
exists. exists.
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 the routing metrics along an measure the aggregated values of the routing metrics along an
existing route to another RPL router in an LLN, thereby allowing the existing route to another RPL router in an LLN, thereby allowing the
router to decide if it wants to discover a better route using P2P-RPL router to decide if it wants to discover a better route using P2P-RPL
and determine the routing constraints to be used for this purpose. and determine the routing constraints to be used for this purpose.
Thus, the utility of this mechanism is dependent on the existence of
P2P-RPL, which is targeting publication as an Experimental RFC. It
makes sense, therefore, for this document also to target publication
as an Experimental RFC. As more operational experience is gained
using P2P-RPL, it is hoped that the mechanism described in this
document will also be used, and feedback will be provided to the ROLL
working group on the utility and benefits of this document.
1.1. Terminology 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].
Additionally, this document uses terminology from [RFC6550] and This document uses terminology from [RFC6550] and
[I-D.ietf-roll-p2p-rpl]. The following terms, originally defined in [I-D.ietf-roll-p2p-rpl]. Additionally, this document defines the
[I-D.ietf-roll-p2p-rpl], are redefined in the following manner. following terms.
Origin: The Origin refers to the RPL router that initiates the Start Point: The Start Point refers to the RPL router that initiates
measurement process defined in this document and is the start point the measurement process defined in this document and is the start
of the P2P route being measured. point of the P2P route being measured.
Target: The Target refers to the RPL router at the end point of the End Point: The End Point refers to the RPL router at the end point of
P2P route being measured. the P2P route being measured.
Intermediate Router: An RPL router, other than the Origin and the Intermediate Point: An RPL router, other than the Start Point and the
Target, on the P2P route being measured. End Point, on the P2P route being measured.
The following terms, already defined in [I-D.ietf-roll-p2p-rpl], have
been redefined in this document in the following manner.
Forward direction: The direction from the Start Point to the End
Point.
Backward direction: The direction from the End Point to the Start
Point.
2. Overview 2. Overview
The mechanism described in this document can be used by an Origin in The mechanism described in this document can be used by a Start Point
an LLN to measure the aggregated values of some routing metrics along in an LLN to measure the aggregated values of selected routing
a P2P route to a Target within the LLN. The route is measured in the metrics along a P2P route to an End Point within the LLN. The route
direction from the Origin to the Target. Such a route could be a is measured in the Forward direction. Such a route could be a Source
source route or a hop-by-hop route established using RPL [RFC6550] or Route [I-D.ietf-roll-p2p-rpl] or a Hop-by-hop Route
P2P-RPL [I-D.ietf-roll-p2p-rpl]. The Origin decides what metrics to
measure and sends a Measurement Request message, carrying the desired [I-D.ietf-roll-p2p-rpl] established using RPL [RFC6550] or P2P-RPL
routing metric objects, along the route. On receiving a Measurement [I-D.ietf-roll-p2p-rpl]. Such a route could also be a "mixed" route
Request, an Intermediate Router updates the routing metric values with the initial part consisting of hop-by-hop ascent to the root of
inside the message and forwards it to the next hop on the route. a non-storing DAG [RFC6550] and the final part consisting of a
Thus, the Measurement Request accumulates the values of the routing source-routed descent to the End Point. The Start Point decides what
metrics for the complete route as it travels towards the Target. metrics to measure and sends a Measurement Request message, carrying
Upon receiving the Measurement Request, the Target unicasts a the desired routing metric objects, along the route. On receiving a
Measurement Reply message, carrying the accumulated values of the Measurement Request, an Intermediate Point updates the routing metric
routing metrics, back to the Origin. Optionally, the Origin may values inside the message and forwards it to the next hop on the
allow an Intermediate Router to generate the Measurement Reply if it route. Thus, the Measurement Request accumulates the values of the
already knows the relevant routing metric values along rest of the routing metrics for the complete route as it travels towards the End
route. Point. The Measurement Request may also accumulate a Source Route
that the End Point may use to reach the Start Point. Upon receiving
the Measurement Request, the End Point unicasts a Measurement Reply
message, carrying the accumulated values of the routing metrics, back
to the Start Point. Optionally, the Start Point may allow an
Intermediate Point to generate the Measurement Reply if the
Intermediate Point already knows the relevant routing metric values
along rest of the route.
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| SequenceNo| Num | Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Origin Address | | Start Point Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Target Address | | End Point Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Address[1..Num] . . Address[1..Num] .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Metric Container Option(s) . . Metric Container Option(s) .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of the base Measurement Object (MO) Figure 1: Format of the base Measurement Object (MO)
The format of a base MO is shown in Figure 1. A base MO consists of The format of a base MO is shown in Figure 1. A base MO consists of
the following fields: the following fields:
o RPLInstanceID: This field is relevant only if a hop-by-hop route o RPLInstanceID: This field specifies the RPLInstanceID of the Hop-
is being measured, i.e., the H flag, described subsequently, is by-hop Route along which the Measurement Request travels (or
set to one. In this case, the Origin MUST set this field to the traveled initially until it switched over to a Source Route).
RPLInstanceID of the hop-by-hop route being measured. If a source
route is being measured, the Origin MUST set this field to binary
value 10000000. An Intermediate Router MUST set the RPLInstanceID
field in the outgoing MO packet to the same value that it had in
the corresponding incoming MO packet unless it is the root of a
non-storing global DAG, identified by the RPLInstanceID, along
which the MO packet had been traveling so far and the router
intends to insert a source route inside the Address vector to
direct it towards the Target. In that case, the router MUST set
the RPLInstanceID field in the outgoing MO packet to binary value
10000000.
o Compr: In many LLN deployments, IPv6 addresses share a well known, o Compr: In many LLN deployments, IPv6 addresses share a well known,
common prefix. In such cases, the common prefix can be elided common prefix. In such cases, the common prefix can be elided
when specifying IPv6 addresses in the Origin/Target Address fields when specifying IPv6 addresses in the Start Point/End Point
and the Address vector. The "Compr" field, a 4-bit unsigned Address fields and the Address vector. The "Compr" field, a 4-bit
integer, is set by the Origin to specify the number of prefix unsigned integer, is set by the Start Point to specify the number
octets that are elided from the IPv6 addresses in Origin/Target of prefix octets that are elided from the IPv6 addresses in Start
Address fields and the Address vector. An Intermediate Router Point/End Point Address fields and the Address vector. The Start
MUST set the Compr field in the outgoing MO packet to the same Point will set the Compr value to zero if full IPv6 addresses are
value that it had in the corresponding incoming MO packet. The to be carried in the Start Point Address/End Point Address fields
Intermediate Router MUST drop the received MO message if the Compr and the Address vector.
value specified in the message does not match what the router
considers the length of the common prefix to be. The Origin will
set the Compr value to zero if full IPv6 addresses are to be
carried in the Origin Address/Target Address fields and the
Address vector.
o Type (T): This flag is set to one if the MO represents a o Type (T): This flag is set to one if the MO represents a
Measurement Request. The flag is set to zero if the MO is a Measurement Request. The flag is set to zero if the MO is a
Measurement Reply. Measurement Reply.
o Hop-by-hop (H): The Origin MUST set this flag to one if the route o Hop-by-hop (H): The Start Point MUST set this flag to one if (at
being measured is a hop-by-hop route. In that case, the hop-by- least the initial part of) the route being measured is hop-by-hop.
hop route is identified by the RPLInstanceID and, if the In that case, the Hop-by-hop Route is identified by the
RPLInstanceID is a local value, the Origin Address and Target RPLInstanceID, the End Point Address and, if the RPLInstanceID is
Address fields inside the message. The Origin MUST set this flag a local value, the Start Point Address (required to be same as the
to zero if the route being measured is a source route specified in DODAGID of the route being measured) fields inside the Measurement
the Address vector. An Intermediate Router MUST set the H flag in Request. The Start Point MUST set this flag to zero if the route
an outgoing MO packet to the same value that it had in the being measured is a Source Route specified in the Address vector.
corresponding incoming MO packet unless the router is the root of An Intermediate Point MUST set the H flag in an outgoing
the non-storing global DAG, identified by the RPLInstanceID, along Measurement Request to the same value that it had in the
which the MO packet had been traveling so far and the router corresponding incoming Measurement Request unless it is the root
intends to insert a source route inside the Address vector to of the non-storing global DAG, identified by the RPLInstanceID,
direct it towards the Target. In that case, the router MUST reset along which the Measurement Request had been traveling so far and
the H flag to zero in the outgoing MO packet. the Intermediate Point intends to insert a Source Route inside the
Address vector to direct it towards the End Point. In that case,
the Intermediate Point MUST set the H flag to zero.
o Accumulate Route (A): This flag is relevant only if the MO o Accumulate Route (A): A value 1 in this flag indicates that the
represents a Measurement Request that travels along a hop-by-hop Measurement Request is accumulating a Source Route for use by the
route represented by a local RPLInstanceID. In other words, this End Point to send the Measurement Reply back to the Start Point.
flag MAY be set to one only if T = 1, H = 1 and the RPLInstanceID Route accumulation is allowed (i.e., this flag MAY be set to one)
field has a local value. Otherwise, this flag MUST be set to inside a Measurement Request only if it travels along a Hop-by-hop
zero. A value 1 in this flag indicates that the Measurement Route represented by a local RPLInstanceID (i.e., H = 1,
Request MUST accumulate a source route for use by the Target to RPLInstanceID has a local value). In this case, an Intermediate
send the Measurement Reply back to the Origin. In this case, an Point adds its unicast IPv6 address (after eliding Compr number of
Intermediate Router MUST add its unicast IPv6 address (after prefix octets) to the Address vector in the manner specified in
eliding Compr number of prefix octets) to the Address vector in Section 5.3. In other cases, this flag MUST be set to zero on
the manner specified later. Route accumulation is not allowed transmission and ignored on reception. Route accumulation is not
when the Measurement Request travels along a hop-by-hop route with allowed when the Measurement Request travels along a Hop-by-hop
a global RPLInstanceID, i.e., along a global DAG, because: 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 Target; and Route to the End Point; and
* The Target can presumably reach the Origin along this global * The End Point can presumably reach the Start Point along this
DAG. global DAG (identified by the RPLInstanceID field).
o Reverse (R): This flag is relevant only if the MO represents a o Reverse (R): A value 1 in this flag inside a Measurement Request
Measurement Request that travels along a source route, specified indicates that the Address vector contains a complete Source Route
in the Address vector, to the Target. In other words, this flag from the Start Point to the End Point, which can be used, after
MAY be set to one only if T = 1 and H = 0. Otherwise, this flag reversal, by the End Point to send the Measurement Reply back to
MUST be set to zero. A value 1 in the flag indicates that the the Start Point. This flag MAY be set to one inside a Measurement
Address vector contains a complete source route from the Origin to Request only if a Source Route, from the Start Point to the End
the Target, which can be used, after reversal, by the Target to Point, is being measured. Otherwise, this flag MUST be set to
source route the Measurement Reply message back to the Origin. zero on transmission and ignored on reception.
o Back Request (B): This flag serves as a request to the Target to o Back Request (B): A value 1 in this flag serves as a request to
send a Measurement Request towards the Origin. The Origin MAY set the End Point to send a Measurement Request towards the Start
this flag to one to make such a request to the Target. An Point. On receiving a Measurement Request with the B flag set to
Intermediate Router MUST set the B flag in an outgoing MO packet one, the End Point SHOULD generate a Measurement Request to
to the same value that it had in the corresponding incoming MO measure the cost of its current (or the most preferred) route to
packet. On receiving a Measurement Request with the B flag set to the Start Point. Receipt of this Measurement Request would allow
one, the Target SHOULD generate a Measurement Request to measure the Start Point to know the cost of the back route from the End
the cost of its current (or the most preferred) route to the Point to itself and thus determine the round-trip cost of reaching
Origin. Receipt of this Measurement Request would allow the the End Point.
Origin to know the cost of the back route from the Target to
itself and thus determine the round-trip cost of reaching the
Target.
o Intermediate Reply (I): Relevant only if a hop-by-hop route is o Intermediate Reply (I): A value 1 in this flag serves as a
being measured, this flag serves as a permission to an permission to an Intermediate Point to generate a Measurement
Intermediate Router to generate a Measurement Reply if it knows Reply if it knows the aggregated values of the routing metrics
the cost of the rest of the route being measured. The Origin MAY being measured for the rest of the route. Setting this flag to
set this flag to one if a hop-by-hop route is being measured one may be useful in scenarios where the Hop Count [RFC6551] is
(i.e., H = 1) and the Origin wants to allow an Intermediate Router the routing metric of interest and an Intermediate Point (e.g. the
to generate the Measurement Reply in response to this Measurement root of a non-storing global DAG or a common ancestor of the Start
Request. Setting this flag to one may be useful in scenarios Point and the End Point in a storing global DAG) may know the Hop
where the Hop Count [RFC6551] is the routing metric of interest Count of the remainder of the route to the End Point. This flag
and the Origin expects an Intermediate Router (e.g. the root of a MAY be set to one only if a Hop-by-hop Route with a global
non-storing DAG or a common ancestor of the Origin and the Target RPLInstanceID is being measured (i.e., H = 1, RPLInstanceID has a
in a storing DAG) to know the Hop Count of the remainder of the global value). Otherwise, this flag MUST be set to zero on
route to the Target. This flag MUST be set to zero if the route transmission and ignored on reception.
being measured is a source route (i.e., H = 0).
o SequenceNo: A 6-bit sequence number, assigned by the Origin, that o SequenceNo: A 6-bit sequence number, assigned by the Start Point,
allows the Origin to uniquely identify a Measurement Request and that allows the Start Point to uniquely identify a Measurement
the corresponding Measurement Reply. An Intermediate Router MUST Request and the corresponding Measurement Reply.
set this field in the outgoing MO packet to the same value that it
had in the corresponding incoming MO packet. The Target MUST set
this field in a Measurement Reply message to the same value that
it had in the corresponding Measurement Request message.
o Num: This field indicates the number of elements, each (16 - 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 (T=1,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 A flag is set Route with a local RPLInstanceID and the Route Accumulation is on
(T=1,H=1,A=1 and RPLInstanceID field has a local value), this (i.e., H = 1, RPLInstanceID has a local value, A = 1), this field
field indicates the index in the Address vector where an indicates the index in the Address vector where an Intermediate
Intermediate Router receiving the MO message 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 Origin Address: A unicast IPv6 address of the Origin after eliding o Start Point Address: A unicast IPv6 address of the Start Point
Compr number of prefix octets. If the MO is traveling along a after eliding Compr number of prefix octets. If the Measurement
hop-by-hop route and the RPLInstanceID field indicates a local Request is traveling along a Hop-by-hop Route and the
value, the Origin Address field MUST specify the DODAGID value RPLInstanceID field indicates a local value, the Start Point
that, along with the RPLInstanceID and the Target Address, Address field MUST specify the DODAGID value that, along with the
uniquely identifies the hop-by-hop route being measured. RPLInstanceID and the End Point Address, uniquely identifies the
Hop-by-hop Route being measured.
o Target Address: A unicast IPv6 address of the Target after eliding o End Point Address: A unicast IPv6 address of the End Point after
Compr number of prefix octets. eliding Compr number of prefix octets.
o Address[1..Num]: A vector of unicast IPv6 addresses (with Compr o Address[0..Num-1]: A vector of unicast IPv6 addresses (with Compr
number of prefix octets elided) representing a source route to the number of prefix octets elided) representing a Source Route:
Target:
* 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.
* When the Measurement Request is traveling along a hop-by-hop * When the Measurement Request is traveling along a Hop-by-hop
route with local RPLInstanceID and has the A flag set, the Route with local RPLInstanceID and has the A flag set to one
Address vector is used to accumulate a source route to be used (i.e., H = 1, RPLInstanceID has a local value, A = 1), the
by the Target to send the Measurement Reply back to the Origin. Address vector is used to accumulate a Source Route that can be
In this case, the route MUST be accumulated in the forward used by the End Point, after reversal, to send the Measurement
direction, i.e., from the Origin to the Target. The Target Reply back to the Start Point. The route MUST be accumulated
router would reverse this route to obtain a source route from in the Forward direction but the IPv6 addresses in the
itself to the Origin. The IPv6 addresses in the accumulated accumulated route MUST be reachable in the Backward direction.
route MUST be reachable in the backward direction, i.e., from An Intermediate Point adding its address to the Address vector
the Target to the Origin. An Intermediate Router adding its MUST ensure that a routing loop involving this router does not
address to the Address vector MUST ensure that its address does exist in the accumulated route.
not already exist in the vector.
* When the Measurement Request is traveling along a source route, * When the Measurement Request is traveling along a Source Route
the Address vector MUST contain a complete route to the Target (i.e., H = 0), the Address vector MUST contain a complete route
and the IPv6 addresses in the Address vector MUST be reachable to the End Point and the IPv6 addresses in the Address vector
in the forward direction, i.e., from the Origin to the Target. MUST be reachable in the Forward direction. A router (the
A router (Origin or an Intermediate Router) inserting an Start Point or an Intermediate Point) inserting an Address
Address vector inside an MO MUST ensure that no address appears vector inside a Measurement Request MUST ensure that no address
more than once inside the vector. Each router on the way MUST appears more than once inside the vector. Each router on the
ensure that the loops do not exist within the source route. way MUST ensure that a routing loop involving this router does
The Origin MAY set the R flag in the MO if the route in the not exist within the Source Route. The Start Point MAY set the
Address vector represents a complete route from the Origin to R flag in the Measurement Request if the route in the Address
the Target and this route can be used after reversal by the vector represents a complete route from the Start Point to the
Target to send the Measurement Reply message back to the Origin End Point and this route can be used by the End Point, after
(i.e., the IPv6 addresses in the Address vector are reachable reversal, to send the Measurement Reply message back to the
in the backward direction - from the Target to the Origin). Start Point (i.e., the IPv6 addresses in the Address vector are
reachable in the Backward direction).
* The Origin and Target addresses MUST NOT be included in the * The Start Point and End Point addresses MUST NOT be included in
Address vector. the Address vector.
* The Address vector MUST NOT contain any multicast addresses. * The Address vector MUST NOT contain any multicast addresses.
o Metric Container Options: An MO MUST contain one or more Metric o Metric Container Options: A Measurement Request MUST contain one
Container options to accumulate the routing metric values for the or more Metric Container options [RFC6550] to accumulate the
route being measured. values of the selected routing metrics in the manner described in
[RFC6551] for the route being measured.
Section 4 describes how does a Start Point set various fields inside
a Measurement Request in different cases. Section 5 describes how
does an Intermediate Point process a received Measurement Request
before forwarding it further. Section 6 describes how does the End
Point process a received Measurement Request and generate a
Measurement Reply. Finally, Section 7 describes how does the Start
Point process a received Measurement Reply.
3.2. Secure MO 3.2. Secure MO
A Secure MO message follows the format in Figure 7 of [RFC6550], A Secure MO follows the format in Figure 7 of [RFC6550], where the
where the base format is the base MO shown in Figure 1. base format is the base MO shown in Figure 1.
4. Originating a Measurement Request 4. Originating a Measurement Request
If an Origin needs to measure the routing metric values along a P2P A Start Point sets various fields inside the Measurement Request it
route towards a Target, it generates an MO message and sets its generates in the manner described below. The Start Point MUST also
fields as described in Section 3.1. The setting of MO fields in include the routing metric objects [RFC6551] of interest inside one
specific cases is described below. In all cases, the Origin MUST set or more Metric Container options inside the Measurement Request. The
the T flag to one to indicate that the MO represents a Measurement Start Point then determines the next hop on the route being measured.
Request. The Origin MUST also include the routing metric objects of If a Hop-by-hop route is being measured (i.e., H = 1), the next hop
interest inside one or more Metric Container options inside the MO. is determined using the RPLInstanceID, the End Point Address and, if
Depending on the metrics being measured, the Origin must also RPLInstanceID is a local value, the Start Point Address fields in the
initiate these routing metric objects by including the values of the Measurement Request. If a Source Route is being measured (i.e., H =
routing metrics for the first hop on the P2P route being measured. 0), the Address[0] element inside the Measurement Request contains
the next hop address. The Start Point MUST discard the Measurement
After setting the MO fields appropriately, the Origin determines the Request if:
next hop on the P2P route being measured. If a hop-by-hop route is
being measured (i.e., the H flag is set to one), the next hop is
determined using the RPLInstanceID, the Target Address and, if
RPLInstanceID is a local value, the Origin Address fields in the MO.
If a source route is being measured (i.e., the H flag is set to
zero), the Address[1] element contains the next hop address.
The Origin MUST discard the MO message if:
o the next hop address is not a unicast address; or o the next hop address is not a unicast address; or
o the next hop is not on-link; or o the next hop is not on-link; or
o the next hop is not in the same RPL routing domain as the Origin. o the next hop is not in the same RPL routing domain as the Start
Point.
Otherwise, the Origin MUST unicast the MO message to the next hop on Otherwise, depending on the routing metrics, the Start Point must
the P2P route. initiate the routing metric objects inside the Metric Container
options by including the routing metric values for the first hop on
the route being measured. Finally, the Start Point MUST unicast the
Measurement Request to the next hop on the route being measured.
4.1. To Measure A Hop-by-hop Route with a Global RPLInstanceID 4.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
the MO message MUST NOT contain the Address vector and the following (i.e., H = 1, RPLInstanceID has a global value), the MO MUST NOT
MO fields MUST be set in the manner specified below: contain an Address vector and various MO fields MUST be set in the
following manner:
o Hop-by-hop (H): This flag MUST be set to one. o RPLInstanceID: MUST be set to the RPLInstanceID of the route being
measured.
o Compr: MUST be set to specify the number of prefix octets that are
elided from the IPv6 addresses in Start Point/End Point Address
fields.
o Type (T): MUST be set to one since the MO represents a Measurement
Request.
o Hop-by-hop (H): MUST be set to one.
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
Point to send a Measurement Request to the Start Point.
o Intermediate Reply (I): This flag MAY be set to one if the Start
Point expects an Intermediate Point to know the values of the
routing metrics being measured for the remainder of the route.
o SequenceNo: Assigned by the Start Point so that it can uniquely
identify the Measurement Request and the corresponding Measurement
Reply.
o Num: This field MUST be set to zero. o 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.
4.2. To Measure A Hop-by-hop Route with a Local RPLInstanceID o Start Point Address: MUST be set to a unicast IPv6 address of the
Start Point after eliding Compr number of prefix octets.
If a hop-by-hop route with a local RPLInstanceID is being measured o End Point Address: MUST be set to a unicast IPv6 address of the
and the MO is not accumulating a source route for the Target's use, End Point after eliding Compr number of prefix octets.
the MO message MUST NOT contain the Address vector and the following
MO fields MUST be set in the manner specified below:
o Hop-by-hop (H): This flag MUST be set to one. 4.2. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With
Route Accumulation Off
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
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:
o RPLInstanceID: MUST be set to the RPLInstanceID of the route being
measured.
o Compr: MUST be set to specify the number of prefix octets that are
elided from the IPv6 addresses in Start Point/End Point Address
fields.
o Type (T): MUST be set to one since the MO represents a Measurement
Request.
o Hop-by-hop (H): MUST be set to one.
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
Point to send a Measurement Request to the Start Point.
o Intermediate Reply (I): This flag MUST be set to zero.
o SequenceNo: Assigned by the Start Point so that it can uniquely
identify the Measurement Request and the corresponding Measurement
Reply.
o Num: This field MUST be set to zero. o 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 Origin Address: This field MUST contain the DODAGID value (after o Start Point Address: This field MUST contain the DODAGID value
eliding Compr number of prefix octets) associated with the route (after eliding Compr number of prefix octets) associated with the
being measured. route being measured.
If a hop-by-hop route with a local RPLInstanceID is being measured o End Point Address: MUST be set to a unicast IPv6 address of the
and the Origin desires the MO to accumulate a source route for the End Point after eliding Compr number of prefix octets.
Target to send the Measurement Reply message back, it MUST set the
following MO fields in the manner specified below:
o Hop-by-hop (H): This flag MUST be set to one. 4.3. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With
Route Accumulation On
If a Hop-by-hop Route with a local RPLInstanceID is being measured
and the Start Point desires the MO to accumulate a Source Route for
the End Point to send the Measurement Reply message back, the MO MUST
contain an Address vector and various MO fields MUST be set in the
following manner:
o RPLInstanceID: MUST be set to the RPLInstanceID of the route being
measured.
o Compr: MUST be set to specify the number of prefix octets that are
elided from the IPv6 addresses in Start Point/End Point Address
fields and the Address vector.
o Type (T): MUST be set to one since the MO represents a Measurement
Request.
o Hop-by-hop (H): MUST be set to one.
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
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
identify the Measurement Request and the corresponding Measurement
Reply.
o Num: This field MUST specify the number of address elements, each
(16 - Compr) octets in size, that can fit inside the Address
vector.
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.
o Start Point Address: This field MUST contain the DODAGID value
(after eliding Compr number of prefix octets) associated with the
route being measured.
o End Point Address: MUST be set to a unicast IPv6 address of the
End Point after eliding Compr number of prefix octets.
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 Origin to the Target. accomodate a complete Source Route from the End Point to the Start
All the bits in the Address vector field MUST be set to zero. Point. All the bits in the Address vector field MUST be set to
zero.
o Num: This field MUST specify the number of address elements that 4.4. When Measuring A Source Route
can fit inside the Address vector.
o Index: This field MUST be set to one. If a Source Route is being measured, the Start Point MUST set various
MO fields in the following manner:
o Origin Address: This field MUST contain the DODAGID value (after o RPLInstanceID: MUST be set to the binary value 10000000.
eliding Compr number of prefix octets) associated with the route
being measured.
4.3. To Measure A Source Route o Compr: MUST be set to specify the number of prefix octets that are
elided from the IPv6 addresses in Start Point/End Point Address
fields and the Address vector.
If a source route is being measured, the Origin MUST set the o Type (T): MUST be set to one since the MO represents a Measurement
following MO fields in the manner specified below: Request.
o Hop-by-hop (H): This flag MUST be set to zero. o Hop-by-hop (H): MUST be set to zero.
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 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 Target to the Address vector can be reversed and used by the End Point to
source route the Measurement Reply message back to the Origin. 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
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
identify the Measurement Request and the corresponding Measurement
Reply.
o Num: This field MUST specify the number of address elements, each
(16 - Compr) octets in size, inside the Address vector.
o Index: This field MUST be set to zero to indicate the position in
the Address vector of the next hop on the route.
o Start Point Address: MUST be set to a unicast IPv6 address of the
Start Point after eliding Compr number of prefix octets.
o End Point Address: MUST be set to a unicast IPv6 address of the
End Point after eliding Compr number of prefix octets.
o Address vector: o Address vector:
* The Address vector MUST contain a complete route from the * The Address vector MUST contain a complete Source Route from
Origin to the Target (excluding the Origin and the Target). the Start Point to the End Point (excluding the Start Point and
the End Point).
* The IPv6 addresses (with Compr prefix octets elided) in the * The IPv6 addresses (with Compr prefix octets elided) in the
Address vector MUST be reachable in the forward direction, Address vector MUST be reachable in the Forward direction.
i.e., from the Origin to the Target.
* If the R flag is set to one, the IPv6 addresses (with Compr * If the R flag is set to one, the IPv6 addresses (with Compr
prefix octets elided) in the Address vector MUST also be prefix octets elided) in the Address vector MUST also be
reachable in the backward direction, i.e., from the Target to reachable in the Backward direction.
the Origin.
* To prevent loops in the source route, the Origin MUST ensure * To avoid loops in the Source Route, the Start Point MUST ensure
compliance to the following rules: compliance to the following rules:
+ Any IPv6 address MUST NOT appear more than once in the + Any IPv6 address MUST NOT appear more than once in the
Address vector. Address vector.
+ If the Address vector includes multiple IPv6 addresses + If the Address vector includes multiple IPv6 addresses
assigned to the Origin's interfaces, such addresses MUST assigned to the Start Point's interfaces, such addresses
appear back to back inside the Address vector. MUST appear back to back inside the Address vector.
* Each address appearing in the Address vector MUST be a unicast * Each address appearing in the Address vector MUST be a unicast
address. address.
o Num: This field MUST be set to indicate the number of elements in 5. Processing a Measurement Request at an Intermediate Point
the Address vector.
o Index: This field MUST be set to one.
5. Processing a Measurement Request at an Intermediate Router
A router (an Intermediate Router or the Target) MAY discard a 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. to enhance its battery life or to prevent misuse of this mechanism by
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
Compr field inside the received message is not same as what the value in the Compr field inside the received message is more than
router considers the length of the common prefix used in IPv6 what the router considers the length of the common prefix used in
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 Origin or the Target Address. If neither, the router either the Start Point or the End Point Address. If neither, the
considers itself an Intermediate Router and MUST process the received router considers itself an Intermediate Point and MUST process the
MO in the following manner. received MO in the following manner.
An Intermediate Router 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. processing if the received MO is not a Measurement Request (i.e., T =
0).
If the H and I flags are set to one in the received MO and the Next, the Intermediate Point determines the type of the route being
Intermediate Router knows the values of the routing metrics, measured (by checking the values of the H flag and the RPLInstanceID
specified in the Metric Container, for the remainder of the route, it field) and processes the received MO accordingly in the manner
MAY generate a Measurement Reply on the Target's behalf in the manner specified next.
specified in Section 6 (after including in the Measurement Reply the
relevant routing metric values for the complete route being
measured). Otherwise, the Intermediate Router MUST process the
received MO in the following manner.
The router MUST determine the next hop on the P2P route being 5.1. When Measuring A Hop-by-hop Route with a Global RPLInstanceID
measured in the manner described below. The router MUST drop the MO
with no further processing and MAY send an ICMPv6 Destination
Unreachable (with Code 0 - No Route To Destination) error message to
the source of the message if it can not determine the next hop for
the message. The router MUST drop the MO with no further processing:
o If the next hop address is not a unicast address; or 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
Point MUST process the received Measurement Request in the following
manner.
o If the next hop is not on-link; or The Intermediate Point MUST discard the received Measurement Request
with no further processing if the Num field is not set to zero or if
the Address vector is present in the received message.
o If the next hop is not in the same RPL routing domain as the If the Intermediate Reply (I) flag is set to one in the received
router. Measurement Request and the Intermediate Point knows the values of
the routing metrics, specified in the Metric Container options, for
the remainder of the route, it MAY generate a Measurement Reply on
the End Point's behalf in the manner specified in Section 6.1 (after
including in the Measurement Reply the relevant routing metric values
for the complete route being measured). Otherwise, the Intermediate
Point MUST process the received message in the following manner.
Next, the router MUST update the routing metric objects, contained in The Intermediate Point MUST then determine the next hop on the route
the Metric Container option(s) inside the MO, either by updating the being measured using the RPLInstanceID and the End Point Address. If
aggregated value for the routing metric or by attaching the local the Intermediate Point is the root of the non-storing global DAG
values for the metric inside the object. An Intermediate Router can along which the received Measurement Request had been traveling so
only update the existing metric objects and MUST NOT add any new far, it MUST process the received Measurement Request in the
routing metric object to the Metric Container. An Intermediate following manner:
Router MUST drop the MO if it cannot update a routing metric object
specified inside the Metric Container.
After updating the routing metrics, the router MUST unicast the MO to o The router MUST discard the Measurement Request with no further
the next hop. processing and MAY send an ICMPv6 Destination Unreachable (with
Code 0 - No Route To Destination) error message to the Start Point
if it does not know how to reach the End Point.
5.1. Determining Next Hop For An MO Measuring A Source Route o Otherwise, unless the router determines the End Point itself to be
the next hop, the router MUST make the following changes in the
received Measurement Request:
In case the received MO is measuring a source route (H=0), * Set the H, A, R and I flags to zero (the A and R flags should
already be zero in the received message).
o The router MUST verify that the Address[Index] element lists one * Leave remaining fields unchanged (the Num field would be
of its unicast IPv6 addresses, failing which the router MUST modified in next steps). Note that the RPLInstanceID field
discard the MO packet with no further processing; identifies the non-storing global DAG along which the
Measurement Request traveled so far. This information MUST be
preserved so that the End Point may use this DAG to send the
Measurement Reply back to the Start Point.
o The router MUST then increment the Index field and use the * Insert a new Address vector inside the Measurement Request and
Address[Index] element as the next hop. If Index is greater than specify a Source Route to the End Point inside the Address
Num, the router MUST use the Target Address as the next hop. vector as per the following rules:
To prevent loops, an Intermediate Router MUST discard the MO packet + The Address vector MUST contain a complete route from the
with no further processing if the Address vector includes multiple router to the End Point (excluding the router and the End
IPv6 addresses assigned to the router's interfaces and if such Point);
addresses do not appear back to back inside the Address vector.
5.2. Determining Next Hop For An MO Measuring A Hop-by-hop Route + The IPv6 addresses (with Compr prefix octets elided) in the
Address vector MUST be reachable in the Forward direction;
If the received MO is measuring a hop-by-hop route (H=1), the router + To avoid loops in the Source Route, the router MUST ensure
MUST use the RPLInstanceID, the Target Address and, if RPLInstanceID that
is a local value, the Origin Address to determine the next hop for
the MO. Moreover,
o If the RPLInstanceID of the hop-by-hop route is a local value and - Any IPv6 address MUST NOT appear more than once in the
the A flag is set, the router MUST check if the Address vector Address vector;
already contains one of its IPv6 addresses. If yes, the router
MUST discard the packet with no further processing. Otherwise,
the router MUST store one of its IPv6 addresses (after eliding
Compr prefix octets) at location Address[Index] and then increment
the Index field.
o If the router is the root of the non-storing global DAG along - If the Address vector includes multiple IPv6 addresses
which the received MO message had been traveling so far, assigned to the router's interfaces, such addresses MUST
appear back to back inside the Address vector.
* The router discards the MO packet with no further processing if + Each address appearing in the Address vector MUST be a
it does not know of a source route to reach the Target unicast address.
(specified by the Target Address listed in the packet).
* Otherwise, the router MUST do the following: * Specify in the Num field the number of address elements in the
Address vector.
+ Set the H, A and R flags to zero and the RPLInstanceID field * Set the Index field to zero to indicate the position in the
to binary value 10000000. Address vector of the next hop on the route. Thus, Address[0]
element contains the address of the next hop on the route.
+ Remove any existing Address vector inside the MO. The Intermediate Point MUST then complete the processing of the
received Measurement Request as specified in Section 5.5.
+ Insert a new Address vector inside the MO and specify a 5.2. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With
source route to the Target inside the Address vector as per Route Accumulation Off
the following rules:
- The Address vector MUST contain a complete route from the If a Hop-by-hop Route with a local RPLInstanceID is being measured
router to the Target (excluding the router and the and the route accumulation is off (i.e., H = 1, RPLInstanceID has a
Target); local value, A = 0), the Intermediate Point MUST process the received
Measurement Request in the following manner.
- The IPv6 addresses (with Compr prefix octets elided) in The Intermediate Point MUST discard the received Measurement Request
the Address vector MUST be reachable in the forward with no further processing if the Num field is not zero or if the
direction, i.e., towards the Target; Address vector is present in the received message.
- To prevent loops in the source route, the router MUST The Intermediate Point MUST then determine the next hop on the route
ensure that being measured using the RPLInstanceID, the End Point Address and the
Start Point Address (which represents the DODAGID of the route being
measured). The Intermediate Point MUST discard the Measurement
Request with no further processing and MAY send an ICMPv6 Destination
Unreachable (with Code 0 - No Route To Destination) error message to
the Start Point if it can not determine the next hop. Otherwise, the
Intermediate Point MUST complete the processing of the received
Measurement Request as specified in Section 5.5.
o Any IPv6 address MUST NOT appear more than once in the 5.3. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With
Address vector; Route Accumulation On
o If the Address vector includes multiple IPv6 addresses If a Hop-by-hop Route with a local RPLInstanceID is being measured
assigned to the router's interfaces, such addresses and the route accumulation in on (i.e., H = 1, RPLInstanceID has a
MUST appear back to back inside the Address vector. local value, A = 1), the Intermediate Point MUST process the received
Measurement Request in the following manner.
- Each address appearing in the Address vector MUST be a The Intermediate Point MUST discard the received Measurement Request
unicast address. with no further processing if the Num field is set to zero or if the
Address vector is not present in the received message.
+ Specify in the Num field the number of address elements in The Intermediate Point MUST then determine the next hop on the route
the Address vector. being measured using the RPLInstanceID, the End Point Address and the
Start Point Address (which represents the DODAGID of the route being
measured). The Intermediate Point MUST discard the Measurement
Request with no further processing and MAY send an ICMPv6 Destination
Unreachable (with Code 0 - No Route To Destination) error message to
the Start Point if it can not determine the next hop. The
Intermediate Point MUST drop the received Measurement Request with no
further processing if the index field has value Num - 1 and the next
hop is not same as the End Point. In this case, the next hop would
have no space left in the Address vector to store its address.
+ Set the Index field to one. Otherwise, the Intermediate Point MUST check if adding one of its
IPv6 addresses to the the Address vector would create a routing loop
in the accumulated route. If yes, the router MUST discard the packet
with no further processing. Otherwise, the router MUST store one of
its unicast IPv6 addresses (after eliding Compr prefix octets) at
location Address[Index] and then increment the Index field. The IPv6
address added to the Address vector MUST be reachable in the Backward
direction.
6. Processing a Measurement Request at the Target The Intermediate Point MUST then complete the processing of the
received Measurement Request as specified in Section 5.5.
On receiving an MO, if a router chooses to process the packet further 5.4. When Measuring A Source Route
and finds one of its unicast IPv6 addresses listed as the Target
Address, the router considers itself the Target and MUST process the
received MO in the following manner.
The Target MUST discard the packet with no further processing if the If a Source Route is being measured (i.e., H = 0), the Intermediate
received MO is not a Measurement Request. Point MUST process the received Measurement Request in the following
manner.
The Target MUST update the routing metric objects in the Metric The Intermediate Point MUST discard the received Measurement Request
with no further processing if the Num field is set to zero or if the
Address vector is not present in the received message.
The Intermediate Point MUST then determine the next hop on the route
being measured in the manner described below. The Intermediate Point
MUST verify that the Address[Index] element lists one of its unicast
IPv6 addresses, failing which it MUST discard the Measurement Request
with no further processing. To prevent loops, the Intermediate Point
MUST discard the Measurement Request with no further processing if
the Address vector includes multiple IPv6 addresses assigned to its
interfaces and if such addresses do not appear back to back inside
the Address vector. The Intermediate Point MUST then increment the
Index field and use the Address[Index] element as the next hop
(unless Index value is now Num). If the Index value is now Num, the
Intermediate Point MUST use the End Point Address as the next hop.
The Intermediate Point MUST then complete the processing of the
received Measurement Request as specified in Section 5.5.
5.5. Final Processing
The Intermediate Point MUST drop the received Measurement Request
with no further processing:
o If the next hop address is not a unicast address; or
o If the next hop is not on-link; or
o If the next hop is not in the same RPL routing domain as the
Intermediate Point.
Next, the Intermediate Point MUST update the routing metric objects,
inside the Metric Container option(s) inside the Measurement Request,
either by updating the aggregated value for the routing metric or by
attaching the local values for the metric inside the object. An
Intermediate Point can only update the existing metric objects and
MUST NOT add any new routing metric object to the Metric Container.
An Intermediate Point MUST drop the Measurement Request with no
further processing if it cannot update a routing metric object
specified inside the Metric Container.
Finally, the Intermediate Point MUST unicast the Measurement Request
to the next hop.
6. Processing a Measurement Request at the End Point
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
Point Address, the router considers itself the End Point and MUST
process the received MO in the following manner.
The End Point MUST discard the received message with no further
processing if it is not a Measurement Request (i.e., T = 0).
If the received Measurement Request traveled on a Hop-by-hop Route
with a local RPLInstanceID with route accumulation on (i.e., H = 1,
RPLInstanceID has a local value and A = 1), elements Address[0]
through Address[Index - 1] in the Address vector contain a complete
Source Route from the Start Point to the End Point (excluding the
Start Point and the End Point), which the End Point MAY use, after
reversal, to reach the Start Point.
If the received Measurement Request traveled on a Source Route and
the Reverse flag is set to one (i.e., H = 0, R = 1), elements
Address[0] through Address[Num - 1] in the Address vector contain a
complete Source Route from the Start Point to the End Point
(excluding the Start Point and the End Point), which the End Point
MAY use, after reversal, to reach the Start Point.
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 is likely a response to an earlier Measurement Request that the End
Target had sent to the Origin with B flag set to one). Point had sent to the Start Point with B flag set to one).
The Target MUST generate a Measurement Reply message. The The End Point MUST generate a Measurement Reply message as specified
Measurement Reply message MUST have the same SequenceNo field as the in Section 6.1. If the B flag is set to one in the received
received Measurement Request message. The received Measurement Measurement Request, the End Point SHOULD generate a new Measurement
Request message can be trivially converted into the Measurement Reply Request to measure the cost of its current (or the most preferred)
by setting the T flag to zero. The Target MAY remove the Address route to the Start Point. The routing metrics used in the new
vector from the Measurement Reply if desired. The Target MUST then Measurement Request MUST include the routing metrics specified in the
unicast the Measurement Reply back to the Origin: received Measurement Request.
o If the Measurement Request traveled along a global DAG (i.e., one 6.1. Generating the Measurement Reply
with a global RPLInstanceID), the Measurement Reply MAY be unicast
back to the Origin along the same DAG.
o If the Measurement Request traveled along a hop-by-hop route with A Measurement Reply MUST have the Type (T) flag set to zero and need
a local RPLInstanceID and the A flag inside the received message not contain the Address vector. The following fields inside a
is set to one, the Target MAY reverse the source route contained Measurement Reply MUST have the same values as they had inside the
in the Address vector and use it to send the Measurement Reply corresponding Measurement Request: RPLInstanceID, Compr, SequenceNo,
back to the Origin. Start Point Address, End Point Address and Metric Container
Option(s). The remaining fields inside a Measurement Reply may have
any value and MUST be ignored on reception at the Start Point. The
received Measurement Request MAY trivially be converted into a
Measurement Reply by setting the Type (T) flag to zero.
o If the Measurement Request traveled along a source route and the R A Measurement Reply MUST be unicast back to the Start Point:
flag inside the received message is set to one, the Target MAY
reverse the source route contained in the Address vector and use
it to send the Measurement Reply back to the Origin.
If the B flag in the received Measurement Request is set to one, the o If the Measurement Request traveled along a global DAG, identified
Target SHOULD generate a new Measurement Request to measure the cost by the RPLInstanceID field, the Measurement Reply MAY be unicast
of its current (or the most preferred) route to the Origin. The back to the Start Point along the same DAG.
routing metrics used in the new Measurement Request MUST include the
routing metrics specified in the received Measurement Request.
7. Processing a Measurement Reply at the Origin o If the Measurement Request traveled along a Hop-by-hop Route with
a local RPLInstanceID and accumulated a Source Route from the
Start Point to the End Point, this Source Route MAY be used after
reversal to send the Measurement Reply back to the Start Point.
o If the Measurement Request traveled along a Source Route and the R
flag inside the received message is set to one, the End Point MAY
reverse the Source Route contained in the Address vector and use
it to send the Measurement Reply back to the Start Point.
7. Processing a Measurement Reply at the Start Point
When a router receives an MO, it examines if one of its unicast IPv6 When a router receives an MO, it examines if one of its unicast IPv6
addresses is listed as the Origin Address. If yes, the router is the addresses is listed as the Start Point Address. If yes, the router
Origin and MUST process the received message in the following manner. is the Start Point and MUST process the received message in the
following manner.
The Origin MUST discard the packet with no further processing if the The Start Point MUST discard the packet with no further processing if
received MO is not a Measurement Reply or if the Origin has no the received MO is not a Measurement Reply or if the Start Point has
recollection of sending a Measurement Request with the sequence no recollection of sending the corresponding Measurement Request.
number listed in the received MO.
The Origin MUST examine the routing metric objects inside the Metric The Start Point can use the routing metric objects inside the Metric
Container options to evaluate the quality of the measured P2P route. Container to evaluate the metrics for the measured P2P route. If a
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 Origin MUST aggregate these local values routers on the route, the Start Point can make use of these local
into an end-to-end value as per the aggregation rules for the metric. values by aggregating them into an end-to-end metric according to the
aggregation rules for the specific metric. A Start Point is then
free to interpret the metrics for the route according to its local
policy.
8. Security Considerations 8. Security Considerations
The mechanism defined in this document can potentially be used by a The mechanism defined in this document can potentially be used by a
compromised router to generate bogus Measurement Requests to compromised router to send bogus Measurement Requests to arbitrary
arbitrary Target routers. Such Measurement Requests may cause CPU End Points. Such Measurement Requests may cause CPU overload in the
overload in the routers in the network, drain their batteries and routers in the network, drain their batteries and cause traffic
cause traffic congestion in the network. Note that some of these congestion in the network. Note that some of these problems would
problems would occur even if the compromised router were to generate occur even if the compromised router were to generate bogus data
bogus data traffic to arbitrary destinations. traffic to arbitrary destinations.
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.
o This document requires that an MO message must not cross the o This document requires that an MO message must not cross the
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 MO o This document requires that a router must drop a received MO
message if the next hop address is not on-link or if it is not a message if the next hop address is not on-link or if it is not a
unicast address. unicast address.
o This document requires that a router must check the source route o This document requires that a router must check the Source Route
inside the Address vector of each received MO message to ensure inside the Address vector of each received MO message to ensure
that it does not contain a loop involving the router. The router that it does not contain a loop involving the router. The router
must drop the received packet if the source route does contain must drop the received packet if the Source Route does contain
such a loop. This and the previous two rules protect the network such a loop. This and the previous two rules protect the network
against some of the security concerns even if a compromised node against some of the security concerns even if a compromised node
inserts a malformed Address vector inside the MO message. inserts a malformed Address vector inside the MO message.
The measurement mechanism described in this document may potentially
be used by a rogue node to find out key information about the LLN,
e.g., the topological features of the LLN (such as the identity of
the key nodes in the topology) or the remaining energy levels
[RFC6551] in the LLN routers. This information can potentially be
used to attack the LLN. To protect against such misuse, this
document allows RPL routers implementing this mechanism to not
process MO messages (or process such messages selectively) based on a
local policy. Further, an LLN deployment may use Secure MO
Section 3.2 messages to invoke RPL-provided security mechanisms and
prevent misuse of the measurement mechanism by unauthorized nodes.
9. IANA Considerations 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 18, line 34 skipping to change at page 23, line 46
10. Acknowledgements 10. Acknowledgements
Authors gratefully acknowledge the contributions of Matthias Philipp, Authors gratefully acknowledge the contributions of Matthias Philipp,
Pascal Thubert, Richard Kelsey and Zach Shelby in the development of Pascal Thubert, Richard Kelsey and Zach Shelby in the development of
this document. this document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-roll-p2p-rpl]
Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J.
Martocci, "Reactive Discovery of Point-to-Point Routes in
Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-15
(work in progress), December 2012.
[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.
11.2. Informative References 11.2. Informative References
[I-D.ietf-roll-p2p-rpl]
Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J.
Martocci, "Reactive Discovery of Point-to-Point Routes in
Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-13
(work in progress), June 2012.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095, of Type 0 Routing Headers in IPv6", RFC 5095,
December 2007. December 2007.
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low-Power and Lossy Networks", Routing Requirements in Low-Power and Lossy Networks",
RFC 5826, April 2010. RFC 5826, April 2010.
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
"Building Automation Routing Requirements in Low-Power and "Building Automation Routing Requirements in Low-Power and
 End of changes. 123 change blocks. 
438 lines changed or deleted 676 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/