draft-ietf-roll-of0-05.txt   draft-ietf-roll-of0-06.txt 
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track January 5, 2011 Intended status: Standards Track March 13, 2011
Expires: July 9, 2011 Expires: September 14, 2011
RPL Objective Function 0 RPL Objective Function 0
draft-ietf-roll-of0-05 draft-ietf-roll-of0-06
Abstract Abstract
The Routing Protocol for Low Power and Lossy Networks (RPL) defines a The Routing Protocol for Low Power and Lossy Networks (RPL) defines a
generic Distance Vector protocol for Low Power and Lossy Networks generic Distance Vector protocol for Low Power and Lossy Networks
(LLNs). RPL is instantiated to honor a particular routing objective/ (LLNs). RPL is instantiated to honor a particular routing objective/
constraint by the adding a specific Objective Function (OF) that is constraint by the adding a specific Objective Function (OF) that is
designed to solve that problem. This specification defines a basic designed to solve that problem. This specification defines a basic
OF, OF0, that uses only the abstract properties exposed in RPL OF, OF0, that uses only the abstract properties exposed in RPL
messages with no metric container. messages with no metric container.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 July 9, 2011. This Internet-Draft will expire on September 14, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Selection of the Preferred Parent . . . . . . . . . . . . . . . 5 4. Selection of the Preferred Parent . . . . . . . . . . . . . . 6
5. Selection of the Backup next_hop . . . . . . . . . . . . . . . 6 5. Selection of the Backup next_hop . . . . . . . . . . . . . . . 7
6. Abstract Interface with RPL core . . . . . . . . . . . . . . . 7 6. Abstract Interface with RPL core . . . . . . . . . . . . . . . 7
7. OF0 Constants and Variables . . . . . . . . . . . . . . . . . . 7 7. OF0 Constants and Variables . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . . 8 11.2. Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The IETF ROLL Working Group has defined application-specific routing The IETF ROLL Working Group has defined application-specific routing
requirements for a Low Power and Lossy Network (LLN) routing requirements for a Low Power and Lossy Network (LLN) routing
protocol, specified in [I-D.ietf-roll-building-routing-reqs], protocol, specified in [I-D.ietf-roll-building-routing-reqs],
[I-D.ietf-roll-home-routing-reqs], [RFC5673], and [RFC5548]. [I-D.ietf-roll-home-routing-reqs], [RFC5673], and [RFC5548].
Considering the wide variety of use cases, link types and metrics, Considering the wide variety of use cases, link types and metrics,
the Routing Protocol for Low Power and Lossy Networks the Routing Protocol for Low Power and Lossy Networks
[I-D.ietf-roll-rpl] was designed as a generic core that is agnostic [I-D.ietf-roll-rpl] was designed as a generic core that is agnostic
to metrics and instantiated using Objective Functions. to metrics and instantiated using Objective Functions.
RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs) RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs)
within instances of the protocol, each instance being set up to honor within instances of the protocol, each instance being set up to honor
a particular routing objective/constraint of a given deployment. a particular routing objective/constraint of a given deployment.
This instantiation is achieved by plugging into the RPL core a This instantiation is achieved by plugging into the RPL core a
specific Objective Function (OF) that is designed to solve that specific Objective Function (OF) that is designed to solve that
problem to be addressed by that instance. problem to be addressed by that instance.
the Objective Function selects the DODAG iteration that a device An Objective Function selects the DODAG version that a device joins,
joins, and a number of neighbor routers within that iteration as and a number of neighbor routers within that version as parents and
parents and siblings. The OF is also responsible for computing the siblings. The OF is also responsible for computing the Rank of the
Rank of the device, that abstracts a relative position within the device, that abstracts a relative position within the DODAG and is
DODAG and is used by the RPL core to enable a degree of loop used by the RPL core to enable a degree of loop avoidance and verify
avoidance and verify forward progression towards a destination, as forward progression towards a destination, as specified in
specified in [I-D.ietf-roll-rpl]. [I-D.ietf-roll-rpl].
It is the general design in RPL that the metrics are passed from Since there is no default OF or metric container in the RPL main
parent to children in a specific container and that the OF will specification, it might happen that, unless given two implementations
follow a same guidance for a specific problem or environment, those
implementations will not support a common OF with which they could
interoperate. This specification fills the need for an Objective
Function that can be used as a common denominator between all generic
implementations. This is why OF0 is very abstract as to how the link
properties are transformed into a Rank, giving only normalized values
for what a normal link and what the acceptable range is for a step of
Rank are, as opposed to formulating the details of the step of Rank
computation.
Indeed, it is the general design in RPL that the metrics are passed
from parent to children in a specific container and that the OF will
derive the Rank from the natural metric. The separation of Rank and derive the Rank from the natural metric. The separation of Rank and
metrics avoids a loss of information as the various metrics are metrics avoids a loss of information as the various metrics are
propagated down the DAG. It might happen, though, that the metric is propagated down the DAG. This specification can be used when the
so simple that it can be turned in a scalar Rank in a reversible link properties that are considered are such that they can be turned
fashion. Since there is no default OF or metric in RPL, it might in a scalar step of Rank in a reversible fashion and the resulting
also happen that two implementations do not support a common OF or step of rank is additive over multiple hops.
the same metric information with which they could interoperate.
There is thus a need for a Last Resort Objective Function that could
be used as a minimalistic common denominator.
This specification proposes such a last resort OF, Objective Function The Objective Function 0 (OF0) corresponds to the Objective Code
0 (OF0), that corresponds to the Objective Code Point 0. OF0 does Point 0 (OCP0). OF0 does not leverage metric containers such as
not leverage metric containers such as described in the metrics draft described in the metrics draft [I-D.ietf-roll-routing-metrics]. OF0
[I-D.ietf-roll-routing-metrics], but is only based on abstract does not require information in the RPL messages but the abstract
information from the DIO base container, such as Rank and an information from the DIO base container, such as Rank and an
administrative preference, that is transported in DIOs as administrative preference, that is transported in DIOs as
DODAGPreference in [I-D.ietf-roll-rpl]. OF0 uses a DODAGPreference in [I-D.ietf-roll-rpl]. The Rank of a node is
MinHopRankIncrease of 0x100 so that Rank value can be stored in one obtained by adding a step of Rank multiplied by a Rank Factor to the
octet. This allows up to at least 16 hops when each hop has the Rank of a selected preferred parent. OF0 uses a MinHopRankIncrease
worst Rank Increment of 16. How the link properties are transformed of 0x100 so that Rank value can be stored in one octet. This allows
into a Rank Increment for a given hop depends on the link type and on up to at least 28 hops even when each hop has the worst step of Rank
of 9 and a Rank Factor of 1. How the link properties are transformed
into a step of Rank for a given hop depends on the link type and on
the implementation. It can be as simple as an administrative cost, the implementation. It can be as simple as an administrative cost,
but might also derive from a statistical metric with some hysteresis. but might also derive from a statistical metric with some hysteresis.
2. Terminology 2. Terminology
The terminology used in this document is consistent with and The terminology used in this document is consistent with and
incorporates that described in `Terminology in Low power And Lossy incorporates that described in `Terminology in Low power And Lossy
Networks' [I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl]. Networks' [I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl].
3. Goal 3. Goal
The Goal of the OF0 is to join a DODAG iteration that offers The Goal of the OF0 is to join a DODAG version that offers
connectivity to a specific set of nodes or to a larger routing connectivity to a specific set of nodes or to a larger routing
infrastructure. For the purpose of OF0, Grounded thus means that the infrastructure. For the purpose of OF0, Grounded thus means that the
root provides such connectivity. How that connectivity is asserted root provides such connectivity. How that connectivity is asserted
and maintained is out of scope. and maintained is out of scope.
Objective Function 0 is designed to find the nearest Grounded root. Objective Function 0 is designed to find the nearest Grounded root.
In the absence of a Grounded root, LLN inner connectivity is still In the absence of a Grounded root, LLN inner connectivity is still
desirable and floating DAGs will form, rooted at the nodes with the desirable and floating DAGs will form, rooted at the nodes with the
highest administrative preference. highest administrative preference.
The metric used in OF0 is an administratively defined scalar cost The metric used in OF0 can be an administratively defined scalar cost
that is trivially added up along a path to compute the RPL Rank, as that is trivially added up along a path to compute the RPL Rank, as
defined in [I-D.ietf-roll-rpl]. As a result, the Rank if a node is defined in [I-D.ietf-roll-rpl]. Depending on how the step of Rank is
analogous to a weighted hop count of the path to the root. Using a computed by an implementation, the Rank of a node might be analogous
metric that in essence is similar to hop count implies that the to a weighted hop count of the path to the root. Using a metric that
quality of the connectivity should be asserted so that only neighbors in essence is similar to hop count implies that the quality of the
with a good enough connectivity are presented to the OF. How that connectivity should be asserted so that only neighbors with a good
connectivity is asserted and maintained is out of scope. enough connectivity are presented to the OF. How that connectivity
is asserted and maintained is not covered by this specification.
Hop count used in wireless networks will tend to favor paths with In wireless networks, Hop Count will tend to favor paths with long
long distance links and non optimal connectivity properties. As a distance links and non optimal connectivity properties. In some
result, the link selection must be very conservative, and the situations, this might end up partitioning the network. As a result,
available link set is thus constrained. In some situations, this the link selection must be very conservative, and the available link
might end up partitioning the network. For those reasons, though it set is thus constrained. For those reasons, though it can be used on
can be used on wired links and wired link emulations such as WIFI wired links and wired link emulations such as WIFI infrastructure
infrastructure mode, OF0 is generally not recommended for wireless mode, a metric derived from hop count is generally not recommended
networks. for wireless networks. Instead, careful thinking should be applied
to determine how the step of Rank is computed from the link
properties and attention should be paid to maintain a certain
stability in the resulting Rank.
The default step of Rank is DEFAULT_RANK_INCREMENT for each hop. An The default step of Rank is DEFAULT_RANK_INCREMENT for each hop. An
implementation MAY allow a step between MINIMUM_RANK_INCREMENT and implementation MAY allow a step between MINIMUM_RANK_INCREMENT and
MAXIMUM_RANK_INCREMENT to reflect a large variation of link quality MAXIMUM_RANK_INCREMENT to reflect a large variation of link quality
by units of MINIMUM_RANK_INCREMENT. In other words, the least by units of MINIMUM_RANK_INCREMENT. In other words, the least
significant octet in the Rank is not used. significant octet in the Rank is not used.
It MAY stretch its step of Rank by up to MAXIMUM_RANK_STRETCH in A node MAY stretch its step of Rank by up to MAXIMUM_RANK_STRETCH in
order to enable the selection of a sibling when only one parent is order to enable the selection of a sibling when only one parent is
available. For instance, say that a node computes a step of Rank of available. For instance, say that a node computes a step of Rank of
4 units of MINIMUM_RANK_INCREMENT from a preferred parent with a Rank 4 units of MINIMUM_RANK_INCREMENT from a preferred parent with a Rank
of 6 units resulting in a Rank of 10 units for this node. Say that of 6 units resulting in a Rank of 10 units for this node. Say that
with that Rank of 10 units, this node would end up with only one with that Rank of 10 units, this node would end up with only one
parent and no sibling, though there is a neighbor with a Rank of 12 parent and no sibling, though there is a neighbor with a Rank of 12
units. In that case, the node is entitled to stretch its step of units. In that case, the node is entitled to stretch its step of
Rank by a value of 2 units, thus using a step of Rank of 6 units so Rank by a value of 2 units, thus using a step of Rank of 6 units so
as to reach a Rank of 12 units and find a sibling. But the node is as to reach a Rank of 12 units and find a sibling. But the node is
not entitled to use a step of Rank larger than 6 units since that not entitled to use a step of Rank larger than 6 units since that
would be a greedy behavior that would deprive the neighbor of this would be a greedy behavior that would deprive the neighbor of this
node of a successor. Also, if the neighbor had exposed a Rank of 16 node of a successor. Also, if the neighbor had exposed a Rank of 16
units, the stretch of Rank from 10 to 16 units would have exceeded units, the stretch of Rank from 10 to 16 units would have exceeded
MAXIMUM_RANK_STRETCH of 4 units and thus the neighbor would not have MAXIMUM_RANK_STRETCH of 5 units and thus the neighbor would not have
been selectable even as a sibling. been selectable even as a sibling.
The gap between MINIMUM_RANK_INCREMENT and MAXIMUM_RANK_STRETCH may
not be sufficient in every case to strongly distinguish links of
different types or categories in order to favor, say, powered over
battery-operated or wired over wireless, within a same DAG. An
implementation SHOULD allow a configurable factor called Rank Factor
and to apply the factor on all links and peers. An implementation
MAY recognizes sub-categories of peers and links, such as different
MAC types, in which case it SHOULD be able to configure a more
specific Rank Factor to those categories. The Rank Factor SHOULD be
set between MINIMUM_RANK_FACTOR and MAXIMUM_RANK_FACTOR. Once a step
of Rank is computed along the rules specified in this document, the
result of the computation is multipled by the Rank Factor and the
result is what gets added to the Rank of preferred parent in order to
obtain the Rank of this node.
Optionally, the administrative preference of a root MAY be configured Optionally, the administrative preference of a root MAY be configured
to supercede the goal to reach Grounded root. In that case, nodes to supercede the goal to reach Grounded root. In that case, nodes
will associate to the root with the highest preference available, will associate to the root with the highest preference available,
regardless of whether that root is Grounded or not. Compared to a regardless of whether that root is Grounded or not. Compared to a
deployment with a multitude of Grounded roots that would result in a deployment with a multitude of Grounded roots that would result in a
same multitude of DODAGs, such a configuration may result in possibly same multitude of DODAGs, such a configuration may result in possibly
less but larger DODAGs, as many as roots configured with the highest less but larger DODAGs, as many as roots configured with the highest
priority in the reachable vincinity. priority in the reachable vincinity.
OF0 selects a preferred parent and a backup next_hop if one is OF0 selects a preferred parent and a backup next_hop if one is
skipping to change at page 5, line 45 skipping to change at page 6, line 27
conditions do not let a packet through the preferred parent, the conditions do not let a packet through the preferred parent, the
packet is passed to the backup next_hop. packet is passed to the backup next_hop.
4. Selection of the Preferred Parent 4. Selection of the Preferred Parent
As it scans all the candidate neighbors, OF0 keeps the parent that is As it scans all the candidate neighbors, OF0 keeps the parent that is
the best for the following criteria (in order): the best for the following criteria (in order):
1. [I-D.ietf-roll-rpl] spells out the generic rules for a node to 1. [I-D.ietf-roll-rpl] spells out the generic rules for a node to
reparent and in particular the boundaries to augment its Rank reparent and in particular the boundaries to augment its Rank
within a DODAG iteration. A candidate that would not satisfy within a DODAG version. A candidate that would not satisfy
those rules MUST NOT be considered. those rules MUST NOT be considered.
2. An implementation should validate a router prior to selecting it 2. An implementation should validate a router prior to selecting it
as preferred. This validation process is implementation and as preferred. This validation process is implementation and
link type dependent, and is out of scope. A router that has link type dependent, and is out of scope. A router that has
been validated is preferrable. been validated is preferrable.
3. When multiple interfaces are available, a policy might be 3. When multiple interfaces are available, a policy might be
locally configured to prioritize them and that policy applies locally configured to prioritize them and that policy applies
first; that is a router on a higher order interface is first; that is a router on a higher order interface is
preferable. preferable.
4. In the absence of a Grounded DODAG iteration, the router with a 4. In the absence of a Grounded DODAG version, the router with a
higher administrative preference SHOULD be preferred. higher administrative preference SHOULD be preferred.
Optionally, this selection applies regardless of whether the Optionally, this selection applies regardless of whether the
DODAG is Grounded or not. DODAG is Grounded or not.
5. A router that offers connectivity to a grounded DODAG iteration 5. A router that offers connectivity to a grounded DODAG version
SHOULD be preferred over one that does not. SHOULD be preferred over one that does not.
6. When comparing 2 routers that belong to the same DODAG, a router 6. When comparing 2 routers that belong to the same DODAG, a router
that offers connectivity to the freshest sequence SHOULD be that offers connectivity to the freshest sequence SHOULD be
preferred. preferred.
7. When computing a resulting Rank for this node from a parent Rank 7. When computing a resulting Rank for this node from a parent Rank
and a Step of Rank from that parent, the parent that causes the and a Step of Rank from that parent, the parent that causes the
lesser resulting Rank SHOULD be preferred. lesser resulting Rank SHOULD be preferred.
8. A DODAG iteration for which there is an alternate parent SHOULD 8. A DODAG version for which there is an alternate parent SHOULD be
be preferred. This check is optional. It is performed by preferred. This check is optional. It is performed by
computing the backup next_hop while assuming that the router computing the backup next_hop while assuming that the router
that is currently examined is finally selected as preferred that is currently examined is finally selected as preferred
parent. parent.
9. The DODAG iteration that was in use already SHOULD be preferred. 9. The DODAG version that was in use already SHOULD be preferred.
10. The preferred parent that was in use already SHOULD be 10. The preferred parent that was in use already SHOULD be
preferred. preferred.
11. A router that has announced a DIO message more recently SHOULD 11. A router that has announced a DIO message more recently SHOULD
be preferred. be preferred.
5. Selection of the Backup next_hop 5. Selection of the Backup next_hop
o When multiple interfaces are available, a router on a higher order o When multiple interfaces are available, a router on a higher order
interface is preferable. interface is preferable.
o The preferred parent MUST be ignored. o The backup next_hop MUST NOT be the preferred parent.
o A Router that is not in the same DODAG as the preferred parent, o The backup next_hop MUST be either in the same DODAG version as
either in the current or a subsequent iteration, MUST be ignored. the preferred parent or in an subsequent version.
o A Router with a Rank that is higher than the Rank computed for o A Router with a Rank that is higher than the Rank computed for
this node out of the preferred parent SHOULD NOT be selected as this node out of the preferred parent SHOULD NOT be selected as
parent, to avoid greedy behaviors. It MAY still be selected as parent, to avoid greedy behaviors. It MAY still be selected as
sibling if no better Back-up next hop is found. sibling if no better Back-up next hop is found.
o A router with a lesser Rank SHOULD be preferred. o A router with a lesser Rank SHOULD be preferred.
o A router that has been validated as usable by an implementation o A router that has been validated as usable by an implementation
dependant validation process SHOULD be preferred. dependant validation process SHOULD be preferred.
skipping to change at page 7, line 37 skipping to change at page 8, line 20
the DAG information for a given instance to the RPL core. the DAG information for a given instance to the RPL core.
This includes the material that is contained in a DIO base This includes the material that is contained in a DIO base
header. header.
Providing a Parent List The OF0 support can be required to provide Providing a Parent List The OF0 support can be required to provide
the list of the parents for a given instance to the RPL the list of the parents for a given instance to the RPL
core. This includes the material that is contained in the core. This includes the material that is contained in the
transit option for that parent. transit option for that parent.
Trigger The OF0 support may trigger the RPL core to inform it that Trigger The OF0 support may trigger the RPL core to inform it that
a change occurred. This indicates whether the change a change occurred. This can be used to indicate whether
requires a new DIO to be fired, trickle timers to be the change requires a new DIO to be fired or whether
reset, etc... trickle timers need to be reset.
7. OF0 Constants and Variables 7. OF0 Constants and Variables
OF0 uses the following constants: OF0 uses the following constants:
MinHopRankIncrease: 256 MinHopRankIncrease: 256
DEFAULT_RANK_INCREMENT: 4 * MinHopRankIncrease DEFAULT_RANK_INCREMENT: 3 * MinHopRankIncrease
MINIMUM_RANK_INCREMENT: 1 * MinHopRankIncrease MINIMUM_RANK_INCREMENT: 1 * MinHopRankIncrease
MAXIMUM_RANK_INCREMENT: 16 * MinHopRankIncrease MAXIMUM_RANK_INCREMENT: 9 * MinHopRankIncrease
MAXIMUM_RANK_STRETCH: 4 * MinHopRankIncrease MAXIMUM_RANK_STRETCH: 5 * MinHopRankIncrease
DEFAULT_RANK_FACTOR: 1
MINIMUM_RANK_FACTOR: 1
MAXIMUM_RANK_FACTOR: 4
8. IANA Considerations 8. IANA Considerations
IThis specification requires the assignment of an OCP for OF0. The IThis specification requires the assignment of an OCP for OF0. The
value of 0 is suggested. value of 0 is suggested.
9. Security Considerations 9. Security Considerations
Security Considerations for OCP/OF are to be developed in accordance Security Considerations for OCP/OF are to be developed in accordance
with recommendations laid out in, for example, with recommendations laid out in, for example,
[I-D.tsao-roll-security-framework]. [I-D.tsao-roll-security-framework].
10. Acknowledgements 10. Acknowledgements
Most specific thanks to Tim Winter, JP Vasseur, Julien Abeille, Most specific thanks to Philip Levis for his help in finalizing this
Mathilde Durvy, Teco Boot, Navneet Agarwal and Henning Rogge for in- document, in particular WRT wireless links, to Tim Winter, JP
depth review and first hand implementer's feedback. Vasseur, Julien Abeille, Mathilde Durvy, Teco Boot, Navneet Agarwal
and Henning Rogge for in-depth review and first hand implementer's
feedback.
11. References 11. References
11.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.
11.2. Informative References 11.2. Informative References
skipping to change at page 9, line 9 skipping to change at page 9, line 44
[I-D.ietf-roll-home-routing-reqs] [I-D.ietf-roll-home-routing-reqs]
Brandt, A., Buron, J., and G. Porcu, "Home Automation Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low Power and Lossy Networks", Routing Requirements in Low Power and Lossy Networks",
draft-ietf-roll-home-routing-reqs-08 (work in progress), draft-ietf-roll-home-routing-reqs-08 (work in progress),
September 2009. September 2009.
[I-D.ietf-roll-routing-metrics] [I-D.ietf-roll-routing-metrics]
Vasseur, J., Kim, M., Pister, K., Dejean, N., and D. Vasseur, J., Kim, M., Pister, K., Dejean, N., and D.
Barthel, "Routing Metrics used for Path Calculation in Low Barthel, "Routing Metrics used for Path Calculation in Low
Power and Lossy Networks", Power and Lossy Networks",
draft-ietf-roll-routing-metrics-14 (work in progress), draft-ietf-roll-routing-metrics-19 (work in progress),
December 2010. March 2011.
[I-D.ietf-roll-rpl] [I-D.ietf-roll-rpl]
Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
Vasseur, "RPL: IPv6 Routing Protocol for Low power and Vasseur, "RPL: IPv6 Routing Protocol for Low power and
Lossy Networks", draft-ietf-roll-rpl-17 (work in Lossy Networks", draft-ietf-roll-rpl-18 (work in
progress), December 2010. progress), February 2011.
[I-D.ietf-roll-terminology] [I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-04 (work in Networks", draft-ietf-roll-terminology-04 (work in
progress), September 2010. progress), September 2010.
[I-D.tsao-roll-security-framework] [I-D.tsao-roll-security-framework]
Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A
Security Framework for Routing over Low Power and Lossy Security Framework for Routing over Low Power and Lossy
Networks", draft-tsao-roll-security-framework-02 (work in Networks", draft-tsao-roll-security-framework-02 (work in
 End of changes. 30 change blocks. 
83 lines changed or deleted 122 lines changed or added

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