draft-ietf-roll-routing-metrics-18.txt   draft-ietf-roll-routing-metrics-19.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: August 26, 2011 Corporate Technology Group, KT Expires: September 2, 2011 Corporate Technology Group, KT
K. Pister K. Pister
Dust Networks Dust Networks
N. Dejean N. Dejean
Coronis SAS Elster SAS
D. Barthel D. Barthel
France Telecom Orange France Telecom Orange
February 22, 2011 March 1, 2011
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-18 draft-ietf-roll-routing-metrics-19
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 August 26, 2011. This Internet-Draft will expire on September 2, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 29 skipping to change at page 3, line 29
4.3. Link Reliability . . . . . . . . . . . . . . . . . . . . . 19 4.3. Link Reliability . . . . . . . . . . . . . . . . . . . . . 19
4.3.1. The Link Quality Level Reliability Metric . . . . . . 20 4.3.1. The Link Quality Level Reliability Metric . . . . . . 20
4.3.2. The Expected Transmission Count (ETX) reliability 4.3.2. The Expected Transmission Count (ETX) reliability
object . . . . . . . . . . . . . . . . . . . . . . . . 21 object . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4. Link Color Object . . . . . . . . . . . . . . . . . . . . 23 4.4. Link Color Object . . . . . . . . . . . . . . . . . . . . 23
4.4.1. Link Color Object Description . . . . . . . . . . . . 23 4.4.1. Link Color Object Description . . . . . . . . . . . . 23
4.4.2. Mode of operation . . . . . . . . . . . . . . . . . . 24 4.4.2. Mode of operation . . . . . . . . . . . . . . . . . . 24
5. Computation of Dynamic Metrics and Attributes . . . . . . . . 25 5. Computation of Dynamic Metrics and Attributes . . . . . . . . 25
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
6.1. Routing Metric/Constraint Type . . . . . . . . . . . . . . 26 6.1. Routing Metric/Constraint Type . . . . . . . . . . . . . . 26
6.2. Routing Metric/Constraint TLV . . . . . . . . . . . . . . 26 6.2. Routing Metric/Constraint TLVs . . . . . . . . . . . . . . 26
6.3. Routing Metric/Constraint Common Header . . . . . . . . . 26 6.3. Routing Metric/Constraint Common Header Flag field . . . . 26
6.4. NSA Object . . . . . . . . . . . . . . . . . . . . . . . . 27 6.4. Routing Metric/Constraint Common Header A field . . . . . 27
6.5. Hop-Count Object . . . . . . . . . . . . . . . . . . . . . 27 6.5. NSA Object Flag field . . . . . . . . . . . . . . . . . . 27
6.6. Hop-Count Object Flag field . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Normative references . . . . . . . . . . . . . . . . . . . 28 9.1. Normative references . . . . . . . . . . . . . . . . . . . 28
9.2. Informative references . . . . . . . . . . . . . . . . . . 28 9.2. Informative references . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 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
[RFC5867]. [RFC5867].
skipping to change at page 6, line 11 skipping to change at page 6, line 11
Links in LLN commonly have rapidly changing node and link Links in LLN commonly have rapidly changing node and link
characteristics: thus routing metrics must be dynamic and techniques characteristics: thus routing metrics must be dynamic and techniques
must be used to smooth out the dynamicity of these metrics so as to must be used to smooth out the dynamicity of these metrics so as to
avoid routing oscillations. For instance, in addition to the dynamic avoid routing oscillations. For instance, in addition to the dynamic
nature of some links (e.g. wireless but also Powerline Communication nature of some links (e.g. wireless but also Powerline Communication
(PLC) links), nodes' resources such as residual energy are changing (PLC) links), nodes' resources such as residual energy are changing
continuously and may have to be taken into account during the path continuously and may have to be taken into account during the path
computation. computation.
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 (see [[Khanna1989J]). The use of been experimented in ARPANET 2 (see [Zinky1989]). The use of dynamic
dynamic metrics is not trivial and great care must be given to the metrics is not trivial and great care must be given to the use of
use of dynamic metrics since it may lead to potential routing dynamic metrics since it may lead to potential routing instabilities.
instabilities. That being said, lots of experience has been gained That being said, lots of experience has been gained over the years on
over the years on the use of dynamic routing metrics, which have been the use of dynamic routing metrics, which have been deployed in a
deployed in a number of (non IP) networks. number of (non IP) networks.
Very careful attention must be given to the pace at which routing Very careful attention must be given to the pace at which routing
metrics and attributes values change in order to preserve routing metrics and attributes values change in order to preserve routing
stability. When using a dynamic routing metric, a RPL implementation stability. When using a dynamic routing metric, a RPL implementation
should make use of a multi-threshold scheme rather than fine granular should make use of a multi-threshold scheme rather than fine granular
metric updates reflecting each individual change to avoid spurious metric updates reflecting each individual change to avoid spurious
and unneccessary routing changes. and unneccessary routing changes.
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 metric. thus different reporting rates may be used for each metric.
skipping to change at page 8, line 26 skipping to change at page 8, line 26
The object body carries one or more sub-objects defined later in this The object body carries one or more sub-objects defined later in this
document. Note that an object may carry TLV, which may itself document. Note that an object may carry TLV, which may itself
comprise other TLVs. A TLV carried within a TLV is called a TLV in comprise other TLVs. A TLV carried within a TLV is called a TLV in
this specification. this specification.
Routing-MC-Type (Routing Metric/Constraint Type - 8 bits): the Routing-MC-Type (Routing Metric/Constraint Type - 8 bits): the
Routing Metric/Constraint Type field uniquely identifies each Routing Routing Metric/Constraint Type field uniquely identifies each Routing
Metric/Constraint object and is managed by IANA. Metric/Constraint object and is managed by IANA.
Length: this field defines the length of the object body, in bytes. Length (8 bits): this field defines the length of the object body,
expressed in bytes. It ranges from 0 to 255.
Flag field (16 bits). The Flag field of the Routing Metric/ Flag field (16 bits). The Flag field of the Routing Metric/
Constraint object is managed by IANA. Unassigned bits are considered Constraint object is managed by IANA. Unassigned bits are considered
as reserved. They MUST be set to zero on transmission and MUST be as reserved. They MUST be set to zero on transmission and MUST be
ignored on receipt. ignored on receipt.
The following bits of the Routing Metric/Constraint Flag field object The following bits of the Routing Metric/Constraint Flag field object
are currently defined: are currently defined:
o P flag: the P field is only used for recorded metrics. When o P flag: the P field is only used for recorded metrics. When
skipping to change at page 9, line 24 skipping to change at page 9, line 24
o A=0x00: The routing metric is additive o A=0x00: The routing metric is additive
o A=0x01: The routing metric reports a maximum o A=0x01: The routing metric reports a maximum
o A=0x02: The routing metric reports a minimum o A=0x02: The routing metric reports a minimum
o A=0x03: The routing metric is multiplicative o 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) and Routing Metric/Constraint object refers to a routing constraint) and
he only valid when the R bit is cleared. Otherwise, the A field MUST is only valid when the R bit is cleared. Otherwise, the A field MUST
be set to 0x00 and MUST be ignored on receipt. be set to 0x00 and MUST be ignored on receipt.
Prec field (4 bits): The Prec field indicates the precedence of this Prec field (4 bits): The Prec field indicates the precedence of this
Routing Metric/Constraint object relative to other objects in the Routing Metric/Constraint object relative to other objects in the
container. This is useful when a DAG Metric Container contains container. This is useful when a DAG Metric Container contains
several Routing Metric objects. The value 0 means the highest several Routing Metric objects. Its value ranges from 0 to 15. The
precedence. value 0 means the highest precedence.
Example 1: A DAG formed by RPL where all nodes must be mains-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 object with R=0) and the second one is a Node Energy constraint object with
header (C=1, O=0, A=00, R=0). Note that a RPL instance may use the header (C=1, O=0, A=00, R=0). Note that a RPL instance may use the
metric object to report a maximum (A=0x01) or a minimum (A=0x02). metric object to report a maximum (A=0x01) or a minimum (A=0x02).
If, for example, the best path is characterized by the path avoiding If, for example, the best path is characterized by the path avoiding
low quality links, then the path metric reports a maximum (A=0x01) low quality links, then the path metric reports a maximum (A=0x01)
(the higher is the ETX the lower link quality is): when the DIO (the higher the ETX, the lower the link quality): when the DIO
message reporting link quality metric (ETX) is processed by a node, message reporting link quality metric (ETX) is processed by a node,
each node selecting the advertising node as a parent updates the each node selecting the advertising node as a parent updates the
value carried in the metric object by replacing it with its local value carried in the metric object by replacing it with its local
link ETX value if and only if the latter is higher. As far as the link ETX value if and only if the latter is higher. As far as the
constraint is concerned, the object body will carry a node energy constraint is concerned, the object body will carry a node energy
constraint object defined in Section 3.1 indicating that nodes must constraint object defined in Section 3.1 indicating that nodes must
be mains-powered: if the constraint signalled in the DIO message is be mains-powered: if the constraint signalled in the DIO message is
not satisfied, the advertising node is just not selected as a parent not satisfied, the advertising node is just not selected as a parent
by the node that processes the DIO message. by the node that processes the DIO message.
skipping to change at page 10, line 24 skipping to change at page 10, line 24
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 (from 0 to 255). field defines the length of the value field in bytes (from 0 to 255).
Unrecognized TLVs MUST be silently ignored while still being Unrecognized TLVs MUST be silently ignored while still being
propagated in DIO generated by receiving node. propagated in DIOs generated by the receiving node.
IANA manages the codepoints for all TLV carried in routing IANA manages the codepoints for all TLVs carried in routing
constraint/metric objects. constraint/metric objects.
IANA management of the Routing Metric/Constraint objects identifier IANA management of the Routing Metric/Constraint objects identifier
codespace is described in Section 6. codespace is described in Section 6.
2.2. Use of Multiple DAG Metric Containers 2.2. Use of Multiple DAG Metric Containers
Since the length of RPL options is encoded using 1 octet, they cannot Since the length of RPL options is encoded using 1 octet, they cannot
exceed 255 bytes, which also applies to the DAG Metric Container. In exceed 255 bytes, which also applies to the DAG Metric Container. In
the vast majority of cases, the advertised routing metrics and the vast majority of cases, the advertised routing metrics and
skipping to change at page 11, line 30 skipping to change at page 11, line 30
case, the Hop-Count, LQL and Node Energy metric objects' Prec fields case, the Hop-Count, LQL and Node Energy metric objects' Prec fields
should bear strictly increasing values such as 0, 1 and 2, should bear strictly increasing values such as 0, 1 and 2,
respectively. respectively.
If several aggregated metrics happen to bear the same Prec value, the If several aggregated metrics happen to bear the same Prec value, the
behavior is implementation-dependant. behavior is implementation-dependant.
3. Node Metric/Constraint Objects 3. Node Metric/Constraint Objects
The sections 3. and 4. specify several link and node metric/ The sections 3. and 4. specify several link and node metric/
constraint objects. In some cases it is stated that there must not constraint objects. In some cases, it is stated that there must not
be more than one object of a specific type. In that case, if an RPL be more than one object of a specific type. In that case, if an RPL
implementation receives more than one object of that type, the second implementation receives more than one object of that type, the second
objet MUST silently be ignored. objet MUST silently be ignored.
In the presence of a constraint and a metric (which may or may not be In the presence of a constraint and a metric (which may or may not be
of the same type), a node MUST update the constraint before of the same type), a node MUST update the constraint before
advertising the updated metric and constraints. For example, if the advertising the updated metric and constraints. For example, if the
constraint is the number of hops (e.g. the maximum number of hops is constraint is the number of hops (e.g. the maximum number of hops is
n) and the path is optimized against the delay: if a node selects a n) and the path is optimized against the delay: if a node selects a
parent advertising a maximum number of hops of n (constraint), it parent advertising a maximum number of hops of n (constraint), it
must advertises DIO messages containing a hop count metrics must advertise DIO messages containing a hop count metrics constraint
constraint with a field value equal of (n-1) and the newly computed with a field value equal of (n-1) and the newly computed path metric.
path metric. This applies to the following constraints defined This applies to the following constraints defined below: hop-count,
below: hop-count, latency and path ETX. latency and path ETX.
3.1. Node State and Attributes Object 3.1. Node State and Attributes Object
The Node State and Attribute (NSA) object is used to provide The Node State and Attribute (NSA) object is used to provide
information on node characteristics. information on node characteristics.
The NSA object MAY be present in the DAG Metric Container. There The NSA object MAY be present in the DAG Metric Container. There
MUST NOT be more than one NSA object as a constraint per DAG Metric MUST NOT be more than one NSA object as a constraint per DAG Metric
Container, and there MUST NOT be more than one NSA object as a metric Container, and there MUST NOT be more than one NSA object as a metric
per DAG Metric Container. per DAG Metric Container.
skipping to change at page 14, line 34 skipping to change at page 14, line 34
application, E-E=P_in/P_out, in units of percent. Nodes which are application, E-E=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. A good time period for averaging power in this calculation may 100. A good time period for averaging power in this calculation may
be related to the discharge time of the energy storage device on the be related to the discharge time of the energy storage device on the
node, but specifying this is out of the scope of this document. For node, but specifying this is out of the scope of this document. For
battery powered devices, E-E is the current expected lifetime divided battery powered devices, E-E is the current expected lifetime divided
by the desired minimum lifetime, in units of percent. The estimation by the desired minimum lifetime, in units of percent. The estimation
of remaining battery energy and actual power consumption can be of remaining battery energy and actual power consumption can be
difficult, and the specifics of this calculation are out of scope of difficult, and the specifics of this calculation are out of scope of
this document, but two examples are presented. If the node can this document, but two examples are presented. If the node can
measure its average power consumption, then H can be calculated as measure its average power consumption, then E-E can be calculated as
the ratio of desired max power (initial energy E_0 divided by desired the ratio of desired max power (initial energy E_0 divided by desired
lifetime T) to actual power, E-E=P_max/P_now. Alternatively, if the lifetime T) to actual power, E-E=P_max/P_now. Alternatively, if the
energy in the battery E_bat can be estimated, and the total elapsed energy in the battery E_bat can be estimated, and the total elapsed
lifetime, t, is available, then H can be calculated as the total lifetime, t, is available, then E-E can be calculated as the total
stored energy remaining versus the target energy remaining: E-E= stored energy remaining versus the target energy remaining: E-E=
E_bat / [E_0 (T-t)/T]. E_bat / [E_0 (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 E-E>=100 for nodes along the route, subject to the constraint that E-E>=100 for
all scavengers along the route. all scavengers along the route.
Note that the estimated percentage of remaining energy indicated in 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 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 battery or energy scavengers when the amount of energy accumulated by
the device significantly differ. Indeed, X% of remaining energy on a the device significantly differ. Indeed, X% of remaining energy on a
node that can store a large amount of energy cannot be easily node that can store a large amount of energy cannot be easily
compared to the same percentage of remaining energy on a node powered 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 by a tiny source of energy. That being said, in networks where nodes
have relatively close energy storage, such a percentage of remaining have similar energy storage, such a percentage of remaining energy is
energy is useful. useful.
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
NOT be more than one NE object as a constraint per DAG Metric NOT be more than one NE object as a constraint per DAG Metric
Container, and there MUST NOT be more than one NE object as a metric Container, and there MUST NOT be more than one NE object as a metric
per DAG Metric Container. per DAG Metric 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).
skipping to change at page 17, line 27 skipping to change at page 17, line 27
No Flag is currently defined. Unassigned bits are considered as No Flag is currently defined. Unassigned bits are considered as
reserved. They MUST be set to zero on transmission and MUST be reserved. They MUST be set to zero on transmission and MUST be
ignored on receipt. ignored on receipt.
The HP object may be used as a constraint or a metric. When used as The HP object may be used as a constraint or a metric. When used as
a constraint, the DAG root indicates the maximum number of hops that a constraint, the DAG root indicates the maximum number of hops that
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.
Note that the first node along a path inserting a Hop-count object Note that the first node along a path inserting a Hop-count Metric
MUST set the Hop Count field value to 1. object MUST set the Hop Count field value to 1.
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 of a link to vary protocols which allow for the effective bit rate of a link to vary
skipping to change at page 22, line 6 skipping to change at page 22, line 6
neighbor and Dr is the measured probability that the acknowledgment neighbor and Dr is the measured probability that the acknowledgment
packet is successfully received. This document does not mandate the packet is successfully received. This document does not mandate the
use of a specific formula to compute the ETX value. use of a specific formula to compute 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 NOT be more than one ETX object as a constraint per DAG Metric MUST NOT be more than one ETX object as a constraint per DAG Metric
Container, and there MUST NOT be more than one ETX object as a metric Container, and there MUST NOT be more than one ETX object as a metric
per DAG Metric Container. per DAG Metric Container.
The ETX object is made of ETX sub-objects and MUST at least comprise The ETX object is made of ETX sub-objects and MUST at least comprise
one ETX sub-object. Each ETX sub-object has a fixed length of 8 one ETX sub-object. Each ETX sub-object has a fixed length of 16
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 format of the ETX object body is as follows: The format of the ETX object body is as follows:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3
skipping to change at page 25, line 33 skipping to change at page 25, line 33
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. IANA Considerations 6. IANA Considerations
IANA is requested to establish a new top-level registry to contain IANA is requested to establish a new top-level registry, called "RPL
all Routing Metric/Constraint objects codepoints and sub-registries. Routing Metric/Constraint", to contain all Routing Metric/Constraint
objects codepoints and sub-registries.
The allocation policy for each new registry is by IETF review: new The allocation policy for each new registry is by IETF review: new
values are assigned through the IETF review process (see [RFC5226]). values are assigned through the IETF review process (see [RFC5226]).
Specifically, new assignments are made via RFCs approved by the IESG. Specifically, new assignments are made via RFCs approved by the IESG.
Typically, the IESG will seek input on prospective assignments from Typically, the IESG will seek input on prospective assignments from
appropriate persons (e.g., a relevant Working Group if one exists). appropriate persons (e.g., a relevant Working Group if one exists).
New bit numbers may be allocated only by an IETF Review action. Each New bit numbers may be allocated only by an IETF Review action. Each
bit should be tracked with the following qualities: 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
6.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 subregistry, called "Routing Metric/
objects. Each Routing Metric/Constraint object has a type value Constraint Type", for Routing Metric/Constraint object types, which
(from 1 to 255). range from 0 to 255. Value 0 is undefined.
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
6.2. Routing Metric/Constraint TLV 6.2. Routing Metric/Constraint TLVs
IANA is requested to create a registry used for all TLVs carried IANA is requested to create a subregistry, called "Routing Metric/
within Routing Metric/Constraint objects. The type field is an 8-bit Constraint TLVs", used for all TLVs carried within Routing Metric/
field whose value can be comprised between 1 and 255. Constraint objects. The Type field is an 8-bit field whose value is
comprised between 0 and 255. Value 0 is undefined. The Length file
is an 8-bit field whose value ranges from 0 to 255. The Value field
has value ranges depending on the Type, therefore are not defined
here, since no Type is registered at this time.
6.3. Routing Metric/Constraint Common Header 6.3. Routing Metric/Constraint Common Header Flag field
IANA is requested to create a registry to manage the Flag field of IANA is requested to create a subregistry, called "Routing Metric/
the Routing Metric/Constraint common header. Constraint Common Header Flag field", to manage the 9-bit Flag field
of the Routing Metric/Constraint common header.
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 Flag field 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
9-11 Additive/Max/Min/Multi This document
8 Recorded/Aggregated This document 8 Recorded/Aggregated This document
7 Optional Constraint This document 7 Optional Constraint This document
6 Constraint/Metric This document 6 Constraint/Metric This document
5 P (Partial) This document 5 P (Partial) This document
IANA is requested to create a registry to manage the codespace of the Bits 0-4 are currently reserved.
A field of the Routing Metric/Constraint common header.
6.4. Routing Metric/Constraint Common Header A field
IANA is requested to create a subregistry, called "Routing Metric/
Constraint Common Header A field", to manage the codespace of the A
field of the Routing Metric/Constraint common header.
The A field is 3 bits in length, and has values ranging from 0 to 7.
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
6.4. NSA Object 6.5. NSA Object Flag field
IANA is requested to create a registry to manage the codespace of the IANA is requested to create a subregistry, called "NSA Object Flag
Flag field of the NSA object. field", to manage the codespace of the 8-bit Flag field of the NSA
object.
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 6 Aggregator This document
15 Overloaded This document 7 Overloaded This document
6.5. Hop-Count Object Bits 0-5 are reserved.
IANA is requested to create a registry to manage the codespace of the 6.6. Hop-Count Object Flag field
Flag field of the Hop-count object.
IANA is requested to create a subregistry, called "Hop-Count Object
Flag field", to manage the codespace of the 4-bit Flag field of the
Hop-count object.
No Flag is currently defined. No Flag is currently defined.
7. 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, RPL should not allow a malicious node to falsely For instance, RPL should not allow a malicious node to falsely
advertise that it has good metrics for routing, be added as a router advertise that it has good metrics for routing, be added as a router
for other nodes' traffic and intercept packets. Another attack may for other nodes' traffic and intercept packets. Another attack may
consist of making intermitment attacks on a link in an attempt to consist of making intermittent attacks on a link in an attempt to
constantly modify the link quality and consequently the associated constantly modify the link quality and consequently the associated
routing metric, thus leading to potential fluctuation in the DODAG. routing metric, thus leading to potential fluctuation in the DODAG.
It is thus RECOMMENDED for a RPL implementation to put in place It is thus RECOMMENDED for a RPL implementation to put in place
mechanism so as to stop advertising routing metrics for highly mechanisms so as to stop advertising routing metrics for highly
unstable links that may be subject to attacks. unstable links that may be subject to attacks.
Some routing metrics may also be used to identify some areas of Some routing metrics may also be used to identify some areas of
weaknesses in the network (a highly unreliable link, a node running weaknesses in the network (a highly unreliable link, a node running
low in terms of energy, etc.). Such information may be used by a low in terms of energy, etc.). Such information may be used by a
potential attacker. Thus, it is RECOMMENDED to carefully consider potential attacker. Thus, it is RECOMMENDED to carefully consider
which metrics should be used by RPL and the level of visibility that which metrics should be used by RPL and the level of visibility that
they provide about the network state or to use appropriate the they provide about the network state or to use appropriate the
security measures as specified in [I-D.ietf-roll-rpl] to protect that security measures as specified in [I-D.ietf-roll-rpl] to protect that
information. information.
skipping to change at page 28, line 50 skipping to change at page 29, line 16
9.2. Informative references 9.2. Informative references
[I-D.ietf-roll-of0] [I-D.ietf-roll-of0]
Thubert, P., "RPL Objective Function 0", Thubert, P., "RPL Objective Function 0",
draft-ietf-roll-of0-05 (work in progress), January 2011. draft-ietf-roll-of0-05 (work in progress), January 2011.
[I-D.ietf-roll-terminology] [I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-04 (work in Networks", draft-ietf-roll-terminology-04 (work in
[Khanna1989J A. Zinky, A. Khanna, and G. Vichniac. "Performance of
the Revised Routing Metric for ARPANET and MILNET.
Submitted to MILCOM 89, March 1989
progress), September 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.
skipping to change at page 29, line 36 skipping to change at page 29, line 47
Networks", RFC 5673, October 2009. Networks", RFC 5673, October 2009.
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low-Power and Lossy Networks", Routing Requirements in Low-Power and Lossy Networks",
RFC 5826, April 2010. RFC 5826, April 2010.
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
"Building Automation Routing Requirements in Low-Power and "Building Automation Routing Requirements in Low-Power and
Lossy Networks", RFC 5867, June 2010. Lossy Networks", RFC 5867, June 2010.
[Zinky1989]
Zinky, J., Vichniac, G., and A. Khanna, "Performance of
the Revised Routing Metric for ARPANET and MILNET",
Military Communications Conference, 1989. MILCOM '89 ,
March 1989.
Authors' Addresses Authors' Addresses
JP Vasseur (editor) JP Vasseur (editor)
Cisco Systems, Inc Cisco Systems, Inc
11, Rue Camille Desmoulins 11, Rue Camille Desmoulins
Issy Les Moulineaux, 92782 Issy Les Moulineaux, 92782
France France
Email: jpv@cisco.com Email: jpv@cisco.com
Mijeom Kim (editor) Mijeom Kim (editor)
Corporate Technology Group, KT Corporate Technology Group, KT
17 Woomyeon-dong, Seocho-gu 17 Woomyeon-dong, Seocho-gu
Seoul, 137-792 Seoul, 137-792
Korea Korea
Email: mjkim@kt.com Email: mjkim@kt.com
Kris Pister Kris Pister
Dust Networks Dust Networks
skipping to change at page 30, line 21 skipping to change at page 30, line 32
Kris Pister Kris Pister
Dust Networks Dust Networks
30695 Huntwood Ave. 30695 Huntwood Ave.
Hayward, CA 95544 Hayward, CA 95544
USA USA
Email: kpister@dustnetworks.com Email: kpister@dustnetworks.com
Nicolas Dejean Nicolas Dejean
Coronis SAS Elster SAS
Espace Concorde, 120 impasse JB Say Espace Concorde, 120 impasse JB Say
Perols, 34470 Perols, 34470
France France
Email: nicolas.dejean@coronis.com Email: nicolas.dejean@coronis.com
Dominique Barthel Dominique Barthel
France Telecom Orange France Telecom Orange
28 chemin du Vieux Chene, BP 98 28 chemin du Vieux Chene, BP 98
Meylan, 38243 Meylan, 38243
 End of changes. 41 change blocks. 
69 lines changed or deleted 89 lines changed or added

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