draft-ietf-roll-routing-metrics-04.txt   draft-ietf-roll-routing-metrics-05.txt 
Networking Working Group JP. Vasseur, Ed. Networking Working Group JP. Vasseur, Ed.
Internet-Draft Cisco Systems, Inc Internet-Draft Cisco Systems, Inc
Intended status: Standards Track M. Kim, Ed. Intended status: Standards Track M. Kim, Ed.
Expires: June 6, 2010 Future Tech Lab., Korea Telecom Expires: September 22, 2010 Corporate Technology Group, KT
K. Pister K. Pister
Dust Networks Dust Networks
H. Chong H. Chong
Future Tech Lab., Korea Telecom Corporate Technology Group, KT
December 3, 2009 March 21, 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-04 draft-ietf-roll-routing-metrics-05
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. node routing metrics and constraints suitable to LLNs.
skipping to change at page 2, line 8 skipping to change at page 2, line 8
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 6, 2010. This Internet-Draft will expire on September 22, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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
skipping to change at page 3, line 17 skipping to change at page 3, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Node Metrics And Constraints Objects . . . . . . . . . . . . . 9 3. Node Metrics And Constraints Objects . . . . . . . . . . . . . 9
3.1. Node State And Attributes Object . . . . . . . . . . . . . 9 3.1. Node State And Attributes Object . . . . . . . . . . . . . 9
3.2. Node Energy Object . . . . . . . . . . . . . . . . . . . . 11 3.2. Node Energy Object . . . . . . . . . . . . . . . . . . . . 11
3.3. Hop-Count Object . . . . . . . . . . . . . . . . . . . . . 14 3.3. Hop-Count Object . . . . . . . . . . . . . . . . . . . . . 14
4. Link Metrics and Constraints Objects . . . . . . . . . . . . . 14 4. Link Metrics and Constraints Objects . . . . . . . . . . . . . 14
4.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. Link reliability . . . . . . . . . . . . . . . . . . . . . 17 4.3. Link reliability . . . . . . . . . . . . . . . . . . . . . 17
4.3.1. The Link Quality Level Reliability Metric . . . . . . 18 4.3.1. The Link Quality Level Reliability Metric . . . . . . 17
4.3.2. The Expected Transmission Count (ETX) Reliability 4.3.2. The Expected Transmission Count (ETX) Reliability
Object . . . . . . . . . . . . . . . . . . . . . . . . 19 Object . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4. Link Color Object . . . . . . . . . . . . . . . . . . . . 21 4.4. Link Color Object . . . . . . . . . . . . . . . . . . . . 20
4.4.1. Link Color Object Description . . . . . . . . . . . . 21 4.4.1. Link Color Object Description . . . . . . . . . . . . 20
4.4.2. Mode of Operation . . . . . . . . . . . . . . . . . . 22 4.4.2. Mode of Operation . . . . . . . . . . . . . . . . . . 22
5. Computation of Dynamic Metrics and Attributes . . . . . . . . 23 5. Computation of Dynamic Metrics and Attributes . . . . . . . . 22
6. Objective Function . . . . . . . . . . . . . . . . . . . . . . 23 6. Objective Function . . . . . . . . . . . . . . . . . . . . . . 23
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Other metric under consideration . . . . . . . . . . . . . 24 7.1. Other metric under consideration . . . . . . . . . . . . . 24
8. Metric Consistency . . . . . . . . . . . . . . . . . . . . . . 24 8. Metric Consistency . . . . . . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9.1. Routing Objects . . . . . . . . . . . . . . . . . . . . . 25 9.1. Routing Objects . . . . . . . . . . . . . . . . . . . . . 24
9.2. Routing Object Common Header . . . . . . . . . . . . . . . 25 9.2. Routing Object Common Header . . . . . . . . . . . . . . . 25
9.3. NSA Object . . . . . . . . . . . . . . . . . . . . . . . . 26 9.3. NSA Object . . . . . . . . . . . . . . . . . . . . . . . . 25
9.4. Hop-count Object . . . . . . . . . . . . . . . . . . . . . 26 9.4. Hop-count Object . . . . . . . . . . . . . . . . . . . . . 26
9.5. DAG Information Option (DIO) suboption for the OCP 9.5. DAG Information Option (DIO) suboption for the OCP
Object . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Object . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.6. Objective Code Point (OCP) Object . . . . . . . . . . . . 27 9.6. Objective Code Point (OCP) Object . . . . . . . . . . . . 26
10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . . 28 12.2. Informative References . . . . . . . . . . . . . . . . . . 27
12.3. References . . . . . . . . . . . . . . . . . . . . . . . . 29 12.3. References . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
This document makes use of the terminology defined in This document makes use of the terminology defined in
[I-D.ietf-roll-terminology]. [I-D.ietf-roll-terminology].
Low power and Lossy Networks (LLNs) have specific routing Low power and Lossy Networks (LLNs) have specific routing
characteristics compared with traditional wired or ad-hoc networks characteristics compared with traditional wired or ad-hoc networks
that have been spelled out in [RFC5548], [RFC5673], that have been spelled out in [RFC5548], [RFC5673],
[I-D.ietf-roll-home-routing-reqs] and [I-D.ietf-roll-home-routing-reqs] and
skipping to change at page 7, line 19 skipping to change at page 7, line 19
local energy without the need to propagate the energy level of all local energy without the need to propagate the energy level of all
nodes along the path. In contrast, other metrics such as link nodes along the path. In contrast, other metrics such as link
latency metrics are cumulative and global in the sense that they latency metrics are cumulative and global in the sense that they
characterize a path cost using the latency as a metric. In this characterize a path cost using the latency as a metric. In this
particular example the delay is an aggregated global and cumulative particular example the delay is an aggregated global and cumulative
link metric. link metric.
2. Object Formats 2. Object Formats
Routing metrics and constraints are carried within the DAG Metric Routing metrics and constraints are carried within the DAG Metric
Container object defined in [I-D.ietf-roll-rpl]. Container object defined in [I-D.ietf-roll-rpl]. The Object Code
Point (OCP) object is a sub-option carried within the DIO base option
object defined in [I-D.ietf-roll-rpl].
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 5 6 7 8 9 0 1 2 3 4 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Type=2 | Container Len | DAG Metric data ... | Type=2 | Container Len | DAG Metric data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 1: DAG Metric Container Format Figure 1: DAG Metric Container Format
Routing metrics and constraints have a common format consisting of Routing metrics and constraints have a common format consisting of
one or more 8-bit words with a common header: one or more 8-bit words with a common header:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Routing-Ob-Type|Res|R|G| A |O|C| Object Length (bytes) | |Routing-Ob-Type|Res|R|G| A |O|C| Object Length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (Object body) // // (Object body) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Routing Metric/Constraint common header format Figure 2: Routing Metric/Constraint common header format
skipping to change at page 10, line 6 skipping to change at page 10, line 6
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 only one NSA object per DAG Metric Container object. MUST be only one NSA object per DAG Metric Container object.
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 TLVs are currently defined. node characteristics. No TLVs are currently defined.
The NSA Routing Object Type is to be assigned by IANA (recommended The NSA Routing Object Type is to be assigned by IANA (recommended
value=1). value=1).
The format of the NSA object body is as follows: The format of the NSA object body is as follows:
0 1
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Res | Flags |A|O| Optional TLVs | Res | Flags |A|O| Optional TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 3: NSA Object format Figure 3: NSA Object format
Node workload may be hard to determine and express in some scalar Node workload may be hard to determine and express in some scalar
form. However, node workload could be a useful metric to consider form. However, node workload could be a useful metric to consider
during path calculation, in particular when queuing delays must be during path calculation, in particular when queuing delays must be
skipping to change at page 13, line 6 skipping to change at page 13, line 6
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 only one NE object per DAG Metric Container object. be only one NE object per DAG Metric Container object.
The NE Routing Object Type is to be assigned by IANA (recommended The NE Routing Object Type is to be assigned by IANA (recommended
value=2). value=2).
The format of the NE object body is as follows: The format of the NE object body is as follows:
0 1
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| NE Sub-objects | NE Sub-objects
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 4: NE Object format Figure 4: NE Object format
When used as a constraint, the NE object comprises only one NE sub- When used as a constraint, the NE object comprises only one NE sub-
object. object.
The format of the NE sub-object body is as follows: The format of the NE sub-object body is as follows:
0 1 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| 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.
skipping to change at page 14, line 30 skipping to change at page 14, line 31
The HP object may also contain a set of TLVs used to convey various The HP object may also contain a set of TLVs used to convey various
node characteristics. No TLVs are currently defined. node characteristics. No TLVs are currently defined.
The HP routing metric object Type is to be assigned by IANA The HP routing metric object Type is to be assigned by IANA
(recommended value=3) (recommended value=3)
The HP routing metric object is a global routing object that The HP routing metric object is a global routing object that
characterizes a path. characterizes a path.
The format of the Hop Count object body is as follows: The format of the Hop Count object body is as follows:
0 1
0 1 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 | Hop Count | Optional TLVs | Res | Flags | Hop Count | Optional TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 6: Hop Count Object format Figure 6: Hop Count Object format
No Flags are currently defined. No Flags are currently defined.
The HP object may be used as a constraint or a metric. When used as The HP object may be used as a constraint or a metric. When used as
skipping to change at page 16, line 7 skipping to change at page 15, line 34
The Throughput object does not contain any additional TLV. The Throughput object does not contain any additional TLV.
The Throughput Object Type is to be assigned by IANA (recommended The Throughput Object Type is to be assigned by IANA (recommended
value=4) value=4)
The Throughput Object is a global metric. The Throughput Object is a global metric.
The format of the Throughput object body is as follows: The format of the Throughput object body is as follows:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-object) ..... | (sub-object) .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Throughput Object Body Format Figure 7: Throughput Object Body Format
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Throughput | | Throughput |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Throughput Sub-object format Figure 8: Throughput Sub-object format
Throughput: 32 bits. The Throughput is encoded in 32 bits in IEEE
floating point format (see [IEEE.754.1985]), expressed in bytes per Throughput: 32 bits. The Throughput is encoded in 32 bits in
second. Refer to Section 3.1.2 of [RFC3471] for a table of commonly unsigned integer format, expressed in bytes per second.
used values.
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
be varied over many orders of magnitude, again with a corresponding be varied over many orders of magnitude, again with a corresponding
change in current consumption. Some LLN MAC link layers will allow change in current consumption. Some LLN MAC link layers will allow
the latency to be adjusted globally on the subnet, or on a link-by- the latency to be adjusted globally on the subnet, or on a link-by-
link basis, or not at all. Some will insist that it be fixed for a link basis, or not at all. Some will insist that it be fixed for a
given link, but allow it to be variable from link to link. given link, but allow it to be variable from link to link.
The Latency object MAY be present in the DAG Metric Container. There The Latency object MAY be present in the DAG Metric Container. There
MUST be only one Latency object per DAG Metric Container object. MUST be only one Latency object per DAG Metric Container object.
The Latency object is made of Latency sub-objects and MUST as least The Latency object is made of Latency sub-objects and MUST as least
comprise one Latency sub-object. Each Latency sub-object has a fixed comprise one Latency sub-object. Each Latency sub-object has a fixed
length of 4 bytes. length of 3 bytes.
The Latency object does not contain any additional TLV. The Latency object does not contain any additional TLV.
The Latency object Type is to be assigned by IANA (recommended The Latency object Type is to be assigned by IANA (recommended
value=5) value=5)
The Latency Object is a global metric or constraint. The Latency Object is a global metric or constraint.
The format of the Latency object body is as follows: The format of the Latency object body is as follows:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-object) ..... | (sub-object) .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Latency Object Body Format Figure 9: Latency Object Body Format
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latency | | Latency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Latency Sub-object format Figure 10: Latency Sub-object format
Latency: 32 bits. The Latency is encoded in 32 bits in IEEE floating Latency: 24 bits. The Latency is encoded in 24 bits in unsigned
point format (see [IEEE.754.1985]), expressed in milliseconds. Refer integer format, expressed in microseconds.
to Section 3.1.2 of [RFC3471] for a table of commonly used values.
The Latency object may be used as a constraint or a path metric. For The Latency object may be used as a constraint or a path metric. For
example, an Objective Function may indicate that the latency must not example, an Objective Function may indicate that the latency must not
exceed some values. In this case, the latency object common header exceed some values. In this case, the latency object common header
indicates that the value relates to a constraint with a maximum indicates that the value relates to a constraint with a maximum
value. In another example, the latency object may be used as an value. In another example, the latency object may be used as an
aggregated additive metric where the value is updated along the path aggregated additive metric where the value is updated along the path
to reflect to path latency. to reflect to path latency.
4.3. Link reliability 4.3. Link reliability
skipping to change at page 19, line 6 skipping to change at page 18, line 21
The LQL object contains one or more sub-object used to report the The LQL object contains one or more sub-object used to report the
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 LQL object is a global object that characterizes the path The LQL object is a global object that characterizes the path
reliability. reliability.
The format of the LQL object body is as follows: The format of the LQL object body is as follows:
0 1
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Res | LQL Sub-object | Res | LQL Sub-object
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 11: LQL Object format Figure 11: 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.
skipping to change at page 19, line 36 skipping to change at page 19, line 7
Val: LQL value from 0 to 3 where 0 means undetermined and 1 indicates Val: LQL value from 0 to 3 where 0 means undetermined and 1 indicates
the lowest link quality. the lowest link quality.
Counter: number of links. Counter: number of links.
When the LQL metric is aggregated, the LQL object body comprises one When the LQL metric is aggregated, the LQL object body comprises one
LQL Type 2 sub-object: LQL Type 2 sub-object:
The format of the LQL Type 2 sub-object is as follows The format of the LQL Type 2 sub-object is as follows
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Aggregated LQL Value | | Aggregated LQL Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: LQL Type 2 sub-Object format Figure 13: LQL Type 2 sub-Object format
Aggregated LQL Value: when used an an additive metric (A=0x00), the Aggregated LQL Value: when used an an additive metric (A=0x00), the
aggregated LQL value reports the sum of all the LQL values for all aggregated LQL value reports the sum of all the LQL values for all
links along the path. When used to report a minimum (A=0x02), the links along the path. When used to report a minimum (A=0x02), the
field reports the minimum LQL value of all links along the path. field reports the minimum LQL value of all links along the path.
4.3.2. The Expected Transmission Count (ETX) Reliability Object 4.3.2. The Expected Transmission Count (ETX) Reliability Object
skipping to change at page 20, line 27 skipping to change at page 20, line 7
bits. bits.
The ETX object does not contain any additional TLV. The ETX object does not contain any additional TLV.
The ETX object Type is to be assigned by IANA (recommended value=7) The ETX object Type is to be assigned by IANA (recommended value=7)
The ETX object is a global metric or constraint. The ETX object is a global metric or constraint.
The format of the Latency object body is as follows: The format of the Latency object body is as follows:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-object) ..... | (sub-object) .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: ETX Object Body Format Figure 14: ETX Object Body Format
0 1 0 1
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETX | | ETX |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: ETX Sub-object format Figure 15: ETX Sub-object format
ETX: 8 bits. The ETX is encoded in 8 bits in IEEE floating point ETX: 16 bits. The ETX * 128 is encoded in 16 bits in unsinged
format (see [IEEE.754.1985]). Refer to Section 3.1.2 of [RFC3471] integer format, rounded off to the nearest whole number. For
for a table of commonly used values. 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.
The ETX object may be used as a constraint or a path metric. For The ETX object may be used as a constraint or a path metric. For
example, an Objective Function may indicate that the ETX must not be example, an Objective Function may indicate that the ETX must not be
below some specified value. In this case, the ETX object common below some specified value. In this case, the ETX object common
header indicates that the value relates to a constraint with a header indicates that the value relates to a constraint with a
minimum value. In another example, the ETX object may be used as an minimum value. In another example, the ETX object may be used as an
aggregated additive metric where the value is updated along the path aggregated additive metric where the value is updated along the path
to reflect to path quality. to reflect to path quality.
4.4. Link Color Object 4.4. Link Color Object
skipping to change at page 21, line 40 skipping to change at page 21, line 21
sub-object per DAG Metric Container object. sub-object per DAG Metric Container object.
The LC routing object does not contain any additional TLV. The LC routing object does not contain any additional TLV.
The LC routing object Type is to be assigned by IANA (recommended The LC routing object Type is to be assigned by IANA (recommended
value=8) value=8)
The LC object may either be local or global. The LC object may either be local or global.
The format of the LC object body is as follows: The format of the LC object body is as follows:
0 1
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Res | LC Sub-objects | Res | LC Sub-objects
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 16: LC Object format Figure 16: LC Object format
When the LC object is used as a global recorded metric, the LC object When the LC object is used as a global recorded metric, the LC object
body comprises one or more LC Type 1 sub-objects. body comprises one or more LC Type 1 sub-objects.
The format of the LC Type 1 sub-object body is as follows: The format of the LC Type 1 sub-object body is as follows:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Color | Counter | | Link Color | Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: LC Type 1 sub-object format Figure 17: LC Type 1 sub-object format
When the LC object is used as a constraint, the LC object body When the LC object is used as a constraint, the LC object body
comprises one or more LC Type 2 sub-objects. comprises one or more LC Type 2 sub-objects.
The format of the LC Type 2 sub-object body is as follows: The format of the LC Type 2 sub-object body is as follows:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Color |I| | Link Color |I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: LC Type 2 sub-object format Figure 18: LC Type 2 sub-object format
I Bit: When cleared, this indicates that links with the specified I Bit: When cleared, this indicates that links with the specified
color must be included. When set, this indicates that links with the color must be included. When set, this indicates that links with the
specified color must be excluded. specified color must be excluded.
skipping to change at page 24, line 5 skipping to change at page 23, line 31
specified in [I-D.ietf-roll-rpl], the OF is used by a node to select specified in [I-D.ietf-roll-rpl], the OF is used by a node to select
its parent during the DAG building construction process. its parent during the DAG building construction process.
The OCP object is used to specify the OF and is carried as a sub- The OCP object is used to specify the OF and is carried as a sub-
option within the DIO Base Option object defined in option within the DIO Base Option object defined in
[I-D.ietf-roll-rpl]. [I-D.ietf-roll-rpl].
There MUST be a single instance of the OCP object within the sub- There MUST be a single instance of the OCP object within the sub-
option field of the DIO Base option object. option field of the DIO Base option object.
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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| OCP | (TLVs) | OCP | (TLVs)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 19: OCP Object Format Figure 19: OCP Object Format
The OCP object suboption type is 5 (to be confirmed by IANA). The OCP object suboption type is 5 (to be confirmed by IANA).
The OCP object body may carry optional TLVs. No TLVs are currently The OCP object body may carry optional TLVs. No TLVs are currently
skipping to change at page 28, line 10 skipping to change at page 27, line 35
[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 12.2. Informative References
[I-D.ietf-roll-building-routing-reqs] [I-D.ietf-roll-building-routing-reqs]
Martocci, J., Riou, N., Mil, P., and W. Vermeylen, Martocci, J., Riou, N., Mil, P., and W. Vermeylen,
"Building Automation Routing Requirements in Low Power and "Building Automation Routing Requirements in Low Power and
Lossy Networks", draft-ietf-roll-building-routing-reqs-07 Lossy Networks", draft-ietf-roll-building-routing-reqs-09
(work in progress), September 2009. (work in progress), January 2010.
[I-D.ietf-roll-home-routing-reqs] [I-D.ietf-roll-home-routing-reqs]
Brandt, A. and J. Buron, "Home Automation Routing Brandt, A. and J. Buron, "Home Automation Routing
Requirements in Low Power and Lossy Networks", Requirements in Low Power and Lossy Networks",
draft-ietf-roll-home-routing-reqs-09 (work in progress), draft-ietf-roll-home-routing-reqs-11 (work in progress),
November 2009. January 2010.
[I-D.ietf-roll-rpl] [I-D.ietf-roll-rpl]
Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing
Protocol for Low power and Lossy Networks", Protocol for Low power and Lossy Networks",
draft-ietf-roll-rpl-04 (work in progress), October 2009. draft-ietf-roll-rpl-07 (work in progress), March 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-02 (work in Networks", draft-ietf-roll-terminology-02 (work in
progress), October 2009. progress), October 2009.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990. dual environments", RFC 1195, December 1990.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
skipping to change at page 29, line 20 skipping to change at page 29, line 4
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 (editor) Mijeom (editor)
Future Tech Lab., Korea Telecom 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 Kris
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
Hakjin Hakjin
Future Tech Lab., Korea Telecom Corporate Technology Group, KT
17 Woomyeon-dong, Seocho-gu 17 Woomyeon-dong, Seocho-gu
Seoul, 137-792 Seoul, 137-792
Korea Korea
Email: hjchong@kt.com Email: hjchong@kt.com
 End of changes. 42 change blocks. 
64 lines changed or deleted 69 lines changed or added

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