draft-ietf-roll-routing-metrics-01.txt   draft-ietf-roll-routing-metrics-02.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: April 26, 2010 Future Tech Lab., Korea Telecom Expires: April 29, 2010 Future Tech Lab., Korea Telecom
K. Pister K. Pister
Dust Networks Dust Networks
H. Chong H. Chong
Future Tech Lab., Korea Telecom Future Tech Lab., Korea Telecom
October 23, 2009 October 26, 2009
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-01 draft-ietf-roll-routing-metrics-02
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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 2010. This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 39 skipping to change at page 3, line 24
4.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. Link reliability . . . . . . . . . . . . . . . . . . . . . 17 4.3. Link reliability . . . . . . . . . . . . . . . . . . . . . 17
4.3.1. The Link Quality Level Reliability Metric . . . . . . 18 4.3.1. The Link Quality Level Reliability Metric . . . . . . 18
4.3.2. The Expected Transmission Count (ETX) Reliability 4.3.2. The Expected Transmission Count (ETX) Reliability
Object . . . . . . . . . . . . . . . . . . . . . . . . 19 Object . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4. Link Color Object . . . . . . . . . . . . . . . . . . . . 21 4.4. Link Color Object . . . . . . . . . . . . . . . . . . . . 21
4.4.1. Link Color Object Description . . . . . . . . . . . . 21 4.4.1. Link Color Object Description . . . . . . . . . . . . 21
4.4.2. Mode of Operation . . . . . . . . . . . . . . . . . . 22 4.4.2. Mode of Operation . . . . . . . . . . . . . . . . . . 22
5. Computation of Dynamic Metrics and Attributes . . . . . . . . 23 5. Computation of Dynamic Metrics and Attributes . . . . . . . . 23
6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 23 6. Objective Function . . . . . . . . . . . . . . . . . . . . . . 23
6.1. Other metric under consideration . . . . . . . . . . . . . 23 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 24
7. Metric Consistency . . . . . . . . . . . . . . . . . . . . . . 23 7.1. Other metric under consideration . . . . . . . . . . . . . 24
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. Metric Consistency . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Routing Objects . . . . . . . . . . . . . . . . . . . . . 24 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8.2. Routing Object Common Header . . . . . . . . . . . . . . . 24 9.1. Routing Objects . . . . . . . . . . . . . . . . . . . . . 25
8.3. NSA Object . . . . . . . . . . . . . . . . . . . . . . . . 25 9.2. Routing Object Common Header . . . . . . . . . . . . . . . 25
8.4. Hop-count Object . . . . . . . . . . . . . . . . . . . . . 25 9.3. NSA Object . . . . . . . . . . . . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 9.4. Hop-count Object . . . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 9.5. Objective Code Point (OCP) Object . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . . 26 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.3. References . . . . . . . . . . . . . . . . . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 12.2. Informative References . . . . . . . . . . . . . . . . . . 27
12.3. References . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
This document makes use of the terminology defined in This document makes use of the terminology defined in
[I-D.ietf-roll-terminology]. [I-D.ietf-roll-terminology].
Low power and Lossy Networks (LLNs) have specific routing Low power and Lossy Networks (LLNs) have specific routing
characteristics compared with traditional wired or ad-hoc networks characteristics compared with traditional wired or ad-hoc networks
that have been spelled out in [RFC5548], that have been spelled out in [RFC5548], [RFC5673],
[I-D.ietf-roll-indus-routing-reqs], [I-D.ietf-roll-home-routing-reqs] [I-D.ietf-roll-home-routing-reqs] and
and [I-D.ietf-roll-building-routing-reqs]. [I-D.ietf-roll-building-routing-reqs].
Historically, IGP such as OSPF ([RFC2328]) and IS-IS ([RFC1195]) have Historically, IGP such as OSPF ([RFC2328]) and IS-IS ([RFC1195]) have
used quantitative static link metrics. Other mechanisms such as used quantitative static link metrics. Other mechanisms such as
Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) (see Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) (see
[RFC2702] and [RFC3209]) make use of other link attributes such as [RFC2702] and [RFC3209]) make use of other link attributes such as
the available reserved bandwidth (dynamic) or link affinities the available reserved bandwidth (dynamic) or link affinities
(static) to compute constrained shortest paths for Traffic (static) to compute constrained shortest paths for Traffic
Engineering Label Switched Paths (TE LSPs). Engineering Label Switched Paths (TE LSPs).
This document specifies routing constraints and metrics to be used in This document specifies routing constraints and metrics to be used in
path calculation by the Routing Protocol for Low Power and Lossy path calculation by the Routing Protocol for Low Power and Lossy
Networks (RPL) specified in [I-D.ietf-roll-rpl]. Networks (RPL) specified in [I-D.ietf-roll-rpl].
One of the prime objectives of this document is to propose a flexible One of the prime objectives of this document is to propose a flexible
mechnanism for the advertisment 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 wheareas other implementations may use a larger set of constraint whereas other implementations may use a larger set of link
link and node routing metrics and constraints. This specification and node routing metrics and constraints. This specification
provides a high degree of flexibility and new routing metrics; new provides a high degree of flexibility and new routing metrics; new
constraints could be defined in the future, as needed. constraints could be defined in the future, as needed.
RPL is a distance vector routing protocol that builds a Directed RPL is a distance vector routing protocol that builds a Directed
Acyclic Graph (DAG) based on routing metrics and constraints. DAG Acyclic Graph (DAG) based on routing metrics and constraints. DAG
formation rules are defined in [I-D.ietf-roll-rpl]: formation rules are defined in [I-D.ietf-roll-rpl]:
o The DAG root may advertise a routing constraint used as a "filter" o The DAG root may advertise a routing constraint used as a "filter"
to prune links and nodes that do not satisfy specific properties. to prune links and nodes that do not satisfy specific properties.
For example, it may be required for the path to only traverse For example, it may be required for the path to only traverse
nodes that are main powered or links that have at least a minimum nodes that are main powered or links that have at least a minimum
reliability or a specific "color" reflecting a user defined link reliability or a specific "color" reflecting a user defined link
charateristic (e.g the link layer supports encryption). characteristic (e.g the link layer supports encryption).
o A routing metric is a quantitative value that is used to evaluate o A routing metric is a quantitative value that is used to evaluate
the path quality, also referred to as the path cost. Link and the path quality, also referred to as the path cost. Link and
nodes metrics are usually (but not always) additive: for example, nodes metrics are usually (but not always) additive: for example,
the throughput or the reliabillity link metric can be used to the throughput or the reliability link metric can be used to
evaluate the path cost. evaluate the path cost.
The best path is the path with the lowest cost with respect to some The best path is the path with the lowest cost with respect to some
metrics that satisfies all constraints (if any) and is also called metrics that satisfies all constraints (if any) and is also called
the shortest constrained path (in the presence of constraints). the shortest constrained path (in the presence of constraints).
Routing metrics can be classified according to the following set of Routing metrics can be classified according to the following set of
characteristics: characteristics:
o Link versus Node metrics o Link versus Node metrics
skipping to change at page 5, line 25 skipping to change at page 5, line 25
o Dynamic versus static o Dynamic versus static
It must be noted that the use of dynamic metrics is not new and has It must be noted that the use of dynamic metrics is not new and has
been experimented in ARPANET 2 [Khanna1989], with moderate success. been experimented in ARPANET 2 [Khanna1989], with moderate success.
The use of dynamic metrics is not trivial and very careful care must The use of dynamic metrics is not trivial and very careful care must
be given to the use of dynamic metrics since it may lead to potential be given to the use of dynamic metrics since it may lead to potential
routing instabilities. routing instabilities.
As pointed out in various routing requirements documents (see As pointed out in various routing requirements documents (see
[I-D.ietf-roll-indus-routing-reqs], [I-D.ietf-roll-home-routing-reqs] [RFC5673], [I-D.ietf-roll-home-routing-reqs] [RFC5548] and
[RFC5548] and [I-D.ietf-roll-building-routing-reqs]), a variety of [I-D.ietf-roll-building-routing-reqs]), it must be possible to take
nodes constraints/metrics must be taken into account during path into account a variety of node constraints/metrics during path
computation (e.g. node's resources). computation.
It is also worth mentioning that it is fairly common for links in It is also worth mentioning that it is fairly common for links in
LLNs to have fast changing node and link charateristics, which must LLNs to have fast changing node and link characteristics, which must
be taken into account when specifying routing metrics. For instance, be taken into account when specifying routing metrics. For instance,
in addition to the dynamic nature of wireless connectivity, nodes' in addition to the dynamic nature of wireless connectivity, nodes'
resources such as residual energy and available resources are resources such as residual energy and other link's charatacteristics
changing continuously and may have to be taken into account during such as the throughput are changing continuously and may have to be
the path computation. Similarly, link attributes including taken into account during the path computation. Similarly, link
throughput and reliability may drastically change over time due to attributes including throughput and reliability may drastically
multi-path interference. change over time due to multi-path interference.
Very careful attention must be given when using dynamic metrics and Very careful attention must be given when using dynamic metrics and
attributes that affect routing decisions in order to preserve routing attributes that affect routing decisions in order to preserve routing
stability. Routing metrics and constraints may either be static or stability. Routing metrics and constraints may either be static or
dynamic. When dynamic, a RPL implementation SHOULD make use of a dynamic. When dynamic, a RPL implementation SHOULD make use of a
multi-threshold scheme rather than fine granular metric updates so as multi-threshold scheme rather than fine granular metric updates so as
to avoid constant routing changes. to avoid constant routing changes.
Furthermore, it is a time and energy consuming process to update Furthermore, it is a time and energy consuming process to update
dynamic metrics and recompute the routing tables on a frequent basis. dynamic metrics and recompute the routing tables on a frequent basis.
skipping to change at page 6, line 12 skipping to change at page 6, line 12
this comes with a cost, namely, reduced metric accuracy. Reliability this comes with a cost, namely, reduced metric accuracy. Reliability
is an example of qualitative parameters which may be used as a is an example of qualitative parameters which may be used as a
routing metric by RPL. Such qualitative parameters may be routing metric by RPL. Such qualitative parameters may be
transformed to quantitative values. In other cases, a set of flags transformed to quantitative values. In other cases, a set of flags
may be defined to reflect a node state without having to define may be defined to reflect a node state without having to define
discrete values. discrete values.
Some link or node characteristics (e.g. link reliability flag, energy Some link or node characteristics (e.g. link reliability flag, energy
remaining on the node) may either be used by RPL as routing remaining on the node) may either be used by RPL as routing
constraints or metric. For example, the path may be computed to constraints or metric. For example, the path may be computed to
avoid link that do not provide a sufficient level of reliability (use avoid links that do not provide a sufficient level of reliability
as a constraint) or as the path offering the maximum number of links (use as a constraint) or as the path offering the maximum number of
with a specified reliability level (use as a metric). links with a specified reliability level (use as a metric).
It is not required to use all the metrics and attributes specified in It is not required to use all the metrics and attributes specified in
this document. The set of routing metrics and constraints used by an this document. The set of routing metrics and constraints used by an
RPL implementation is signalled along the Directed Acyclic Graph RPL implementation is signalled along the Directed Acyclic Graph
(DAG) computed by RPL via an Objective Function (OF) as specified in (DAG) computed by RPL via an Objective Function (OF) as described in
[I-D.ietf-roll-rpl]. Indeed, RPL may be used to build DAGs with [I-D.ietf-roll-rpl]. Indeed, RPL may be used to build DAGs with
different charaterictics. For example, it may be desirable to build different characteristics. For example, it may be desirable to build
a DAG trying to maximize reliability by using the link reliability a DAG trying to maximize reliability by using the link reliability
metric: in this case, the OF advertised by RPL in the Dag Information metric: in this case, the OF advertised by RPL in the Dag Information
Option (DIO) message specifies an Objective Code Point (OCP) Option (DIO) message specifies an Objective Code Point (OCP)
indicating that the link reliability metric is the metric to use. indicating that the link reliability metric is the metric used to
Another example might be to use the energy node charateristic (e.g. compute the "best" path. Another example might be to use the energy
main powered versus battery operated) as a node constraint when node characteristic (e.g. main powered versus battery operated) as a
building the DAG so as to avoid battery powered nodes in the DAG. node constraint when building the DAG so as to avoid battery powered
Links and nodes routing metrics and constraints are not exclusive. nodes in the DAG. Links and nodes routing metrics and constraints
are not exclusive.
The requirements on reporting frequency may differ among metrics, The requirements on reporting frequency may differ among metrics,
thus different reporting rates may be used for each category. thus different reporting rates may be used for each category.
The specification of the objective function used to compute the path The specification of objective functions used to compute the DAG
is out of the scope of this document. built by RPL is out of the scope of this document and will be
specified in other documents.
Some metrics are either aggregated or recorded. In the former case, Some metrics are either aggregated or recorded. In the former case,
the metric is adjusted as the DIO message travels along the DAG. For the metric is adjusted as the DIO message travels along the DAG. For
example, if the metric is the link latency, each node updates the example, if the metric is the link latency, each node updates the
latency metric along the DAG. By contrast, metric may be recorded in latency metric along the DAG. By contrast, metric may be recorded in
which case each node adds a sub-object reflecting the local metric. which case each node adds a sub-object reflecting the local metric.
For example, it might be desirable to record the link quality level For example, it might be desirable to record the link quality level
along the path. In this case, each visited node adds a sub-object along the path. In this case, each visited node adds a sub-object
reporting the local link quality level. In order to limit the number reporting the local link quality level. In order to limit the number
of sub-objects, the use of a counter may be desirable (e.g. record of sub-objects, the use of a counter may be desirable (e.g. record
the number of links with a certain link quality level). Upon the number of links with a certain link quality level). Upon
receiving the DIO message from a set of parents, a node can decide receiving the DIO message from a set of parents, a node can decide
which node to choose as a parent based on the maximum number of links which node to choose as a parent based on the maximum number of links
with a specific link relaiblity level for example. with a specific link reliability level for example.
Notion of local versus global metric: some routing objects may have a Notion of local versus global metric: some routing objects may have a
local or a global significance. In the former case, a metric may be local or a global significance. In the former case, a metric may be
transmitted to a neighbor to charaterize a link or a node as opposed transmitted to a neighbor to charaterize a link or a node as opposed
to a path. For example, a node may report information about its to a path. For example, a node may report information about its
local energy without the need to propagate the energy level of all local energy without the need to propagate the energy level of all
nodes along the path. In contrast, other metrics such as link nodes along the path. In contrast, other metrics such as link
latency metrics are cumulative and global in the sense that they latency metrics are cumulative and global in the sense that they
charaterize a path cost using the latency as a metric. In this characterize a path cost using the latency as a metric. In this
particular example the delay is an aggregated global and cummulative particular example the delay is an aggregated global and cumulative
link metric. link metric.
2. Object Formats 2. Object Formats
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]. Container object defined in [I-D.ietf-roll-rpl].
0 1 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 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Type=2 |Container Len | DAG Metric data ... | Type=2 | Container Len | DAG Metric data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 1: DAG Metric Container Format Figure 1: DAG Metric Container Format
Routing metrics and constraints have a common format consisting of Routing metrics and constraints have a common format consisting of
one or more 8-bit words with a common header: one or more 8-bit words 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-Ob-Type|Res|R|G| A |O|C| Object Length (bytes) | |Routing-Ob-Type|Res|R|G| A |O|C| Object Length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (Object body) // // (Object body) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Routing Metric/Constraint common header format Figure 2: Routing Metric/Constraint common header format
The object body carries one or more sub-objects. The object body carries one or more sub-objects.
Note that the routing metric objects defined in this document can Note that the routing metric objects defined in this document can
appear in any order in the DAG Metric Container object. appear in any order in the DAG Metric Container object with the
exception of the Objective Function object that MUST appear first.
Routing-Ob-Type: (Routing Object Type - 8 bits): the Routing Object Routing-Ob-Type: (Routing Object Type - 8 bits): the Routing Object
Type field uniquely identifies each Routing object and is managed by Type field uniquely identifies each Routing object and is managed by
IANA. IANA.
Res flags (4 bits). Reserved field. This field MUST be set to zero Res flags (2 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.
o C Flag. When set, this indicates that the routing object refers o C Flag. When set, this indicates that the routing object refers
to a routing constraint. When cleared the routing object refers to a routing constraint. When cleared the routing object refers
to a routing metric. to a routing metric.
o O Flag: The O flag is used exclusively for routing constraints (C o O Flag: The O flag is used exclusively for routing constraints (C
flag is set) and has no meaning for routing metrics. When set, flag is set) and has no meaning for routing metrics. When set,
this indicates that the constraint is optional. When cleared, the this indicates that the constraint is optional. When cleared, the
constraint is mandatory. constraint is mandatory.
skipping to change at page 8, line 29 skipping to change at page 8, line 30
* A=0x00: The routing metric is additive * A=0x00: The routing metric is additive
* A=0x01: The routing metric reports a maximum * A=0x01: The routing metric reports a maximum
* A=0x02: The routing metric reports a minimum * A=0x02: The routing metric reports a minimum
o G Flag: When set, the routing object is global. When cleared it o G Flag: When set, the routing object is global. When cleared it
is local (see details below). is local (see details below).
o R Fag: The R flag is only relevant for global routing metric (C=0 o R Fag: The R Flag is only relevant for global routing metric (C=0
and G=1) and MUST be cleared for all other values of C and G. When and G=1) and MUST be cleared for all other values of C and G. When
set, this indicates that the routing metric is recorded along the set, this indicates that the routing metric is recorded along the
path. Conversely, when cleared the routing metric is aggregated. path. Conversely, when cleared the routing metric is aggregated.
The A field has no meaning when the C Flag is set (i.e. the routing The A field has no meaning when the C Flag is set (i.e. the routing
object refers to a routing constraint). object refers to a routing constraint).
Example 1: A DAG formed by RPL where all nodes must be main powered Example 1: A DAG formed by RPL where all nodes must be main powered
and the link metric is the link throughput. In this case the DAG and the link metric is the link throughput. In this case the DAG
Metric container carries two routing objects: the link metric is the Metric container carries two routing objects: the link metric is the
link throughput (C=0, O=0, A=00, G=1, R=0) and the node constraint is link throughput (C=0, O=0, A=00, G=1, R=0) and the node constraint is
power (C=1, O=0, A=00, G=0, R=0). Note that in this example, the power (C=1, O=0, A=00, G=0, R=0). Note that in this example, the
link throughput is a global additive aggegated link metric. An RPL link throughput is a global additive aggregated link metric. An RPL
implementation may use the metric to report a minimum (A=01). In implementation may use the metric to report a minimum (A=01). In
this case, when the link throughput metric is processed each node this case, when the link throughput metric is processed each node
updates it is the link throughput is less than the value reported by updates it is the link throughput is less than the value reported by
the link throughput metric. the link throughput metric.
Example 2: A DAG formed by RPL where the link metric is the link Example 2: A DAG formed by RPL where the link metric is the link
quality level and link quality levels must be recorded along the quality level and link quality levels must be recorded along the
path. In this case the DAG Metric container carries one routing path. In this case the DAG Metric container carries one routing
object: the link quality level (C=0, O=0, A=00, G=1, R=1). object: the link quality level (C=0, O=0, A=00, G=1, R=1).
skipping to change at page 9, line 16 skipping to change at page 9, line 17
encoded data sets. Each Routing TLV has the same structure: encoded data sets. Each Routing TLV has the same structure:
Type: 2 bytes Type: 2 bytes
Length: 2 bytes Length: 2 bytes
Value: variable Value: variable
A Routing metric TLV is comprised of 2 bytes for the type, 2 bytes A Routing metric TLV is comprised of 2 bytes for the type, 2 bytes
specifying the TLV length, and a value field. specifying the TLV length, and a value field.
The Length field defines the length of the value portion in bytes. The Length field defines the length of the value portion in bytes.
The TLV is padded to 4-bytes alignment; padding is not included in
the Length field (so a three byte value would have a length of three,
but the total size of the TLV would be eight bytes).
Unrecognized TLVs MUST be ignored. Unrecognized TLVs MUST be ignored.
IANA management of the routing metric objects identifier codespace is IANA management of the routing metric objects identifier codespace is
described in Section 8. described in Section 9.
3. Node Metrics And Constraints Objects 3. Node Metrics And Constraints Objects
It is fairly common for LLNs to be made of nodes with heterogeneous It is fairly common for LLNs to be made of nodes with heterogeneous
attributes and capabilities (e.g. nodes being battery operated or attributes and capabilities (e.g. nodes being battery operated or
not, amount of memory, etc). More capable and stable nodes may not, amount of memory, etc). More capable and stable nodes may
assist the most constrained ones for routing packets, which results assist the most constrained ones for routing packets, which results
in extension of network lifetime and efficient network operations. in extension of network lifetime and efficient network operations.
This is a typical use of constraint-based routing where the computed This is a typical use of constraint-based routing where the computed
path may not be the shortest path according to some specified path may not be the shortest path according to some specified
skipping to change at page 10, line 17 skipping to change at page 10, line 17
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 format Figure 3: NSA Object format
Node workload may be hard to determine and express in some scalar Node workload may be hard to determine and express in some scalar
form. However, node workload could be a useful metric to consider form. However, node workload could be a useful metric to consider
during path calculation, in particular when queuing delays must be during path calculation, in particular when queuing delays must be
minimized for highly sensitive traffic considering Meduim Access minimized for highly sensitive traffic considering Medium Access
Control (MAC) layer delay. Node workload MAY be set upon CPU Control (MAC) layer delay. Node workload MAY be set upon CPU
overload, lack of memory or any other node related condditions. overload, lack of memory or any other node related conditions. Using
Using a simple 1-bit flag to characterize the node workload provides a simple 1-bit flag to characterize the node workload provides a
a sufficient level of granularity, similarly to the "overload" bit sufficient level of granularity, similarly to the "overload" bit used
used in routing protocols such as IS-IS. Algorithms used to set the in routing protocols such as IS-IS. Algorithms used to set the
overload bit and to compute path to potentially avoid node with their overload bit and to compute path to potentially avoid node with their
overload bit set are outside the scope of this document. overload bit set are outside the scope of this document.
Data Aggregation Attribute: data fusion involves more complicated Data Aggregation Attribute: data fusion involves more complicated
processing to improve accuracy of the output data while data processing to improve accuracy of the output data while data
aggregation mostly aims at reducing the amount of data. This is aggregation mostly aims at reducing the amount of data. This is
listed as a requirement in Section 6.2 of [RFC5548]. Some listed as a requirement in Section 6.2 of [RFC5548]. Some
applications may make use of the aggregation node attribute in their applications may make use of the aggregation node attribute in their
routing decision so as to minimize the amount of traffic on the routing decision so as to minimize the amount of traffic on the
network, thus potentially increasing its life time in battery network, thus potentially increasing its life time in battery
skipping to change at page 11, line 14 skipping to change at page 11, line 14
3.2. Node Energy Object 3.2. Node Energy Object
Whenever possible, a node with low residual energy should not be Whenever possible, a node with low residual energy should not be
selected as a router, thus the support for constrained-based routing selected as a router, thus the support for constrained-based routing
is needed. In such cases, the routing protocol engine may compute a is needed. In such cases, the routing protocol engine may compute a
longer path (constraint based) for some traffic in order to increase longer path (constraint based) for some traffic in order to increase
the network life duration. the network life duration.
The routing engine may prefer a "longer" path that traverses mains- The routing engine may prefer a "longer" path that traverses mains-
powered nodes or nodes equipped with energy scavening, rather than a powered nodes or nodes equipped with energy scavenging, rather than a
"shorter" path through battery operated nodes. "shorter" path through battery operated nodes.
Power and energy are clearly critical resources in LLNs. As yet Power and energy are clearly critical resources in LLNs. As yet
there are no simple abstractions which adequately cover the broad there are no simple abstractions which adequately cover the broad
range of power sources and energy storage devices used in existing range of power sources and energy storage devices used in existing
LLN nodes. These include line-power, primary batteries, energy- LLN nodes. These include line-power, primary batteries, energy-
scavengers, and a variety of secondary storage mechanisms. scavengers, and a variety of secondary storage mechanisms.
Scavengers may provide a reliable low level of power, such as might Scavengers may provide a reliable low level of power, such as might
be available from a 4-20mA loop; a reliable but periodic stream of be available from a 4-20mA loop; a reliable but periodic stream of
power, such as provided by a well-positioned solar cell; or power, such as provided by a well-positioned solar cell; or
skipping to change at page 14, line 27 skipping to change at page 14, line 27
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
be only one HP object per DAG Metric Container object. be only one HP object per DAG Metric Container object.
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 TLVs are currently defined. node characteristics. No TLVs are 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 HP routing metric object is a global routing object that The HP routing metric object is a global routing object that
charaterizes a path. characterizes a path.
The format of the Hop Count object body is as follows: The format of the Hop Count 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 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 | Hops Count | Optional TLVs | Res | Flags | Hop Count | Optional TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 6: Hop Count Object format Figure 6: Hop Count Object format
No Flags are currently defined. No Flags are currently defined.
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
a path may traverse. When that number is reached no other node can a path may traverse. When that number is reached no other node can
join that path. When used as a metric each visited node simply join that path. When used as a metric each visited node simply
skipping to change at page 15, line 23 skipping to change at page 15, line 23
change in power consumption. For efficient operation, it may be change in power consumption. For efficient operation, it may be
desirable for nodes to report the range of throughput that their desirable for nodes to report the range of throughput that their
links can handle in addition to the currently available throughput. links can handle in addition to the currently available throughput.
The Throughput object MAY be present in the DAG Metric Container. The Throughput object MAY be present in the DAG Metric Container.
There MUST be only one Throughput object per DAG Metric Container There MUST be only one Throughput object per DAG Metric Container
object. object.
The Throughput object is made of throughput sub-objects and MUST as The Throughput object is made of throughput sub-objects and MUST as
least comprise one Throughput sub-object. Each Throughput sub-object least comprise one Throughput sub-object. Each Throughput sub-object
has a fixed lenght of 4 bytes. 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 Throughput Object is a global metric. The Throughput Object is a global metric.
The format of the Throughput object body is as follows: The format of the Throughput object body is as follows:
skipping to change at page 16, line 24 skipping to change at page 16, line 24
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 8: Throughput Sub-object format Figure 8: Throughput Sub-object format
Throughput: 32 bits. The Throughput is encoded in 32 bits in IEEE Throughput: 32 bits. The Throughput is encoded in 32 bits in IEEE
floating point format (see [IEEE.754.1985]), expressed in bytes per floating point format (see [IEEE.754.1985]), expressed in bytes per
second. Refer to Section 3.1.2 of [RFC3741] for a table of commonly second. Refer to Section 3.1.2 of [RFC3471] for a table of commonly
used values. used values.
The throughput object may be used as a constraint or a path metric.
For example, an OF may indicate that the throughput must be at least
equal to some values. In this case, the throughput common header
indicates that the values relates to a constraint with a miminum
value. In another example, the throughput object may be used as an
aggregated minimum metric where the value is updated along the path
to reflect to minimum value along the path. In yet another example,
the list of throughputs of the links traversed along the path may be
recorded.
4.2. Latency 4.2. Latency
Similarily to throughput, the latency of many LLN MAC sub-layers can Similarly to throughput, the latency of many LLN MAC sub-layers can
be varied over many orders of magnitude, again with a corresponding be varied over many orders of magnitude, again with a corresponding
change in current consumption. Some LLN MAC link layers will allow change in current consumption. Some LLN MAC link layers will allow
the latency to be adjusted globally on the subnet, or on a link-by- the latency to be adjusted globally on the subnet, or on a link-by-
link basis, or not at all. Some will insist that it be fixed for a link basis, or not at all. Some will insist that it be fixed for a
given link, but allow it to be variable from link to link. given link, but allow it to be variable from link to link.
The Latency object MAY be present in the DAG Metric Container. There The Latency object MAY be present in the DAG Metric Container. There
MUST be only one Latency object per DAG Metric Container object. MUST be only one Latency object per DAG Metric Container object.
The Latency object is made of Latency sub-objects and MUST as least The Latency object is made of Latency sub-objects and MUST as least
comprise one Latency sub-object. Each Latency sub-object has a fixed comprise one Latency sub-object. Each Latency sub-object has a fixed
lenght of 4 bytes. length of 4 bytes.
The Latency object does not contain any additional TLV. The Latency object does not contain any additional TLV.
The Latency object Type is to be assigned by IANA (recommended The Latency object Type is to be assigned by IANA (recommended
value=5) value=5)
The Latency Object is a global metric or constraint. The Latency Object is a global metric or constraint.
The format of the Latency object body is as follows: The format of the Latency object body is as follows:
skipping to change at page 17, line 32 skipping to change at page 17, line 25
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 10: Latency Sub-object format Figure 10: Latency Sub-object format
Latency: 32 bits. The Latency is encoded in 32 bits in IEEE floating Latency: 32 bits. The Latency is encoded in 32 bits in IEEE floating
point format (see [IEEE.754.1985]), expressed in milliseconds. Refer point format (see [IEEE.754.1985]), expressed in milliseconds. Refer
to Section 3.1.2 of [RFC3741] for a table of commonly used values. to Section 3.1.2 of [RFC3471] for a table of commonly used values.
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, an Objective Function may indicate that the latency must not example, an Objective Function may indicate that the latency must not
exceed some values. In this case, the latency object common header exceed some values. In this case, the latency object common header
indicates that the value relates to a constraint with a maximum indicates that the value relates to a constraint with a maximum
value. In another example, the latency object may be used as an value. In another example, the latency object may be used as an
aggregated addditive metric where the value is updated along the path aggregated additive metric where the value is updated along the path
to reflect to path latency. to reflect to path latency.
4.3. Link reliability 4.3. Link reliability
In LLNs, link reliability is degraded by external interference and In LLNs, link reliability is degraded by external interference and
multi-path interference. Multipath typically affects both directions multi-path interference. Multipath typically affects both directions
on the link equally, whereas external interference is sometimes uni- on the link equally, whereas external interference is sometimes uni-
directional. Time scales vary from milliseconds to days, and are directional. Time scales vary from milliseconds to days, and are
often periodic and linked to human activity. Packet error rates can often periodic and linked to human activity. Packet error rates can
generally be measured directly, and other metrics (e.g. bit error generally be measured directly, and other metrics (e.g. bit error
skipping to change at page 18, line 33 skipping to change at page 18, line 25
quality level. The mechanisms and algorithms used to compute the LQL quality level. The mechanisms and algorithms used to compute the LQL
is implementation specific and outside of the scope of this document. is implementation specific and outside of the scope of this document.
The LQL is global and can either be used as a metric or a constraint. The LQL is global and can either be used as a metric or a constraint.
When used as a metric, the LQL metric can be recorded or aggregated. When used as a metric, the LQL metric can be recorded or aggregated.
For example, the DAG may require to record the LQL for all traversed For example, the DAG may require to record the LQL for all traversed
links. Each node can then use the LQL to select the parent based on links. Each node can then use the LQL to select the parent based on
user defined rules (e.g. "select the path with the maximum number of user defined rules (e.g. "select the path with the maximum number of
links reporting a LQL value of 3"). By contrast the LQL link metric links reporting a LQL value of 3"). By contrast the LQL link metric
may be aggregated in which case, the sum of all LQL may be reported may be aggregated in which case, the sum of all LQL may be reported
(additive metric) or the mimimum value may be reported along the (additive metric) or the minimum value may be reported along the
path. path.
When used as a recorded metric, a counter is used to compress the When used as a recorded metric, a counter is used to compress the
information where the number of links for each LQL is reported. information where the number of links for each LQL 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 be only one LQL object with at least one LQL sub-object per DAG MUST be only one LQL object with at least one LQL sub-object per DAG
Metric Container object. Metric Container object.
The LQL object contains one or more sub-object used to report the The LQL object contains one or more sub-object used to report the
skipping to change at page 19, line 39 skipping to change at page 19, line 39
Counter: number of links. Counter: number of links.
When the LQL metric is aggregated, the LQL object body comprises one When the LQL metric is aggregated, the LQL object body comprises one
LQL Type 2 sub-object: LQL Type 2 sub-object:
The format of the LQL Type 2 sub-object is as follows The format of the LQL Type 2 sub-object 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Aggregated LQL Vaue | Aggregated LQL Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: LQL Type 2 sub-Object format Figure 13: LQL Type 2 sub-Object format
Aggregated LQL Value: when used an an additive metric (A=0x00), the Aggregated LQL Value: when used an an additive metric (A=0x00), the
aggregated LQL value reports the sum of all the LQL values for all 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 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. field reports the minimum LQL value of all links along the path.
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 defined as 1 / (Df * The Expected Transmission Count (ETX) metric is the number of
Dr) where Df is the measured probability that a packet is received by transmissions a node expects to make to a destination in order to
the neighbor and Dr is the measured probability that the successfully deliver a packet.
acknowledgment packet is successfully received.
For example, an implementation may use the following formula: ETX= 1
/ (Df * Dr) where Df is the measured probability that a packet is
received by the neighbor and Dr is the measured probability that the
acknowledgment packet is successfully received. This document does
not mandate the use of a specific formula to comput the ETX value.
The ETX object MAY be present in the DAG Metric Container. There The ETX object MAY be present in the DAG Metric Container. There
MUST be only one ETX object per DAG Metric Container object. MUST be only one ETX object per DAG Metric Container object.
The ETX object is made of ETX sub-objects and MUST as least comprise The ETX object is made of ETX sub-objects and MUST as least comprise
one ETX sub-object. Each ETX sub-object has a fixed lenght of 8 one ETX sub-object. Each ETX sub-object has a fixed length of 8
bits. bits.
The ETX object does not contain any additional TLV. The ETX object does not contain any additional TLV.
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 ETX object is a global metric or constraint. The ETX object is a global metric or constraint.
The format of the Latency object body is as follows: The format of the Latency object body is as follows:
skipping to change at page 20, line 38 skipping to change at page 20, line 43
Figure 14: ETX Object Body Format Figure 14: ETX Object Body Format
0 1 0 1
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| ETX | | ETX |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 15: ETX Sub-object format Figure 15: ETX Sub-object format
ETX: 8 bits. The Latency is encoded in 32 bits in IEEE floating ETX: 8 bits. The ETX is encoded in 8 bits in IEEE floating point
point format (see [IEEE.754.1985]). Refer to Section 3.1.2 of format (see [IEEE.754.1985]). Refer to Section 3.1.2 of [RFC3471]
[RFC3741] for a table of commonly used values. for a table of commonly used values.
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, an Objective Function may indicate that the ETX must not be example, an Objective Function may indicate that the ETX must not be
below some specified value. In this case, the ETX object common below some specified value. In this case, the ETX object common
header indicates that the value relates to a constraint with a header indicates that the value relates to a constraint with a
minimum value. In another example, the ETX object may be used as an minimum value. In another example, the ETX object may be used as an
aggregated addditive metric where the value is updated along the path aggregated additive metric where the value is updated along the path
to reflect to path quality. to reflect to path quality.
4.4. Link Color Object 4.4. Link Color Object
4.4.1. Link Color Object Description 4.4.1. Link Color Object Description
The Link Color (LC) object is an administrative 10-bit static link The Link Color (LC) object is an administrative 10-bit static link
constraint used to avoid or attract specific links for specific constraint used to avoid or attract specific links for specific
traffic types. traffic types.
skipping to change at page 23, line 15 skipping to change at page 23, line 15
5. Computation of Dynamic Metrics and Attributes 5. Computation of Dynamic Metrics and Attributes
As already pointed out, dynamically calculated metrics are of the As already pointed out, dynamically calculated metrics are of the
utmost importance in many circumstances in LLNs. This is mainly utmost importance in many circumstances in LLNs. This is mainly
because a variety of metrics change on a frequent basis, thus because a variety of metrics change on a frequent basis, thus
implying the need to adapt the routing decisions. That being said, implying the need to adapt the routing decisions. That being said,
care must be given to the pace at which changes are reported in the care must be given to the pace at which changes are reported in the
network. The attributes will change according to their own time network. The attributes will change according to their own time
scales. RPL controls the reporting rate. scales. RPL controls the reporting rate.
To minimize metric updates, multi-threshhold algorithms MAY be used To minimize metric updates, multi-threshold algorithms MAY be used to
to determine when updates should be sent. When practical, a low-pass determine when updates should be sent. When practical, a low-pass
filter should be used to avoid rapid fluctuations of these values. filter should be used to avoid rapid fluctuations of these values.
Finally, although the specification of path computation algorithms Finally, although the specification of path computation algorithms
using dynamic metrics are out the scope of this document, the using dynamic metrics are out the scope of this document, the
objective function should be designed carefully to avoid too frequent objective function should be designed carefully to avoid too frequent
computation of new routes upon metric values changes. computation of new routes upon metric values changes.
Controlled adaptation of the routing metrics and rate at which paths Controlled adaptation of the routing metrics and rate at which paths
are computed are critical to avoid undesirable routing instabilities are computed are critical to avoid undesirable routing instabilities
resulting in increased latencies and packet loss because of temporary resulting in increased latencies and packet loss because of temporary
micro-loops. Furthermore, excessive route changes will impact the micro-loops. Furthermore, excessive route changes will impact the
traffic and power consumption in the network adversely. traffic and power consumption in the network adversely.
6. Open Issues 6. Objective Function
The Objective Function (OF) is used by RPL to specify how the routing
metric and constraints should be used to reach specific objectives.
For example, the OF may specify that the objective is to find the
constrained shortest path where the constraint is related to the node
power mode and the metric is the ETX (e.g. "Avoid battery operated
links and compute the path that optimizes reliability"). As
specified in [I-D.ietf-roll-rpl], the OF is used by a node to select
its parent during the DAG building construction process.
The OCP object is used to specify the OF and is carried within the
DAG Metric Container object defined in [I-D.ietf-roll-rpl].
There MUST be a single instance of the OCP object within the DAG
Metric Container object.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| OCP | (TLVs)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 19: OCP Object Format
The OCP object is not preceded by the common header specified for the
routing and metric objects.
The OCP object body may carry optional TLVs. No TLVs are currently
defined.
OCP (Objective Code Point - 16 bits): the OCP field identifies the OF
and is managed by IANA.
7. Open Issues
Other items to be addressed in further revisions of this document Other items to be addressed in further revisions of this document
include: include:
6.1. Other metric under consideration 7.1. Other metric under consideration
Metrics related to security (e.g. capability to avoid a node that has Metrics related to security (e.g. capability to avoid a node that has
not been authorized or authenticated). not been authorized or authenticated).
7. Metric Consistency 8. Metric Consistency
Since a set of metrics and constraints will be used for links and Since a set of metrics and constraints will be used for links and
nodes in LLN, it is particularly critical to ensure the use of nodes in LLN, it is particularly critical to ensure the use of
consistent metric calculation mechanisms for all links and nodes in consistent metric calculation mechanisms for all links and nodes in
the network. the network.
8. IANA Considerations 9. IANA Considerations
IANA is requested to establish a new top-level registry to contain IANA is requested to establish a new top-level registry to contain
all Routing Objects codepoints and sub-registries. all Routing Objects codepoints and sub-registries.
The allocation policy for each new registry is by IETF Consensus: new The allocation policy for each new registry is by IETF Consensus: new
values are assigned through the IETF consensus process (see values are assigned through the IETF consensus process (see
[RFC5226]). Specifically, new assignments are made via RFCs approved [RFC5226]). Specifically, new assignments are made via RFCs approved
by the IESG. Typically, the IESG will seek input on prospective by the IESG. Typically, the IESG will seek input on prospective
assignments from appropriate persons (e.g., a relevant Working Group assignments from appropriate persons (e.g., a relevant Working Group
if one exists). if one exists).
8.1. Routing Objects 9.1. Routing Objects
IANA is requested to create a registry for Routing objects. Each IANA is requested to create a registry for Routing objects. Each
Routing object has a Routing object type value. Routing object has a Routing object type value.
Value Meaning Reference Value Meaning Reference
1 Node State and Attribute This document 1 Node State and Attribute This document
2 Node Energy This document 2 Node Energy This document
3 Hop Count This document 3 Hop Count This document
4 Link Throughput This document 4 Link Throughput This document
5 Link Latency This document 5 Link Latency This document
6 Link Quality Level This document 6 Link Quality Level This document
7 Link ETX This document 7 Link ETX This document
8 Link Color This document 8 Link Color This document
8.2. Routing Object Common Header 9.2. Routing Object Common Header
IANA is requested to create a registry to manage the codespace of A IANA is requested to create a registry to manage the codespace of A
field and the Flag field of the Routing Common header. field and the Flag field of the Routing Common header.
Codespace of the A field (NSA Object) Codespace of the A field (NSA Object)
Value Meaning Reference Value Meaning Reference
0 Routing metric is additive This document 0 Routing metric is additive This document
2 Routing metric reports a maximimum This document 2 Routing metric reports a maximum This document
3 Routing metric reports a minimum This document 3 Routing metric reports a minimum This document
IANA is requested to create a registry to manage the Flag field of IANA is requested to create a registry to manage the Flag field of
the Routing metric common header. the Routing metric common header.
New bit numbers may be allocated only by an IETF Consensus action. New bit numbers may be allocated only by an IETF Consensus action.
Each bit should be tracked with the following qualities: Each bit should be tracked with the following qualities:
o Bit number o Bit number
skipping to change at page 25, line 14 skipping to change at page 26, line 14
Codespace of the Flag field (Routing common header) Codespace of the Flag field (Routing common header)
Bit Description Reference Bit Description Reference
8 Constraint/metric This document 8 Constraint/metric This document
7 Optional Constraint This document 7 Optional Constraint This document
5-6 Additive/Max/Min This document 5-6 Additive/Max/Min This document
4 Global/Local This document 4 Global/Local This document
3 Recorded/Aggregated This document 3 Recorded/Aggregated This document
8.3. NSA Object 9.3. NSA Object
IANA is requested to create a registry to manage the codespace of the IANA is requested to create a registry to manage the codespace of the
Flag field of the NSA Object. Flag field of the NSA Object.
New bit numbers may be allocated only by an IETF Consensus action. New bit numbers may be allocated only by an IETF Consensus action.
Each bit should be tracked with the following qualities: Each bit should be tracked with the following qualities:
o Bit number o Bit number
o Capability Description o Capability Description
o Defining RFC o Defining RFC
Several bits are defined for the NSA Object flag field in this Several bits are defined for the NSA Object flag field in this
document. The following values have been assigned: document. The following values have been assigned:
Codespace of the Flag field (RP Object) Codespace of the Flag field (RP Object)
Bit Description Reference Bit Description Reference
14 Aggegrator This document 14 Aggregator This document
15 Overloaded This document 15 Overloaded This document
8.4. Hop-count Object 9.4. Hop-count Object
IANA is requested to create a registry to manage the codespace of the IANA is requested to create a registry to manage the codespace of the
Flag field of the Hop-count Object. Flag field of the Hop-count Object.
New bit numbers may be allocated only by an IETF Consensus action. New bit numbers may be allocated only by an IETF Consensus action.
Each bit should be tracked with the following qualities: Each bit should be tracked with the following qualities:
o Bit number o Bit number
o Capability Description o Capability Description
o Defining RFC o Defining RFC
No Flags are currently defined. No Flags are currently defined.
9. Security Considerations 9.5. Objective Code Point (OCP) Object
IANA is requested to create a registry to manage the codespace of the
OCP field of the OCP object.
No OCP codepoints are defined in this specification.
10. Security Considerations
Routing metrics should be handled in a secure and trustful manner. Routing metrics should be handled in a secure and trustful manner.
For instance, a malicious node can not advertise falsely that it has For instance, a malicious node can not advertise falsely that it has
good metrics for routing and belong to the established path to have a good metrics for routing and belong to the established path to have a
chance to intercept packets. chance to intercept packets.
10. Acknowledgements 11. Acknowledgements
The authors would like to acknowledge the contributions of YoungJae The authors would like to acknowledge the contributions of Young Jae
Kim, David Meyer, Mischa Dohler, Anders Brandt, Philip Levis, Pascal Kim, David Meyer, Mischa Dohler, Anders Brandt, Philip Levis, Pascal
Thubert, Richard Kelsey, Jonathan Hui and Phil Levis for their review Thubert, Richard Kelsey, Jonathan Hui, Phil Levis and Tim Winter for
and comments. their review and comments.
11. References 12. References
11.1. Normative References 12.1. Normative References
[I-D.ietf-roll-rpl] [I-D.ietf-roll-rpl]
Winter, T., Thubert, P., and R. Team, "RPL: Routing Winter, T., Thubert, P., and R. Team, "RPL: Routing
Protocol for Low Power and Lossy Networks", Protocol for Low Power and Lossy Networks",
draft-ietf-roll-rpl-03 (work in progress), October 2009. draft-ietf-roll-rpl-03 (work in progress), October 2009.
[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.
11.2. Informative References 12.2. Informative References
[I-D.ietf-roll-building-routing-reqs] [I-D.ietf-roll-building-routing-reqs]
Martocci, J., Riou, N., Mil, P., and W. Vermeylen, Martocci, J., Riou, N., Mil, P., and W. Vermeylen,
"Building Automation Routing Requirements in Low Power and "Building Automation Routing Requirements in Low Power and
Lossy Networks", draft-ietf-roll-building-routing-reqs-07 Lossy Networks", draft-ietf-roll-building-routing-reqs-07
(work in progress), September 2009. (work in progress), September 2009.
[I-D.ietf-roll-home-routing-reqs] [I-D.ietf-roll-home-routing-reqs]
Brandt, A., Buron, J., and G. Porcu, "Home Automation 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",
draft-ietf-roll-home-routing-reqs-08 (work in progress), draft-ietf-roll-home-routing-reqs-08 (work in progress),
September 2009. September 2009.
[I-D.ietf-roll-indus-routing-reqs]
Networks, D., Thubert, P., Dwars, S., and T. Phinney,
"Industrial Routing Requirements in Low Power and Lossy
Networks", draft-ietf-roll-indus-routing-reqs-06 (work in
progress), June 2009.
[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-02 (work in Networks", draft-ietf-roll-terminology-02 (work in
progress), October 2009. progress), October 2009.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990. dual environments", RFC 1195, December 1990.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS", McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999. RFC 2702, September 1999.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3741] Boyer, J., Eastlake, D., and J. Reagle, "Exclusive XML [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
Canonicalization, Version 1.0", RFC 3741, March 2004. (GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
"Routing Requirements for Urban Low-Power and Lossy "Routing Requirements for Urban Low-Power and Lossy
Networks", RFC 5548, May 2009. Networks", RFC 5548, May 2009.
11.3. References [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney,
"Industrial Routing Requirements in Low-Power and Lossy
Networks", RFC 5673, October 2009.
12.3. References
[IEEE.754.1985] [IEEE.754.1985]
IEEE Standard 754, "Standard for Binary Floating-Point IEEE Standard 754, "Standard for Binary Floating-Point
Arithmetic", August 1985. Arithmetic", August 1985.
Authors' Addresses Authors' Addresses
JP Vasseur (editor) JP Vasseur (editor)
Cisco Systems, Inc Cisco Systems, Inc
11, Rue Camille Desmoulins 11, Rue Camille Desmoulins
 End of changes. 68 change blocks. 
131 lines changed or deleted 168 lines changed or added

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