draft-ietf-roll-p2p-measurement-04.txt   draft-ietf-roll-p2p-measurement-05.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: September 8, 2012 E. Baccelli Expires: November 11, 2012 E. Baccelli
INRIA INRIA
A. Brandt A. Brandt
Sigma Designs Sigma Designs
J. Martocci J. Martocci
Johnson Controls Johnson Controls
March 7, 2012 May 10, 2012
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-04 draft-ietf-roll-p2p-measurement-05
Abstract Abstract
This document specifies a mechanism that enables an RPL router to This document specifies a mechanism that enables an RPL router to
measure the quality of an existing route towards another RPL router measure the quality of an existing route towards another RPL router
in a low power and lossy network, thereby allowing the router to in a low power and lossy network, thereby allowing the router to
decide if it wants to initiate the discovery of a better route. decide if it wants to initiate the discovery of a better route.
Status of this Memo Status of this Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 September 8, 2012. This Internet-Draft will expire on November 11, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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) . . . . . . . . . . . . . . . . . 4 3. The Measurement Object (MO) . . . . . . . . . . . . . . . . . 5
3.1. Format of the base MO . . . . . . . . . . . . . . . . . . 5 3.1. Format of the base MO . . . . . . . . . . . . . . . . . . 5
3.2. Secure MO . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Secure MO . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Originating a Measurement Request . . . . . . . . . . . . . . 9 4. Originating a Measurement Request . . . . . . . . . . . . . . 9
4.1. To Measure A Hop-by-hop Route with a Global 4.1. To Measure A Hop-by-hop Route with a Global
RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 10 RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 10
4.2. To Measure A Hop-by-hop Route with a Local 4.2. To Measure A Hop-by-hop Route with a Local
RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 10 RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 10
4.3. To Measure A Source Route . . . . . . . . . . . . . . . . 11 4.3. To Measure A Source Route . . . . . . . . . . . . . . . . 11
5. Processing a Measurement Request at an Intermediate Router . . 12 5. Processing a Measurement Request at an Intermediate Router . . 12
5.1. Determining Next Hop For An MO Measuring A Source Route . 13 5.1. Determining Next Hop For An MO Measuring A Source Route . 14
5.2. Determining Next Hop For An MO Measuring A Hop-by-hop 5.2. Determining Next Hop For An MO Measuring A Hop-by-hop
Route . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Route . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Processing a Measurement Request at the Target . . . . . . . . 15 6. Processing a Measurement Request at the Target . . . . . . . . 15
7. Processing a Measurement Reply at the Origin . . . . . . . . . 16 7. Processing a Measurement Reply at the Origin . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
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 [RFC6550], the IPv6 Routing
Routing Protocol for LLNs, constrains the LLN topology to a Directed Protocol for LLNs, constrains the LLN topology to a Directed Acyclic
Acyclic Graph (DAG) built to optimize the routing costs to reach the Graph (DAG) built to optimize the routing costs to reach the DAG's
DAG's root. The P2P routing functionality, available under RPL, has root. The P2P routing functionality, available under RPL, has the
the following key limitations: following key limitations:
o The P2P routes are restricted to use the DAG links only. Such P2P o The P2P routes are restricted to use the DAG links only. Such P2P
routes may potentially be suboptimal and may lead to traffic routes may potentially be suboptimal and may lead to traffic
congestion near the DAG root. congestion near the DAG root.
o RPL is a proactive routing protocol and hence requires all P2P o RPL is a proactive routing protocol and hence requires all P2P
routes to be established ahead of the time they are used. Many routes to be established ahead of the time they are used. Many
LLN applications require the ability to establish P2P routes "on LLN applications require the ability to establish P2P routes "on
demand". demand".
To ameliorate situations, where the core RPL's P2P routing To ameliorate situations, where the core RPL's P2P routing
functionality does not meet the application requirements, functionality does not meet the application requirements,
[I-D.ietf-roll-p2p-rpl] describes P2P-RPL, an extension to core RPL. [I-D.ietf-roll-p2p-rpl] describes P2P-RPL, an extension to core RPL.
P2P-RPL provides a reactive mechanism to discover P2P routes that P2P-RPL provides a reactive mechanism to discover P2P routes that
meet the specified routing constraints meet the specified routing constraints [RFC6551]. In some cases, the
[I-D.ietf-roll-routing-metrics]. In some cases, the application application requirements or the LLN's topological features allow a
requirements or the LLN's topological features allow a router to router to infer these routing constraints implicitly. For example,
infer these routing constraints implicitly. For example, the the application may require the end-to-end loss rate and/or latency
application may require the end-to-end loss rate and/or latency along along the route to be below certain thresholds or the LLN topology
the route to be below certain thresholds or the LLN topology may be may be such that a router can safely assume its destination to be
such that a router can safely assume its destination to be less than less than a certain number of hops away from itself.
a certain number of hops away from itself.
When the existing routes are deemed unsatisfactory but the router When the existing routes are deemed unsatisfactory but the router
does not implicitly know the routing constraints to be used in P2P- does not implicitly know the routing constraints to be used in P2P-
RPL route discovery, it may be necessary for the router to measure RPL route discovery, it may be necessary for the router to measure
the aggregated values of the routing metrics along the existing the aggregated values of the routing metrics along the existing
route. This knowledge will allow the router to frame reasonable route. This knowledge will allow the router to frame reasonable
routing constraints to discover a better route using P2P-RPL. For routing constraints to discover a better route using P2P-RPL. For
example, if the router determines the aggregate ETX example, if the router determines the aggregate ETX [RFC6551] along
[I-D.ietf-roll-routing-metrics] along an existing route to be "x", it an existing route to be "x", it can use "ETX < x*y", where y is a
can use "ETX < x*y", where y is a certain fraction, as the routing certain fraction, as the routing constraint for use in P2P-RPL route
constraint for use in P2P-RPL route discovery. Note that it is discovery. Note that it is important that the routing constraints
important that the routing constraints are not overly strict; are not overly strict; otherwise the P2P-RPL route discovery may fail
otherwise the P2P-RPL route discovery may fail even though a route, even though a route, much better than the one currently being used,
much better than the one currently being used, exists. exists.
This document specifies a mechanism that enables an RPL router to This document specifies a mechanism that enables an RPL router to
measure the aggregated values of the routing metrics along an measure the aggregated values of the routing metrics along an
existing route to another RPL router in an LLN, thereby allowing the existing route to another RPL router in an LLN, thereby allowing the
router to decide if it wants to discover a better route using P2P-RPL router to decide if it wants to discover a better route using P2P-RPL
and determine the routing constraints to be used for this purpose. and determine the routing constraints to be used for this purpose.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
Additionally, this document uses terminology from Additionally, this document uses terminology from [RFC6550] and
[I-D.ietf-roll-terminology], [I-D.ietf-roll-rpl] and
[I-D.ietf-roll-p2p-rpl]. The following terms, originally defined in [I-D.ietf-roll-p2p-rpl]. The following terms, originally defined in
[I-D.ietf-roll-p2p-rpl], are redefined in the following manner. [I-D.ietf-roll-p2p-rpl], are redefined in the following manner.
Origin: The origin refers to the RPL router that initiates the Origin: The Origin refers to the RPL 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 RPL router at the end point of the Target: The Target refers to the RPL router at the end point of the
P2P route being measured. P2P route being measured.
Intermediate Router: An RPL router, other than the origin and the Intermediate Router: An RPL router, other than the Origin and the
target, on the P2P route being measured. Target, on the P2P route being measured.
2. Overview 2. Overview
The mechanism described in this document can be used by an origin in The mechanism described in this document can be used by an Origin in
an LLN to measure the aggregated values of the routing metrics along an LLN to measure the aggregated values of some routing metrics along
a P2P route to a target within the LLN. Such a route could be a a P2P route to a Target within the LLN. The route is measured in the
source route or a hop-by-hop route established using RPL direction from the Origin to the Target. Such a route could be a
[I-D.ietf-roll-rpl] or P2P-RPL [I-D.ietf-roll-p2p-rpl]. The origin source route or a hop-by-hop route established using RPL [RFC6550] or
sends a Measurement Request message along the route. The Measurement P2P-RPL [I-D.ietf-roll-p2p-rpl]. The Origin decides what metrics to
Request accumulates the values of the routing metrics as it travels measure and sends a Measurement Request message, carrying the desired
towards the target. Upon receiving the Measurement Request, the routing metric objects, along the route. On receiving a Measurement
target unicasts a Measurement Reply message, carrying the accumulated Request, an Intermediate Router updates the routing metric values
values of the routing metrics, back to the origin. Optionally, the inside the message and forwards it to the next hop on the route.
origin may allow an intermediate router to generate the Measurement Thus, the Measurement Request accumulates the values of the routing
Reply if it already knows the relevant routing metric values along metrics for the complete route as it travels towards the Target.
rest of the route. Upon receiving the Measurement Request, the Target unicasts a
Measurement Reply message, carrying the accumulated values of the
routing metrics, back to the Origin. Optionally, the Origin may
allow an Intermediate Router 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 This document defines two new RPL Control Message types, the
Measurement Object (MO), with code 0x06 (to be confirmed by IANA), 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 and the Secure MO, with code 0x86 (to be confirmed by IANA). An MO
serves as both Measurement Request and Measurement Reply. serves as both Measurement Request and Measurement Reply.
3.1. Format of the base MO 3.1. Format of the base MO
skipping to change at page 5, line 42 skipping to change at page 5, line 47
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of the base Measurement Object (MO) Figure 1: Format of the base Measurement Object (MO)
The format of a base MO is shown in Figure 1. A base MO consists of The format of a base MO is shown in Figure 1. A base MO consists of
the following fields: the following fields:
o RPLInstanceID: This field is relevant only if a hop-by-hop route o RPLInstanceID: This field is relevant only if a hop-by-hop route
is being measured, i.e., the H flag, described subsequently, is is being measured, i.e., the H flag, described subsequently, is
set to one. In this case, the origin MUST set this field to the set to one. In this case, the Origin MUST set this field to the
RPLInstanceID of the hop-by-hop route being measured. If a source RPLInstanceID of the hop-by-hop route being measured. If a source
route is being measured, the origin MUST set this field to binary route is being measured, the Origin MUST set this field to binary
value 10000000. An intermediate router MUST set the RPLInstanceID value 10000000. An Intermediate Router MUST set the RPLInstanceID
field in the outgoing MO packet to the same value that it had in field in the outgoing MO packet to the same value that it had in
the corresponding incoming MO packet unless it is the root of a the corresponding incoming MO packet unless it is the root of a
non-storing global DAG, identified by the RPLInstanceID, along non-storing global DAG, identified by the RPLInstanceID, along
which the MO packet had been traveling so far and the router which the MO packet had been traveling so far and the router
intends to insert a source route inside the Address vector to intends to insert a source route inside the Address vector to
direct it towards the target. In that case, the router MUST set direct it towards the Target. In that case, the router MUST set
the RPLInstanceID field in the outgoing MO packet to binary value the RPLInstanceID field in the outgoing MO packet to binary value
10000000. 10000000.
o Compr: In many LLN deployments, IPv6 addresses share a well known, o Compr: In many LLN deployments, IPv6 addresses share a well known,
common prefix. In such cases, the common prefix can be elided common prefix. In such cases, the common prefix can be elided
when specifying IPv6 addresses in the Origin/Target Address fields when specifying IPv6 addresses in the Origin/Target Address fields
and the Address vector. The "Compr" field, a 4-bit unsigned and the Address vector. The "Compr" field, a 4-bit unsigned
integer, is set by the origin to specify the number of prefix integer, is set by the Origin to specify the number of prefix
octets that are elided from the IPv6 addresses in Origin/Target octets that are elided from the IPv6 addresses in Origin/Target
Address fields and the Address vector. An intermediate router Address fields and the Address vector. An Intermediate Router
MUST set the Compr field in the outgoing MO packet to the same MUST set the Compr field in the outgoing MO packet to the same
value that it had in the corresponding incoming MO packet. The value that it had in the corresponding incoming MO packet. The
intermediate router MUST drop the received MO message if the Compr Intermediate Router MUST drop the received MO message if the Compr
value specified in the message does not match what the router value specified in the message does not match what the router
considers the length of the common prefix to be. The origin will considers the length of the common prefix to be. The Origin will
set the Compr value to zero if full IPv6 addresses are to be set the Compr value to zero if full IPv6 addresses are to be
carried in the Origin Address/Target Address fields and the carried in the Origin Address/Target Address fields and the
Address vector. Address vector.
o Type (T): This flag is set to one if the MO represents a o Type (T): This flag is set to one if the MO represents a
Measurement Request. The flag is set to zero if the MO is a Measurement Request. The flag is set to zero if the MO is a
Measurement Reply. Measurement Reply.
o Hop-by-hop (H): The origin MUST set this flag to one if the route o Hop-by-hop (H): The Origin MUST set this flag to one if the route
being measured is a hop-by-hop route. In that case, the hop-by- being measured is a hop-by-hop route. In that case, the hop-by-
hop route is identified by the RPLInstanceID and, if the hop route is identified by the RPLInstanceID and, if the
RPLInstanceID is a local value, the Origin Address and Target RPLInstanceID is a local value, the Origin Address and Target
Address fields inside the message. The origin MUST set this flag Address fields inside the message. The Origin MUST set this flag
to zero if the route being measured is a source route specified in to zero if the route being measured is a source route specified in
the Address vector. An intermediate router MUST set the H flag in the Address vector. An Intermediate Router MUST set the H flag in
an outgoing MO packet to the same value that it had in the an outgoing MO packet to the same value that it had in the
corresponding incoming MO packet unless the router is the root of corresponding incoming MO packet unless the router is the root of
the non-storing global DAG, identified by the RPLInstanceID, along the non-storing global DAG, identified by the RPLInstanceID, along
which the MO packet had been traveling so far and the router which the MO packet had been traveling so far and the router
intends to insert a source route inside the Address vector to intends to insert a source route inside the Address vector to
direct it towards the target. In that case, the router MUST reset direct it towards the Target. In that case, the router MUST reset
the H flag to zero in the outgoing MO packet. the H flag to zero in the outgoing MO packet.
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. In other words, this route represented by a local RPLInstanceID. In other words, this
flag MAY be set to one only if T = 1, H = 1 and the RPLInstanceID flag MAY be set to one only if T = 1, H = 1 and the RPLInstanceID
field has a local value. Otherwise, this flag MUST be set to field has a local value. Otherwise, this flag MUST be set to
zero. A value 1 in this flag indicates that the Measurement zero. A value 1 in this flag indicates that the Measurement
Request MUST accumulate a source route for use by the target to Request MUST accumulate a source route for use by the Target to
send the Measurement Reply back to the origin. In this case, an send the Measurement Reply back to the Origin. In this case, an
intermediate router MUST add its unicast IPv6 address (after Intermediate Router MUST add its unicast IPv6 address (after
eliding Compr number of prefix octets) to the Address vector in eliding Compr number of prefix octets) to the Address vector in
the manner specified later. Route accumulation is not allowed the manner specified later. Route accumulation is not allowed
when the Measurement Request travels along a hop-by-hop route with when the Measurement Request travels along a hop-by-hop route with
a global RPLInstanceID, i.e., along a global DAG, because: a global RPLInstanceID, i.e., along a global DAG, because:
* The DAG's root may need the Address vector to insert a source * The DAG's root may need the Address vector to insert a source
route to the target; and route to the Target; and
* The target can presumably reach the origin along this global * The Target can presumably reach the Origin along this global
DAG. DAG.
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. In other words, this flag in the Address vector, to the Target. In other words, this flag
MAY be set to one only if T = 1 and H = 0. Otherwise, this flag MAY be set to one only if T = 1 and H = 0. Otherwise, this flag
MUST be set to zero. A value 1 in the flag indicates that the MUST be set to zero. A value 1 in the flag indicates that the
Address vector contains a complete source route from the origin to Address vector contains a complete source route from the Origin to
the target, which can be used, after reversal, by the target to the Target, which can be used, after reversal, by the Target to
source route the Measurement Reply message back to the origin. source route the Measurement Reply message back to the Origin.
o Back Request (B): This flag serves as a request to the target to 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 send a Measurement Request towards the Origin. The Origin MAY set
this flag to one to make such a request to the target. An this flag to one to make such a request to the Target. An
intermediate router MUST set the B flag in an outgoing MO packet Intermediate Router MUST set the B flag in an outgoing MO packet
to the same value that it had in the corresponding incoming MO to the same value that it had in the corresponding incoming MO
packet. On receiving a Measurement Request with the B flag set to packet. On receiving a Measurement Request with the B flag set to
one, the target SHOULD generate a Measurement Request to measure one, the Target SHOULD generate a Measurement Request to measure
the cost of its current (or the most preferred) route to the the cost of its current (or the most preferred) route to the
origin. Receipt of this Measurement Request would allow the Origin. Receipt of this Measurement Request would allow the
origin to know the cost of the back route from the target to Origin to know the cost of the back route from the Target to
itself and thus determine the round-trip cost of reaching the itself and thus determine the round-trip cost of reaching the
target. Target.
o Intermediate Reply (I): Relevant only if a hop-by-hop route is o Intermediate Reply (I): Relevant only if a hop-by-hop route is
being measured, this flag serves as a permission to an being measured, this flag serves as a permission to an
intermediate router to generate a Measurement Reply if it knows Intermediate Router to generate a Measurement Reply if it knows
the cost of the rest of the route being measured. The origin MAY the cost of the rest of the route being measured. The Origin MAY
set this flag to one if a hop-by-hop route is being measured set this flag to one if a hop-by-hop route is being measured
(i.e., H = 1) and the origin wants to allow an intermediate router (i.e., H = 1) and the Origin wants to allow an Intermediate Router
to generate the Measurement Reply in response to this Measurement to generate the Measurement Reply in response to this Measurement
Request. Setting this flag to one may be useful in scenarios Request. Setting this flag to one may be useful in scenarios
where the Hop Count [I-D.ietf-roll-routing-metrics] is the routing where the Hop Count [RFC6551] is the routing metric of interest
metric of interest and the origin expects an intermediate router and the Origin expects an Intermediate Router (e.g. the root of a
(e.g. the root of a non-storing DAG or a common ancestor of the non-storing DAG or a common ancestor of the Origin and the Target
origin and the target in a storing DAG) to know the Hop Count of in a storing DAG) to know the Hop Count of the remainder of the
the remainder of the route to the target. This flag MUST be set route to the Target. This flag MUST be set to zero if the route
to zero if the route being measured is a source route (i.e., H = being measured is a source route (i.e., H = 0).
0).
o SequenceNo: A 6-bit sequence number, assigned by the origin, that o SequenceNo: A 6-bit sequence number, assigned by the Origin, that
allows the origin to uniquely identify a Measurement Request and allows the Origin to uniquely identify a Measurement Request and
the corresponding Measurement Reply. An intermediate router MUST the corresponding Measurement Reply. An Intermediate Router MUST
set this field in the outgoing MO packet to the same value that it set this field in the outgoing MO packet to the same value that it
had in the corresponding incoming MO packet. The target MUST set had in the corresponding incoming MO packet. The Target MUST set
this field in a Measurement Reply message to the same value that this field in a Measurement Reply message to the same value that
it had in the corresponding Measurement Request message. it had in the corresponding Measurement Request message.
o Num: This field indicates the number of elements, each (16 - o Num: This field indicates the number of elements, each (16 -
Compr) octets in size, inside the Address vector. If the value of Compr) octets in size, inside the Address vector. If the value of
this field is zero, the Address vector is not present in the MO. this field is zero, the Address vector is not present in the MO.
o Index: If the Measurement Request is traveling along a source o Index: If the Measurement Request is traveling along a source
route contained in the Address vector (T=1,H=0), this field route contained in the Address vector (T=1,H=0), this field
indicates the index in the Address vector of the next hop on the indicates the index in the Address vector of the next hop on the
route. If the Measurement Request is traveling along a hop-by-hop route. If the Measurement Request is traveling along a hop-by-hop
route with a local RPLInstanceID and the A flag is set route with a local RPLInstanceID and the A flag is set
(T=1,H=1,A=1 and RPLInstanceID field has a local value), this (T=1,H=1,A=1 and RPLInstanceID field has a local value), this
field indicates the index in the Address vector where an field indicates the index in the Address vector where an
intermediate router receiving the MO message must store its IPv6 Intermediate Router receiving the MO message must store its IPv6
address. Otherwise, this field MUST be set to zero on address. Otherwise, this field MUST be set to zero on
transmission and ignored on reception. transmission and ignored on reception.
o Origin Address: A unicast IPv6 address of the origin after eliding o Origin Address: A unicast IPv6 address of the Origin after eliding
Compr number of prefix octets. If the MO is traveling along a Compr number of prefix octets. If the MO is traveling along a
hop-by-hop route and the RPLInstanceID field indicates a local hop-by-hop route and the RPLInstanceID field indicates a local
value, the Origin Address field MUST specify the DODAGID value value, the Origin Address field MUST specify the DODAGID value
that, along with the RPLInstanceID and the Target Address, that, along with the RPLInstanceID and the Target Address,
uniquely identifies the hop-by-hop route being measured. uniquely identifies the hop-by-hop route being measured.
o Target Address: A unicast IPv6 address of the target after eliding o Target Address: A unicast IPv6 address of the Target after eliding
Compr number of prefix octets. Compr number of prefix octets.
o Address[1..Num]: A vector of unicast IPv6 addresses (with Compr o Address[1..Num]: A vector of unicast IPv6 addresses (with Compr
number of prefix octets elided) representing a source route to the number of prefix octets elided) representing a source route to the
target: 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 source route to be used Address vector is used to accumulate a source route to be used
by the target to send the Measurement Reply back to the origin. by the Target to send the Measurement Reply back to the Origin.
In 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 reachable in the backward direction, i.e., from route MUST be reachable in the backward direction, i.e., from
the target to the origin. An intermediate router adding its the Target to the Origin. An Intermediate Router adding its
address to the Address vector MUST ensure that its address does address to the Address vector MUST ensure that its address does
not already exist in the vector. not already exist in the vector.
* When the Measurement Request is traveling along a source route, * When the Measurement Request is traveling along a source route,
the Address vector MUST contain a complete route to the target the Address vector MUST contain a complete route to the Target
and the IPv6 addresses in the Address vector MUST be reachable and the IPv6 addresses in the Address vector MUST be reachable
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 (origin or an intermediate router) inserting an A router (Origin or an Intermediate Router) inserting an
Address vector inside an MO MUST ensure that no address appears Address vector inside an MO MUST ensure that no address appears
more than once inside the vector. Each router on the way MUST more than once inside the vector. Each router on the way MUST
ensure that the loops do not exist within the source route. ensure that the loops do not exist within the source route.
The origin MAY set the R flag in the MO if the route in the The Origin MAY set the R flag in the MO if the route in the
Address vector represents a complete route from the origin to Address vector represents a complete route from the Origin to
the target and this route can be used after reversal by the the Target and this route can be used after reversal by the
target to send the Measurement Reply message back to the origin Target to send the Measurement Reply message back to the Origin
(i.e., the IPv6 addresses in the Address vector are reachable (i.e., the IPv6 addresses in the Address vector are reachable
in the backward direction - from the target to the origin). in the backward direction - from the Target 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 the routing metric values for the Container options to accumulate the routing metric values for the
route being measured. route being measured.
3.2. Secure MO 3.2. Secure MO
A Secure MO message follows the format in Figure 7 of A Secure MO message follows the format in Figure 7 of [RFC6550],
[I-D.ietf-roll-rpl], where the base format is the base MO shown in where the base format is the base MO shown in Figure 1.
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 as described in Section 3.1. The setting of MO fields in fields as described in Section 3.1. The setting of MO fields in
specific cases is described below. In all cases, the origin MUST set specific cases is described below. In all cases, the Origin MUST set
the T flag to one to indicate that the MO represents a Measurement the T flag to one to indicate that the MO represents a Measurement
Request. The origin MUST also include one or more Metric Container Request. The Origin MUST also include the routing metric objects of
options inside the MO to carry the routing metric objects of interest inside one or more Metric Container options inside the MO.
interest. Depending on the metrics being measured, the origin must Depending on the metrics being measured, the Origin must also
also initiate these routing metric objects by including the values of initiate these routing metric objects by including the values of the
the routing metrics for the first hop on the P2P route being routing metrics for the first hop on the P2P route being measured.
measured.
After setting the MO fields appropriately, the origin determines the After setting the MO fields appropriately, the Origin determines the
next hop on the P2P route being measured. If a hop-by-hop route is next hop on the P2P route being measured. If a hop-by-hop route is
being measured (i.e., the H flag is set to one), the next hop is being measured (i.e., the H flag is set to one), the next hop is
determined using the RPLInstanceID, the Target Address and, if determined using the RPLInstanceID, the Target Address and, if
RPLInstanceID is a local value, the Origin Address fields in the MO. RPLInstanceID is a local value, the Origin Address fields in the MO.
If a source route is being measured (i.e., the H flag is set to If a source route is being measured (i.e., the H flag is set to
zero), the Address[1] element contains the next hop address. zero), the Address[1] element contains the next hop address.
The origin MUST discard the MO message if: The Origin MUST discard the MO message if:
o the next hop address is not a unicast address; or o the next hop address is not a unicast address; or
o the next hop is not on-link; or o the next hop is not on-link; or
o the next hop is not in the same RPL routing domain as the origin. o the next hop is not in the same RPL routing domain as the Origin.
Otherwise, the origin MUST unicast the MO message to the next hop on Otherwise, the Origin MUST unicast the MO message to the next hop on
the P2P route. the P2P route.
4.1. To Measure A Hop-by-hop Route with a Global RPLInstanceID 4.1. To Measure A Hop-by-hop Route with a Global RPLInstanceID
If a hop-by-hop route with a global RPLInstanceID is being measured, If a hop-by-hop route with a global RPLInstanceID is being measured,
the MO message MUST NOT contain the Address vector and the following the MO message MUST NOT contain the Address vector and the following
MO fields MUST be set in the manner specified below: MO fields MUST be set in the manner specified below:
o Hop-by-hop (H): This flag MUST be set to one. o Hop-by-hop (H): This flag MUST be set to one.
skipping to change at page 10, line 46 skipping to change at page 10, line 48
o Reverse (R): This flag MUST be set to zero. o Reverse (R): This flag MUST be set to zero.
o Num: This field MUST be set to zero. o Num: This field MUST be set to zero.
o Index: This field MUST be set to zero. o Index: This field MUST be set to zero.
4.2. To Measure A Hop-by-hop Route with a Local RPLInstanceID 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 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, 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 the MO message MUST NOT contain the Address vector and the following
MO fields MUST be set in the manner specified below: MO fields MUST be set in the manner specified below:
o Hop-by-hop (H): This flag MUST be set to one. o Hop-by-hop (H): This flag MUST be set to one.
o Accumulate Route (A): This flag MUST be set to zero. o Accumulate Route (A): This flag MUST be set to zero.
o Reverse (R): This flag MUST be set to zero. o Reverse (R): This flag MUST be set to zero.
o Num: This field MUST be set to zero. o Num: This field MUST be set to zero.
o Index: This field MUST be set to zero. o Index: This field MUST be set to zero.
o Origin Address: This field MUST contain the DODAGID value (after o Origin Address: This field MUST contain the DODAGID value (after
eliding Compr number of prefix octets) associated with the route eliding Compr number of prefix octets) associated with the route
being measured. 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 set the Target to send the Measurement Reply message back, it MUST set the
following MO fields in the manner specified below: following MO fields in the manner specified below:
o Hop-by-hop (H): This flag MUST be set to one. o Hop-by-hop (H): This flag MUST be set to one.
o Accumulate Route (A): This flag MUST be set to one. o Accumulate Route (A): This flag MUST be set to one.
o Reverse (R): This flag MUST be set to zero. o Reverse (R): This flag MUST be set to zero.
o Intermediate Reply (I): This flag MUST be set to zero. o Intermediate Reply (I): This flag MUST be set to zero.
o Address vector: The Address vector must be large enough to o Address vector: The Address vector must be large enough to
accomodate a complete source route from the origin to the target. accomodate a complete source route from the Origin to the Target.
All the bits in the Address vector field MUST be set to zero. 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 o Num: This field MUST specify the number of address elements that
can fit inside the Address vector. can fit inside the Address vector.
o Index: This field MUST be set to one. o Index: This field MUST be set to one.
o Origin Address: This field MUST contain the DODAGID value (after o Origin Address: This field MUST contain the DODAGID value (after
eliding Compr number of prefix octets) associated with the route eliding Compr number of prefix octets) associated with the route
being measured. being measured.
4.3. To Measure A Source Route 4.3. To Measure A Source Route
If a source route is being measured, the origin MUST set the If a source route is being measured, the Origin MUST set the
following MO fields in the manner specified below: following MO fields in the manner specified below:
o Hop-by-hop (H): This flag MUST be set to zero. o Hop-by-hop (H): This flag MUST be set to zero.
o Accumulate Route (A): This flag MUST be set to zero. o Accumulate Route (A): This flag MUST be set to zero.
o Reverse (R): This flag SHOULD be set to one if the source route in o Reverse (R): This flag SHOULD be set to one if the source route in
the Address vector can be reversed and used by the target to the Address vector can be reversed and used by the Target to
source route the Measurement Reply message back to the origin. source route the Measurement Reply message back to the Origin.
Otherwise, this flag MUST be set to zero. Otherwise, this flag MUST be set to zero.
o Intermediate Reply (I): This flag MUST be set to zero. o Intermediate Reply (I): This flag MUST be set to zero.
o Address vector: o Address vector:
* The Address vector MUST contain a complete route from the * The Address vector MUST contain a complete route from the
origin to the target (excluding the origin and the target). Origin to the Target (excluding the Origin and the Target).
* The IPv6 addresses (with Compr prefix octets elided) in the * The IPv6 addresses (with Compr prefix octets elided) in the
Address vector MUST be reachable in the forward direction, Address vector MUST be reachable in the forward direction,
i.e., from the origin to the target. i.e., from the Origin to the Target.
* If the R flag is set to one, the IPv6 addresses (with Compr * If the R flag is set to one, the IPv6 addresses (with Compr
prefix octets elided) in the Address vector MUST also be prefix octets elided) in the Address vector MUST also be
reachable in the backward direction, i.e., from the target to reachable in the backward direction, i.e., from the Target to
the origin. the Origin.
* To prevent loops in the source route, the origin MUST ensure * To prevent loops in the source route, the Origin MUST ensure
compliance to the following rules: compliance to the following rules:
+ Any IPv6 address MUST NOT appear more than once in the + Any IPv6 address MUST NOT appear more than once in the
Address vector. Address vector.
+ If the Address vector includes multiple IPv6 addresses + If the Address vector includes multiple IPv6 addresses
assigned to the origin's interfaces, such addresses MUST assigned to the Origin's interfaces, such addresses MUST
appear back to back inside the Address vector. appear back to back inside the Address vector.
* Each address appearing in the Address vector MUST be a unicast * Each address appearing in the Address vector MUST be a unicast
address. address.
o Num: This field MUST be set to indicate the number of elements in o Num: This field MUST be set to indicate the number of elements in
the Address vector. the Address vector.
o Index: This field MUST be set to one. o Index: This field MUST be set to one.
5. Processing a Measurement Request at an Intermediate Router 5. Processing a Measurement Request at an Intermediate Router
A router (an intermediate router or the target) MAY discard a A router (an Intermediate Router or the Target) MAY discard a
received MO with no processing to meet any policy-related goal. Such received MO with no processing to meet any policy-related goal. Such
policy goals may include the need to reduce the router's CPU load or policy goals may include the need to reduce the router's CPU load or
to enhance its battery life. to enhance its battery life.
A router MUST discard a received MO with no further processing if the A router MUST discard a received MO with no further processing if the
Compr field inside the received message is not same as what the Compr field inside the received message is not same as what the
router considers the length of the common prefix used in IPv6 router considers the length of the common prefix used in IPv6
addresses in the LLN to be. addresses in the LLN to be.
On receiving an MO, if a router chooses to process the packet On receiving an MO, if a router chooses to process the packet
further, it MUST check if one of its IPv6 addresses is listed as further, it MUST check if one of its IPv6 addresses is listed as
either the Origin or the Target Address. If neither, the router either the Origin or the Target Address. If neither, the router
considers itself an Intermediate Router and MUST process the received considers itself an Intermediate Router and MUST process the received
MO in the following manner. 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.
If the H and I flags are set to one in the received MO and the If the H and I flags are set to one in the received MO and the
intermediate router knows the values of the routing metrics, Intermediate Router knows the values of the routing metrics,
specified in the Metric Container, for the remainder of the route, it specified in the Metric Container, for the remainder of the route, it
MAY generate a Measurement Reply on the target's behalf in the manner MAY generate a Measurement Reply on the Target's behalf in the manner
specified in Section 6 (after including in the Measurement Reply the specified in Section 6 (after including in the Measurement Reply the
relevant routing metric values for the complete route being relevant routing metric values for the complete route being
measured). Otherwise, the intermediate router MUST process the measured). Otherwise, the Intermediate Router MUST process the
received MO in the following manner. received MO in the following manner.
The router MUST determine the next hop on the P2P route being The router MUST determine the next hop on the P2P route being
measured in the manner described below. The router MUST drop the MO measured in the manner described below. The router MUST drop the MO
with no further processing and MAY send an ICMPv6 Destination with no further processing and MAY send an ICMPv6 Destination
Unreachable (with Code 0 - No Route To Destination) error message to 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 source of the message if it can not determine the next hop for
the message. The router MUST drop the MO with no further processing: the message. The router MUST drop the MO 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
o If the next hop is not on-link; or o If the next hop is not on-link; or
o If the next hop is not in the same RPL routing domain as the o If the next hop is not in the same RPL routing domain as the
router. router.
Next, the router MUST update the routing metric objects, contained in Next, the router MUST update the routing metric objects, contained in
the Metric Container options inside the MO, either by updating the the Metric Container option(s) inside the MO, either by updating the
aggregated value for the routing metric or by attaching the local aggregated value for the routing metric or by attaching the local
values for the metric inside the object. After updating the routing values for the metric inside the object. An Intermediate Router can
metrics, the router MUST unicast the MO to the next hop. only update the existing metric objects and MUST NOT add any new
routing metric object to the Metric Container. An Intermediate
Router MUST drop the MO if it cannot update a routing metric object
specified inside the Metric Container.
After updating the routing metrics, the router MUST unicast the MO to
the next hop.
5.1. Determining Next Hop For An MO Measuring A Source Route 5.1. Determining Next Hop For An MO Measuring A Source Route
In case the received MO is measuring a source route (H=0), In case the received MO is measuring a source route (H=0),
o The router MUST verify that the Address[Index] element lists one o The router MUST verify that the Address[Index] element lists one
of its unicast IPv6 addresses, failing which the router MUST of its unicast IPv6 addresses, failing which the router MUST
discard the MO packet with no further processing; discard the MO packet with no further processing;
o The router MUST then increment the Index field and use the o The router MUST then increment the Index field and use the
Address[Index] element as the next hop. If Index is greater than Address[Index] element as the next hop. If Index is greater than
Num, the router MUST use the Target Address as the next hop. Num, the router MUST use the Target Address as the next hop.
To prevent loops, an intermediate router MUST discard the MO packet To prevent loops, an Intermediate Router MUST discard the MO packet
with no further processing if the Address vector includes multiple with no further processing if the Address vector includes multiple
IPv6 addresses assigned to the router's interfaces and if such IPv6 addresses assigned to the router's interfaces and if such
addresses do not appear back to back inside the Address vector. addresses do not appear back to back inside the Address vector.
5.2. Determining Next Hop For An MO Measuring A Hop-by-hop Route 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 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 MUST use the RPLInstanceID, the Target Address and, if RPLInstanceID
is a local value, the Origin Address to determine the next hop for is a local value, the Origin Address to determine the next hop for
the MO. Moreover, the MO. Moreover,
skipping to change at page 14, line 34 skipping to change at page 14, line 41
already contains one of its IPv6 addresses. If yes, the router already contains one of its IPv6 addresses. If yes, the router
MUST discard the packet with no further processing. Otherwise, MUST discard the packet with no further processing. Otherwise,
the router MUST store one of its IPv6 addresses (after eliding the router MUST store one of its IPv6 addresses (after eliding
Compr prefix octets) at location Address[Index] and then increment Compr prefix octets) at location Address[Index] and then increment
the Index field. the Index field.
o If the router is the root of the non-storing global DAG along o If the router is the root of the non-storing global DAG along
which the received MO message had been traveling so far, which the received MO message had been traveling so far,
* The router discards the MO packet with no further processing if * The router discards the MO packet with no further processing if
it does not know of a source route to reach the target it does not know of a source route to reach the Target
(specified by the Target Address listed in the packet). (specified by the Target Address listed in the packet).
* Otherwise, the router MUST do the following: * Otherwise, the router MUST do the following:
+ Set the H, A and R flags to zero and the RPLInstanceID field + Set the H, A and R flags to zero and the RPLInstanceID field
to binary value 10000000. to binary value 10000000.
+ Remove any existing Address vector inside the MO. + Remove any existing Address vector inside the MO.
+ Insert a new Address vector inside the MO and specify a + Insert a new Address vector inside the MO and specify a
source route to the target inside the Address vector as per source route to the Target inside the Address vector as per
the following rules: 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 target (excluding the router and the router to the Target (excluding the router and the
target); Target);
- The IPv6 addresses (with Compr prefix octets elided) in - The IPv6 addresses (with Compr prefix octets elided) in
the Address vector MUST be reachable in the forward the Address vector MUST be reachable in the forward
direction, i.e., towards the target; direction, i.e., towards the Target;
- To prevent loops in the source route, the router MUST - To prevent loops in the source route, the router MUST
ensure that ensure that
o Any IPv6 address MUST NOT appear more than once in the o Any IPv6 address MUST NOT appear more than once in the
Address vector; Address vector;
o If the Address vector includes multiple IPv6 addresses o If the Address vector includes multiple IPv6 addresses
assigned to the router's interfaces, such addresses assigned to the router's interfaces, such addresses
MUST appear back to back inside the Address vector. MUST appear back to back inside the Address vector.
skipping to change at page 15, line 31 skipping to change at page 15, line 36
+ Specify in the Num field the number of address elements in + Specify in the Num field the number of address elements in
the Address vector. the Address vector.
+ Set the Index field to one. + Set the Index field to one.
6. Processing a Measurement Request at the Target 6. Processing a Measurement Request at the Target
On receiving an MO, if a router chooses to process the packet further On receiving an MO, if a router chooses to process the packet further
and finds one of its unicast IPv6 addresses listed as the Target and finds one of its unicast IPv6 addresses listed as the Target
Address, the router considers itself the target and MUST process the Address, the router considers itself the Target and MUST process the
received MO in the following manner. received MO in the following manner.
The target MUST discard the packet with no further processing if the The Target MUST discard the packet with no further processing if the
received MO is not a Measurement Request. received MO is not a Measurement Request.
The target MUST update the routing metric objects in the Metric The Target MUST update the routing metric objects in the Metric
Container options if required and MAY note the measured values for Container options if required and MAY note the measured values for
the complete route (especially, if the received Measurement Request the complete route (especially, if the received Measurement Request
is likely a response to an earlier Measurement Request that the is likely a response to an earlier Measurement Request that the
target had sent to the origin with B flag set to one). Target had sent to the Origin with B flag set to one).
The target MUST generate a Measurement Reply message. The The Target MUST generate a Measurement Reply message. The
Measurement Reply message MUST have the same SequenceNo field as the Measurement Reply message MUST have the same SequenceNo field as the
received Measurement Request message. The received Measurement received Measurement Request message. The received Measurement
Request message can be trivially converted into the Measurement Reply Request message can be trivially converted into the Measurement Reply
by setting the T flag to zero. The target MAY remove the Address by setting the T flag to zero. The Target MAY remove the Address
vector from the Measurement Reply if desired. The target MUST then vector from the Measurement Reply if desired. The Target MUST then
unicast the Measurement Reply back to the origin: unicast the Measurement Reply back to the Origin:
o If the Measurement Request traveled along a global DAG (i.e., one o If the Measurement Request traveled along a global DAG (i.e., one
with a global RPLInstanceID), the Measurement Reply MAY be unicast with a global RPLInstanceID), the Measurement Reply MAY be unicast
back to the origin along the same DAG. back to the 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 to one, the target MAY reverse the source route contained is set to one, the Target MAY reverse the source route contained
in the Address vector and use it to send the Measurement Reply in the Address vector and use it to send the Measurement Reply
back to the origin. back to 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 is set to one, the target MAY flag inside the received message is set to one, the Target MAY
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 origin. it to send the Measurement Reply back to the Origin.
If the B flag in the received Measurement Request is set to one, the If the B flag in the received Measurement Request is set to one, the
target SHOULD generate a new Measurement Request to measure the cost Target SHOULD generate a new Measurement Request to measure the cost
of its current (or the most preferred) route to the origin. The 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 used in the new Measurement Request MUST include the
routing metrics specified in the received Measurement Request. 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 unicast IPv6 When a router receives an MO, it examines if one of its unicast IPv6
addresses is listed as the Origin Address. If yes, the router is the addresses is listed as the Origin Address. If yes, the router is the
origin and MUST process the received message in the following manner. Origin and MUST 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 MUST examine the routing metric objects inside the Metric The Origin MUST examine the routing metric objects inside the Metric
Container options to evaluate the quality of the measured P2P route. Container options to evaluate the quality of the measured P2P route.
If a routing metric object contains local metric values recorded by If a routing metric object contains local metric values recorded by
routers on the route, the origin MUST aggregate these local values routers on the route, the Origin MUST aggregate these local values
into an end-to-end value as per the aggregation rules for the metric. into an end-to-end value as per the aggregation rules for the metric.
8. Security Considerations 8. Security Considerations
The mechanism defined in this document can potentially be used by a The mechanism defined in this document can potentially be used by a
compromised router to generate bogus Measurement Requests to compromised router to generate bogus Measurement Requests to
arbitrary target routers. Such Measurement Requests may cause CPU arbitrary Target routers. Such Measurement Requests may cause CPU
overload in the routers in the network, drain their batteries and overload in the routers in the network, drain their batteries and
cause traffic congestion in the network. Note that some of these cause traffic congestion in the network. Note that some of these
problems would occur even if the compromised router were to generate problems would occur even if the compromised router were to generate
bogus data traffic to arbitrary destinations. bogus data traffic to arbitrary destinations.
Since a Measurement Request can travel along a source route specified Since a Measurement Request can travel along a source route specified
in the Address vector, some of the security concerns that led to the in the Address vector, some of the security concerns that led to the
deprecation of Type 0 routing header [RFC5095] may be valid here. To deprecation of Type 0 routing header [RFC5095] may be valid here. To
address such concerns, the mechanism described in this document address such concerns, the mechanism described in this document
includes several remedies: includes several remedies:
skipping to change at page 17, line 37 skipping to change at page 17, line 42
o This document requires that a router must check the source route o This document requires that a router must check the source route
inside the Address vector of each received MO message to ensure inside the Address vector of each received MO message to ensure
that it does not contain a loop involving the router. The router that it does not contain a loop involving the router. The router
must drop the received packet if the source route does contain must drop the received packet if the source route does contain
such a loop. This and the previous two rules protect the network such a loop. This and the previous two rules protect the network
against some of the security concerns even if a compromised node against some of the security concerns even if a compromised node
inserts a malformed Address vector inside the MO message. inserts a malformed Address vector inside the MO message.
9. IANA Considerations 9. IANA Considerations
IANA is requested to allocate new code points in the "RPL Control This document defines two new RPL messages:
Codes" registry for the "Measurement Object" and "Secure Measurement
Object" described in this document. o "Measurement Object" (see Section 3.1), assigned a value of 0x06
from the "RPL Control Codes" space [to be removed upon
publication:
http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
[RFC6550].
o "Secure Measurement Object" (see Section 3.2), assigned a value of
0x86 from the "RPL Control Codes" space [to be removed upon
publication:
http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
[RFC6550].
+------+---------------------------+---------------+ +------+---------------------------+---------------+
| Code | Description | Reference | | Code | Description | Reference |
+------+---------------------------+---------------+ +------+---------------------------+---------------+
| 0x06 | Measurement Object | This document | | 0x06 | Measurement Object | This document |
| 0x86 | Secure Measurement Object | This document | | 0x86 | Secure Measurement Object | This document |
+------+---------------------------+---------------+ +------+---------------------------+---------------+
RPL Control Codes RPL Control Codes
skipping to change at page 18, line 23 skipping to change at page 18, line 38
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., 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-09 Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-12
(work in progress), March 2012. (work in progress), May 2012.
[I-D.ietf-roll-routing-metrics]
Barthel, D., Vasseur, J., Pister, K., Kim, M., and N.
Dejean, "Routing Metrics used for Path Calculation in Low
Power and Lossy Networks",
draft-ietf-roll-routing-metrics-19 (work in progress),
March 2011.
[I-D.ietf-roll-rpl]
Brandt, A., Vasseur, J., Hui, J., Pister, K., Thubert, P.,
Levis, P., Struik, R., Kelsey, R., Clausen, T., and T.
Winter, "RPL: IPv6 Routing Protocol for Low power and
Lossy Networks", draft-ietf-roll-rpl-19 (work in
progress), March 2011.
[I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-06 (work in
progress), September 2011.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095, of Type 0 Routing Headers in IPv6", RFC 5095,
December 2007. December 2007.
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low-Power and Lossy Networks", Routing Requirements in Low-Power and Lossy Networks",
RFC 5826, April 2010. RFC 5826, April 2010.
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
"Building Automation Routing Requirements in Low-Power and "Building Automation Routing Requirements in Low-Power and
Lossy Networks", RFC 5867, June 2010. Lossy Networks", RFC 5867, June 2010.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012.
[RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D.
Barthel, "Routing Metrics Used for Path Calculation in
Low-Power and Lossy Networks", RFC 6551, March 2012.
Authors' Addresses Authors' Addresses
Mukul Goyal (editor) Mukul Goyal (editor)
University of Wisconsin Milwaukee University of Wisconsin Milwaukee
3200 N Cramer St 3200 N Cramer St
Milwaukee, WI 53211 Milwaukee, WI 53211
USA USA
Phone: +1 414 2295001 Phone: +1 414 2295001
Email: mukul@uwm.edu Email: mukul@uwm.edu
 End of changes. 102 change blocks. 
193 lines changed or deleted 199 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/