summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6552.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6552.txt')
-rw-r--r--doc/rfc/rfc6552.txt787
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc6552.txt b/doc/rfc/rfc6552.txt
new file mode 100644
index 0000000..5cc0bf6
--- /dev/null
+++ b/doc/rfc/rfc6552.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) P. Thubert, Ed.
+Request for Comments: 6552 Cisco Systems
+Category: Standards Track March 2012
+ISSN: 2070-1721
+
+
+ Objective Function Zero for the
+ Routing Protocol for Low-Power and Lossy Networks (RPL)
+
+Abstract
+
+ The Routing Protocol for Low-Power and Lossy Networks (RPL)
+ specification defines a generic Distance Vector protocol that is
+ adapted to a variety of network types by the application of specific
+ Objective Functions (OFs). An OF states the outcome of the process
+ used by a RPL node to select and optimize routes within a RPL
+ Instance based on the Information Objects available; an OF is not an
+ algorithm.
+
+ This document specifies a basic Objective Function that relies only
+ on the objects that are defined in the RPL and does not use any
+ protocol extensions.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6552.
+
+Copyright Notice
+
+ Copyright (c) 2012 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+
+
+
+Thubert Standards Track [Page 1]
+
+RFC 6552 RPL Objective Function Zero March 2012
+
+
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Terminology .....................................................4
+ 3. Objective Function Zero Overview ................................4
+ 4. OF0 Operations ..................................................5
+ 4.1. Computing Rank .............................................5
+ 4.2. Parent Selection ...........................................7
+ 4.2.1. Selection of the Preferred Parent ...................7
+ 4.2.2. Selection of the Backup Feasible Successor ..........8
+ 5. Abstract Interface to OF0 .......................................9
+ 6. OF0 Operands ....................................................9
+ 6.1. Variables ..................................................9
+ 6.2. Configurable Parameters ...................................10
+ 6.3. Constants .................................................10
+ 7. Manageability Considerations ...................................10
+ 7.1. Device Configuration ......................................11
+ 7.2. Device Monitoring .........................................11
+ 8. IANA Considerations ............................................12
+ 9. Security Considerations ........................................12
+ 10. Acknowledgements ..............................................12
+ 11. References ....................................................13
+ 11.1. Normative References .....................................13
+ 11.2. Informative References ...................................13
+
+1. Introduction
+
+ The Routing Protocol for Low-Power and Lossy Networks (RPL)
+ specification [RFC6550] defines a generic Distance Vector protocol
+ that is adapted to a variety of Low-Power and Lossy Network (LLN)
+ types by the application of specific Objective Functions (OFs).
+
+ A RPL OF states the outcome of the process used by a RPL node to
+ select and optimize routes within a RPL Instance based on the
+ Information Objects available. As a general concept, an OF is not an
+ algorithm. For example, outside RPL, "shortest path first" is an OF
+ where the least cost path between two points is derived as an
+ outcome; there are a number of algorithms that can be used to satisfy
+ the OF, of which the well-known Dijkstra algorithm is an example.
+
+ The separation of OFs from the core protocol specification allows RPL
+ to be adapted to meet the different optimization criteria required by
+ the wide range of deployments, applications, and network designs.
+
+
+
+
+Thubert Standards Track [Page 2]
+
+RFC 6552 RPL Objective Function Zero March 2012
+
+
+ RPL forms Directed Acyclic Graphs (DAGs) as collections of
+ Destination-Oriented DAGs (DODAGs) within instances of the protocol.
+ Each instance is associated with a specialized Objective Function. A
+ DODAG is periodically reconstructed as a new DODAG Version to enable
+ a global reoptimization of the graph.
+
+ An instance of RPL running on a device uses an Objective Function to
+ help it determine which DODAG and which Version of that DODAG it
+ should join. The OF is also used by the RPL Instance to select a
+ number of routers within the DODAG current and subsequent Versions to
+ serve as parents or as feasible successors.
+
+ The RPL Instance uses the OF to compute a Rank for the device. This
+ value represents an abstract distance to the root of the DODAG within
+ the DODAG Version. The Rank is exchanged between nodes using RPL and
+ allows other RPL nodes to avoid loops and verify forward progression
+ toward the destination, as specified in [RFC6550]. Regardless of the
+ particular OF used by a node, Rank will always increase; thus, post
+ convergence, loop-free paths are always formed.
+
+ The Objective Function Zero (OF0) operates on parameters that are
+ obtained from provisioning, the RPL DODAG Configuration option and
+ the RPL DODAG Information Object (DIO) base container [RFC6550].
+
+ The Rank of a node is obtained by adding a strictly positive,
+ indirectly normalized scalar, rank_increase (Section 6.1), to the
+ Rank of a selected preferred parent. The rank_increase is based on a
+ step_of_rank (Section 6.1) normalized scalar that can vary with a
+ ratio from 1 (excellent) to 9 (worst acceptable) to represent the
+ link properties. The step_of_rank can be multiplied by a
+ configurable factor called rank_factor (Section 6.2) that amplifies
+ the rank_increase to reflect the relative preferences between
+ different link types that would be used in the same RPL Instance.
+ The rank_increase can be further adapted as detailed in Section 4.1.
+ By default, OF0 encodes the 2-octet Rank in units of 256, and the
+ default settings allow for the encoding of a minimum of 28 (worst
+ acceptable) hops and a maximum of 255 (excellent) hops.
+
+ The RPL specification [RFC6550] requires the use of a common OF by
+ all nodes in a network. The possible use of multiple OFs with a
+ single network is for further study.
+
+ The RPL specification [RFC6550] does not include any OF definitions.
+ This is left for other documents specific to different deployments
+ and application environments. Since there is no default OF or metric
+ container in the RPL main specification, it might happen that, unless
+
+
+
+
+
+Thubert Standards Track [Page 3]
+
+RFC 6552 RPL Objective Function Zero March 2012
+
+
+ two given implementations follow the same guidance for a specific
+ problem or environment, those implementations will not support a
+ common OF with which they could interoperate.
+
+ OF0 is designed as a default OF that will allow interoperation
+ between implementations in a wide spectrum of use cases. This is why
+ OF0 does not specify how the link properties are transformed into a
+ rank_increase and leaves that responsibility to the implementation;
+ rather, OF0 enforces the values for the rank_increase by normalizing
+ the step_of_rank for a normal link and its acceptable range, as
+ opposed to formulating the details of the step_of_rank computation.
+ This is also why OF0 ignores metric containers.
+
+2. Terminology
+
+ The terminology used in this document is consistent with and
+ incorporates that described in "Terminology in Low power And Lossy
+ Networks" [ROLL-TERMS] and [RFC6550].
+
+ The term "feasible successor" is used to refer to a neighbor that can
+ possibly be used as a next hop for Upward traffic following the loop
+ avoidance and forwarding rules that the nodes implement and that are
+ defined in the RPL specification [RFC6550].
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in RFC
+ 2119 [RFC2119].
+
+3. Objective Function Zero Overview
+
+ The RPL specification describes constraints on how nodes select
+ potential parents, called a parent set, from their neighbors. All
+ parents are feasible successors for upward traffic (towards the
+ root). Additionally, RPL allows the use of parents in a subsequent
+ Version of a same DODAG as feasible successors, in which case this
+ node acts as a leaf in the subsequent DODAG Version.
+
+ The Goal of the OF0 is for a node to join a DODAG Version that offers
+ good enough connectivity to a specific set of nodes or to a larger
+ routing infrastructure though there is no guarantee that the path
+ will be optimized according to a specific metric. This validation
+ process for the connectivity is implementation and link type
+ dependent and is out of scope. The validation involves but is not
+ limited to application of [RFC6550], Sections 3.2.3 and 13, as
+ appropriate and may involve deployment specific policies as well.
+
+
+
+
+
+Thubert Standards Track [Page 4]
+
+RFC 6552 RPL Objective Function Zero March 2012
+
+
+ Thus, for the purpose of OF0, the term "Grounded" [RFC6550] means
+ that the DODAG root provides such connectivity. How that
+ connectivity is asserted and maintained is out of scope.
+
+ Objective Function Zero is designed to find the nearest Grounded
+ root. This can be achieved if the Rank of a node is very close to an
+ abstract function of its distance to the root. This need is balanced
+ with the other need of maintaining some path diversity, which may be
+ achieved by increasing the Rank. In the absence of a Grounded root,
+ inner connectivity within the LLN is still desirable and floating
+ DAGs will form, rooted at the nodes with the highest administrative
+ preference.
+
+ OF0 selects a preferred parent and a backup feasible successor if one
+ is available. All the upward traffic is normally routed via the
+ preferred parent with no attempt to perform any load balancing. When
+ the link conditions do not let an upward packet through the preferred
+ parent, the packet is passed to the backup feasible successor.
+
+ A RPL node monitors links to a number of neighbor nodes and can use
+ OF0 to assign a rank_increase to each link. Though the exact method
+ for computing the rank_increase is implementation dependent, the
+ computation must follow the rules that are specified in Section 4.1.
+
+4. OF0 Operations
+
+4.1. Computing Rank
+
+ An OF0 implementation first computes a variable step_of_rank
+ (Section 6.1) associated with a given parent from relevant link
+ properties and metrics. The step_of_rank is used to compute the
+ amount by which to increase the rank along a particular link, as
+ explained later in this section.
+
+ Computing a step_of_rank based on a static metric such as an
+ administrative cost implies that the OF0 implementation only
+ considers parents with good enough connectivity, and results in a
+ Rank that is analogous to hop-count. In most LLNs, this favors paths
+ with fewer but longer hops of poorer connectivity; it is thus
+ RECOMMENDED to base the computation of the step_of_rank on dynamic
+ link properties such as the expected transmission count (ETX) metric
+ as introduced in [DeCouto03] and discussed in [RFC6551]. "Minimum
+ Rank Objective Function with Hysteresis" [HYSTERESIS] provides
+ guidance on how link cost can be computed and on how hysteresis can
+ improve Rank stability.
+
+
+
+
+
+
+Thubert Standards Track [Page 5]
+
+RFC 6552 RPL Objective Function Zero March 2012
+
+
+ OF0 allows an implementation to stretch the step_of_rank in order to
+ enable the selection of at least one feasible successor and thus
+ maintain path diversity. Stretching the step_of_rank is NOT
+ RECOMMENDED, because it augments the apparent distance from the node
+ to the root, distorts the DODAG from the optimal shape and may cause
+ instabilities due to greedy behaviors whereby depending nodes augment
+ their Ranks to use each other as parents in a loop. Still, an
+ implementation may stretch the step_of_rank with at most a
+ configurable stretch_of_rank (Section 6.2) of any value between 0 (no
+ stretch) and the fixed constant MAXIMUM_RANK_STRETCH (Section 6.3).
+
+ An implementation MUST maintain the stretched step_of_rank between
+ the fixed constants MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK
+ (Section 6.3). This range allows the reflection of a large variation
+ of link quality.
+
+ The gap between MINIMUM_STEP_OF_RANK 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 high-speed (wired) over lower-speed (wireless)
+ links, within the same DAG. An implementation SHOULD allow the
+ operator to configure a factor called rank_factor (Section 6.2) and
+ to apply the factor on all links and peers to multiply the effect of
+ the stretched step_of_rank in the rank_increase computation as
+ further detailed below.
+
+ Additionally, an implementation MAY recognize categories of peers and
+ links, such as different link types, in which case it SHOULD be able
+ to configure a more specific rank_factor to those categories. The
+ rank_factor MUST be set between the fixed constants
+ MINIMUM_RANK_FACTOR and MAXIMUM_RANK_FACTOR (Section 6.3).
+
+ The variable rank_increase is represented in units expressed by the
+ variable MinHopRankIncrease, which defaults to the fixed constant
+ DEFAULT_MIN_HOP_RANK_INCREASE ([RFC6550]); with that setting, the
+ least significant octet in the RPL Rank field in the DIO Base Object
+ is not used.
+
+ The step_of_rank Sp that is computed for that link is multiplied by
+ the rank_factor Rf and then possibly stretched by a term Sr that is
+ less than or equal to the configured stretch_of_rank. The resulting
+ rank_increase is added to the Rank of preferred parent R(P) to obtain
+ that of this node R(N):
+
+ R(N) = R(P) + rank_increase where:
+
+ rank_increase = (Rf*Sp + Sr) * MinHopRankIncrease
+
+
+
+
+Thubert Standards Track [Page 6]
+
+RFC 6552 RPL Objective Function Zero March 2012
+
+
+ Optionally, the administrative preference of a root MAY be configured
+ to supersede the goal to join a Grounded DODAG. In that case, nodes
+ will associate with the root with the highest preference available,
+ regardless of whether or not that root is Grounded. Compared to a
+ deployment with a multitude of Grounded roots that would result in
+ the same multitude of DODAGs, such a configuration may result in
+ possibly less but larger DODAGs, as many as roots configured with the
+ highest priority in the reachable vicinity.
+
+4.2. Parent Selection
+
+4.2.1. Selection of the Preferred Parent
+
+ As it scans all the candidate neighbors, OF0 keeps the parent that is
+ the best for the following criteria (in order):
+
+ 1. [RFC6550], Section 8, spells out the generic rules for a node to
+ re-parent and in particular the boundaries to augment its Rank
+ within a DODAG Version. A candidate that would not satisfy
+ those rules MUST NOT be considered.
+
+ 2. Prior to selecting a router as the preferred parent, an
+ implementation SHOULD validate the connectivity and suitability
+ of the router as discussed in Section 3. This validation
+ involves checking the Layer 2 connectivity to the router, the
+ Layer 3 connectivity offered by the router, and may involve
+ examination of other factors such as locally or globally
+ configured policies.
+
+ In most cases, a router that does not succeed in the validation
+ process cannot be further considered for selection as preferred
+ parent. In any case, a router that succeeded in that validation
+ process SHOULD be preferred over one that did not succeed.
+
+ 3. When multiple interfaces are available, a policy might be
+ locally configured to order them and that policy applies first;
+ that is, a router on a higher-order interface in the policy is
+ preferable.
+
+ 4. If the administrative preference of the root is configured to
+ supersede the goal to join a Grounded DODAG, a router that
+ offers connectivity to a more preferable root SHOULD be
+ preferred.
+
+ 5. A router that offers connectivity to a grounded DODAG Version
+ SHOULD be preferred over one that does not.
+
+
+
+
+
+Thubert Standards Track [Page 7]
+
+RFC 6552 RPL Objective Function Zero March 2012
+
+
+ 6. A router that offers connectivity to a more preferable root
+ SHOULD be preferred.
+
+ 7. When comparing two parents that belong to the same DODAG, a
+ router that offers connectivity to the most recent DODAG Version
+ SHOULD be preferred.
+
+ 8. The parent that causes the lesser resulting Rank for this node,
+ as specified in Section 4.1, SHOULD be preferred.
+
+ 9. A DODAG Version for which there is an alternate parent SHOULD be
+ preferred. This check is OPTIONAL. It is performed by
+ computing the backup feasible successor while assuming that the
+ router that is currently examined is finally selected as
+ preferred parent.
+
+ 10. The preferred parent that was in use already SHOULD be
+ preferred.
+
+ 11. A router that has announced a DIO message more recently SHOULD
+ be preferred.
+
+ These rules and their order MAY be varied by an implementation
+ according to configured policy.
+
+4.2.2. Selection of the Backup Feasible Successor
+
+ When selecting a backup feasible successor, the OF performs in order
+ the following checks:
+
+ 1. The backup feasible successor MUST NOT be the preferred parent.
+
+ 2. The backup feasible successor MUST be either in the same DODAG
+ Version as this node or in an subsequent DODAG Version.
+
+ 3. Along with RPL rules, a Router in the same DODAG Version as this
+ node and with a Rank that is higher than the Rank computed for
+ this node MUST NOT be selected as a feasible successor.
+
+ 4. A router with a lesser Rank SHOULD be preferred.
+
+ 5. A router that has been validated as usable by an implementation-
+ dependent validation process SHOULD be preferred.
+
+ 6. When multiple interfaces are available, a router on a higher
+ order interface is preferable.
+
+
+
+
+
+Thubert Standards Track [Page 8]
+
+RFC 6552 RPL Objective Function Zero March 2012
+
+
+ 7. The backup feasible successor that was in use already SHOULD be
+ preferred.
+
+ These rules and their order MAY be varied by an implementation
+ according to configured policy.
+
+5. Abstract Interface to OF0
+
+ Objective Function Zero interacts for its management and operations
+ in the following ways:
+
+ Processing DIO: When a new DIO is received, the OF that corresponds
+ to the Objective Code Point (OCP) in the DIO is triggered with the
+ content of the DIO. OF0 is identified by OCP 0 (see Section 8).
+
+ Providing DAG Information: The OF0 support provides an interface
+ that returns information about a given instance. This includes
+ material from the DIO base header, the role (router, leaf), and
+ the Rank of this node.
+
+ Providing a Parent List: The OF0 support provides an interface that
+ returns the ordered list of the parents and feasible successors
+ for a given instance to the RPL core. This includes the material
+ that is contained in the transit option for each entry.
+
+ Triggered Updates: The OF0 support provides events to inform it that
+ a change in DAG information or Parent List has occurred. This can
+ be caused by an interaction with another system component such as
+ configuration, timers, and device drivers, and the change may
+ cause the RPL core to fire a new DIO or reset Trickle timers.
+
+6. OF0 Operands
+
+ On top of variables and constants defined in [RFC6550], this
+ specification introduces the following variables and constants:
+
+6.1. Variables
+
+ OF0 uses the following variables:
+
+ step_of_rank (strictly positive integer): an intermediate
+ computation based on the link properties with a certain neighbor.
+
+ rank_increase (strictly positive integer): delta between the Rank of
+ the preferred parent and self
+
+
+
+
+
+
+Thubert Standards Track [Page 9]
+
+RFC 6552 RPL Objective Function Zero March 2012
+
+
+6.2. Configurable Parameters
+
+ OF0 can use the following optional configurable values that are used
+ as parameters to the rank_increase computation:
+
+ stretch_of_rank (unsigned integer): the maximum augmentation to the
+ step_of_rank of a preferred parent to allow the selection of an
+ additional feasible successor. If none is configured to the
+ device, then the step_of_rank is not stretched.
+
+ rank_factor (strictly positive integer): A configurable factor that
+ is used to multiply the effect of the link properties in the
+ rank_increase computation. If none is configured, then a
+ rank_factor of 1 is used.
+
+6.3. Constants
+
+ Section 17 of [RFC6550] defines RPL constants. OF0 fixes the values
+ of the following constants:
+
+ DEFAULT_STEP_OF_RANK: 3
+
+ MINIMUM_STEP_OF_RANK: 1
+
+ MAXIMUM_STEP_OF_RANK: 9
+
+ DEFAULT_RANK_STRETCH: 0
+
+ MAXIMUM_RANK_STRETCH: 5
+
+ DEFAULT_RANK_FACTOR: 1
+
+ MINIMUM_RANK_FACTOR: 1
+
+ MAXIMUM_RANK_FACTOR: 4
+
+7. Manageability Considerations
+
+ Section 18 of [RFC6550] depicts the management of the protocol. This
+ specification inherits from that section and its subsections, with
+ the exception that metrics as specified in [RFC6551] are not used and
+ do not require management.
+
+
+
+
+
+
+
+
+
+Thubert Standards Track [Page 10]
+
+RFC 6552 RPL Objective Function Zero March 2012
+
+
+7.1. Device Configuration
+
+ An implementation SHOULD allows the configuration of at least a
+ global rank_factor that applies to all links. Additionally, the
+ implementation may allow the grouping of interfaces, links, and/or
+ neighbors and configure a more specific rank_factor to such groups.
+
+ An implementation MAY allow the configuration of a maximum
+ stretch_of_rank that MUST be less than or equal to
+ MAXIMUM_RANK_STRETCH as discussed in Section 4.1. If none is
+ configured, a value of 0 is assumed and the step_of_rank is not
+ stretched.
+
+ An OF0 implementation SHOULD support the DODAG Configuration option
+ as specified in Section 6.7.6 of [RFC6550] and apply the parameters
+ contained therein. As discussed in Section 16 of [RFC6550], this
+ requirement might be overridden by further guidance for certain
+ application scenarios. When the option is used, the parameters are
+ configured to the nodes that may become DODAG roots, and the nodes
+ are configured to redistribute the information using the DODAG
+ Configuration option. In particular, the value of MinHopRankIncrease
+ can be distributed with that option and override the fixed constant
+ of DEFAULT_MIN_HOP_RANK_INCREASE that is defined in Section 17 of
+ [RFC6550] with a fixed value of 256.
+
+ Out of the box, that is at initial factory time, the default constant
+ values SHOULD be used, that is:
+
+ the rank_factor is set to the fixed constant DEFAULT_RANK_FACTOR
+ (Section 6.3).
+
+ the maximum stretch_of_rank is set to the fixed constant
+ DEFAULT_RANK_STRETCH (Section 6.3).
+
+ the MinHopRankIncrease is set to the fixed constant
+ DEFAULT_MIN_HOP_RANK_INCREASE ([RFC6550]).
+
+ The values can be overridden at any time and apply at the next
+ Version of the DODAG. As discussed in Section 16 of [RFC6550], this
+ requirement might be overridden by further guidance for certain
+ application scenarios.
+
+7.2. Device Monitoring
+
+ As discussed in Section 5, the OF support must be able to provide
+ information about its operations and trigger events when that
+ information changes. At a minimum, the information should include:
+
+
+
+
+Thubert Standards Track [Page 11]
+
+RFC 6552 RPL Objective Function Zero March 2012
+
+
+ DAG information as specified in Section 6.3.1 of [RFC6550], and
+ including the DODAGID, the RPLInstanceID, the Mode of Operation,
+ the Rank of this node, the current Version Number, and the value
+ of the Grounded flag.
+
+ A list of neighbors indicating the preferred parent and an
+ alternate feasible if available. For each neighbor, the Rank, the
+ current Version Number, and the value of the Grounded flag should
+ be indicated.
+
+8. IANA Considerations
+
+ Per this specification, an Objective Code Point (OCP) for OF0 has
+ been assigned in the Objective Code Point Registry as described in
+ Section 20.5 of [RFC6550].
+
+ OCP code: 0
+
+ Description: A basic Objective Function that relies only on the
+ objects that are defined in [RFC6550].
+
+ Defining RFC: RFC 6552
+
+9. Security Considerations
+
+ This specification makes simple extensions to RPL and so is
+ vulnerable to and benefits from the security issues and mechanisms
+ described in [RFC6550] and [ROLL-SECURITY]. This document does not
+ introduce new flows or new messages; thus, it requires no specific
+ mitigation for new threats.
+
+ OF0 depends on information exchanged in the Rank and OCP protocol
+ elements. If those elements were compromised, then an implementation
+ of OF0 might generate the wrong path for a packet, resulting in it
+ being misrouted. Therefore, deployments are RECOMMENDED to use RPL
+ security mechanisms if there is a risk that routing information might
+ be modified or spoofed.
+
+10. Acknowledgements
+
+ Specific thanks to Philip Levis and Phoebus Chen for their help in
+ finalizing this document.
+
+ Many thanks also to Adrian Farrel, Tim Winter, JP. Vasseur, Julien
+ Abeille, Mathilde Durvy, Teco Boot, Navneet Agarwal, Meral
+ Shirazipour, and Henning Rogge for in-depth review and first-hand
+ implementers' feedback.
+
+
+
+
+Thubert Standards Track [Page 12]
+
+RFC 6552 RPL Objective Function Zero March 2012
+
+
+11. References
+
+11.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC6550] Winter, T., Ed., Thubert, P., Ed., 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.
+
+11.2. Informative References
+
+ [DeCouto03] De Couto, D., Aguayo, D., Bicket, J., and R. Morris,
+ "A High-Throughput Path Metric for Multi-Hop
+ Wireless Routing", MobiCom '03, The 9th ACM
+ International Conference on Mobile Computing and
+ Networking, San Diego, California, 2003,
+ <http://pdos.csail.mit.edu/papers/grid:mobicom03/
+ paper.pdf>.
+
+ [HYSTERESIS] Gnawali, O. and P. Levis, "The Minimum Rank
+ Objective Function with Hysteresis", Work
+ in Progress, May 2011.
+
+ [RFC6551] Vasseur, J., Ed., Kim, M., Ed., Pister, K., Dejean,
+ N., and D. Barthel, "Routing Metrics Used for Path
+ Calculation in Low-Power and Lossy Networks",
+ RFC 6551, March 2012.
+
+ [ROLL-SECURITY] Tsao, T., Alexander, R., Dohler, M., Daza, V., and
+ A. Lozano, "A Security Framework for Routing over
+ Low Power and Lossy Networks", Work in Progress,
+ March 2012.
+
+ [ROLL-TERMS] Vasseur, JP., "Terminology in Low power And Lossy
+ Networks", Work in Progress, September 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+Thubert Standards Track [Page 13]
+
+RFC 6552 RPL Objective Function Zero March 2012
+
+
+Author's Address
+
+ Pascal Thubert (editor)
+ Cisco Systems
+ Village d'Entreprises Green Side
+ 400, Avenue de Roumanille
+ Batiment T3
+ Biot - Sophia Antipolis 06410
+ FRANCE
+
+ Phone: +33 497 23 26 34
+ EMail: pthubert@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thubert Standards Track [Page 14]
+