draft-ietf-roll-p2p-measurement-10.txt | rfc6998.txt | |||
---|---|---|---|---|
Internet Engineering Task Force M. Goyal, Ed. | Internet Engineering Task Force (IETF) M. Goyal, Ed. | |||
Internet-Draft University of Wisconsin | Request for Comments: 6998 Univ. of Wisconsin Milwaukee | |||
Intended status: Experimental Milwaukee | Category: Experimental E. Baccelli | |||
Expires: October 3, 2013 E. Baccelli | ISSN: 2070-1721 INRIA | |||
INRIA | ||||
A. Brandt | A. Brandt | |||
Sigma Designs | Sigma Designs | |||
J. Martocci | J. Martocci | |||
Johnson Controls | Johnson Controls | |||
April 1, 2013 | August 2013 | |||
A Mechanism to Measure the Routing Metrics along a Point-to-point Route | A Mechanism to Measure the Routing Metrics along a Point-to-Point Route | |||
in a Low Power and Lossy Network | in a Low-Power and Lossy Network | |||
draft-ietf-roll-p2p-measurement-10 | ||||
Abstract | Abstract | |||
This document specifies a mechanism that enables an RPL router to | This document specifies a mechanism that enables a Routing Protocol | |||
measure the aggregated values of given routing metrics along an | for Low-power and Lossy Networks (RPL) router to measure the | |||
existing route towards another RPL router, thereby allowing the | aggregated values of given routing metrics along an existing route | |||
router to decide if it wants to initiate the discovery of a better | towards another RPL router, thereby allowing the router to decide if | |||
route. | it wants to initiate the discovery of a better route. | |||
Status of this Memo | ||||
This Internet-Draft is submitted to IETF in full conformance with the | Status of This Memo | |||
provisions of BCP 78 and BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | This document is not an Internet Standards Track specification; it is | |||
Task Force (IETF). Note that other groups may also distribute | published for examination, experimental implementation, and | |||
working documents as Internet-Drafts. The list of current Internet- | evaluation. | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This document defines an Experimental Protocol for the Internet | |||
and may be updated, replaced, or obsoleted by other documents at any | community. This document is a product of the Internet Engineering | |||
time. It is inappropriate to use Internet-Drafts as reference | Task Force (IETF). It represents the consensus of the IETF | |||
material or to cite them other than as "work in progress." | community. It has received public review and has been approved for | |||
publication by the Internet Engineering Steering Group (IESG). Not | ||||
all documents approved by the IESG are a candidate for any level of | ||||
Internet Standard; see Section 2 of RFC 5741. | ||||
This Internet-Draft will expire on October 3, 2013. | Information about the current status of this document, any errata, | |||
and how to provide feedback on it may be obtained at | ||||
http://www.rfc-editor.org/info/rfc6998. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2013 IETF Trust and the persons identified as the | Copyright (c) 2013 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
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 ....................................................4 | |||
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.1. Terminology ................................................5 | |||
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Overview ........................................................6 | |||
3. The Measurement Object (MO) . . . . . . . . . . . . . . . . . 6 | 3. The Measurement Object (MO) .....................................7 | |||
3.1. Format of the base MO . . . . . . . . . . . . . . . . . . 6 | 3.1. Format of the Base MO ......................................8 | |||
3.2. Secure MO . . . . . . . . . . . . . . . . . . . . . . . . 11 | 3.2. Secure MO .................................................12 | |||
4. Originating a Measurement Request . . . . . . . . . . . . . . 11 | 4. Originating a Measurement Request ..............................13 | |||
4.1. When Measuring A Hop-by-hop Route with a Global | 4.1. When Measuring a Hop-by-Hop Route with a Global | |||
RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 12 | RPLInstanceID .............................................14 | |||
4.2. When Measuring A Hop-by-hop Route with a Local | 4.2. When Measuring a Hop-by-Hop Route with a Local | |||
RPLInstanceID With Route Accumulation Off . . . . . . . . 13 | RPLInstanceID with Route Accumulation Off .................15 | |||
4.3. When Measuring A Hop-by-hop Route with a Local | 4.3. When Measuring a Hop-by-Hop Route with a Local | |||
RPLInstanceID With Route Accumulation On . . . . . . . . . 14 | RPLInstanceID with Route Accumulation On ..................16 | |||
4.4. When Measuring A Source Route . . . . . . . . . . . . . . 16 | 4.4. When Measuring a Source Route .............................17 | |||
5. Processing a Measurement Request at an Intermediate Point . . 17 | 5. Processing a Measurement Request at an Intermediate Point ......19 | |||
5.1. When Measuring A Hop-by-hop Route with a Global | 5.1. When Measuring a Hop-by-Hop Route with a Global | |||
RPLInstanceID . . . . . . . . . . . . . . . . . . . . . . 18 | RPLInstanceID .............................................19 | |||
5.2. When Measuring A Hop-by-hop Route with a Local | 5.2. When Measuring a Hop-by-Hop Route with a Local | |||
RPLInstanceID With Route Accumulation Off . . . . . . . . 19 | RPLInstanceID with Route Accumulation Off .................21 | |||
5.3. When Measuring A Hop-by-hop Route with a Local | 5.3. When Measuring a Hop-by-Hop Route with a Local | |||
RPLInstanceID With Route Accumulation On . . . . . . . . . 20 | RPLInstanceID with Route Accumulation On ..................21 | |||
5.4. When Measuring A Source Route . . . . . . . . . . . . . . 21 | 5.4. When Measuring a Source Route .............................22 | |||
5.5. Final Processing . . . . . . . . . . . . . . . . . . . . . 21 | 5.5. Final Processing ..........................................23 | |||
6. Processing a Measurement Request at the End Point . . . . . . 22 | 6. Processing a Measurement Request at the End Point ..............23 | |||
6.1. Generating the Measurement Reply . . . . . . . . . . . . . 23 | 6.1. Generating the Measurement Reply ..........................24 | |||
7. Processing a Measurement Reply at the Start Point . . . . . . 23 | 7. Processing a Measurement Reply at the Start Point ..............25 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 | 8. Security Considerations ........................................25 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 | 9. IANA Considerations ............................................27 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 | 10. Acknowledgements ..............................................27 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 | 11. References ....................................................28 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 | 11.1. Normative References .....................................28 | |||
11.2. Informative References . . . . . . . . . . . . . . . . . . 27 | 11.2. Informative References ...................................28 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 | ||||
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 | |||
power and Lossy Network (LLN) is a key requirement for many | Low-power and Lossy Network (LLN) is a key requirement for many home | |||
applications [RFC5826][RFC5867]. The IPv6 Routing Protocol for LLNs | and commercial building automation applications [RFC5826] [RFC5867]. | |||
(RPL) [RFC6550] constrains the LLN topology to a Directed Acyclic | The IPv6 Routing Protocol for LLNs (RPL) [RFC6550] constrains the LLN | |||
Graph (DAG) built to optimize the routing costs to reach the DAG's | topology to a Directed Acyclic Graph (DAG) built to optimize the | |||
root. The P2P routing functionality, available under RPL, has the | routing costs to reach the DAG's root. The P2P routing | |||
following key limitations: | functionality, available under RPL, has the 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 that all | |||
routes to be established ahead of the time they are used. Many | P2P routes 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 an application's requirements, [RFC6997] | |||
[I-D.ietf-roll-p2p-rpl] describes P2P-RPL, an extension to core RPL. | describes P2P-RPL, an extension to core RPL. P2P-RPL provides a | |||
P2P-RPL provides a reactive mechanism to discover P2P routes that | reactive mechanism to discover P2P routes that meet the specified | |||
meet the specified routing constraints [RFC6551]. In some cases, the | routing constraints [RFC6551]. In some cases, the application's | |||
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 that the end-to-end loss rate and/or latency | |||
along the route to be below certain thresholds or the LLN topology | along the route be below certain thresholds, or the LLN topology may | |||
may be such that a router can safely assume its destination to be | be such that a router can safely assume that its destination is less | |||
less than a certain number of hops away from itself. | than a certain number of hops away from itself. | |||
When the existing routes are deemed unsatisfactory but the router | When the existing routes are deemed unsatisfactory but the router | |||
does not implicitly know the routing constraints to be used in P2P- | does not implicitly know the routing constraints to be used in | |||
RPL route discovery, it may be necessary for the router to measure | P2P-RPL route discovery, it may be necessary for the router to | |||
the aggregated values of the routing metrics along the existing | measure the aggregated values of the routing metrics along the | |||
route. This knowledge will allow the router to frame reasonable | existing route. This knowledge will allow the router to frame | |||
routing constraints to discover a better route using P2P-RPL. For | reasonable routing constraints to discover a better route using | |||
example, if the router determines the aggregate ETX (Expected Number | P2P-RPL. For example, if the router determines the aggregate ETX | |||
of Transmissions) [RFC6551] along an existing route to be "x", it can | (expected transmission count) [RFC6551] along an existing route to be | |||
use "ETX < x*y", where y is a certain fraction, as the routing | "x", it can use "ETX < x*y", where y is a certain fraction, as the | |||
constraint for use in P2P-RPL route discovery. Note that it is | routing constraint for use in P2P-RPL route discovery. Note that it | |||
important that the routing constraints not be overly strict; | is important that the routing constraints not be overly strict; | |||
otherwise, the P2P-RPL route discovery may fail even though a route | otherwise, the P2P-RPL route discovery may fail even though a route | |||
exists that is much better than the one currently being used. | exists that is much better than the one currently being used. | |||
This document specifies a mechanism that enables an RPL router to | This document specifies a mechanism that enables a RPL router to | |||
measure the aggregated values of the routing metrics along an | measure the aggregated values of the routing metrics along an | |||
existing route to another RPL router in an LLN, thereby allowing the | existing route to another RPL router in an LLN, thereby allowing the | |||
router to decide if it wants to discover a better route using P2P-RPL | router to decide if it wants to discover a better route using P2P-RPL | |||
and determine the routing constraints to be used for this purpose. | and determine the routing constraints to be used for this purpose. | |||
Thus, the utility of this mechanism is dependent on the existence of | Thus, the utility of this mechanism is dependent on the existence of | |||
P2P-RPL, which is targeting publication as an Experimental RFC. It | P2P-RPL [RFC6997]. The hope is that experiments with P2P-RPL and the | |||
makes sense, therefore, for this document also to target publication | mechanism defined in this document will result in feedback on the | |||
as an Experimental RFC. The hope is that experiments with P2P-RPL | utility and benefits of this document, so that a Standards Track | |||
and the mechanism defined in this document will result in feedback on | version of this document can then be developed. | |||
the utility and benefits of this document and it will be revised and | ||||
progressed on the Standards Track based on this feedback. | ||||
1.1. Terminology | 1.1. Terminology | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
[RFC2119]. | [RFC2119]. | |||
This document uses terminology from [RFC6550], | Additionally, this document uses terminology from [RFC6550], | |||
[I-D.ietf-roll-terminology] and [I-D.ietf-roll-p2p-rpl]. | [RFC6554], and [RFC6997]. Further terminology may be found in | |||
Additionally, this document defines the following terms. | [ROLL-TERMS]. This document defines the following terms: | |||
Start Point: The Start Point refers to the RPL router that initiates | Start Point: The RPL router that initiates the measurement process | |||
the measurement process defined in this document and is the start | defined in this document and that is the start point of the P2P | |||
point of the P2P route being measured. | route being measured. | |||
End Point: The End Point refers to the RPL router at the end point of | End Point: The RPL router at the end point of the P2P route being | |||
the P2P route being measured. | measured. | |||
Intermediate Point: An RPL router, other than the Start Point and the | Intermediate Point: A RPL router, other than the Start Point and the | |||
End Point, on the P2P route being measured. | End Point, on the P2P route being measured. | |||
The following terms, already defined in [I-D.ietf-roll-p2p-rpl], have | The following terms, as already defined in [RFC6997], are redefined | |||
been redefined in this document in the following manner. | in this document in the following manner: | |||
Forward direction: The direction from the Start Point to the End | Forward direction: The direction from the Start Point to the | |||
Point. | End Point. | |||
Reverse direction: The direction from the End Point to the Start | Reverse direction: The direction from the End Point to the | |||
Point. | Start Point. | |||
2. Overview | 2. Overview | |||
The mechanism described in this document can be used by a Start Point | The mechanism described in this document can be used by a Start Point | |||
in an LLN to measure the aggregated values of selected routing | in an LLN to measure the aggregated values of selected routing | |||
metrics along a P2P route to an End Point within the LLN. The route | metrics along a P2P route to an End Point within the LLN. The route | |||
is measured in the Forward direction. Such a route could be a Source | is measured in the Forward direction. Such a route could be a Source | |||
Route or a Hop-by-hop Route established using RPL [RFC6550] or P2P- | Route or a Hop-by-hop Route established using RPL [RFC6550] or | |||
RPL [I-D.ietf-roll-p2p-rpl]. Such a route could also be a "mixed" | P2P-RPL [RFC6997]. Such a route could also be a "mixed" route, with | |||
route with the initial part consisting of hop-by-hop ascent to the | the initial part consisting of hop-by-hop ascent to the root of a | |||
root of a non-storing DAG [RFC6550] and the final part consisting of | non-storing DAG [RFC6550] and the final part consisting of a source- | |||
a source-routed descent to the End Point. The Start Point decides | routed descent to the End Point. The Start Point decides what | |||
what metrics to measure and sends a Measurement Request message, | metrics to measure and sends a Measurement Request message, carrying | |||
carrying the desired routing metric objects, along the route. If a | the desired routing metric objects, along the route. If a Source | |||
Source Route is being measured, the Measurement Request carries the | Route is being measured, the Measurement Request carries the route | |||
route inside an Address vector. If a Hop-by-hop Route is being | inside an Address vector. If a Hop-by-hop Route is being measured, | |||
measured, the Measurement Request identifies the route by its | the Measurement Request identifies the route by its RPLInstanceID | |||
RPLInstanceID [RFC6550] (and, in case the RPLInstanceID is a local | [RFC6550] (and, if the RPLInstanceID is a local value, the | |||
value, the Start Point's IPv6 address associated with the route). On | Start Point's IPv6 address associated with the route). On receiving | |||
receiving a Measurement Request, an Intermediate Point updates the | a Measurement Request, an Intermediate Point updates the routing | |||
routing metric values inside the message and forwards it to the next | metric values inside the message and forwards it to the next hop on | |||
hop on the route. Thus, the Measurement Request accumulates the | the route. Thus, the Measurement Request accumulates the values of | |||
values of the routing metrics for the complete route as it travels | the routing metrics for the complete route as it travels towards the | |||
towards the End Point. Upon receiving the Measurement Request, the | End Point. Upon receiving the Measurement Request, the End Point | |||
End Point unicasts a Measurement Reply message, carrying the | unicasts a Measurement Reply message, carrying the accumulated values | |||
accumulated values of the routing metrics, back to the Start Point. | of the routing metrics, back to the Start Point. Optionally, the | |||
Optionally, the Start Point may allow an Intermediate Point to | Start Point may allow an Intermediate Point to generate the | |||
generate the Measurement Reply if the Intermediate Point already | Measurement Reply if the Intermediate Point already knows the | |||
knows the relevant routing metric values along rest of the route. | relevant routing metric values along the rest of the route. | |||
The Measurement Request may include an Address vector that serves one | The Measurement Request may include an Address vector that serves one | |||
of the following functions: | of the following functions: | |||
o To accumulate a Source Route for End Point's use: If a Hop-by-hop | o To accumulate a Source Route for the End Point's use: If a Hop-by- | |||
Route with a local RPLInstanceID is being measured, the Start | hop Route with a local RPLInstanceID is being measured, the | |||
Point may require each Intermediate Point to add its global or | Start Point may require that each Intermediate Point add its | |||
unique local IPv6 address to an Address vector inside the | global or unique-local IPv6 address to an Address vector inside | |||
Measurement Request. The Source Route, thus accumulated, can be | the Measurement Request. The Source Route, thus accumulated, can | |||
used by the End Point to reach the Start Point. In particular, | be used by the End Point to reach the Start Point. In particular, | |||
the End Point may use the accumulated Source Route to send the | the End Point may use the accumulated Source Route to send the | |||
Measurement Reply back to the Start Point. In this case, the | Measurement Reply back to the Start Point. In this case, the | |||
Start Point includes a suitably-sized Address vector in the | Start Point includes a suitably sized Address vector in the | |||
Measurement Request. The size of the Address vector puts a hard | Measurement Request. The size of the Address vector puts a hard | |||
limit on the length of the accumulated route. An Intermediate | limit on the length of the accumulated route. An Intermediate | |||
Point is not allowed to modify the size of the Address vector and | Point is not allowed to modify the size of the Address vector and | |||
must discard a received Measurement Request if the Address vector | must discard a received Measurement Request if the Address vector | |||
is not large enough to contain the complete route. | is not large enough to contain the complete route. | |||
o To carry the Source Route being measured: The Start Point may | o To carry the Source Route being measured: The Start Point may | |||
insert an Address vector inside the Measurement Request to carry | insert an Address vector inside the Measurement Request to carry | |||
the Source Route being measured. Also, the root of a global non- | the Source Route being measured. Also, the root of a global | |||
storing DAG may insert an Address vector, carrying a Source Route | non-storing DAG may insert an Address vector, carrying a Source | |||
from itself to the End Point, inside a Measurement Request message | Route from itself to the End Point, inside a Measurement Request | |||
if this message had been traveling along this DAG so far. This | message if this message had been traveling along this DAG so far. | |||
Source Route must consist of global or unique local IPv6 | This Source Route must consist of global or unique-local IPv6 | |||
addresses. An Intermediate Point is not allowed to modify an | addresses. An Intermediate Point is not allowed to modify an | |||
existing Address vector before forwarding the Measurement Request | existing Address vector before forwarding the Measurement Request | |||
further. In other words, an Intermediate Point must not modify | further. In other words, an Intermediate Point must not modify | |||
the Source Route along which the Measurement Request is currently | the Source Route along which the Measurement Request is currently | |||
traveling. | traveling. | |||
3. The Measurement Object (MO) | 3. The Measurement Object (MO) | |||
This document defines two new RPL Control Message types, the | This document defines two new RPL control message types: the | |||
Measurement Object (MO), with code TBD1, and the Secure MO, with code | Measurement Object (MO), with code 0x06; and the Secure MO, with | |||
TBD2. An MO serves as both Measurement Request and Measurement | code 0x86. An MO serves as both Measurement Request and | |||
Reply. | Measurement Reply. | |||
3.1. Format of the base MO | 3.1. Format of the Base MO | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| RPLInstanceID | Compr |T|H|A|R|B|I| SeqNo | Num | Index | | | RPLInstanceID | Compr |T|H|A|R|B|I| SeqNo | Num | Index | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
. Start Point Address . | . Start Point Address . | |||
. . | . . | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
. End Point Address . | . End Point Address . | |||
. . | . . | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
. Address[0..Num-1] . | . Address[0..Num-1] . | |||
. . | . . | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
. Metric Container Option(s) . | . Metric Container Option(s) . | |||
. . | . . | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 1: Format of the base Measurement Object (MO) | Figure 1: Format of the Base Measurement Object (MO) | |||
The format of a base MO is shown in Figure 1. A base MO consists of | The format of a base MO is shown in Figure 1. A base MO consists of | |||
the following fields: | the following fields: | |||
o RPLInstanceID: This field specifies the RPLInstanceID of the Hop- | o RPLInstanceID: This field specifies the RPLInstanceID of the | |||
by-hop Route along which the Measurement Request travels (or | Hop-by-hop Route along which the Measurement Request travels | |||
traveled initially until it switched over to a Source Route). | (or traveled initially until it switched over to a Source Route). | |||
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 Start Point/End Point | when specifying IPv6 addresses in the Start Point/End Point | |||
Address fields and the Address vector. The "Compr" field, a 4-bit | Address fields and the Address vector. The "Compr" field, a 4-bit | |||
unsigned integer, is set by the Start Point to specify the number | unsigned integer, is set by the Start Point to specify the number | |||
of prefix octets that are elided from the IPv6 addresses in Start | of prefix octets that are elided from the IPv6 addresses in | |||
Point/End Point Address fields and the Address vector. The Start | Start Point/End Point Address fields and the Address vector. The | |||
Point will set the Compr value to zero if full IPv6 addresses are | Start Point will set the Compr value to zero if full IPv6 | |||
to be carried in the Start Point Address/End Point Address fields | addresses are to be carried in the Start Point Address/End Point | |||
and the Address vector. | Address fields and the Address vector. | |||
o Type (T): This flag is set to one if the MO represents a | o Type (T): This flag is set to one if the MO represents a | |||
Measurement Request. The flag is set to zero if the MO is a | Measurement Request. The flag is set to zero if the MO is a | |||
Measurement Reply. | Measurement Reply. | |||
o Hop-by-hop (H): The Start Point MUST set this flag to one if (at | o Hop-by-hop (H): The Start Point MUST set this flag to one if (at | |||
least the initial part of) the route being measured is hop-by-hop. | least the initial part of) the route being measured is hop by hop. | |||
In that case, the Hop-by-hop Route is identified by the | In that case, the Hop-by-hop Route is identified by the | |||
RPLInstanceID, the End Point Address and, if the RPLInstanceID is | RPLInstanceID, the End Point Address, and, if the RPLInstanceID is | |||
a local value, the Start Point Address fields inside the | a local value, the Start Point Address fields inside the | |||
Measurement Request. Here, the Start Point Address field is | Measurement Request. Here, the Start Point Address field is | |||
required to be same as the DODAGID (the identifier of the | required to be the same as the DODAGID (the identifier of the | |||
destination-oritented DAG root) [RFC6550] of the route being | Destination-Oriented DAG (DODAG) root) [RFC6550] of the route | |||
measured. The Start Point MUST set the H flag to zero if the | being measured. The Start Point MUST set the H flag to zero if | |||
route being measured is a Source Route specified in the Address | the route being measured is a Source Route specified in the | |||
vector. An Intermediate Point MUST set the H flag in an outgoing | Address vector. An Intermediate Point MUST set the H flag in an | |||
Measurement Request to the same value that it had in the | outgoing Measurement Request to the same value that it had in the | |||
corresponding incoming Measurement Request unless it is the root | corresponding incoming Measurement Request, except under the | |||
of the non-storing global DAG, identified by the RPLInstanceID, | following circumstance: If the Intermediate Point is the root of | |||
along which the Measurement Request had been traveling so far and | the non-storing global DAG along which the Measurement Request had | |||
the Intermediate Point intends to insert a Source Route inside the | been traveling so far and it intends to insert a Source Route | |||
Address vector to direct it towards the End Point. In that case, | inside the Address vector to direct the Measurement Request | |||
the Intermediate Point MUST set the H flag to zero. | towards the End Point, then it MUST set the H flag to zero. | |||
o Accumulate Route (A): A value 1 in this flag indicates that the | o Accumulate Route (A): A value of 1 in this flag indicates that the | |||
Measurement Request is accumulating a Source Route for use by the | Measurement Request is accumulating a Source Route for use by the | |||
End Point to send the Measurement Reply back to the Start Point. | End Point to send the Measurement Reply back to the Start Point. | |||
Route accumulation MUST NOT be used (i.e., this flag MUST NOT be | Route accumulation MUST NOT be used (i.e., this flag MUST NOT be | |||
set to 1) inside a Measurement Request unless it travels along a | set to one) inside a Measurement Request, unless it travels along | |||
Hop-by-hop Route represented by a local RPLInstanceID (i.e., H = | a Hop-by-hop Route represented by a local RPLInstanceID (i.e., H = | |||
1, RPLInstanceID has a local value). Route accumulation MAY be | 1 and RPLInstanceID has a local value). Route accumulation MAY be | |||
used (i.e., this flag MAY be set to 1) if the Measurement Request | used (i.e., this flag MAY be set to one) if the Measurement | |||
is traveling along a Hop-by-hop Route with a local RPLInstanceID. | Request is traveling along a Hop-by-hop Route with a local | |||
In this case if the route accumulation is on, an Intermediate | RPLInstanceID. In this case, if the route accumulation is on, an | |||
Point adds its unicast global/unique-local IPv6 address (after | Intermediate Point adds its unicast global/unique-local IPv6 | |||
eliding Compr number of prefix octets) to the Address vector in | address (after eliding Compr number of prefix octets) to the | |||
the manner specified in Section 5.3. In other cases, this flag | Address vector in the manner specified in Section 5.3. In other | |||
MUST be set to zero on transmission and ignored on reception. | cases, this flag MUST be set to zero on transmission and ignored | |||
Route accumulation is not allowed when the Measurement Request | on reception. Route accumulation is not allowed when the | |||
travels along a Hop-by-hop Route with a global RPLInstanceID, | Measurement Request travels along a Hop-by-hop Route with a global | |||
i.e., along a global DAG, because: | 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 End Point; and | Route to the End Point; and | |||
* The End Point can presumably reach the Start Point along this | * The End Point can presumably reach the Start Point along this | |||
global DAG (identified by the RPLInstanceID field). | global DAG (identified by the RPLInstanceID field). | |||
o Reverse (R): A value 1 in this flag inside a Measurement Request | o Reverse (R): A value of 1 in this flag inside a Measurement | |||
indicates that the Address vector contains a complete Source Route | Request indicates that the Address vector contains a complete | |||
from the Start Point to the End Point, which can be used, after | Source Route from the Start Point to the End Point, which can be | |||
reversal, by the End Point to send the Measurement Reply back to | used, after reversal, by the End Point to send the Measurement | |||
the Start Point. This flag MAY be set to one inside a Measurement | Reply back to the Start Point. This flag MAY be set to one inside | |||
Request only if a Source Route, from the Start Point to the End | a Measurement Request only if a Source Route, from the Start Point | |||
Point, is being measured. Otherwise, this flag MUST be set to | to the End Point, is being measured. Otherwise, this flag MUST be | |||
zero on transmission and ignored on reception. | set to zero on transmission and ignored on reception. | |||
o Back Request (B): A value 1 in this flag serves as a request to | o Back Request (B): A value of 1 in this flag serves as a request to | |||
the End Point to send a Measurement Request towards the Start | the End Point to send a Measurement Request towards the | |||
Point. On receiving a Measurement Request with the B flag set to | Start Point. On receiving a Measurement Request with the B flag | |||
one, the End Point SHOULD generate a Measurement Request to | set to one, the End Point SHOULD generate a Measurement Request to | |||
measure the cost of its current (or the most preferred) route to | measure the cost of its current (or the most preferred) route to | |||
the Start Point. Receipt of this Measurement Request would allow | the Start Point. Receipt of this Measurement Request would allow | |||
the Start Point to know the cost of the back route from the End | the Start Point to know the cost of the back route from the | |||
Point to itself and thus determine the round-trip cost of reaching | End Point to itself and thus determine the round-trip cost of | |||
the End Point. | reaching the End Point. | |||
o Intermediate Reply (I): A value 1 in this flag serves as a | o Intermediate Reply (I): A value of 1 in this flag serves as | |||
permission to an Intermediate Point to generate a Measurement | permission to an Intermediate Point to generate a Measurement | |||
Reply if it knows the aggregated values of the routing metrics | Reply if it knows the aggregated values of the routing metrics | |||
being measured for the rest of the route. Setting this flag to | being measured for the rest of the route. Setting this flag to | |||
one may be useful in scenarios where the Hop Count [RFC6551] is | one may be useful in scenarios where the Hop Count [RFC6551] is | |||
the routing metric of interest and an Intermediate Point (e.g. the | the routing metric of interest and an Intermediate Point (e.g., | |||
root of a non-storing global DAG or a common ancestor of the Start | the root of a non-storing global DAG or a common ancestor of the | |||
Point and the End Point in a storing global DAG) may know the Hop | Start Point and the End Point in a storing global DAG) may know | |||
Count of the remainder of the route to the End Point. This flag | the Hop Count of the remainder of the route to the End Point. | |||
MAY be set to one only if a Hop-by-hop Route with a global | This flag MAY be set to one only if a Hop-by-hop Route with a | |||
RPLInstanceID is being measured (i.e., H = 1, RPLInstanceID has a | global RPLInstanceID is being measured (i.e., H = 1 and | |||
global value). Otherwise, this flag MUST be set to zero on | RPLInstanceID has a global value). Otherwise, this flag MUST be | |||
transmission and ignored on reception. | set to zero on transmission and ignored on reception. | |||
o SeqNo: A 6-bit sequence number, assigned by the Start Point, that | o SeqNo: This is a 6-bit sequence number, assigned by the | |||
allows the Start Point to uniquely identify a Measurement Request | Start Point, that allows the Start Point to uniquely identify a | |||
and the corresponding Measurement Reply. | Measurement Request and the corresponding Measurement Reply. | |||
o Num: This field indicates the number of elements, each (16 - | o Num: This field indicates the number of elements, each | |||
Compr) octets in size, inside the Address vector. If the value of | (16 - Compr) octets in size, inside the Address vector. If the | |||
this field is zero, the Address vector is not present in the MO. | value of 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 (i.e., H = 0), this field | Route contained in the Address vector (i.e., H = 0), this field | |||
indicates the index in the Address vector of the next hop on the | indicates the index in the Address vector of the next hop on the | |||
route. If the Measurement Request is traveling along a Hop-by-hop | route. If the Measurement Request is traveling along a Hop-by-hop | |||
Route with a local RPLInstanceID and the Route Accumulation is on | Route with a local RPLInstanceID and the route accumulation is on | |||
(i.e., H = 1, RPLInstanceID has a local value, A = 1), this field | (i.e., H = 1, RPLInstanceID has a local value, and A = 1), this | |||
indicates the index in the Address vector where an Intermediate | field indicates the index in the Address vector where an | |||
Point receiving the Measurement Request must store its IPv6 | Intermediate Point receiving the Measurement Request must store | |||
address. Otherwise, this field MUST be set to zero on | its IPv6 address. Otherwise, this field MUST be set to zero on | |||
transmission and ignored on reception. | transmission and ignored on reception. | |||
o Start Point Address: A unicast global or unique local IPv6 address | o Start Point Address: This is a unicast global or unique-local IPv6 | |||
of the Start Point after eliding Compr number of prefix octets. | address of the Start Point after eliding Compr number of prefix | |||
If the Measurement Request is traveling along a Hop-by-hop Route | octets. If the Measurement Request is traveling along a Hop-by- | |||
and the RPLInstanceID field indicates a local value, the Start | hop Route and the RPLInstanceID field indicates a local value, the | |||
Point Address field MUST specify the DODAGID value that, along | Start Point Address field MUST specify the DODAGID value that, | |||
with the RPLInstanceID and the End Point Address, uniquely | along with the RPLInstanceID and the End Point Address, uniquely | |||
identifies the Hop-by-hop Route being measured. | identifies the Hop-by-hop Route being measured. | |||
o End Point Address: A unicast global or unique local IPv6 address | o End Point Address: This is a unicast global or unique-local IPv6 | |||
of the End Point after eliding Compr number of prefix octets. | address of the End Point after eliding Compr number of prefix | |||
octets. | ||||
o Address[0..Num-1]: A vector of unicast global or unique local IPv6 | o Address[0..Num-1]: This field is a vector of unicast global or | |||
addresses (with Compr number of prefix octets elided) representing | unique-local IPv6 addresses (with Compr number of prefix octets | |||
a Source Route: | elided) representing a Source Route: | |||
* Each element in the vector has size (16 - Compr) octets. | * Each element in the vector has size (16 - Compr) octets. | |||
* The total number of elements inside the Address vector is given | * The total number of elements inside the Address vector is given | |||
by the Num field. | by the Num field. | |||
* The Start Point and End Point addresses MUST NOT be included in | * The Start Point and End Point addresses MUST NOT be included in | |||
the Address vector. | the Address vector. | |||
* The Address vector MUST NOT contain any multicast addresses. | * The Address vector MUST NOT contain any multicast addresses. | |||
* If the Start Point wants to measure a Hop-by-hop Route with a | * If the Start Point wants to measure a Hop-by-hop Route with a | |||
local RPLInstanceID and accumulate a Source Route for the End | local RPLInstanceID and accumulate a Source Route for the | |||
Point's use (i.e., the Measurement Request has the H flag set | End Point's use (i.e., the Measurement Request has the H flag | |||
to 1, RPLInstanceID set to a local value and the A flag set to | set to one, RPLInstanceID set to a local value, and the A flag | |||
1), it MUST include a suitably-sized Address vector in the | set to one), it MUST include a suitably sized Address vector in | |||
Measurement Request. As the Measurement Request travels over | the Measurement Request. As the Measurement Request travels | |||
the route being measured, the Address vector accumulates a | over the route being measured, the Address vector accumulates a | |||
Source Route that can be used by the End Point, after reversal, | Source Route that can be used by the End Point, after reversal, | |||
to reach (and, in particular, to send the Measurement Reply | to reach (and, in particular, to send the Measurement Reply | |||
back to) the Start Point. The route MUST be accumulated in the | back to) the Start Point. The route MUST be accumulated in the | |||
Forward direction but the IPv6 addresses in the accumulated | Forward direction, but the IPv6 addresses in the accumulated | |||
route MUST be reachable in the Reverse direction. An | route MUST be reachable in the Reverse direction. An | |||
Intermediate Point MUST add only a global or unique local IPv6 | Intermediate Point MUST add only a global or unique-local IPv6 | |||
address to the Address vector and MUST NOT modify the size of | address to the Address vector and MUST NOT modify the size of | |||
the Address vector. | the Address vector. | |||
* If the Start Point wants to measure a Source Route, it MUST | * If the Start Point wants to measure a Source Route, it MUST | |||
include an Address vector, containing the route being measured, | include an Address vector, containing the route being measured, | |||
inside the Measurement Request. Similarly, if the Measurement | inside the Measurement Request. Similarly, if the Measurement | |||
Request had been traveling along a global non-storing DAG so | Request had been traveling along a global non-storing DAG so | |||
far, the root of this DAG may insert an Address vector, | far, the root of this DAG may insert an Address vector, | |||
containing a Source Route from itself to the End Point, inside | containing a Source Route from itself to the End Point, inside | |||
the Measurement Request. In both cases, the Source Route | the Measurement Request. In both cases, the Source Route | |||
inside the Address vector MUST consist only of global or unique | inside the Address vector MUST consist only of global or | |||
local IPv6 addresses that are reachable in the Forward | unique-local IPv6 addresses that are reachable in the Forward | |||
direction. Further, in both cases, an Intermediate Point MUST | direction. Further, in both cases, an Intermediate Point MUST | |||
NOT modify the contents of the existing Address vector before | NOT modify the contents of the existing Address vector before | |||
forwarding the Measurement Request further. In other words, an | forwarding the Measurement Request further. In other words, an | |||
Intermediate Point MUST NOT modify the Source Route along which | Intermediate Point MUST NOT modify the Source Route along which | |||
the Measurement Request is currently traveling. The Start | the Measurement Request is currently traveling. The | |||
Point MAY set the R flag in the Measurement Request to one if | Start Point MAY set the R flag in the Measurement Request to | |||
the Source Route inside the Address vector can be used by the | one if the Source Route inside the Address vector can be used | |||
End Point, after reversal, to reach (and, in particular, to | by the End Point, after reversal, to reach (and, in particular, | |||
send the Measurement Reply back to) the Start Point. In other | to send the Measurement Reply back to) the Start Point. In | |||
words, the Start Point MAY set the R flag to one only if all | other words, the Start Point MAY set the R flag to one only if | |||
the IPv6 addresses in the Address vector are reachable in the | all the IPv6 addresses in the Address vector are reachable in | |||
Reverse direction. | the Reverse direction. | |||
o Metric Container Options: A Measurement Request MUST contain one | o Metric Container Options: A Measurement Request MUST contain one | |||
or more Metric Container options [RFC6550] to accumulate the | or more Metric Container options [RFC6550] to accumulate the | |||
values of the selected routing metrics in the manner described in | values of the selected routing metrics in the manner described in | |||
[RFC6551] for the route being measured. | [RFC6551] for the route being measured. | |||
Section 4 describes how a Start Point sets various fields inside a | Section 4 describes how a Start Point sets various fields inside a | |||
Measurement Request in different cases. Section 5 describes how an | Measurement Request in different cases. Section 5 describes how an | |||
Intermediate Point processes a received Measurement Request before | Intermediate Point processes a received Measurement Request before | |||
forwarding it further. Section 6 describes how the End Point | forwarding it further. Section 6 describes how the End Point | |||
processes a received Measurement Request and generate a Measurement | processes a received Measurement Request and generates a Measurement | |||
Reply. Finally, Section 7 describes how the Start Point processes a | Reply. Finally, Section 7 describes how the Start Point processes a | |||
received Measurement Reply. In the following discussion, any | received Measurement Reply. In the following discussion, any | |||
reference to discarding a received Measurement Request/Reply with "no | reference to discarding a received Measurement Request/Reply with "no | |||
further processing" does not preclude updating the appropriate error | further processing" does not preclude updating the appropriate error | |||
counters or any similar actions. | counters or any similar actions. | |||
3.2. Secure MO | 3.2. Secure MO | |||
A Secure MO follows the format in Figure 7 of [RFC6550], where the | A Secure MO follows the format shown in Figure 7 of [RFC6550], where | |||
base format is the base MO shown in Figure 1. Sections 6.1, 10 and | the base format is the base MO shown in Figure 1. Sections 6.1, 10, | |||
19 of [RFC6550] describe RPL security framework. These sections are | and 19 of [RFC6550] describe the RPL security framework. These | |||
applicable to the use of Secure MO messages as well except as | sections are applicable to the use of Secure MO messages as well, | |||
constrained in this section. An LLN deployment MUST support the use | except as constrained in this section. An LLN deployment MUST | |||
of Secure MO messages so that it has the ability to invoke RPL- | support the use of Secure MO messages so that it has the ability to | |||
provided security mechanisms and prevent misuse of the measurement | invoke RPL-provided security mechanisms and prevent misuse of the | |||
mechanism by unauthorized routers. | measurement mechanism by unauthorized routers. | |||
The Start Point determines whether Secure MO messages are to be used | The Start Point determines whether Secure MO messages are to be used | |||
in a particular route measurement and if yes the Security | in a particular route measurement and, if yes, the Security | |||
Configuration (see definition in [I-D.ietf-roll-p2p-rpl]) to be used | Configuration (see definition in [RFC6997]) to be used for that | |||
for the purpose. The Start Point MUST NOT set the "Key Identifier | purpose. The Start Point MUST NOT set the "Key Identifier Mode" | |||
Mode" field to value 1 inside this Security Configuration since this | field to a value of 1 inside this Security Configuration, since this | |||
setting indicates the use of a per-pair key which is not suitable for | setting indicates the use of a per-pair key, which is not suitable | |||
securing the Measurement Request messages that travel over multiple | for securing the Measurement Request messages that travel over | |||
hops. A router (an Intermediate Point or the End Point), | multiple hops. A router (an Intermediate Point or the End Point) | |||
participating in a particular route measurement, | participating in a particular route measurement | |||
o MUST generate a Secure MO message (a Measurement Request or a | o MUST generate a Secure MO message (a Measurement Request or a | |||
Measurement Reply) if the received Measurement Request is a Secure | Measurement Reply) if the received Measurement Request is a Secure | |||
MO. The Security Configuration used in generating a Secure MO | MO. The Security Configuration used in generating a Secure MO | |||
message MUST be same as the one used in the received message. | message MUST be the same as the one used in the received message. | |||
o MUST NOT generate a Secure MO message if the received Measurement | o MUST NOT generate a Secure MO message if the received Measurement | |||
Request is not a Secure MO. | Request is not a Secure MO. | |||
A router MUST discard a received Measurement Request if it cannot | A router MUST discard a received Measurement Request if it cannot | |||
follow the above mentioned rules. If the Start Point sends a | follow the above-mentioned rules. If the Start Point sends a | |||
Measurement Request in a Secure MO message using a particular | Measurement Request in a Secure MO message using a particular | |||
Security Configuration, it MUST discard the corresponding Measurement | Security Configuration, it MUST discard the corresponding Measurement | |||
Reply it receives with no further processing unless the Measurement | Reply it receives with no further processing, unless the Measurement | |||
Reply is received in a Secure MO message generated with same Security | Reply is received in a Secure MO message generated with the same | |||
Configuration as the one used in the Measurement Request. | Security Configuration as the one used in the Measurement Request. | |||
In the following discussion, any reference to an MO message is also | In the following discussion, any reference to an MO message is also | |||
applicable to a Secure MO message unless noted otherwise. | applicable to a Secure MO message, unless noted otherwise. | |||
4. Originating a Measurement Request | 4. Originating a Measurement Request | |||
A Start Point sets various fields inside the Measurement Request it | A Start Point sets various fields inside the Measurement Request it | |||
generates in the manner described below. The Start Point MUST also | generates in the manner described below. The Start Point MUST also | |||
include the routing metric objects [RFC6551] of interest inside one | include the routing metric objects [RFC6551] of interest inside one | |||
or more Metric Container options inside the Measurement Request. The | or more Metric Container options inside the Measurement Request. The | |||
Start Point then determines the next hop on the route being measured. | Start Point then determines the next hop on the route being measured. | |||
If a Hop-by-hop route is being measured (i.e., H = 1), the next hop | If a Hop-by-hop Route is being measured (i.e., H = 1), the next hop | |||
is determined using the RPLInstanceID, the End Point Address and, if | is determined using the RPLInstanceID, the End Point Address, and, if | |||
RPLInstanceID is a local value, the Start Point Address fields in the | RPLInstanceID is a local value, the Start Point Address fields in the | |||
Measurement Request. If a Source Route is being measured (i.e., H = | Measurement Request. If a Source Route is being measured (i.e., | |||
0), the Address[0] element inside the Measurement Request contains | H = 0), the Address[0] element inside the Measurement Request | |||
the next hop address. The Start Point MUST ensure that | contains the next-hop address. The Start Point MUST ensure that | |||
o the next hop address is a unicast address; and | ||||
o the next hop is on-link; and | o the next-hop address is a unicast address, and | |||
o the next hop is in the same RPL routing domain | o the next hop is on-link, and | |||
[I-D.ietf-roll-terminology] as the Start Point; | o the next hop is in the same RPL routing domain [RFC6554] as the | |||
Start Point, | ||||
failing which the Start Point MUST discard the Measurement Request | failing which the Start Point MUST discard the Measurement Request | |||
without sending. Depending on the routing metrics, the Start Point | without sending. Depending on the routing metrics, the Start Point | |||
must initiate the routing metric objects inside the Metric Container | must initiate the routing metric objects inside the Metric Container | |||
options by including the routing metric values for the first hop on | options by including the routing metric values for the first hop on | |||
the route being measured. Finally, the Start Point MUST unicast the | the route being measured. Finally, the Start Point MUST unicast the | |||
Measurement Request to the next hop on the route being measured. | Measurement Request to the next hop on the route being measured. | |||
The Start Point MUST maintain state for just transmitted Measurement | The Start Point MUST maintain state for a just-transmitted | |||
Request for a life time duration that is large enough to allow the | Measurement Request, for a lifetime duration that is large enough to | |||
corresponding Measurement Reply to return. This state consists of | allow the corresponding Measurement Reply to return. This state | |||
the RPLInstanceID, the SeqNo and the End Point Address fields of the | consists of the RPLInstanceID, the SeqNo, and the End Point Address | |||
Measurement Request. The life time duration for this state is | fields of the Measurement Request. The lifetime duration for this | |||
locally determined by the Start Point and may be deployment specific. | state is locally determined by the Start Point and may be deployment | |||
This state expires when the corresponding Measurement Reply is | specific. This state expires when the corresponding Measurement | |||
received or when the life time is over, whichever occurs first. | Reply is received or when the lifetime is over, whichever occurs | |||
Failure to receive the corresponding Measurement Reply before the | first. Failure to receive the corresponding Measurement Reply before | |||
expiry of a state may occur due to a number of reasons including | the expiry of a state may occur due to a number of reasons, including | |||
unwillingness on part of an Intermediate Point or the End Point to | the unwillingness on the part of an Intermediate Point or the | |||
process the Measurement Request. The Start Point should take such | End Point to process the Measurement Request. The Start Point should | |||
possibilities in account when deciding whether to generate another | take such possibilities into account when deciding whether to | |||
Measurement Request for this route. The Start Point MUST discard a | generate another Measurement Request for this route. The Start Point | |||
received Measurement Reply with no further processing if the state | MUST discard a received Measurement Reply with no further processing | |||
for the corresponding Measurement Request has already expired. | if the state for the corresponding Measurement Request has already | |||
expired. | ||||
4.1. When Measuring A Hop-by-hop Route with a Global RPLInstanceID | 4.1. When Measuring a Hop-by-Hop Route with a Global RPLInstanceID | |||
If a Hop-by-hop Route with a global RPLInstanceID is being measured | If a Hop-by-hop Route with a global RPLInstanceID is being measured | |||
(i.e., H = 1, RPLInstanceID has a global value), the MO MUST NOT | (i.e., H = 1 and RPLInstanceID has a global value), the MO MUST NOT | |||
contain an Address vector and various MO fields MUST be set in the | contain an Address vector, and various MO fields MUST be set in the | |||
following manner: | following manner: | |||
o RPLInstanceID: MUST be set to the RPLInstanceID of the route being | o RPLInstanceID: This field MUST be set to the RPLInstanceID of the | |||
measured. | route being measured. | |||
o Compr: MUST be set to specify the number of prefix octets that are | o Compr: This field MUST be set to specify the number of prefix | |||
elided from the IPv6 addresses in Start Point/End Point Address | octets that are elided from the IPv6 addresses in Start Point/ | |||
fields. | End Point Address fields. | |||
o Type (T): MUST be set to one since the MO represents a Measurement | o Type (T): This flag MUST be set to one, since the MO represents a | |||
Request. | Measurement Request. | |||
o Hop-by-hop (H): 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 Back Request (B): This flag MAY be set to one to request the End | o Back Request (B): This flag MAY be set to one to request that the | |||
Point to send a Measurement Request to the Start Point. | End Point send a Measurement Request to the Start Point. | |||
o Intermediate Reply (I): This flag MAY be set to one if the Start | o Intermediate Reply (I): This flag MAY be set to one if the | |||
Point expects an Intermediate Point to know the values of the | Start Point expects an Intermediate Point to know the values of | |||
routing metrics being measured for the remainder of the route. | the routing metrics being measured for the remainder of the route. | |||
o SeqNo: Assigned by the Start Point so that it can uniquely | o SeqNo: This is assigned by the Start Point so that it can uniquely | |||
identify the Measurement Request and the corresponding Measurement | identify the Measurement Request and the corresponding | |||
Reply. | Measurement Reply. | |||
o Num: This field MUST be set to zero. | o Num: This field MUST be set to zero. | |||
o Index: This field MUST be set to zero. | o Index: This field MUST be set to zero. | |||
o Start Point Address: MUST be set to a unicast global/unique-local | o Start Point Address: This field MUST be set to a unicast | |||
IPv6 address of the Start Point after eliding Compr number of | global/unique-local IPv6 address of the Start Point after eliding | |||
prefix octets. | Compr number of prefix octets. | |||
o End Point Address: MUST be set to a unicast global/unique-local | o End Point Address: This field MUST be set to a unicast | |||
IPv6 address of the End Point after eliding Compr number of prefix | global/unique-local IPv6 address of the End Point after eliding | |||
octets. | Compr number of prefix octets. | |||
4.2. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With | 4.2. When Measuring a Hop-by-Hop Route with a Local RPLInstanceID with | |||
Route Accumulation Off | Route Accumulation Off | |||
If a Hop-by-hop Route with a local RPLInstanceID is being measured | If a Hop-by-hop Route with a local RPLInstanceID is being measured | |||
and the Start Point does not want the MO to accumulate a Source Route | and the Start Point does not want the MO to accumulate a Source Route | |||
for the End Point's use, the MO MUST NOT contain the Address vector | for the End Point's use, the MO MUST NOT contain the Address vector, | |||
and various MO fields MUST be set in the following manner: | and various MO fields MUST be set in the following manner: | |||
o RPLInstanceID: MUST be set to the RPLInstanceID of the route being | o RPLInstanceID: This field MUST be set to the RPLInstanceID of the | |||
measured. | route being measured. | |||
o Compr: MUST be set to specify the number of prefix octets that are | o Compr: This field MUST be set to specify the number of prefix | |||
elided from the IPv6 addresses in Start Point/End Point Address | octets that are elided from the IPv6 addresses in Start Point/ | |||
fields. | End Point Address fields. | |||
o Type (T): MUST be set to one since the MO represents a Measurement | o Type (T): This flag MUST be set to one, since the MO represents a | |||
Request. | Measurement Request. | |||
o Hop-by-hop (H): 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 Back Request (B): This flag MAY be set to one to request the End | o Back Request (B): This flag MAY be set to one to request that the | |||
Point to send a Measurement Request to the Start Point. | End Point send a Measurement Request to the Start Point. | |||
o Intermediate Reply (I): This flag MUST be set to zero. | o Intermediate Reply (I): This flag MUST be set to zero. | |||
o SeqNo: Assigned by the Start Point so that it can uniquely | o SeqNo: This is assigned by the Start Point so that it can uniquely | |||
identify the Measurement Request and the corresponding Measurement | identify the Measurement Request and the corresponding | |||
Reply. | Measurement Reply. | |||
o Num: This field MUST be set to zero. | o Num: This field MUST be set to zero. | |||
o Index: This field MUST be set to zero. | o Index: This field MUST be set to zero. | |||
o Start Point Address: This field MUST contain the DODAGID value | o Start Point Address: This field MUST contain the DODAGID value | |||
(after eliding Compr number of prefix octets) associated with the | (after eliding Compr number of prefix octets) associated with the | |||
route being measured. This DODAGID MUST also be a global or | route being measured. This DODAGID MUST also be a global or | |||
unique local IPv6 address of the Start Point. | unique-local IPv6 address of the Start Point. | |||
o End Point Address: MUST be set to a unicast global or unique local | o End Point Address: This field MUST be set to a unicast global or | |||
IPv6 address of the End Point after eliding Compr number of prefix | unique-local IPv6 address of the End Point after eliding Compr | |||
octets. | number of prefix octets. | |||
4.3. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With | 4.3. When Measuring a Hop-by-Hop Route with a Local RPLInstanceID with | |||
Route Accumulation On | Route Accumulation On | |||
If a Hop-by-hop Route with a local RPLInstanceID is being measured | If a Hop-by-hop Route with a local RPLInstanceID is being measured | |||
and the Start Point desires the MO to accumulate a Source Route for | and the Start Point desires the MO to accumulate a Source Route for | |||
the End Point to send the Measurement Reply message back, the MO MUST | the End Point to send the Measurement Reply message back, the MO MUST | |||
contain a suitably-sized Address vector and various MO fields MUST be | contain a suitably sized Address vector, and various MO fields MUST | |||
set in the following manner: | be set in the following manner: | |||
o RPLInstanceID: MUST be set to the RPLInstanceID of the route being | o RPLInstanceID: This field MUST be set to the RPLInstanceID of the | |||
measured. | route being measured. | |||
o Compr: MUST be set to specify the number of prefix octets that are | o Compr: This field MUST be set to specify the number of prefix | |||
elided from the IPv6 addresses in Start Point/End Point Address | octets that are elided from the IPv6 addresses in Start Point/ | |||
fields and the Address vector. | End Point Address fields and the Address vector. | |||
o Type (T): MUST be set to one since the MO represents a Measurement | o Type (T): This flag MUST be set to one, since the MO represents a | |||
Request. | Measurement Request. | |||
o Hop-by-hop (H): 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 Back Request (B): This flag MAY be set to one to request the End | o Back Request (B): This flag MAY be set to one to request that the | |||
Point to send a Measurement Request to the Start Point. | End Point send a Measurement Request to the Start Point. | |||
o Intermediate Reply (I): This flag MUST be set to zero. | o Intermediate Reply (I): This flag MUST be set to zero. | |||
o SeqNo: Assigned by the Start Point so that it can uniquely | o SeqNo: This is assigned by the Start Point so that it can uniquely | |||
identify the Measurement Request and the corresponding Measurement | identify the Measurement Request and the corresponding | |||
Reply. | Measurement Reply. | |||
o Num: This field MUST specify the number of address elements, each | o Num: This field MUST specify the number of address elements, each | |||
(16 - Compr) octets in size, that can fit inside the Address | (16 - Compr) octets in size, that can fit inside the Address | |||
vector. | vector. | |||
o Index: This field MUST be set to zero to indicate the position in | o Index: This field MUST be set to zero to indicate the position in | |||
the Address vector where the next hop must store its IPv6 address. | the Address vector where the next hop must store its IPv6 address. | |||
o Start Point Address: This field MUST contain the DODAGID value | o Start Point Address: This field MUST contain the DODAGID value | |||
(after eliding Compr number of prefix octets) associated with the | (after eliding Compr number of prefix octets) associated with the | |||
route being measured. This DODAGID MUST also be a global or | route being measured. This DODAGID MUST also be a global or | |||
unique local IPv6 address of the Start Point. | unique-local IPv6 address of the Start Point. | |||
o End Point Address: MUST be set to a unicast global or unique local | o End Point Address: This field MUST be set to a unicast global or | |||
IPv6 address of the End Point after eliding Compr number of prefix | unique-local IPv6 address of the End Point after eliding Compr | |||
octets. | number of prefix octets. | |||
o Address vector: The Address vector must be large enough to | o Address vector: The Address vector must be large enough to | |||
accomodate a complete Source Route from the End Point to the Start | accommodate a complete Source Route from the End Point to the | |||
Point. All the bits in the Address vector field MUST be set to | Start Point. All the bits in the Address vector field MUST be set | |||
zero. | to zero. | |||
4.4. When Measuring A Source Route | 4.4. When Measuring a Source Route | |||
If a Source Route is being measured, the Start Point MUST set various | If a Source Route is being measured, the Start Point MUST set various | |||
MO fields in the following manner: | MO fields in the following manner: | |||
o RPLInstanceID: This field does not have any significance when a | o RPLInstanceID: This field does not have any significance when a | |||
Source Route is being measured and hence can be set to any value. | Source Route is being measured and hence can be set to any value. | |||
o Compr: MUST be set to specify the number of prefix octets that are | o Compr: This field MUST be set to specify the number of prefix | |||
elided from the IPv6 addresses in Start Point/End Point Address | octets that are elided from the IPv6 addresses in Start Point/ | |||
fields and the Address vector. | End Point Address fields and the Address vector. | |||
o Type (T): MUST be set to one since the MO represents a Measurement | o Type (T): This flag MUST be set to one, since the MO represents a | |||
Request. | Measurement Request. | |||
o Hop-by-hop (H): 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 End Point to | the Address vector can be reversed and used by the End Point to | |||
send the Measurement Reply message back to the Start Point. | send the Measurement Reply message back to the Start Point. | |||
Otherwise, this flag MUST be set to zero. | Otherwise, this flag MUST be set to zero. | |||
o Back Request (B): This flag MAY be set to one to request the End | o Back Request (B): This flag MAY be set to one to request that the | |||
Point to send a Measurement Request to the Start Point. | End Point send a Measurement Request to the Start Point. | |||
o Intermediate Reply (I): This flag MUST be set to zero. | o Intermediate Reply (I): This flag MUST be set to zero. | |||
o SeqNo: Assigned by the Start Point so that it can uniquely | o SeqNo: This is assigned by the Start Point so that it can uniquely | |||
identify the Measurement Request and the corresponding Measurement | identify the Measurement Request and the corresponding | |||
Reply. | Measurement Reply. | |||
o Num: This field MUST specify the number of address elements, each | o Num: This field MUST specify the number of address elements, each | |||
(16 - Compr) octets in size, inside the Address vector. | (16 - Compr) octets in size, inside the Address vector. | |||
o Index: This field MUST be set to zero to indicate the position in | o Index: This field MUST be set to zero to indicate the position in | |||
the Address vector of the next hop on the route. | the Address vector of the next hop on the route. | |||
o Start Point Address: MUST be set to a unicast global or unique | o Start Point Address: This field MUST be set to a unicast global or | |||
local IPv6 address of the Start Point after eliding Compr number | unique-local IPv6 address of the Start Point after eliding Compr | |||
of prefix octets. | number of prefix octets. | |||
o End Point Address: MUST be set to a unicast global or unique local | o End Point Address: This field MUST be set to a unicast global or | |||
IPv6 address of the End Point after eliding Compr number of prefix | unique-local IPv6 address of the End Point after eliding Compr | |||
octets. | number of prefix octets. | |||
o Address vector: | o Address vector: | |||
* The Address vector MUST contain a complete Source Route from | * The Address vector MUST contain a complete Source Route from | |||
the Start Point to the End Point (excluding the Start Point and | the Start Point to the End Point (excluding the Start Point and | |||
the End Point). | the End Point). | |||
* Each address appearing in the Address vector MUST be a unicast | * Each address appearing in the Address vector MUST be a unicast | |||
global or unique local IPv6 address. Further, each address | global or unique-local IPv6 address. Further, each address | |||
MUST have the same prefix as the Start Point Address and the | MUST have the same prefix as the Start Point Address and the | |||
End Point Address. This prefix, whose length in octets is | End Point Address. This prefix, whose length in octets is | |||
specified in the Compr field, MUST be elided from each address. | specified in the Compr field, MUST be elided from each address. | |||
* The IPv6 addresses in the Address vector MUST be reachable in | * The IPv6 addresses in the Address vector MUST be reachable in | |||
the Forward direction. | the Forward direction. | |||
* If the R flag is set to one, the IPv6 addresses in the Address | * If the R flag is set to one, the IPv6 addresses in the Address | |||
vector MUST also be reachable in the Reverse direction. | vector MUST also be reachable in the Reverse direction. | |||
5. Processing a Measurement Request at an Intermediate Point | 5. Processing a Measurement Request at an Intermediate Point | |||
A router (an Intermediate Point or the End Point) MAY discard a | A router (an Intermediate Point or the End Point) MAY discard a | |||
received MO with no processing to meet any policy-related goal. Such | received MO with no processing, in order to meet any policy-related | |||
policy goals may include the need to reduce the router's CPU load or | goals. Such policy goals may include the need to reduce the router's | |||
to enhance its battery life or to prevent misuse of this mechanism by | CPU load, or to enhance its battery life, or to prevent the misuse of | |||
unauthorized nodes. | this mechanism by unauthorized nodes. | |||
A router MUST discard a received MO with no further processing if the | A router MUST discard a received MO with no further processing if the | |||
value in the Compr field inside the received message is more than | value in the Compr field inside the received message is more than | |||
what the router considers the length of the common prefix used in | what the router considers to be the length of the common prefix used | |||
IPv6 addresses in the LLN to be. | in IPv6 addresses in the LLN. | |||
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 determine whether or not one of its IPv6 addresses | |||
either the Start Point or the End Point Address. If neither, the | is listed as either the Start Point or the End Point Address. If | |||
router considers itself an Intermediate Point and MUST process the | not, the router considers itself an Intermediate Point and MUST | |||
received MO in the following manner. | process the received MO in the following manner. | |||
An Intermediate Point MUST discard the packet with no further | An Intermediate Point MUST discard the packet with no further | |||
processing if the received MO is not a Measurement Request (i.e., T = | processing if the received MO is not a Measurement Request (i.e., | |||
0). This is because the End Point unicasts a Measurement Reply | T = 0). This is because the End Point unicasts a Measurement Reply | |||
directly to the Start Point. So, the Intermediate Point treats a | directly to the Start Point. So, the Intermediate Point treats a | |||
transiting Measurement Reply as a data packet and not an RPL control | transiting Measurement Reply as a data packet and not a RPL control | |||
message. | message. | |||
Next, the Intermediate Point determines the type of the route being | Next, the Intermediate Point determines the type of the route being | |||
measured (by checking the values of the H flag and the RPLInstanceID | measured (by checking the values of the H flag and the RPLInstanceID | |||
field) and processes the received MO accordingly in the manner | field) and processes the received MO accordingly, in the manner | |||
specified next. | specified next. | |||
5.1. When Measuring A Hop-by-hop Route with a Global RPLInstanceID | 5.1. When Measuring a Hop-by-Hop Route with a Global RPLInstanceID | |||
If a Hop-by-hop Route with a global RPLInstanceID is being measured | If a Hop-by-hop Route with a global RPLInstanceID is being measured | |||
(i.e. H = 1 and RPLInstanceID has a global value), the Intermediate | (i.e., H = 1 and RPLInstanceID has a global value), the Intermediate | |||
Point MUST process the received Measurement Request in the following | Point MUST process the received Measurement Request in the following | |||
manner. | manner. | |||
If the Num field inside the received Measurement Request is not set | If the Num field inside the received Measurement Request is not set | |||
to zero, thereby implying that an Address vector is present, the | to zero, thereby implying that an Address vector is present, the | |||
Intermediate Point MUST discard the received message with no further | Intermediate Point MUST discard the received message with no further | |||
processing. | processing. | |||
If the Intermediate Reply (I) flag is set to one in the received | If the Intermediate Reply (I) flag is set to one in the received | |||
Measurement Request and the Intermediate Point knows the values of | Measurement Request and the Intermediate Point knows the values of | |||
the routing metrics, specified in the Metric Container options, for | the routing metrics (as specified in the Metric Container options) | |||
the remainder of the route, it MAY generate a Measurement Reply on | for the remainder of the route, it MAY generate a Measurement Reply | |||
the End Point's behalf in the manner specified in Section 6.1 (after | on the End Point's behalf in the manner specified in Section 6.1 | |||
including in the Measurement Reply the relevant routing metric values | (after including in the Measurement Reply the relevant routing metric | |||
for the complete route being measured). Otherwise, the Intermediate | values for the complete route being measured). Otherwise, the | |||
Point MUST process the received message in the following manner. | Intermediate Point MUST process the received message in the following | |||
manner. | ||||
The Intermediate Point MUST determine the next hop on the route being | The Intermediate Point MUST determine the next hop on the route being | |||
measured using the RPLInstanceID and the End Point Address. If the | measured using the RPLInstanceID and the End Point Address. If the | |||
Intermediate Point is the root of the non-storing global DAG along | Intermediate Point is the root of the non-storing global DAG along | |||
which the received Measurement Request had been traveling so far, it | which the received Measurement Request had been traveling so far, it | |||
MUST process the received Measurement Request in the following | MUST process the received Measurement Request in the following | |||
manner: | manner: | |||
o If the router does not know how to reach the End Point, it MUST | o If the router does not know how to reach the End Point, it MUST | |||
discard the Measurement Request with no further processing and MAY | discard the Measurement Request with no further processing and MAY | |||
send an ICMPv6 Destination Unreachable (with Code 0 - No Route To | send an ICMPv6 Destination Unreachable (with Code 0 -- No Route To | |||
Destination) error message [RFC4443] to the Start Point. | Destination) error message [RFC4443] to the Start Point. | |||
o Otherwise, unless the router determines the End Point itself to be | o Otherwise, unless the router determines the End Point itself to be | |||
the next hop, the router MUST make the following changes in the | the next hop, the router MUST make the following changes in the | |||
received Measurement Request: | received Measurement Request: | |||
* Set the H, A, R and I flags to zero (the A and R flags should | * Set the H, A, R, and I flags to zero (the A and R flags should | |||
already be zero in the received message). | already be zero in the received message). | |||
* Leave remaining fields unchanged (the Num field would be | * Leave the remaining fields unchanged (the Num field would be | |||
modified in next steps). Note that the RPLInstanceID field | modified in the next steps). Note that the RPLInstanceID field | |||
identifies the non-storing global DAG along which the | identifies the non-storing global DAG along which the | |||
Measurement Request traveled so far. This information MUST be | Measurement Request traveled so far. This information MUST be | |||
preserved so that the End Point may use this DAG to send the | preserved so that the End Point may use this DAG to send the | |||
Measurement Reply back to the Start Point. | Measurement Reply back to the Start Point. | |||
* Insert a new Address vector inside the Measurement Request and | * Insert a new Address vector inside the Measurement Request, and | |||
specify a Source Route to the End Point inside the Address | specify a Source Route to the End Point inside the Address | |||
vector as per the following rules: | vector as per the following rules: | |||
+ The Address vector MUST contain a complete route from the | + The Address vector MUST contain a complete route from the | |||
router to the End Point (excluding the router and the End | router to the End Point (excluding the router and the | |||
Point); | End Point). | |||
+ Each address appearing in the Address vector MUST be a | + Each address appearing in the Address vector MUST be a | |||
unicast global or unique local IPv6 address. Further, each | unicast global or unique-local IPv6 address. Further, each | |||
address MUST have the same prefix as the Start Point Address | address MUST have the same prefix as the Start Point Address | |||
and the End Point Address. This prefix, whose length in | and the End Point Address. This prefix, whose length in | |||
octets is specified in the Compr field, MUST be elided from | octets is specified in the Compr field, MUST be elided from | |||
each address. | each address. | |||
+ The IPv6 addresses in the Address vector MUST be reachable | + The IPv6 addresses in the Address vector MUST be reachable | |||
in the Forward direction; | in the Forward direction. | |||
If the router cannot insert an Address vector satisfying the | If the router cannot insert an Address vector satisfying the | |||
rules mentioned above, it MUST discard the Measurement Request | rules mentioned above, it MUST discard the Measurement Request | |||
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 | Unreachable (with Code 0 -- No Route To Destination) error | |||
message [RFC4443] to the Start Point. | message [RFC4443] to the Start Point. | |||
* Specify in the Num field the number of address elements in the | * Specify in the Num field the number of address elements in the | |||
Address vector. | Address vector. | |||
* Set the Index field to zero to indicate the position in the | * Set the Index field to zero to indicate the position in the | |||
Address vector of the next hop on the route. Thus, Address[0] | Address vector of the next hop on the route. Thus, the | |||
element contains the address of the next hop on the route. | Address[0] element contains the address of the next hop on the | |||
route. | ||||
The Intermediate Point MUST then complete the processing of the | The Intermediate Point MUST then complete the processing of the | |||
received Measurement Request as specified in Section 5.5. | received Measurement Request as specified in Section 5.5. | |||
5.2. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With | 5.2. When Measuring a Hop-by-Hop Route with a Local RPLInstanceID with | |||
Route Accumulation Off | Route Accumulation Off | |||
If a Hop-by-hop Route with a local RPLInstanceID is being measured | If a Hop-by-hop Route with a local RPLInstanceID is being measured | |||
and the route accumulation is off (i.e., H = 1, RPLInstanceID has a | and the route accumulation is off (i.e., H = 1, RPLInstanceID has a | |||
local value, A = 0), the Intermediate Point MUST process the received | local value, and A = 0), the Intermediate Point MUST process the | |||
Measurement Request in the following manner. | received Measurement Request in the following manner. | |||
If the Num field inside the received Measurement Request is not set | If the Num field inside the received Measurement Request is not set | |||
to zero, thereby implying that an Address vector is present, the | to zero, thereby implying that an Address vector is present, the | |||
Intermediate Point MUST discard the received message with no further | Intermediate Point MUST discard the received message with no further | |||
processing. | processing. | |||
The Intermediate Point MUST then determine the next hop on the route | The Intermediate Point MUST then determine the next hop on the route | |||
being measured using the RPLInstanceID, the End Point Address and the | being measured using the RPLInstanceID, the End Point Address, and | |||
Start Point Address (which represents the DODAGID of the route being | the Start Point Address (which represents the DODAGID of the route | |||
measured). If the Intermediate Point can not determine the next hop, | being measured). If the Intermediate Point cannot determine the next | |||
it MUST discard the Measurement Request with no further processing | hop, it MUST discard the Measurement Request with no further | |||
and MAY send an ICMPv6 Destination Unreachable (with Code 0 - No | processing and MAY send an ICMPv6 Destination Unreachable (with | |||
Route To Destination) error message [RFC4443] to the Start Point. | Code 0 -- No Route To Destination) error message [RFC4443] to the | |||
Otherwise, the Intermediate Point MUST complete the processing of the | Start Point. Otherwise, the Intermediate Point MUST complete the | |||
received Measurement Request as specified in Section 5.5. | processing of the received Measurement Request as specified in | |||
Section 5.5. | ||||
5.3. When Measuring A Hop-by-hop Route with a Local RPLInstanceID With | 5.3. When Measuring a Hop-by-Hop Route with a Local RPLInstanceID with | |||
Route Accumulation On | Route Accumulation On | |||
If a Hop-by-hop Route with a local RPLInstanceID is being measured | If a Hop-by-hop Route with a local RPLInstanceID is being measured | |||
and the route accumulation is on (i.e., H = 1, RPLInstanceID has a | and the route accumulation is on (i.e., H = 1, RPLInstanceID has a | |||
local value, A = 1), the Intermediate Point MUST process the received | local value, and A = 1), the Intermediate Point MUST process the | |||
Measurement Request in the following manner. | received Measurement Request in the following manner. | |||
If the Num field inside the received Measurement Request is set to | If the Num field inside the received Measurement Request is set to | |||
zero, thereby implying that an Address vector is not present, the | zero, thereby implying that an Address vector is not present, the | |||
Intermediate Point MUST discard the received message with no further | Intermediate Point MUST discard the received message with no further | |||
processing. | processing. | |||
The Intermediate Point MUST then determine the next hop on the route | The Intermediate Point MUST then determine the next hop on the route | |||
being measured using the RPLInstanceID, the End Point Address and the | being measured using the RPLInstanceID, the End Point Address, and | |||
Start Point Address (which represents the DODAGID of the route being | the Start Point Address (which represents the DODAGID of the route | |||
measured). If the Intermediate Point can not determine the next hop, | being measured). If the Intermediate Point cannot determine the next | |||
it MUST discard the Measurement Request with no further processing | hop, it MUST discard the Measurement Request with no further | |||
and MAY send an ICMPv6 Destination Unreachable (with Code 0 - No | processing and MAY send an ICMPv6 Destination Unreachable (with | |||
Route To Destination) error message [RFC4443] to the Start Point. If | Code 0 -- No Route To Destination) error message [RFC4443] to the | |||
the index field has value Num - 1 and the next hop is not same as the | Start Point. If the index field has value Num - 1 and the next hop | |||
End Point, the Intermediate Point MUST drop the received Measurement | is not the same as the End Point, the Intermediate Point MUST drop | |||
Request with no further processing. In this case, the next hop would | the received Measurement Request with no further processing. In this | |||
have no space left in the Address vector to store its address. | case, the next hop would have no space left in the Address vector to | |||
Otherwise, the router MUST store one of its IPv6 addresses at | store its address. Otherwise, the router MUST store one of its IPv6 | |||
location Address[Index] and then increment the Index field. The IPv6 | addresses at location Address[Index] and then increment the Index | |||
address added to the Address vector MUST have the following | field. The IPv6 address added to the Address vector MUST have the | |||
properties: | following properties: | |||
o This address MUST be a unicast global or unique local address. | o This address MUST be a unicast global or unique-local address. | |||
o This address MUST have the same prefix as the Start Point Address | o This address MUST have the same prefix as the Start Point Address | |||
and the End Point Address. This prefix, whose length in octets is | and the End Point Address. This prefix, whose length in octets is | |||
specified in the Compr field, MUST be elided before the address is | specified in the Compr field, MUST be elided before the address is | |||
added to the Address vector. | added to the Address vector. | |||
o This address MUST be reachable in the Reverse direction. | o This address MUST be reachable in the Reverse direction. | |||
If the router does not have an IPv6 address that satisfies the | If the router does not have an IPv6 address that satisfies the | |||
properties mentioned above, it MUST discard the Measurement Request | properties mentioned above, it MUST discard the Measurement Request | |||
with no further processing. | with no further processing. | |||
The Intermediate Point MUST then complete the processing of the | The Intermediate Point MUST then complete the processing of the | |||
received Measurement Request as specified in Section 5.5. | received Measurement Request as specified in Section 5.5. | |||
5.4. When Measuring A Source Route | 5.4. When Measuring a Source Route | |||
If a Source Route is being measured (i.e., H = 0), the Intermediate | If a Source Route is being measured (i.e., H = 0), the Intermediate | |||
Point MUST process the received Measurement Request in the following | Point MUST process the received Measurement Request in the following | |||
manner. | manner. | |||
If the Num field inside the received Measurement Request is set to | If the Num field inside the received Measurement Request is set to | |||
zero, thereby implying that an Address vector is not present, the | zero, thereby implying that an Address vector is not present, the | |||
Intermediate Point MUST discard the received message with no further | Intermediate Point MUST discard the received message with no further | |||
processing. | processing. | |||
The Intermediate Point MUST verify that the Address[Index] element | The Intermediate Point MUST verify that the Address[Index] element | |||
lists one of its unicast global or unique local IPv6 addresses (minus | lists one of its unicast global or unique-local IPv6 addresses (minus | |||
the prefix whose length in octets is specified in the Compr field), | the prefix whose length in octets is specified in the Compr field), | |||
failing which it MUST discard the Measurement Request with no further | failing which it MUST discard the Measurement Request with no further | |||
processing. The Intermediate Point MUST then increment the Index | processing. The Intermediate Point MUST then increment the Index | |||
field and use the Address[Index] element as the next hop (unless | field and use the Address[Index] element as the next hop (unless the | |||
Index value is now Num). If the Index value is now Num, the | Index value is now Num). If the Index value is now Num, the | |||
Intermediate Point MUST use the End Point Address as the next hop. | Intermediate Point MUST use the End Point Address as the next hop. | |||
The Intermediate Point MUST then complete the processing of the | The Intermediate Point MUST then complete the processing of the | |||
received Measurement Request as specified in Section 5.5. | received Measurement Request as specified in Section 5.5. | |||
5.5. Final Processing | 5.5. Final Processing | |||
The Intermediate Point MUST drop the received Measurement Request | The Intermediate Point MUST drop the received Measurement Request | |||
with no further processing: | with no further processing: | |||
o If the next hop address is not a unicast address; or | o if the next-hop address is not a unicast address; or | |||
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 | |||
Intermediate Point. | Intermediate Point. | |||
Next, the Intermediate Point MUST update the routing metric objects, | Next, the Intermediate Point MUST update the routing metric objects, | |||
inside the Metric Container option(s) inside the Measurement Request, | inside the Metric Container option(s) inside the Measurement Request, | |||
either by updating the aggregated value for the routing metric or by | either by updating the aggregated value for the routing metric or by | |||
attaching the local values for the metric inside the object. An | attaching the local values for the metric inside the object. An | |||
Intermediate Point can only update the existing metric objects and | Intermediate Point can only update the existing metric objects and | |||
MUST NOT add any new routing metric object to the Metric Container. | MUST NOT add any new routing metric objects to the Metric Container. | |||
An Intermediate Point MUST drop the Measurement Request with no | An Intermediate Point MUST drop the Measurement Request with no | |||
further processing if it cannot update a routing metric object | further processing if it cannot update a routing metric object | |||
specified inside the Metric Container. | specified inside the Metric Container. | |||
Finally, the Intermediate Point MUST unicast the Measurement Request | Finally, the Intermediate Point MUST unicast the Measurement Request | |||
to the next hop. | to the next hop. | |||
6. Processing a Measurement Request at the End Point | 6. Processing a Measurement Request at the End Point | |||
On receiving an MO, if a router chooses to process the message | On receiving an MO, if a router chooses to process the message | |||
further and finds one of its unicast global or unique local IPv6 | further and finds one of its unicast global or unique-local IPv6 | |||
addresses (minus the prefix whose length in octets is specified in | addresses (minus the prefix whose length in octets is specified in | |||
the Compr field) listed as the End Point Address, the router | the Compr field) listed as the End Point Address, the router | |||
considers itself the End Point and MUST process the received MO in | considers itself the End Point and MUST process the received MO in | |||
the following manner. | the following manner. | |||
The End Point MUST discard the received message with no further | The End Point MUST discard the received message with no further | |||
processing if it is not a Measurement Request (i.e., T = 0). | processing if it is not a Measurement Request (i.e., T = 0). | |||
If the received Measurement Request traveled on a Hop-by-hop Route | If the received Measurement Request traveled on a Hop-by-hop Route | |||
with a local RPLInstanceID with route accumulation on (i.e., H = 1, | with a local RPLInstanceID with route accumulation on (i.e., H = 1, | |||
RPLInstanceID has a local value and A = 1), elements Address[0] | RPLInstanceID has a local value, and A = 1), elements Address[0] | |||
through Address[Index - 1] in the Address vector contain a complete | through Address[Index - 1] in the Address vector contain a complete | |||
Source Route from the Start Point to the End Point, which the End | Source Route from the Start Point to the End Point, which the | |||
Point MAY use, after reversal, to reach the Start Point. Note that | End Point MAY use, after reversal, to reach the Start Point. Note | |||
the Source Route in the Address vector does not include the Start | that the Source Route in the Address vector does not include the | |||
Point and the End Point addresses and the individual addresses do not | Start Point and the End Point addresses, and that the individual | |||
include the common prefix whose length in octets is specified in the | addresses do not include the common prefix whose length in octets is | |||
Compr field. | specified in the Compr field. | |||
If the received Measurement Request traveled on a Source Route and | If the received Measurement Request traveled on a Source Route and | |||
the Reverse flag is set to one (i.e., H = 0, R = 1), elements | the Reverse flag is set to one (i.e., H = 0 and R = 1), elements | |||
Address[0] through Address[Num - 1] in the Address vector contain a | Address[0] through Address[Num - 1] in the Address vector contain a | |||
complete Source Route from the Start Point to the End Point, which | complete Source Route from the Start Point to the End Point, which | |||
the End Point MAY use, after reversal, to reach the Start Point. | the End Point MAY use, after reversal, to reach the Start Point. | |||
Again, the Source Route in the Address vector does not include the | Again, the Source Route in the Address vector does not include the | |||
Start Point and the End Point addresses and the individual addresses | Start Point and the End Point addresses, and the individual addresses | |||
do not include the common prefix whose length in octets is specified | do not include the common prefix whose length in octets is specified | |||
in the Compr field. | in the Compr field. | |||
The End Point MUST update the routing metric objects in the Metric | The End Point MUST update the routing metric objects in the Metric | |||
Container options if required and MAY note the measured values for | Container options if required and MAY note the measured values for | |||
the complete route (especially, if the received Measurement Request | the complete route (especially if the received Measurement Request is | |||
is likely a response to an earlier Measurement Request that the End | likely a response to an earlier Measurement Request that the | |||
Point had sent to the Start Point with B flag set to one). | End Point had sent to the Start Point with the B flag set to one). | |||
The End Point MUST generate a Measurement Reply message as specified | The End Point MUST generate a Measurement Reply message as specified | |||
in Section 6.1. If the B flag is set to one in the received | in Section 6.1. If the B flag is set to one in the received | |||
Measurement Request, the End Point SHOULD generate a new Measurement | Measurement Request, the End Point SHOULD generate a new Measurement | |||
Request to measure the cost of its current (or the most preferred) | Request to measure the cost of its current (or the most preferred) | |||
route to the Start Point. The routing metrics used in the new | route to the Start Point. The routing metrics used in the new | |||
Measurement Request MUST include the routing metrics specified in the | Measurement Request MUST include the routing metrics specified in the | |||
received Measurement Request. | received Measurement Request. | |||
6.1. Generating the Measurement Reply | 6.1. Generating the Measurement Reply | |||
A Measurement Reply MUST have the Type (T) flag set to zero and need | A Measurement Reply MUST have the Type (T) flag set to zero and need | |||
not contain the Address vector. The following fields inside a | not contain the Address vector. The following fields inside a | |||
Measurement Reply MUST have the same values as they had inside the | Measurement Reply MUST have the same values as they had inside the | |||
corresponding Measurement Request: RPLInstanceID, Compr, SeqNo, Start | corresponding Measurement Request: RPLInstanceID, Compr, SeqNo, | |||
Point Address, End Point Address and Metric Container Option(s). The | Start Point Address, End Point Address, and Metric Container | |||
remaining fields inside a Measurement Reply may have any value and | option(s). The remaining fields inside a Measurement Reply may have | |||
MUST be ignored on reception at the Start Point; the received | any value and MUST be ignored on reception at the Start Point; the | |||
Measurement Request can, therefore, trivially be converted into a | received Measurement Request can, therefore, trivially be converted | |||
Measurement Reply by setting the Type (T) flag to zero. | into a Measurement Reply by setting the Type (T) flag to zero. | |||
A Measurement Reply MUST be unicast back to the Start Point: | A Measurement Reply MUST be unicast back to the Start Point: | |||
o If the Measurement Request traveled along a global DAG, identified | o If the Measurement Request traveled along a global DAG, identified | |||
by the RPLInstanceID field, the Measurement Reply MAY be unicast | by the RPLInstanceID field, the Measurement Reply MAY be unicast | |||
back to the Start Point along the same DAG. | back to the Start Point along the same DAG. | |||
o If the Measurement Request traveled along a Hop-by-hop Route with | o If the Measurement Request traveled along a Hop-by-hop Route with | |||
a local RPLInstanceID and accumulated a Source Route from the | a local RPLInstanceID and accumulated a Source Route from the | |||
Start Point to the End Point, this Source Route MAY be used after | Start Point to the End Point, this Source Route MAY be used after | |||
reversal to send the Measurement Reply back to the Start Point. | reversal to send the Measurement Reply back to the Start Point. | |||
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 | |||
flag inside the received message is set to one, the End Point MAY | R flag inside the received message is set to one, the End Point | |||
reverse the Source Route contained in the Address vector and use | MAY reverse the Source Route contained in the Address vector and | |||
it to send the Measurement Reply back to the Start Point. | use it to send the Measurement Reply back to the Start Point. | |||
7. Processing a Measurement Reply at the Start Point | 7. Processing a Measurement Reply at the Start Point | |||
When a router receives an MO, it examines if one of its unicast IPv6 | When a router receives an MO, it examines the MO to see if one of its | |||
addresses is listed as the Start Point Address. If yes, the router | unicast IPv6 addresses is listed as the Start Point Address. If yes, | |||
is the Start Point and MUST process the received message in the | the router is the Start Point and MUST process the received message | |||
following manner. | in the following manner. | |||
If the Start Point discovers that the received MO is not a | If the Start Point discovers that the received MO is not a | |||
Measurement Reply or if it no longer maintains state for the | Measurement Reply, or if it no longer maintains state for the | |||
corresponding Measurement Request, it MUST discard the received | corresponding Measurement Request, it MUST discard the received | |||
message with no further processing. | message with no further processing. | |||
The Start Point can use the routing metric objects inside the Metric | The Start Point can use the routing metric objects inside the Metric | |||
Container to evaluate the metrics for the measured P2P route. If a | Container to evaluate the metrics for the measured P2P route. If a | |||
routing metric object contains local metric values recorded by | routing metric object contains local metric values recorded by | |||
routers on the route, the Start Point can make use of these local | routers on the route, the Start Point can make use of these local | |||
values by aggregating them into an end-to-end metric according to the | values by aggregating them into an end-to-end metric, according to | |||
aggregation rules for the specific metric. A Start Point is then | the aggregation rules for the specific metric. A Start Point is then | |||
free to interpret the metrics for the route according to its local | free to interpret the metrics for the route, according to its local | |||
policy. | policy. | |||
8. Security Considerations | 8. Security Considerations | |||
In general, the security considerations for the route measurement | In general, the security considerations for the route measurement | |||
mechanism described in this document are similar to the ones for RPL | mechanism described in this document are similar to those for RPL (as | |||
(as described in Section 19 of [RFC6550]). Sections 6.1 and 10 of | described in Section 19 of the RPL specification [RFC6550]). | |||
RPL specification [RFC6550] describe RPL's security framework that | Sections 6.1 and 10 of [RFC6550] describe RPL's security framework, | |||
provides data confidentiality, authentication, replay protection and | which provides data confidentiality, authentication, replay | |||
delay protection services. This security framework is applicable to | protection, and delay protection services. This security framework | |||
the route measurement mechanism described here as well after taking | is applicable to the route measurement mechanism described here as | |||
in account the constraints specified in Section 3.2. | well, after taking into account the constraints specified in | |||
Section 3.2. | ||||
This document requires all routers participating in a secure | This document requires that all routers participating in a secure | |||
invocation of the route measurement process to use the Security | invocation of the route measurement process use the Security | |||
Configuration decided by the Start Point. The intention is to avoid | Configuration chosen by the Start Point. The intention is to avoid | |||
compromising the overall security of the route measurement due to | compromising the overall security of the route measurement due to | |||
some routers using a weaker Security Configuration. A router is | some routers using a weaker Security Configuration. A router is | |||
allowed to participate in a "secure" route measurement only if it can | allowed to participate in a "secure" route measurement only if it can | |||
support the Security Configuration in use, which also specifies the | support the Security Configuration in use, which also specifies the | |||
key in use. It does not matter whether the key is pre-installed or | key in use. It does not matter whether the key is preinstalled or | |||
dynamically acquired after proper authentication. The router must | dynamically acquired after proper authentication. The router must | |||
have the key in use before it can process or generate Secure MO | have the key in use before it can process or generate Secure MO | |||
messages. Hence, from the perspective of the route measurement | messages. Hence, from the perspective of the route measurement | |||
mechanism, there is no distinction between the "preinstalled" and | mechanism, there is no distinction between the "preinstalled" and | |||
"authenticated" security modes described in RPL specification | "authenticated" security modes described in the RPL specification | |||
[RFC6550]. Ofcourse if a compromised router has the key being used, | [RFC6550]. Of course, if a compromised router has the key being | |||
it could cause the route measurement to fail, or worse, insert wrong | used, it could cause the route measurement to fail, or worse, insert | |||
information in Secure MO messages. | wrong information in Secure MO messages. | |||
A rogue router acting as the Start Point could use the route | A rogue router acting as the Start Point could use the route | |||
measurement mechanism defined in this document to measure routes from | measurement mechanism defined in this document to measure routes from | |||
itself to other routers and thus find out key information about the | itself to other routers and thus find out key information about the | |||
LLN, e.g., the topological features of the LLN (such as the identity | LLN, e.g., the topological features of the LLN (such as the identity | |||
of the key routers in the topology) or the remaining energy levels | of the key routers in the topology) or the remaining energy levels | |||
[RFC6551] in the routers. This information can potentially be used | [RFC6551] in the routers. This information can potentially be used | |||
to attack the LLN. A rogue router could also use this mechanism to | to attack the LLN. A rogue router could also use this mechanism to | |||
send bogus Measurement Requests to arbitrary End Points. If | send bogus Measurement Requests to arbitrary End Points. If | |||
sufficient Measurement Requests are sent, then it may cause CPU | sufficient Measurement Requests are sent, then it 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. | |||
To protect against such misuse, this document allows RPL routers | To protect against such misuse, this document allows RPL routers | |||
implementing this mechanism to not process MO messages (or process | implementing this mechanism to not process MO messages (or process | |||
such messages selectively) based on a local policy. For example, an | such messages selectively), based on a local policy. For example, an | |||
LLN deployment might require the use of Secure MO messages generated | LLN deployment might require the use of Secure MO messages generated | |||
using a key that could be obtained only after proper authentication. | using a key that could be obtained only after proper authentication. | |||
Note that this document requires an LLN deployment to support Secure | Note that this document requires that an LLN deployment support | |||
MO messages so that such policies can be enforced where considered | Secure MO messages so that such policies can be enforced where | |||
essential. | considered essential. | |||
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 headers [RFC5095] may be valid here. | |||
address such concerns, the mechanism described in this document | To address such concerns, the mechanism described in this document | |||
includes several remedies: | includes several remedies, in the form of the following requirements: | |||
o This document requires that a route inserted inside the Address | o A route inserted inside the Address vector must be a strict Source | |||
vector must be a strict Source Route and must not include any | Route and must not include any multicast addresses. | |||
multicast addresses. | ||||
o This document requires that an MO message must not cross the | o An MO message must not cross the boundaries of the RPL routing | |||
boundaries of the RPL routing domain where it originated. A | domain where it originated. A router must not forward a received | |||
router must not forward a received MO message further if the next | MO message further if the next hop belongs to a different RPL | |||
hop belongs to a different RPL routing domain. Hence, any | routing domain. Hence, any security problems associated with the | |||
security problems associated with the mechanism would be limited | mechanism would be limited to one RPL routing domain. | |||
to one RPL routing domain. | ||||
o This document requires that a router must drop a received | o A router must drop a received Measurement Request if the next-hop | |||
Measurement Request if the next hop address is not on-link or if | address is not on-link or if it is not a unicast address. | |||
it is not a unicast address. | ||||
9. IANA Considerations | 9. IANA Considerations | |||
This document defines two new RPL messages: | This document defines two new RPL messages: | |||
o "Measurement Object" (see Section 3.1), assigned a value TBD1 from | o "Measurement Object" (see Section 3.1), assigned a value of 0x06 | |||
the "RPL Control Codes" space [to be removed upon publication: | from the "RPL Control Codes" space [RFC6550]. | |||
http://www.iana.org/assignments/rpl/rpl.xml#control-codes] | ||||
[RFC6550]. IANA is requested to allocate TBD1 from the range | ||||
0x00-0x7F to indicate a message without security enabled. The | ||||
string TBD1 in this document should be replaced by the allocated | ||||
value. These last two sentences should be removed before | ||||
publication. | ||||
o "Secure Measurement Object" (see Section 3.2), assigned a value | o "Secure Measurement Object" (see Section 3.2), assigned a value of | |||
TBD2 from the "RPL Control Codes" space [to be removed upon | 0x86 from the "RPL Control Codes" space [RFC6550]. | |||
publication: | ||||
http://www.iana.org/assignments/rpl/rpl.xml#control-codes] | ||||
[RFC6550]. IANA is requested to allocate TBD2 from the range | ||||
0x80-0xFF to indicate a message with security enabled. The string | ||||
TBD2 in this document should be replaced by the allocated value. | ||||
These last two sentences should be removed before publication. | ||||
+------+---------------------------+---------------+ | +------+---------------------------+---------------+ | |||
| Code | Description | Reference | | | Code | Description | Reference | | |||
+------+---------------------------+---------------+ | +------+---------------------------+---------------+ | |||
| TBD1 | Measurement Object | This document | | | 0x06 | Measurement Object | This document | | |||
| TBD2 | Secure Measurement Object | This document | | | 0x86 | Secure Measurement Object | This document | | |||
+------+---------------------------+---------------+ | +------+---------------------------+---------------+ | |||
RPL Control Codes | RPL Control Codes | |||
10. Acknowledgements | 10. Acknowledgements | |||
Authors gratefully acknowledge the contributions of Ralph Droms, | The authors gratefully acknowledge the contributions of Ralph Droms, | |||
Adrian Farrel, Joel Halpern, Matthias Philipp, Pascal Thubert, | Adrian Farrel, Joel Halpern, Matthias Philipp, Pascal Thubert, | |||
Richard Kelsey and Zach Shelby in the development of this document. | Richard Kelsey, and Zach Shelby in the development of this document. | |||
11. References | 11. References | |||
11.1. Normative References | 11.1. Normative References | |||
[I-D.ietf-roll-p2p-rpl] | ||||
Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. | ||||
Martocci, "Reactive Discovery of Point-to-Point Routes in | ||||
Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-17 | ||||
(work in progress), March 2013. | ||||
[I-D.ietf-roll-terminology] | ||||
Vasseur, J., "Terminology in Low power And Lossy | ||||
Networks", draft-ietf-roll-terminology-12 (work in | ||||
progress), March 2013. | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control | [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control | |||
Message Protocol (ICMPv6) for the Internet Protocol | Message Protocol (ICMPv6) for the Internet Protocol | |||
Version 6 (IPv6) Specification", RFC 4443, March 2006. | Version 6 (IPv6) Specification", RFC 4443, March 2006. | |||
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., | [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., | |||
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. | Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. | |||
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and | Alexander, "RPL: IPv6 Routing Protocol for Low-Power and | |||
Lossy Networks", RFC 6550, March 2012. | Lossy Networks", RFC 6550, March 2012. | |||
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 | ||||
Routing Header for Source Routes with the Routing Protocol | ||||
for Low-Power and Lossy Networks (RPL)", RFC 6554, | ||||
March 2012. | ||||
[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and | ||||
J. Martocci, "Reactive Discovery of Point-to-Point Routes | ||||
in Low-Power and Lossy Networks", RFC 6997, August 2013. | ||||
11.2. Informative References | 11.2. Informative References | |||
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation | [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation | |||
of Type 0 Routing Headers in IPv6", RFC 5095, | of Type 0 Routing Headers in IPv6", RFC 5095, | |||
December 2007. | December 2007. | |||
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation | [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation | |||
Routing Requirements in Low-Power and Lossy Networks", | Routing Requirements in Low-Power and Lossy Networks", | |||
RFC 5826, April 2010. | RFC 5826, April 2010. | |||
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, | [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, | |||
"Building Automation Routing Requirements in Low-Power and | "Building Automation Routing Requirements in Low-Power and | |||
Lossy Networks", RFC 5867, June 2010. | Lossy Networks", RFC 5867, June 2010. | |||
[RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. | [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. | |||
Barthel, "Routing Metrics Used for Path Calculation in | Barthel, "Routing Metrics Used for Path Calculation in | |||
Low-Power and Lossy Networks", RFC 6551, March 2012. | Low-Power and Lossy Networks", RFC 6551, March 2012. | |||
[ROLL-TERMS] | ||||
Vasseur, JP., "Terminology in Low power And Lossy | ||||
Networks", Work in Progress, March 2013. | ||||
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 53201 | |||
USA | USA | |||
Phone: +1 414 2295001 | Phone: +1-414-229-5001 | |||
Email: mukul@uwm.edu | EMail: mukul@uwm.edu | |||
Emmanuel Baccelli | 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 | |||
Jerald Martocci | Jerald Martocci | |||
Johnson Controls | Johnson Controls | |||
507 E Michigan Street | 507 E. Michigan Street | |||
Milwaukee 53202 | Milwaukee, WI 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. 176 change blocks. | ||||
593 lines changed or deleted | 584 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/ |