draft-ietf-roll-routing-metrics-13.txt   draft-ietf-roll-routing-metrics-14.txt 
Networking Working Group JP. Vasseur, Ed. Networking Working Group JP. Vasseur, Ed.
Internet-Draft Cisco Systems, Inc Internet-Draft Cisco Systems, Inc
Intended status: Standards Track M. Kim, Ed. Intended status: Standards Track M. Kim, Ed.
Expires: June 5, 2011 Corporate Technology Group, KT Expires: June 16, 2011 Corporate Technology Group, KT
K. Pister K. Pister
Dust Networks Dust Networks
N. Dejean N. Dejean
Coronis SAS Coronis SAS
D. Barthel D. Barthel
France Telecom Orange France Telecom Orange
December 6, 2010 December 13, 2010
Routing Metrics used for Path Calculation in Low Power and Lossy Routing Metrics used for Path Calculation in Low Power and Lossy
Networks Networks
draft-ietf-roll-routing-metrics-13 draft-ietf-roll-routing-metrics-14
Abstract Abstract
Low power and Lossy Networks (LLNs) have unique characteristics Low power and Lossy Networks (LLNs) have unique characteristics
compared with traditional wired and ad-hoc networks that require the compared with traditional wired and ad-hoc networks that require the
specification of new routing metrics and constraints. By contrast specification of new routing metrics and constraints. By contrast
with typical Interior Gateway Protocol (IGP) routing metrics using with typical Interior Gateway Protocol (IGP) routing metrics using
hop counts or link metrics, this document specifies a set of link and hop counts or link metrics, this document specifies a set of link and
node routing metrics and constraints suitable to LLNs to be used by node routing metrics and constraints suitable to LLNs to be used by
the Routing for Low Power and lossy networks (RPL) routing protocol. the Routing for Low Power and lossy networks (RPL) routing protocol.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 5, 2011. This Internet-Draft will expire on June 16, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 3, line 25 skipping to change at page 3, line 25
3.3. Hop-Count Object . . . . . . . . . . . . . . . . . . . . . 16 3.3. Hop-Count Object . . . . . . . . . . . . . . . . . . . . . 16
4. Link Metric/Constraint Objects . . . . . . . . . . . . . . . . 17 4. Link Metric/Constraint Objects . . . . . . . . . . . . . . . . 17
4.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3. Link Reliability . . . . . . . . . . . . . . . . . . . . . 19 4.3. Link Reliability . . . . . . . . . . . . . . . . . . . . . 19
4.3.1. The Link Quality Level Reliability Metric . . . . . . 20 4.3.1. The Link Quality Level Reliability Metric . . . . . . 20
4.3.2. The Expected Transmission Count (ETX) reliability 4.3.2. The Expected Transmission Count (ETX) reliability
object . . . . . . . . . . . . . . . . . . . . . . . . 21 object . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4. Link Color Object . . . . . . . . . . . . . . . . . . . . 23 4.4. Link Color Object . . . . . . . . . . . . . . . . . . . . 23
4.4.1. Link Color Object Description . . . . . . . . . . . . 23 4.4.1. Link Color Object Description . . . . . . . . . . . . 23
4.4.2. Mode of operation . . . . . . . . . . . . . . . . . . 25 4.4.2. Mode of operation . . . . . . . . . . . . . . . . . . 24
5. Computation of Dynamic Metrics and Attributes . . . . . . . . 25 5. Computation of Dynamic Metrics and Attributes . . . . . . . . 25
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
6.1. Routing Metric/Constraint Type . . . . . . . . . . . . . . 26 6.1. Routing Metric/Constraint Type . . . . . . . . . . . . . . 25
6.2. Routing Metric/Constraint TLV . . . . . . . . . . . . . . 26 6.2. Routing Metric/Constraint TLV . . . . . . . . . . . . . . 26
6.3. Routing Metric/Constraint Common Header . . . . . . . . . 26 6.3. Routing Metric/Constraint Common Header . . . . . . . . . 26
6.4. NSA Object . . . . . . . . . . . . . . . . . . . . . . . . 27 6.4. NSA Object . . . . . . . . . . . . . . . . . . . . . . . . 27
6.5. Hop-Count Object . . . . . . . . . . . . . . . . . . . . . 27 6.5. Hop-Count Object . . . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Normative references . . . . . . . . . . . . . . . . . . . 28 9.1. Normative references . . . . . . . . . . . . . . . . . . . 28
9.2. Informative references . . . . . . . . . . . . . . . . . . 29 9.2. Informative references . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
skipping to change at page 4, line 37 skipping to change at page 4, line 37
One of the prime objectives of this document is to define a flexible One of the prime objectives of this document is to define a flexible
mechanism for the advertisement of routing metrics and constraints mechanism for the advertisement of routing metrics and constraints
used by RPL. Some RPL implementations may elect to adopt an used by RPL. Some RPL implementations may elect to adopt an
extremely simple approach based on the use of a single metric with no extremely simple approach based on the use of a single metric with no
constraint whereas other implementations may use a larger set of link constraint whereas other implementations may use a larger set of link
and node routing metrics and constraints. This specification and node routing metrics and constraints. This specification
provides a high degree of flexibility and a set of routing metrics provides a high degree of flexibility and a set of routing metrics
and constraints. New routing metrics and constraints could be and constraints. New routing metrics and constraints could be
defined in the future, as needed. defined in the future, as needed.
The metrics and constraints defined in this document are carried in
objects that are OPTIONAL within RPL. This means that
implementations are free to include different subsets of the
functions (metric, constraint) defined in this document. Specific
sets of metrics/constraints and other optional RPL parameters for use
in key environments will be specified as compliance profiles in
applicability profile documents produced by the ROLL working group.
RPL is a distance vector routing protocol variant that builds RPL is a distance vector routing protocol variant that builds
Directed Acyclic Graphs (DAGs) based on routing metrics and Directed Acyclic Graphs (DAGs) based on routing metrics and
constraints. DAG formation rules are defined in [I-D.ietf-roll-rpl]: constraints. DAG formation rules are defined in [I-D.ietf-roll-rpl]:
o The Destination Oriented Directed Acyclic Graph (DODAG) root as o The Destination Oriented Directed Acyclic Graph (DODAG) root as
defined in [I-D.ietf-roll-rpl] may advertise a routing constraint defined in [I-D.ietf-roll-rpl] may advertise a routing constraint
used as a "filter" to prune links and nodes that do not satisfy used as a "filter" to prune links and nodes that do not satisfy
specific properties. For example, it may be required for the path specific properties. For example, it may be required for the path
to only traverse nodes that are mains powered or links that have to only traverse nodes that are mains powered or links that have
at least a minimum reliability or a specific "color" reflecting a at least a minimum reliability or a specific "color" reflecting a
skipping to change at page 7, line 25 skipping to change at page 7, line 34
2. Object Formats 2. Object Formats
2.1. DAG Metric Container Format 2.1. DAG Metric Container Format
Routing metrics and constraints are carried within the DAG Metric Routing metrics and constraints are carried within the DAG Metric
Container object defined in [I-D.ietf-roll-rpl]. Should multiple Container object defined in [I-D.ietf-roll-rpl]. Should multiple
metrics and/or constraints be present in the DAG Metric Container, metrics and/or constraints be present in the DAG Metric Container,
their use to determine the "best" path can be defined by an Objective their use to determine the "best" path can be defined by an Objective
Function. Function.
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Type=2 | Option Len |Routing Metric/Constraint objects
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Figure 1: DAG Metric Container format
The Routing Metric/Constraint objects represent a metric or a The Routing Metric/Constraint objects represent a metric or a
constraint of a particular type. They may appear in any order in the constraint of a particular type. They may appear in any order in the
DAG Metric Container. They have a common format consisting of one or DAG Metric Container (specified in [I-D.ietf-roll-rpl]). They have a
more bytes with a common header: common format consisting of one or more bytes with a common header:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Routing-MC-Type| Flags |P|C|O|R| A | Prec | Length (bytes)| |Routing-MC-Type| Flags |P|C|O|R| A | Prec | Length (bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (object body) // // (object body) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Routing Metric/Constraint object generic format Figure 1: Routing Metric/Constraint object generic format
The object body carries one or more sub-objects defined later in this The object body carries one or more sub-objects defined later in this
document. Note that an object may carry TLV, which may itself document. Note that an object may carry TLV, which may itself
comprise other TLVs. A TLV carried within a TLV is called a TLV in comprise other TLVs. A TLV carried within a TLV is called a TLV in
this specification. this specification.
Routing-MC-Type (Routing Metric/Constraint Type - 8 bits): the Routing-MC-Type (Routing Metric/Constraint Type - 8 bits): the
Routing Metric/Constraint Type field uniquely identifies each Routing Routing Metric/Constraint Type field uniquely identifies each Routing
Metric/Constraint object and is managed by IANA. Metric/Constraint object and is managed by IANA.
skipping to change at page 11, line 29 skipping to change at page 11, line 29
behavior is implementation-dependant. behavior is implementation-dependant.
3. Node Metric/Constraint Objects 3. Node Metric/Constraint Objects
The sections 3. and 4. specify several link and node metric/ The sections 3. and 4. specify several link and node metric/
constraint objects. In some cases it is stated that there must not constraint objects. In some cases it is stated that there must not
be more than one object of a specific type. In that case, if an RPL be more than one object of a specific type. In that case, if an RPL
implementation receives more than one objet of that type, the second implementation receives more than one objet of that type, the second
objet MUST silently be ignored. objet MUST silently be ignored.
In the presence of a constraint and a metric (which may or may not be
of the same type), a node MUST update the constraint before
advertising the updated metric and constraints. For example, if the
constraint is the number of hops (e.g. the maximum number of hops is
n) and the path is optimized against the delay: if a node selects a
parent advertising a maximum number of hops of n (constraint), it
must advertises DIO messages containing a hop count metrics
constraint with a field value equal of (n-1) and the newly computed
path metric. This applies to the following constraints defined
below: hop-count, latency and path ETX.
3.1. Node State and Attributes Object 3.1. Node State and Attributes Object
The Node State and Attribute (NSA) object is used to provide The Node State and Attribute (NSA) object is used to provide
information on node characteristics. information on node characteristics.
The NSA object MAY be present in the DAG Metric Container. There The NSA object MAY be present in the DAG Metric Container. There
MUST NOT be more than one NSA object as a constraint per DAG Metric MUST NOT be more than one NSA object as a constraint per DAG Metric
Container, and there MUST NOT be more than one NSA object as a metric Container, and there MUST NOT be more than one NSA object as a metric
per DAG Metric Container. per DAG Metric Container.
skipping to change at page 12, line 13 skipping to change at page 12, line 17
(recommended value=1). (recommended value=1).
The format of the NSA object body is as follows: The format of the NSA object body is as follows:
0 1 2 0 1 2
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Res | Flags |A|O| Optional TLVs | Res | Flags |A|O| Optional TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 3: NSA object body format Figure 2: NSA object body format
Res flags (8 bits): Reserved field. This field MUST be set to zero Res flags (8 bits): Reserved field. This field MUST be set to zero
on transmission and MUST be ignored on receipt. on transmission and MUST be ignored on receipt.
The following two bits of the NSA object are currently defined: The following two bits of the NSA object are currently defined:
o A Flag: data Aggregation Attribute. Data fusion involves more o A Flag: data Aggregation Attribute. Data fusion involves more
complicated processing to improve the accuracy of the output data, complicated processing to improve the accuracy of the output data,
while data aggregation mostly aims at reducing the amount of data. while data aggregation mostly aims at reducing the amount of data.
This is listed as a requirement in Section 6.2 of [RFC5548]. Some This is listed as a requirement in Section 6.2 of [RFC5548]. Some
skipping to change at page 15, line 16 skipping to change at page 15, line 21
The NE object Type is to be assigned by IANA (recommended value=2). The NE object Type is to be assigned by IANA (recommended value=2).
The format of the NE object body is as follows: The format of the NE object body is as follows:
0 1 2 0 1 2
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| NE Sub-objects | NE Sub-objects
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 4: NE sub-object format Figure 3: NE sub-object format
The format of the NE sub-object body is as follows: The format of the NE sub-object body is as follows:
0 1 2 0 1 2
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Flags |I| T |E| E-E | Optional TLVs | Flags |I| T |E| E-E | Optional TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 5: NE sub-object format Figure 4: NE sub-object format
The NE sub-object may also contain a set of TLVs used to convey The NE sub-object may also contain a set of TLVs used to convey
various nodes' characteristics. various nodes' characteristics.
The following flags are currently defined: The following flags are currently defined:
o I (Included): the I bit is only relevant when the node type is o I (Included): the I bit is only relevant when the node type is
used as a constraint. For example, the path must only traverse used as a constraint. For example, the path must only traverse
mains-powered nodes. Conversely, battery operated nodes must be mains-powered nodes. Conversely, battery operated nodes must be
excluded. The I bit is used to stipulate inclusion versus excluded. The I bit is used to stipulate inclusion versus
skipping to change at page 16, line 39 skipping to change at page 17, line 4
The HP object MAY be present in the DAG Metric Container. There MUST The HP object MAY be present in the DAG Metric Container. There MUST
NOT be more than one HP object as a constraint per DAG Metric NOT be more than one HP object as a constraint per DAG Metric
Container, and there MUST NOT be more than one HP object as a metric Container, and there MUST NOT be more than one HP object as a metric
per DAG Metric Container. per DAG Metric Container.
The HP object may also contain a set of TLVs used to convey various The HP object may also contain a set of TLVs used to convey various
node characteristics. No TLV is currently defined. node characteristics. No TLV is currently defined.
The HP routing metric object Type is to be assigned by IANA The HP routing metric object Type is to be assigned by IANA
(recommended value=3) (recommended value=3)
The format of the Hop Count object body is as follows: The format of the Hop Count object body is as follows:
0 1 2 0 1 2
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Res | Flags | Hop Count | Optional TLVs | Res | Flags | Hop Count | Optional TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 6: Hop Count object body format Figure 5: Hop Count object body format
Res flags (4 bits): Reserved field. This field MUST be set to zero Res flags (4 bits): Reserved field. This field MUST be set to zero
on transmission and MUST be ignored on receipt. on transmission and MUST be ignored on receipt.
No Flag is currently defined. Unassigned bits are considered as No Flag is currently defined. Unassigned bits are considered as
reserved. They MUST be set to zero on transmission and MUST be reserved. They MUST be set to zero on transmission and MUST be
ignored on receipt. ignored on receipt.
The HP object may be used as a constraint or a metric. When used as The HP object may be used as a constraint or a metric. When used as
a constraint, the DAG root indicates the maximum number of hops that a constraint, the DAG root indicates the maximum number of hops that
skipping to change at page 18, line 4 skipping to change at page 18, line 14
object MUST be the most recently estimated actual throughput. The object MUST be the most recently estimated actual throughput. The
actual estimation of the throughput is outside the scope of this actual estimation of the throughput is outside the scope of this
document. document.
Each Throughput sub-object has a fixed length of 4 bytes. Each Throughput sub-object has a fixed length of 4 bytes.
The Throughput object does not contain any additional TLV. The Throughput object does not contain any additional TLV.
The Throughput object Type is to be assigned by IANA (recommended The Throughput object Type is to be assigned by IANA (recommended
value=4) value=4)
The format of the Throughput object body is as follows: The format of the Throughput object body is as follows:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-object) ..... | (sub-object) .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Throughput object body format Figure 6: Throughput object body format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Throughput | | Throughput |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Throughput sub-object format Figure 7: Throughput sub-object format
Throughput: 32 bits. The Throughput is encoded in 32 bits in Throughput: 32 bits. The Throughput is encoded in 32 bits in
unsigned integer format, expressed in bytes per second. unsigned integer format, expressed in bytes per second.
4.2. Latency 4.2. Latency
Similarly to throughput, the latency of many LLN MAC sub-layers can Similarly to throughput, the latency of many LLN MAC sub-layers can
vary over many orders of magnitude, again with a corresponding change vary over many orders of magnitude, again with a corresponding change
in power consumption. Some LLN MAC link layers will allow the in power consumption. Some LLN MAC link layers will allow the
latency to be adjusted globally on the subnet, on a link-by-link latency to be adjusted globally on the subnet, on a link-by-link
skipping to change at page 19, line 13 skipping to change at page 19, line 22
The Latency object is a metric or constraint. The Latency object is a metric or constraint.
The format of the Latency object body is as follows: The format of the Latency object body is as follows:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-object) ..... | (sub-object) .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Latency object body format Figure 8: Latency object body format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latency | | Latency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Latency sub-object format Figure 9: Latency sub-object format
Latency: 32 bits. The Latency is encoded in 32 bits in unsigned Latency: 32 bits. The Latency is encoded in 32 bits in unsigned
integer format, expressed in microseconds. integer format, expressed in microseconds.
The Latency object may be used as a constraint or a path metric. For The Latency object may be used as a constraint or a path metric. For
example, one may want the latency not to exceed some value. In this example, one may want the latency not to exceed some value. In this
case, the Latency object common header indicates that the provided case, the Latency object common header indicates that the provided
value relates to a constraint. In another example, the Latency value relates to a constraint. In another example, the Latency
object may be used as an aggregated additive metric where the value object may be used as an aggregated additive metric where the value
is updated along the path to reflect the path latency. is updated along the path to reflect the path latency.
skipping to change at page 20, line 5 skipping to change at page 20, line 15
specific to wireless link but also applies to PLC links. specific to wireless link but also applies to PLC links.
A change in link quality can affect network connectivity, thus, link A change in link quality can affect network connectivity, thus, link
quality may be taken into account as a critical routing metric. quality may be taken into account as a critical routing metric.
A number of link reliability metrics could be defined reflecting A number of link reliability metrics could be defined reflecting
several reliability aspects. Two link reliability metrics are several reliability aspects. Two link reliability metrics are
defined in this document: the Link Quality Level (LQL) and the defined in this document: the Link Quality Level (LQL) and the
Expected Transmission count Metric (ETX). Expected Transmission count Metric (ETX).
Note that an RPL implementation MAY either use the LQL, the ETX or Note that an RPL deployment MAY either use the LQL, the ETX or both.
both.
4.3.1. The Link Quality Level Reliability Metric 4.3.1. The Link Quality Level Reliability Metric
The Link Quality Level (LQL) object is used to quantify the link The Link Quality Level (LQL) object is used to quantify the link
reliability using a discrete value, from 0 to 7 where 0 indicates reliability using a discrete value, from 0 to 7 where 0 indicates
that the link quality level is unknown and 1 reports the highest link that the link quality level is unknown and 1 reports the highest link
quality level. The mechanisms and algorithms used to compute the LQL quality level. The mechanisms and algorithms used to compute the LQL
are implementation specific and outside of the scope of this are implementation specific and outside of the scope of this
document. document.
The LQL can either be used as a metric or a constraint. When used as The LQL can either be used as a metric or a constraint. When used as
a metric, the LQL metric can be recorded or aggregated. For example, a metric, the LQL metric can only be recorded. For example, the DAG
the DAG Metric object may request all traversed nodes to record the Metric object may request all traversed nodes to record the LQL of
LQL of their incoming link into the LQL object. Each node can then their incoming link into the LQL object. Each node can then use the
use the LQL record to select its parent based on some user defined LQL record to select its parent based on some user defined rules
rules (e.g. something like "select the path with most links reporting (e.g. something like "select the path with most links reporting a LQL
a LQL value of 3 or less"). By contrast, the LQL link metric may be value of 3 or less").
aggregated, in which case the sum of all LQLs may be reported
(additive metric) or the minimum value may be reported along the
path.
When used as a recorded metric, counters are used to compress the Counters are used to compress the information: for each encountered
information: for each encountered LQL value, only the number of LQL value, only the number of matching links is reported.
matching links is reported.
The LQL object MAY be present in the DAG Metric Container. There The LQL object MAY be present in the DAG Metric Container. There
MUST NOT be more than one LQL object as a constraint per DAG Metric MUST NOT be more than one LQL object as a constraint per DAG Metric
Container, and there MUST NOT be more than one LQL object as a metric Container, and there MUST NOT be more than one LQL object as a metric
per DAG Metric Container. per DAG Metric Container.
The LQL object MUST contain one or more sub-object used to report the The LQL object MUST contain one or more sub-object used to report the
number of links along with their LQL. number of links along with their LQL.
The LQL object Type is to be assigned by IANA (recommended value=6) The LQL object Type is to be assigned by IANA (recommended value=6)
skipping to change at page 20, line 41 skipping to change at page 21, line 4
The LQL object MAY be present in the DAG Metric Container. There The LQL object MAY be present in the DAG Metric Container. There
MUST NOT be more than one LQL object as a constraint per DAG Metric MUST NOT be more than one LQL object as a constraint per DAG Metric
Container, and there MUST NOT be more than one LQL object as a metric Container, and there MUST NOT be more than one LQL object as a metric
per DAG Metric Container. per DAG Metric Container.
The LQL object MUST contain one or more sub-object used to report the The LQL object MUST contain one or more sub-object used to report the
number of links along with their LQL. number of links along with their LQL.
The LQL object Type is to be assigned by IANA (recommended value=6) The LQL object Type is to be assigned by IANA (recommended value=6)
The format of the LQL object body is as follows: The format of the LQL object body is as follows:
0 1 2 0 1 2
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Res | LQL sub-object | Res | LQL sub-object
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 12: LQL object body format Figure 10: LQL object body format
Res flags (8 bits): Reserved field. This field MUST be set to zero Res flags (8 bits): Reserved field. This field MUST be set to zero
on transmission and MUST be ignored on receipt. on transmission and MUST be ignored on receipt.
When the LQL metric is recorded, the LQL object body comprises one or When the LQL metric is recorded, the LQL object body comprises one or
more LQL Type 1 sub-object. more LQL Type 1 sub-object.
The format of the LQL Type 1 sub-object is as follows The format of the LQL Type 1 sub-object is as follows
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Val | Counter | | Val | Counter |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 13: LQL Type 1 sub-object format Figure 11: LQL Type 1 sub-object format
Val: LQL value from 0 to 7 where 0 means undetermined and 1 indicates Val: LQL value from 0 to 7 where 0 means undetermined and 1 indicates
the highest link quality. the highest link quality.
Counter: number of links with that value. Counter: number of links with that value.
When the LQL metric is aggregated, the LQL object body comprises one
LQL Type 2 sub-object:
The format of the LQL Type 2 sub-object is as follows
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Aggregated LQL Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: LQL Type 2 sub-object format
Aggregated LQL Value: when used as an additive metric (A=0x00), the
aggregated LQL value reports the sum of all the LQL values for all
links along the path. When used to report a minimum (A=0x02), the
field reports the minimum LQL value of all links along the path,
ignoring undetermined LQLs (Aggregated LQL Value = 0). When used to
report a maximum (A=0x01), the field reports the maximum LQL value of
all links along the path. When used to report a multiplication
(A=0x03), and the LQL field of one of the links along the path is
undetermined (LQL=0), the undetermined LQL will be ignored and not be
aggregated (i.e. no reset to Aggregated LQL Value field).
4.3.2. The Expected Transmission Count (ETX) reliability object 4.3.2. The Expected Transmission Count (ETX) reliability object
The Expected Transmission Count (ETX) metric is the number of The Expected Transmission Count (ETX) metric is the number of
transmissions a node expects to make to a destination in order to transmissions a node expects to make to a destination in order to
successfully deliver a packet. In contrast with the LQL routing successfully deliver a packet. In contrast with the LQL routing
metric, the ETX provides a discrete value (wich may not be an metric, the ETX provides a discrete value (wich may not be an
integer) computed according to a specific formula: for example, an integer) computed according to a specific formula: for example, an
implementation may use the following formula: ETX= 1 / (Df * Dr) implementation may use the following formula: ETX= 1 / (Df * Dr)
where Df is the measured probability that a packet is received by the where Df is the measured probability that a packet is received by the
neighbor and Dr is the measured probability that the acknowledgment neighbor and Dr is the measured probability that the acknowledgment
skipping to change at page 22, line 34 skipping to change at page 22, line 21
The ETX object Type is to be assigned by IANA (recommended value=7) The ETX object Type is to be assigned by IANA (recommended value=7)
The format of the ETX object body is as follows: The format of the ETX object body is as follows:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-object) ..... | (sub-object) .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: ETX object body format Figure 12: ETX object body format
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETX | | ETX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: ETX sub-object format Figure 13: ETX sub-object format
ETX: 16 bits. The ETX * 128 is encoded using 16 bits in unsigned ETX: 16 bits. The ETX * 128 is encoded using 16 bits in unsigned
integer format, rounded off to the nearest whole number. For integer format, rounded off to the nearest whole number. For
example, if ETX = 3.569, the object value will be 457. If ETX > example, if ETX = 3.569, the object value will be 457. If ETX >
511.9921875, the object value will be the maximum which is 65535. 511.9921875, the object value will be the maximum which is 65535.
The ETX object may be used as a constraint or a path metric. For The ETX object may be used as a constraint or a path metric. For
example, it may be required that the ETX must not exceed some example, it may be required that the ETX must not exceed some
specified value. In this case, the ETX object common header specified value. In this case, the ETX object common header
indicates that the value relates to a constraint. In another indicates that the value relates to a constraint. In another
skipping to change at page 24, line 4 skipping to change at page 23, line 37
The Link Color (LC) object MAY be present in the DAG Metric The Link Color (LC) object MAY be present in the DAG Metric
Container. There MUST NOT be more than one LC object as a constraint Container. There MUST NOT be more than one LC object as a constraint
per DAG Metric Container, and there MUST NOT be more than one LC per DAG Metric Container, and there MUST NOT be more than one LC
object as a metric per DAG Metric Container. object as a metric per DAG Metric Container.
There MUST be a at least one LC sub-object per LC object. There MUST be a at least one LC sub-object per LC object.
The LC object does not contain any additional TLV. The LC object does not contain any additional TLV.
The LC object Type is to be assigned by IANA (recommended value=8) The LC object Type is to be assigned by IANA (recommended value=8)
The format of the LC object body is as follows: The format of the LC object body is as follows:
0 1 2 0 1 2
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Res | LC sub-objects | Res | LC sub-objects
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 17: LC object format Figure 14: LC object format
Res flags (8 bits): Reserved field. This field MUST be set to zero Res flags (8 bits): Reserved field. This field MUST be set to zero
on transmission and MUST be ignored on receipt. on transmission and MUST be ignored on receipt.
When the LC object is used as a recorded metric, the LC object body When the LC object is used as a recorded metric, the LC object body
comprises one or more LC Type 1 sub-objects. comprises one or more LC Type 1 sub-objects.
The format of the LC Type 1 sub-object body is as follows: The format of the LC Type 1 sub-object body is as follows:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Color | Counter | | Link Color | Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: LC Type 1 sub-object format Figure 15: LC Type 1 sub-object format
When the LC object is used as a constraint, the LC object body When the LC object is used as a constraint, the LC object body
comprises one or more LC Type 2 sub-objects. comprises one or more LC Type 2 sub-objects.
The format of the LC Type 2 sub-object body is as follows: The format of the LC Type 2 sub-object body is as follows:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Color |Reserved |I| | Link Color |Reserved |I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: LC Type 2 sub-object format Figure 16: LC Type 2 sub-object format
Res flags (7 bits): Reserved field. This field MUST be set to zero Res flags (7 bits): Reserved field. This field MUST be set to zero
on transmission and MUST be ignored on receipt. on transmission and MUST be ignored on receipt.
I Bit: The I bit is only relevant when the Link Color is used as a I Bit: The I bit is only relevant when the Link Color is used as a
constraint. When cleared, this indicates that links with the constraint. When cleared, this indicates that links with the
specified color must be included. When set, this indicates that specified color must be included. When set, this indicates that
links with the specified color must be excluded. links with the specified color must be excluded.
It is left to the implementer to define the meaning of each bit of It is left to the implementer to define the meaning of each bit of
skipping to change at page 28, line 49 skipping to change at page 28, line 41
review. review.
9. References 9. References
9.1. Normative references 9.1. Normative references
[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-15 (work in Lossy Networks", draft-ietf-roll-rpl-16 (work in
progress), November 2010. progress), December 2010.
[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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
9.2. Informative references 9.2. Informative references
 End of changes. 35 change blocks. 
74 lines changed or deleted 56 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/