draft-ietf-roll-p2p-measurement-01.txt   draft-ietf-roll-p2p-measurement-02.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: Standards Track Milwaukee Intended status: Experimental Milwaukee
Expires: January 12, 2012 E. Baccelli, Ed. Expires: May 1, 2012 E. Baccelli
INRIA INRIA
A. Brandt A. Brandt
Sigma Designs Sigma Designs
R. Cragie
Gridmerge Ltd
J. Martocci J. Martocci
Johnson Controls Johnson Controls
July 11, 2011 October 29, 2011
A Mechanism to Measure the Quality of a Point-to-point Route in a Low A Mechanism to Measure the Quality of a Point-to-point Route in a Low
Power and Lossy Network Power and Lossy Network
draft-ietf-roll-p2p-measurement-01 draft-ietf-roll-p2p-measurement-02
Abstract Abstract
This document specifies a mechanism that enables an RPL router to This document specifies a mechanism that enables an RPL router to
measure the quality of an existing route to another RPL router in a measure the quality of an existing route towards another RPL router
low power and lossy network, thereby allowing the router to decide if in a low power and lossy network, thereby allowing the router to
it wants to initiate the discovery of a more optimal route. decide if it wants to initiate the discovery of a better route.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 12, 2012. This Internet-Draft will expire on May 1, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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. Functional Overview . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The Measurement Object (MO) . . . . . . . . . . . . . . . . . 5 3. The Measurement Object (MO) . . . . . . . . . . . . . . . . . 4
4. Originating a Measurement Request . . . . . . . . . . . . . . 8 3.1. Format of the base MO . . . . . . . . . . . . . . . . . . 5
5. Processing a Measurement Request at an Intermediate Router . . 9 3.2. Secure MO . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Processing a Measurement Request at the Target . . . . . . . . 10 4. Originating a Measurement Request . . . . . . . . . . . . . . 9
7. Processing a Measurement Reply at the Origin . . . . . . . . . 11 4.1. To Measure A Hop-by-hop Route with a Global
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4.2. To Measure A Hop-by-hop Route with a Local
10. Authors and Contributors . . . . . . . . . . . . . . . . . . . 11 RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3. To Measure A Source Route . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 5. Processing a Measurement Request at an Intermediate Router . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . . 12 5.1. Determining Next Hop For An MO Measuring A Source Route . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2. Determining Next Hop For An MO Measuring A Hop-by-hop
Route . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Processing a Measurement Request at the Target . . . . . . . . 14
7. Processing a Measurement Reply at the Origin . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
Point to point (P2P) communication between arbitrary routers in a Low Point to point (P2P) communication between arbitrary routers in a Low
power and Lossy Network (LLN) is a key requirement for many power and Lossy Network (LLN) is a key requirement for many
applications [RFC5826][RFC5867]. RPL [I-D.ietf-roll-rpl], the IPv6 applications [RFC5826][RFC5867]. RPL [I-D.ietf-roll-rpl], the IPv6
Routing Protocol for LLNs, constrains the LLN topology to a Directed Routing Protocol for LLNs, constrains the LLN topology to a Directed
Acyclic Graph (DAG) built to optimize routing costs to reach the Acyclic Graph (DAG) built to optimize routing costs to reach the
DAG's root and requires the P2P routes to use the DAG links only. DAG's root and requires the P2P routes to use the DAG links only.
Such P2P routes may potentially be suboptimal and may lead to traffic Such P2P routes may potentially be suboptimal and may lead to traffic
congestion near the DAG root. Additionally, RPL is a proactive congestion near the DAG root. Additionally, RPL is a proactive
routing protocol and hence all P2P routes must be established ahead routing protocol and hence all P2P routes must be established ahead
of the time they are used. of the time they are used.
To ameliorate situations, where RPL's P2P routing functionality does To ameliorate situations, where RPL's P2P routing functionality does
not meet the requirements, [I-D.ietf-roll-p2p-rpl] describes a not meet the requirements, [I-D.ietf-roll-p2p-rpl] describes a
reactive mechanism to discover P2P routes that meet the specified reactive mechanism to discover P2P routes that meet the specified
performance criteria. This mechanism, henceforth referred to as the performance criteria. This mechanism, henceforth referred to as the
reactive P2P route discovery, requires the specification of routing reactive P2P route discovery, allows the specification of routing
constraints [I-D.ietf-roll-routing-metrics], that the discovered constraints [I-D.ietf-roll-routing-metrics], that the discovered
routes must satisfy. In some cases, the application requirements or routes must satisfy. In some cases, the application requirements or
the LLN's topological features allow a router to infer the routing the LLN's topological features allow a router to infer the routing
constraints intrinsically. For example, the application may require constraints intrinsically. For example, the application may require
the end-to-end loss rate and/or latency on the route to be below the end-to-end loss rate and/or latency on the route to be below
certain thresholds or the LLN topology may be such that a router can certain thresholds or the LLN topology may be such that a router can
safely assume its destination to be less than a certain number of safely assume its destination to be less than a certain number of
hops away from itself. hops away from itself.
When the existing routes are deemed unsatisfactory but the router When the existing routes are deemed unsatisfactory but the router
skipping to change at page 4, line 27 skipping to change at page 4, line 27
Origin: The origin refers to the router that initiates the Origin: The origin refers to the router that initiates the
measurement process defined in this document and is the start point measurement process defined in this document and is the start point
of the P2P route being measured. of the P2P route being measured.
Target: The target refers to the router at the end point of the P2P Target: The target refers to the router at the end point of the P2P
route being measured. route being measured.
Intermediate Router: A router, other than the origin and the target, Intermediate Router: A router, other than the origin and the target,
on the P2P route being measured. on the P2P route being measured.
2. Functional Overview 2. Overview
The mechanism described in this document can be used by an origin to The mechanism described in this document can be used by an origin in
measure the aggregated values of the routing metrics along a P2P an RPL domain to measure the aggregated values of the routing metrics
route to a target in the LLN. Such a route could be a source route along a P2P route to a target within the same RPL domain. Such a
or a hop-by-hop route established using RPL [I-D.ietf-roll-rpl] or route could be a source route or a hop-by-hop route established using
the reactive P2P route discovery [I-D.ietf-roll-p2p-rpl]. The origin RPL [I-D.ietf-roll-rpl] or the reactive P2P route discovery
sends a Measurement Request message along the route. The Measurement [I-D.ietf-roll-p2p-rpl]. The origin sends a Measurement Request
Request accumulates the values of the routing metrics as it travels message along the route. The Measurement Request accumulates the
towards the target. Upon receiving the Measurement Request, the values of the routing metrics as it travels towards the target. Upon
target unicasts a Measurement Reply message, carrying the accumulated receiving the Measurement Request, the target unicasts a Measurement
values of the routing metrics, back to the origin. Reply message, carrying the accumulated values of the routing
metrics, back to the origin. Optionally, the origin may allow an
intermediate route to generate the Measurement Reply if it already
knows the relevant routing metric values along rest of the route.
3. The Measurement Object (MO) 3. The Measurement Object (MO)
This document defines two new RPL Control Message types, the
Measurement Object (MO), with code 0x06 (to be confirmed by IANA),
and the Secure MO, with code 0x86 (to be confirmed by IANA). An MO
serves as both Measurement Request and Measurement Reply.
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 | SequenceNo | Compr |T|H|A|R| Num | Index | | RPLInstanceID | Compr |T|H|A|R|B|I| SequenceNo| Num | Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Origin Address | | Origin Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Target Address | | Target Address |
| | | |
| | | |
skipping to change at page 5, line 33 skipping to change at page 5, line 33
. Address[1..Num] . . Address[1..Num] .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Metric Container Option(s) . . Metric Container Option(s) .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of the Measurement Object (MO) Figure 1: Format of the base Measurement Object (MO)
This document defines a new RPL Control Message type, the Measurement The format of a base MO is shown in Figure 1. A base MO consists of
Object (MO), with code 0x06 (to be confirmed by IANA) that serves as the following fields:
both Measurement Request and Measurement Reply. The format of an MO
is shown in Figure 1. An MO consists of the following fields:
o RPLInstanceID: Relevant only if the MO travels along a hop-by-hop o RPLInstanceID: Relevant only if the MO travels along a hop-by-hop
route. This field identifies the RPLInstanceID of the hop-by-hop route. This field identifies the RPLInstanceID of the hop-by-hop
route being measured. If the route being measured is a source route being measured. If the route being measured is a source
route, this field MUST be set to 10000000 on transmission and route, this field MUST be set to 10000000 on transmission and
ignored on reception. ignored on reception.
o SequenceNo: An 8-bit sequence number that uniquely identifies a o Compr: In many LLN deployments, IPv6 addresses share a well known,
Measurement Request and the corresponding Measurement Reply. common prefix. In such cases, the common prefix can be elided
when specifying IPv6 addresses in Origin/Target Address fields and
o Compr: A 4-bit unsigned integer indicating the number of prefix the Address vector. The "Compr" field is a 4-bit unsigned integer
octets that are elided from the IPv6 addresses in Origin/Target that indicates the number of prefix octets that are elided from
Address fields and the Address vector. For example, Compr value the IPv6 addresses in Origin/Target Address fields and the Address
will be 0 if full IPv6 addresses are carried in the Origin/Target vector. The Compr value will be 0 if full IPv6 addresses are
Address fields and the Address vector. carried in the Origin/Target Address fields and the Address
vector.
o Type (T): This flag is set if the MO represents a Measurement o Type (T): This flag is set if the MO represents a Measurement
Request. The flag is cleared if the MO is a Measurement Reply. Request. The flag is cleared if the MO is a Measurement Reply.
o Hop-by-hop (H): This flag is set if the MO travels along a hop-by- o Hop-by-hop (H): This flag is set if the MO travels along a hop-by-
hop route. In that case, the hop-by-hop route is identified by hop route. In that case, the hop-by-hop route is identified by
the RPLInstanceID and, if the RPLInstanceID is a local value, the the RPLInstanceID and, if the RPLInstanceID is a local value, the
Origin Address serving as the DODAGID. This flag is cleared if Origin Address serving as the DODAGID. This flag is cleared if
the MO travels along a source route specified in the Address the MO travels along a source route specified in the Address
vector. Note that, in case the P2P route being measured lies vector. Note that, in case the P2P route being measured lies
along a non-storing DAG, an MO message may travel along a hop-by- along a non-storing DAG, an MO message may travel along a hop-by-
hop route till it reaches the DAG's root, which then sends it hop route till it reaches the DAG's root, which then sends it
along a source route to its destination. In that case, the DAG along a source route to its destination. In that case, the DAG
root will reset the H flag and also insert the source route to the root will reset the H flag and also insert the source route to the
destination inside the Address vector. destination inside the Address vector.
o Accumulate Route (A): This flag is relevant only if the MO o Accumulate Route (A): This flag is relevant only if the MO
represents a Measurement Request that travels along a hop-by-hop represents a Measurement Request that travels along a hop-by-hop
route represented by a local RPLInstanceID. When this flag is route represented by a local RPLInstanceID. In other words, this
relevant, a value 1 in the flag indicates that the Measurement flag MAY be set only if T = 1, H = 1 and the RPLInstanceID field
Request MUST accumulate a source route for use by the target to has a local value. Otherwise, this flag MUST be cleared. A value
send the Measurement Reply back to the origin. In this case, the 1 in this flag indicates that the Measurement Request MUST
accumulate a source route for use by the target to send the
Measurement Reply back to the origin. In this case, the
intermediate routers MUST add their IPv6 addresses (after eliding intermediate routers MUST add their IPv6 addresses (after eliding
Compr number of prefix octets) to the Address vector in the manner Compr number of prefix octets) to the Address vector in the manner
specified later. specified later.
o Reverse (R): This flag is relevant only if the MO represents a o Reverse (R): This flag is relevant only if the MO represents a
Measurement Request that travels along a source route, specified Measurement Request that travels along a source route, specified
in the Address vector, to the target. When this flag is relevant, in the Address vector, to the target. In other words, this flag
a value 1 in the flag indicates that the Address vector contains a MAY be set only if T = 1 and H = 0. Otherwise, this flag MUST be
complete source route from the origin to the target, which can be cleared. A value 1 in the flag indicates that the Address vector
used, after reversal, by the target to source route the contains a complete source route from the origin to the target,
Measurement Reply message back to the origin. which can be used, after reversal, by the target to source route
the Measurement Reply message back to the origin.
o Back Request (B): This flag serves as a request to the target to
send a Measurement Request towards the origin. The origin MAY set
this flag if it wants to make such a request to the target. On
receiving this request, the target MAY generate a Measurement
Request to measure the cost of its current (or the most preferred)
route to the origin. Receipt of this Measurement Request would
allow the origin to know the cost of the back route from the
target to itself and thus determine the round-trip cost of
reaching the target.
o Intermediate Reply (I): Relevant only if a hop-by-hop route is
being measured, this flag serves as a permission to an
intermediate router to generate a Measurement Reply if it knows
the cost of the rest of the route being measured. The origin MAY
set this flag if a hop-by-hop route is being measured (i.e., H =
1) and the origin wants to allow the intermediate routers to
generate the Measurement Reply in response to this Measurement
Request. Setting this flag may be useful in scenarios where Hop
Count [I-D.ietf-roll-routing-metrics] is the routing metric of
interest and the origin expects an intermediate router (e.g. the
root of a non-storing DAG or a common ancestor of the origin and
the target in a storing DAG) to know the Hop Count of the
remainder of the route to the target. This flag MUST be cleared
if the route being measured is a source route (i.e., H = 0).
o SequenceNo: A 6-bit sequence number, assigned by the origin, that
allows the origin to uniquely identify a Measurement Request and
the corresponding Measurement Reply.
o Num: This field indicates the number of fields in the Address o Num: This field indicates the number of fields in the Address
vector. If the value of this field is zero, the Address vector is vector. If the value of this field is zero, the Address vector is
not present in the MO. not present in the MO.
o Index: If the Measurement Request is traveling along a source o Index: If the Measurement Request is traveling along a source
route contained in the Address vector, this field indicates the route contained in the Address vector (T=1,H=0), this field
index in the Address vector of the next hop on the route. If the indicates the index in the Address vector of the next hop on the
Measurement Request is traveling along a hop-by-hop route with a route. If the Measurement Request is traveling along a hop-by-hop
local RPLInstanceID and the A flag is set, this field indicates route with a local RPLInstanceID and the A flag is set
the index in the Address vector where an intermediate router (T=1,H=1,A=1 and RPLInstanceID field has a local value), this
receiving the MO message must store its IPv6 address. Otherwise, field indicates the index in the Address vector where an
this field MUST be set to zero on transmission and ignored on intermediate router receiving the MO message must store its IPv6
reception. address. Otherwise, this field MUST be set to zero on
transmission and ignored on reception.
o Origin Address: An IPv6 address of the origin after eliding Compr o Origin Address: An IPv6 address of the origin after eliding Compr
number of prefix octets. If the MO is traveling along a hop-by- number of prefix octets. If the MO is traveling along a hop-by-
hop route and the RPLInstanceID field indicates a local value, the hop route and the RPLInstanceID field indicates a local value, the
Origin Address field MUST contain the DODAGID value that, along Origin Address field MUST contain the DODAGID value that, along
with the RPLInstanceID, uniquely identifies the hop-by-hop route with the RPLInstanceID, uniquely identifies within the RPL domain
being measured. the hop-by-hop route being measured.
o Target Address: An IPv6 address of the target after eliding Compr o Target Address: An IPv6 address of the target after eliding Compr
number of prefix octets. number of prefix octets.
o Address[1..Num]: A vector of IPv6 addresses (with Compr number of o Address[1..Num]: A vector of IPv6 addresses (with Compr number of
prefix octets elided) representing a (partial) route from the prefix octets elided) representing a source route to the target:
origin to the target:
* Each element in the vector has size (16 - Compr) octets. * Each element in the vector has size (16 - Compr) octets.
* The total number of elements inside the Address vector is given * The total number of elements inside the Address vector is given
by the Num field. by the Num field.
* When the Measurement Request is traveling along a hop-by-hop * When the Measurement Request is traveling along a hop-by-hop
route with local RPLInstanceID and has the A flag set, the route with local RPLInstanceID and has the A flag set, the
Address vector is used to accumulate a route to be used by the Address vector is used to accumulate a source route to be used
target to send the Measurement Reply back to the origin. In by the target to send the Measurement Reply back to the origin.
this case, the route MUST be accumulated in the forward In this case, the route MUST be accumulated in the forward
direction, i.e., from the origin to the target. The target direction, i.e., from the origin to the target. The target
router would reverse this route to obtain a source route from router would reverse this route to obtain a source route from
itself to the origin. The IPv6 addresses in the accumulated itself to the origin. The IPv6 addresses in the accumulated
route MUST be accessible in the backward direction. An route MUST be accessible in the backward direction. An
intermediate router adding its address to the Address vector intermediate router adding its address to the Address vector
MUST ensure that its address does not already exist in the MUST ensure that its address does not already exist in the
vector. vector.
* When the Measurement Request is traveling along a source route, * When the Measurement Request is traveling along a source route,
the Address vector MUST contain a complete route to the target the Address vector MUST contain a complete route to the target
and the IPv6 addresses in the Address vector MUST be accessible and the IPv6 addresses in the Address vector MUST be accessible
in the forward direction, i.e., from the origin to the target. in the forward direction, i.e., from the origin to the target.
A router (the origin or an intermediate router) specifying a A router (origin or an intermediate router) inserting an
route to the target in the Address vector MUST ensure that the Address vector inside an MO MUST ensure that no address appears
vector does not contain any address more than once. The origin more than once inside the vector. Each router on the way MUST
may set the R flag in the MO if the route in the Address vector ensure that the loops do not exist within the source route.
represents a complete route from the origin to the target and The origin may set the R flag in the MO if the route in the
this route can be used after reversal by the target to send the Address vector represents a complete route from the origin to
Measurement Reply message back to the origin. the target and this route can be used after reversal by the
target to send the Measurement Reply message back to the
origin.
* The origin and target addresses MUST NOT be included in the * The origin and target addresses MUST NOT be included in the
Address vector. Address vector.
* The Address vector MUST NOT contain any multicast addresses. * The Address vector MUST NOT contain any multicast addresses.
o Metric Container Options: An MO MUST contain one or more Metric o Metric Container Options: An MO MUST contain one or more Metric
Container options to accumulate routing metric values for the Container options to accumulate routing metric values for the
route being measured. route being measured.
3.2. Secure MO
A Secure MO message follows the format in Figure 7 of
[I-D.ietf-roll-rpl], where the base format is the base MO shown in
Figure 1.
4. Originating a Measurement Request 4. Originating a Measurement Request
If an origin needs to measure the routing metric values along a P2P If an origin needs to measure the routing metric values along a P2P
route towards a target, it generates an MO message and sets its route towards a target, it generates an MO message and sets its
fields in the manner described above. Specifically, the origin MUST fields in the manner described below. Additionally, the origin MUST
set the T flag to 1 to indicate that the MO represents a Measurement set the T flag to 1 to indicate that the MO represents a Measurement
Request. Request. The origin MUST also include one or more Metric Container
options inside the MO that carry the routing metric objects of
interest. If required, the origin must also initiate these routing
metric objects by including the values of the routing metrics for the
first hop on the P2P route being measured.
If a source route is being measured, the origin MUST do the After setting the MO fields as described below, the origin MUST
following: unicast the MO message to the next hop on the P2P route.
o specify the complete source route to the target inside the Address 4.1. To Measure A Hop-by-hop Route with a Global RPLInstanceID
vector;
o specify in the Num field the number of address elements in the If a hop-by-hop route with a global RPLInstanceID is being measured,
Address vector; the MO message MUST NOT contain the Address vector and the following
MO fields MUST be set in the manner specified below:
o set the Index field to value zero; o Hop-by-hop (H): This flag MUST be set;
o set the R flag if the route in the Address vector can be used o Accumulate Route (A): This flag MUST be cleared;
after reversal by the target to source route the Measurement Reply
message back to the origin. o Reverse (R): This flag MUST be cleared;
o Back Request (B): This flag MAY be set if the origin wants to
request the target to generate a Measurement Request back to
itself;
o Intermediate Reply (I): This flag MAY be set if the origin wants
to permit the intermediate routers to generate the Measurement
Reply on the target's behalf;
o Num: This field MUST be set to zero;
o Index: This field MUST be set to zero.
4.2. To Measure A Hop-by-hop Route with a Local RPLInstanceID
If a hop-by-hop route with a local RPLInstanceID is being measured
and the MO is not accumulating a source route for the target's use,
the MO message MUST NOT contain the Address vector and the following
MO fields MUST be set in the manner specified below:
o Hop-by-hop (H): This flag MUST be set;
o Accumulate Route (A): This flag MUST be cleared;
o Reverse (R): This flag MUST be cleared;
o Back Request (B): This flag MAY be set if the origin wants to
request the target to generate a Measurement Request back to
itself;
o Intermediate Reply (I): This flag MAY be set if the origin wants
to permit the intermediate routers to generate the Measurement
Reply on the target's behalf;
o Num: This field MUST be set to zero;
o Index: This field MUST be set to zero;
o Origin Address: This field MUST contain the DODAGID value (after
eliding Compr number of prefix octets) associated with the route
being measured.
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 origin desires the MO to accumulate a source route for the and the origin desires the MO to accumulate a source route for the
target to send the Measurement Reply message back, it MUST do the target to send the Measurement Reply message back, it MUST set the
following: following MO fields in the manner specified below:
o set A flag to 1; o Hop-by-hop (H): This flag MUST be set;
o include a suitably sized, empty Address vector (with all bits set o Accumulate Route (A): This flag MUST be set;
to zero) in the MO;
o specify in the Num field the number of address elements that can o Reverse (R): This flag MUST be cleared;
fit inside the Address vector;
o set the Index field to value zero. o Back Request (B): This flag MAY be set if the origin wants to
request the target to generate a Measurement Request back to
itself;
The origin MUST include one or more Metric Container options inside o Intermediate Reply (I): This flag MAY be set if the origin wants
the MO that carry the routing metric objects of interest. If to permit the intermediate routers to generate the Measurement
required, the origin must also initiate these routing metric objects Reply on the target's behalf;
by including the values of the routing metrics for the first hop on
the P2P route being measured.
After setting the MO fields as described above, the origin MUST o Address vector: The Address vector must be large enough to
unicast the MO message to the next hop on the P2P route. accomodate a complete source route from the origin to the target.
All the bits in the Address vector field MUST be set to zero;
o Num: This field MUST specify the number of address elements that
can fit inside the Address vector;
o Index: This field MUST be set to 1;
o Origin Address: This field MUST contain the DODAGID value (after
eliding Compr number of prefix octets) associated with the route
being measured.
4.3. To Measure A Source Route
If a source route is being measured, the origin MUST set the
following MO fields in the manner specified below:
o RPLInstanceID: This field MUST be set to 10000000;
o Hop-by-hop (H): This flag MUST be cleared;
o Accumulate Route (A): This flag MUST be cleared;
o Reverse (R): This flag MUST be set if the source route in the
Address vector can be reversed and used by the target to source
route the Measurement Reply message back to the origin.
Otherwise, this flag MUST be cleared;
o Back Request (B): This flag MAY be set if the origin wants to
request the target to generate a Measurement Request back to
itself;
o Intermediate Reply (I): This flag MUST be cleared.
o Address vector:
* The Address vector MUST contain a complete route from the
origin to the target (excluding the origin and the target);
* The IPv6 addresses (with Compr prefix octets elided) in the
Address vector MUST be accessible in the forward direction,
i.e., from the origin to the target;
* To prevent loops in the source route, the origin 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 origin's interfaces, such addresses MUST
appear back to back inside the Address vector.
* Each address appearing in the Address vector MUST be a unicast
address.
o Num: This field MUST be set to indicate the number of elements in
the Address vector;
o Index: This field MUST be set to 1.
The origin MUST NOT send the packet further if the next hop address
on the source route is not on-link.
5. Processing a Measurement Request at an Intermediate Router 5. Processing a Measurement Request at an Intermediate Router
When a router receives an MO, it examines if one of its IPv6 A router MAY discard a received MO with no further processing to meet
addresses is listed as the Origin or the Target Address. If not, the any policy-related goal. Such policy goals may include the need to
router processes the received message in the following manner. reduce the router's CPU load or to enhance its battery life.
On receiving an MO, if a router chooses to process the packet
further, it MUST check if one of its IPv6 addresses is listed as
either the Origin or the Target Address. If not, the router
considers itself an Intermediate Router and MUST process the received
MO in the following manner.
An intermediate router MUST discard the packet with no further An intermediate router MUST discard the packet with no further
processing if the received MO is not a Measurement Request. processing if the received MO is not a Measurement Request.
The router then determines the next hop on the P2P route being If the I flag is set in the received MO and the intermediate router
measured. In case the received MO has a clear H flag, the router knows the values of the routing metrics, specified in the Metric
increments the Index field and uses the Address[Index] element as the Container, for the remainder of the route, it MAY generate a
next hop. If this element does not exist, the router uses the Target Measurement Reply on the target's behalf in the manner specified in
Address as the next hop. Section 6 (after including in the Measurement Reply the relevant
routing metric values for the complete route being measured).
Otherwise, the intermediate router MUST process the received MO in
the following manner.
If the received MO has H flag set to 1, the router uses the The router MUST determine the next hop on the P2P route being
RPLInstanceID, the Target Address and, if RPLInstanceID is a local measured in the manner described below. The router MUST drop the MO
value, the DODAGID (same as the Origin Address) to determine the next with no further processing and MAY send an ICMPv6 Destination
hop for the MO. Also, Unreachable (with Code 0 - No Route To Destination) error message to
the source of the message if it can not determine the next hop for
the message.
After determining the next hop, the router MUST update the routing
metric objects, contained in the Metric Container options inside the
MO, either by updating the aggregated value for the routing metric or
by attaching the local values for the metric inside the object.
After updating the routing metrics, the router MUST unicast the MO to
the next hop.
5.1. Determining Next Hop For An MO Measuring A Source Route
In case the received MO is measuring a source route (H=0), the router
MUST increment the Index field and use the Address[Index] element as
the next hop. If Index is greater than Num, the router MUST use the
Target Address as the next hop.
An intermediate router MUST discard the MO packet with no further
processing if the next hop address is not on-link or is not a unicast
address. To prevent loops, an intermediate router MUST check if the
Address vector includes multiple IPv6 addresses assigned to the
router's interfaces and if such addresses do not appear back to back
inside the Address vector. In this case, the router MUST discard the
MO packet with no further processing. An MO message MUST NOT leave
the RPL domain where it originated. Hence, an intermediate router
MUST discard an MO message traveling along a source route if the next
hop on the way does not lie within the RPL domain.
5.2. Determining Next Hop For An MO Measuring A Hop-by-hop Route
If the received MO is measuring a hop-by-hop route (H=1), the router
MUST use the RPLInstanceID, the Target Address and, if RPLInstanceID
is a local value, the DODAGID (same as the Origin Address) to
determine the next hop for the MO. Moreover,
o If the RPLInstanceID of the hop-by-hop route is a local value and o If the RPLInstanceID of the hop-by-hop route is a local value and
the A flag is set, the router MUST store one of its IPv6 addresses the A flag is set, the router MUST check if the Address vector
(after eliding Compr bytes and making sure that the Address vector already contains one of its IPv6 addresses. If yes, the router
does not already contains one of its IPv6 addresses) at location MUST discard the packet with no further processing. Otherwise,
Address[Index] and then increments the Index field. the router MUST store one of its IPv6 addresses (after eliding
Compr prefix octets) at location Address[Index] and then increment
the Index field.
o If the router is the root of the non-storing DAG along which the o If the router is the root of the non-storing DAG along which the
received MO message has been traveling, the router MUST do the received MO message has been traveling, the router MUST do the
following: following:
* reset the H, A and R flags; * Reset the H, A and R flags.
* insert a source route to the target inside the Address vector; * Insert a source route to the target inside the Address vector
as per the following rules:
* specify in the Num field the number of address elements in the + The Address vector MUST contain a complete route from the
Address vector; router to the target (excluding the router and the target);
* set the Index field to value zero; + The IPv6 addresses (with Compr prefix octets elided) in the
Address vector MUST be accessible in the forward direction,
i.e., towards the target;
The router MUST drop the MO with no further processing and send an + To prevent loops in the source route, the router MUST ensure
ICMPv6 Destination Unreachable error message to the source of the that
message if it can not determine the next hop for the message.
After determining the next hop, the router updates the routing metric - Any IPv6 address MUST NOT appear more than once in the
objects, contained in the Metric Container options inside the MO, Address vector;
either by updating the aggregated value for the routing metric or by
attaching the local values for the metric inside the object. The
router MUST drop the MO with no further processing and send a
suitable ICMPv6 error message to the source of the message if the
router does not know the relevant routing metric values for the next
hop.
After updating the routing metrics, the router MUST unicast the MO to - If the Address vector includes multiple IPv6 addresses
the next hop. 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
unicast address.
* Specify in the Num field the number of address elements in the
Address vector.
* Set the Index field to 1.
6. Processing a Measurement Request at the Target 6. Processing a Measurement Request at the Target
When a router receives an MO, it examines if one of its IPv6 On receiving an MO, if a router chooses to process the packet further
addresses is listed as the Target Address. If yes, the router and finds one of its IPv6 addresses listed as the Target Address, it
processes the received message in the following manner. MUST process the received MO in the following manner.
An intermediate router MUST discard the packet with no further The target MUST discard the packet with no further processing if the
processing if the received MO is not a Measurement Request. received MO is not a Measurement Request.
The target then updates the routing metrics objects in the Metric The target MUST update the routing metric objects in the Metric
Container options if required and generates a Measurement Reply Container options if required and MAY note the measured values for
message. The received Measurement Request message can be trivially the complete route if desired.
converted into the Measurement Reply by reseting the T flag to zero.
The target MAY remove the Address vector from the Measurement Reply The target MUST generate a Measurement Reply message. The received
if desired. The target then unicasts the Measurement Reply back to Measurement Request message can be trivially converted into the
the origin: Measurement Reply by reseting the T flag to zero. The target MAY
remove the Address vector from the Measurement Reply if desired. The
target MUST then unicast the Measurement Reply back to the origin:
o If the Measurement Request traveled along a DAG with a global o If the Measurement Request traveled along a DAG with a global
RPLInstanceID, the Measurement Reply MAY be unicast back to the RPLInstanceID, the Measurement Reply MAY be unicast back to the
origin along the same DAG. origin 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 the A flag inside the received message a local RPLInstanceID and the A flag inside the received message
is set, the target MAY reverse the source route contained in the is set, the target MAY reverse the source route contained in the
Address vector and use it to send the Measurement Reply back to Address vector and use it to send the Measurement Reply back to
the origin. the origin.
o If the Measurement Request traveled along a source route and the R o If the Measurement Request traveled along a source route and the R
flag inside the received message it set, the target MAY reverse flag inside the received message is set, the target MAY reverse
the source route contained in the Address vector and use it to the source route contained in the Address vector and use it to
send the Measurement Reply back to the origin. send the Measurement Reply back to the origin.
If the B flag is set in the received Measurement Request, the target
MAY generate a new Measurement Request to measure the cost of its
current (or the most preferred) route to the origin. The routing
metrics used in the new Measurement Request MUST include the routing
metrics specified in the received Measurement Request.
7. Processing a Measurement Reply at the Origin 7. Processing a Measurement Reply at the Origin
When a router receives an MO, it examines if one of its IPv6 When a router receives an MO, it examines if one of its IPv6
addresses is listed as the Origin Address. If yes, the router addresses is listed as the Origin Address. If yes, the router MUST
processes the received message in the following manner. process the received message in the following manner.
The origin MUST discard the packet with no further processing if the The origin MUST discard the packet with no further processing if the
received MO is not a Measurement Reply or if the origin has no received MO is not a Measurement Reply or if the origin has no
recollection of sending a Measurement Request with the sequence recollection of sending a Measurement Request with the sequence
number listed in the received MO. number listed in the received MO.
The origin then examines the routing metric objects inside the Metric The origin SHOULD examine the routing metric objects inside the
Container options to evaluate the quality of the measured P2P route. Metric Container options to evaluate the quality of the measured P2P
If a routing metric object contains local metric values recorded by route. If a routing metric object contains local metric values
enroute routers, the origin MAY aggregate these local values into an recorded by routers on the route, the origin MAY aggregate these
end-to-end value as per the aggregation rules for the metric. local values into an end-to-end value as per the aggregation rules
for the metric.
8. Security Considerations 8. Security Considerations
TBA The mechanism defined in this document can potentially be used by a
compromised router to generate bogus measurement requests to
arbitrary target routers. Such bogus measurement requests may cause
processing overload in the routers in the network, drain their
batteries and cause traffic congestion in the network. Note that
some of these problems would occur even if the compromised router
were to generate bogus data traffic to arbitrary destinations.
9. IANA Considerations Since a Measurement Request can travel along a source route specified
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
address such concerns, the mechanism described in this document
includes several remedies:
TBA o This document requires that a route inserted inside the Address
vector must be a strict source route and must not include any
multicast addresses.
10. Authors and Contributors o This document requires that an MO message must not cross the
boundaries of the RPL domain where it is originated. Hence, any
security problems associated with the mechanism would be limited
to the RPL domain where the MO message is generated.
In addition to the editors, the authors of this document include the o A router must drop a received MO message if the next hop address
following individuals (listed in alphabetical order). is not on-link or if it is not a unicast address.
Anders Brandt, Sigma Designs, Emdrupvej 26A, 1., Copenhagen, Dk-2100, o A router must check the source route inside the Address vector of
Denmark. Phone: +45 29609501; Email: abr@sdesigns.dk 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
rule protect the network against some of the security concerns
even if a compromised node inserts the Address vector inside the
MO message.
Robert Cragie, Gridmerge Ltd, 89 Greenfield Crescent, Wakefieldm WF4 9. IANA Considerations
4WA, UK. Phone: +44 1924910888; Email: robert.cragie@gridmerge.com
Jerald Martocci, Johnson Controls, Milwaukee, WI 53202, USA. Phone: IANA is requested to allocate a new code point in the "RPL Control
+1 414 524 4010; Email:jerald.p.martocci@jci.com Codes" registry for the "Measurement Object" described in this
document.
Charles Perkins, Tellabs Inc., USA. Email:charliep@computer.org +------+---------------------------+---------------+
| Code | Description | Reference |
+------+---------------------------+---------------+
| 0x06 | Measurement Object | This document |
| 0x86 | Secure Measurement Object | This document |
+------+---------------------------+---------------+
Authors gratefully acknowledge the contributions of Richard Kelsey RPL Control Codes
and Zach Shelby in the development of this document.
11. References 10. Acknowledgements
Authors gratefully acknowledge the contributions of Pascal Thubert,
Richard Kelsey and Zach Shelby in the development of this document.
11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References 11.2. Informative References
[I-D.ietf-roll-p2p-rpl] [I-D.ietf-roll-p2p-rpl]
Goyal, M., Baccelli, E., Brandt, A., Cragie, R., and J. Goyal, M., Baccelli, E., Philipp, M., Brandt, A., Cragie,
Martocci, "Reactive Discovery of Point-to-Point Routes in R., and J. Martocci, "Reactive Discovery of Point-to-Point
Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-03 Routes in Low Power and Lossy Networks",
(work in progress), May 2011. draft-ietf-roll-p2p-rpl-04 (work in progress), July 2011.
[I-D.ietf-roll-routing-metrics] [I-D.ietf-roll-routing-metrics]
Vasseur, J., Kim, M., Pister, K., Dejean, N., and D. Vasseur, J., Kim, M., Pister, K., Dejean, N., and D.
Barthel, "Routing Metrics used for Path Calculation in Low Barthel, "Routing Metrics used for Path Calculation in Low
Power and Lossy Networks", Power and Lossy Networks",
draft-ietf-roll-routing-metrics-19 (work in progress), draft-ietf-roll-routing-metrics-19 (work in progress),
March 2011. March 2011.
[I-D.ietf-roll-rpl] [I-D.ietf-roll-rpl]
Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
Vasseur, "RPL: IPv6 Routing Protocol for Low power and Vasseur, "RPL: IPv6 Routing Protocol for Low power and
Lossy Networks", draft-ietf-roll-rpl-19 (work in Lossy Networks", draft-ietf-roll-rpl-19 (work in
progress), March 2011. progress), March 2011.
[I-D.ietf-roll-terminology] [I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-05 (work in Networks", draft-ietf-roll-terminology-06 (work in
progress), March 2011. progress), September 2011.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095,
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.
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
USA USA
Phone: +1 414 2295001 Phone: +1 414 2295001
Email: mukul@uwm.edu Email: mukul@uwm.edu
Emmanuel Baccelli (editor) Emmanuel Baccelli
INRIA INRIA
Phone: +33-169-335-511 Phone: +33-169-335-511
Email: Emmanuel.Baccelli@inria.fr Email: Emmanuel.Baccelli@inria.fr
URI: http://www.emmanuelbaccelli.org/ URI: http://www.emmanuelbaccelli.org/
Anders Brandt Anders Brandt
Sigma Designs Sigma Designs
Emdrupvej 26A, 1. Emdrupvej 26A, 1.
Copenhagen, Dk-2100 Copenhagen, Dk-2100
Denmark Denmark
Phone: +45-29609501 Phone: +45 29609501
Email: abr@sdesigns.dk Email: abr@sdesigns.dk
Robert Cragie
Gridmerge Ltd
89 Greenfield Crescent
Wakefield WF4 4WA
UK
Phone: +44-1924910888
Email: robert.cragie@gridmerge.com
Jerald Martocci Jerald Martocci
Johnson Controls Johnson Controls
507 E Michigan St 507 E Michigan Street
Milwaukee, WI 53202 Milwaukee 53202
USA USA
Phone: +1 414-524-4010 Phone: +1 414 524 4010
Email: jerald.p.martocci@jci.com Email: jerald.p.martocci@jci.com
 End of changes. 74 change blocks. 
196 lines changed or deleted 439 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/