draft-ietf-roll-routing-metrics-05.txt   draft-ietf-roll-routing-metrics-06.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: September 22, 2010 Corporate Technology Group, KT Expires: October 29, 2010 Corporate Technology Group, KT
K. Pister K. Pister
Dust Networks Dust Networks
H. Chong H. Chong
Corporate Technology Group, KT Corporate Technology Group, KT
March 21, 2010 April 27, 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-05 draft-ietf-roll-routing-metrics-06
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 1, line 38 skipping to change at page 1, line 38
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on October 29, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 22, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 23 skipping to change at page 2, line 15
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Node 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
skipping to change at page 8, line 31 skipping to change at page 8, line 31
o A Field: The A field is used to indicate whether a routing metric o A Field: The A field is used to indicate whether a routing metric
is additive, reports a maximum or a minimum. is additive, reports a maximum or a minimum.
* A=0x00: The routing metric is additive * A=0x00: The routing metric is additive
* A=0x01: The routing metric reports a maximum * A=0x01: The routing metric reports a maximum
* A=0x02: The routing metric reports a minimum * A=0x02: The routing metric reports a minimum
* A=0x03: The routing metric is multiplicative
o G Flag: When set, the routing object is global. When cleared it o G Flag: When set, the routing object is global. When cleared it
is local (see details below). is local (see details below).
o R Fag: The R Flag is only relevant for global routing metric (C=0 o R Fag: The R Flag is only relevant for global routing metric (C=0
and G=1) and MUST be cleared for all other values of C and G. When and G=1) and MUST be cleared for all other values of C and G. When
set, this indicates that the routing metric is recorded along the set, this indicates that the routing metric is recorded along the
path. Conversely, when cleared the routing metric is aggregated. path. Conversely, when cleared the routing metric is aggregated.
The A field has no meaning when the C Flag is set (i.e. the routing The A field has no meaning when the C Flag is set (i.e. the routing
object refers to a routing constraint). object refers to a routing constraint).
skipping to change at page 18, line 43 skipping to change at page 18, line 43
The format of the LQL Type 1 sub-object is as follows The format of the LQL Type 1 sub-object is as follows
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Val| Counter | |Val| Counter |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 12: LQL Type 1 sub-Object format Figure 12: LQL Type 1 sub-Object format
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 highest 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
skipping to change at page 20, line 29 skipping to change at page 20, line 29
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: ETX Sub-object format Figure 15: ETX Sub-object format
ETX: 16 bits. The ETX * 128 is encoded in 16 bits in unsinged ETX: 16 bits. The ETX * 128 is encoded in 16 bits in unsinged
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, an Objective Function may indicate that the ETX must not be example, an Objective Function may indicate that the ETX must not
below some specified value. In this case, the ETX object common exceed 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
4.4.1. Link Color Object Description 4.4.1. Link Color Object Description
The Link Color (LC) object is an administrative 10-bit static link The Link Color (LC) object is an administrative 10-bit static link
skipping to change at page 25, line 16 skipping to change at page 25, line 16
IANA is requested to create a registry to manage the codespace of A IANA is requested to create a registry to manage the codespace of A
field and the Flag field of the Routing Common header. field and the Flag field of the Routing Common header.
Codespace of the A field (NSA Object) Codespace of the A field (NSA Object)
Value Meaning Reference Value Meaning Reference
0 Routing metric is additive This document 0 Routing metric is additive This document
2 Routing metric reports a maximum This document 2 Routing metric reports a maximum This document
3 Routing metric reports a minimum This document 3 Routing metric reports a minimum This document
4 Routing metric is multiplicative This document
IANA is requested to create a registry to manage the Flag field of IANA is requested to create a registry to manage the Flag field of
the Routing metric common header. the Routing metric common header.
New bit numbers may be allocated only by an IETF Consensus action. New bit numbers may be allocated only by an IETF Consensus action.
Each bit should be tracked with the following qualities: Each bit should be tracked with the following qualities:
o Bit number o Bit number
o Capability Description o Capability Description
skipping to change at page 27, line 16 skipping to change at page 27, line 16
Routing metrics should be handled in a secure and trustful manner. Routing metrics should be handled in a secure and trustful manner.
For instance, a malicious node can not advertise falsely that it has For instance, a malicious node can not advertise falsely that it has
good metrics for routing and belong to the established path to have a good metrics for routing and belong to the established path to have a
chance to intercept packets. chance to intercept packets.
11. Acknowledgements 11. Acknowledgements
The authors would like to acknowledge the contributions of Young Jae The authors would like to acknowledge the contributions of Young Jae
Kim, David Meyer, Mischa Dohler, Anders Brandt, Philip Levis, Pascal Kim, David Meyer, Mischa Dohler, Anders Brandt, Philip Levis, Pascal
Thubert, Richard Kelsey, Jonathan Hui, Phil Levis and Tim Winter for Thubert, Richard Kelsey, Jonathan Hui, Phil Levis, Tim Winter, Mukul
their review and comments. Goyal, Yoav Ben-Yehezkel and Matteo Paris for their review and
comments.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
skipping to change at page 28, line 4 skipping to change at page 28, line 5
draft-ietf-roll-home-routing-reqs-11 (work in progress), draft-ietf-roll-home-routing-reqs-11 (work in progress),
January 2010. 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-07 (work in progress), March 2010. 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-03 (work in
progress), October 2009. progress), March 2010.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990. dual environments", RFC 1195, December 1990.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS", McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999. RFC 2702, September 1999.
 End of changes. 13 change blocks. 
22 lines changed or deleted 19 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/