draft-ietf-roll-p2p-measurement-08.txt   draft-ietf-roll-p2p-measurement-09.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: July 25, 2013 E. Baccelli Expires: August 8, 2013 E. Baccelli
INRIA INRIA
A. Brandt A. Brandt
Sigma Designs Sigma Designs
J. Martocci J. Martocci
Johnson Controls Johnson Controls
January 21, 2013 February 4, 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-08 draft-ietf-roll-p2p-measurement-09
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 in a low power and lossy existing route towards another RPL router, thereby allowing the
network, thereby allowing the router to decide if it wants to router to decide if it wants to initiate the discovery of a better
initiate the discovery of a better route. 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 July 25, 2013. This Internet-Draft will expire on August 8, 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 22 skipping to change at page 2, line 22
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 . . . . . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . 12 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 . . . . . . . . . 13 RPLInstanceID With Route Accumulation On . . . . . . . . . 14
4.4. When Measuring A Source Route . . . . . . . . . . . . . . 14 4.4. When Measuring A Source Route . . . . . . . . . . . . . . 15
5. Processing a Measurement Request at an Intermediate Point . . 15 5. Processing a Measurement Request at an Intermediate Point . . 16
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 . . . . . . . . . . . . . . . . . . . . . . 16 RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 17
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 . . . . . . . . 17 RPLInstanceID With Route Accumulation Off . . . . . . . . 18
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 . . . . . . . . . 18 RPLInstanceID With Route Accumulation On . . . . . . . . . 19
5.4. When Measuring A Source Route . . . . . . . . . . . . . . 19 5.4. When Measuring A Source Route . . . . . . . . . . . . . . 19
5.5. Final Processing . . . . . . . . . . . . . . . . . . . . . 19 5.5. Final Processing . . . . . . . . . . . . . . . . . . . . . 20
6. Processing a Measurement Request at the End Point . . . . . . 20 6. Processing a Measurement Request at the End Point . . . . . . 20
6.1. Generating the Measurement Reply . . . . . . . . . . . . . 20 6.1. Generating the Measurement Reply . . . . . . . . . . . . . 21
7. Processing a Measurement Reply at the Start Point . . . . . . 21 7. Processing a Measurement Reply at the Start Point . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
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:
skipping to change at page 3, line 42 skipping to change at page 3, line 42
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.
When the existing routes are deemed unsatisfactory but the router When the existing routes are deemed unsatisfactory but the router
does not implicitly know the routing constraints to be used in P2P- does not implicitly know the routing constraints to be used in P2P-
RPL route discovery, it may be necessary for the router to measure RPL route discovery, it may be necessary for the router to measure
the aggregated values of the routing metrics along the existing the aggregated values of the routing metrics along the existing
route. This knowledge will allow the router to frame reasonable route. This knowledge will allow the router to frame reasonable
routing constraints to discover a better route using P2P-RPL. For routing constraints to discover a better route using P2P-RPL. For
example, if the router determines the aggregate ETX [RFC6551] along example, if the router determines the aggregate ETX (Expected Number
an existing route to be "x", it can use "ETX < x*y", where y is a of Transmissions) [RFC6551] along an existing route to be "x", it can
certain fraction, as the routing constraint for use in P2P-RPL route use "ETX < x*y", where y is a certain fraction, as the routing
discovery. Note that it is important that the routing constraints constraint for use in P2P-RPL route discovery. Note that it is
are not overly strict; otherwise the P2P-RPL route discovery may fail important that the routing constraints not be overly strict;
even though a route, much better than the one currently being used, otherwise, the P2P-RPL route discovery may fail even though a route
exists. exists that is much better than the one currently being used.
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 Thus, the utility of this mechanism is dependent on the existence of
P2P-RPL, which is targeting publication as an Experimental RFC. It P2P-RPL, which is targeting publication as an Experimental RFC. It
makes sense, therefore, for this document also to target publication makes sense, therefore, for this document also to target publication
as an Experimental RFC. As more operational experience is gained as an Experimental RFC. The hope is that experiments with P2P-RPL
using P2P-RPL, it is hoped that the mechanism described in this and the mechanism defined in this document will result in feedback on
document will also be used, and feedback will be provided to the ROLL the utility and benefits of this document and it will be revised and
working group on the utility and benefits of this document. 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] and
[I-D.ietf-roll-p2p-rpl]. Additionally, this document defines the [I-D.ietf-roll-p2p-rpl]. Additionally, this document defines the
skipping to change at page 4, line 41 skipping to change at page 4, line 41
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.
The following terms, already defined in [I-D.ietf-roll-p2p-rpl], have The following terms, already defined in [I-D.ietf-roll-p2p-rpl], have
been redefined in this document in the following manner. been redefined in this document in the following manner.
Forward direction: The direction from the Start Point to the End Forward direction: The direction from the Start Point to the End
Point. Point.
Backward 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 [I-D.ietf-roll-p2p-rpl] or a Hop-by-hop Route
skipping to change at page 6, line 18 skipping to change at page 6, line 18
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Start Point Address | . Start Point Address .
| | . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| End Point Address | . End Point Address .
| | . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Address[0..Num-1] . . Address[0..Num-1] .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. 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 specifies the RPLInstanceID of the Hop- o RPLInstanceID: This field specifies the RPLInstanceID of the Hop-
by-hop Route along which the Measurement Request travels (or by-hop Route along which the Measurement Request travels (or
traveled initially until it switched over to a Source Route). traveled initially until it switched over to a Source Route).
skipping to change at page 7, line 28 skipping to change at page 7, line 28
and the Address vector. 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 Start Point MUST set this flag to one if (at o Hop-by-hop (H): The Start Point MUST set this flag to one if (at
least the initial part of) the route being measured is hop-by-hop. least the initial part of) the route being measured is hop-by-hop.
In that case, the Hop-by-hop Route is identified by the In that case, the Hop-by-hop Route is identified by the
RPLInstanceID, the End Point Address and, if the RPLInstanceID is RPLInstanceID, the End Point Address and, if the RPLInstanceID is
a local value, the Start Point Address (required to be same as the a local value, the Start Point Address fields inside the
DODAGID of the route being measured) fields inside the Measurement Measurement Request. Here, the Start Point Address field is
Request. The Start Point MUST set this flag to zero if the route required to be same as the DODAGID (the identifier of the
being measured is a Source Route specified in the Address vector. destination-oritented DAG root) [RFC6550] of the route being
An Intermediate Point MUST set the H flag in an outgoing measured. The Start Point MUST set the H flag to zero if the
route being measured is a Source Route specified in the Address
vector. An Intermediate Point MUST set the H flag in an outgoing
Measurement Request to the same value that it had in the Measurement Request to the same value that it had in the
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
skipping to change at page 10, line 4 skipping to change at page 10, line 6
local RPLInstanceID and accumulate a Source Route for the End local RPLInstanceID and accumulate a Source Route for the End
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 Backward direction. An route MUST be reachable in the Reverse direction. An
Intermediate Point adding its address to the Address vector Intermediate Point adding its address to the Address vector
MUST NOT modify the size of the Address vector. 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
skipping to change at page 10, line 27 skipping to change at page 10, line 29
Intermediate Point MUST NOT modify the contents of the existing Intermediate Point MUST NOT modify the contents of the existing
Address vector before forwarding the Measurement Request Address vector before forwarding the Measurement Request
further. In other words, an Intermediate Point MUST NOT modify further. In other words, an Intermediate Point MUST NOT modify
the Source Route along which the Measurement Request is the Source Route along which the Measurement Request is
currently traveling. The Start Point MAY set the R flag in the currently traveling. The Start Point MAY set the R flag in the
Measurement Request to one if the Source Route inside the Measurement Request to one if the Source Route inside the
Address vector can be used by the End Point, after reversal, to Address vector can be used by the End Point, after reversal, to
reach (and, in particular, to send the Measurement Reply back reach (and, in particular, to send the Measurement Reply back
to) the Start Point. In other words, the Start Point MAY set to) the Start Point. In other words, the Start Point MAY set
the R flag to one only if all the IPv6 addresses in the Address the R flag to one only if all the IPv6 addresses in the Address
vector are reachable in the Backward direction. 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 does a Start Point set various fields inside Section 4 describes how a Start Point sets various fields inside a
a Measurement Request in different cases. Section 5 describes how Measurement Request in different cases. Section 5 describes how an
does an Intermediate Point process a received Measurement Request Intermediate Point processes a received Measurement Request before
before forwarding it further. Section 6 describes how does the End forwarding it further. Section 6 describes how the End Point
Point process a received Measurement Request and generate a processes a received Measurement Request and generate a Measurement
Measurement Reply. Finally, Section 7 describes how does the Start Reply. Finally, Section 7 describes how the Start Point processes a
Point process a received Measurement Reply. In the following received Measurement Reply. In the following discussion, any
discussion, any reference to discarding a received Measurement reference to discarding a received Measurement Request/Reply with "no
Request/Reply with "no further processing" does not preclude updating further processing" does not preclude updating the appropriate error
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.
An LLN deployment MUST support the use of Secure MO messages to have
the ability to invoke RPL-provided security mechanisms and prevent
misuse of the measurement mechanism by unauthorized routers.
In the following discussion, any reference to MO message is also
applicable to 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 discard the Measurement the next hop address. The Start Point MUST ensure that
Request if:
o the next hop address is not a unicast address; or o the next hop address is a unicast address; and
o the next hop is not on-link; or o the next hop is on-link; and
o the next hop is not in the same RPL routing domain as the Start o the next hop is in the same RPL routing domain as the Start Point;
Point.
Otherwise, depending on the routing metrics, the Start Point must failing which the Start Point MUST discard the Measurement Request
initiate the routing metric objects inside the Metric Container without sending. Depending on the routing metrics, the Start Point
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
Request for a life time duration that is large enough to allow the
corresponding Measurement Reply to return. This state consists of
the RPLInstanceID, the SequenceNo and the End Point Address fields of
the Measurement Request. The life time duration for this state is
locally determined by the Start Point and may be deployment specific.
This state expires when the corresponding Measurement Reply is
received or when the life time is over, whichever occurs first.
Failure to receive the corresponding Measurement Reply before the
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
process the Measurement Request. The Start Point should take such
possibilities in account when deciding whether to generate another
Measurement Request for this route. The Start Point MUST discard a
received Measurement Reply with no further processing if the state
for the corresponding Measurement Request has already expired.
4.1. When Measuring 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
(i.e., H = 1, RPLInstanceID has a global value), the MO MUST NOT (i.e., H = 1, RPLInstanceID has a global value), the MO MUST NOT
contain an Address vector and various MO fields MUST be set in the contain an Address vector and various MO fields MUST be set in the
following manner: 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
measured. measured.
skipping to change at page 15, line 39 skipping to change at page 16, line 16
* 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 * 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.
* 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. reachable in the Reverse direction.
* Each address appearing in the Address vector MUST be a unicast * Each address appearing in the Address vector MUST be a unicast
address. address.
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
skipping to change at page 16, line 46 skipping to change at page 17, line 26
If the Intermediate Reply (I) flag is set to one in the received If the Intermediate Reply (I) flag is set to one in the received
Measurement Request and the Intermediate Point knows the values of Measurement Request and the Intermediate Point knows the values of
the routing metrics, specified in the Metric Container options, for the routing metrics, specified in the Metric Container options, for
the remainder of the route, it MAY generate a Measurement Reply on 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 the End Point's behalf in the manner specified in Section 6.1 (after
including in the Measurement Reply the relevant routing metric values including in the Measurement Reply the relevant routing metric values
for the complete route being measured). Otherwise, the Intermediate for the complete route being measured). Otherwise, the Intermediate
Point MUST process the received message in the following manner. Point MUST process the received message in the following manner.
The Intermediate Point MUST then determine the next hop on the route The Intermediate Point MUST determine the next hop on the route being
being measured using the RPLInstanceID and the End Point Address. If measured using the RPLInstanceID and the End Point Address. If the
the Intermediate Point is the root of the non-storing global DAG Intermediate Point is the root of the non-storing global DAG along
along which the received Measurement Request had been traveling so which the received Measurement Request had been traveling so far, it
far, it MUST process the received Measurement Request in the MUST process the received Measurement Request in the following
following manner: manner:
o If the router does not know how to reach the End Point, it MUST o If the router does not know how to reach the End Point, it MUST
discard the Measurement Request with no further processing and MAY discard the Measurement Request with no further processing and MAY
send an ICMPv6 Destination Unreachable (with Code 0 - No Route To send an ICMPv6 Destination Unreachable (with Code 0 - No Route To
Destination) error message to the Start Point. Destination) error message [RFC4443] to the Start Point.
o Otherwise, unless the router determines the End Point itself to be o Otherwise, unless the router determines the End Point itself to be
the next hop, the router MUST make the following changes in the the next hop, the router MUST make the following changes in the
received Measurement Request: received Measurement Request:
* Set the H, A, R and I flags to zero (the A and R flags should * Set the H, A, R and I flags to zero (the A and R flags should
already be zero in the received message). already be zero in the received message).
* Leave remaining fields unchanged (the Num field would be * Leave remaining fields unchanged (the Num field would be
modified in next steps). Note that the RPLInstanceID field modified in next steps). Note that the RPLInstanceID field
skipping to change at page 18, line 18 skipping to change at page 18, line 48
to zero, thereby implying that an Address vector is present, the to zero, thereby implying that an Address vector is 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 to the Start Point. Otherwise, Route To Destination) error message [RFC4443] to the Start Point.
the Intermediate Point MUST complete the processing of the received Otherwise, the Intermediate Point MUST complete the processing of the
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 in 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 to the Start Point. If the index Route To Destination) error message [RFC4443] to the Start Point. If
field has value Num - 1 and the next hop is not same as the End the index field has value Num - 1 and the next hop is not same as the
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 unicast IPv6 addresses
(after eliding Compr prefix octets) at location Address[Index] and (after eliding Compr prefix octets) at location Address[Index] and
then increment the Index field. The IPv6 address added to the then increment the Index field. The IPv6 address added to the
Address vector MUST be reachable in the Backward direction. Address vector MUST be reachable in the Reverse direction.
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.
skipping to change at page 20, line 52 skipping to change at page 21, line 35
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, SequenceNo,
Start Point Address, End Point Address and Metric Container Start Point Address, End Point Address and Metric Container
Option(s). The remaining fields inside a Measurement Reply may have Option(s). The remaining fields inside a Measurement Reply may have
any value and MUST be ignored on reception at the Start Point. The any value and MUST be ignored on reception at the Start Point; the
received Measurement Request MAY trivially be converted into a received Measurement Request can, therefore, trivially be converted
Measurement Reply by setting the Type (T) flag to zero. into a 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 21, line 31 skipping to change at page 22, line 15
it to send the Measurement Reply back to the Start Point. it to send the Measurement Reply back to the Start Point.
7. Processing a Measurement Reply at 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 Start Point Address. If yes, the router addresses is listed as the Start Point Address. If yes, the router
is the Start Point and MUST process the received message in the is the Start Point and MUST process the received message in the
following manner. following manner.
If the Start Point discovers that the received MO is not a If the Start Point discovers that the received MO is not a
Measurement Reply or if it has no recollection of sending the Measurement Reply or if it no longer maintains state for the
corresponding Measurement Request, it MUST discard the received corresponding Measurement Request, it MUST discard the received
message with no further processing. message with no further processing.
The Start Point can use the routing metric objects inside the Metric The Start Point can use the routing metric objects inside the Metric
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 The mechanism defined in this document can potentially be used by a
compromised router to send bogus Measurement Requests to arbitrary compromised router to send bogus Measurement Requests to arbitrary
End Points. Such Measurement Requests may cause CPU overload in the End Points. If sufficient Measurement Requests are sent, then it may
routers in the network, drain their batteries and cause traffic cause CPU overload in the routers in the network, drain their
congestion in the network. Note that some of these problems would batteries and cause traffic congestion in the network. Note that
occur even if the compromised router were to generate bogus data some of these problems would occur even if the compromised router
traffic to arbitrary destinations. were to generate bogus data 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.
skipping to change at page 22, line 30 skipping to change at page 23, line 14
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 The measurement mechanism described in this document may potentially
be used by a rogue node to find out key information about the LLN, be used by a rogue router to measure routes from itself to other
e.g., the topological features of the LLN (such as the identity of routers and thus find out key information about the LLN, e.g., the
the key nodes in the topology) or the remaining energy levels topological features of the LLN (such as the identity of the key
[RFC6551] in the LLN routers. This information can potentially be routers in the topology) or the remaining energy levels [RFC6551] in
used to attack the LLN. To protect against such misuse, this the routers. This information can potentially be used to attack the
document allows RPL routers implementing this mechanism to not LLN. To protect against such misuse, this document allows RPL
process MO messages (or process such messages selectively) based on a routers implementing this mechanism to not process MO messages (or
local policy. Further, an LLN deployment may use Secure MO process such messages selectively) based on a local policy. Further,
Section 3.2 messages to invoke RPL-provided security mechanisms and an LLN deployment is required to support Secure MO (Section 3.2)
prevent misuse of the measurement mechanism by unauthorized nodes. 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
skipping to change at page 23, line 38 skipping to change at page 24, line 27
Joel Halpern, Matthias Philipp, Pascal Thubert, Richard Kelsey and Joel Halpern, Matthias Philipp, Pascal Thubert, Richard Kelsey and
Zach Shelby in the development of this document. 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-15 Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-16
(work in progress), December 2012. (work in progress), February 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
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012.
11.2. Informative References 11.2. Informative References
[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
Lossy Networks", RFC 5867, June 2010. Lossy Networks", RFC 5867, June 2010.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012.
[RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D.
Barthel, "Routing Metrics Used for Path Calculation in Barthel, "Routing Metrics Used for Path Calculation in
Low-Power and Lossy Networks", RFC 6551, March 2012. Low-Power and Lossy Networks", RFC 6551, March 2012.
Authors' Addresses Authors' Addresses
Mukul Goyal (editor) Mukul Goyal (editor)
University of Wisconsin Milwaukee University of Wisconsin Milwaukee
3200 N Cramer St 3200 N Cramer St
Milwaukee, WI 53211 Milwaukee, WI 53211
 End of changes. 41 change blocks. 
128 lines changed or deleted 159 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/