draft-ietf-roll-p2p-measurement-07.txt   draft-ietf-roll-p2p-measurement-08.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: June 27, 2013 E. Baccelli Expires: July 25, 2013 E. Baccelli
INRIA INRIA
A. Brandt A. Brandt
Sigma Designs Sigma Designs
J. Martocci J. Martocci
Johnson Controls Johnson Controls
December 24, 2012 January 21, 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-07 draft-ietf-roll-p2p-measurement-08
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 in a low power and lossy
network, thereby allowing the router to decide if it wants to network, thereby allowing the router to decide if it wants to
initiate the discovery of a better route. initiate the discovery of a better route.
Status of this Memo Status of this Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 27, 2013. This Internet-Draft will expire on July 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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) . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . 12
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 . . . . . . . . . 13
4.4. When Measuring A Source Route . . . . . . . . . . . . . . 14 4.4. When Measuring A Source Route . . . . . . . . . . . . . . 14
5. Processing a Measurement Request at an Intermediate Point . . 15 5. Processing a Measurement Request at an Intermediate Point . . 15
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 . . . . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . 17
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 . . . . . . . . . 18
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 . . . . . . . . . . . . . . . . . . . . . 19
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 . . . . . . . . . . . . . 20
7. Processing a Measurement Reply at the Start Point . . . . . . 21 7. Processing a Measurement Reply at the Start Point . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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]. 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
skipping to change at page 5, line 11 skipping to change at page 5, line 11
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
[I-D.ietf-roll-p2p-rpl] established using RPL [RFC6550] or P2P-RPL [I-D.ietf-roll-p2p-rpl] established using RPL [RFC6550] or P2P-RPL
[I-D.ietf-roll-p2p-rpl]. Such a route could also be a "mixed" route [I-D.ietf-roll-p2p-rpl]. Such a route could also be a "mixed" route
with the initial part consisting of hop-by-hop ascent to the root of with the initial part consisting of hop-by-hop ascent to the root of
a non-storing DAG [RFC6550] and the final part consisting of a a non-storing DAG [RFC6550] and the final part consisting of a
source-routed descent to the End Point. The Start Point decides what source-routed descent to the End Point. The Start Point decides what
metrics to measure and sends a Measurement Request message, carrying metrics to measure and sends a Measurement Request message, carrying
the desired routing metric objects, along the route. On receiving a the desired routing metric objects, along the route. If a Source
Route is being measured, the Measurement Request carries the route
inside an Address vector. If a Hop-by-hop Route is being measured,
the Measurement Request identifies the route by its RPLInstanceID
[RFC6550] (and, in case the RPLInstanceID is a local value, the Start
Point's IPv6 address associated with the route). On receiving a
Measurement Request, an Intermediate Point updates the routing metric Measurement Request, an Intermediate Point updates the routing metric
values inside the message and forwards it to the next hop on the values inside the message and forwards it to the next hop on the
route. Thus, the Measurement Request accumulates the values of the route. Thus, the Measurement Request accumulates the values of the
routing metrics for the complete route as it travels towards the End routing metrics for the complete route as it travels towards the End
Point. The Measurement Request may also accumulate a Source Route Point. Upon receiving the Measurement Request, the End Point
that the End Point may use to reach the Start Point. Upon receiving unicasts a Measurement Reply message, carrying the accumulated values
the Measurement Request, the End Point unicasts a Measurement Reply of the routing metrics, back to the Start Point. Optionally, the
message, carrying the accumulated values of the routing metrics, back Start Point may allow an Intermediate Point to generate the
to the Start Point. Optionally, the Start Point may allow an Measurement Reply if the Intermediate Point already knows the
Intermediate Point to generate the Measurement Reply if the relevant routing metric values along rest of the route.
Intermediate Point already knows the relevant routing metric values
along rest of the route. The Measurement Request may include an Address vector that serves one
of the following functions:
o To accumulate a Source Route for End Point's use: If a Hop-by-hop
Route with a local RPLInstanceID is being measured, the Start
Point may require each Intermediate Point to add its IPv6 address
to an Address vector inside the Measurement Request. The Source
Route, thus accumulated, can be used by the End Point to reach the
Start Point. In particular, the End Point may use the accumulated
Source Route to send the Measurement Reply back to the Start
Point. In this case, the Start Point includes a suitably-sized
Address vector in the Measurement Request. The size of the
Address vector puts a hard limit on the length of the accumulated
route. An Intermediate Point is not allowed to modify the size of
the Address vector and must discard a received Measurement Request
if the Address vector is not large enough to contain the complete
route.
o To carry the Source Route being measured: The Start Point may
insert an Address vector inside the Measurement Request to carry
the Source Route being measured. Also, the root of a global non-
storing DAG may insert an Address vector, carrying a Source Route
from itself to the End Point, inside a Measurement Request message
if this message had been traveling along this DAG so far. In both
cases, an Intermediate Point is not allowed to modify an existing
Address vector before forwarding the Measurement Request further.
In other words, an Intermediate Point is not allowed to modify the
Source Route along which the Measurement Request is currently
traveling.
3. The Measurement Object (MO) 3. The Measurement Object (MO)
This document defines two new RPL Control Message types, the This document defines two new RPL Control Message types, the
Measurement Object (MO), with code TBD1, and the Secure MO, with code Measurement Object (MO), with code TBD1, and the Secure MO, with code
TBD2. An MO serves as both Measurement Request and Measurement TBD2. An MO serves as both Measurement Request and Measurement
Reply. Reply.
3.1. Format of the base MO 3.1. Format of the base MO
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID | Compr |T|H|A|R|B|I| SequenceNo| Num | Index | | RPLInstanceID | Compr |T|H|A|R|B|I| SequenceNo| Num | Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Start Point Address | | Start Point Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| End Point Address | | End Point Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Address[1..Num] . . 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 9, line 21 skipping to change at page 9, line 36
eliding Compr number of prefix octets. eliding Compr number of prefix octets.
o Address[0..Num-1]: A vector of unicast IPv6 addresses (with Compr o Address[0..Num-1]: A vector of unicast IPv6 addresses (with Compr
number of prefix octets elided) representing a Source Route: number of prefix octets elided) representing a Source Route:
* Each element in the vector has size (16 - Compr) octets. * Each element in the vector has size (16 - Compr) octets.
* The total number of elements inside the Address vector is given * The total number of elements inside the Address vector is given
by the Num field. by the Num field.
* When the Measurement Request is traveling along a Hop-by-hop
Route with local RPLInstanceID and has the A flag set to one
(i.e., H = 1, RPLInstanceID has a local value, A = 1), the
Address vector is used to accumulate a Source Route that can be
used by the End Point, after reversal, to send the Measurement
Reply back to the Start Point. The route MUST be accumulated
in the Forward direction but the IPv6 addresses in the
accumulated route MUST be reachable in the Backward direction.
An Intermediate Point adding its address to the Address vector
MUST ensure that a routing loop involving this router does not
exist in the accumulated route.
* When the Measurement Request is traveling along a Source Route
(i.e., H = 0), the Address vector MUST contain a complete route
to the End Point and the IPv6 addresses in the Address vector
MUST be reachable in the Forward direction. A router (the
Start Point or an Intermediate Point) inserting an Address
vector inside a Measurement Request MUST ensure that no address
appears more than once inside the vector. Each router on the
way MUST ensure that a routing loop involving this router does
not exist within the Source Route. The Start Point MAY set the
R flag in the Measurement Request if the route in the Address
vector represents a complete route from the Start Point to the
End Point and this route can be used by the End Point, after
reversal, to send the Measurement Reply message back to the
Start Point (i.e., the IPv6 addresses in the Address vector are
reachable in the Backward direction).
* The Start Point and End Point addresses MUST NOT be included in * The Start Point and End Point addresses MUST NOT be included in
the Address vector. the Address vector.
* The Address vector MUST NOT contain any multicast addresses. * The Address vector MUST NOT contain any multicast addresses.
* If the Start Point wants to measure a Hop-by-hop Route with a
local RPLInstanceID and accumulate a Source Route for the End
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
1), it MUST include a suitably-sized Address vector in the
Measurement Request. As the Measurement Request travels over
the route being measured, the Address vector accumulates a
Source Route that can be used by the End Point, after reversal,
to reach (and, in particular, to send the Measurement Reply
back to) the Start Point. The route MUST be accumulated in the
Forward direction but the IPv6 addresses in the accumulated
route MUST be reachable in the Backward direction. An
Intermediate Point adding its address to the Address vector
MUST NOT modify the size of the Address vector.
* If the Start Point wants to measure a Source Route, it MUST
include an Address vector, containing the route being measured,
inside the Measurement Request. Similarly, if the Measurement
Request had been traveling along a global non-storing DAG so
far, the root of this DAG may insert an Address vector,
containing a Source Route from itself to the End Point, inside
the Measurement Request. In both cases, the Source Route
inside the Address vector MUST consist of IPv6 addresses
reachable in the Forward direction. Further, in both cases, an
Intermediate Point MUST NOT modify the contents of the existing
Address vector before forwarding the Measurement Request
further. In other words, an Intermediate Point MUST NOT modify
the Source Route along which the Measurement Request is
currently traveling. The Start Point MAY set the R flag in the
Measurement Request to one if the Source Route inside the
Address vector can be used by the End Point, after reversal, to
reach (and, in particular, to send the Measurement Reply back
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
vector are reachable in the Backward 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 does a Start Point set various fields inside
a Measurement Request in different cases. Section 5 describes how a Measurement Request in different cases. Section 5 describes how
does an Intermediate Point process a received Measurement Request does an Intermediate Point process a received Measurement Request
before forwarding it further. Section 6 describes how does the End before forwarding it further. Section 6 describes how does the End
Point process a received Measurement Request and generate a Point process a received Measurement Request and generate a
Measurement Reply. Finally, Section 7 describes how does the Start Measurement Reply. Finally, Section 7 describes how does the Start
Point process a received Measurement Reply. Point process a received Measurement Reply. In the following
discussion, any reference to discarding a received Measurement
Request/Reply with "no further processing" does not preclude updating
the appropriate error 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.
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
skipping to change at page 13, line 11 skipping to change at page 13, line 33
o End Point Address: MUST be set to a unicast IPv6 address of the o End Point Address: MUST be set to a unicast IPv6 address of the
End Point after eliding Compr number of prefix octets. End Point after eliding Compr number of prefix octets.
4.3. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With 4.3. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With
Route Accumulation On Route Accumulation On
If a Hop-by-hop Route with a local RPLInstanceID is being measured If a Hop-by-hop Route with a local RPLInstanceID is being measured
and the Start Point desires the MO to accumulate a Source Route for and the Start Point desires the MO to accumulate a Source Route for
the End Point to send the Measurement Reply message back, the MO MUST the End Point to send the Measurement Reply message back, the MO MUST
contain an Address vector and various MO fields MUST be set in the contain a suitably-sized Address vector and various MO fields MUST be
following manner: set in the following manner:
o RPLInstanceID: MUST be set to the RPLInstanceID of the route being o RPLInstanceID: MUST be set to the RPLInstanceID of the route being
measured. measured.
o Compr: MUST be set to specify the number of prefix octets that are o Compr: MUST be set to specify the number of prefix octets that are
elided from the IPv6 addresses in Start Point/End Point Address elided from the IPv6 addresses in Start Point/End Point Address
fields and the Address vector. fields and the Address vector.
o Type (T): MUST be set to one since the MO represents a Measurement o Type (T): MUST be set to one since the MO represents a Measurement
Request. Request.
skipping to change at page 15, line 18 skipping to change at page 15, line 41
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 Backward direction.
* To avoid loops in the Source Route, the Start Point MUST ensure
compliance to the following rules:
+ Any IPv6 address MUST NOT appear more than once in the
Address vector.
+ If the Address vector includes multiple IPv6 addresses
assigned to the Start Point's interfaces, such addresses
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.
5. Processing a Measurement Request at an Intermediate Point 5. Processing a Measurement Request at an Intermediate Point
A router (an Intermediate Point or the End Point) MAY discard a A router (an Intermediate Point or the End Point) MAY discard a
received MO with no processing to meet any policy-related goal. Such received MO with no processing to meet any policy-related goal. Such
policy goals may include the need to reduce the router's CPU load or policy goals may include the need to reduce the router's CPU load or
to enhance its battery life or to prevent misuse of this mechanism by to enhance its battery life or to prevent misuse of this mechanism by
unauthorized nodes. unauthorized nodes.
skipping to change at page 16, line 18 skipping to change at page 16, line 32
field) and processes the received MO accordingly in the manner field) and processes the received MO accordingly in the manner
specified next. specified next.
5.1. When Measuring A Hop-by-hop Route with a Global RPLInstanceID 5.1. When Measuring A Hop-by-hop Route with a Global RPLInstanceID
If a Hop-by-hop Route with a global RPLInstanceID is being measured If a Hop-by-hop Route with a global RPLInstanceID is being measured
(i.e. H = 1 and RPLInstanceID has a global value), the Intermediate (i.e. H = 1 and RPLInstanceID has a global value), the Intermediate
Point MUST process the received Measurement Request in the following Point MUST process the received Measurement Request in the following
manner. manner.
The Intermediate Point MUST discard the received Measurement Request If the Num field inside the received Measurement Request is not set
with no further processing if the Num field is not set to zero or if to zero, thereby implying that an Address vector is present, the
the Address vector is present in the received message. Intermediate Point MUST discard the received message with no further
processing.
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 then determine the next hop on the route
being measured using the RPLInstanceID and the End Point Address. If being measured using the RPLInstanceID and the End Point Address. If
the Intermediate Point is the root of the non-storing global DAG the Intermediate Point is the root of the non-storing global DAG
along which the received Measurement Request had been traveling so along which the received Measurement Request had been traveling so
far, it MUST process the received Measurement Request in the far, it MUST process the received Measurement Request in the
following manner: following manner:
o The router MUST discard the Measurement Request with no further o If the router does not know how to reach the End Point, it MUST
processing and MAY send an ICMPv6 Destination Unreachable (with discard the Measurement Request with no further processing and MAY
Code 0 - No Route To Destination) error message to the Start Point send an ICMPv6 Destination Unreachable (with Code 0 - No Route To
if it does not know how to reach the End Point. Destination) error message 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 17, line 20 skipping to change at page 17, line 35
specify a Source Route to the End Point inside the Address specify a Source Route to the End Point inside the Address
vector as per the following rules: vector as per the following rules:
+ The Address vector MUST contain a complete route from the + The Address vector MUST contain a complete route from the
router to the End Point (excluding the router and the End router to the End Point (excluding the router and the End
Point); Point);
+ The IPv6 addresses (with Compr prefix octets elided) in the + 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;
+ To avoid loops in the Source Route, the router MUST ensure
that
- Any IPv6 address MUST NOT appear more than once in the
Address vector;
- If the Address vector includes multiple IPv6 addresses
assigned to the router's interfaces, such addresses MUST
appear back to back inside the Address vector.
+ Each address appearing in the Address vector MUST be a + Each address appearing in the Address vector MUST be a
unicast address. unicast address.
* Specify in the Num field the number of address elements in the * Specify in the Num field the number of address elements in the
Address vector. Address vector.
* Set the Index field to zero to indicate the position in the * Set the Index field to zero to indicate the position in the
Address vector of the next hop on the route. Thus, Address[0] Address vector of the next hop on the route. Thus, Address[0]
element contains the address of the next hop on the route. element contains the address of the next hop on the route.
skipping to change at page 17, line 51 skipping to change at page 18, line 7
received Measurement Request as specified in Section 5.5. received Measurement Request as specified in Section 5.5.
5.2. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With 5.2. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With
Route Accumulation Off Route Accumulation Off
If a Hop-by-hop Route with a local RPLInstanceID is being measured If a Hop-by-hop Route with a local RPLInstanceID is being measured
and the route accumulation is off (i.e., H = 1, RPLInstanceID has a and the route accumulation is off (i.e., H = 1, RPLInstanceID has a
local value, A = 0), the Intermediate Point MUST process the received local value, A = 0), the Intermediate Point MUST process the received
Measurement Request in the following manner. Measurement Request in the following manner.
The Intermediate Point MUST discard the received Measurement Request If the Num field inside the received Measurement Request is not set
with no further processing if the Num field is not zero or if the to zero, thereby implying that an Address vector is present, the
Address vector is present in the received message. Intermediate Point MUST discard the received message with no further
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). The Intermediate Point MUST discard the Measurement measured). If the Intermediate Point can not determine the next hop,
Request with no further processing and MAY send an ICMPv6 Destination it MUST discard the Measurement Request with no further processing
Unreachable (with Code 0 - No Route To Destination) error message to and MAY send an ICMPv6 Destination Unreachable (with Code 0 - No
the Start Point if it can not determine the next hop. Otherwise, the Route To Destination) error message to the Start Point. Otherwise,
Intermediate Point MUST complete the processing of the received the Intermediate Point MUST complete the processing of the received
Measurement Request as specified in Section 5.5. 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.
The Intermediate Point MUST discard the received Measurement Request If the Num field inside the received Measurement Request is set to
with no further processing if the Num field is set to zero or if the zero, thereby implying that an Address vector is not present, the
Address vector is not present in the received message. Intermediate Point MUST discard the received message with no further
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). The Intermediate Point MUST discard the Measurement measured). If the Intermediate Point can not determine the next hop,
Request with no further processing and MAY send an ICMPv6 Destination it MUST discard the Measurement Request with no further processing
Unreachable (with Code 0 - No Route To Destination) error message to and MAY send an ICMPv6 Destination Unreachable (with Code 0 - No
the Start Point if it can not determine the next hop. The Route To Destination) error message to the Start Point. If the index
Intermediate Point MUST drop the received Measurement Request with no field has value Num - 1 and the next hop is not same as the End
further processing if the index field has value Num - 1 and the next Point, the Intermediate Point MUST drop the received Measurement
hop is not same as the End Point. 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 Intermediate Point MUST check if adding one of its (after eliding Compr prefix octets) at location Address[Index] and
IPv6 addresses to the the Address vector would create a routing loop then increment the Index field. The IPv6 address added to the
in the accumulated route. If yes, the router MUST discard the packet Address vector MUST be reachable in the Backward direction.
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.
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.
The Intermediate Point MUST discard the received Measurement Request If the Num field inside the received Measurement Request is set to
with no further processing if the Num field is set to zero or if the zero, thereby implying that an Address vector is not present, the
Address vector is not present in the received message. Intermediate Point MUST discard the received message with no further
processing.
The Intermediate Point MUST then determine the next hop on the route The Intermediate Point MUST verify that the Address[Index] element
being measured in the manner described below. The Intermediate Point lists one of its unicast IPv6 addresses, failing which it MUST
MUST verify that the Address[Index] element lists one of its unicast discard the Measurement Request with no further processing. The
IPv6 addresses, failing which it MUST discard the Measurement Request Intermediate Point MUST then increment the Index field and use the
with no further processing. To prevent loops, the Intermediate Point Address[Index] element as the next hop (unless Index value is now
MUST discard the Measurement Request with no further processing if Num). If the Index value is now Num, the Intermediate Point MUST use
the Address vector includes multiple IPv6 addresses assigned to its the End Point Address as the next hop.
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 The Intermediate Point MUST then complete the processing of the
received Measurement Request as specified in Section 5.5. received Measurement Request as specified in Section 5.5.
5.5. Final Processing 5.5. Final Processing
The Intermediate Point MUST drop the received Measurement Request The Intermediate Point MUST drop the received Measurement Request
with no further processing: with no further processing:
o If the next hop address is not a unicast address; or o If the next hop address is not a unicast address; or
skipping to change at page 21, line 34 skipping to change at page 21, line 30
reverse the Source Route contained in the Address vector and use reverse the Source Route contained in the Address vector and use
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.
The Start Point MUST discard the packet with no further processing if If the Start Point discovers that the received MO is not a
the received MO is not a Measurement Reply or if the Start Point has Measurement Reply or if it has no recollection of sending the
no recollection of sending the corresponding Measurement Request. corresponding Measurement Request, it MUST discard the received
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.
skipping to change at page 22, line 28 skipping to change at page 22, line 25
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
message if the next hop address is not on-link or if it is not a Measurement Request if the next hop address is not on-link or if
unicast address. it is not a unicast address.
o This document requires that a router must check the Source Route
inside the Address vector of each received MO message to ensure
that it does not contain a loop involving the router. The router
must drop the received packet if the Source Route does contain
such a loop. This and the previous two rules protect the network
against some of the security concerns even if a compromised node
inserts a malformed Address vector inside the MO message.
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 node to find out key information about the LLN,
e.g., the topological features of the LLN (such as the identity of e.g., the topological features of the LLN (such as the identity of
the key nodes in the topology) or the remaining energy levels the key nodes in the topology) or the remaining energy levels
[RFC6551] in the LLN routers. This information can potentially be [RFC6551] in the LLN routers. This information can potentially be
used to attack the LLN. To protect against such misuse, this used to attack the LLN. To protect against such misuse, this
document allows RPL routers implementing this mechanism to not document allows RPL routers implementing this mechanism to not
process MO messages (or process such messages selectively) based on a process MO messages (or process such messages selectively) based on a
local policy. Further, an LLN deployment may use Secure MO local policy. Further, an LLN deployment may use Secure MO
skipping to change at page 23, line 38 skipping to change at page 23, line 27
| Code | Description | Reference | | Code | Description | Reference |
+------+---------------------------+---------------+ +------+---------------------------+---------------+
| TBD1 | Measurement Object | This document | | TBD1 | Measurement Object | This document |
| TBD2 | Secure Measurement Object | This document | | TBD2 | Secure Measurement Object | This document |
+------+---------------------------+---------------+ +------+---------------------------+---------------+
RPL Control Codes RPL Control Codes
10. Acknowledgements 10. Acknowledgements
Authors gratefully acknowledge the contributions of Matthias Philipp, Authors gratefully acknowledge the contributions of Adrian Farrel,
Pascal Thubert, Richard Kelsey and Zach Shelby in the development of Joel Halpern, Matthias Philipp, Pascal Thubert, Richard Kelsey and
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-15
(work in progress), December 2012. (work in progress), December 2012.
 End of changes. 30 change blocks. 
160 lines changed or deleted 171 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/