draft-ietf-roll-routing-metrics-09.txt   draft-ietf-roll-routing-metrics-10.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: March 9, 2011 Corporate Technology Group, KT Expires: April 22, 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
September 5, 2010 October 19, 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-09 draft-ietf-roll-routing-metrics-10
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 March 9, 2011. This Internet-Draft will expire on April 22, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Object formats . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Object formats . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Node Metric/Constraint objects . . . . . . . . . . . . . . . . 9 2.1. DAG Metric Container format . . . . . . . . . . . . . . . 7
3.1. Node State and Attributes object . . . . . . . . . . . . . 10 2.2. Use of multiple DAG Metric Containers . . . . . . . . . . 10
3.2. Node Energy object . . . . . . . . . . . . . . . . . . . . 11 2.3. Metric usage . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Hop-Count object . . . . . . . . . . . . . . . . . . . . . 14 3. Node Metric/Constraint objects . . . . . . . . . . . . . . . . 11
3.4. Node Fanout Ratio object . . . . . . . . . . . . . . . . . 15 3.1. Node State and Attributes object . . . . . . . . . . . . . 11
4. Link Metric/Constraint objects . . . . . . . . . . . . . . . . 16 3.2. Node Energy object . . . . . . . . . . . . . . . . . . . . 13
4.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 16 3.3. Hop-Count object . . . . . . . . . . . . . . . . . . . . . 16
4.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 17 4. Link Metric/Constraint objects . . . . . . . . . . . . . . . . 17
4.3. Link reliability . . . . . . . . . . . . . . . . . . . . . 18 4.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.1. The Link Quality Level reliability metric . . . . . . 19 4.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3. Link reliability . . . . . . . . . . . . . . . . . . . . . 19
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 . . . . . . . . . . . . . . . . . . . . . . . . 22
4.4. Link Color object . . . . . . . . . . . . . . . . . . . . 22 4.4. Link Color object . . . . . . . . . . . . . . . . . . . . 23
4.4.1. Link Color object description . . . . . . . . . . . . 22 4.4.1. Link Color object description . . . . . . . . . . . . 23
4.4.2. Mode of operation . . . . . . . . . . . . . . . . . . 24 4.4.2. Mode of operation . . . . . . . . . . . . . . . . . . 25
5. Computation of dynamic metrics and attributes . . . . . . . . 24 5. Computation of dynamic metrics and attributes . . . . . . . . 25
6. Use of multiple DAG Metric Container . . . . . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
7. Metric consistency . . . . . . . . . . . . . . . . . . . . . . 25 6.1. Routing Metric/Constraint type . . . . . . . . . . . . . . 26
8. Metric usage . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.2. Routing Metric/Constraint common header . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 6.3. NSA object . . . . . . . . . . . . . . . . . . . . . . . . 27
9.1. Routing Metric/Constraint type . . . . . . . . . . . . . . 26 6.4. Hop-Count object . . . . . . . . . . . . . . . . . . . . . 28
9.2. Routing Metric/Constraint common header . . . . . . . . . 27 7. Security considerations . . . . . . . . . . . . . . . . . . . 28
9.3. NSA object . . . . . . . . . . . . . . . . . . . . . . . . 27 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
9.4. Hop-Count object . . . . . . . . . . . . . . . . . . . . . 28 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10. Security considerations . . . . . . . . . . . . . . . . . . . 28 9.1. Normative references . . . . . . . . . . . . . . . . . . . 29
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 9.2. Informative references . . . . . . . . . . . . . . . . . . 29
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. Normative references . . . . . . . . . . . . . . . . . . . 29
12.2. Informative references . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
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], [RFC5673], [RFC5826] and that have been spelled out in [RFC5548], [RFC5673], [RFC5826] and
skipping to change at page 4, line 49 skipping to change at page 4, line 49
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 mains powered or links that have at least a minimum nodes that are mains 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
characteristic (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 cost. Link and nodes metrics are usually (but not the path cost. Link and node metrics are usually (but not always)
always) additive. additive.
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). It 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
o Qualitative versus quantitative o Qualitative versus quantitative
o Dynamic versus static o Dynamic versus static
It must be noted that the use of dynamic metrics is not new and has
been experimented in ARPANET 2 [Khanna1989], with moderate success.
The use of dynamic metrics is not trivial and great care must be
given to the use of dynamic metrics since it may lead to potential
routing instabilities. it must be noted that the use of dynamic
metrics has been largely experimented and deployed in a number of
(non IP) networks in the past decade.
As pointed out in various routing requirements documents (see As pointed out in various routing requirements documents (see
[RFC5673], [RFC5826] [RFC5548] and [RFC5867]), it must be possible to [RFC5673], [RFC5826] [RFC5548] and [RFC5867]), it must be possible to
take into account a variety of node constraints/metrics during path take into account a variety of node constraints/metrics during path
computation. computation.
Some link or node characteristics (e.g. link reliability flag,
remaining energy on the node) may either be used by RPL as routing
constraints or metrics. For example, the path may be computed to
avoid links that do not provide a sufficient level of reliability
(use as a constraint) or as the path offering most links with a
specified reliability level (use as a metric). The document provides
the flexibility to use link and node characterisics either as
constraints and/or metrics.
The use of link and node routing metrics and constraints is not
exclusive.
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 characteristics, 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 some links (e.g. wireless but in addition to the dynamic nature of some links (e.g. wireless but
also Poweline Communication (PLC) links, nodes' resources such as also Powerline Communication (PLC) links), nodes' resources such as
residual energy and other link's charatacteristics such as the residual energy and other link's characteristics such as the
throughput are changing continuously and may have to be taken into throughput are changing continuously and may have to be taken into
account during the path computation. Similarly, link attributes account during the path computation. Similarly, link attributes
including throughput and reliability may drastically change over time including throughput and reliability may drastically change over time
due to multi-path interference. due to multi-path interference.
It must be noted that the use of dynamic metrics is not new and has
been experimented in ARPANET 2 [Khanna1989], with moderate success.
The use of dynamic metrics is not trivial and great care must be
given to the use of dynamic metrics since it may lead to potential
routing instabilities. it must be noted that the use of dynamic
metrics has been largely experimented and deployed in a number of
(non IP) networks in the past decade.
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.
Therefore, it may be desirable to use a set of discrete values to Therefore, it may be desirable to use a set of discrete values to
reduce computational overhead and bandwidth utilization. Of course, reduce computational overhead and bandwidth utilization. Of course,
this comes with a cost, namely, reduced metric accuracy. In other this comes with a cost, namely, reduced metric accuracy. In other
cases, a set of flags may be defined to reflect a node state without cases, a set of flags may be defined to reflect a node state without
having to define discrete values. having to define discrete values.
Some link or node characteristics (e.g. link reliability flag, The requirements on reporting frequency may differ among metrics,
remaining energy on the node) may either be used by RPL as routing thus different reporting rates may be used for each category and are
constraints or metric. For example, the path may be computed to consequently implementation-specific.
avoid links that do not provide a sufficient level of reliability
(use as a constraint) or as the path offering the maximum number of
links with a specified reliability level (use as a metric). The
document provides the flexibility to use link and node charaterisics
either as constraints and/or metrics.
The set of routing metrics and constraints used by an RPL The set of routing metrics and constraints used by an RPL
implementation is signalled along the Directed Acyclic Graph (DAG) implementation is signaled along the Directed Acyclic Graph (DAG)
that is built according to the Objective Function (rules governing that is built according to the Objective Function (rules governing
how to build a DAG) and the routing metrics and constraints are how to build a DAG) and the routing metrics and constraints are
advertised in the DAG Information Option (DIO) message specified in advertised in the DAG Information Option (DIO) message specified in
[I-D.ietf-roll-rpl]. RPL may be used to build DAGs with different [I-D.ietf-roll-rpl]. RPL may be used to build DAGs with different
characteristics. For example, it may be desirable to build a DAG characteristics. For example, it may be desirable to build a DAG
with the goal to maximize reliability by using the link reliability with the goal to maximize reliability by using the link reliability
metric to compute the "best" path. Another example might be to use metric to compute the "best" path. Another example might be to use
the energy node characteristic (e.g. mains powered versus battery the energy node characteristic (e.g. mains powered versus battery
operated) as a node constraint when building the DAG so as to avoid operated) as a node constraint when building the DAG so as to avoid
battery powered nodes in the DAG while optimizing the link battery powered nodes in the DAG while optimizing the link
throughput. throughput.
Links and nodes routing metrics and constraints are not exclusive.
The requirements on reporting frequency may differ among metrics,
thus different reporting rates may be used for each category and are
consequently implementatin-specific.
The specification of objective functions used to compute the DAG The specification of objective functions used to compute the DAG
built by RPL is out of the scope of this document. Routing metrics built by RPL is out of the scope of this document. Routing metrics
and constraints are decoupled from the objective function. So a and constraints are decoupled from the objective function. So a
generic objective function could for example specify the rules to generic objective function could for example specify the rules to
select the best parents in the DAG, the number of backup parents, select the best parents in the DAG, the number of backup parents,
etc. Such objective function can be used with any routing metrics etc. Such objective function can be used with any routing metrics
and/or contraints such as the ones specified in this document. and/or constraints such as the ones specified in this document.
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, a metric may be recorded latency metric along the DAG. By contrast, a metric may be recorded
in which case each node adds a sub-object reflecting the local in which case each node adds a sub-object reflecting the local
metric. For example, it might be desirable to record the link metric. For example, it might be desirable to record the link
quality level along the path. In this case, each visited node adds a quality level along the path. In this case, each visited node adds a
sub-object reporting the local link quality level. In order to limit sub-object reporting the local link quality level. In order to limit
the number of sub-objects, the use of a counter may be desirable the number of sub-objects, the use of a counter may be desirable
(e.g. record the number of links with a certain link quality level), (e.g. record the number of links with a certain link quality level),
thus compressing the information to reduce the message lenght. Upon thus compressing the information to reduce the message length. 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
accoding to the OF and local policy which node to choose as a parent according to the OF and local policy which node to choose as a parent
based on the maximum number of links with a specific link reliability based on the maximum number of links with a specific link reliability
level for example. level, for example.
Note that the routing metrics are constrained specified in this Note that the routing metrics and constraints specified in this
document are not specific to any link layer. Internal API between document are not specific to any link layer. An internal API between
the MAC layer and RPL may advantageously be used to accurately the MAC layer and RPL may be used to accurately reflect the metrics
reflect the metrics values of the link (wireless, wired, PLC). values of the link (wireless, wired, PLC).
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
consistent metric calculation mechanisms for all links and nodes in
the network, similarly to the case of inter-domain IP routing.
2. Object formats 2. Object formats
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]. Container object defined in [I-D.ietf-roll-rpl]. Should multiple
metrics and/or constraints be present in the DAG Metric Container,
their use to determine the "best" path can be defined by an Objective
Function or a new TLV to be defined in future documents.
0 1 2 3 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 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 | Type=2 | Option Len | Routing Metric/Constraint objects
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Figure 1: DAG Metric Container format Figure 1: DAG Metric Container format
The Routing Metric/Contraints objects have a common format consisting The Routing Metric/Constraint objects have a common format consisting
of one or more 8-bit words with a common header: of 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-MC-Type| Flags |P|C|0|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 2: Routing Metric/Constraint object generic format
The object body carries one or more sub-objects. The object body carries one or more sub-objects.
Note that the Routing Metric/Constraint objects defined in this Note that the Routing Metric/Constraint objects defined in this
document can appear in any order in the DAG Metric Container. document can appear in any order in the DAG Metric Container.
Routing-MC-Type (Routing Metric/Contraint Type - 8 bits): the Routing Routing-MC-Type (Routing Metric/Constraint Type - 8 bits): the
Metric/Constraint Type field uniquely identifies each Routing Metric/ Routing Metric/Constraint Type field uniquely identifies each Routing
Constraint object and is managed by IANA. Metric/Constraint object and is managed by IANA.
Length: this field defines the length of the object body, in bytes. Length: this field defines the length of the object body, in bytes.
The Flag field of the Routing Metric/Constraint object is managed by The Flag field of the Routing Metric/Constraint object is managed by
IANA. Unassigned bits are considered as reserved. They MUST be set IANA. Unassigned bits are considered as reserved. They MUST be set
to zero on transmission and MUST be ignored on receipt. to zero on transmission and MUST be ignored on receipt.
o C Flag. When set, this indicates that the Routing Metric/ o C Flag. When set, this indicates that the Routing Metric/
Constraint object refers to a routing constraint. When cleared, Constraint object refers to a routing constraint. When cleared,
the routing object refers to a routing metric. the routing object refers to a routing metric.
skipping to change at page 8, line 46 skipping to change at page 9, line 14
* 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
* A=0x03: The routing metric is multiplicative * A=0x03: The routing metric is multiplicative
The A field has no meaning when the C Flag is set (i.e. when the The A field has no meaning when the C Flag is set (i.e. when the
Routing Metric/Constraint object refers to a routing constraint) Routing Metric/Constraint object refers to a routing constraint)
and MUST be written to 0x00. and MUST be written to 0x00.
o Prec field: The P field indicates the precedence of this Routing o Prec field: The Prec field indicates the precedence of this
Metric/Constraint object. This is useful when a DAG Metric Routing Metric/Constraint object. This is useful when a DAG
Container contains several Routing Metric objects. The value 0 Metric Container contains several Routing Metric objects. The
means the highest precedence. The precedence field can be used as value 0 means the highest precedence.
a tie-breaker in the presence of the multiple metrics advertising
the same value.
o P field: the P field is only used for recorded metric. When o P field: the P field is only used for recorded metrics. When
cleared, all nodes along the path managed to recorded the cleared, all nodes along the path successfully recorded the
corresponding link metric. When set, this indicates than one of corresponding metric. When set, this indicates than one or
more nodes along the path could not record the metric of interest several nodes along the path could not record the metric of
(either because of lack of knowledge or because this was prevented interest (either because of lack of knowledge or because this was
by policy). prevented by policy).
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 mains-powered
and the best path is the one with lower aggregated ETX. In this case and the best path is the one with lower aggregated ETX. In this case
the DAG Metric container carries two Routing Metric/Constraint the DAG Metric container carries two Routing Metric/Constraint
objects: one is an ETX metric object with header (C=0, O=0, A=00, objects: one is an ETX metric object with header (C=0, O=0, A=00,
R=0) and the second one is a Node Energy constraint with header (C=1, R=0) and the second one is a Node Energy constraint object with
O=0, A=00, R=0). Note that a RPL instance may use the metric object header (C=1, O=0, A=00, R=0). Note that a RPL instance may use the
to report a maximum (A=0x01) or a minimum (A=0x02). If the best path metric object to report a maximum (A=0x01) or a minimum (A=0x02).
is characterized by the path avoiding low quality links for example, If, for example, the best path is characterized by the path avoiding
then the path metric reports a maximum (A=0x01) (note that higher low quality links, then the path metric reports a maximum (A=0x01)
values mean lower link quality): when the link quality metric (ETX) (note that higher values mean lower link quality): when the link
is processed along a path, each node updates its value if the current quality metric (ETX) is processed along a path, each node updates the
link ETX value is higher than the value carried by the metric object. value carried in the metric object by replacing it with its local
link ETX value if and only if the latter is higher.
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 a Routing path. In this case, the DAG Metric Container carries a Routing
Metric/Constraint object: link quality level metric (C=0, O=0, A=00, Metric/Constraint object: link quality level metric (C=0, O=0, A=00,
R=1) containing multiple sub-objects. R=1) containing multiple sub-objects.
A Routing Metric/Constraint object may also include one or more type- A Routing Metric/Constraint object may also include one or more
length-value (TLV) encoded data sets. Each Routing Metric/Constraint type-length-value (TLV) encoded data sets. Each Routing Metric/
TLV has the same structure: Constraint TLV has the same structure:
Type: 1 byte Type: 1 byte
Length: 1 byte Length: 1 byte
Value: variable Value: variable
A Routing Metric/Constraint TLV is comprised of 1 byte for the type, A Routing Metric/Constraint TLV is comprised of 1 byte for the type,
1 byte specifying the TLV length, and a value field. The TLV length 1 byte specifying the TLV length, and a value field. The TLV length
field defines the length of the value field in bytes. field defines the length of the value field in bytes.
Unrecognized TLVs MUST be ignored. Unrecognized TLVs MUST be ignored.
IANA management of the Routing Metric/Constraint objects identifier IANA management of the Routing Metric/Constraint objects identifier
codespace is described in Section 9. codespace is described in Section 6.
2.2. Use of multiple DAG Metric Containers
Since the length of RPL options is encoded using 1 octet, they cannot
exceed 256 bytes, which also applies to the DAG Metric Container. In
the vast majority of cases, the advertised routing metrics and
constraints will not require that much space. However, there might
be circumstances where larger space is required, should for example a
set of routing metrics be recorded along a long path. In this case,
as specified in [I-D.ietf-roll-rpl], routing metrics will be carried
using multiple DAG Metric Containers.
In the rest of this document, this use of multiple DAG Metric
Containers will be considered as if they were actually just one long
DAG Metric Container.
2.3. Metric usage
This section describes how metrics carried in the DAG Metric
Container shall be used.
When the DAG Metric Container contains a single aggregated metric
(scalar value), the order relation to select the best path is
implicitly derived from the metric type. For example, lower is
better for Hop Count, Link Latency and ETX. Conversely, for Node
Energy or Throughput, higher is better.
An example of using such a single aggregated metric is optimizing
routing for node energy. The Node Energy metric (E-E field) is
aggregated along paths with an explicit min function (A field), and
the best path is selected through an implied Max function because the
metric is Energy.
When the DAG Metric Container contains several aggregated metrics,
they are to be used as tie-breakers according to their precedence
defined by their Prec field values.
An example of such use of multiple aggregated metrics is the
following: Hop-Count as the primary criterion, LQL as the secondary
criterion and Node Energy as the ultimate tie-breaker. In such a
case, the Hop-Count, LQL and Node Energy metric objects' Prec fields
should bear strictly increasing values such as 0, 1 and 2,
respectively.
If several aggregated metrics happen to bear the same Prec value, the
behavior is implementation-dependant.
3. Node Metric/Constraint objects 3. Node Metric/Constraint 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 (but non exclusive) use of constraint-based routing This is a typical (but non-exclusive) use of constraint-based
where the computed path may not be the shortest path according to routing, where the computed path may not be the shortest path
some specified metrics. Another use is to find the shortest path according to some specified metrics. Another use is to find the
according to a pre-defined metric while avoiding link with a specific shortest path according to a pre-defined metric while avoiding links
color (for example "non secured link"). with a specific color (for example "non-secured link").
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 the nodes characteristics. information on the nodes 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 be no more than one NSA object as a constraint per DAG Metric MUST be no more than one NSA object as a constraint per DAG Metric
Container, and no more than one NSA object as a metric per DAG Metric Container, and no more than one NSA object as a metric per DAG Metric
Container. Container.
The NSA object may also contain a set of TLVs used to convey various The NSA 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 NSA Routing Metric/Constraint Type is to be assigned by IANA The NSA Routing Metric/Constraint Type is to be assigned by IANA
(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 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 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 expressed 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 Medium 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 conditions. Using overload, lack of memory or any other node related conditions. Using
a simple 1-bit flag to characterize the node workload provides a a simple 1-bit flag to characterize the node workload provides a
sufficient level of granularity, similarly to the "overload" bit used sufficient level of granularity, similarly to the "overload" bit 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 paths to potentially avoid nodes with
overload bit set are outside the scope of this document but it is their overload bit set are outside the scope of this document, but it
RECOMMENDED to avoid too frequent changes of that bit to avoid is RECOMMENDED to avoid frequent changes of this bit to avoid routing
routing oscillations. oscillations.
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 the 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 lifetime in battery operated
operated environments. Applications where high directional data flow environments. Applications where highly directional data flow is
is expected on a regular basis may take advantage of data aggregation expected on a regular basis may take advantage of data aggregation
supported routing. supported routing.
The following two bits of the NSA object are currently defined: The following two bits of the NSA object are currently defined:
o O Flag: When set, this indicates that the node is overloaded and
may not be able to process traffic.
o A Flag: When set, this indicates that the node can act as a o A Flag: When set, this indicates that the node can act as a
traffic aggregator. An implementation MAY decide to add optional traffic aggregator. An implementation MAY decide to add optional
TLVs (not currently defined) to further describe the node traffic TLVs (not currently defined) to further describe the node traffic
aggregator functionality. aggregator functionality.
o O Flag: When set, this indicates that the node is overloaded and
may not be able to process traffic.
The Flag field of the NSA Routing Metric/Constraint object is managed The Flag field of the NSA Routing Metric/Constraint object is managed
by IANA. Unassigned bits are considered as reserved. They MUST be by IANA. Unassigned bits are considered as reserved. They MUST be
set to zero on transmission and MUST be ignored on receipt. set to zero on transmission and MUST be ignored on receipt.
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 constraint-based routing selected as a router, thus the support for constraint-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 in particular for low-critical traffic or nodes powered nodes (in particular for routine traffic) or nodes equipped
equipped with energy scavenging, rather than a "shorter" path through with energy scavenging, rather than a "shorter" path through battery
battery operated nodes. operated nodes.
Power and energy are clearly critical resources in most LLNs. As yet Power and energy are clearly critical resources in most LLNs. As yet
there is no simple abstraction which adequately covers the broad there is no simple abstraction which adequately covers 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 main-powered, primary batteries, energy- LLN nodes. These include mains-powered, 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
unpredictable power, such as might be provided by a vibrational unpredictable power, such as might be provided by a vibrational
energy scavenger on an intermittently powered pump. Routes which are energy scavenger on an intermittently powered pump. Routes which are
viable when the sun is shining may disappear at night. A pump viable when the sun is shining may disappear at night. A pump
turning on may connect two previously disconnected sections of a turning on may connect two previously disconnected sections of a
network. network.
Storage systems like rechargeable batteries often suffer substantial Storage systems like rechargeable batteries often suffer substantial
degradation if regularly used to full discharge, leading to different degradation if regularly used to full discharge, leading to different
residual energy numbers for regular versus emergency operation. A residual energy numbers for regular versus emergency operation. A
route for emergency traffic may have a different optimum than one for route for emergency traffic may have a different optimum than one for
regular reporting. regular reporting.
Batteries used in LLNs often degrade substantially if their average Batteries used in LLNs often degrade substantially if their average
current consumption exceeds a small fraction of the peak current that current consumption exceeds a small fraction of the peak current that
they can deliver. It is not uncommon for battery-operated nodes to they can deliver. It is not uncommon for self-supporting nodes to
have a combination of primary storage, energy scavenging, and have a combination of primary storage, energy scavenging, and
secondary storage, leading to three different values for acceptable secondary storage, leading to three different values for acceptable
average current depending on the time frame being considered, e.g. average current depending on the time frame being considered, e.g.
milliseconds, seconds, and hours/years. milliseconds, seconds, and hours/years.
Raw power and energy values are meaningless without knowledge of the Raw power and energy values are meaningless without knowledge of the
energy cost of sending and receiving packets, and lifetime estimates energy cost of sending and receiving packets, and lifetime estimates
have no value without some higher-level constraint on the lifetime have no value without some higher-level constraint on the lifetime
required of a device. In some cases the path that exhausts the required of a device. In some cases the path that exhausts the
battery of a node on the bed table in a month may be preferable to a battery of a node on the bed table in a month may be preferable to a
skipping to change at page 12, line 43 skipping to change at page 14, line 19
The simplest solution relies on a 2-bit field encoding three types of The simplest solution relies on a 2-bit field encoding three types of
power sources: "powered", "battery", "scavenger". This simple power sources: "powered", "battery", "scavenger". This simple
approach may be sufficient for many applications. approach may be sufficient for many applications.
The mid-complexity solution is a single parameter that can be used to The mid-complexity solution is a single parameter that can be used to
encode the energetic happiness of both battery powered and scavenging encode the energetic happiness of both battery powered and scavenging
nodes. For scavenging nodes, the 8 bit quantity is the power nodes. For scavenging nodes, the 8 bit quantity is the power
provided by the scavenger divided by the power consumed by the provided by the scavenger divided by the power consumed by the
application, H=P_in/P_out, in units of percent. Nodes which are application, H=P_in/P_out, in units of percent. Nodes which are
scavenging more power than they are consuming will register above scavenging more power than they are consuming will register above
100. The time period for averaging power in this calculation is out 100. A good time period for averaging power in this calculation may
of the scope of this document but something related to the discharge be related to the discharge time of the energy storage device on the
time of the energy storage device on the node is probably node, but specifying this is out of the scope of this document. For
appropriate. For battery powered devices, H is the current expected battery powered devices, H is the current expected lifetime divided
lifetime divided by the desired minimum lifetime. The estimation of by the desired minimum lifetime. The estimation of remaining battery
remaining battery energy and actual power consumption can be energy and actual power consumption can be difficult, and the
difficult, and the specifics of this calculation are out of scope of specifics of this calculation are out of scope of this document, but
this document, but two examples are presented. If the node can two examples are presented. If the node can measure its average
measure its average power consumption, then H can be calculated as power consumption, then H can be calculated as the ratio of desired
the ratio of desired max power (initial energy E_0 divided by desired max power (initial energy E_0 divided by desired lifetime T) to
lifetime T) to actual power H=P_max/P_now. Alternatively, if the actual power, H=P_max/P_now. Alternatively, if the energy in the
energy in the battery E_bat can be estimated, and the total elapsed battery E_bat can be estimated, and the total elapsed lifetime, t, is
lifetime, t, is available, then H can be calculated as the total available, then H can be calculated as the total stored energy
stored energy remaining versus the target energy remaining: H= E_bat remaining versus the target energy remaining: H= E_bat / [E_0
/ [E_0 (T-t)/T]. (T-t)/T].
An example of optimized route is max(min(H)) for all battery operated An example of optimized route is max(min(H)) for all battery operated
nodes along the route, subject to the constraint that H>=100 for all nodes along the route, subject to the constraint that H>=100 for all
scavengers along the route. scavengers along the route.
Note that the estimated percentage of remaining energy indicated in
the E-E field may not be useful in the presence of nodes powered by
battery or energy scavengers when the amount of energy accumulated by
the device significantly differ. Indeed, X% of remaining energy on a
node that can store a large amount of energy cannot be easily
compared to the same percentage of remaining energy on a node powered
by a tiny source of energy. That being said, in networks where nodes
have relatively close energy storage, such a percentage of remaining
energy is useful. Other documents may define more complex/detailed
mechanisms to represent these metric.
The Node Energy (NE) object is used to provide information related to The Node Energy (NE) object is used to provide information related to
node energy and may be used as a metric or as constraint. node energy and may be used as a metric or as constraint.
The NE object MAY be present in the DAG Metric Container. There MUST The NE object MAY be present in the DAG Metric Container. There MUST
be no more than one NE object as a constraint per DAG Metric be no more than one NE object as a constraint per DAG Metric
Container, and no more than one NE object as a metric per DAG Metric Container, and no more than one NE object as a metric per DAG Metric
Container. Container.
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 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 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 object format Figure 4: NE 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 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 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 5: 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 T (node Type): 2-bit field indicating the node type. When E=0x00,
the node is mains powered. When E=0x01 is battery powered. When
E=0x02 the node is powered by a scavenger.
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 node. Conversely, battery operated node 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
exclusion. When set, this indicates that nodes of type specified exclusion. When set, this indicates that nodes of the type
in the node type field MUST be included. Conversely, when specified in the node type field MUST be included. Conversely,
cleared, this indicates that nodes of type specified in the node when cleared, this indicates that nodes of type specified in the
type field MUST be excluded. node type field MUST be excluded.
o T (node Type): 2-bit field indicating the node type. E=0x00
designates a mains-powered node, E=0x01 a battery-powered node and
E=0x02 a node powered by an energy scavenger.
o E (Estimation): when the E bit is set for a metric, the estimated o E (Estimation): when the E bit is set for a metric, the estimated
percentage of remaining energy on the node is indicated in the E-E percentage of remaining energy on the node is indicated in the E-E
8-bit field. When cleared, the estimated percentage of remaining 8-bit field. When cleared, the estimated percentage of remaining
energy is not provided. When the E bit is set for a constraint, energy is not provided. When the E bit is set for a constraint,
the E-E field defines a threshold for the inclusion/exclusion: if the E-E field defines a threshold for the inclusion/exclusion: if
an inclusion, nodes with values higher than the threshold are to an inclusion, nodes with values higher than the threshold are to
be included; if an exclusion, nodes with values lower than the be included; if an exclusion, nodes with values lower than the
threshold are to be excluded. threshold are to be excluded.
skipping to change at page 14, line 40 skipping to change at page 16, line 23
is cleared. is cleared.
If the NE object comprises several sub-objects when used as a If the NE object comprises several sub-objects when used as a
constraint, each sub-object adds or subtracts node subsets as the constraint, each sub-object adds or subtracts node subsets as the
sub-objects are parsed in order. The initial set (full or empty) is sub-objects are parsed in order. The initial set (full or empty) is
defined by the I bit of the first sub-object: full if that I bit is defined by the I bit of the first sub-object: full if that I bit is
an exclusion, empty is that I bit is an inclusion. an exclusion, empty is that I bit is an inclusion.
No TLV is currently defined. No TLV is currently defined.
The most complex solution involves a half dozen TLV parameters Future addenda to this document may include more complex solutions
representing energy storage, consumption, and generation capabilities involving a half dozen TLV parameters representing energy storage,
of the node, as well as desired lifetime, and will appear in a future consumption, and generation capabilities of the node, as well as
version of this document. desired lifetime.
3.3. Hop-Count object 3.3. Hop-Count object
The HoP-Count (HP) object is used to report the number of traversed The HoP-Count (HP) object is used to report the number of traversed
nodes along the path. nodes along the path.
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 no more than one HP object as a constraint per DAG Metric be no more than one HP object as a constraint per DAG Metric
Container, and no more than one HP object as a metric per DAG Metric Container, and no more than one HP object as a metric per DAG Metric
Container. Container.
skipping to change at page 15, line 27 skipping to change at page 17, line 19
| Res | Flags | Hop Count | Optional TLVs | Res | Flags | Hop Count | Optional TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 6: Hop Count object format Figure 6: Hop Count object format
No Flag is currently defined. No Flag is 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
increments the Hop Count field. increments the Hop Count field.
3.4. Node Fanout Ratio object
The Node Fanout Ratio (NFR) object is used to provide information on
the nodes current forwarding load.
The NFR object MAY be present in the DAG Metric Container. There
MUST be no more than one NFR object as a constraint per DAG Metric
Container, and no more than one NFR object as a metric per DAG Metric
Container.
The NFR object may also contain a set of TLVs used to convey various
forwarding load characteristics. No TLV is currently defined.
The NFR object Type is to be assigned by IANA (recommended value=9).
The format of the NFR object body is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Flags | F R | Optional TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 7: NFR object format
When the data traffic of the application supported by the network is
known a priori, energy depletion in the network can be equalized
simply by controlling the fanout ratio of router nodes.
Algorithms describing how to compute the FR value and how to use it
are outside the scope of this document.
The following field of the NFR object is defined:
o FR Field: a 4-bit unsigned integer that indicates a relative
fanout of the node. A value of 15 indicates a node that is very
close to, or at its maximum supported fanout capability. A value
of 0 indicates a very small fanout.
Unassigned bits are considered as reserved. They MUST be set to zero
on transmission and MUST be ignored on receipt.
4. Link Metric/Constraint objects 4. Link Metric/Constraint objects
4.1. Throughput 4.1. Throughput
Many LLNs support a wide range of throughputs. For some links, this Many LLNs support a wide range of throughputs. For some links, this
may be due to variable coding. For the deeply duty-cycled links may be due to variable coding. For the deeply duty-cycled links
found in many LLNs, the variability comes as a result of trading found in many LLNs, the variability comes as a result of trading
power consumption for bit rate. There are several MAC layer power consumption for bit rate. There are several MAC layer
protocols which allow for the effective bit rate and power protocols which allow for the effective bit rate and power
consumption of a link to vary over more than three orders of consumption of a link to vary over more than three orders of
skipping to change at page 17, line 8 skipping to change at page 17, line 45
currently available throughput. 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 no more than one Throughput object as a constraint per There MUST be no more than one Throughput object as a constraint per
DAG Metric Container, and no more than one Throughput object as a DAG Metric Container, and no more than one Throughput object as a
metric per DAG Metric Container. metric per DAG Metric Container.
The Throughput object is made of throughput sub-objects and MUST at The Throughput object is made of throughput sub-objects and MUST at
least comprise one Throughput sub-object. The first Throughput sub- least comprise one Throughput sub-object. The first Throughput sub-
object MUST be the most recently estimated actual throughput. The object MUST be the most recently estimated actual throughput. The
actual evaluation of the throughput is outside of this document. actual estimation of the throughput is outside the scope of this
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:
skipping to change at page 17, line 43 skipping to change at page 18, line 34
Figure 9: Throughput sub-object format Figure 9: 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 current consumption. Some LLN MAC link layers will allow the in current consumption. Some LLN MAC link layers will allow the
latency to be adjusted globally on the subnet, or on a link-by-link latency to be adjusted globally on the subnet, on a link-by-link
basis, or not at all. Some will insist that it be fixed for a given 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. 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 no more than one Latency object as a constraint per DAG MUST be no more than one Latency object as a constraint per DAG
Metric Container, and no more than one Latency object as a metric per Metric Container, and no more than one Latency object as a metric per
DAG Metric Container. DAG Metric Container.
The Latency object is made of Latency sub-objects and MUST at least The Latency object is made of Latency sub-objects and MUST at 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
skipping to change at page 18, line 49 skipping to change at page 19, line 39
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.
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 (wireless links). Multipath typically multi-path interference (wireless links). Multipath typically
affects both directions on the link equally, whereas external affects both directions on the link equally, whereas external
interference is sometimes uni-directional. Time scales vary from interference is sometimes unidirectional. Time scales vary from
milliseconds to days, and are often periodic and linked to human milliseconds to days, and are often periodic and linked to human
activity. Packet error rates can generally be measured directly, and activity. Packet error rates can generally be measured directly, and
other metrics (e.g. bit error rate, mean time between failures) are other metrics (e.g. bit error rate, mean time between failures) are
typically derived from that. Note that such variability is not typically derived from that. Note that such variability is not
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. Link quality may be taken into account as a critical routing metric.
quality metric should be applied to each directional link unless bi-
directionality is one of routing metrics.
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 implementation 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
is implementation specific and outside of the scope of this document. are implementation specific and outside of the scope of this
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 be recorded or aggregated. For example,
the DAG may require to record the LQL for all traversed links. Each the DAG Metric object may request all traversed nodes to record the
node can then use the LQL to select the parent based on user defined LQL of their incoming link into the LQL object. Each node can then
rules (e.g. "select the path with the maximum number of links use the LQL record to select its parent based on some user defined
reporting a LQL value of 3 or less"). By contrast the LQL link rules (e.g. something like "select the path with most links reporting
metric may be aggregated, in which case the sum of all LQLs may be a LQL value of 3 or less"). By contrast, the LQL link metric may be
reported (additive metric) or the minimum value may be reported along aggregated, in which case the sum of all LQLs may be reported
the path. (additive metric) or the minimum value may be reported along the
path.
When used as a recorded metric, a counter is used to compress the When used as a recorded metric, counters are used to compress the
information where the number of links for each LQL is reported. information: for each encountered LQL value, only the number of
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 be no more than one LQL object as a constraint per DAG Metric MUST be no more than one LQL object as a constraint per DAG Metric
Container, and no more than one LQL object as a metric per DAG Metric Container, and no more than one LQL object as a metric per DAG Metric
Container. 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 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 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 format Figure 12: LQL object format
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 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 13: 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.
skipping to change at page 20, line 47 skipping to change at page 21, line 48
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 Value | | Aggregated LQL Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: LQL Type 2 sub-object format Figure 14: LQL Type 2 sub-object format
Aggregated LQL Value: when used as an additive metric (A=0x00), the 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 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,
ignoring undetermined LQLs (Aggregated LQL Value = 0). When used to ignoring undetermined LQLs (Aggregated LQL Value = 0). When used to
report a maximum (A=0x01), the field reports the maximum LQL value of report a maximum (A=0x01), the field reports the maximum LQL value of
all links along the path. When used to report a multiplication 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 (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 undetermined (LQL=0), the undetermined LQL will be ignored and not be
aggregated (i.e. no reset to Aggregated LQL Value field). 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
skipping to change at page 22, line 30 skipping to change at page 23, line 30
Figure 16: ETX sub-object format Figure 16: 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
example, the ETX object may be used as an aggregated additive metric example, the ETX object may be used as an aggregated additive metric
where the value is updated along the path to reflect to path quality. where the value is updated along the path to reflect the 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 link The Link Color (LC) object is an administrative 10-bit link
constraint (which may either be static or dynamically adjusted) used constraint (which may either be static or dynamically adjusted) used
to avoid or attract specific links for specific traffic types. to avoid or attract specific links for specific traffic types.
The LC object can either be used as a metric or as a constraint. The LC object can either be used as a metric or as a constraint.
skipping to change at page 23, line 20 skipping to change at page 24, line 22
per DAG Metric Container. 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 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 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 17: LC object format
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.
skipping to change at page 24, line 15 skipping to change at page 25, line 15
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 |I| | Link Color |I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: LC Type 2 sub-object format Figure 19: LC Type 2 sub-object format
I Bit: The I bits 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.
The use of the LC object is outside the scope of this document. The use of the LC object is outside the scope of this document.
4.4.2. Mode of operation 4.4.2. Mode of operation
The link color may be used as a constraint or a metric. The link color may be used as a constraint or a metric.
o When used as constraint, the LC object may be inserted in the DAG o When used as constraint, the LC object may be inserted in the DAG
Metric Container to indicate that links with a specific color Metric Container to indicate that links with a specific color
should be included or excluded from the computed path. should be included or excluded from the computed path.
o When used as recorded metric, each node along the path may insert o When used as recorded metric, each node along the path may insert
a LC object in the DAG Metric Container to report the color of the a LC object in the DAG Metric Container to report the color of the
local link. If there is already a LC object reported a similar local link. If there is already a LC object reporting a similar
color, the node MUST NOT add another identical LC sub-object and color, the node MUST NOT add another identical LC sub-object and
MUST increment the counter field. MUST increment the counter field.
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
skipping to change at page 25, line 14 skipping to change at page 26, line 14
optimization algorithm to avoid too frequent computation of new optimization algorithm to avoid too frequent computation of new
routes upon metric values changes. 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 adversely micro-loops. Furthermore, excessive route changes will adversely
impact the traffic and power consumption in the network, thus impact the traffic and power consumption in the network, thus
potentially impacting its scalability. potentially impacting its scalability.
6. Use of multiple DAG Metric Container 6. IANA Considerations
Since RPL options length are coded using 1 octet, their length cannot
exceed 256 bytes, which also applies to the DAG Metric Container.
Although in the vast majority of cases, the advertised routing
metrics and constraints will not require that much space, there might
be circumstances where larger space will be required, should for
example a set of routing metrics be recorded along a long path. In
this case, as specified in [I-D.ietf-roll-rpl], routing metrics will
be carried using multiple DAG Metric Containers.
In the rest of this document, this use of multiple DAG Metric
Containers will be considered as if they were actually just one long
DAG Metric Container.
7. Metric consistency
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
consistent metric calculation mechanisms for all links and nodes in
the network, similarly to the case of inter-domain IP routing.
8. Metric usage
This section describes how metrics carried in the DAG Metric
Container shall be used.
When the DAG Metric Container contains a single aggregated metric
(scalar value), the order relation to select the best path is
implicitly derived from the metric type. For example, lower is
better for Hop Count, Link Latency, ETX and Fanout Ratio. For Node
Energy or Throughput, higher is better.
An example of using such a single aggregated metric is optimizing
routing for node energy. The Node Energy metric (E-E field) is
aggregated along paths with an explicit min function (A field), and
the best path is selected through an implied Max function because the
metric is Energy.
When the DAG Metric Container contains several aggregated metrics,
they are to be used as tie-breakers according to their precedence
defined by their Prec field values.
An example of such use of multiple aggregated metrics is the
following: Hop-Count as the primary criteria, LQL as the secondary
criteria and Fanout Ratio as the ultimate tie-breaker. In such a
case, the Hop-Count, LQL and Fanout Ratio metric objects' Prec fields
should bear strictly increasing values such as 0, 1 and 2,
respectively.
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 Metric/Constraint objects codepoints and sub-registries. all Routing Metric/Constraint 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).
9.1. Routing Metric/Constraint type 6.1. Routing Metric/Constraint type
IANA is requested to create a registry for Routing Metric/Constraint IANA is requested to create a registry for Routing Metric/Constraint
objects. Each Routing Metric/Constraint object has a type value. objects. Each Routing Metric/Constraint object has a 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
9 Node Fanout Ratio This document
9.2. Routing Metric/Constraint common header 6.2. Routing Metric/Constraint 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 the
field of the Routing Metric/Constraint common header. A field of the Routing Metric/Constraint common header.
Codespace of the A field (Routing Metric/Constraint common header) Codespace of the A field (Routing Metric/Constraint common header)
Value Meaning Reference Value Meaning Reference
0 Routing metric is additive This document 0 Routing metric is additive This document
1 Routing metric reports a maximum This document 1 Routing metric reports a maximum This document
2 Routing metric reports a minimum This document 2 Routing metric reports a minimum This document
3 Routing metric is multiplicative This document 3 Routing metric is multiplicative 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
skipping to change at page 27, line 37 skipping to change at page 27, line 32
o Defining RFC o Defining RFC
Several bits are defined for the Routing Metric/Constraint common Several bits are defined for the Routing Metric/Constraint common
header in this document. The following values have been assigned: header in this document. The following values have been assigned:
Codespace of the Flag field (Routing Metric/Constraint common header) Codespace of the Flag field (Routing Metric/Constraint common header)
Bit Description Reference Bit Description Reference
12-15 Precedence This document 12-15 Precedence This document
10-11 Additive/Max/Min/Multi This document 9-11 Additive/Max/Min/Multi This document
9 Recorded/Aggregated This document 8 Recorded/Aggregated This document
8 Optional Constraint This document 7 Optional Constraint This document
7 Constraint/metric This document 6 Constraint/Metric This document
6 P (Partial) This document 5 P (Partial) This document
9.3. NSA object 6.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 (NSA object) Codespace of the Flag field (NSA object)
Bit Description Reference Bit Description Reference
skipping to change at page 28, line 17 skipping to change at page 28, line 12
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 (NSA object) Codespace of the Flag field (NSA object)
Bit Description Reference Bit Description Reference
14 Aggregator This document 14 Aggregator This document
15 Overloaded This document 15 Overloaded This document
9.4. Hop-Count object 6.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 Flag is currently defined. No Flag is currently defined.
10. Security considerations 7. 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, RPL should not allow a malicious node to falsely
good metrics for routing and belong to the established path to have a advertise that it has good metrics for routing, be added as a router
chance to intercept packets. Since the routing metrics/constraints for other nodes' traffic and intercept packets. Since the routing
are carried within RPL message, the security routing mechanisms metrics/constraints are carried within RPL message, the security
defined in [I-D.ietf-roll-rpl] applies here. routing mechanisms defined in [I-D.ietf-roll-rpl] applies here.
11. Acknowledgements 8. Acknowledgements
The authors would like to acknowledge the contributions of Young Jae The authors would like to acknowledge the contributions of Young Jae
Kim, Hakjin Chong, David Meyer, Mischa Dohler, Anders Brandt, Philip Kim, Hakjin Chong, David Meyer, Mischa Dohler, Anders Brandt, Philip
Levis, Pascal Thubert, Richard Kelsey, Jonathan Hui, Alexandru Levis, Pascal Thubert, Richard Kelsey, Jonathan Hui, Alexandru
Petrescu, Richard Kelsey, Mathilde Durvy, Phoebus Chen, Tim Winter, Petrescu, Richard Kelsey, Mathilde Durvy, Phoebus Chen, Tim Winter,
Mukul Goyal, Yoav Ben-Yehezkel, Matteo Paris, Omprakash Gnawali, Mads Mukul Goyal, Yoav Ben-Yehezkel, Matteo Paris, Omprakash Gnawali, Mads
Westergreen and Mukul Goyal for their review and valuable comments. Westergreen and Mukul Goyal for their review and valuable comments.
12. References 9. References
9.1. Normative references
12.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
12.2. Informative references 9.2. Informative references
[I-D.ietf-roll-rpl] [I-D.ietf-roll-rpl]
Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
Protocol for Low power and Lossy Networks", Kelsey, R., Levis, P., Networks, D., Struik, R., and J.
draft-ietf-roll-rpl-11 (work in progress), July 2010. Vasseur, "RPL: IPv6 Routing Protocol for Low power and
Lossy Networks", draft-ietf-roll-rpl-12 (work in
progress), October 2010.
[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-03 (work in Networks", draft-ietf-roll-terminology-04 (work in
progress), March 2010. progress), September 2010.
[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.
 End of changes. 84 change blocks. 
302 lines changed or deleted 281 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/