draft-ietf-roll-p2p-measurement-00.txt   draft-ietf-roll-p2p-measurement-01.txt 
Internet Engineering Task Force M. Goyal, Ed. Internet Engineering Task Force M. Goyal, Ed.
Internet-Draft University of Wisconsin Internet-Draft University of Wisconsin
Intended status: Standards Track Milwaukee Intended status: Standards Track Milwaukee
Expires: October 13, 2011 E. Baccelli, Ed. Expires: January 12, 2012 E. Baccelli, Ed.
INRIA INRIA
A. Brandt A. Brandt
Sigma Designs Sigma Designs
R. Cragie R. Cragie
Gridmerge Ltd Gridmerge Ltd
J. Martocci J. Martocci
Johnson Controls Johnson Controls
C. Perkins July 11, 2011
Tellabs Inc
April 11, 2011
A Mechanism to Measure the Quality of a Point-to-point Route in a Low A Mechanism to Measure the Quality of a Point-to-point Route in a Low
Power and Lossy Network Power and Lossy Network
draft-ietf-roll-p2p-measurement-00 draft-ietf-roll-p2p-measurement-01
Abstract Abstract
This document specifies a mechanism that enables an RPL node to This document specifies a mechanism that enables an RPL router to
measure the quality of an existing route to/from another RPL node in measure the quality of an existing route to another RPL router in a
a low power and lossy network, thereby allowing the node to decide if low power and lossy network, thereby allowing the router to decide if
it wants to initiate the discovery of a more optimal route. it wants to initiate the discovery of a more optimal route.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 13, 2011. This Internet-Draft will expire on January 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Functional Overview . . . . . . . . . . . . . . . . . . . . . 4 2. Functional Overview . . . . . . . . . . . . . . . . . . . . . 4
3. The Measurement Object (MO) . . . . . . . . . . . . . . . . . 5 3. The Measurement Object (MO) . . . . . . . . . . . . . . . . . 5
4. Originating an MO To Measure a P2P Route . . . . . . . . . . . 6 4. Originating a Measurement Request . . . . . . . . . . . . . . 8
4.1. From the Origin Node to the Target Node . . . . . . . . . 7 5. Processing a Measurement Request at an Intermediate Router . . 9
4.2. From the Target Node to the Origin Node . . . . . . . . . 8 6. Processing a Measurement Request at the Target . . . . . . . . 10
5. Processing a Received MO at an Intermediate Router . . . . . . 8 7. Processing a Measurement Reply at the Origin . . . . . . . . . 11
6. Processing a Received MO at the Target Node . . . . . . . . . 9
7. Processing a Received MO at the Origin Node . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 10. Authors and Contributors . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Point to point (P2P) communication between arbitrary nodes in a Low Point to point (P2P) communication between arbitrary routers in a Low
power and Lossy Network (LLN) is a key requirement for many power and Lossy Network (LLN) is a key requirement for many
applications [RFC5826][RFC5867]. RPL [I-D.ietf-roll-rpl], the IPv6 applications [RFC5826][RFC5867]. RPL [I-D.ietf-roll-rpl], the IPv6
Routing Protocol for LLNs, constrains the LLN topology to a Directed Routing Protocol for LLNs, constrains the LLN topology to a Directed
Acyclic Graph (DAG) built to optimize routing costs to reach the Acyclic Graph (DAG) built to optimize routing costs to reach the
DAG's root and requires the P2P routes to use the DAG links only. DAG's root and requires the P2P routes to use the DAG links only.
Such P2P routes may potentially be suboptimal and may lead to traffic Such P2P routes may potentially be suboptimal and may lead to traffic
congestion near the DAG root. Additionally, RPL is a proactive congestion near the DAG root. Additionally, RPL is a proactive
routing protocol and hence all P2P routes must be established ahead routing protocol and hence all P2P routes must be established ahead
of the time they are used. of the time they are used.
To ameliorate situations, where RPL's P2P routing functionality does To ameliorate situations, where RPL's P2P routing functionality does
not meet the requirements, [I-D.ietf-roll-p2p-rpl] describes a not meet the requirements, [I-D.ietf-roll-p2p-rpl] describes a
reactive mechanism to discover P2P routes that meet the specified reactive mechanism to discover P2P routes that meet the specified
performance characteristics. This mechanism, henceforth referred to performance criteria. This mechanism, henceforth referred to as the
as the reactive P2P route discovery, requires the specification of reactive P2P route discovery, requires the specification of routing
"good enough criteria", in terms of constraints on aggregated values constraints [I-D.ietf-roll-routing-metrics], that the discovered
of the relevant routing metrics [I-D.ietf-roll-routing-metrics], that routes must satisfy. In some cases, the application requirements or
the discovered routes must satisfy. In some cases, the application the LLN's topological features allow a router to infer the routing
requirements or the LLN's topological features allow a node to infer constraints intrinsically. For example, the application may require
the good enough criteria intrinsically. For example, the application the end-to-end loss rate and/or latency on the route to be below
may require the end-to-end loss rate and/or latency on the route to certain thresholds or the LLN topology may be such that a router can
be below certain thresholds or the LLN topology may be such that a safely assume its destination to be less than a certain number of
router can safely assume its destination to be less than a certain hops away from itself.
number of hops away from itself.
When the existing P2P routes are deemed unsatisfactory by the When the existing routes are deemed unsatisfactory but the router
application layer but the node does not intrinsically know the good does not intrinsically know the routing constraints to be used in P2P
enough criteria, it may be necessary for the node to determine the route discovery, it may be necessary for the router to determine the
aggregated values of relevant routing metrics along the existing aggregated values of the routing metrics along the existing route.
routes. This knowledge will allow the node to frame a reasonable This knowledge will allow the router to frame reasonable routing
good enough criteria and initiate a reactive P2P route discovery to constraints for use in P2P route discovery to determine a better
determine better routes. For example, if the router determines the route. For example, if the router determines the aggregate ETX
aggregate ETX [I-D.ietf-roll-routing-metrics] along an existing route [I-D.ietf-roll-routing-metrics] along an existing route to be "x", it
to be "x", it can use "ETX < x*y", where y is a certain fraction, as can use "ETX < x*y", where y is a certain fraction, as the routing
a constraint in the good enough criteria. Note that it is important constraint for use in P2P route discovery. Note that it is important
that the good enough criteria is not overly strict; otherwise the that the routing constraints are not overly strict; otherwise the P2P
route discovery may fail even though routes, much better than the route discovery may fail even though a route, much better than the
ones being currently used, exist. one currently being used, exists.
This document specifies a mechanism that enables an RPL node to This document specifies a mechanism that enables an RPL router to
measure the aggregated values of the routing metrics along an measure the aggregated values of the routing metrics along an
existing route to/from another RPL node in an LLN, thereby allowing existing route to another RPL router in an LLN, thereby allowing the
the node to decide if it wants to initiate the reactive discovery of router to decide if it wants to initiate the reactive discovery of a
a more optimal route and determine the good enough criteria to be more optimal route and determine the routing constraints to be used
used for this purpose. for this purpose.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
Additionally, this document uses terminology from Additionally, this document uses terminology from
[I-D.ietf-roll-terminology], [I-D.ietf-roll-rpl] and [I-D.ietf-roll-terminology], [I-D.ietf-roll-rpl] and
[I-D.ietf-roll-p2p-rpl]. Specifically, the term node refers to an [I-D.ietf-roll-p2p-rpl]. The following terms, originally defined in
RPL router or an RPL host as defined in [I-D.ietf-roll-rpl]. The [I-D.ietf-roll-p2p-rpl], are redefined in the following manner.
following terms, originally defined in [I-D.ietf-roll-p2p-rpl], are
redefined in the following manner.
Origin Node: The origin node refers to the node that initiates the Origin: The origin refers to the router that initiates the
measurement process defined in this document and is one end point of measurement process defined in this document and is the start point
the P2P route being measured. of the P2P route being measured.
Target Node: The target node refers to the other end of the P2P route Target: The target refers to the router at the end point of the P2P
being measured. route being measured.
Intermediate Router: A router, other than the origin and the target Intermediate Router: A router, other than the origin and the target,
node, on the P2P route being measured. on the P2P route being measured.
2. Functional Overview 2. Functional Overview
The mechanism described in this document can be used by an origin The mechanism described in this document can be used by an origin to
node to measure the aggregated values of the routing metrics along a measure the aggregated values of the routing metrics along a P2P
P2P route to/from a target node in the LLN. Such a route could be a route to a target in the LLN. Such a route could be a source route
source route or a hop-by-hop route established using RPL or a hop-by-hop route established using RPL [I-D.ietf-roll-rpl] or
[I-D.ietf-roll-rpl] or the reactive P2P route discovery the reactive P2P route discovery [I-D.ietf-roll-p2p-rpl]. The origin
[I-D.ietf-roll-p2p-rpl]. sends a Measurement Request message along the route. The Measurement
Request accumulates the values of the routing metrics as it travels
When an origin node desires to measure the aggregated values of the towards the target. Upon receiving the Measurement Request, the
routing metrics along a P2P route from itself to a target node, it target unicasts a Measurement Reply message, carrying the accumulated
sends a Measurement Request message along that route. The values of the routing metrics, back to the origin.
Measurement Request message accumulates the values of the relevant
routing metrics as it travels towards the target node. Upon
receiving the Measurement Request message, the target node unicasts a
Measurement Reply message, carrying the accumulated values of the
routing metrics, back to the origin node.
When an origin node desires to measure the aggregated values of the
routing metrics along a P2P route from a target node to itself, it
unicasts a Measurement Request message, specifying the routing
metrics to be measured, to the target node. On receiving the
Measurement Request message, the target node sends a Measurement
Reply message to the origin node along the P2P route to be measured.
The Measurement Reply message accumulates the values of the relevant
routing metrics as it travels towards the origin node.
3. The Measurement Object (MO) 3. The Measurement Object (MO)
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID | SequenceNo |T|H|I|D| Resvd | | RPLInstanceID | SequenceNo | Compr |T|H|A|R| Num | Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Origin Address | | Origin Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Target Address | | Target Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Source Route Option(*) . . Address[1..Num] .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Metric Container Options . . Metric Container Option(s) .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of the Measurement Object (MO) Figure 1: Format of the Measurement Object (MO)
This document defines a new RPL Control Message type, the Measurement This document defines a new RPL Control Message type, the Measurement
Object (MO) with code 0x05 (to be confirmed by IANA) that serves as Object (MO), with code 0x06 (to be confirmed by IANA) that serves as
both Measurement Request and Measurement Reply. The format of an MO both Measurement Request and Measurement Reply. The format of an MO
is shown in Figure 1. An MO consists of the following fields: is shown in Figure 1. An MO consists of the following fields:
o RPLInstanceID: Relevant only if the MO travels along a hop-by-hop o RPLInstanceID: Relevant only if the MO travels along a hop-by-hop
route. This field identifies the RPLInstanceID of the hop-by-hop route. This field identifies the RPLInstanceID of the hop-by-hop
route. route being measured. If the route being measured is a source
route, this field MUST be set to 10000000 on transmission and
ignored on reception.
o SequenceNo: A 16-bit sequence number that uniquely identifies a o SequenceNo: An 8-bit sequence number that uniquely identifies a
Measurement Request and the corresponding Measurement Reply to the Measurement Request and the corresponding Measurement Reply.
origin node.
o T: The type flag. This flag is set if the MO represents a o Compr: A 4-bit unsigned integer indicating the number of prefix
Measurement Request. The flag is cleared if the MO is a octets that are elided from the IPv6 addresses in Origin/Target
Measurement Reply. Address fields and the Address vector. For example, Compr value
will be 0 if full IPv6 addresses are carried in the Origin/Target
Address fields and the Address vector.
o H: This flag is set if the MO travels along a hop-by-hop route. o Type (T): This flag is set if the MO represents a Measurement
In that case, the hop-by-hop route is identified by the Request. The flag is cleared if the MO is a Measurement Reply.
RPLInstanceID and, if required, the Origin/Target Address serving
as the DODAGID. This flag is cleared if the MO travels along a o Hop-by-hop (H): This flag is set if the MO travels along a hop-by-
source route. In that case, the MO MUST contain a Source Route hop route. In that case, the hop-by-hop route is identified by
option [I-D.ietf-roll-p2p-rpl]. Note that, in case of a P2P route the RPLInstanceID and, if the RPLInstanceID is a local value, the
along a non-storing DAG, it is possible that an MO message travels Origin Address serving as the DODAGID. This flag is cleared if
along a hop-by-hop route till the DAG's root, which then sends it the MO travels along a source route specified in the Address
vector. Note that, in case the P2P route being measured lies
along a non-storing DAG, an MO message may travel along a hop-by-
hop route till it reaches the DAG's root, which then sends it
along a source route to its destination. In that case, the DAG along a source route to its destination. In that case, the DAG
root will reset the H flag and also insert a Source Route option root will reset the H flag and also insert the source route to the
in the MO. destination inside the Address vector.
o I: A flag that indicates which of the two - the Origin Address and o Accumulate Route (A): This flag is relevant only if the MO
the Target Address - indicates the DODAGID for the hop-by-hop represents a Measurement Request that travels along a hop-by-hop
route. This flag is relevant only if the MO travels along a hop- route represented by a local RPLInstanceID. When this flag is
by-hop route (i.e., H flag is set) and a local RPLInstanceID has relevant, a value 1 in the flag indicates that the Measurement
been specified to identify the hop-by-hop route. This flag is set Request MUST accumulate a source route for use by the target to
if the Origin Address indicates the DODAGID; the flag is cleared send the Measurement Reply back to the origin. In this case, the
if the Target Address indicates the DODAGID. intermediate routers MUST add their IPv6 addresses (after eliding
Compr number of prefix octets) to the Address vector in the manner
specified later.
o D: A flag that indicates the direction of the P2P route. This o Reverse (R): This flag is relevant only if the MO represents a
flag is set when the route to be measured is from the origin node Measurement Request that travels along a source route, specified
to the target node. Otherwise, the flag is cleared. in the Address vector, to the target. When this flag is relevant,
a value 1 in the flag indicates that the Address vector contains a
complete source route from the origin to the target, which can be
used, after reversal, by the target to source route the
Measurement Reply message back to the origin.
o Reserved: These bits are reserved for future use. These bits MUST o Num: This field indicates the number of fields in the Address
be set to zero on transmission and MUST be ignored on reception. vector. If the value of this field is zero, the Address vector is
not present in the MO.
o Origin Address: The IPv6 address of the origin node. o Index: If the Measurement Request is traveling along a source
route contained in the Address vector, this field 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 with a
local RPLInstanceID and the A flag is set, this field indicates
the index in the Address vector where an intermediate router
receiving the MO message must store its IPv6 address. Otherwise,
this field MUST be set to zero on transmission and ignored on
reception.
o Target Address: The IPv6 address of the target node. o Origin Address: An IPv6 address of the origin after eliding Compr
number of prefix octets. If the MO is traveling along a hop-by-
hop route and the RPLInstanceID field indicates a local value, the
Origin Address field MUST contain the DODAGID value that, along
with the RPLInstanceID, uniquely identifies the hop-by-hop route
being measured.
o Source Route Option: An MO MUST contain one Source Route option if o Target Address: An IPv6 address of the target after eliding Compr
it travels along a source route. number of prefix octets.
o Metric Container Options: An MO MUST contain one or more Metric o Address[1..Num]: A vector of IPv6 addresses (with Compr number of
Container options to carry the routing metric objects prefix octets elided) representing a (partial) route from the
[I-D.ietf-roll-routing-metrics]. origin to the target:
4. Originating an MO To Measure a P2P Route * Each element in the vector has size (16 - Compr) octets.
4.1. From the Origin Node to the Target Node
If the origin node intends to measure the routing metric values along * The total number of elements inside the Address vector is given
a P2P route towards a target node, it generates an MO message and by the Num field.
sets its fields as follows:
o RPLInstanceID: If the P2P route is a hop-by-hop route, the origin * When the Measurement Request is traveling along a hop-by-hop
node specifies the RPLInstanceID to identify the route in this route with local RPLInstanceID and has the A flag set, the
field. This field is not relevant if the P2P route is a source Address vector is used to accumulate a route to be used by the
route specified in the Source Route option. This document target to send the Measurement Reply back to the origin. In
RECOMMENDS a value 10000000 for this field if the P2P route is a this case, the route MUST be accumulated in the forward
source route. direction, i.e., from the origin to the target. The target
router would reverse this route to obtain a source route from
itself to the origin. The IPv6 addresses in the accumulated
route MUST be accessible in the backward direction. An
intermediate router adding its address to the Address vector
MUST ensure that its address does not already exist in the
vector.
o SequenceNo: The origin node assigns a sequence number to the MO to * When the Measurement Request is traveling along a source route,
uniquely identify the corresponding Measurement Reply. the Address vector MUST contain a complete route to the target
and the IPv6 addresses in the Address vector MUST be accessible
in the forward direction, i.e., from the origin to the target.
A router (the origin or an intermediate router) specifying a
route to the target in the Address vector MUST ensure that the
vector does not contain any address more than once. The origin
may set the R flag in the MO if the route in the Address vector
represents a complete route from the origin to the target and
this route can be used after reversal by the target to send the
Measurement Reply message back to the origin.
o T: The T flag is set to indicate that MO represents a Measurement * The origin and target addresses MUST NOT be included in the
Request. Address vector.
o H: The H flag is set if the MO travels along a hop-by-hop route. * The Address vector MUST NOT contain any multicast addresses.
o I: This field in relevant only if the H flag is set and the o Metric Container Options: An MO MUST contain one or more Metric
RPLInstanceID is a local value. The origin node sets this flag if Container options to accumulate routing metric values for the
the Origin Address indicates the DODAGID. The origin node clears route being measured.
this flag if the Target Address indicates the DODAGID.
o D: This flag is set. 4. Originating a Measurement Request
o Origin Address, Target Address: These fields are set to the IPv6 If an origin needs to measure the routing metric values along a P2P
addresses of the origin and target nodes respectively. If the H route towards a target, it generates an MO message and sets its
flag is set and the RPLInstanceID is a local value, the Origin fields in the manner described above. Specifically, the origin MUST
Address or the Target Address MUST also indicate the DODAGID value set the T flag to 1 to indicate that the MO represents a Measurement
required to identify the hop-by-hop route. Request.
o Source Route Option: If the P2P route is a source route (i.e., the If a source route is being measured, the origin MUST do the
H flag is cleared), the Source Route option MUST be present and following:
MUST include a complete source route to the target node in forward
direction (excluding the addresses of the origin and target
nodes).
o Metric Container Options: The origin node MUST also include one or o specify the complete source route to the target inside the Address
more Metric Container options containing relevant routing metric vector;
objects to accumulate the costs for these metrics along the P2P
route. The origin node also initiates the routing metric objects
by including the local values of the routing metrics for the first
hop on the P2P route.
After setting the MO fields as described above, the origin node MUST o specify in the Num field the number of address elements in the
unicast the MO message to the next hop on the P2P route. The origin Address vector;
node MAY include a Record Route IPv6 Extension Header, proposed in
[I-D.thubert-6man-reverse-routing-header], in the MO message to
accumulate a reverse route that the target node can use to send the
Measurement Reply back to the origin node.
4.2. From the Target Node to the Origin Node o set the Index field to value zero;
If the origin node intends to measure the routing metric values along o set the R flag if the route in the Address vector can be used
a P2P route from a target node to itself, it generates an MO message after reversal by the target to source route the Measurement Reply
and sets its fields as follows: message back to the origin.
o SequenceNo: The origin node assigns a sequence number to the MO to If a hop-by-hop route with a local RPLInstanceID is being measured
uniquely identify the corresponding Measurement Reply. and the origin desires the MO to accumulate a source route for the
target to send the Measurement Reply message back, it MUST do the
following:
o T: The T flag is set to indicate that MO represents a Measurement o set A flag to 1;
Request.
o D: This flag is cleared. o include a suitably sized, empty Address vector (with all bits set
to zero) in the MO;
o Origin Address, Target Address: These fields are set to the IPv6 o specify in the Num field the number of address elements that can
addresses of the origin and target nodes respectively. fit inside the Address vector;
o Source Route Option: In this case, the MO SHOULD NOT include any o set the Index field to value zero.
Source Route option.
o Metric Container Options: The origin node MUST include one or more The origin MUST include one or more Metric Container options inside
Metric Container options containing relevant routing metric the MO that carry the routing metric objects of interest. If
objects to accumulate the costs for these metrics along the P2P required, the origin must also initiate these routing metric objects
route. These routing metric objects MUST be empty. by including the values of the routing metrics for the first hop on
the P2P route being measured.
The other fields in the MO are not relevant in this case and SHOULD After setting the MO fields as described above, the origin MUST
be set to zero. After setting the MO fields as described above, the unicast the MO message to the next hop on the P2P route.
origin node MUST unicast the MO message to the target node.
5. Processing a Received MO at an Intermediate Router 5. Processing a Measurement Request at an Intermediate Router
When a node receives an MO, it examines if one of its IPv6 addresses When a router receives an MO, it examines if one of its IPv6
is listed as the Origin Address or the Target Address. If not, the addresses is listed as the Origin or the Target Address. If not, the
node checks if H bit is clear (i.e., the MO is traveling along a router processes the received message in the following manner.
source route). If yes, the node checks the Address[0] field inside
the Source Route Option contained in the MO. The node MUST drop the
MO with no further processing and send an ICMPv6 Destination
Unreachable error message to the source of the message (the Origin
Address if the MO is a Measurement Request; otherwise the Target
Address) if the received MO has a clear H bit but does not contain a
Source Route Option or if the Address[0] inside the Source Route
option does not match one of the node's IPv6 address.
The node then determines the next hop on the P2P route being An intermediate router MUST discard the packet with no further
measured. In case the received MO has a clear H flag, the Address[1] processing if the received MO is not a Measurement Request.
field (the second element in the Address vector) inside the Source
Route Option is taken as the next hop. If the Source Route Option
does not contain Address[1] element, the node checks the T flag
inside the MO. If T flag is set, i.e., MO is a Measurement Request,
the Target Address is taken as the next hop; otherwise the Origin
Address is the next hop. If the received MO has H flag set, the node
uses the RPLInstanceID, the ultimate destination of the MO (Target
Address if T flag is set; otherwise the Origin Address) and, if
RPLInstanceID is a local value, the DODAGID (the Origin Address if I
flag is set; otherwise the Target Address) to determine the next hop
for the MO. If the H flag in the MO is set and the node is the root
of a non-storing DAG, indicated by the RPLInstanceID, the node MAY
reset the H flag and insert a Source Route option in the MO to
indicate a source route along which the MO should travel on rest of
its way to its destination. The node MUST drop the MO with no
further processing and send an ICMPv6 Destination Unreachable error
message to the source of the message if it can not determine the next
hop for the message.
After determining the next hop, the node updates the routing metric The router then determines the next hop on the P2P route being
objects, contained in the Metric Container options inside the MO, measured. In case the received MO has a clear H flag, the router
either by updating the aggregated value for the routing metric or by increments the Index field and uses the Address[Index] element as the
attaching the local values for the metric inside the object. The next hop. If this element does not exist, the router uses the Target
node MUST drop the MO with no further processing and send a suitable Address as the next hop.
ICMPv6 error message to the source of the message if the node does
not know the relevant routing metric values for the next hop.
After updating the routing metrics, the node MUST unicast the MO to If the received MO has H flag set to 1, the router uses the
the next hop. If the MO to be forwarded has a clear H flag, the node RPLInstanceID, the Target Address and, if RPLInstanceID is a local
MUST ensure that the Address vector in the Source Route option value, the DODAGID (same as the Origin Address) to determine the next
contains the next hop address as the first element. hop for the MO. Also,
6. Processing a Received MO at the Target Node o If the RPLInstanceID of the hop-by-hop route is a local value and
the A flag is set, the router MUST store one of its IPv6 addresses
(after eliding Compr bytes and making sure that the Address vector
does not already contains one of its IPv6 addresses) at location
Address[Index] and then increments the Index field.
When a node receives an MO, it examines if one of its IPv6 addresses o If the router is the root of the non-storing DAG along which the
is listed as the Target Address. If yes, the node checks the T flag. received MO message has been traveling, the router MUST do the
The node MUST drop the MO with no further processing and optionally following:
log an error if the T flag is clear (i.e. the received MO is a
Measurement Reply).
The target node then checks the D flag to determine the direction of * reset the H, A and R flags;
the P2P route to be measured. If the D flag is set (i.e., the P2P
route to be measured is from the origin node to the target node), the
target node updates the routing metrics objects in the Metric
Container options if required, removes the Source Route Option if
present and clears the T bit thereby converting the MO into a
Measurement Reply. The target node then unicasts the updated MO back
to the origin node. For this purpose, the target node MAY use the
reverse route accumulated in the Record Route IPv6 Extension Header
[I-D.thubert-6man-reverse-routing-header] if present in the received
MO message.
If the D flag in the received MO message is clear (i.e., the P2P * insert a source route to the target inside the Address vector;
route to be measured is from the target node to the origin node), the
target node selects the P2P route to be measured and modifies the
following MO fields:
o RPLInstanceID: If the P2P route is a hop-by-hop route, the target * specify in the Num field the number of address elements in the
node specifies in this field the RPLInstanceID associated with the Address vector;
route. This field is not relevant if the P2P route is a source
route. This document RECOMMENDS a value 10000000 for this field
if the P2P route is a source route.
o T: The T flag is cleared to indicate that MO represents a * set the Index field to value zero;
Measurement Reply.
o H: The H flag is set if the P2P route is a hop-by-hop one. The router MUST drop the MO with no further processing and send an
ICMPv6 Destination Unreachable error message to the source of the
message if it can not determine the next hop for the message.
o I: If the H flag is set and the RPLInstanceID is a local value, After determining the next hop, the router updates the routing metric
the target node sets this flag if the Origin Address indicates the objects, contained in the Metric Container options inside the MO,
DODAGID. The target node clears this flag if the Target Address either by updating the aggregated value for the routing metric or by
indicates the DODAGID. attaching the local values for the metric inside the object. The
router MUST drop the MO with no further processing and send a
suitable ICMPv6 error message to the source of the message if the
router does not know the relevant routing metric values for the next
hop.
o D: This flag is cleared. After updating the routing metrics, the router MUST unicast the MO to
the next hop.
o Source Route Option: If the P2P route is a source route, the 6. Processing a Measurement Request at the Target
Source Route option MUST be present and MUST include a complete
source route from the target node to the origin node (excluding
the addresses of the target and origin nodes).
o Metric Container Options: The target node MUST initiate the When a router receives an MO, it examines if one of its IPv6
routing metric objects inside the Metric Container options by addresses is listed as the Target Address. If yes, the router
including the local values of the routing metrics for the first processes the received message in the following manner.
hop on the P2P route.
The target node need not modify the other fields in the received MO. An intermediate router MUST discard the packet with no further
After these modifications, the target node MUST unicast the MO processing if the received MO is not a Measurement Request.
message to the next hop on the P2P route.
7. Processing a Received MO at the Origin Node The target then updates the routing metrics objects in the Metric
Container options if required and generates a Measurement Reply
message. The received Measurement Request message can be trivially
converted into the Measurement Reply by reseting the T flag to zero.
The target MAY remove the Address vector from the Measurement Reply
if desired. The target then unicasts the Measurement Reply back to
the origin:
When a node receives an MO, it examines if one of its IPv6 addresses o If the Measurement Request traveled along a DAG with a global
is listed as the Origin Address. If yes, the node checks the T flag. RPLInstanceID, the Measurement Reply MAY be unicast back to the
The node MUST drop the MO with no further processing and optionally origin along the same DAG.
log an error if the T flag is set (i.e. the received MO is a
Measurement Request) or if the node has no recollection of sending a
Measurement Request with the sequence number listed in the received
MO.
If the D flag in the received MO is clear (i.e., the P2P route to be o If the Measurement Request traveled along a hop-by-hop route with
measured is from the target node to the origin node), the origin node a local RPLInstanceID and the A flag inside the received message
MUST update the routing metrics objects in the Metric Container is set, the target MAY reverse the source route contained in the
options if required. Address vector and use it to send the Measurement Reply back to
the origin.
The origin node can now examine the routing metric objects inside the o If the Measurement Request traveled along a source route and the R
Metric Container options to evaluate the quality of the measured P2P flag inside the received message it set, the target MAY reverse
route. If a routing metric object contains local metric values the source route contained in the Address vector and use it to
recorded by enroute nodes, the origin node MAY aggregate these local send the Measurement Reply back to the origin.
values into an end-to-end value as per the aggregation rules for the
metric. 7. Processing a Measurement Reply at the Origin
When a router receives an MO, it examines if one of its IPv6
addresses is listed as the Origin Address. If yes, the router
processes the received message in the following manner.
The origin MUST discard the packet with no further processing if the
received MO is not a Measurement Reply or if the origin has no
recollection of sending a Measurement Request with the sequence
number listed in the received MO.
The origin then examines the routing metric objects inside the Metric
Container options to evaluate the quality of the measured P2P route.
If a routing metric object contains local metric values recorded by
enroute routers, the origin MAY aggregate these local values into an
end-to-end value as per the aggregation rules for the metric.
8. Security Considerations 8. Security Considerations
TBA TBA
9. IANA Considerations 9. IANA Considerations
TBA TBA
10. Acknowledgement 10. Authors and Contributors
Authors gratefully acknowledge the contributions of Pascal Thubert, In addition to the editors, the authors of this document include the
Richard Kelsey and Zach Shelby in the development of this document. following individuals (listed in alphabetical order).
Anders Brandt, Sigma Designs, Emdrupvej 26A, 1., Copenhagen, Dk-2100,
Denmark. Phone: +45 29609501; Email: abr@sdesigns.dk
Robert Cragie, Gridmerge Ltd, 89 Greenfield Crescent, Wakefieldm WF4
4WA, UK. Phone: +44 1924910888; Email: robert.cragie@gridmerge.com
Jerald Martocci, Johnson Controls, Milwaukee, WI 53202, USA. Phone:
+1 414 524 4010; Email:jerald.p.martocci@jci.com
Charles Perkins, Tellabs Inc., USA. Email:charliep@computer.org
Authors gratefully acknowledge the contributions of Richard Kelsey
and Zach Shelby in the development of this document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References 11.2. Informative References
[I-D.ietf-roll-p2p-rpl] [I-D.ietf-roll-p2p-rpl]
Goyal, M., Baccelli, E., Brandt, A., Cragie, R., Martocci, Goyal, M., Baccelli, E., Brandt, A., Cragie, R., and J.
J., and C. Perkins, "Reactive Discovery of Point-to-Point Martocci, "Reactive Discovery of Point-to-Point Routes in
Routes in Low Power and Lossy Networks", Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-03
draft-ietf-roll-p2p-rpl-02 (work in progress), (work in progress), May 2011.
February 2011.
[I-D.ietf-roll-routing-metrics] [I-D.ietf-roll-routing-metrics]
Vasseur, J., Kim, M., Pister, K., Dejean, N., and D. Vasseur, J., Kim, M., Pister, K., Dejean, N., and D.
Barthel, "Routing Metrics used for Path Calculation in Low Barthel, "Routing Metrics used for Path Calculation in Low
Power and Lossy Networks", Power and Lossy Networks",
draft-ietf-roll-routing-metrics-19 (work in progress), draft-ietf-roll-routing-metrics-19 (work in progress),
March 2011. March 2011.
[I-D.ietf-roll-rpl] [I-D.ietf-roll-rpl]
Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
Vasseur, "RPL: IPv6 Routing Protocol for Low power and Vasseur, "RPL: IPv6 Routing Protocol for Low power and
Lossy Networks", draft-ietf-roll-rpl-19 (work in Lossy Networks", draft-ietf-roll-rpl-19 (work in
progress), March 2011. progress), March 2011.
[I-D.ietf-roll-terminology] [I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-05 (work in Networks", draft-ietf-roll-terminology-05 (work in
progress), March 2011. progress), March 2011.
[I-D.thubert-6man-reverse-routing-header]
Thubert, P., "Reverse Routing Header",
draft-thubert-6man-reverse-routing-header-01 (work in
progress), December 2010.
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low-Power and Lossy Networks", Routing Requirements in Low-Power and Lossy Networks",
RFC 5826, April 2010. RFC 5826, April 2010.
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
"Building Automation Routing Requirements in Low-Power and "Building Automation Routing Requirements in Low-Power and
Lossy Networks", RFC 5867, June 2010. Lossy Networks", RFC 5867, June 2010.
Authors' Addresses Authors' Addresses
skipping to change at page 14, line 12 skipping to change at line 572
Phone: +44-1924910888 Phone: +44-1924910888
Email: robert.cragie@gridmerge.com Email: robert.cragie@gridmerge.com
Jerald Martocci Jerald Martocci
Johnson Controls Johnson Controls
507 E Michigan St 507 E Michigan St
Milwaukee, WI 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
Charles Perkins
Tellabs Inc
Email: charliep@computer.org
 End of changes. 80 change blocks. 
305 lines changed or deleted 297 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/