draft-ietf-roll-routing-metrics-11.txt   draft-ietf-roll-routing-metrics-12.txt 
Networking Working Group JP. Vasseur, Ed. Networking Working Group JP. Vasseur, Ed.
Internet-Draft Cisco Systems, Inc Internet-Draft Cisco Systems, Inc
Intended status: Standards Track M. Kim, Ed. Intended status: Standards Track M. Kim, Ed.
Expires: April 26, 2011 Corporate Technology Group, KT Expires: May 12, 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
October 23, 2010 November 8, 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-11 draft-ietf-roll-routing-metrics-12
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 April 26, 2011. This Internet-Draft will expire on May 12, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 28 skipping to change at page 3, line 28
4.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3. Link reliability . . . . . . . . . . . . . . . . . . . . . 19 4.3. Link reliability . . . . . . . . . . . . . . . . . . . . . 19
4.3.1. The Link Quality Level reliability metric . . . . . . 20 4.3.1. The Link Quality Level reliability metric . . . . . . 20
4.3.2. The Expected Transmission Count (ETX) reliability 4.3.2. The Expected Transmission Count (ETX) reliability
object . . . . . . . . . . . . . . . . . . . . . . . . 21 object . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4. Link Color object . . . . . . . . . . . . . . . . . . . . 23 4.4. Link Color object . . . . . . . . . . . . . . . . . . . . 23
4.4.1. Link Color object description . . . . . . . . . . . . 23 4.4.1. Link Color object description . . . . . . . . . . . . 23
4.4.2. Mode of operation . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 25 6.1. Routing Metric/Constraint type . . . . . . . . . . . . . . 26
6.2. Routing Metric/Constraint common header . . . . . . . . . 26 6.2. Routing Metric/Constraint common header . . . . . . . . . 26
6.3. NSA object . . . . . . . . . . . . . . . . . . . . . . . . 27 6.3. NSA object . . . . . . . . . . . . . . . . . . . . . . . . 27
6.4. Hop-Count object . . . . . . . . . . . . . . . . . . . . . 27 6.4. Hop-Count object . . . . . . . . . . . . . . . . . . . . . 27
7. Security considerations . . . . . . . . . . . . . . . . . . . 28 7. Security considerations . . . . . . . . . . . . . . . . . . . 28
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Normative references . . . . . . . . . . . . . . . . . . . 28 9.1. Normative references . . . . . . . . . . . . . . . . . . . 28
9.2. Informative references . . . . . . . . . . . . . . . . . . 28 9.2. Informative references . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
skipping to change at page 7, line 25 skipping to change at page 7, line 25
2. Object formats 2. Object formats
2.1. DAG Metric Container format 2.1. DAG Metric Container format
Routing metrics and constraints are carried within the DAG Metric Routing metrics and constraints are carried within the DAG Metric
Container object defined in [I-D.ietf-roll-rpl]. Should multiple Container object defined in [I-D.ietf-roll-rpl]. Should multiple
metrics and/or constraints be present in the DAG Metric Container, metrics and/or constraints be present in the DAG Metric Container,
their use to determine the "best" path can be defined by an Objective their use to determine the "best" path can be defined by an Objective
Function. Function.
0 1 2 3 4 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| 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/Constraint objects represent a metric or a The Routing Metric/Constraint objects represent a metric or a
constraint of a particular type. They may appear in any order in the constraint of a particular type. They may appear in any order in the
DAG Metric Container. They have a common format consisting of one or DAG Metric Container. They have a common format consisting of one or
more bytes with a common header: more bytes with a common header:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 9, line 36 skipping to change at page 9, line 36
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 is the ETX the lower link quality is): 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 selected the advertising nodes 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, if the constraint signalled in the DIO constraint is concerned, if the constraint signalled in the DIO
message is not satisfied, the advertising node is just not selected message is not satisfied, the advertising node is just not selected
as a parent by the node that processes the DIO message. as a parent by the node that processes the DIO message.
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 (defined in Section 4) and link quality levels must be quality level (defined in Section 4) and link quality levels must be
recorded along the path. In this case, the DAG Metric Container recorded along the path. In this case, the DAG Metric Container
carries a Routing Metric/Constraint object: link quality level metric carries a Routing Metric/Constraint object: link quality level metric
skipping to change at page 12, line 40 skipping to change at page 12, line 40
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-
powered nodes (in particular for routine traffic) or nodes equipped
with energy scavenging, rather than a "shorter" path through battery
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 mains-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
skipping to change at page 14, line 26 skipping to change at page 14, line 21
scavengers along the route. 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 relatively close energy storage, such a percentage of remaining
energy is useful. Other documents may define more complex/detailed energy is useful.
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).
skipping to change at page 21, line 49 skipping to change at page 21, line 49
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
transmissions a node expects to make to a destination in order to transmissions a node expects to make to a destination in order to
successfully deliver a packet. successfully deliver a packet. In contrast with the LQL routing
metric, the ETX provides a discrete value (wich may not be an
For example, an implementation may use the following formula: ETX= 1 integer) computed according to a specific formula: for example, an
/ (Df * Dr) where Df is the measured probability that a packet is implementation may use the following formula: ETX= 1 / (Df * Dr)
received by the neighbor and Dr is the measured probability that the where Df is the measured probability that a packet is received by the
acknowledgment packet is successfully received. This document does neighbor and Dr is the measured probability that the acknowledgment
not mandate the use of a specific formula to compute the ETX value. packet is successfully received. This document does not mandate the
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 be no more than one ETX object as a constraint per DAG Metric MUST be no more than one ETX object as a constraint per DAG Metric
Container, and no more than one ETX object as a metric per DAG Metric Container, and no more than one ETX object as a metric per DAG Metric
Container. 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 8
bits. bits.
skipping to change at page 23, line 4 skipping to change at page 23, line 5
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 the path where the value is updated along the path to reflect the path
quality. quality: when a node receives the aggregated additive ETX value of
the path (cummulative path ETX calculated as the sum of the link ETX
of all of the traversed links from the advertising node to the DAG
root), if it selects that node as its preferred parent, the node
updates the path ETX by adding the ETX of the local link between
itself and the preferred parent to the received path cost (path ETX)
before potentially advertising itself the new path ETX.
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 28, line 41 skipping to change at page 28, line 41
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
9.2. Informative references 9.2. Informative references
[I-D.ietf-roll-rpl] [I-D.ietf-roll-rpl]
Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
Kelsey, R., Levis, P., Networks, D., Struik, R., and J. Kelsey, R., Levis, P., Networks, D., Struik, R., and J.
Vasseur, "RPL: IPv6 Routing Protocol for Low power and Vasseur, "RPL: IPv6 Routing Protocol for Low power and
Lossy Networks", draft-ietf-roll-rpl-13 (work in Lossy Networks", draft-ietf-roll-rpl-14 (work in
progress), October 2010. 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-04 (work in Networks", draft-ietf-roll-terminology-04 (work in
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.
skipping to change at page 29, line 31 skipping to change at page 29, line 31
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.
[Khanna1989J A. Zinky, A. Khanna, and G. Vichniac. "Performance of
the Revised Routing Metric for ARPANET and MILNET.
Submitted to 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
 End of changes. 13 change blocks. 
27 lines changed or deleted 32 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/