draft-ietf-roll-routing-metrics-06.txt   draft-ietf-roll-routing-metrics-07.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: October 29, 2010 Corporate Technology Group, KT Expires: December 12, 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
April 27, 2010 June 10, 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-06 draft-ietf-roll-routing-metrics-07
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 47 skipping to change at page 1, line 47
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 October 29, 2010. This Internet-Draft will expire on December 12, 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
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . 10
3.3. Hop-Count Object . . . . . . . . . . . . . . . . . . . . . 14 3.3. Hop-Count Object . . . . . . . . . . . . . . . . . . . . . 13
4. Link Metrics and Constraints Objects . . . . . . . . . . . . . 14 4. Link Metrics and Constraints Objects . . . . . . . . . . . . . 14
4.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3. Link reliability . . . . . . . . . . . . . . . . . . . . . 17 4.3. Link reliability . . . . . . . . . . . . . . . . . . . . . 16
4.3.1. The Link Quality Level Reliability Metric . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . . 20 4.4. Link Color Object . . . . . . . . . . . . . . . . . . . . 20
4.4.1. Link Color Object Description . . . . . . . . . . . . 20 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 . . . . . . . . 22 5. Computation of Dynamic Metrics and Attributes . . . . . . . . 22
6. Objective Function . . . . . . . . . . . . . . . . . . . . . . 23 6. Use of Multiple Dag Metric Container . . . . . . . . . . . . . 23
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. Metric Consistency . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Other metric under consideration . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8. Metric Consistency . . . . . . . . . . . . . . . . . . . . . . 24 8.1. Routing Objects . . . . . . . . . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8.2. Routing Object Common Header . . . . . . . . . . . . . . . 24
9.1. Routing Objects . . . . . . . . . . . . . . . . . . . . . 24 8.3. NSA Object . . . . . . . . . . . . . . . . . . . . . . . . 25
9.2. Routing Object Common Header . . . . . . . . . . . . . . . 25 8.4. Hop-count Object . . . . . . . . . . . . . . . . . . . . . 25
9.3. NSA Object . . . . . . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
9.4. Hop-count Object . . . . . . . . . . . . . . . . . . . . . 26 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
9.5. DAG Information Option (DIO) suboption for the OCP 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Object . . . . . . . . . . . . . . . . . . . . . . . . . . 26 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26
9.6. Objective Code Point (OCP) Object . . . . . . . . . . . . 26 11.2. Informative References . . . . . . . . . . . . . . . . . . 26
10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 11.3. References . . . . . . . . . . . . . . . . . . . . . . . . 27
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . . 27
12.3. References . . . . . . . . . . . . . . . . . . . . . . . . 28
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], [RFC5826] and
[I-D.ietf-roll-home-routing-reqs] and
[I-D.ietf-roll-building-routing-reqs]. [I-D.ietf-roll-building-routing-reqs].
Historically, IGP such as OSPF ([RFC2328]) and IS-IS ([RFC1195]) have Historically, IGP such as OSPF ([RFC2328]) and IS-IS ([RFC1195]) have
used quantitative static link metrics. Other mechanisms such as used quantitative static link metrics. Other mechanisms such as
Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) (see Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) (see
[RFC2702] and [RFC3209]) make use of other link attributes such as [RFC2702] and [RFC3209]) make use of other link attributes such as
the available reserved bandwidth (dynamic) or link affinities the available reserved bandwidth (dynamic) or link affinities
(static) to compute constrained shortest paths for Traffic (static) to compute constrained shortest paths for Traffic
Engineering Label Switched Paths (TE LSPs). Engineering Label Switched Paths (TE LSPs).
This document specifies routing constraints and metrics to be used in This document specifies routing metrics and constraints to be used in
path calculation by the Routing Protocol for Low Power and Lossy path calculation by the Routing Protocol for Low Power and Lossy
Networks (RPL) specified in [I-D.ietf-roll-rpl]. Networks (RPL) specified in [I-D.ietf-roll-rpl].
One of the prime objectives of this document is to propose a flexible One of the prime objectives of this document is to propose a flexible
mechanism for the advertisement of routing metrics and constraints mechanism for the advertisement of routing metrics and constraints
used by RPL. Some RPL implementations may elect to adopt an used by RPL. Some RPL implementations may elect to adopt an
extremely simple approach based on the use of a single metric with no extremely simple approach based on the use of a single metric with no
constraint whereas other implementations may use a larger set of link constraint whereas other implementations may use a larger set of link
and node routing metrics and constraints. This specification and node routing metrics and constraints. This specification
provides a high degree of flexibility and new routing metrics; new provides a high degree of flexibility and a set of routing metrics
constraints could be defined in the future, as needed. and constraints. New routing metrics and constraints could be
defined in the future, as needed.
RPL is a distance vector routing protocol that builds a Directed RPL is a distance vector routing protocol that builds a Directed
Acyclic Graph (DAG) based on routing metrics and constraints. DAG Acyclic Graph (DAG) based on routing metrics and constraints. DAG
formation rules are defined in [I-D.ietf-roll-rpl]: formation rules are defined in [I-D.ietf-roll-rpl]:
o The DAG root may advertise a routing constraint used as a "filter" o The DAG root may advertise a routing constraint used as a "filter"
to prune links and nodes that do not satisfy specific properties. to prune links and nodes that do not satisfy specific properties.
For example, it may be required for the path to only traverse For example, it may be required for the path to only traverse
nodes that are main powered or links that have at least a minimum nodes that are main powered or links that have at least a minimum
reliability or a specific "color" reflecting a user defined link reliability or a specific "color" reflecting a user defined link
characteristic (e.g the link layer supports encryption). characteristic (e.g the link layer supports encryption).
o A routing metric is a quantitative value that is used to evaluate o A routing metric is a quantitative value that is used to evaluate
the path quality, also referred to as the path cost. Link and the path cost. Link and nodes metrics are usually (but not
nodes metrics are usually (but not always) additive: for example, always) additive.
the throughput or the reliability link metric can be used to
evaluate the path cost.
The best path is the path with the lowest cost with respect to some The best path is the path with the lowest cost with respect to some
metrics that satisfies all constraints (if any) and is also called metrics that satisfies all constraints (if any) and is also called
the shortest constrained path (in the presence of constraints). the shortest constrained path (in the presence of constraints).
Routing metrics can be classified according to the following set of Routing metrics can be classified according to the following set of
characteristics: characteristics:
o Link versus Node metrics o Link versus Node metrics
skipping to change at page 5, line 25 skipping to change at page 4, line 23
o Dynamic versus static o Dynamic versus static
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 [Khanna1989], with moderate success. been experimented in ARPANET 2 [Khanna1989], with moderate success.
The use of dynamic metrics is not trivial and very careful care must The use of dynamic metrics is not trivial and very careful care must
be given to the use of dynamic metrics since it may lead to potential be given to the use of dynamic metrics since it may lead to potential
routing instabilities. routing instabilities.
As pointed out in various routing requirements documents (see As pointed out in various routing requirements documents (see
[RFC5673], [I-D.ietf-roll-home-routing-reqs] [RFC5548] and [RFC5673], [RFC5826] [RFC5548] and
[I-D.ietf-roll-building-routing-reqs]), it must be possible to take [I-D.ietf-roll-building-routing-reqs]), it must be possible to take
into account a variety of node constraints/metrics during path into account a variety of node constraints/metrics during path
computation. computation.
It is also worth mentioning that it is fairly common for links in It is also worth mentioning that it is fairly common for links in
LLNs to have fast changing node and link characteristics, which must LLNs to have fast changing node and link characteristics, which must
be taken into account when specifying routing metrics. For instance, be taken into account when specifying routing metrics. For instance,
in addition to the dynamic nature of wireless connectivity, nodes' in addition to the dynamic nature of wireless connectivity, nodes'
resources such as residual energy and other link's charatacteristics resources such as residual energy and other link's charatacteristics
such as the throughput are changing continuously and may have to be such as the throughput are changing continuously and may have to be
skipping to change at page 5, line 51 skipping to change at page 4, line 49
attributes that affect routing decisions in order to preserve routing attributes that affect routing decisions in order to preserve routing
stability. Routing metrics and constraints may either be static or stability. Routing metrics and constraints may either be static or
dynamic. When dynamic, a RPL implementation SHOULD make use of a dynamic. When dynamic, a RPL implementation SHOULD make use of a
multi-threshold scheme rather than fine granular metric updates so as multi-threshold scheme rather than fine granular metric updates so as
to avoid constant routing changes. to avoid constant routing changes.
Furthermore, it is a time and energy consuming process to update Furthermore, it is a time and energy consuming process to update
dynamic metrics and recompute the routing tables on a frequent basis. dynamic metrics and recompute the routing tables on a frequent basis.
Therefore, it may be desirable to use a set of discrete values to Therefore, it may be desirable to use a set of discrete values to
reduce computational overhead and bandwidth utilization. Of course, reduce computational overhead and bandwidth utilization. Of course,
this comes with a cost, namely, reduced metric accuracy. Reliability this comes with a cost, namely, reduced metric accuracy. In other
is an example of qualitative parameters which may be used as a cases, a set of flags may be defined to reflect a node state without
routing metric by RPL. Such qualitative parameters may be having to define discrete values.
transformed to quantitative values. In other cases, a set of flags
may be defined to reflect a node state without having to define
discrete values.
Some link or node characteristics (e.g. link reliability flag, energy Some link or node characteristics (e.g. link reliability flag, energy
remaining on the node) may either be used by RPL as routing remaining on the node) may either be used by RPL as routing
constraints or metric. For example, the path may be computed to constraints or metric. For example, the path may be computed to
avoid links that do not provide a sufficient level of reliability avoid links that do not provide a sufficient level of reliability
(use as a constraint) or as the path offering the maximum number of (use as a constraint) or as the path offering the maximum number of
links with a specified reliability level (use as a metric). links with a specified reliability level (use as a metric).
It is not required to use all the metrics and attributes specified in The set of routing metrics and constraints used by an RPL
this document. The set of routing metrics and constraints used by an implementation is signalled along the Directed Acyclic Graph (DAG)
RPL implementation is signalled along the Directed Acyclic Graph that is built according to the Objective Function (rules governing
(DAG) computed by RPL via an Objective Function (OF) as described in how to build a DAG) and the routing metrics and constraints
[I-D.ietf-roll-rpl]. Indeed, RPL may be used to build DAGs with advertised in the Dag Information Option (DIO) message specified in
different characteristics. For example, it may be desirable to build [I-D.ietf-roll-rpl]. RPL may be used to build DAGs with different
a DAG trying to maximize reliability by using the link reliability characteristics. For example, it may be desirable to build a DAG
metric: in this case, the OF advertised by RPL in the Dag Information with the objective to maximize reliability by using the link
Option (DIO) message specifies an Objective Code Point (OCP) reliability metric to compute the "best" path. Another example might
indicating that the link reliability metric is the metric used to be to use the energy node characteristic (e.g. main powered versus
compute the "best" path. Another example might be to use the energy battery operated) as a node constraint when building the DAG so as to
node characteristic (e.g. main powered versus battery operated) as a avoid battery powered nodes in the DAG while optimizing the link
node constraint when building the DAG so as to avoid battery powered throughput.
nodes in the DAG. Links and nodes routing metrics and constraints
are not exclusive. Links and nodes routing metrics and constraints are not exclusive.
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 category. thus different reporting rates may be used for each category.
The specification of objective functions used to compute the DAG The specification of objective functions used to compute the DAG
built by RPL is out of the scope of this document and will be built by RPL is out of the scope of this document and will be
specified in other documents. specified in other documents. Routing metrics and constraints are
decoupled from the objective function. So a generic objective
function could for example specify the rules to select the best
parents in the DAG, the number of backup parents, etc and a generic
optimization function such as "Select the best parent as the one
providing the least cost path that meets the advertized constraints".
Such objective function could be used with a number of routing
metrics and/or contraints such as the ones specified in this
document.
Some metrics are either aggregated or recorded. In the former case, Some metrics are either aggregated or recorded. In the former case,
the metric is adjusted as the DIO message travels along the DAG. For the metric is adjusted as the DIO message travels along the DAG. For
example, if the metric is the link latency, each node updates the example, if the metric is the link latency, each node updates the
latency metric along the DAG. By contrast, metric may be recorded in latency metric along the DAG. By contrast, metric may be recorded in
which case each node adds a sub-object reflecting the local metric. which case each node adds a sub-object reflecting the local metric.
For example, it might be desirable to record the link quality level For example, it might be desirable to record the link quality level
along the path. In this case, each visited node adds a sub-object along the path. In this case, each visited node adds a sub-object
reporting the local link quality level. In order to limit the number reporting the local link quality level. In order to limit the number
of sub-objects, the use of a counter may be desirable (e.g. record of sub-objects, the use of a counter may be desirable (e.g. record
skipping to change at page 7, line 11 skipping to change at page 6, line 14
receiving the DIO message from a set of parents, a node can decide receiving the DIO message from a set of parents, a node can decide
which node to choose as a parent based on the maximum number of links which node to choose as a parent based on the maximum number of links
with a specific link reliability level for example. with a specific link reliability level for example.
Notion of local versus global metric: some routing objects may have a Notion of local versus global metric: some routing objects may have a
local or a global significance. In the former case, a metric may be local or a global significance. In the former case, a metric may be
transmitted to a neighbor to charaterize a link or a node as opposed transmitted to a neighbor to charaterize a link or a node as opposed
to a path. For example, a node may report information about its to a path. For example, a node may report information about its
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 additive 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 path latency is an aggregated global and
link metric. additive 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]. The Object Code Container object defined in [I-D.ietf-roll-rpl].
Point (OCP) object is a sub-option carried within the DIO base option
object defined in [I-D.ietf-roll-rpl].
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 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 | Option Len | DAG Metric data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 1: DAG Metric Container Format Figure 1: 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
The object body carries one or more sub-objects. The object body carries one or more sub-objects.
Note that the routing metric objects defined in this document can Note that the routing metric objects defined in this document can
appear in any order in the DAG Metric Container object with the appear in any order in the DAG Metric Container object.
exception of the Objective Function object that MUST appear first.
Routing-Ob-Type: (Routing Object Type - 8 bits): the Routing Object Routing-Ob-Type: (Routing Object Type - 8 bits): the Routing Object
Type field uniquely identifies each Routing object and is managed by Type field uniquely identifies each Routing object and is managed by
IANA. IANA.
Res flags (2 bits). Reserved field. This field MUST be set to zero Res flags (2 bits). Reserved field. This field MUST be set to zero
on transmission and MUST be ignored on receipt. on transmission and MUST be ignored on receipt.
o C Flag. When set, this indicates that the routing object refers o C Flag. When set, this indicates that the routing object refers
to a routing constraint. When cleared the routing object refers to a routing constraint. When cleared the routing object refers
to a routing metric. to a routing metric.
o O Flag: The O flag is used exclusively for routing constraints (C o O Flag: The O flag is used exclusively for routing constraints (C
flag is set) and has no meaning for routing metrics. When set, flag is set) and has no meaning for routing metrics. When set,
this indicates that the constraint is optional. When cleared, the this indicates that the constraint is optional. When cleared, the
constraint is mandatory. constraint is mandatory.
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, multiplicative, 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 * 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
skipping to change at page 8, line 45 skipping to change at page 8, line 14
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).
Example 1: A DAG formed by RPL where all nodes must be main powered Example 1: A DAG formed by RPL where all nodes must be main powered
and the link metric is the link throughput. In this case the DAG and the link metric is the link quality characterized by the ETX. In
Metric container carries two routing objects: the link metric is the this case the DAG Metric container carries two routing objects: the
link throughput (C=0, O=0, A=00, G=1, R=0) and the node constraint is link metric that is the link ETX (C=0, O=0, A=00, G=1, R=0) and the
power (C=1, O=0, A=00, G=0, R=0). Note that in this example, the node constraint is power (C=1, O=0, A=00, G=0, R=0). Note that in
link throughput is a global additive aggregated link metric. An RPL this example, the link quality is a global additive aggregated link
implementation may use the metric to report a minimum (A=01). In metric. Note that a RPL implementation may use the metric to report
this case, when the link throughput metric is processed each node a maximum (A=0x01) or a minimum (A=0x02). If the best path is
updates it is the link throughput is less than the value reported by characterized by the path avoiding low quality links for example,
the link throughput metric. then the path metric reports a maximum (A=0x02): when the link
quality metric (ETX) is processed each node updates it if the link
quality (ETX) is higher than the current value reported by the link
quality metric.
Example 2: A DAG formed by RPL where the link metric is the link Example 2: A DAG formed by RPL where the link metric is the link
quality level and link quality levels must be recorded along the quality level and link quality levels must be recorded along the
path. In this case the DAG Metric container carries one routing path. In this case the DAG Metric container carries a series of
object: the link quality level (C=0, O=0, A=00, G=1, R=1). routing objects: link quality level (C=0, O=0, A=00, G=1, R=1)
routing metrics.
A Routing object may also include one or more type-length-value (TLV) A Routing object may also include one or more type-length-value (TLV)
encoded data sets. Each Routing TLV has the same structure: encoded data sets. Each Routing TLV has the same structure:
Type: 2 bytes Type: 1 bytes
Length: 2 bytes Length: 1 bytes
Value: variable Value: variable
A Routing metric TLV is comprised of 2 bytes for the type, 2 bytes A Routing metric TLV is comprised of 1 bytes for the type, 1 bytes
specifying the TLV length, and a value field. specifying the TLV length, and a value field.
The Length field defines the length of the value portion in bytes. The Length field defines the length of the value portion in bytes.
Unrecognized TLVs MUST be ignored. Unrecognized TLVs MUST be ignored.
IANA management of the routing metric objects identifier codespace is IANA management of the routing metric objects identifier codespace is
described in Section 9. described in Section 8.
3. Node Metrics And Constraints Objects 3. Node Metrics And Constraints Objects
It is fairly common for LLNs to be made of nodes with heterogeneous It is fairly common for LLNs to be made of nodes with heterogeneous
attributes and capabilities (e.g. nodes being battery operated or attributes and capabilities (e.g. nodes being battery operated or
not, amount of memory, etc). More capable and stable nodes may not, amount of memory, etc). More capable and stable nodes may
assist the most constrained ones for routing packets, which results assist the most constrained ones for routing packets, which results
in extension of network lifetime and efficient network operations. in extension of network lifetime and efficient network operations.
This is a typical use of constraint-based routing where the computed This is a typical use of constraint-based routing where the computed
path may not be the shortest path according to some specified path may not be the shortest path according to some specified
skipping to change at page 18, line 25 skipping to change at page 18, line 10
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 2 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.
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
skipping to change at page 19, line 18 skipping to change at page 18, line 48
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Aggregated LQL Value | | Aggregated LQL Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 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
ignoring undetermined LQLs (Aggregated LQL Value = 0). When used to
report a maximum (A=0x01), the field reports the maximum LQL value of
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
undetermined (LQL=0), the undetermined LQL will be ignored and not be
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.
For example, an implementation may use the following formula: ETX= 1 For example, an implementation may use the following formula: ETX= 1
/ (Df * Dr) where Df is the measured probability that a packet is / (Df * Dr) where Df is the measured probability that a packet is
received by the neighbor and Dr is the measured probability that the received by the neighbor and Dr is the measured probability that the
skipping to change at page 21, line 25 skipping to change at page 21, line 25
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 2 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
skipping to change at page 23, line 13 skipping to change at page 23, line 13
using dynamic metrics are out the scope of this document, the using dynamic metrics are out the scope of this document, the
objective function should be designed carefully to avoid too frequent objective function should be designed carefully to avoid too frequent
computation of new routes upon metric values changes. computation of new routes upon metric values changes.
Controlled adaptation of the routing metrics and rate at which paths Controlled adaptation of the routing metrics and rate at which paths
are computed are critical to avoid undesirable routing instabilities are computed are critical to avoid undesirable routing instabilities
resulting in increased latencies and packet loss because of temporary resulting in increased latencies and packet loss because of temporary
micro-loops. Furthermore, excessive route changes will impact the micro-loops. Furthermore, excessive route changes will impact the
traffic and power consumption in the network adversely. traffic and power consumption in the network adversely.
6. Objective Function 6. Use of Multiple Dag Metric Container
The Objective Function (OF) is used by RPL to specify how the routing
metric and constraints should be used to reach specific objectives.
For example, the OF may specify that the objective is to find the
constrained shortest path where the constraint is related to the node
power mode and the metric is the ETX (e.g. "Avoid battery operated
links and compute the path that optimizes reliability"). As
specified in [I-D.ietf-roll-rpl], the OF is used by a node to select
its parent during the DAG building construction process.
The OCP object is used to specify the OF and is carried as a sub-
option within the DIO Base Option object defined in
[I-D.ietf-roll-rpl].
There MUST be a single instance of the OCP object within the sub-
option field of the DIO Base option object.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| OCP | (TLVs)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 19: OCP Object Format
The OCP object suboption type is 5 (to be confirmed by IANA).
The OCP object body may carry optional TLVs. No TLVs are currently
defined.
OCP (Objective Code Point - 16 bits): the OCP field identifies the OF
and is managed by IANA.
7. Open Issues
Other items to be addressed in further revisions of this document
include:
7.1. Other metric under consideration
Metrics related to security (e.g. capability to avoid a node that has Since RPL options lenght are coded using 1 octet, their lenght cannot
not been authorized or authenticated). exceed 256 bytes, which also applies to the DAG Metric Container.
Although in the vast majority of the cases, the advertized routing
metrics and constraints will not require that much space, there might
be circumstances where larger space will be required, should for
example a set of routing metrics be recorded along a long path. In
this case, as specified in [I-D.ietf-roll-rpl], routing metrics will
be carried using multiple DAG Metric Containers.
8. Metric Consistency 7. Metric Consistency
Since a set of metrics and constraints will be used for links and Since a set of metrics and constraints will be used for links and
nodes in LLN, it is particularly critical to ensure the use of nodes in LLN, it is particularly critical to ensure the use of
consistent metric calculation mechanisms for all links and nodes in consistent metric calculation mechanisms for all links and nodes in
the network. the network.
9. IANA Considerations 8. IANA Considerations
IANA is requested to establish a new top-level registry to contain IANA is requested to establish a new top-level registry to contain
all Routing Objects codepoints and sub-registries. all Routing Objects codepoints and sub-registries.
The allocation policy for each new registry is by IETF Consensus: new The allocation policy for each new registry is by IETF Consensus: new
values are assigned through the IETF consensus process (see values are assigned through the IETF consensus process (see
[RFC5226]). Specifically, new assignments are made via RFCs approved [RFC5226]). Specifically, new assignments are made via RFCs approved
by the IESG. Typically, the IESG will seek input on prospective by the IESG. Typically, the IESG will seek input on prospective
assignments from appropriate persons (e.g., a relevant Working Group assignments from appropriate persons (e.g., a relevant Working Group
if one exists). if one exists).
9.1. Routing Objects 8.1. Routing Objects
IANA is requested to create a registry for Routing objects. Each IANA is requested to create a registry for Routing objects. Each
Routing object has a Routing object type value. Routing object has a Routing object type value.
Value Meaning Reference Value Meaning Reference
1 Node State and Attribute This document 1 Node State and Attribute This document
2 Node Energy This document 2 Node Energy This document
3 Hop Count This document 3 Hop Count This document
4 Link Throughput This document 4 Link Throughput This document
5 Link Latency This document 5 Link Latency This document
6 Link Quality Level This document 6 Link Quality Level This document
7 Link ETX This document 7 Link ETX This document
8 Link Color This document 8 Link Color This document
9.2. Routing Object Common Header 8.2. Routing Object Common Header
IANA is requested to create a registry to manage the codespace of A IANA is requested to create a registry to manage the codespace of 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 1 Routing metric reports a maximum This document
3 Routing metric reports a minimum This document 2 Routing metric reports a minimum This document
4 Routing metric is multiplicative This document 3 Routing metric is multiplicative This document
IANA is requested to create a registry to manage the Flag field of IANA is requested to create a registry to manage the Flag field of
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 25, line 38 skipping to change at page 25, line 10
o Defining RFC o Defining RFC
Several bits are defined for the Routing metric common header in this Several bits are defined for the Routing metric common header in this
document. The following values have been assigned: document. The following values have been assigned:
Codespace of the Flag field (Routing common header) Codespace of the Flag field (Routing common header)
Bit Description Reference Bit Description Reference
8 Constraint/metric This document 8 Constraint/metric This document
7 Optional Constraint This document 7 Optional Constraint This document
5-6 Additive/Max/Min This document 5-6 Additive/Max/Min/Multi This document
4 Global/Local This document 4 Global/Local This document
3 Recorded/Aggregated This document 3 Recorded/Aggregated This document
9.3. NSA Object 8.3. NSA Object
IANA is requested to create a registry to manage the codespace of the IANA is requested to create a registry to manage the codespace of the
Flag field of the NSA Object. Flag field of the NSA Object.
New bit numbers may be allocated only by an IETF Consensus action. New bit numbers may be allocated only by an IETF Consensus action.
Each bit should be tracked with the following qualities: Each bit should be tracked with the following qualities:
o Bit number o Bit number
o Capability Description o Capability Description
o Defining RFC o Defining RFC
Several bits are defined for the NSA Object flag field in this Several bits are defined for the NSA Object flag field in this
document. The following values have been assigned: document. The following values have been assigned:
Codespace of the Flag field (NSA Object) Codespace of the Flag field (NSA Object)
Bit Description Reference Bit Description Reference
skipping to change at page 26, line 17 skipping to change at page 25, line 37
Several bits are defined for the NSA Object flag field in this Several bits are defined for the NSA Object flag field in this
document. The following values have been assigned: document. The following values have been assigned:
Codespace of the Flag field (NSA Object) Codespace of the Flag field (NSA Object)
Bit Description Reference Bit Description Reference
14 Aggregator This document 14 Aggregator This document
15 Overloaded This document 15 Overloaded This document
9.4. Hop-count Object 8.4. Hop-count Object
IANA is requested to create a registry to manage the codespace of the IANA is requested to create a registry to manage the codespace of the
Flag field of the Hop-count Object. Flag field of the Hop-count Object.
New bit numbers may be allocated only by an IETF Consensus action. New bit numbers may be allocated only by an IETF Consensus action.
Each bit should be tracked with the following qualities: Each bit should be tracked with the following qualities:
o Bit number o Bit number
o Capability Description o Capability Description
o Defining RFC o Defining RFC
No Flags are currently defined. No Flags are currently defined.
9.5. DAG Information Option (DIO) suboption for the OCP Object 9. Security Considerations
A new DAG Information Option (DIO) suboption is defined for the OCP
object.
DIO suboption for the OCP Object
Value Description Reference
5 OCP Value This document
9.6. Objective Code Point (OCP) Object
IANA is requested to create a registry to manage the codespace of the
OCP field of the OCP object.
No OCP codepoints are defined in this specification.
10. Security Considerations
Routing metrics should be handled in a secure and trustful manner. Routing metrics should be handled in a secure and trustful manner.
For instance, a malicious node can not advertise falsely that it has For instance, 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 10. 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, Tim Winter, Mukul Thubert, Richard Kelsey, Jonathan Hui, Phil Levis, Tim Winter, Mukul
Goyal, Yoav Ben-Yehezkel and Matteo Paris for their review and Goyal, Yoav Ben-Yehezkel, Matteo Paris, Omprakash Gnawali, Mads
comments. Westergreen and Mukul Goyal for their review and comments.
12. References 11. References
12.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
12.2. Informative References 11.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-09 Lossy Networks", draft-ietf-roll-building-routing-reqs-09
(work in progress), January 2010. (work in progress), January 2010.
[I-D.ietf-roll-home-routing-reqs]
Brandt, A. and J. Buron, "Home Automation Routing
Requirements in Low Power and Lossy Networks",
draft-ietf-roll-home-routing-reqs-11 (work in progress),
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-08 (work in progress), May 2010.
[I-D.ietf-roll-terminology] [I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-03 (work in Networks", draft-ietf-roll-terminology-03 (work in
progress), March 2010. 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.
skipping to change at page 28, line 33 skipping to change at page 27, line 27
January 2003. January 2003.
[RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
"Routing Requirements for Urban Low-Power and Lossy "Routing Requirements for Urban Low-Power and Lossy
Networks", RFC 5548, May 2009. Networks", RFC 5548, May 2009.
[RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney,
"Industrial Routing Requirements in Low-Power and Lossy "Industrial Routing Requirements in Low-Power and Lossy
Networks", RFC 5673, October 2009. Networks", RFC 5673, October 2009.
12.3. References [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low-Power and Lossy Networks",
RFC 5826, April 2010.
11.3. References
[IEEE.754.1985] [IEEE.754.1985]
IEEE Standard 754, "Standard for Binary Floating-Point IEEE Standard 754, "Standard for Binary Floating-Point
Arithmetic", August 1985. Arithmetic", August 1985.
Authors' Addresses Authors' Addresses
JP Vasseur (editor) JP Vasseur (editor)
Cisco Systems, Inc Cisco Systems, Inc
11, Rue Camille Desmoulins 11, Rue Camille Desmoulins
 End of changes. 51 change blocks. 
175 lines changed or deleted 129 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/