draft-ietf-roll-minrank-hysteresis-of-07.txt | draft-ietf-roll-minrank-hysteresis-of-08.txt | |||
---|---|---|---|---|
Networking Working Group O. Gnawali | Networking Working Group O. Gnawali | |||
Internet-Draft P. Levis | Internet-Draft University of Houston | |||
Intended status: Standards Track Stanford University | Intended status: Standards Track P. Levis | |||
Expires: September 10, 2012 March 9, 2012 | Expires: October 22, 2012 Stanford University | |||
April 20, 2012 | ||||
The Minimum Rank with Hysteresis Objective Function | The Minimum Rank with Hysteresis Objective Function | |||
draft-ietf-roll-minrank-hysteresis-of-07 | draft-ietf-roll-minrank-hysteresis-of-08 | |||
Abstract | Abstract | |||
The Routing Protocol for Low Power and Lossy Networks (RPL) uses | The Routing Protocol for Low Power and Lossy Networks (RPL) uses | |||
objective functions to construct routes that optimize or constrain | objective functions to construct routes that optimize or constrain | |||
the routes it selects and uses. This specification describes the | the routes it selects and uses. This specification describes the | |||
Minimum Rank Objective Function with Hysteresis (MRHOF), an objective | Minimum Rank with Hysteresis Objective Function (MRHOF), an objective | |||
function that selects routes that minimize a metric, while using | function that selects routes that minimize a metric, while using | |||
hysteresis to reduce churn in response to small metric changes. | hysteresis to reduce churn in response to small metric changes. | |||
MRHOF works with metrics that are additive along a route, and the | MRHOF works with metrics that are additive along a route, and the | |||
metric it uses is determined by the metrics RPL Destination | metric it uses is determined by the metrics RPL Destination | |||
Information Object (DIO) messages advertise. | Information Object (DIO) messages advertise. | |||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
skipping to change at page 1, line 38 | skipping to change at page 1, line 39 | |||
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 September 10, 2012. | This Internet-Draft will expire on October 22, 2012. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2012 IETF Trust and the persons identified as the | Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. The Minimum Rank Objective Function with Hysteresis . . . . . 4 | 3. The Minimum Rank with Hysteresis Objective Function . . . . . 4 | |||
3.1. Computing the Path cost . . . . . . . . . . . . . . . . . 4 | 3.1. Computing the Path cost . . . . . . . . . . . . . . . . . 4 | |||
3.2. Parent Selection . . . . . . . . . . . . . . . . . . . . . 5 | 3.2. Parent Selection . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.2.1. When Parent Selection Runs . . . . . . . . . . . . . . 6 | 3.2.1. When Parent Selection Runs . . . . . . . . . . . . . . 6 | |||
3.2.2. Parent Selection Algorithm . . . . . . . . . . . . . . 6 | 3.2.2. Parent Selection Algorithm . . . . . . . . . . . . . . 6 | |||
3.3. Computing Rank . . . . . . . . . . . . . . . . . . . . . . 7 | 3.3. Computing Rank . . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.4. Advertising the Path Cost . . . . . . . . . . . . . . . . 8 | 3.4. Advertising the Path Cost . . . . . . . . . . . . . . . . 8 | |||
3.5. Working Without Metric Containers . . . . . . . . . . . . 8 | 3.5. Working Without Metric Containers . . . . . . . . . . . . 9 | |||
4. Using MRHOF for Metric Maximization . . . . . . . . . . . . . 9 | 4. Using MRHOF for Metric Maximization . . . . . . . . . . . . . 9 | |||
5. MRHOF Variables and Parameters . . . . . . . . . . . . . . . . 9 | 5. MRHOF Variables and Parameters . . . . . . . . . . . . . . . . 9 | |||
6. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 10 | 6. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
6.1. Device Configuration . . . . . . . . . . . . . . . . . . . 10 | 6.1. Device Configuration . . . . . . . . . . . . . . . . . . . 11 | |||
6.2. Device Monitoring . . . . . . . . . . . . . . . . . . . . 11 | 6.2. Device Monitoring . . . . . . . . . . . . . . . . . . . . 11 | |||
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | |||
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . . 12 | 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
1. Introduction | 1. Introduction | |||
An objective function specifies how RPL [I-D.ietf-roll-rpl] selects | An objective function specifies how RPL [RFC6550] selects paths. For | |||
paths. For example, if an RPL instance uses an objective function | example, if an RPL instance uses an objective function that minimizes | |||
that minimizes hop-count, RPL will select paths with minimum hop | hop-count, RPL will select paths with minimum hop count. RPL | |||
count. RPL requires that all nodes in a network use a common OF; | requires that all nodes in a network use a common OF; relaxing this | |||
relaxing this requirement may be a subject of future study. | requirement may be a subject of future study. | |||
The nodes running RPL might use a number of metrics to describe a | The nodes running RPL might use a number of metrics to describe a | |||
link or a node [I-D.ietf-roll-routing-metrics] and make these metrics | link or a node [I-D.ietf-roll-routing-metrics] and make these metrics | |||
available for route selection. RPL advertises metrics in RPL | available for route selection. RPL advertises metrics in RPL | |||
Destination Information Object (DIO) messages with a Metric Container | Destination Information Object (DIO) messages with a Metric Container | |||
suboption. An objective function can use these metrics to choose | suboption. An objective function can use these metrics to choose | |||
routes. | routes. | |||
To decouple the details of an individual metric or objective function | To decouple the details of an individual metric or objective function | |||
from forwarding and routing, RPL describes routes through a value | from forwarding and routing, RPL describes routes through a value | |||
skipping to change at page 3, line 41 | skipping to change at page 3, line 41 | |||
metrics in the DIO Metric Container. For example, the use of MRHOF | metrics in the DIO Metric Container. For example, the use of MRHOF | |||
with the latency metric allows RPL to find stable minimum-latency | with the latency metric allows RPL to find stable minimum-latency | |||
paths from the nodes to a root in the DAG instance. The use of MRHOF | paths from the nodes to a root in the DAG instance. The use of MRHOF | |||
with the ETX metric allows RPL to find the stable minimum-ETX paths | with the ETX metric allows RPL to find the stable minimum-ETX paths | |||
from the nodes to a root in the DAG instance. In the absence of a | from the nodes to a root in the DAG instance. In the absence of a | |||
metric in the DIO Metric Container or the lack of a DIO Metric | metric in the DIO Metric Container or the lack of a DIO Metric | |||
Container, MRHOF defaults to using ETX to compute Rank, as described | Container, MRHOF defaults to using ETX to compute Rank, as described | |||
in Section 3.5. | in Section 3.5. | |||
Because MRHOF seeks to minimize path costs as described by metrics, | Because MRHOF seeks to minimize path costs as described by metrics, | |||
it can only be used with additive metrics. MRHOF ignores metrics t | it can only be used with additive metrics. MRHOF ignores metrics | |||
that are not additive. | ||||
2. Terminology | 2. Terminology | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in RFC | "OPTIONAL" in this document are to be interpreted as described in RFC | |||
2119 [RFC2119]. | 2119 [RFC2119]. | |||
This terminology used in this document is consistent with the | The terminologies used in this document are consistent with the | |||
terminologies described in [I-D.ietf-roll-terminology], | terminologies described in [I-D.ietf-roll-terminology] and | |||
[I-D.ietf-roll-routing-metrics]. | ||||
[I-D.ietf-roll-rpl], and [I-D.ietf-roll-routing-metrics]. | The terminologies used in this document are also consistent with the | |||
terminologies described in RFC 6550 [RFC6550], except the term Rank. | ||||
In this document, Rank refers to the value of the Rank field, not | ||||
DAGRank as in RFC 6550 [RFC6550]. | ||||
This document introduces three terms: | This document introduces three terms: | |||
Selected metric: The metric chosen by the network operator to use | Selected metric: The metric chosen by the network operator to use | |||
for path selection. This metric can be any additive metric | for path selection. This metric can be any additive metric | |||
listed in [I-D.ietf-roll-routing-metrics]. | listed in [I-D.ietf-roll-routing-metrics]. | |||
Path cost: Path cost quantifies a property of an end-to-end path. | Path cost: Path cost quantifies a property of an end-to-end path. | |||
Path cost is obtained by summing up the selected metric of the | Path cost is obtained by summing up the selected metric of the | |||
links or nodes along the path. Path cost can be used by RPL to | links or nodes along the path. Path cost can be used by RPL to | |||
compare different paths. | compare different paths. | |||
Worst parent: The node in the parent set with the largest path cost. | Worst parent: The node in the parent set with the largest path cost. | |||
3. The Minimum Rank Objective Function with Hysteresis | 3. The Minimum Rank with Hysteresis Objective Function | |||
The Minimum Rank with Hysteresis Objective Function, MRHOF, is | The Minimum Rank with Hysteresis Objective Function, MRHOF, is | |||
designed to find the paths with the smallest path cost while | designed to find the paths with the smallest path cost while | |||
preventing excessive churn in the network. It does so by finding the | preventing excessive churn in the network. It does so by finding the | |||
minimum cost path and switching to that path only if it is shorter | minimum cost path and switching to that path only if it is shorter | |||
(in terms of path cost) than the current path by at least a given | (in terms of path cost) than the current path by at least a given | |||
threshold. | threshold. | |||
MRHOF may be used with any additive metric listed in | MRHOF may be used with any additive metric listed in | |||
[I-D.ietf-roll-routing-metrics] as long the routing objective is to | [I-D.ietf-roll-routing-metrics] as long the routing objective is to | |||
skipping to change at page 7, line 34 | skipping to change at page 7, line 39 | |||
| Latency | Cost/65536 | | | Latency | Cost/65536 | | |||
| Link Quality Level | Cost | | | Link Quality Level | Cost | | |||
| ETX | Cost | | | ETX | Cost | | |||
+--------------------+------------+ | +--------------------+------------+ | |||
Table 1: Conversion of metric to rank. | Table 1: Conversion of metric to rank. | |||
Rank is undefined for these node/link metrics: node state and | Rank is undefined for these node/link metrics: node state and | |||
attributes, throughput, and link color. If the rank is undefined, | attributes, throughput, and link color. If the rank is undefined, | |||
the node must join one of the neighbors as a RPL Leaf node according | the node must join one of the neighbors as a RPL Leaf node according | |||
to [I-D.ietf-roll-rpl]. | to [RFC6550]. | |||
MRHOF uses this Rank value to compute the Rank it associates with the | MRHOF uses this Rank value to compute the Rank it associates with the | |||
path through each meqber of the parent set. The Rank associated with | path through each member of the parent set. The Rank associated with | |||
a path through a member of the parent set is the maximum of two | a path through a member of the parent set is the maximum of two | |||
values. The first is corresponding Rank value calculated with the | values. The first is corresponding Rank value calculated with the | |||
table above, the second is the that node's advertised Rank plus | table above, the second is that node's advertised Rank plus | |||
MinHopRankIncrease. | MinHopRankIncrease. | |||
A node sets its Rank to the maximum of three values: | A node sets its Rank to the maximum of three values: | |||
1. The Rank calculated for the path through the preferred parent | 1. The Rank calculated for the path through the preferred parent | |||
2. The Rank of the member of the parent set with the highest | 2. The Rank of the member of the parent set with the highest | |||
advertised Rank plus one | advertised Rank, rounded to the next higher integral Rank, ie, to | |||
MinHopRankIncrease * (1 + floor(Rank/MinHopRankIncrease)). | ||||
3. The largest calculated Rank among paths through the parent set, | 3. The largest calculated Rank among paths through the parent set, | |||
minus MaxRankIncrease | minus MaxRankIncrease | |||
The first case is the Rank associated with the path through the | The first case is the Rank associated with the path through the | |||
preferred parent. The second case covers requirement 4 of Rank | preferred parent. The second case covers requirement 5 of Rank | |||
advertisements in Section 8.2.1 of [I-D.ietf-roll-rpl]. The third | advertisements in Section 8.2.1 of [RFC6550]. The third case ensures | |||
case ensures that a node does not advertise a Rank which then | that a node does not advertise a Rank which then precludes it from | |||
precludes it from using members of its parent set. | using members of its parent set. | |||
Note that the third case means that a node advertises a conservative | Note that the third case means that a node advertises a conservative | |||
Rank value based on members of its parent set, which might be | Rank value based on members of its parent set. This conservative | |||
significantly higher than the Rank calculated for the path through | value might be significantly higher than the Rank calculated for the | |||
the preferred parent. Accordingly, picking a parent set whose paths | path through the preferred parent. Accordingly, picking a parent set | |||
have a large range of Ranks will likely result in sub-optimal | whose paths have a large range of Ranks will likely result in sub- | |||
routing: nodes will not choose good paths because they are advertised | optimal routing: nodes might not choose good paths because they are | |||
as much worse than they actually are. The exact selection of a | advertised as much worse than they actually are. The exact selection | |||
parent set is an implementation decision. | of a parent set is an implementation decision. | |||
3.4. Advertising the Path Cost | 3.4. Advertising the Path Cost | |||
Once the preferred parent is selected, the node sets its | Once the preferred parent is selected, the node sets its | |||
cur_min_path_cost variable to the path cost corresponding to its | cur_min_path_cost variable to the path cost corresponding to its | |||
preferred parent. It then calculates the metric it will advertise in | preferred parent. It then calculates the metric it will advertise in | |||
its metric container. This value is the path cost of the member of | its metric container. This value is the path cost of the member of | |||
the parent set with the highest path cost. Thus, while | the parent set with the highest path cost. Thus, while | |||
cur_min_path_cost is the cost through the preferred parent, a node | cur_min_path_cost is the cost through the preferred parent, a node | |||
advertises the highest cost path from the node to the root through a | advertises the highest cost path from the node to the root through a | |||
skipping to change at page 10, line 36 | skipping to change at page 10, line 46 | |||
PARENT_SET_SIZE: 3. If the preferred parent is not available, two | PARENT_SET_SIZE: 3. If the preferred parent is not available, two | |||
candidate parents are still available without triggering a new | candidate parents are still available without triggering a new | |||
round of route discovery. | round of route discovery. | |||
ALLOW_FLOATING_ROOT: 0. Do not allow a node to become a floating | ALLOW_FLOATING_ROOT: 0. Do not allow a node to become a floating | |||
root. | root. | |||
6. Manageability | 6. Manageability | |||
Section 18 of [I-D.ietf-roll-rpl] depicts the management of RPL. | Section 18 of [RFC6550] depicts the management of RPL. This | |||
This specification inherits from that section and its subsections, | specification inherits from that section and its subsections, with | |||
with the exception that metrics as specified in | the exception that metrics as specified in | |||
[I-D.ietf-roll-routing-metrics] are not used and do not require | [I-D.ietf-roll-routing-metrics] are not used and do not require | |||
management. | management. | |||
6.1. Device Configuration | 6.1. Device Configuration | |||
An implementation SHOULD allow the following parameters to be | An implementation SHOULD allow the following parameters to be | |||
configured at installation time: MAX_LINK_METRIC, MAX_PATH_COST, | configured at installation time: MAX_LINK_METRIC, MAX_PATH_COST, | |||
MIN_PATH_COST, PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and | MIN_PATH_COST, PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and | |||
ALLOW_FLOATING_ROOT. An implementation MAY allow these parameters to | ALLOW_FLOATING_ROOT. An implementation MAY allow these parameters to | |||
be configured dynamically at run time once a network has been | be configured dynamically at run time once a network has been | |||
deployed. | deployed. | |||
A MRHOF implementation SHOULD support the DODAG Configuration option | A MRHOF implementation SHOULD support the DODAG Configuration option | |||
as described in [I-D.ietf-roll-rpl] and apply the parameters it | as described in [RFC6550] and apply the parameters it specifies. | |||
specifies. Care should be taken in the relationship between the | Care should be taken in the relationship between the MRHOF | |||
MRHOF PARENT_SWITCH_THRESHOLD parameter and the RPL MaxRankIncrease | PARENT_SWITCH_THRESHOLD parameter and the RPL MaxRankIncrease | |||
parameter. For example, if MaxRankIncrease is smaller than | parameter. For example, if MaxRankIncrease is smaller than | |||
PARENT_SWITCH_THRESHOLD, a RPL node using MRHOF could enter a | PARENT_SWITCH_THRESHOLD, a RPL node using MRHOF could enter a | |||
situation where its current preferred parent causes the nodes Rank to | situation where its current preferred parent causes the nodes Rank to | |||
increase more than MaxRankIncrease but MRHOF does not change | increase more than MaxRankIncrease but MRHOF does not change | |||
preferred parents: this could cause the node to leave the routing | preferred parents: this could cause the node to leave the routing | |||
topology even though there may be other members of the parent set | topology even though there may be other members of the parent set | |||
which would allow the node's Rank to remain within MaxRankIncrease. | which would allow the node's Rank to remain within MaxRankIncrease. | |||
Unless configured otherwise, a MRHOF implementation SHOULD use the | Unless configured otherwise, a MRHOF implementation SHOULD use the | |||
default parameters as specified in Section 5. | default parameters as specified in Section 5. | |||
skipping to change at page 11, line 33 | skipping to change at page 11, line 44 | |||
increment is greater than that caused by link cost, then metrics will | increment is greater than that caused by link cost, then metrics will | |||
be used to select a preferred parent but the advertised Rank will be | be used to select a preferred parent but the advertised Rank will be | |||
a simple hopcount. This behavior might be desirable, but it also | a simple hopcount. This behavior might be desirable, but it also | |||
might be unintended: care is recommended. | might be unintended: care is recommended. | |||
6.2. Device Monitoring | 6.2. Device Monitoring | |||
A MRHOF implementation should provide an interface for monitoring its | A MRHOF implementation should provide an interface for monitoring its | |||
operation. At a minimum, the information provided should include: | operation. At a minimum, the information provided should include: | |||
DAG information as specified in Section 6.3.1 of | DAG information as specified in Section 6.3.1 of [RFC6550], and | |||
[I-D.ietf-roll-rpl], and including the DODAGID, the RPLInstanceID, | including the DODAGID, the RPLInstanceID, the Mode of Operation, | |||
the Mode of Operation, the Rank of this node, the current Version | the Rank of this node, the current Version Number, and the value | |||
Number, and the value of the Grounded flag. | of the Grounded flag. | |||
A list of neighbors indicating the preferred parent. The list | A list of neighbors indicating the preferred parent. The list | |||
should indicate, for each neighbor, the Rank, the current Version | should indicate, for each neighbor, the Rank, the current Version | |||
Number, the value of the Grounded flag, and associated metrics. | Number, the value of the Grounded flag, and associated metrics. | |||
7. Acknowledgements | 7. Acknowledgements | |||
Thanks to Antonio Grilo, Nicolas Tsiftes, Matteo Paris, JP Vasseur, | Thanks to Antonio Grilo, Nicolas Tsiftes, Matteo Paris, JP Vasseur, | |||
and Phoebus Chen for their comments. | and Phoebus Chen for their comments. | |||
8. IANA Considerations | 8. IANA Considerations | |||
This specification requires a value allocated from the "Objective | This specification requires a value allocated from the "Objective | |||
Code Point (OCP)" sub-registry of the "Routing Protocol for Low Power | Code Point (OCP)" sub-registry of the "Routing Protocol for Low Power | |||
and Lossy Networks (RPL)" registry. A value of 1 is suggested. | and Lossy Networks (RPL)" registry. A value of 1 is suggested. | |||
9. Security Considerations | 9. Security Considerations | |||
This specification makes simple extensions to RPL and so is | This specification makes simple extensions to RPL and so is | |||
vulnerable to and benefits from the security issues and mechanisms | vulnerable to and benefits from the security issues and mechanisms | |||
described in [I-D.ietf-roll-rpl] and | described in [RFC6550] and [I-D.ietf-roll-security-framework]. This | |||
[I-D.ietf-roll-security-framework]. This document does not introduce | document does not introduce new flows or new messages, thus requires | |||
new flows or new messages, thus requires no specific mitigation for | no specific mitigation for new threats. | |||
new threats. | ||||
MRHOF depends on information exchanged in a number RPL protocol | MRHOF depends on information exchanged in a number RPL protocol | |||
elements. If those elements were compromised, then an implementation | elements. If those elements were compromised, then an implementation | |||
of MRHOF might generate the wrong path for a packet, resulting in it | of MRHOF might generate the wrong path for a packet, resulting in it | |||
being misrouted. Therefore, deployments are RECOMMENDED to use RPL | being misrouted. Therefore, deployments are RECOMMENDED to use RPL | |||
security mechanisms if there is a risk that routing information might | security mechanisms if there is a risk that routing information might | |||
be modified or spoofed. | be modified or spoofed. | |||
10. References | 10. References | |||
10.1. Normative References | 10.1. Normative References | |||
[I-D.ietf-roll-routing-metrics] | [I-D.ietf-roll-routing-metrics] | |||
Barthel, D., Vasseur, J., Pister, K., Kim, M., and N. | Barthel, D., Vasseur, J., Pister, K., Kim, M., and N. | |||
Dejean, "Routing Metrics used for Path Calculation in Low | Dejean, "Routing Metrics used for Path Calculation in Low | |||
Power and Lossy Networks", | Power and Lossy Networks", | |||
draft-ietf-roll-routing-metrics-19 (work in progress), | draft-ietf-roll-routing-metrics-19 (work in progress), | |||
March 2011. | March 2011. | |||
[I-D.ietf-roll-rpl] | ||||
Brandt, A., Vasseur, J., Hui, J., Pister, K., Thubert, P., | ||||
Levis, P., Struik, R., Kelsey, R., Clausen, T., and T. | ||||
Winter, "RPL: IPv6 Routing Protocol for Low power and | ||||
Lossy Networks", draft-ietf-roll-rpl-19 (work in | ||||
progress), March 2011. | ||||
[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. | |||
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., | ||||
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. | ||||
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and | ||||
Lossy Networks", RFC 6550, March 2012. | ||||
10.2. Informative References | 10.2. Informative References | |||
[I-D.ietf-roll-security-framework] | [I-D.ietf-roll-security-framework] | |||
Tsao, T., Alexander, R., Dohler, M., Daza, V., and A. | Tsao, T., Alexander, R., Dohler, M., Daza, V., and A. | |||
Lozano, "A Security Framework for Routing over Low Power | Lozano, "A Security Framework for Routing over Low Power | |||
and Lossy Networks", draft-ietf-roll-security-framework-07 | and Lossy Networks", draft-ietf-roll-security-framework-07 | |||
(work in progress), January 2012. | (work in progress), January 2012. | |||
[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-05 (work in | Networks", draft-ietf-roll-terminology-05 (work in | |||
progress), March 2011. | progress), March 2011. | |||
Authors' Addresses | Authors' Addresses | |||
Omprakash Gnawali | Omprakash Gnawali | |||
Stanford University | University of Houston | |||
S255 Clark Center, 318 Campus Drive | PGH 577, University of Houston | |||
Stanford, CA 94305 | Houston, TX 77204 | |||
USA | USA | |||
Phone: +1 650 725 6086 | Phone: +1 713 743 3356 | |||
Email: gnawali@cs.stanford.edu | Email: gnawali@cs.uh.edu | |||
Philip Levis | Philip Levis | |||
Stanford University | Stanford University | |||
412 Gates Hall, Stanford University | 412 Gates Hall, Stanford University | |||
Stanford, CA 94305 | Stanford, CA 94305 | |||
USA | USA | |||
Email: pal@cs.stanford.edu | Email: pal@cs.stanford.edu | |||
End of changes. 28 change blocks. | ||||
63 lines changed or deleted | 67 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/ |