Networking Working Group                                  T. Winter, Ed.
Internet-Draft
Intended status: Standards Track                         P. Thubert, Ed.
Expires: April 29, June 10, 2010                                     Cisco Systems
                                                        ROLL Design Team
                                                            IETF ROLL WG
                                                        October 26,
                                                        December 7, 2009

      RPL: IPv6 Routing Protocol for Low power and Lossy Networks
                         draft-ietf-roll-rpl-04
                         draft-ietf-roll-rpl-05

Abstract

   Low power and Lossy Networks (LLNs) are a class of network in which
   both the routers and their interconnect are constrained: LLN routers
   typically operate with constraints on (any subset of) processing
   power, memory and energy (battery), and their interconnects are
   characterized by (any subset of) high loss rates, low data rates and
   instability.  LLNs are comprised of anything from a few dozen and up
   to thousands of LLN routers, and support point-to-point traffic
   (between devices inside the LLN), point-to-multipoint traffic (from a
   central control point to a subset of devices inside the LLN) and
   multipoint-to-point traffic (from devices inside the LLN towards a
   central control point).  This document specifies the IPv6 Routing
   Protocol for LLNs (RPL), which provides a mechanism whereby
   multipoint-to-point traffic from devices inside the LLN towards a
   central control point, as well as point-to-multipoint traffic from
   the central control point to the devices inside the LLN, is
   supported.  Support for point-to-point traffic is also available.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 29, June 10, 2010.

Copyright Notice

   Copyright (c) 2009 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 (http://trustee.ietf.org/license-info). document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Abstract

   Low power and Lossy Networks (LLNs) are a class of network  Code Components extracted from this document must
   include Simplified BSD License text as described in which
   both Section 4.e of
   the routers and their interconnect are constrained: LLN routers
   typically operate with constraints on (any subset of) processing
   power, memory and energy (battery), and their interconnects are
   characterized by (any subset of) high loss rates, low data rates Trust Legal Provisions and
   instability.  LLNs are comprised of anything from a few dozen and up
   to thousands of LLN routers, and support point-to- point traffic
   (between devices inside the LLN), point-to-multipoint traffic (from a
   central control point to a subset of devices inside the LLN) and
   multipoint-to- point traffic (from devices inside the LLN towards a
   central control point).  This document specifies the IPv6 Routing
   Protocol for LLNs (RPL), which provides a mechanism whereby
   multipoint-to-point traffic from devices inside the LLN towards a
   central control point, as well as point-to-multipoint traffic from
   the central control point to the devices inside the LLN, is
   supported.  Support for point-to-point traffic is also available.

Table provided without warranty as
   described in the BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  6  5
     1.1.  Design Principles  . . . . . . . . . . . . . . . . . . . .  6  5
     1.2.  Expectations of Link Layer Type  . . . . . . . . . . . . .  7  6
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  7  6
   3.  Protocol Model . . . . . . . . . . . . . . . . . . . . . . . .  9  8
     3.1.  Overview  Instances, DODAGs, and DODAG Iterations  . . . . . . . . .  8
     3.2.  Traffic Flows  . . . . . . . . . . . . . . . .  9
       3.1.1.  Topology Instance and Objectives . . . . . . 10
       3.2.1.  Multipoint-to-Point Traffic  . . . . .  9
       3.1.2.  Multipoint-to-Point Traffic Flows and DAGs . . . . . . 11
       3.1.3. . . 10
       3.2.2.  Point-to-Multipoint Traffic Flows  . . . . . . . . . . 11
       3.1.4.  Point-to-Point Traffic Flows . . . . 10
       3.2.3.  Point-to-Point Traffic . . . . . . . . . 12
     3.2.  Protocol Operation . . . . . . . 10
     3.3.  DODAG Construction . . . . . . . . . . . . . 12
       3.2.1.  DAG Construction . . . . . . . 11
       3.3.1.  DAG Information Object (DIO) . . . . . . . . . . . . 12
       3.2.2.  Destination Advertisement . 11
       3.3.2.  DAG Repair . . . . . . . . . . . . . 15
     3.3.  Loop Avoidance and Stability . . . . . . . . . 11
       3.3.3.  Grounded and Floating DODAGs . . . . . . 17
       3.3.1.  Greediness and Rank-based Instabilities . . . . . . . 17
       3.3.2.  DAG Loops 12
       3.3.4.  Administrative Preference  . . . . . . . . . . . . . . 12
       3.3.5.  Objective Function (OF)  . . . . . . . . 18
       3.3.3.  DAO Loops . . . . . . . 12
       3.3.6.  Distributed Algorithm Operation  . . . . . . . . . . . 13
     3.4.  Destination Advertisement  . . . . 18
       3.3.4.  Sibling Loops . . . . . . . . . . . . 13
       3.4.1.  Destination Advertisement Object (DAO) . . . . . . . . 18 13
   4.  Routing Metrics and Constraints Used By RPL  . . . . . . . . . 18 14
   5.  RPL Protocol Specification  Rank . . . . . . . . . . . . . . . . . . 19
     5.1.  RPL Messages . . . . . . . . . . . 15
     5.1.  Loop Avoidance . . . . . . . . . . . . . 19
       5.1.1.  ICMPv6 RPL Control Message . . . . . . . . . 15
       5.1.1.  Greediness and Rank-based Instabilities  . . . . . 19 . . 15
       5.1.2.  DAG Information Solicitation (DIS)  DODAG Loops  . . . . . . . . . . 20
       5.1.3.  DAG Information Object (DIO) . . . . . . . . . . . 16
       5.1.3.  DAO Loops  . . 20
       5.1.4.  Destination Advertisement Object (DAO) . . . . . . . . 27
     5.2.  Conceptual Data Structures . . . . . . . . . . . . 16
       5.1.4.  Sibling Loops  . . . . 28
       5.2.1.  Candidate Neighbors Data Structure . . . . . . . . . . 28
       5.2.2.  Directed Acyclic Graphs (DAGs) Data Structure . . . . 29
     5.3.  DAG . . 16
     5.2.  Rank Properties  . . . . . . . . . . . . . . . . . . . . . 16
   6.  RPL Protocol Specification . . . . 30
     5.4.  DAG Discovery and Maintenance . . . . . . . . . . . . . . 31
       5.4.1.  DAG Discovery Rules 18
     6.1.  RPL Messages . . . . . . . . . . . . . . . . . 32
       5.4.2.  Reception and Processing of DIO messages . . . . . . 18
       6.1.1.  ICMPv6 RPL Control Message . 36
       5.4.3.  DIO Transmission . . . . . . . . . . . . . 18
       6.1.2.  DAG Information Solicitation (DIS) . . . . . . 38
       5.4.4.  Trickle Timer for DIO Transmission . . . . 19
       6.1.3.  DAG Information Object (DIO) . . . . . . 39
     5.5.  DAG Sequence Number Increment . . . . . . . 19
       6.1.4.  Destination Advertisement Object (DAO) . . . . . . . 40
     5.6.  DAG Selection . 26
     6.2.  Protocol Elements  . . . . . . . . . . . . . . . . . . . . 28
       6.2.1.  Topological Elements . 41
     5.7.  Administrative rank . . . . . . . . . . . . . . . . 28
       6.2.2.  Neighbors, Parents, and Siblings . . . 41
     5.8.  Collision . . . . . . . . 28
       6.2.3.  DODAG Information  . . . . . . . . . . . . . . . . 42
     5.9.  Guidelines for Objective Functions . . 29
     6.3.  DAG Discovery and Maintenance  . . . . . . . . . . . . 42
       5.9.1.  Objective Function . . 30
       6.3.1.  DAG Discovery Rules  . . . . . . . . . . . . . . . . 42
       5.9.2.  Objective Function 0 (OF0) . 31
       6.3.2.  DIO Message Communication  . . . . . . . . . . . . . 44
     5.10. Establishing Routing State Outward Along the DAG . 35
       6.3.3.  DIO Transmission . . . . 46
       5.10.1. Destination Advertisement Operation . . . . . . . . . 47
     5.11. Loop Detection . . . . . . 36
       6.3.4.  Trickle Timer for DIO Transmission . . . . . . . . . . 37
     6.4.  DAG Selection  . . . . . . 54
       5.11.1. Host Basic Operation . . . . . . . . . . . . . . . . 38
     6.5.  Operation as a Leaf Node . 55
       5.11.2. Instance Forwarding . . . . . . . . . . . . . . . . 39
     6.6.  Administrative rank  . 55
       5.11.3. DAG Inconsistency Loop Detection . . . . . . . . . . . 56
       5.11.4. Sibling Loop Avoidance . . . . . . . 39
     6.7.  Collision  . . . . . . . . . 56
       5.11.5. DAO Inconsistency Loop Detection and Recovery . . . . 57
     5.12. Multicast Operation . . . . . . . . . . . 39
     6.8.  Establishing Routing State Down the DODAG  . . . . . . . . 57
     5.13. Maintenance of Routing Adjacency 40
       6.8.1.  Destination Advertisement Operation  . . . . . . . . . 41
     6.9.  Loop Detection . . . . 58
     5.14. Packet Forwarding . . . . . . . . . . . . . . . . . . 48
       6.9.1.  Source Node Operation  . . 59
   6.  RPL Constants and Variables . . . . . . . . . . . . . . 49
       6.9.2.  Router Operation . . . 60
   7.  Manageability Considerations . . . . . . . . . . . . . . . . 49
     6.10. Multicast Operation  . 61
     7.1.  Control of Function and Policy . . . . . . . . . . . . . . 61
       7.1.1.  Initialization Mode . . . . 51
     6.11. Maintenance of Routing Adjacency . . . . . . . . . . . . . 61
       7.1.2.  DIO Base option 52
   7.  Suggestions for Packet Forwarding  . . . . . . . . . . . . . . 53
   8.  Guidelines for Objective Functions . . . . . 61
       7.1.3.  Trickle Timers . . . . . . . . . 54
   9.  RPL Constants and Variables  . . . . . . . . . . . 62
       7.1.4.  DAG Sequence Number Increment . . . . . . 56
   10. Manageability Considerations . . . . . . 63
       7.1.5.  Destination Advertisement Timers . . . . . . . . . . . 63
       7.1.6.  Policy 58
     10.1. Control of Function and Policy . . . . . . . . . . . . . . 58
       10.1.1. Initialization Mode  . . . . . . 63
       7.1.7. . . . . . . . . . . . 58
       10.1.2. DIO Base option  . . . . . . . . . . . . . . . . . . . 58
       10.1.3. Trickle Timers . . . . . . . . . . . . . . . . . . . . 59
       10.1.4. DAG Sequence Number Increment  . . . . . . . . . . . . 59
       10.1.5. Destination Advertisement Timers . . . . . . . . . . . 59
       10.1.6. Policy Control . . . . . . . . . . . . . . . . . . . . 59
       10.1.7. Data Structures  . . . . . . . . . . . . . . . . . . . 63
     7.2. 60
     10.2. Information and Data Models  . . . . . . . . . . . . . . . 64
     7.3. 60
     10.3. Liveness Detection and Monitoring  . . . . . . . . . . . . 64
       7.3.1. 60
       10.3.1. Candidate Neighbor Data Structure  . . . . . . . . . . 64
       7.3.2. 61
       10.3.2. Directed Acyclic Graph (DAG) Table . . . . . . . . . . 64
       7.3.3. 61
       10.3.3. Routing Table  . . . . . . . . . . . . . . . . . . . . 65
       7.3.4. 61
       10.3.4. Other RPL Monitoring Parameters  . . . . . . . . . . . 65
       7.3.5. 62
       10.3.5. RPL Trickle Timers . . . . . . . . . . . . . . . . . . 66
     7.4. 62
     10.4. Verifying Correct Operation  . . . . . . . . . . . . . . . 66
     7.5. 62
     10.5. Requirements on Other Protocols and Functional
           Components . . . . . . . . . . . . . . . . . . . . . . . . 66
     7.6. 63
     10.6. Impact on Network Operation  . . . . . . . . . . . . . . . 66
   8. 63
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 66
   9. 63
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 66
     9.1. 63
     12.1. RPL Control Message  . . . . . . . . . . . . . . . . . . . 66
     9.2. 63
     12.2. New Registry for RPL Control Codes . . . . . . . . . . . . 67
     9.3. 63
     12.3. New Registry for the Control Field of the DIO Base
           Option . . . . . . . . . . . . . . . . . . . . . . . . . . 67
     9.4. 64
     12.4. DAG Information Object (DIO) Suboption . . . . . . . . . . 68
     9.5.  Objective Code Point for the Default Objective
           Function OF0 . . . . . . . . . . . . . . . . . . . . . . . 68
   10. 64
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 68
   11. 65
   14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 69
   12. 65
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70
     12.1. 67
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 70
     12.2. 67
     15.2. Informative References . . . . . . . . . . . . . . . . . . 71 67
   Appendix A.  Requirements  . . . . . . . . . . . . . . . . . . . . 72 69
     A.1.  Protocol Properties Overview . . . . . . . . . . . . . . . 72 69
       A.1.1.  IPv6 Architecture  . . . . . . . . . . . . . . . . . . 73 69
       A.1.2.  Typical LLN Traffic Patterns . . . . . . . . . . . . . 73 69
       A.1.3.  Constraint Based Routing . . . . . . . . . . . . . . . 73 70
     A.2.  Deferred Requirements  . . . . . . . . . . . . . . . . . . 74 70
   Appendix B.  Examples  . . . . . . . . . . . . . . . . . . . . . . 74 70
     B.1.  Destination Advertisement  . . . . . . . . . . . . . . . . 76 72
     B.2.  Example: DAG Parent Selection  . . . . . . . . . . . . . . 77 73
     B.3.  Example: DAG Maintenance . . . . . . . . . . . . . . . . . 78 75
     B.4.  Example: Greedy Parent Selection and Instability . . . . . 79 76
   Appendix C.  Outstanding Issues  . . . . . . . . . . . . . . . . . 81 78
     C.1.  Additional Support for P2P Routing . . . . . . . . . . . . 81 78
     C.2.  Loop Detection . . . . . . . . . . . . . . . . . . . . . . 81 78
     C.3.  Destination Advertisement / DAO Fan-out  . . . . . . . . . 81 78
     C.4.  Source Routing . . . . . . . . . . . . . . . . . . . . . . 82 79
     C.5.  Address / Header Compression . . . . . . . . . . . . . . . 82 79
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 82 79

1.  Introduction

   Low power and Lossy Networks (LLNs) are made largely of constrained
   nodes (with limited processing power, memory, and sometimes energy
   when they are battery operated).  These routers are interconnected by
   lossy links, typically time supporting only low data rates, that are
   usually unstable with relatively low packet delivery rates.  Another
   characteristic of such networks is that the traffic patterns are not
   simply unicast, but in many cases point-to-multipoint or multipoint-
   to-point.  Furthermore such networks may potentially comprise up to
   thousands of nodes.  These characteristics offer unique challenges to
   a routing solution: the IETF ROLL Working Group has defined
   application-specific routing requirements for a Low power and Lossy
   Network (LLN) routing protocol, specified in
   [I-D.ietf-roll-building-routing-reqs],
   [I-D.ietf-roll-home-routing-reqs], [RFC5673], and [RFC5548].  This
   document specifies the IPv6 Routing Protocol for Low power and Lossy
   Networks (RPL).

1.1.  Design Principles

   RPL was designed with the objective to meet the requirements spelled
   out in [I-D.ietf-roll-building-routing-reqs],
   [I-D.ietf-roll-home-routing-reqs], [RFC5673], and [RFC5548].  Because
   those requirements are heterogeneous and sometimes incompatible in
   nature, the approach is first taken to design a protocol capable of
   supporting a core set of functionalities corresponding to the
   intersection of the requirements.  (Note: it is intended that as this  As the RPL design evolves optional
   features may be added to address some application specific requirements).
   requirements.  This is a key protocol design decision providing a
   granular approach in order to restrict the core of the protocol to a
   minimal set of functionalities, and to allow each implementation of
   the protocol to be optimized in terms of,
   e.g., minimizing required code space and use of limited computation
   resources.

   Multiple instances of the protocol can be operated at the same time
   in order to serve different and potentially antagonistic constraints.
   Instances run independently of one another with no required
   interaction.  A node might participate to multiple instances and
   route independently along the associated topologies.  This
   specification defines only the protocol operation for the node within
   one instance.  Consideration is given to default behavior that
   enables future extensions for the multiple instances and related
   policies.

   It must be noted that RPL is not restricted to the aforementioned
   applications and is expected to be used in other environments. differently.  All "MUST" application
   requirements that cannot be satisfied by RPL will be specifically
   listed in the Appendix A, accompanied by a justification.

   The core set of functionalities is to be capable

   A network may run multiple instances of operating in the
   most severely constrained environments, with minimal requirements for
   memory, energy, processing, communication, RPL concurrently.  Each such
   instance may serve different and other consumption of
   limited resources from nodes.  Trade-offs inherent in the
   provisioning of potentially antagonistic constraints
   or performance criteria.  This document defines how a single instance
   operates.

   RPL is a generic protocol features will be exposed to the implementer
   in the form of configurable parameters, such that is to be deployed by instantiating the implementer can
   further tweak and optimize the
   generic operation of RPL as appropriate to described in this document with a specific application
   objective function (OF) (which ties together metrics, constraints,
   and implementation.  Finally, RPL is designed to
   consult implementation specific policies an optimization objective) to determine, for example,
   the evaluation of routing metrics. realize a desired objective in a
   given environment.

   A set of companion documents to this specification will provide
   further guidance in the form of applicability statements specifying a
   set of operating points appropriate to the Building Automation, Home
   Automation, Industrial, and Urban application scenarios.

1.2.  Expectations of Link Layer Type

   This specification

   As RPL is a routing protocol, it of course does not rely on any
   particular features of a specific link layer technologies.  It is anticipated that an
   implementer technology.  RPL should
   be able to operate RPL over a variety of different link layers, including
   but not limited to low power wireless or PLC (Power Line
   Communication) technologies.

   Implementers may find RFC 3819 [RFC3819] a useful reference when
   designing a link layer interface between RPL and a particular link
   layer technology.

2.  Terminology

   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].

   This document requires readers to be familiar with the terminology
   described in `Terminology in Low power And Lossy Networks'
   [I-D.ietf-roll-terminology].

   DAG:  Directed Acyclic Graph.  A directed graph having the property
         that all edges are oriented in such a way that no cycles exist.
         In the RPL context, all
         All edges are contained in paths oriented toward and
         terminating at one or more root nodes (a nodes.

   DAG root,
         or sink- typically a Low power and Lossy Network Border Router
         (LBR)).  For the purpose of this document, the term DAG is
         often used to refer to a DAG Iteration as defined below.

   DAG Instance:  A DAG Instance is Instance:  A DAG Instance is a set of possibly multiple
         Destination Oriented DAGs.  A network may have more than one
         DAG Instance, and a RPL router can participate to multiple DAG
         instances.  Each DAG Instance operates independently of other
         DAG Instances.  This document describes operation within a
         single DAG instance.

   InstanceID:  Unique identifier of a DAG Instance.

   Destination Oriented DAG: DAG (DODAG):  A DAG rooted at a single
         destination, which is a node with no outgoing edges.  The tuple
         (InstanceID, DAGID) uniquely identifies a Destination Oriented DAG.
         DAG (DODAG).  In the RPL context, a router can can belong to at
         most one Destination
         Oriented DAG DODAG per DAG Instance.

   DAGID:  The identifier of a DAG DODAG root.  The DAGID must be unique
         within the scope of a DAG Instance in the LLN.

   DAG

   DODAG Iteration:  The DAG that results from the iterative process that
         reshapes the Destination Oriented DAG upon  A specific sequence number iteration of a stimulation by the
         root. DODAG.

   DAGSequenceNumber:  A sequential counter that is incremented by the
         root to form a new Iteration of a DAG. DODAG.  A DAG DODAG Iteration is
         identified uniquely by the (InstanceID, DAGID,
         DAGSequenceNumber) tuple.

   DAG parent:  A parent of a node within a DAG is one of the immediate
         successors of the node on a path towards the DAG root.

   DAG sibling:  A sibling of a node within a DAG is defined in this
         specification to be any neighboring node which is located at
         the same rank within a DAG.  Note that siblings defined in this
         manner do not necessarily share a common parent.

   DAG root:  A DAG root is a node within the DAG that has no outgoing
         edges.  Because the graph is acyclic, by definition all DAGs
         must have at least one DAG root and all paths terminate at a
         DAG root.

   Sub-DAG  The sub-DAG of a node is the set of other nodes in the DAG
         that might use a path towards the DAG root that contains the
         node.  Nodes in the sub-DAG of a node have a greater rank
         (although not all nodes of greater rank are in the sub-DAG).

   Grounded:  A DAG is grounded if it contains a DAG root offering
         connectivity to an external routed infrastructure such as the
         public Internet or a private core (non-LLN) IP network.

   Floating:  A DAG is floating if is not grounded.  A floating DAG is
         not expected to reach any additional external routed
         infrastructure such as the public Internet or a private core
         (non-LLN) IP network.

   Inward:  Inward

   Up:   Up refers to the direction from leaf nodes towards DAG DODAG roots,
         following the orientation of the edges within the DAG.

   Outward:  Outward DODAG.

   Down: Down refers to the direction from DAG DODAG roots towards leaf
         nodes, going against the orientation of the edges within the
         DAG.
         DODAG.

   OCP:  Objective Code Point.  The Objective Code Point is used to
         indicate which Objective Function is in use in a DAG. DODAG.  The
         Objective Code Point is further described in
         [I-D.ietf-roll-routing-metrics].

   OF:   Objective Function.  The Objective Function (OF) defines which
         routing metrics, optimization objectives, and related functions
         are in use in a DAG. DODAG.  The Objective Function is further
         described in [I-D.ietf-roll-routing-metrics].

   Note that in this document, the terms `node' and `LLN router' are
   used interchangeably.

3.  Protocol Model

   Goal: The aim of this section Goal is to describe RPL in the spirit of
   [RFC4101].  Protocol details can be found in further sections.

3.1.  Overview

3.1.1.  Topology Instance and Objectives

   A topology instance of RPL exists over the scope of an LLN in support a host or set of hosts that satisfy a particular application,
         application objective / OF.  Whether or service, and is optimized according not a DODAG can provide
         connectivity to a certain objective, as determined by an Objective Function (OF),
   and may goal is a property of the DODAG.  For
         example, a goal might be characterized by certain destination prefixes a host serving as well.  A
   topology instance, a data collection
         point, or DAG Instance, may be administratively
   associated with a gateway providing connectivity to an InstanceID. external
         infrastructure.

   Grounded:  A DAG is grounded when the root can reach the Goal of the
         objective function.

   Floating:  A DAG is floating if is not Grounded.  A floating DAG is
         not expected to reach the Goal defined for the OF.

   As they form networks, LLN devices often mix the roles of `host' and
   `router' when compared to traditional IP networks.  In this document,
   `host' refers to an LLN device that can generate but does not forward
   RPL traffic, `router' refers to an LLN device that can forward as
   well as generate RPL traffic, and `node' refers to any RPL device,
   either a host or a router.

3.  Protocol Model

   The aim of this section is to describe RPL in the spirit of
   [RFC4101].  Protocol details can be found in further sections.

3.1.  Instances, DODAGs, and DODAG Iterations

   Each DAG instance constructs a routing topology optimized for a
   certain Objective Function (OF).  A DAG instance may provide routes
   to certain destination prefixes.  A single topology instance may comprise:

   o  a single DAG instance contains one
   or more Destination Oriented DAG (DODAG) roots.  These roots may
   operate independently, or may coordinate over a non-LLN backchannel.

   Each root has a unique identifier, the DAGID, such that nodes can
   identify the DODAG root.

   A DAG instance may comprise:

   o  a single DODAG with a single DAG root

      *  For example, a DAG DODAG optimized to minimize latency rooted at a
         single centralized lighting controller in a home automation
         application.

   o  multiple uncoordinated Destination Oriented DAGs DODAGs with independent
      DAG roots (differing
      DAGIDs)
      *  For example, multiple data collection points in an urban data
         collection application that do not have an always-on backbone
         suitable to coordinate to form a single DAG, DODAG, and further use
         the formation of multiple DAGs DODAGs as a means to dynamically and
         autonomously partition the network.

   o  a single Destination Oriented DAG DODAG with multiple DAG roots a single virtual root coordinating LLN sinks
      (with the same DAGID) over some non-LLN backbone

      *  For example, multiple border routers operating with a reliable
         backbone, e.g. in support of a 6LowPAN application, that are
         capable to act as logically equivalent sinks to the same DAG. DODAG.

   o  a combination of one of the above as suited to some application
      scenario

   The exact deployment scenario is determined as appropriate to the
   application and capabilities of the LLN nodes.  What is suitable for
   one deployment may not be possible or necessary for another.
      scenario.

   Traffic is bound to a specific DAG DODAG Instance by a marking in the
   flow label of the IPv6 header.  Traffic originating in support of a
   particular application may be tagged to follow an appropriate DAG
   instance, for example to follow paths optimized for low latency or
   low energy.  The provisioning or automated discovery of a mapping
   between an InstanceID and a type or service of application traffic is
   beyond the scope of this specification.

   Conceptually a node running RPL may capable to maintain

   An example of a membership
   in multiple DAG Instances in support Instance comprising a number of different application
   services and/or optimization objectives.  For example, one instance
   may optimize for minimizing latency and a separate orthogonal
   instance may optimize for minimizing energy.  This scenario does
   introduce some additional considerations, for example loop avoidance
   and default routing behavior.  These considerations are beyond the
   scope of this specification and are intended to be elaborated on in a
   future revision of this or a companion specification.  As such, this
   specification will deal exclusively with the scenario where a node
   implements RPL in support of a single DAG Instance.

3.1.2.  Multipoint-to-Point Traffic Flows and DAGs

   Many of the dominant traffic flows in support of the LLN application
   scenarios are MP2P flows ([I-D.ietf-roll-building-routing-reqs],
   [I-D.ietf-roll-home-routing-reqs], [RFC5673], and [RFC5548]).  These
   flows are rooted at designated nodes that have some application
   significance, such as providing connectivity to an external routed
   infrastructure.  The term "external" is used to refer to the public
   Internet or a core private (non-LLN) IP network.

   LLN nodes running RPL will construct Directed Acyclic Graphs (DAGs)
   rooted at DAG roots, which may be naturally designated according to
   their application significance.  This structure provides the routing
   solution for the dominant MP2P traffic flows.  The DAG structure
   further provides each node potentially multiple successors for MP2P
   flows, which may be used for, e.g., local route repair or load
   balancing.

   Nodes running RPL are able to further restrict the scope of the
   routing problem by using the DAG as a reference topology.  By
   referencing a rank property that DODAGs is related to the positions in the
   DAG, nodes are able to determine their positions
   depicted in a DAG relative to
   each other.  This information Figure 1.  A DODAG Iteration is used by RPL depicted in part to construct
   rules for movement relative to the DAG that endeavor to avoid loops.
   It is important to note that the rank property is derived from
   metrics, and not directly from the position in the DAG (Section 5.3).

3.1.3.  Point-to-Multipoint Traffic Flows

   As DAGs are organized, RPL will use a destination advertisement
   mechanism to build up routing tables in support of outward P2MP
   traffic flows.  This mechanism, using the DAG as a reference,
   distributes routing information across intermediate nodes (between
   the DAG leaves and the root), guided along the DAG, such that the
   routes toward destination prefixes in the outward direction may be
   set up.  As the DAG undergoes modification during DAG maintenance,
   the destination advertisement mechanism can be triggered to update
   the outward routing state.

3.1.4.  Point-to-Point Traffic Flows

   A baseline support for P2P traffic in RPL is provided by the DAG, as
   P2P traffic may flow inward along the DAG until a common parent is
   reached that has stored an entry for the destination in its routing
   table and is capable of directing the traffic outward along the
   correct outward path.  RPL also provides support for the trivial case
   where a P2P destination may be a `one-hop' neighbor.  In the present
   document RPL does not specify nor preclude any additional mechanisms
   that may be capable to compute and install more optimal routes into
   LLN nodes in support of arbitrary P2P traffic according to some
   routing metric.

3.2.  Protocol Operation

3.2.1.  DAG Construction

3.2.1.1.  DAG Information Object (DIO)

   A DAG Information Object is defined and used by RPL in order to build
   and maintain a DAG.  This document defines an ICMPv6 Message Type RPL
   Control Message, which is capable to carry the DIO.  The DIO message
   conveys information about the DAG, including:

   o  A DAGID used to identify the DAG as sourced from the DAG root.
      The DAGID must be unique to a single DAG in the scope of the LLN.

   o  Objective Function identified by an Objective Code Point (OCP) as
      described below.

   o  Rank information used by nodes to determine their positions in the
      DAG relative to each other.

   o  Sequence number originated from the DAG root, used to aid in
      identification of dependent sub-DAGs and coordinate topology
      changes in a manner so as to avoid loops.

   o  Indications and configuration for the DAG, e.g. grounded or
      floating, administrative preference, ...

   o  A set of path metrics and constraints, as further described in
      [I-D.ietf-roll-routing-metrics].

   o  List of additional destination prefixes reachable inwards along
      the DAG.

   The DIO messages are issued whenever a change is detected to the DAG
   such that a node is able to determine that a region of the DAG has
   become inconsistent.  As the DAG stabilizes the period at which RA
   messages occur is configured to taper off, reducing the steady-state
   overhead of DAG maintenance.  The periodic issue of DIO messages,
   along with the triggered DIO messages in response to inconsistency,
   is one feature that enables RPL to operate in the presence of
   unreliable links.

3.2.1.2.  Grounded and Floating DAGs

   Certain LLN nodes may offer connectivity to an external routed
   infrastructure in support of an application scenario.  These nodes
   are designated `grounded', and may serve as the DAG roots of a
   grounded DAG.  DAGs that do not have a grounded DAG root are floating
   DAGs.  In either case routes may be provisioned toward the DAG root,
   although in the floating case there is no expectation to reach an
   external infrastructure.  Some applications will include permanent
   floating DAGs.

3.2.1.3.  Administrative Preference

   An administrative preference may be associated with each DAG root,
   and thereby each DAG, in order that some DAGs in the LLN may be more
   preferred over other DAGs.  For example, a DAG root that is sinking
   traffic in support of a data collection application may be configured
   by the application to be very preferred.  A transient DAG, e.g. a DAG
   that is only existing until a permanent DAG is found, may be
   configured to be less preferred.  The administrative preference
   offers a way to engineer the formation of the DAG in support of the
   application.

3.2.1.4.  Objective Function (OF)

   The Objective Function (OF) conveys and controls the optimization
   objectives in use within the DAG.  The Objective Function is
   indicated by an Objective Code Point (OCP), and is further specified
   in [I-D.ietf-roll-routing-metrics].  Each instance of an allocated OF
   indicates:

   o  The set of metrics used within the DAG

   o  The method used for least cost path determination.

   o  The method used to compute DAG Rank

   o  The methods used to prepare metrics for propagation within a DIO
      message

   By using defined OCPs that are understood by all nodes in a
   particular implementation, and by conveying them in the DIO message,
   RPL nodes may work to build optimized LLN using a variety of
   application and implementation specific metrics and goals.

   A default OF, OF0 (designated by OCP value of 0x0000), is specified
   with a well-defined default behavior.  OF0 may be used to define RPL
   behaviors in the case where a node encounters a DIO message
   containing a code point that it does not support, if allowed by
   policy.

3.2.1.5.  Distributed Algorithm Operation

   A high level overview of the distributed algorithm which constructs
   the DAG is as follows:

   o  Some nodes may be initially provisioned to act as DAG roots,
      either permanent or transient, with associated preferences.

   o  Nodes will maintain a data structure containing their candidate
      (viable) neighbors, as determined by the implementation.  This
      data structure will also track DAG information as learned from and
      associated with each neighbor.

   o  Nodes that are members of a DAG, including DAG roots, will
      multicast DIO messages as needed (when inconsistency is detected),
      to their link-local neighbors.  Nodes will also respond to DIS
      messages.

   o  Nodes that receive DIO messages may either discard the DIO based
      on several criteria, including rank-based loop avoidance rules, or
      process the DIO to maintain a position in an existing DAG or
      improve a position as according to an Objective Function (OF) and
      current path cost.

   o  Nodes manage a set of DAG Parents according to the rules specified
      by RPL.  This set is also augmented to include DAG siblings.

   o  DIO messages may be emitted more or less frequently as a function
      of DAG consistency.

   o  As less preferred DAGs encounter more preferred DAGs that offer
      equivalent or better optimization objectives for the same
      InstanceID, the nodes in the less preferred DAGs may leave to join
      the more preferred DAGs, finally leaving only the more preferred
      DAGs.  This is an illustration of the mechanism by which an
      application may engineer DAG construction.

   o  The nodes provision routing table entries for the destinations
      specified by the DIO towards their DAG Parents.  Nodes may
      provision a DAG Parent as a default gateway.

3.2.2.  Destination Advertisement

   As RPL constructs DAGs, nodes may provision routes toward
   destinations advertised through DIO messages through their selected
   parents, and are thus able to send traffic inward along the DAG by
   forwarding to their selected parents.  However, this mechanism alone
   is not sufficient to support P2MP traffic flowing outward along the
   DAG from the DAG root toward nodes.  A destination advertisement
   mechanism is employed by RPL to build up routing state in support of
   these outward flows.  The destination advertisement mechanism may not
   be supported in all implementations, as appropriate to the
   application requirements.  A DAG root that supports using the
   destination advertisement mechanism to build up routing state will
   indicate such in the DIO message.  A DAG root that supports using the
   destination advertisement mechanism must be capable of allocating
   enough state to store the routing state received from the LLN.

3.2.2.1.  Destination Advertisement Object (DAO)

   A Destination Advertisement Object is defined and used by RPL in
   order to convey the destination information inward along the DAG
   toward the DAG root.  This document defines an ICMPv6 Message Type
   RPL Control Message, which is capable to carry the DAO.  The
   information conveyed in the DAO message includes the following:

   o  A lifetime and sequence counter to determine the freshness of the
      destination advertisement.

   o  Depth information used by nodes to determine how far away the
      destination (the source of the destination advertisement) is

   o  Prefix information to identify the destination, which may be a
      prefix, an individual host, or multicast listeners

   o  Reverse Route information to record the nodes visited (along the
      outward path) when the intermediate nodes along the path cannot
      support storing state for Hop-By-Hop routing.

3.2.2.2.  Destination Advertisement Operation

   As the DAG is constructed and maintained, nodes are capable to emit
   DAO messages to a subset of their DAG parents.

3.2.2.2.1.  `One-Hop' Neighbors

   As a special case, a node may periodically emit a link-local
   multicast IPv6 DAO message advertising its locally available
   destination prefixes.  This mechanism allows for the one-hop
   neighbors of a node to learn explicitly of the prefixes on the node,
   and in some application specific scenarios this is desirable in
   support of provisioning a trivial `one-hop' route.  In this case,
   nodes that receive the multicast destination advertisement may use it
   to provision the one-hop route only, and not engage in any additional
   processing (so as not to engage the mechanisms used by a DAG parent).

3.2.2.2.2.  Operation in Support of Stateful Nodes

   When a (unicast) DAO message reaches a node capable of storing
   routing state, the node extracts information from the DAO message and
   updates its local database with a record of the DAO message and the
   neighbor that it was received from.  When the node later propagates
   DAO messages, it selects the best (least depth) information for each
   destination and conveys this information again in the form of DAO
   messages to a subset of its own DAG parents.  At this time the node
   may perform route aggregation if it is able, thus reducing the
   overall number of DAO messages.

3.2.2.2.3.  Operation in Support of Stateless Nodes

   When a (unicast) DAO message reaches a node incapable of storing
   additional state, the node must append the next-hop address (from
   which neighbor the DAO message was received) to a Reverse Route Stack
   carried within the DAO message.  The node then passes the DAO message
   on to one or more of its DAG parents without storing any additional
   state.

   When a node that is capable of storing routing state encounters a
   (unicast) DAO message with a Reverse Route Stack that has been
   populated, the node knows that the DAO message has traversed a region
   of nodes that did not record any routing state.  The node is able to
   detach and store the Reverse Route State and associate it with the
   destination described by the DAO message.  Subsequently the node may
   use this information to construct a source route in order to bridge
   the region of nodes that are unable to support Hop-By-Hop routing to
   reach the destination.

3.2.2.2.4.  Additional Considerations

   Further aggregations of DAO messages prefix reachability information
   by destinations are possible in order to support additional
   scalability.

   A special case of an DAO message, termed a `no-DAO', may be used to
   tear down the routing state that has been established by the
   destination advertisement mechanism in case of, e.g., unreachability
   or other events that affect the outward routing state.

   A further example of the operation of the destination advertisement
   mechanism is available in Appendix B.1

3.3.  Loop Avoidance and Stability

   The goal of a guaranteed consistent and loop free global routing
   solution for an LLN may not be practically achieved given the real
   behavior and volatility of the underlying metrics.  The trade offs to
   achieve a stable approximation of global convergence may be too
   restrictive with respect to the need of the LLN to react quickly in
   response to the lossy environment.  Globally the LLN may be able to
   achieve a weak convergence, in particular as link changes are able to
   be handled locally and result in minimal changes to global topology.

   RPL does not aim to guarantee loop free path selection, or strong
   global convergence.  In order to reduce control overhead, in
   particular the expense of mechanisms such as count-to-infinity, RPL
   does try to avoid the creation of loops when undergoing topology
   changes.

   RPL includes rank-based mechanisms for detecting loops to ensure that
   packets make forward progress within the DAG and trigger DAG repair
   if necessary.

3.3.1.  Greediness and Rank-based Instabilities

   Once a node has joined a DAG, RPL disallows certain behaviors,
   including greediness, in order to prevent resulting instabilities in
   the DAG.

   If a node is allowed to be greedy and attempts to move deeper in the
   DAG, beyond its most preferred parent, in order to increase the size
   of the DAG parent set, then an instability can result.  This is
   illustrated in Figure 14.

   Suppose a node is willing to receive and process a DIO messages from
   a node in its own sub-DAG, and in general a node deeper than it.  In
   such cases a chance exists to create a feedback loop, wherein two or
   more nodes continue to try and move in the DAG in order to optimize
   against each other.  In some cases this will result in an
   instability.  It is for this reason that RPL mandates that a node
   never receive and process DIO messages from deeper nodes.  This rule
   creates an `event horizon', whereby a node cannot be influenced into
   an instability by the action of nodes that may be in its own sub-DAG.

   A further example of the consequences of greedy operation, and
   instability related to processing DIO messages from nodes of greater
   rank, may be found in Appendix B.4

3.3.2.  DAG Loops

   A DAG loop may occur when a node detaches from the DAG and reattaches
   to a device in its prior sub-DAG.  This may happen in particular when
   DIO messages are missed.  Strict use of the DAG sequence number can
   eliminate this type of loop.

3.3.3.  DAO Loops

   A DAO loop may occur when the parent has a route installed upon
   receiving and processing a DAO message from a child, but the child
   has subsequently cleaned up the state.  This loop happens when a no-
   DAO was missed till a heartbeat cleans up all states.  RPL includes
   loop detection mechanisms that may mitigate the impact of DAO loops
   and trigger their repair.

   In the case where stateless DAO operation is used, i.e. source
   routing specifies the outwards routes, then DAO Loops should not
   occur on the stateless portions of the path.

3.3.4.  Sibling Loops

   Sibling loops could occur if a group of siblings kept choosing
   amongst themselves as successors such that a packet does not make
   forward progress.  This specification limits the number of times that
   sibling forwarding may be used at a given rank to prevent sibling
   loops.

4.  Routing Metrics and Constraints Used By RPL

   Routing metrics are used by routing protocols to compute the shortest
   paths.  Interior Gateway Protocols (IGPs) such as IS-IS ([RFC5120])
   and OSPF ([RFC4915]) use static link metrics.  Such link metrics can
   simply reflect the bandwidth or can also be computed according to a
   polynomial function of several metrics defining different link
   characteristics; in all cases they are static metrics.  Some routing
   protocols support more than one metric: in the vast majority of the
   cases, one metric is used per (sub)topology.  Less often, a second
   metric may be used as a tie-breaker in the presence of Equal Cost
   Multiple Paths (ECMP).  The optimization of multiple metrics is known
   as an NP complete problem and is sometimes supported by some
   centralized path computation engine.

   In contrast, LLNs do require the support of both static and dynamic
   metrics.  Furthermore, both link and node metrics are required.  In
   the case of RPL, it is virtually impossible to define one metric, or
   even a composite, that will satisfy all use cases.

   In addition, RPL supports constrained-based routing where constraints
   may be applied to link and nodes.  If a link or a node does not
   satisfy a required constraint, it is `pruned' from the candidate list
   thus leading to a constrained shortest path.

   The set of supported link/node constraints and metrics is specified
   in [I-D.ietf-roll-routing-metrics].

   The role of the Objective Function is to advertise routing metrics
   and constraints in addition to the objectives used to compute the
   (constrained) shortest path.

   Example 1: Shortest path: path offering the shortest end-to-end delay

   Example 2: Constrained shortest path: the path that does traverse any
              battery-operated node and that optimizes the path
              reliability

5.  RPL Protocol Specification

5.1.  RPL Messages

5.1.1.  ICMPv6 RPL Control Message

   This document defines the RPL Control Message, a new ICMPv6 message.
   The RPL Control Message has the following general format, in
   accordance with [RFC4443]:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |     Code      |          Checksum             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                         Message Body                          +
       |                                                               |

                       Figure 1: RPL Control Message

   The RPL Control message is an ICMPv6 information message with a
   requested Type of 155.

   The Code will be used to identify RPL Control Messages as follows:

   o  0x01: DAG Information Solicitation (Section 5.1.2)

   o  0x02: DAG Information Object (Section 5.1.3)

   o  0x04: Destination Advertisement Object (Section 5.1.4)

5.1.2.  DAG Information Solicitation (DIS)

   The DAG Information Solicitation (DIS) message may be used to solicit
   a DAG Information Object from a RPL node.  Its use is analogous to
   that of a Router Solicitation; a node may use DIS to probe its
   neighborhood for nearby DAGs.  The DAG Information Solicitation
   carries no additional message body.

5.1.3.  DAG Information Object (DIO)

   The DAG Information Object carries a number of metrics and other
   information that allows a node to discover a DAG, select its DAG
   parents, and identify its siblings while employing loop avoidance
   strategies.

5.1.3.1.  DIO Base Option

   The DIO Base Option is a container option, which is always present,
   and might contain a number of suboptions.  The base option regroups
   the minimum information set that is mandatory in all cases.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |G|D|A|0|0| Prf |   Sequence    |  InstanceID   |    DAGRank    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                            DAGID                              |
       +                                                               +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   sub-option(s)...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 2: DIO Base Option

   Control Field:  The DAG Control Field is currently allocated as
         follows:

         Grounded (G):  The Grounded (G) flag is set when the DAG root
               is offering connectivity to an external routed
               infrastructure such as the Internet.

         Destination Advertisement Trigger (D):  The Destination
               Advertisement Trigger (D) flag is set when the DAG root
               or another node in the successor chain decides to trigger
               the sending of destination advertisements in order to
               update routing state for the outward direction along the
               DAG, as further detailed in Section 5.10.  Note that the
               use and semantics of this flag are still under
               investigation.

         Destination Advertisement Supported (A):  The Destination
               Supported (A) bit is set when the DAG root is capable to
               support the collection of destination advertisement
               related routing state and enables the operation of the
               destination advertisement mechanism within the DAG.

         DAGPreference (Prf):  3-bit unsigned integer set by the DAG
               root to its preference and unchanged at propagation.
               DAGPreference ranges from 0x00 (least preferred) to 0x07
               (most preferred).  The default is 0 (least preferred).
               The DAG preference provides an administrative mechanism
               to engineer the self-organization of the LLN, for example
               indicating the most preferred LBR.  If a node has the
               option to join a more preferred DAG while still meeting
               other optimization objectives, then the node will
               generally seek to join the more preferred DAG as
               determined by the OF.

         Unassigned bits of the Control Field are considered as
         reserved.  They MUST be set to zero on transmission and MUST be
         ignored on receipt.

   Sequence Number:  8-bit unsigned integer set by the DAG root,
         incremented according to a policy provisioned at the DAG root,
         and propagated with no change outwards along the DAG.  Each
         increment SHOULD have a value of 1 and may cause a wrap back to
         zero.

   InstanceID:  8-bit field indicating the topology instance associated
         with the DAG, as provisioned at the DAG root.

   DAGRank:  8-bit unsigned integer indicating the DAG rank of the node
         sending the DIO message.  The DAGRank of the DAG root is
         ROOT_RANK.  DAGRank is further described in Section 5.4.

   DAGID:  128-bit unsigned integer which uniquely identify a DAG.  This
         value is set by the DAG root.  The global IPv6 address of the
         DAG root can be used, however. the DAGID MUST be unique per DAG
         within the scope of the LLN.  In the case where a DAG root is
         rooting multiple DAGs the DAGID MUST be unique for each Figure 2.

     +----------------------------------------------------------------+
     |                                                                |
     | +--------------+                                               |
     | |              |                                               |
     | |     (R1)     |            (R2)                   (Rn)        |
     | |     /  \     |            /| \                  / |  \       |
     | |    /    \    |           / |  \                /  |   \      |
     | |  (A)    (B)  |         (C) |  (D)     ...    (F) (G)  (H)    |
     | |  /|\     |\  |         /   |   |\             |   |    |     |
     | | : : :    : : |        :   (E)  : :            :   :    :     |
     | |              |            / \                                |
     | +--------------+           :   :                               |
     |      DODAG                                                     |
     |                                                                |
     +----------------------------------------------------------------+
                                DAG
         rooted at a specific Instance

                          Figure 1: DAG root.

   The following values MUST NOT change during the propagation of DIO
   messages outwards along the DAG:
      Grounded (G)
      Destination Advertisement Supported Instance

            +----------------+                +----------------+
            |                |                |                |
            |      (R1)      |                |      (R1)      |
            |      /  \      |                |      /         |
            |     /    \     |                |     /          |
            |   (A)
      DAGPreference (Prf)
      Sequence
      InstanceID
      DAGID
   All other fields of the DIO message may be updated at each hop of the
   propagation.

5.1.3.1.1.  DIO Suboptions

   In addition to the minimum options presented in the base option,
   several suboptions are defined for the DIO message:

5.1.3.1.1.1.  Format
        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -    (B)   |  Subopt. Type         \      |         Subopt Length   (A)          | Subopt Data
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -

                  Figure 3: DIO Suboption Generic Format

   Suboption Type:  8-bit identifier of the type of suboption.  When
         processing a DIO message containing a suboption for which the
         Suboption Type value is not recognized by the receiver, the
         receiver MUST silently ignore the unrecognized option, continue
         to process the following suboption, correctly handling any
         remaining options in the message.

   Suboption Length:  16-bit unsigned integer, representing the length
            |   /|\     |\   |    ------\     |   /|\          |
            |  : : (C)  : :  |           \    |  : : (C)       |
            |                |           /    |        \       |
            |                |    ------/     |         \      |
            |                |         /      |         (B)    |
            |                |                |          |\    |
            |                |                |          : :   |
            |                |                |                |
            +----------------+                +----------------+
                Sequence N                       Sequence N+1

                         Figure 2: DODAG Iteration

3.2.  Traffic Flows

3.2.1.  Multipoint-to-Point Traffic

   Multipoint-to-Point (MP2P) is a dominant traffic flow in octets of the suboption, not including the suboption Type
         and Length fields.

   Suboption Data:  A variable length field that contains data specific
         to the option. many LLN
   applications ([I-D.ietf-roll-building-routing-reqs],
   [I-D.ietf-roll-home-routing-reqs], [RFC5673], [RFC5548]).  The following subsections specify the DIO message suboptions which
   destinations of MP2P flows are currently defined for use in the DAG Information Object.

   Implementations MUST silently ignore any DIO message suboptions
   options designated nodes that they do not understand.

   DIO message suboptions may have alignment requirements.  Following
   the convention in IPv6, these options are aligned in a packet some
   application significance, such
   that multi-octet values within the Option Data field of each option
   fall on natural boundaries (i.e., fields of width n octets are placed
   at an integer multiple of n octets from the start of as providing connectivity to the header, for
   n = 1, 2, 4,
   larger Internet or 8).

5.1.3.1.1.2.  Pad1

   The Pad1 suboption does not have any alignment requirements.  Its
   format core private IP network.  RPL supports MP2P
   traffic by allowing MP2P destinations to be reached via DODAG roots.

3.2.2.  Point-to-Multipoint Traffic

   Point-to-multipoint (P2MP) is as follows:

        0
        0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+
       |   Type = 0    |
       +-+-+-+-+-+-+-+-+

                              Figure 4: Pad 1

   NOTE! a traffic pattern required by several
   LLN applications ([I-D.ietf-roll-building-routing-reqs],
   [I-D.ietf-roll-home-routing-reqs], [RFC5673], [RFC5548]).  RPL
   supports P2MP traffic by using a destination advertisement mechanism
   that provisions routes toward destination prefixes and away from
   roots.  Destination advertisements can update routing tables as the format of
   underlying DODAG topology changes.

3.2.3.  Point-to-Point Traffic

   RPL DODAGs provide a basic structure for point-to-point (P2P)
   traffic.  For a RPL network to support P2P traffic, a root must be
   able to route packets to a destination.  Nodes within the Pad1 option is network may
   also have routing tables to destinations.  A packet flows towards a special case -
   root until it reaches an ancestor that has a known route to the
   destination.

   RPL also supports the case where a P2P destination is a `one-hop'
   neighbor.

   RPL neither Option Length specifies nor Option Data fields.

   The Pad1 option is used precludes additional mechanisms for
   computing and installing more optimal routes to insert one or two octets of padding in the
   DIO message support arbitrary P2P
   traffic.

3.3.  DODAG Construction

   RPL provisions routes up towards DODAG roots, forming a DODAG
   optimized according to enable suboptions alignment.  If more than two octets
   of padding is required, the PadN option, described next, should be
   used rather than multiple Pad1 options.

5.1.3.1.1.3.  PadN

   The PadN option does not have any alignment requirements.  Its format
   is as follows:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
       |   Type = 1    |         Subopt Length         | Subopt Data
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -

                              Figure 5: Pad N

   The PadN option is Objective Function (OF) in use.  RPL nodes
   construct and maintain these DODAGs through exchange of DAG
   Information Object (DIO) messages.  Undirected links between siblings
   are also identified during this process, which are used to insert three or more octets of padding in
   the provide
   additional diversity.

3.3.1.  DAG Information Object (DIO)

   A DIO message identifies the DAG Instance, the DAGID, the values used to enable suboptions alignment.  For N (N > 2) octets
   of padding,
   compute the Option Length field contains DAG Instance's objective function, and the value N-3, present DODAG
   Sequence Number.  It can also include additional routing and
   configuration information.  The DIO includes a measure derived from
   the
   Option Data consists position of N-3 zero-valued octets.  PadN Option data
   MUST be ignored by the receiver.

5.1.3.1.1.4.  DAG Metric Container

   The DAG Metric Container suboption may be aligned as necessary to
   support its contents.  Its format is as follows:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
       |   Type = 2    |       Container Length        | DAG Metric Data
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -

                      Figure 6: DAG Metric Container

   The DAG Metric Container node within the DODAG, the rank, which is used
   for nodes to report aggregated path metrics
   along determine their positions relative to each other and to
   inform loop avoidance/detection procedures.  RPL exchanges DIO
   messages to establish and maintain routes.

   RPL adapts the DAG.  The rate at which nodes send DIO messages.  When a DODAG
   is detected to be inconsistent or needs repair, RPL sends DIO
   messages more frequently.  As the DODAG stabilizes, the DIO message
   rate tapers off, reducing the maintenance cost of a steady and well-
   working DODAG.

   This document defines an ICMPv6 Message Type RPL Control Message,
   which is capable of carrying a DIO.

3.3.2.  DAG Metric Container Repair

   RPL supports global repair over the DODAG.  A DODAG Root may contain
   increment the DODAG Sequence Number to institute a number of
   discrete node, link, and aggregate path metrics as chosen by global repair,
   revising the
   implementer.  The Container Length field contains DODAG and allowing nodes to choose an arbitrary new
   position within the length in
   octets of new DODAG iteration.

   RPL may support mechanisms for local repair within the DAG Metric Data. DODAG
   iteration.  The order, content, and coding of DIO message will specify the
   DAG Metric Container data is necessary parameters as specified in

   [I-D.ietf-roll-routing-metrics].

   The processing and propagation of
   configured from the DAG Metric Container DODAG root.  Local repair options include the
   allowing a node, upon detecting a loss of connectivity to a DODAG it
   is
   governed a member of, to:

   o  Poison its sub-DAG by implementation specific policy functions.

5.1.3.1.1.5.  Destination Prefix

   The Destination Prefix suboption does not have any alignment
   requirements.  Its format is as follows:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 3    |            Length             |Resvd|Prf|Resvd|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Prefix Lifetime                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Prefix Length |                                               |
       +-+-+-+-+-+-+-+-+                                               |
       |             Destination Prefix (Variable Length)              |
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 7: DAG Destination Prefix

   The Destination Prefix suboption is used when advertising an effective rank of INFINITY,
      OR detach and form a floating DODAG in order to preserve inner
      connectivity within its sub-DAG.

   o  Move down the DAG root, or
   another node located inwards along DODAG iteration in a limited manner, no further than
      a bound configured via the DAG on DIO so as not to count all the path way to
      infinity.  Such a move may be undertaken after waiting an
      appropriate poisoning interval, and should allow the DAG
   root, needs node to indicate that it
      restore connectivity to the DODAG Iteration if possible.

3.3.3.  Grounded and Floating DODAGs

   DODAGs can be grounded or floating.  A grounded DODAG offers
   connectivity to destination
   prefixes other than to a goal.  A floating DODAG offers no such
   connectivity, and provides routes only to nodes within the default.  This DODAG.
   Floating DODAGs may be useful used, for example, to preserve inner
   connectivity during repair.

3.3.4.  Administrative Preference

   An implementation/deployment may specify that some DODAG roots should
   be used over others through an administrative preference.
   Administrative preference offers a way to control traffic and
   engineer DODAG formation in cases where
   more than one LBR order to better support application
   requirements or needs.

3.3.5.  Objective Function (OF)

   The Objective Function (OF) implements the optimization objectives of
   route selection within the DAG Instance.  The OF is operating identified by an
   Objective Code Point (OCP) within the LLN DIO, and offering
   connectivity its specification also
   indicates the metrics and constraints in use.  The OF also specifies
   the procedure used to different administrative domains, e.g. compute rank within a home network DODAG iteration.  Further
   details may be found in [I-D.ietf-roll-routing-metrics] and a utility network.  In such cases, upon observing the Destination
   Prefixes offered related
   companion specifications.

   By using defined OFs that are understood by all nodes in a particular DAG,
   implementation, and by referencing them in the DIO message, RPL nodes
   may work to build optimized LLN routes using a variety of application
   and implementation specific metrics and goals.

   In the case where a node MAY decide is unable to encounter a suitable DAG
   Instance using a known Objective Function, it may be configured to
   join
   multiple DAGs in support of a particular application.

   The Length is coded DAG Instance using and unknown Objective Function but only
   acting as the length a leaf node.

3.3.6.  Distributed Algorithm Operation

   A high level overview of the suboption in octets,
   excluding distributed algorithm which constructs
   the Type and Length fields.

   Prf DODAG is the Route Preference as in [RFC4191].  The reserved fields
   MUST be set follows:

   o  Some nodes are configured to zero on transmission and MUST be ignored on receipt.

   The Prefix Lifetime is DODAG roots, with associated DODAG
      configuration.

   o  Nodes advertise their presence, affiliation with a 32-bit unsigned integer representing DODAG, routing
      cost, and related metrics by sending link-local multicast DIO
      messages.

   o  Nodes may adjust the
   length of time rate at which DIO messages are sent in seconds (relative
      response to the time the packet is sent)
   that the Destination Prefix is valid for route determination.  A
   value of all one bits (0xFFFFFFFF) represents infinity.  A value stability or detection of
   all zero bits (0x00000000) indicates routing inconsistencies.

   o  Nodes listen for DIOs and use their information to join a loss of reachability.

   The Prefix Length is new
      DODAG, or to maintain an 16-bit unsigned integer that indicates the
   number of leading bits in existing DODAG, as according to the destination prefix.
      specified Objective Function and rank-based loop avoidance rules.

   o  The Destination Prefix contains Prefix Length significant bits of nodes provision routing table entries for the
   destination prefix.  The remaining bits of destinations
      specified by the Destination Prefix, as
   required to complete DIO towards their parents in the trailing octet, are set to 0.

   In DODAG iteration.
      Nodes may provision a parent as a default gateway.

   o  Nodes may identify siblings within the event that DODAG iteration to increase
      path diversity.

   o  Using both DIOs and possibly information in data packets, RPL
      nodes detect possible routing loops.  When a DIO message RPL node detects a
      possible routing loop, it may need adapt its DIO transmission rate to specify connectivity
      apply a local repair to
   more than one destination, the topology.  This process and its
      limitations is discussed in greater detail in 3.4.

3.4.  Destination Prefix suboption Advertisement

   As RPL constructs and maintains DODAGs with DIO messages to establish
   upward routes, it may be
   repeated.

5.1.3.1.1.6.  DAG Timer Configuration

   The DAG Timer Configuration suboption does not have any alignment
   requirements.  Its format is as follows:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 4    |            Length             | DIOIntDoubl.  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  DIOIntMin.   |
       +-+-+-+-+-+-+-+-+

                     Figure 8: DAG Timer Configuration

   The DAG Timer Configuration suboption is used use Destination Advertisement Object (DAO)
   messages to distribute
   configuration information for DAG Timer Operation through establish downward routes along the DAG.
   The information communicated in this suboption is generally static DODAG.  DAO messages
   and unchanging within support for downward routes are an optional feature for
   applications that require P2MP or P2P traffic.  DIO messages
   advertise whether the DAG, therefore it destination advertisement mechanism is not necessary to
   include in every DIO.  This suboption MAY be included periodically by enabled.

3.4.1.  Destination Advertisement Object (DAO)

   A Destination Advertisement Object (DAO) conveys destination
   information upwards along the DAG Root, and SHOULD be included DODAG so that a DODAG root (an other
   intermediate nodes) can provision downward routes.  A DAO message
   includes prefix information to identify destinations, a capability to
   record routes in response support of source routing, and information to
   determine the freshness of a unicast
   request, e.g. particular advertisement.

   Nodes that are capable of maintaining routing state may aggregate
   routes from DAO messages that they receive before transmitting a DAG Information Solicitation (DIS) DAO
   message.

   The Length is coded as 2.

   DIOIntervalDoublings is an 8-bit unsigned integer.  Configured on the
   DAG root and used  Nodes that are not capable to maintain routing state may
   attach a next-hop address to configure the trickle timer governing when DIO
   message should be sent Reverse Route Stack contained within
   the DAG.  DIOIntervalDoublings DAO message.  The Reverse Route Stack is the
   number subsequently used to
   generate piecewise source routes over regions of times the LLN that are
   incapable of storing downward routing state.

   A special case of the DIOIntervalMin DAO message, termed a no-DAO, is allowed used to be doubled
   during the trickle timer clear
   downward routing state that has been provisioned through DAO
   operation.

   DIOIntervalMin is

   This document defines an 8-bit unsigned integer.  Configured on the DAG
   root and used ICMPv6 Message Type RPL Control Message,
   which is capable to configure carry the trickle timer governing when DIO DAO.

3.4.1.1.  `One-Hop' Neighbors

   In addition to sending DAOs toward DODAG roots, RPL nodes may
   occasionally emit a link-local multicast DAO message should be sent within the DAG.  The minimum configured
   interval for the DIO trickle timer in units of ms is
   2^DIOIntervalMin.  For example, advertising
   available destination prefixes.  This mechanism allow provisioning a DIOIntervalMin value of 16ms is
   expressed as
   trivial `one-hop' route to local neighbors.

4.

5.1.4.  Destination Advertisement Object (DAO)

   The Destination Advertisement Object (DAO) is  Routing Metrics and Constraints Used By RPL

   Routing metrics are used by routing protocols to propagate
   destination information inwards along compute the DAG.  The RPL shortest
   paths.  Interior Gateway Protocols (IGPs) such as IS-IS ([RFC5120])
   and OSPF ([RFC4915]) use of the
   DAO allows the nodes in static link metrics.  Such link metrics can
   simply reflect the DAG bandwidth or can also be computed according to build up a
   polynomial function of several metrics defining different link
   characteristics; in all cases they are static metrics.  Some routing state for nodes
   contained
   protocols support more than one metric: in the sub-DAG in support vast majority of traffic flowing outward along the DAG.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         DAO Sequence          |  InstanceID   |   DAO Rank    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          DAO Lifetime                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Route Tag                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Prefix Length |    RRCount    |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
       |                   Prefix (Variable Length)                    |
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Reverse Route Stack (Variable Length)             |
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 9:
   cases, one metric is used per (sub)topology.  Less often, a second
   metric may be used as a tie-breaker in the presence of Equal Cost
   Multiple Paths (ECMP).  The Destination Advertisement Object (DAO)

   DAO Sequence:  Incremented optimization of multiple metrics is known
   as an NP complete problem and is sometimes supported by some
   centralized path computation engine.

   In contrast, LLNs do require the support of both static and dynamic
   metrics.  Furthermore, both link and node metrics are required.  In
   the node case of RPL, it is virtually impossible to define one metric, or
   even a composite, that owns will satisfy all use cases.

   In addition, RPL supports constrained-based routing where constraints
   may be applied to link and nodes.  If a link or a node does not
   satisfy a required constraint, it is `pruned' from the prefix for each
         new DAO message for that prefix.

   InstanceID:  8-bit field indicating candidate list
   thus leading to a constrained shortest path.

   The set of supported link/node constraints and metrics is specified
   in [I-D.ietf-roll-routing-metrics].

   The role of the topology instance associated
         with Objective Function is to advertise routing metrics
   and constraints in addition to the DAG, as learned from objectives used to compute the DIO.

   DAO Rank:  Set by
   (constrained) shortest path.

   Example 1: Shortest path: path offering the shortest end-to-end delay

   Example 2: Constrained shortest path: the path that does not traverse
              any battery-operated node and that owns optimizes the prefix path
              reliability

5.  Rank

5.1.  Loop Avoidance

   RPL guarantees neither loop free path selection nor strong global
   convergence.  In order to reduce control overhead, however, such as
   the cost of the count-to-infinity problem, RPL avoids creating loops
   when undergoing topology changes.  Furthermore, RPL includes rank-
   based mechanisms for detecting loops when they do occur.  RPL uses
   this loop detection to ensure that packets make forward progress
   within the DODAG iteration and first issues trigger repairs when necessary.

5.1.1.  Greediness and Rank-based Instabilities

   Once a node has joined a DODAG, RPL disallows certain behaviors,
   including greediness, in order to prevent resulting instabilities in
   the
         DAO message DODAG.

   If a node is allowed to be greedy and attempts to move deeper in the
   DODAG, beyond its rank.

   DAO Lifetime:  32-bit unsigned integer.  The length of time most preferred parent, in
         seconds (relative order to increase the time the packet is sent) that
   size of the
         prefix parent set, then an instability can result.  This is valid for route determination.  A value of all one
         bits (0xFFFFFFFF) represents infinity.  A value of all zero
         bits (0x00000000) indicates
   illustrated in Figure 16.

   Suppose a loss of reachability.

   Route Tag:  32-bit unsigned integer.  The Route Tag may be used node is willing to
         give receive and process a priority to prefixes that should be stored.  This may be
         useful DIO messages from
   a node in its own sub-DAG, and in general a node deeper than it.  In
   such cases where intermediate nodes are capable of storing a limited amount of routing state.  The further specification
         of this field chance exists to create a feedback loop, wherein two or
   more nodes continue to try and its use is under investigation.

   Prefix Length:  Number of valid leading bits move in the IPv6 Prefix.

   RRCount:  8-bit unsigned integer.  This counter is used DODAG in order to count the
         number of entries optimize
   against each other.  In some cases this will result in the Reverse Route Stack.  A value of `0'
         indicates that no Reverse Route Stack is present.

   Prefix:  Variable-length field containing an IPv6 address or
   instability.  It is for this reason that RPL limits the cases where a prefix
   node may process DIO messages from deeper nodes to some forms of
   local repair.  This approach creates an IPv6 address.  The Prefix Length field contains `event horizon', whereby a
   node cannot be influenced beyond some limit into an instability by
   the
         number action of valid leading bits nodes that may be in its own sub-DAG.

   A further example of the prefix.  The bits consequences of greedy operation, and
   instability related to processing DIO messages from nodes of greater
   rank, may be found in Appendix B.4

5.1.2.  DODAG Loops

   A DODAG loop may occur when a node detaches from the
         prefix after the prefix length (if any) are reserved DODAG and MUST
         be set
   reattaches to zero on transmission and MUST be ignored on receipt.

   Reverse Route Stack:  Variable-length field containing a device in its prior sub-DAG.  This may happen in
   particular when DIO messages are missed.  Strict use of the DAG
   sequence number can eliminate this type of
         RRCount (possibly compressed) IPv6 addresses. loop, but this type of
   loop may possibly be encountered when using some local repair
   mechanisms.

5.1.3.  DAO Loops

   A node DAO loop may occur when the parent has a route installed upon
   receiving and processing a DAO message from a child, but the child
   has subsequently cleaned up the state.  This loop happens when a no-
   DAO was missed until a heartbeat cleans up all states.  RPL includes
   loop detection mechanisms that adds may mitigate the impact of DAO loops
   and trigger their repair.

   In the case where stateless DAO operation is used, i.e. source
   routing specifies the down routes, then DAO Loops should not occur on to
   the Reverse Route Stack will append to stateless portions of the list and
         increment path.

5.1.4.  Sibling Loops

   Sibling loops could occur if a group of siblings kept choosing
   amongst themselves as successors such that a packet does not make
   forward progress.  This specification limits the RRCount. number of times that
   sibling forwarding may be used at a given rank to prevent sibling
   loops.

5.2.  Conceptual Data Structures  Rank Properties

   The RPL implementation MUST maintain the following conceptual data
   structures in support rank of DAG discovery:

   o  A set a node is a scalar representation of candidate neighbors

   o  For each DAG:

      *  A set the location of DAG parents and siblings

5.2.1.  Candidate Neighbors Data Structure that
   node within a DODAG iteration.  The set of candidate neighbors rank is used to be populated by neighbors that
   are discovered by the neighbor discovery mechanism avoid and further
   qualified as statistically stable as per the mechanisms discussed in
   [I-D.ietf-roll-routing-metrics].  The candidate neighbors, detect
   loops, and
   related metrics, should as such must demonstrate stability/reliability beyond a certain threshold, and it is recommended that a local confidence
   value be maintained with respect to the neighbor in order to track
   this.  Implementations MAY choose to bound the maximum size properties.  The exact
   calculation of the
   candidate neighbor set, in which case a local confidence value will
   assist in ordering neighbors rank is left to determine which ones should remain in the candidate neighbor set Objective Function, and which should be evicted.

   If Neighbor Unreachability Detection (NUD) determines that a
   candidate neighbor may
   depend on parents, link metrics, and the node configuration and
   policies.

   The rank is no longer reachable, then it shall not a cost metric, although its value can be removed derived from the candidate neighbor set.  In the case that the candidate
   neighbor
   and influenced by metrics.  The rank has associated states in the DAG parent properties of its own that
   are not necessarily that of all metrics:

   Type:   Rank is an abstract scalar.  Some metrics are boolean (e.g.
           grounded), others are statistical and better expressed as a
           tuple like an expected value and a variance.  Some OCPs use
           not one but a set or active DA
   entries, then the removal of the candidate neighbor shall be
   coordinated with tearing down these states.  All provisioned routes
   associated with the candidate neighbor should be removed.

5.2.2.  Directed Acyclic Graphs (DAGs) Data Structure

   At metrics bound by a given point piece of time, a DAG Iteration logic.

   Function:  Rank is uniquely identified by
   the tuple (DagID, InstanceID, DAGSequenceNumber) where a change in
   the sequence denotes the iteration expression of a given DAG over time.  When relative position within a
   single device is capable
           DODAG iteration with regard to root multiple DAGs in support of an
   application need for multiple optimization objectives it MUST produce neighbors and, not necessarily
           a different and unique (DagID, InstanceID) pair for each good indication or a proper expression of the
   multiple DAGs.

   For each DAG that a node is, distance or may become, a member of,
           cost to the
   implementation MUST root.

   Stability:  The stability of the rank determines that of the routing
           topology.  Some dampening or filtering might be applied to
           keep a DAG table with the following entries:

   o  InstanceID

   o  DAGID

   o  DAGSequenceNumber

   o  DAG Metric Container, including DAGObjectiveCodePoint

   o topology stable and the rank does not necessarily
           change as fast as some physical metrics would.  A set of Destination Prefixes offered inwards along new
           iteration is a good opportunity to reconcile the DAG

   o
           discrepancies that might form over time between the metrics
           and the ranks.

   Granularity:  Rank is coarse grained.  A set fine granularity would
           prevent the selection of DAG parents siblings.

   Properties:  Rank is strictly monotonic and siblings

   o can be used to validate a
           progression from or towards the root.  A timer metric like
           bandwidth or jitter does not necessarily exhibit such
           property.

   Abstract:  Rank does not have a physical unit, but rather a range of
           increment per hop that varies from 1 (best) to govern 16 (worst),
           where the sending assignment of DIO messages for each value is to be determined by the
           implementation.

   The rank value feeds back into the DAG

   When parent selection according to
   the RPL loop-avoidance strategy.  Once a DAG is discovered for which no DAG data structure is
   instantiated, parent has been added, and a
   rank value for the node wants to join, then within the DAG data structure
   is instantiated.

   When DODAG has been advertised, the
   nodes further options with regard to DAG parent set is depleted (i.e. the last DAG is removed),
   then the DAG data structure SHOULD be suppressed after selection and
   movement within the expiration DODAG are restricted in favor of loop avoidance.

   The computation of an implementation-specific local timer.  An implementation SHOULD
   delay before deallocating the DAG data structure rank MUST be done in order such a way so as to observe
   that
   maintain the DAGSequenceNumber has incremented should any new DAG parents
   appear following properties for any nodes M and N that are
   neighbors in the DAG.

5.2.2.1.  DAG Parents/Siblings Structure

   When the DAG is self-rooted, the set of DAG parents/siblings LLN:

   DAGRank(M) is
   empty. less than DAGRank(N):  In all other cases, for each node this case, M is probably
           located in the set, the implementation MUST
   keep a record of:

   o a reference to the neighboring device which is more preferred position than N in the DAG parent or
      sibling

   o  a record of most recent information taken from DODAG with
           respect to the DAG Information
      Object last processed from metrics and optimizations defined by the DAG parent

   DAG parents
           objective code point.  In any fashion, Node M may safely be ordered, according to the OF.  When ordering a
           DAG
   parents, parent for Node N without risk of creating a loop.
           Further, for a node N, all parents in consultation with the OF, the most preferred DAG parent
   may be identified.  All current DAG parents set must have a
           be of rank less than self.  All current DAG siblings must have a self's DAGRank(N).  In other words, the
           rank equal to self.

   When nodes presented by a node N MUST be greater (deeper) than that
           presented by any of its parents.

   DAGRank(M) equals DAGRank(N):  In this case M and N are added to or removed from the DAG set the most
   preferred DAG parent may have changed.  The role located
           positions of all relatively the nodes in same optimality within the list should be reevaluated. DODAG.
           In particular, any nodes having some cases, Node M may be used as a
   rank greater than self after such successor by Node N,
           but with related chance of creating a change loop that must be evicted from
           detected and broken by some other means.

   DAGRank(M) is greater than DAGRank(N):  In this case, then node M is
           located in a less preferred position than N in the
   set.

   An implementation DODAG with
           respect to the metrics and optimizations defined by the
           objective code point.  Further, Node (M) may choose in fact be in
           Node (N)'s sub-DAG.  There is a higher risk to keep these records Node (N)
           selecting Node (M) as a DAG parent, as such a selection may
           create a loop.

   As an extension of example, the Default Router List (DRL).

5.3. DAG Rank

   Based on rank could be computed in such a way so as to
   closely track ETX when the selection of DAG Parents, objective function is to minimize ETX, or
   latency when the objective function is to minimize latency, or in a
   more complicated way as appropriate to the metrics conveyed by objective code point being
   used within the
   most preferred DAG parent, DODAG.

6.  RPL Protocol Specification

6.1.  RPL Messages

6.1.1.  ICMPv6 RPL Control Message

   This document defines the nodes own metrics and configuration,
   and RPL Control Message, a related function defined by new ICMPv6 message.
   The RPL Control Message has the OF, following general format, in
   accordance with [RFC4443]:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |     Code      |          Checksum             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                         Message Body                          +
       |                                                               |

                       Figure 3: RPL Control Message

   The RPL Control message is an ICMPv6 information message with a node
   requested Type of 155.

   The Code will be able used to
   compute a value for its rank identify RPL Control Messages as a consequence of selecting a most
   preferred follows:

   o  0x01: DAG parent. Information Solicitation (Section 6.1.2)

   o  0x02: DAG Information Object (Section 6.1.3)

   o  0x04: Destination Advertisement Object (Section 6.1.4)

6.1.2.  DAG Information Solicitation (DIS)

   The rank value feeds back into the DAG parent selection according Information Solicitation (DIS) message may be used to
   a loop-avoidance strategy.  Once solicit
   a DAG parent has been added, and Information Object from a
   rank value for the node within the DAG has been computed, the nodes
   further options with regard RPL node.  Its use is analogous to DAG parent selection and movement
   within the DAG are restricted in favor
   that of loop avoidance.

   It is important a Router Solicitation; a node may use DIS to note that the probe its
   neighborhood for nearby DAGs.  The DAG Rank is not itself Information Solicitation
   carries no additional message body.

6.1.3.  DAG Information Object (DIO)

   The DAG Information Object carries a metric,
   although its value is derived from and influenced by the use number of metrics and other
   information that allows a node to discover a DAG Instance, select its
   DAG parents parents, and take up a position in the DAG.  The
   only aim of the rank is to inform identify its siblings while employing loop avoidance and detection.
   strategies.

6.1.3.1.  DIO Base

   The computation of the DAG Rank MUST be done in such DIO Base is a way so as to
   maintain the following properties for any nodes M container option, which is always present, and N that are
   neighbors in
   might contain a number of suboptions.  The base option regroups the LLN:

   DAGRank(M) is less than DAGRank(N):  In this case, M
   minimum information set that is probably
           located in a more preferred position than N mandatory in the all cases.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |G|D|A|0|0| Prf |   Sequence    |  InstanceID   |    DAGRank    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                            DAGID                              |
       +                                                               +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   sub-option(s)...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+

                            Figure 4: DIO Base

   Control Field:  The DAG with
           respect to the metrics and optimizations defined by Control Field is currently allocated as
         follows:

         Grounded (G):  The Grounded (G) flag is set when the
           objective code point.  In any fashion, Node M may safely be a
           DAG parent for Node N without risk of creating DODAG root
               is a loop.
           Further, Goal for a node N, all parents in the DAG parent OF.

         Destination Advertisement Trigger (D):  The Destination
               Advertisement Trigger (D) flag is set must
           be of rank less than self's DAGRank(N).  In other words, when the
           rank presented by a DODAG root
               or another node N MUST be greater (deeper) than that
           presented by any of its parents.

   DAGRank(M) equals DAGRank(N):  In this case M and N are located
           positions in the successor chain decides to trigger
               the sending of relatively destination advertisements in order to
               update routing state for the same optimality within down direction along the DAG.
           In some cases, Node M may be used
               DODAG, as a successor by Node N,
           but with related chance of creating a loop further detailed in Section 6.8.  Note that must be
           detected the
               use and broken by some other means.

   DAGRank(M) is greater than DAGRank(N):  In semantics of this case, then node M flag are still under
               investigation.

         Destination Advertisement Supported (A):  The Destination
               Supported (A) bit is
           located in a less preferred position than N in set when the DAG with
           respect DODAG root is capable
               to support the metrics collection of destination advertisement
               related routing state and optimizations defined enables the operation of the
               destination advertisement mechanism within the DODAG.

         DAGPreference (Prf):  3-bit unsigned integer set by the
           objective code point.  Further, Node (M) may in fact be in
           Node (N)'s sub-DAG.  There DODAG
               root to its preference and unchanged at propagation.
               DAGPreference ranges from 0x00 (least preferred) to 0x07
               (most preferred).  The default is a higher risk to Node (N)
           selecting Node (M) as a 0 (least preferred).
               The DAG parent, as such a selection may
           create a loop.

   As preference provides an example, administrative mechanism
               to engineer the DAG Rank could be computed in such self-organization of the LLN, for example
               indicating the most preferred LBR.  If a way so as to
   closely track ETX when node has the objective function is
               option to minimize ETX, or
   latency when join a more preferred DODAG while still meeting
               other optimization objectives, then the objective function is node will
               generally seek to minimize latency, or in a join the more complicated way preferred DODAG as appropriate to
               determined by the objective code point being
   used within OF.

         Unassigned bits of the DAG.

5.4.  DAG Discovery Control Field are considered as
         reserved.  They MUST be set to zero on transmission and Maintenance

   DAG discovery locates MUST be
         ignored on receipt.

   Sequence Number:  8-bit unsigned integer set by the nearest sink (aka root), as determined DODAG root,
         incremented according to some metrics and constraints, and forms a Directed
   Acyclic Graph towards that sink, by identifying policy provisioned at the DODAG
         root, and propagated with no change down the DODAG.  Each
         increment SHOULD have a set value of DAG parents.
   During this process DAG discovery also identifies siblings, which 1 and may
   be used later cause a wrap back to provide additional path diversity towards
         zero.

   InstanceID:  8-bit field indicating the DAG topology instance associated
         with the DODAG, as provisioned at the DODAG root.

   DAGRank:  8-bit unsigned integer indicating the DAG discovery enables nodes to implement different policies
   for selecting their DAG parents rank of the node
         sending the DIO message.  The DAGRank of the DODAG root is
         ROOT_RANK.  DAGRank is further described in the DAG by using implementation
   specific policy functions.  DAG discovery specifies Section 6.3.

   DAGID:  128-bit unsigned integer which uniquely identify a DODAG.
         This value is set of rules to
   be followed by all implementations in order to ensure interoperation.
   DAG discovery also standardizes the format that is used to advertise DODAG root.  The global IPv6 address
         of the most common information that is used in order to select DODAG root can be used. the DAGID MUST be unique per DAG
   parents.

   One
         Instance within the scope of these information, the DAG rank, is used by DAG discovery to
   provide loop avoidance even if nodes implement different policies. LLN.

   The DAG Rank is computed as specified by following values MUST NOT change during the OF in use by propagation of DIO
   messages down the DAG,
   demonstrating DAG:
      Grounded (G)
      Destination Advertisement Supported (A)
      DAGPreference (Prf)
      Sequence
      InstanceID
      DAGID
   All other fields of the properties described in Section 5.3.  The rank
   should DIO message may be computed in such a way so as updated at each hop of the
   propagation.

6.1.3.1.1.  DIO Suboptions

   In addition to provide a comparable basis
   with other nodes which may not use the same metric at all.

   The DAG discovery procedures take into account a number minimum options presented in the base option,
   several suboptions are defined for the DIO message:

6.1.3.1.1.1.  Format
        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
       |  Subopt. Type |         Subopt Length         | Subopt Data
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -

                  Figure 5: DIO Suboption Generic Format

   Suboption Type:  8-bit identifier of factors,
   including:

   o  RPL rules for loop avoidance based on DAGs and ranks

   o  The Objective Function

   o  The advertised metrics

   o  Local policy functions (e.g. a bounded number the type of candidate
      neighbors).

5.4.1.  DAG Discovery Rules

   In order to organize and maintain loopless structure, suboption.  When
         processing a DIO message containing a suboption for which the DAG
   discovery implementation in
         Suboption Type value is not recognized by the nodes receiver, the
         receiver MUST obey silently ignore the unrecognized option, continue
         to process the following
   rules suboption, correctly handling any
         remaining options in the message.

   Suboption Length:  16-bit unsigned integer, representing the length
         in octets of the suboption, not including the suboption Type
         and definitions:

5.4.1.1.  DAGs

   1.  DAG discovery instantiates LLN topologies Length fields.

   Suboption Data:  A variable length field that contains data specific
         to the option.

   The following subsections specify the DIO message suboptions which
   are each optimized currently defined for specific constraints and goals.  A topology assumes use in the shape
       of a DAG, and a DAG Instance is uniquely identified by its
       instanceID.

   2.  For reasons of scalability and operations of Information Object.

   Implementations MUST silently ignore any DIO message suboptions
   options that they do not understand.

   DIO message suboptions may have alignment requirements.  Following
   the protocol, a DAG
       Instance is partitioned into a set of DAGs rooted at a
       destination, aka Destination Oriented DAGs.  A destination is
       uniquely identified by a DAGID so a DAG rooted at convention in IPv6, these options are aligned in a destination
       is uniquely identified by packet such
   that multi-octet values within the pair (InstanceID, DAGID).

   3.  A Destination Oriented DAG is periodically reconstructed Option Data field of each option
   fall on natural boundaries (i.e., fields of width n octets are placed
   at an integer multiple of n octets from the
       root, by incrementing a DAGSequenceNumber.  An Iteration start of a
       Destination Oriented DAG the header, for
   n = 1, 2, 4, or 8).

6.1.3.1.1.2.  Pad1

   The Pad1 suboption does not have any alignment requirements.  Its
   format is thus uniquely identified by as follows:

        0
        0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+
       |   Type = 0    |
       +-+-+-+-+-+-+-+-+

                              Figure 6: Pad 1

   NOTE! the tuple
       (InstanceID, DAGID, DAGSequenceNumber).  Through this document, format of the graph formed by this iterative process Pad1 option is referred a special case - it has
   neither Option Length nor Option Data fields.

   The Pad1 option is used to as the
       DAG Iteration, insert one or two octets of padding in short, the DAG.

   4.  The rank
   DIO message to enable suboptions alignment.  If more than two octets
   of padding is defined within required, the scope of a DAG Iteration PadN option, described next, should be
   used rather than multiple Pad1 options.

6.1.3.1.1.3.  PadN

   The PadN option does not have any alignment requirements.  Its format
   is as an
       abstract coordinate follows:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
       |   Type = 1    |         Subopt Length         | Subopt Data
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -

                              Figure 7: Pad N

   The PadN option is used to compare the relative position insert three or more octets of nodes and
       ensure forward progress padding in
   the DIO message to enable suboptions alignment.  For N (N > 2) octets
   of padding, the traffic.

   5.  A node MUST belong at most to one DAG Iteration per InstanceID Option Length field contains the value N-3, and the
   Option Data consists of N-3 zero-valued octets.  PadN Option data
   MUST select all its parents and siblings within that same DAG
       Iteration.

5.4.1.2.  DAG Sequence Number

   1.  The DAGSequenceNumber is incremented be ignored by the root and flooded
       through DIOs.

   2. receiver.

6.1.3.1.1.4.  DAG Metric Container

   The root floods a new DAGSequenceNumber periodically, at a rate
       that depends on the deployment.  This rate can DAG Metric Container suboption may be set to 0 if
       other methods such aligned as loop detection are considered sufficient necessary to
       solve the routing issues in that deployment.

   3.  The root MAY also flood a new DAGSequenceNumber on-demand.
   support its contents.  Its format is as follows:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
       |   Type = 2    |       Container Length        | DAG Metric Data
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -

                      Figure 8: DAG Metric Container

   The
       details of the mechanism DAG Metric Container is used to signal report aggregated path metrics
   along the root to do so are to be
       specified in DODAG.  The DAG Metric Container may contain a future revision of this document.

   4.  A parent that advertises the new DAGSequenceNumber can not
       possibly belong to the sub-DAG number of a node that still advertises an
       older DAGSequenceNumber.  The node MAY thus attach to that parent
       regardless
   discrete node, link, and aggregate path metrics as chosen by the
   implementer.  The Container Length field contains the length in
   octets of the relative rank, DAG Metric Data.  The order, content, and this situation coding of the
   DAG Metric Container data is equivalent
       to jumping onto a different Destination Oriented DAG.

   5.  Thus, as a new DAGSequenceNumber spreads, a new specified in

   [I-D.ietf-roll-routing-metrics].

   The DAG Iteration
       forms that supersedes Metric Container MUST include the previous one.  During a
       DAGSequenceNumber transition, a node MAY decide to forward
       packets via 'future parents' that belong to value for the same Destination
       Oriented DAG (same InstanceID Objective
   Code Point.

   The processing and DagID), but a more recent
       (incremented) DAGSequenceNumber.

5.4.1.3. propagation of the DAG Root

   1.  A node that Metric Container is
   governed by implementation specific policy functions.

6.1.3.1.1.5.  Destination Prefix

   The Destination Prefix suboption does not have any DAG parent MAY become the root of
       its own floating DAG.  It's rank alignment
   requirements.  Its format is ROOT_RANK.

   2.  A (non-LLN) router as follows:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 3    |            Length             |Resvd|Prf|Resvd|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Prefix Lifetime                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Prefix Length |                                               |
       +-+-+-+-+-+-+-+-+                                               |
       |             Destination Prefix (Variable Length)              |
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 9: DAG Destination Prefix

   The Destination Prefix suboption is considered connected to a grounded
       infrastructure at rank BASE_RANK.  A LLN used when the DODAG root, or
   another node located upwards along the DODAG on the path to the DODAG
   root, needs to indicate that it offers connectivity to destination
   prefixes other than the default.  This may be useful in cases where
   more than one LBR is attached operating within the LLN and offering
   connectivity to different administrative domains, e.g. a home network
   and a utility network.  In such an infrastructure router is cases, upon observing the DAG root of its own grounded
       DAG.  It's rank is ROOT_RANK.

   3.  In Destination
   Prefixes offered by a deployment that uses particular DODAG, a backbone link node MAY decide to federate a number join
   multiple DODAGs in support of
       LLN roots, it a particular application.

   The Length is possible to run RPL over coded as the backbone length of the suboption in octets,
   excluding the Type and use
       one router Length fields.

   Prf is the Route Preference as a backbone root. in [RFC4191].  The backbone root exposes reserved fields
   MUST be set to zero on transmission and MUST be ignored on receipt.

   The Prefix Lifetime is a rank 32-bit unsigned integer representing the
   length of BASE_RANK over time in seconds (relative to the backbone.  All time the LLN roots that are
       parented to packet is sent)
   that backbone root, including the backbone root if it
       also serves as LLN root, expose a rank of ROOT_RANK over Destination Prefix is valid for route determination.  The
   lifetime is initially set by the LLN node that owns the prefix and act as multiple roots
   denotes the valid lifetime for a same DAG, coordinated that prefix (similar to
   AdvValidLifetime [RFC4861]).  The value might be reduced by the
       backbone root.

   4.
   originator and/or en-route nodes that will not provide connectivity
   for the whole valid lifetime.  A value of all one bits (0xFFFFFFFF)
   represents infinity.  A value of all zero bits (0x00000000) indicates
   a loss of reachability.

   The DAG root exposes Prefix Length is an 8-bit unsigned integer that indicates the DAG
   number of leading bits in the DIO message and LLN nodes
       propagate destination prefix.

   The Destination Prefix contains Prefix Length significant bits of the DIO message outwards along
   destination prefix.  The remaining bits of the DAG.

5.4.1.4.  Moving Inside a DAG

   1.  A node moves when it changes its parent selection within Destination Prefix, as
   required to complete the same
       DAG Iteration.  When a node moves (within its DAG) in a fashion
       that cause its rank trailing octet, are set to decrease, 0.

   In the node MUST abandon all
       parents and siblings with event that a rank larger DIO message may need to specify connectivity to
   more than self, and MAY adopt
       as siblings nodes with one destination, the same rank.

   2.  A node MAY move at any time, with no delay, within its Destination Prefix suboption may be
   repeated.

6.1.3.1.1.6.  DAG when
       the move Configuration

   The DAG Configuration suboption does not cause the node have any alignment
   requirements.  Its format is as follows:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 4    |            Length             | DIOIntDoubl.  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  DIOIntMin.   |   DIORedun.   |  MaxRankInc   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 10: DAG Configuration

   The DAG Configuration suboption is used to increase its own distribute configuration
   information for DAG rank, as
       per Operation through the rank calculation indicated by DODAG.  The information
   communicated in this suboption is generally static and unchanging
   within the OF.

   3.  A node DODAG, therefore it is not necessary to include in every
   DIO.  This suboption MAY be included occasionally by the DODAG Root,
   and MUST NOT move outwards along be included in response to a unicast request, e.g. a DAG that it
   Information Solicitation (DIS) message.

   The Length is attached to,
       causing coded as 5.

   DIOIntervalDoublings is an 8-bit unsigned integer, configured on the DAG rank
   DODAG root and used to increase.  If a node cannot stay within configure the DAG without a rank increase, then it MUST poison its routes
       as described in Section 5.4.1.6.

   4.  When trickle timer governing when DIO messages are received from other routers located at
       lesser rank in
   message should be sent within the same DAG, those routers are eligible for
       consideration as DAG parents.  DIO messages received from other
       routers located at DODAG.  DIOIntervalDoublings is the same rank in
   number of times that the same DAG may DIOIntervalMin is allowed to be
       considered as coming from siblings.  DIO messages that are
       received from other routers located at greater rank within doubled
   during the
       same DAG might cause greedy behaviors and loops; such a DIO trickle timer operation.

   DIOIntervalMin is
       ignored unless:

       1.  The DIO comes from an existing parent or sibling; in which
           case that parent must 8-bit unsigned integer, configured on the DODAG
   root and used to configure the trickle timer governing when DIO
   message should be removed.

       2. sent within the DODAG.  The minimum configured
   interval for the DIO comes from a node that has better OF ratings than any
           parent known at this point; in that case, this potential
           parent MAY be remembered trickle timer in order units of ms is
   2^DIOIntervalMin.  For example, a DIOIntervalMin value of 16ms is
   expressed as 4.

   DIORedundancyConstant is an 8-bit unsigned integer used to configure
   suppression of DIO transmissions.  DIORedundancyConstant is the
   minimum number of relevant incoming DIOs required to jump at suppress a better
           position when DIO
   transmission.  If the next sequence value is flooded.

5.4.1.5.  Jumping Onto Another DAG

   1.  A node jumps when it performs a new parent selection whereby its
       DAG Iteration changes within 0xFF then the same DAG Instance.  When a node
       jumps onto a new DAG Iteration, it MUST abandon all parents and
       siblings from its previous position.

   2.  A node MAY jump from its current DAG onto any other DAG that
       provides service for suppression mechanism is
   disabled.

   MaxRankInc, 8-bit unsigned integer, is the same InstanceID if it DAGMaxRankIncrease.  This
   is preferred by the OF, for example allowable increase in rank in support of local repair.  If
   DAGMaxRankIncrease is 0 then this mechanism is disabled.

6.1.4.  Destination Advertisement Object (DAO)

   The Destination Advertisement Object (DAO) is used to propagate
   destination information upwards along the DODAG.  The RPL use of the
   DAO allows the nodes in the DODAG to provision routing state for reasons such as connectivity, configured
       preference, free medium time, size, security, bandwidth, DAG
       rank, or whatever metrics
   nodes contained in the LLN uses.  This is allowed
       regardless sub-DAG in support of traffic flowing down
   along the rank that DODAG.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         DAO Sequence          |  InstanceID   |   DAO Rank    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          DAO Lifetime                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Route Tag                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Prefix Length |    RRCount    |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
       |                   Prefix (Variable Length)                    |
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Reverse Route Stack (Variable Length)             |
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 11: The Destination Advertisement Object (DAO)

   DAO Sequence:  Incremented by the node reaches in that owns the prefix for each
         new DAG.

   3.  A node DAO message for that jumps should attempt to transmit all the packets
       received as part of the previous DAG along the previous DAG.  In
       other words, it should switch the parent set only after the
       outstanding packet queue of packets received prior to announcing prefix.

   InstanceID:  8-bit field indicating the jump is exhausted.

   4.  Jumping back onto a previous DAG is equivalent to moving inside
       that DAG and obeys topology instance associated
         with the same rules.  To satisfy this, a node
       detaching from a DAG SHOULD remember its DAG DODAG, as identified learned from the DIO.

   DAO Rank:  Set by the
       tuple (InstanceID, DagID, DAGSequenceNumber) as well as its rank
       within that DAG for long as that DAG exists.

5.4.1.6.  Poisoning a Broken Path

   1.  A node SHOULD poison its inwards routes when it looses all of its
       current feasible parents, i.e. that owns the set of DAG parents becomes
       depleted, and it can not jump onto an alternate DAG.

   2.  In order to poison its inwards routes, a node MAY stay at its
       position within its DAG (that is maintain its InstanceID, DagID,
       DAGSequenceNumber and Rank) but it SHOULD immediately advertise a
       rank of INFINITE_RANK in a DIO so as to force all its children to
       remove it from their parent list prefix and try an alternate path.  The
       node SHOULD then wait for a new DAG Iteration (DAGSequenceNumber
       increment) before resuming its operation in first issues the same Destination
       Oriented DAG.

   3.  Alternatively, a node MAY detach from its DAG.  A node that
       detaches becomes root of its own floating DAG and MUST
       immediately advertise
         DAO message to its new situation rank.

   DAO Lifetime:  32-bit unsigned integer.  The length of time in a DIO.

   4.  Either way,
         seconds (relative to the route poisoning will recursively be flooded
       throughout time the impacted sub-DAG as children lose their last
       parent in packet is sent) that the original DAG.

   5.  The loss
         prefix is valid for route determination.  A value of all one
         bits (0xFFFFFFFF) represents infinity.  A value of all zero
         bits (0x00000000) indicates a DIO message loss of reachability.

   Route Tag:  32-bit unsigned integer.  The Route Tag may interrupt the flooding.  This can be compensated by cheer repetition through the trickle algorithm.
       If used to
         give a priority to prefixes that also fails, packet loops will should be prevented by the
       detection mechanism described stored.  This may be
         useful in Section 5.11.

5.4.1.7.  Following a Parent

   1.  If a node that receives cases where intermediate nodes are capable of storing
         a DIO from one limited amount of routing state.  The further specification
         of this field and its DAG parents
       indicating that the parent has left the DAG, it may either follow
       that parent or stay in its current DAG through an alternate DAG
       parent if that use is possible.

   2.  If a DAG parent increases its rank such that the node rank would
       have to change, and if under investigation.

   Prefix Length:  8-bit unsigned integer.  Number of valid leading bits
         in the node does not wish IPv6 Prefix.

   RRCount:  8-bit unsigned integer.  This counter is used to follow (e.g. it
       has alternate options), then count the DAG parent SHOULD be evicted
       from
         number of entries in the DAG parent set.  If Reverse Route Stack.  A value of `0'
         indicates that no Reverse Route Stack is present.

   Prefix:  Variable-length field containing an IPv6 address or a prefix
         of an IPv6 address.  The Prefix Length field contains the DAG parent is
         number of valid leading bits in the last prefix.  The bits in the
       DAG parent set, then
         prefix after the node SHOULD chose prefix length (if any) are reserved and MUST
         be set to follow it.

5.4.1.8.  DAG Inconsistency

   1.  When a node detects or causes zero on transmission and MUST be ignored on receipt.

   Reverse Route Stack:  Variable-length field containing a DAG inconsistency, as described
       in Section 5.4.4.2, then the sequence of
         RRCount (possibly compressed) IPv6 addresses.  A node SHOULD send an unsolicited DIO
       message to its one-hop neighbors.  The DIO is updated that adds
         on to
       propagate the new DAG information.  Such an event MUST also cause Reverse Route Stack will append to the trickle timer governing list and
         increment the periodic sending of DIO messages RRCount.

6.2.  Protocol Elements

6.2.1.  Topological Elements

   RPL uses four identifiers to be reset.

5.4.2.  Reception track and Processing of DIO messages

   When an DIO message is received from a source device named SRC, control the
   receiving node must routing topology

   o  The first determine whether or not the DIO message
   should be accepted for further processing, and subsequently present
   the DIO message for further processing if eligible.

   1.  If the DIO message is malformed, then the DIO message is not
       eligible for further processing an InstanceID.  An InstanceID defines what OF a DAG
      uses and is silently discarded. may also indicate what destinations are offered.  A RPL
       implementation MAY log the reception of a malformed DIO message.

   2.  If SRC is not a member
      network may have multiple InstanceIDs, each of the candidate neighbor set, then the
       DIO is not eligible which defines an
      independent DAG optimized for further processing.  (Further evaluation/
       confidence of this neighbor a different OF and/or application.
      The DAG defined by an InstanceID is necessary)

   3.  If the DIO message advertises called a DAG that the node Instance.

   o  The second is already a
       member of, then:

       *  If the rank DAGID.  The scope of SRC as reported in the DIO message a DAGID is lesser
          than that of the node within the DAG, then the DIO message
          MUST be considered for further processing.

       *  If the rank a DAG Instance.  A
      combination of SRC as reported in the DIO message InstanceID and DAGID defines a DODAG.  A DAG
      Instance may have multiple DODAGs.

   o  The third value is equal to
          that a DAG Sequence Number.  The scope of the node within the DAG, then SRC a DAG
      Sequence Number is marked as a
          sibling and the DIO message DODAG.  A DODAG is not eligible for further
          processing.

       *  If sometimes reconstructed
      from the rank of SRC as reported in root, by incrementing the DIO message is higher
          than that DAGSequenceNumber.  A
      combination of the node within the DAG, InstanceID, DAGID, and SRC is not a DAG
          parent, then the DIO message MUST NOT be considered for
          further processing

   4.  Even if not processed further, information from Sequence Number defines
      a DIO might be
       remembered for instance if SRC DODAG Iteration.

   o  The fourth value is preferable to the current
       parents per the OF selection process.

   5.  If SRC rank.  The scope of rank is a DAG parent for any other DAG that the DODAG Iteration.
      Rank establishes a partial order over a DODAG Iteration, defining
      individual node positions.

6.2.2.  Neighbors, Parents, and Siblings

   1.  A node that is
       attached to, then the DIO message MUST be considered for further
       processing (the not a DODAG root MAY maintain multiple DAG parent may have jumped).

   6.  If the DIO message advertises parents
       for a single DAG that offers Instance.

   2.  The set of DAG parents MUST be a better (new or
       alternate) solution conceptual subset of the set of
       candidate neighbors.  (This does not dictate implementation,
       e.g., to use a certain data structure).

   3.  If Neighbor Unreachability Detection (NUD), or an optimization objective desired by the
       node, equivalent
       mechanism, determines that a neighbor is no longer reachable,
       then a RPL node MUST NOT consider this node in the DIO message neighbor set
       when calculating and advertising routes until the node determines
       it is reachable again.

   4.  Routes via that unreachable neighbor MUST be considered for further
       processing.

5.4.2.1.  Overview of DIO Message Processing

      If eliminated from the received DIO message is for a new/alternate DAG:

         If
       routing table, and the node SHOULD poison using no-DAO all DAO
       routes that it has sent advertised via DAO and that it can reach only
       via that neighbor.

   A node's neighbor set is an DIO message within unconstrained subset of the risk window as
         described nodes that it
   can reach with a link-local multicast.

   The OF guides in Section 5.8 then the selection and maintains a collision has occurred; do not
         process number of neighbors to
   interact with, which neighbors being qualified as statistically
   stable and presenting adequate properties as per the DIO message any further.

         If the SRC node is also a DAG parent OF logic,
   for another DAG that instance following mechanisms discussed in
   [I-D.ietf-roll-routing-metrics].  Those neighbors are referred to as
   candidate neighbors.

   Candidate neighbors may take the
         node is a member of, role of Parent or Siblings, in part
   as determined by rank.

   For the purpose of inheriting metrics and if computing rank, the OF
   might select one preferred parent.  In that case, the new/alternate DAG rank of this
   node is the same
         InstanceID computed as the other DAG, then rank of the DAG preferred parent is known to
         have jumped.

            Remove SRC as plus a DAG parent from rank
   increment as determined by the other DAG

            If OF.

6.2.3.  DODAG Information

   For each DODAG that a node is, or may become, a member of, the other DAG is now empty
   implementation should conceptually keep track of candidate parents, then
            prepare to directly follow SRC into the new DAG by adding it
            as a DAG parent following
   information for each DODAG.  The data structures described in this
   section are intended to illustrate a possible implementation to aid
   in the new DAG, else ignore description of the DIO message
            (do protocol, but are not follow the parent).

         Instantiate a data structure for the new/alternate intended to be
   normative.

   o  InstanceID

   o  DAGID

   o  DAGSequenceNumber

   o  DAG if
         necessary

         If Metric Container, including DAGObjectiveCodePoint
   o  A set of Destination Prefixes offered upwards along the new/alternate DODAG

   o  A set of DAG offers a better solution parents

   o  A set of DAG siblings

   o  A timer to govern the
         optimization objectives, then jump: copy the sending of DIO information
         place the neighbor into messages

   When the DAG parent set.

      If the DIO message set is for depleted on a known/existing DAG:

         Process the DIO message as per node that is not a root,
   (i.e. the rules in Section 5.4

   As DIO messages are received from candidate neighbors, last parent is removed), then the neighbors
   may DAG information should
   not be promoted suppressed until after the expiration of an implementation-
   specific local timer in order to DAG observe that the DAGSequenceNumber
   has incremented should any new parents by following appear for the rules DODAG.

6.2.3.1.  DAG Parents/Siblings Structure

   When the DODAG is self-rooted, the set of DAG
   discovery as described in Section 5.4.  When a parents is empty.

   For each node places in a neighbor
   into the DAG Parent parent/sibling set, the node becomes attached implementation should
   conceptually keep track of:

   o  a reference to the DAG through neighboring device which is the new parent node.

   In DAG parent/
      sibling

   o  a record of most recent information taken from the DAG discovery implementation, Information
      Object last processed in the most preferred case where the neighboring device is
      a DAG parent should

   DAG parents may be used ordered, according to restrict which other nodes may become the OF.  When ordering DAG parents.  Some
   nodes
   parents, in consultation with the OF, the most preferred DAG parent set
   may be of identified.  All current DAG parents must have a rank less
   than or self.  All current DAG siblings must have a rank equal to self.

   When nodes are added to or removed from the DAG parent/sibling sets
   the most preferred DAG parent.  (This case parent may occur, for example, if
   an energy constrained device is at a lesser rank but have changed.  The role of all the
   nodes in the list should be
   avoided as per an optimization objective, resulting in a more
   preferred parent at reevaluated.  In particular, any nodes
   having a rank greater rank).

5.4.3.  DIO Transmission

   Each node maintains than self after such a timer that governs when change must be evicted
   from the set.

6.3.  DAG Discovery and Maintenance

   DAG discovery allows a node to multicast DIO
   messages.  This timer is implemented as join a trickle timer operating
   over DODAG rooted at a variable interval.  Trickle timers DODAG root by
   discovering neighbors that are further detailed in
   Section 5.4.4.  The governing parameters for members of the timer should DODAG, and identifying
   a set of parents.  DAG discovery also identifies siblings, which may
   be
   configured consistently across used later to provide additional path diversity towards the DAG, DODAG
   root.

   DODAG discovery may avoid loops by constraining how and when nodes
   can increase their rank, and are provided by statistically poisoning the nodes
   that present the highest risk.

   DAG
   root discovery enables nodes to implement different policies for
   selecting their DAG parents in the DIO message.  In addition DODAG by using implementation
   specific policy functions.  DAG discovery specifies a set of rules to periodic DIO messages, each
   node may respond
   be followed by all implementations to a DIS message with a DIO message.

   o  When a node detects an inconsistency, it enable interoperation.

6.3.1.  DAG Discovery Rules

   The following rules define the RPL DAG Discovery procedures:

6.3.1.1.  DODAG Iteration

   1.   An InstanceID SHOULD reset be administratively provisioned on a DODAG
        root that is significant RPL objective.  The InstanceID MUST be
        unique to that purpose across the interval scope of the trickle timer to a minimum value, causing DIO messages to LLN.

   2.   A DAGID MUST be emitted more frequently as part unique within the scope of a strategy to quickly
      correct the inconsistency.  Such inconsistencies may be, for
      example, an update to a key parameter (e.g. sequence number) in InstanceID.  It
        MAY be derived from the DIO message or a loop detected when a node located inwards
      along IPv6 address of the DODAG root.

   3.   A node MAY belong to multiple DAG forwards traffic outwards.  Inconsistencies instances.  The related
        details of operation are
      further detailed in Section 5.4.4.2.

   o outside the scope of this
        specification.

   4.   DODAG roots MAY increment the DAGSequenceNumber that they
        advertise.

   5.   When a node enters DODAG root increments its DAGSequenceNumber, it MUST
        follow the conventions of Serial Number Arithmetic as described
        in [RFC1982].

   6.   The tuple (InstanceID, DAGID, DAGSequenceNumber) uniquely
        defines a mode DODAG Iteration.  All of consistent operation a node's parents within a DAG,
      i.e.
        DODAG MUST belong to the same DODAG iteration, as conveyed by
        the last heard DIO messages from its DAG parents are consistent and no
      other inconsistencies are detected, each parent.

   7.   A node MUST NOT propagate DIOs for a DODAG Iteration unless it may begin to open up
        is the
      interval DODAG root of the trickle timer towards DODAG iteration or has selected DODAG
        parents in that DODAG iteration.

   8.   A node acting as a maximum value, causing DIO
      messages leaf SHOULD NOT propagate DIOs for a DODAG
        Iteration.

   9.   A node MUST belong at most to be emitted less frequently, thus reducing network
      maintenance overhead and saving energy consumption.

   o  When one DODAG Iteration per
        InstanceID.

   10.  Within a given DODAG, a node that is initialized, it MAY be configured to remain silent
      and a not multicast any DIO messages until a root MUST NOT
        advertise a DAGSequenceNumber higher than the highest
        DAGSequenceNumber it has encountered and
      joined heard.

   Within a DAG (perhaps initially probing for particular implementation, a nearby DAG with an
      DIS message).  Alternately, it may choose to DODAG root its own floating
      DAG and begin multicasting DIO messages using a default trickle
      configuration.  The second case may be advantageous if it is
      desired for independent nodes to begin aggregating into scattered
      floating DAGs in increment the absence of
   DAGSequenceNumber periodically, at a grounded node, for example in
      support of LLN installation and commissioning.

   Note rate that if multiple DAG roots are participating in the same DAG,
   i.e. offering DIO messages with depends on the same DAGID, then they must
   coordinate with each other to ensure that their DIO messages are
   consistent when they emit DIO messages.
   deployment.  In particular the Sequence
   number must other implementations loop detection may be identical from each DAG root, regardless of which of
   the multiple DAG roots issues the DIO message, and changes
   considered sufficient to solve the
   Sequence number should be issued at routing issues, and the same time.  The specific
   mechanism of this coordination, e.g. along a non-LLN network between
   DAG roots, DODAG root
   may increment the DAGSequenceNumber only upon administrative
   intervention.  Another possibility is beyond that nodes within the scope of this specification.

5.4.4.  Trickle Timer for DIO Transmission

   RPL treats LLN have
   some means to signal the construction of a DAG as DODAG root in order to request an on-demand
   increment when routing issues are detected.

   As the DAGSequenceNumber is incremented, a consistency problem, and
   uses new DODAG Iteration
   spreads outward from the DODAG root.  Thus a trickle timer [Levis08] parent that advertises
   the new DAGSequenceNumber can not possibly belong to control the rate sub-DAG of control
   broadcasts.

   For each DAG that a
   node is part of, the that still advertises an older DAGSequenceNumber.  A node must maintain may
   safely add such a single
   trickle timer.  The required state contains the following conceptual
   items:

   I:    The current length parent, without risk of the communication interval

   T:    A timer with forming a duration set loop, without
   regard to a random value its relative rank in the range
         [I/2, I]

   C:    Redundancy Counter

   I_min:  The smallest communication interval in milliseconds. prior DODAG Iteration.  This
         value is learned from the DIO message as (2^DIOIntervalMin)ms.
         The default value is DEFAULT_DIO_INTERVAL_MIN.

   I_doublings:  The number of times I_min should be doubled before
         maintaining
   equivalent to jumping to a constant rate, i.e.  I_max = I_min *
         2^I_doublings.  This value is learned from the DIO message different DODAG.

   As a node transitions to new DODAG Iterations as
         DIOIntervalDoublings.  The default value is
         DEFAULT_DIO_INTERVAL_DOUBLINGS.

5.4.4.1.  Resetting the Trickle Timer

   The trickle timer for a DAGID is reset by:

   1.  Setting I_min and I_doublings consequence of
   following these rules, the node will be unable to advertise the values learned from
   previous DODAG Iteration (prior DAGSequenceNumber) once it has
   committed to advertising the DIO
       message.

   2.  Setting C new DODAG Iteration.

   During a transition to zero.

   3.  Setting I a new DODAG Iteration, a node may decide to I_min.

   4.  Setting T
   forward packets via 'future parents' that belong to a random value as described above.

   5.  Restarting the trickle timer same DODAG
   (same InstanceID and DAGID), but are observed to expire after a duration T

   When node learns about advertise a DAG through more
   recent (incremented) DAGSequenceNumber.

6.3.1.2.  DODAG Roots

   1.  A DODAG root that does not have connectivity to a DIO message and makes network outside
       of the
   decision to join it, it initializes LLN MUST NOT set the state Grounded bit.

   2.  A DODAG root MUST advertise a rank of ROOT_RANK.

   3.  A node that does not have any DODAG parent MAY become the trickle timer by
   resetting the trickle timer and listening.  Each time DODAG
       root of a floating DODAG.  It MAY also set its DAGPreference such
       that it hears is less preferred.  This behavior may be a
   consistent DIO message for this DAG from desired
       alternate to poisoning.

   An LLN node that is a DAG parent, it MAY
   increment C.

   When Goal for the timer fires at time T, Objective Function is the node compares C root of
   its own grounded DODAG, at rank ROOT_RANK.

   In a deployment that uses a backbone link to federate a number of LLN
   roots, it is possible to run RPL over the redundancy
   constant, DEFAULT_DIO_REDUNDANCY_CONSTANT.  If C backbone and use one router
   as a backbone root.  The backbone root is less than the virtual root of the
   DODAG and exposes a rank of BASE_RANK over the backbone.  All the LLN
   roots that
   value, are parented to that backbone root, including the node generates backbone
   root if it also serves as LLN root, expose a new DIO message rank of ROOT_RANK over
   the LLN and multicasts it.  When are part of the communication interval I expires, same DODAG, coordinated with the node doubles virtual
   root over the interval I
   so long as it has previously doubled it fewer than I_doubling times,
   resets C, backbone.

6.3.1.3.  Rank and chooses Movement within a new T value.

5.4.4.2.  Determination DODAG Iteration

   1.  A node MUST NOT advertise a rank less than or equal to any member
       of Inconsistency

   The trickle timer is reset whenever an inconsistency is detected its parent set within the DAG, for example:

   o  The DODAG Iteration.

   2.  A node joins MAY advertise a new DAGID

   o  The node moves rank lower than its prior advertisement
       within the DODAG Iteration.  (This corresponds to a DAGID

   o  The node receives moving
       up within the DODAG Iteration).

   3.  Let L be the lowest rank within a modified DIO message from DODAG iteration that a DAG parent

   o  A DAG parent forwards given
       node has advertised.  Within a packet intended to move inwards,
      indicating DODAG Iteration, that node MUST
       NOT advertise an inconsistency and possible loop.

   o  A metric communicated in the DIO message effective rank deeper than L +
       DAGMaxRankIncrease.  INFINITE_RANK is determined an exception to be
      inconsistent, as according this rule:
       a node MAY advertise an INFINITE_RANK at any time.  (This
       corresponds to a implementation specific path
      metric selection engine.

   o  The limited rank increase for the purpose of local
       repair within the DODAG Iteration.)

   4.  A node MAY, at any time, choose to join a different DODAG within
       a DAG parent Instance.  Such a join has changed.

5.5.  DAG Sequence Number Increment

   The DAG root makes no rank restrictions, unless
       that different DODAG is a DODAG Iteration that the sole determination node has been
       a prior member of, in which case the rule of when to revise the
   DAGSequenceNumber by incrementing previous bullet
       (3) must be observed.  Until a node transmits a DIO indicating
       its new DODAG membership, it upwards.  When MUST forward packets along the
       previous DODAG.

   5.  A node MAY, at any time after hearing the next DAGSequenceNumber is increased an inconsistency results, causing DIO
   messages
       Iteration advertised from suitable parents, choose to be sent back outwards along the DAG migrate up
       to convey the change.
   The degree to which this mechanism is relied on may be determined by next DODAG Iteration within the implementation- on one hand it may serve as DODAG.

   Conceptually, an implementation is maintaining a periodic heartbeat,
   refreshing parent set within
   the DAG states, and on DODAG Iteration.  Movement entails changes to the other hand it may result in parent set.
   Moving up does not present the risk to create a
   constant steady-state control cost overhead which loop but moving down
   might, so that operation is not desirable.

   Some implementations may provide an administrative interface, such as subject to additional constraints.

   When a command line, at node migrates into the DAG root whereby next DODAG Iteration, the DAGSequenceNumber may parent and
   sibling sets need to be
   caused rebuilt for the new iteration.  An
   implementation could defer to increment in response migrate until for some reasonable time
   to see if some policy outside of other neighbors with potentially better metrics but
   higher rank announce themselves.  Similarly, when a node jumps into a
   new DODAG it needs to construct new parent/sibling sets for the scope
   of RPL.

   Other implementations may make use of new
   DODAG.

   When a periodic timer node moves to
   automatically increment improve its position, it must conceptually
   abandon all parents and siblings with a rank larger than itself.  As
   a consequence of the DAGSequenceNumber, resulting in movement it may also add new siblings.  Such a
   periodic DAG iteration
   movement may occur at a rate appropriate any time to decrease the application rank, as per the
   calculation indicated by the OF.  Maintenance of the parent and
   implementation.  Other automated mechanisms to determine
   DAGSequenceNumber increments are also possible
   sibling sets occurs as appropriate to a
   deployment.

5.6.  DAG Selection

   The DAG selection the rank of candidate neighbors is implementation and algorithm dependent.  Nodes
   SHOULD prefer to join DAGs for InstanceIDs advertising OCPs and
   destinations compatible with their implementation specific
   objectives.  In order to limit erratic movements, and all metrics
   being equal, nodes SHOULD keep observed as
   reported in their previous selection.  Also, nodes
   SHOULD provide DIOs.

   If a means node needs to filter out move down a candidate parent whose
   availability DODAG that it is detected as fluctuating, at least when more stable
   choices are available.

   When connection attached to, causing
   the DAG rank to a fixed network is not possible or preferable for
   security or other reasons, scattered DAGs increase, then it MAY aggregate as much poison its routes and delay
   before moving as
   possible into larger DAGs described in Section 6.3.1.4.

6.3.1.4.  Poisoning a Broken Path

   1.  A node MAY poison, in order to allow connectivity within avoid being used as an ancestor by
       the
   LLN.

   A node SHOULD verify that bidirectional connectivity nodes in its sub-DAG, by advertising an effective rank of
       INFINITE_RANK and adequate
   link quality is available with a candidate neighbor resetting the associated DIO trickle timer to
       cause the INFINITE_RANK to be announced promptly.

   2.  The node MAY advertise an effective rank of INFINITE_RANK for an
       arbitrary number of DIO timer events before it
   considers that candidate as announcing a DAG parent.

5.7.  Administrative new
       rank.

   3.  As per Section 6.3.1.3, the node MUST advertise INFINITE_RANK
       within the DODAG iteration if its revised rank

   When would exceed the
       maximum DAG is formed under a common administration, or rank increase.

   An implementation may choose to employ this poisoning mechanism when
   a node
   performs a certain role within a community, that loses all of its current parents, i.e. the set of DAG
   parents becomes depleted, and it might be beneficial can not jump onto an alternate DODAG
   An alternate mechanism is to
   associate form a range floating DODAG.

   The motivation for delaying announcement of acceptable rank with that node.  For instance, a
   node that has limited battery should be a leaf unless there is no
   other choice, and may then augment the rank computation specified by revised route through
   multiple DIO events is to (i) increase tolerance to DIO loss, (ii)
   allow time for the OF in order poisoning action to expose propagate, and (iii) to
   develop an exaggerated accurate assessment of its new rank.

5.8.  Collision

   A race condition occurs if 2 nodes send DIO messages  Such gains are
   obtained at the same time
   and then attempt expense of potentially increasing the delay before
   lower portions of the network are able to join each other.  This might happen, for example,
   between nodes which act as re-establish up routes.
   Path redundancy in the DAG root reduces the significance of their own DAGs.  In order either effect,
   since children with alternate parents should be able to
   detect utilize those
   alternates and retain rank while the situation, LLN Nodes time stamp detached parent re-establishes
   its rank.

   Although an implementation may advertise INFINITE_RANK for the sending
   purposes of DIO
   message.  Any DIO message received poisoning, it is not expected to be equivalent to setting
   the rank to INFINITE_RANK, and an implementation would likely retain
   its rank value prior to the poisoning in some form, for purpose of
   maintaining its effective position within (L + DAGMaxRankIncrease).

6.3.1.5.  Detaching

   1.  A node that does not have a short link-layer-
   dependent period introduces a risk.  It is up solution to the implementation stay connected to define the duration of the risk window.

   There is risk a DODAG
       within a given iteration MAY detach from its current DODAG
       iteration.  A node that detaches becomes root of its own floating
       DODAG and SHOULD immediately advertise its new situation in a collision when DIO
       as an alternate to poisoning.

6.3.1.6.  Following a Parent

   1.  If a node receives and processes a DIO
   within from one of its parents indicating that
       the risk window.  For example, parent has left the DODAG, it may occur that two nodes are
   associated with different DAGs and near-simultaneously send DIO
   messages, which are received and processed by both, and possibly
   result SHOULD stay in both nodes simultaneously deciding to attach its current
       DODAG through an alternate DAG parent if that is possible.  It
       MAY follow that parent.

   A DAG parent may have moved, migrated forward into the next DODAG
   Iteration, or jumped to each other.
   As a remedy, different DODAG.  A node should give some
   preference to remaining in the face of current DODAG if possible, but ought
   to follow the parent if there are no other options.

6.3.2.  DIO Message Communication

   When an DIO message is received from a potential collision, as determined by source device named SRC, the
   receiving a node must first determine whether or not the DIO within message
   should be accepted for further processing, and subsequently present
   the risk window, DIO message for further processing if eligible.

   1.  If the DIO message is not
   processed.  It malformed, then the DIO message is expected that subsequent DIOs would not cross.

5.9.  Guidelines for Objective Functions

5.9.1.  Objective Function

   An Objective Function (OF) allows
       eligible for the selection of a DAG to join, further processing and a number of peers in that DAG as parents.  The OF is used to
   compute an ordered list silently discarded.  A RPL
       implementation MAY log the reception of parents.  The OF a malformed DIO message.

   2.  If SRC is also responsible to
   compute the rank a member of the device within candidate neighbor set, then the DAG.

   The Objective Function DIO is specified in
       eligible for further processing.

6.3.2.1.  DIO Message Processing

      If the node has sent an DIO message within the risk window as
      described in Section 6.7 then a DAG
   Metric Container using an Objective Code Point (OCP), collision has occurred; do not
      process the DIO message any further.

      Process the DIO message as specified per the rules in
   [I-D.ietf-roll-routing-metrics], and indicates Section 6.3

   As DIO messages are received from candidate neighbors, the method that must neighbors
   may be used promoted to compute DAG parents by following the rules of DAG (e.g. "minimize
   discovery as described in Section 6.3.  When a node places a neighbor
   into the path cost using DAG Parent set, the
   ETX metric and avoid `Blue' links").  The Objective Code Points are
   specified in [I-D.ietf-roll-routing-metrics].  This document
   specifies an Objective Function, OF0, in support of default
   operation. node becomes attached to the DODAG
   through the new parent node.

   In the case where DAG discovery implementation, the DIO does not include an OCP
   specification most preferred parent should
   be used to restrict which other nodes may become DAG parents.  Some
   nodes in the DAG Metric Container, OF0 MAY parent set may be presumed.

   Most Objective Functions are expected of a rank less than or equal to follow
   the same abstract
   behavior:

   o  The parent selection most preferred DAG parent.  (This case may occur, for example, if
   an energy constrained device is triggered each time at a lesser rank but should be
   avoided as per an event indicates
      that optimization objective, resulting in a potential next hop information is updated.  This might
      happen upon the reception of more
   preferred parent at a greater rank).

6.3.3.  DIO message, Transmission

   Each node maintains a timer elapse, or a
      trigger indicating that governs when to multicast DIO
   messages.  This timer is a trickle timer, as detailed in
   Section 6.3.4.  The DIO Configuration Option includes the state
   configuration of a candidate neighbor has
      changed. DAG Instance's trickle timer.

   o  An OF scans all the interfaces on  When a node detects or causes an inconsistency, it MUST reset the device.  Although there may
      typically be only one interface in most application scenarios,
      there might be multiple
      interval of them and an interface might be
      configured the trickle timer to be usable or not for RPL operation.  An interface
      can also be configured with a preference or dynamically learned minimum value.

   o  When a node migrates to
      be better than another by some heuristics that might be link-layer
      dependent and are out of scope.  Finally an interface might or not
      match a required criterion for an Objective Function, for instance new DODAG Iteration it MUST reset the
      trickle timer to its minimum value

   o  When a degree of security.  As node detects an inconsistency when forwarding a result some interfaces might be
      completely excluded from packet, as
      detailed in Section 6.9, the computation, while others might be
      more or less preferred.

   o  An OF scans all node MUST reset the candidate neighbors on trickle timer to
      its minimum value.

   o  When a node receives a multicast DIS message, it MUST reset the possible interfaces
      trickle timer to check whether they can act as a router for the minimum value.

   o  When a DAG.  There might
      be multiple of them and node receives a candidate neighbor might need to pass
      some validation tests before unicast DIS message, it can be used. MUST unicast a DIO
      message in response, and include the DAG Configuration Object.  In particular, some
      link layers require experience on
      this case the activity with a router to
      enable node SHOULD NOT reset the router as a next hop. trickle timer.

   o  An OF computes self's rank by adding the step  If a node is not a member of rank a DODAG, it MUST suppress
      transmitting DIO messages.

   o  When a node is initialized, it MAY be configured to that
      candidate remain silent
      and not multicast any DIO messages until it has encountered and
      joined a DODAG (perhaps initially probing for a nearby DODAG with
      an DIS message).  Alternately, it may choose to the rank of that candidate. root its own
      floating DODAG and begin multicasting DIO messages using a default
      trickle configuration.  The step of rank second case may be advantageous if it
      is
      computed by estimating desired for independent nodes to begin aggregating into
      scattered floating DODAGs in the link as follows:

      *  The step absence of rank might vary from 1 to 16.

         +  1 indicates a unusually good link, grounded node, for instance a link
            between powered devices
      example in support of LLN installation and commissioning.

6.3.4.  Trickle Timer for DIO Transmission

   RPL treats the construction of a mostly battery operated
            environment.

         +  4 indicates a `normal'/typical link, DODAG as qualified by a consistency problem, and
   uses a trickle timer [Levis08] to control the
            implementation.

         +  16 indicates a link rate of control
   broadcasts.

   For each DODAG that can hardly be used to forward any
            packet, for instance a radio link with quality indicator or
            expected transmission count that node is close to part of, the acceptable
            threshold.

      *  Candidate neighbors that would cause self's rank to increase
         are ignored

   o  Candidate neighbors that advertise an OF incompatible with node must maintain a
   single trickle timer.  The required state contains the set following
   conceptual items:

   I:    The current length of OF specified by the policy functions are ignored.

   o  As it scans all communication interval

   T:    A timer with a duration set to a random value in the candidate neighbors, range
         [I/2, I]

   C:    Redundancy Counter

   I_min:  The smallest communication interval in milliseconds.  This
         value is learned from the OF keeps DIO message as (2^DIOIntervalMin)ms.
         The default value is DEFAULT_DIO_INTERVAL_MIN.

   I_doublings:  The number of times I_min should be doubled before
         maintaining a constant rate, i.e.  I_max = I_min *
         2^I_doublings.  This value is learned from the current
      best parent and compares its capabilities with DIO message as
         DIOIntervalDoublings.  The default value is
         DEFAULT_DIO_INTERVAL_DOUBLINGS.

6.3.4.1.  Resetting the current
      candidate neighbor. Trickle Timer

   The OF defines trickle timer for a number of tests that are
      critical DODAG is reset by:

   1.  Setting I_min and I_doublings to reach the objective.  A test between the routers
      determines an order relation.

      *  If values learned from the routers are roughly equal for that relation then DIO
       message.

   2.  Setting C to zero.

   3.  Setting I to I_min.

   4.  Setting T to a random value as described above.

   5.  Restarting the
         next test is attempted between trickle timer to expire after a duration T

   When a node learns about a DODAG through a DIO message and makes the routers,

      *  Else
   decision to join it, it initializes the best state of the 2 becomes trickle timer by
   resetting the current best parent trickle timer and the
         scan continues with the next candidate neighbor

      *  Some OFs may include listening.  Each time it hears a test
   redundant DIO message for this DODAG, it MAY increment C. The exact
   determination of redundant is left to compare the ranks an implementation; it could
   include DIOs that would
         result if advertise the node joined either router

   o same rank.

   When the scan is complete, timer fires at time T, the preferred parent is elected and
      self's rank node compares C to the redundancy
   constant, DIORedundancyConstant.  If C is computed as less than that value, or if
   the preferred parent rank plus DIORedundancyConstant value is 0xFF, the step
      in rank with that parent.

   o  Other rounds of scans might be necessary to elect alternate
      parents node generates a new DIO
   message and siblings.  In multicasts it.  When the next rounds:

      *  Candidate neighbors that are not in communication interval I
   expires, the same DAG are ignored

      *  Candidate neighbors that are of greater rank than self are
         ignored

      *  Candidate neighbors of an equal rank to self (siblings) are
         ignored

      *  Candidate neighbors of a lesser rank node doubles the interval I so long as it has previously
   doubled it fewer than self (non-siblings)
         are preferred

5.9.2.  Objective Function 0 (OF0)

   This document specifies I_doubling times, resets C, and chooses a default objective function, called OF0,
   indicated by new T
   value.

6.3.4.2.  Determination of Inconsistency

   The trickle timer is reset whenever an OCP value of 0x0000.  OF0 inconsistency is detected
   within the default objective
   function of RPL, and can be used if allowed by the policy of the
   processing DODAG, for example:

   o  The node when the OF indicated in the joins a new DODAG

   o  The node moves within a DODAG

   o  The node receives a modified DIO message is unknown from a DAG parent

   o  A DAG parent forwards a packet intended to the node.  If not allowed, then the DIO message is simply ignored move up, indicating an
      inconsistency and not processed by the node.  OF0 is notable in that it does not
   use physical metrics as described possible loop.

   o  A metric communicated in [I-D.ietf-roll-routing-metrics],
   but is only based on abstract information from the DIO message such is determined to be
      inconsistent, as according to a implementation specific path
      metric selection engine.

   o  The rank and administrative preference.

   OF0 favors connectivity.  That is, the Objective Function of a DAG parent has changed.

6.4.  DAG Selection

   The DAG selection is designed implementation and algorithm dependent.  Nodes
   SHOULD prefer to find the nearest sink into a 'grounded' topology, join DODAGs for InstanceIDs advertising OCPs and if there
   destinations compatible with their implementation specific
   objectives.  In order to limit erratic movements, and all metrics
   being equal, nodes SHOULD keep their previous selection.  Also, nodes
   SHOULD provide a means to filter out a parent whose availability is
   none then join any
   detected as fluctuating, at least when more stable choices are
   available.

   When connection to a fixed network per order of administrative preference.
   The metric in use is not possible or preferable for
   security or other reasons, scattered DODAGs MAY aggregate as much as
   possible into larger DODAGs in order to allow connectivity within the rank.

   OF0 selects a preferred parent
   LLN.

   A node SHOULD verify that bidirectional connectivity and a backup next hop if one adequate
   link quality is
   available.  The backup next hop might be available with a parent or candidate neighbor before it
   considers that candidate as a sibling.  All
   the traffic is routed via the preferred DAG parent.  When the link
   conditions do not let

6.5.  Operation as a packet through Leaf Node

   In some cases it a RPL node may attach to a DODAG for DAG Instance as
   a leaf node only; the preferred parent, the
   packet node in this case is passed not to extend connectivity
   to the backup next hop.

   The step of rank is 4 DODAG to other nodes under any circumstances.  Such a case may
   occur, for each hop.

5.9.2.1.  Selection of the Preferred Parent

   As it scans all the candidate neighbors, OF0 keeps the parent example, when a node is attaching to a DODAG that is
   the best for the following criteria (in order): using
   an unknown Objective Function.  When operating as a leaf node, a
   node:

   1.   The interface must be usable  MAY receive and any administrative preference
        associated with the interface applies first. process DIOs for that DODAG

   2.   A candidate  SHOULD NOT transmit DIOs for that would cause DODAG

   3.  MUST NOT transmit DIOs containing the node DAG Metric Container for
       that DODAG

   4.  MAY transmit unicast DAOs to the chosen parents for that DODAG

   5.  MAY transmit multicast DAOs to augment the `1 hop' neighborhood.

6.6.  Administrative rank in

   When the
        current DAG DODAG is not considered.

   3.   A router that has been validated as usable, e.g. with formed under a local
        confidence that has exceeded some pre-configured threshold, is
        better.

   4.   If none are grounded then common administration, or when a DAG
   node performs a certain role within a community, it might be
   beneficial to associate a range of acceptable rank with that node.
   For instance, a more preferred
        administrative preference (DAGPreference) is better.

   5.   A router node that offers connectivity to has limited battery should be a grounded DAG is better.

   6.   A lesser resulting rank is better.

   7.   A DAG for which leaf unless
   there is an alternate parent is better.  This
        check is optional.  It is performed no other choice, and may then augment the rank computation
   specified by computing the backup next
        hop while assuming that this router won.

   8.   The DAG that was in use already is preferred.

   9.   The preferred parent that was OF in use already is better.

   10. order to expose an exaggerated rank.

6.7.  Collision

   A router that has announced a race condition occurs if 2 nodes send DIO messages at the same time
   and then attempt to join each other.  This might happen, for example,
   between nodes which act as DAG root of their own DODAGs.  In order to
   detect the situation, LLN Nodes time stamp the sending of DIO
   message.  Any DIO message more recently is
        preferred.

5.9.2.2.  Selection received within a short link-layer-
   dependent period introduces a risk.  It left to the implementation to
   define the duration of the Backup Next Hop

   o  The interface must be usable risk window.

   There is risk of a collision when a node receives and processes a DIO
   within the administrative preference (if
      any) applies first.

   o  The preferred parent is ignored.

   o  Candidate neighbors risk window.  For example, it may occur that two nodes are not in the same DAG are ignored.

   o  Candidate neighbors
   associated with a higher rank different DODAGs and near-simultaneously send DIO
   messages, which are ignored.

   o  Candidate neighbors received and processed by both, and possibly
   result in both nodes simultaneously deciding to attach to each other.
   As a remedy, in the face of a better rank than self (non-siblings) are
      preferred.

   o  A router that has been validated potential collision, as usable, e.g. with determined by
   receiving a local
      confidence that has exceeded some pre-configured threshold, DIO within the risk window, the DIO message is
      better.

   o  The router with a better router preference wins.

   o  The backup next hop that was in use already not
   processed.  It is better.

5.10. expected that subsequent DIOs would not cross.

6.8.  Establishing Routing State Outward Along Down the DAG DODAG

   The destination advertisement mechanism supports the dissemination of
   routing state required to support traffic flows outward down along the
   DAG, DODAG,
   from the DAG DODAG root toward nodes.

   As a result of destination advertisement operation:

   o  DAG discovery establishes a DAG oriented toward a DAG root along
      which inward routes toward the DAG root are set up.

   o  Destination advertisement establishes outward down routes along the
      DAG. DODAG.
      Such paths consist of:
      *  Hop-By-Hop routing state within islands of `stateful' nodes.
      *  Source Routing `bridges' across nodes that do not retain state.

   Destinations disseminated with the destination advertisement
   mechanism may be prefixes, individual hosts, or multicast listeners.
   The mechanism supports nodes of varying capabilities as follows:

   o  When nodes are capable capable of storing routing state, they may inspect
      destination advertisements and learn hop-by-hop routing state
      toward destinations by populating their routing tables with the
      routes learned from nodes in their sub-DAG.  In this process they
      may also learn necessary piecewise source routes to traverse
      regions of the LLN that do not maintain routing state.  They may
      perform route aggregation on known destinations before emitting
      Destination Advertisements.

   o  When nodes are incapable of storing routing state, they may
      forward destination advertisements, recording the reverse route as
      the go in order to support the construction of piecewise source
      routes.

   Nodes that are capable of storing routing state, and finally the
   DODAG roots, are able to learn which destinations are contained in
   the sub-DAG below the node, and via which next-hop neighbors.  The
   dissemination and installation of this routing state into nodes
   allows for Hop-By-Hop routing from the DODAG root down the DODAG.
   The mechanism is further enhance by supporting the construction of
   source routes across stateless `gaps' in the DODAG, where nodes are
   incapable of storing additional routing state, they may inspect state.  An adaptation of this
   mechanism allows for the implementation of loose-source routing.

   A special case, the reception of a destination advertisements and advertisement
   addressed to a link-local multicast address, allows for a node to
   learn hop-by-hop routing state
      toward destinations by populating their routing tables with the directly available from its one-hop neighbors.

   A design choice behind advertising routes learned via destination
   advertisements is not to synchronize the parent and children
   databases along the DODAG, but instead to update them regularly to
   recover from nodes the loss of packets.  The rationale for that choice is
   time variations in their sub-DAG.  In this process they
      may also learn necessary piecewise source routes connectivity across unreliable links.  If the
   topology can be expected to traverse
      regions change frequently, synchronization might
   be an excessive goal in terms of exchanges and protocol complexity.
   The approach used here results in a simple protocol with no real
   peering.  The destination advertisement mechanism hence provides for
   periodic updates of the LLN that do not maintain routing state.  They may
      perform route aggregation on known destinations before emitting state, similarly to other protocols
   such as RIP [RFC2453].

6.8.1.  Destination Advertisements.

   o  When nodes are incapable Advertisement Operation

6.8.1.1.  Overview

   According to implementation specific policy, a subset or all of storing routing state, they the
   feasible parents in the DODAG may
      forward be selected to receive prefix
   information from the destination advertisements, recording advertisement mechanism.  This
   subset of DAG parents shall be designated the reverse route as set of DA parents.

   As DAO messages for particular destinations move up the go in order DODAG, a
   sequence counter is used to support guarantee their freshness.  The sequence
   counter is incremented by the construction of piecewise source
      routes.

   Nodes that are capable of storing routing state, and finally the DAG
   roots, are able to learn which destinations are contained in DAO message (the node
   that owns the sub-
   DAG below prefix, or learned the node, and prefix via which next-hop neighbors.  The
   dissemination and installation of this routing state into nodes
   allows some other means),
   each time it issues a DAO message for Hop-By-Hop routing from its prefix.  Nodes that receive
   the DAG root outwards along DAO message and, if scope allows, will be forwarding a DAO
   message for the
   DAG.  The mechanism unmodified destination up the DODAG, will leave the
   sequence number unchanged.  Intermediate nodes will check the
   sequence counter before processing a DAO message, and if the DAO is further enhance by supporting
   unchanged (the sequence counter has not changed), then the construction DAO
   message will be discarded without additional processing.  Further, if
   the DAO message appears to be out of source routes across stateless `gaps' in synch (the sequence counter is 2
   or more behind the DAG, where present value) then the DAO state is considered to
   be stale and may be purged, and the DAO message is discarded.  The
   rank is also added for tracking purposes; nodes that are
   incapable of storing additional
   routing state.  An adaptation of this
   mechanism allows state may use it to determine which possible next-hops for
   the implementation of loose-source routing.

   A special case, destination are more optimal.

   If destination advertisements are activated in the DIO message as
   indicated by the reception of a `D' bit, the node sends unicast destination advertisement
   addressed
   advertisements to a link-local multicast address, allows one of its DA parents, that is selected as most
   favored for a incoming down traffic.  The node to
   learn destinations directly available from its one-hop neighbors.

   A design choice behind advertising routes via only accepts unicast
   destination advertisements is not to synchronize from any nodes but those contained in the
   DA parent and children
   databases along subset.

   Receiving a DIO message with the DAG, but instead to update them regularly to
   recover `D' destination advertisement bit
   set from a DAG parent stimulates the loss sending of packets.  The rationale for that choice a delayed destination
   advertisement back, with the collection of all known prefixes (that
   is
   time variations in connectivity across unreliable links.  If the
   topology can be expected to change frequently, synchronization might
   be an excessive goal prefixes learned via destination advertisements for nodes
   lower in terms of exchanges the DODAG, and protocol complexity.
   The approach used here results any connected prefixes).  If the Destination
   Advertisement Supported (A) bit is set in the DIO message for the
   DODAG, then a simple protocol with no real
   peering.  The destination advertisement mechanism hence provides for
   periodic updates of the routing state, as cued by occasional RAs and
   other mechanisms, similarly is also sent to other protocols such as RIP [RFC2453].

5.10.1.  Destination Advertisement Operation

5.10.1.1.  Overview

   According a DAG parent
   once it has been added to implementation specific policy, the DA parent set after a subset movement, or all of the
   feasible parents in when
   the list of advertised prefixes has changed.

   A node that modifies its DAG Parent set may be selected set the `D' bit in
   subsequent DIO propagation in order to receive prefix
   information from the trigger destination advertisement mechanism.  This
   subset of DAG parents shall
   advertisements to be designated updated to its DAG Parents and other ancestors
   on the set of DA parents.

   As DAO messages for particular destinations move inwards along DODAG.  Additional recommendations and guidelines regarding
   the
   DAG, use of this mechanism are still under consideration and will be
   elaborated in a sequence counter future revision of this specification.

   Destination advertisements may advertise positive (prefix is used to guarantee their freshness.  The
   sequence counter present)
   or negative (removed) DAO messages, termed as no-DAOs.  A no-DAO is incremented
   stimulated by the source disappearance of the DAO message (the
   node that owns the prefix, or learned the a prefix via some other
   means), each time it issues below.  This is
   discovered by timing out after a DAO message for its prefix.  Nodes that
   receive the DAO message and, if scope allows, will be forwarding request (a DIO message) or by
   receiving a no-DAO.  A no-DAO is a conveyed as a DAO message for the unmodified destination inwards along the DAG,
   will leave the sequence number unchanged.  Intermediate nodes will
   check the sequence counter before processing with a
   DAO message, and if
   the DAO Lifetime of ZERO_LIFETIME.

   A node that is unchanged (the sequence counter has not changed), then capable of recording the state information conveyed in
   a unicast DAO message will be discarded without additional processing.
   Further, if the DAO message appears to be out of synch (the sequence
   counter is 2 or more behind the present value) then do so upon receiving and processing the
   DAO message, thus provisioning routing state is
   considered to be stale and may be purged, and concerning destinations
   located downwards along the DODAG.  If a node capable of recording
   state information receives a DAO message is
   discarded.  A depth is also added for tracking purposes; containing a Reverse Route
   Stack, then the depth is
   incremented at each hop as node knows that the DAO message is propagated up the DAG.

   Nodes has traversed one or
   more nodes that are storing did not retain any routing state may use as it traversed the depth
   path from the DAO source to determine
   which possible next-hops for the destination are more optimal.

   If destination advertisements are activated in node.  The node may then extract the DIO message as
   indicated by
   Reverse Route Stack and retain the `D' bit, included state in order to specify
   Source Routing instructions along the return path towards the
   destination.  The node sends unicast destination
   advertisements MUST set the RRCount back to one of its DA parents, zero and clear
   the Reverse Route Stack prior to passing the DAO message information
   on.

   A node that is selected as most
   favored for incoming outwards traffic.  The node only accepts unicast
   destination advertisements from any nodes but those contained unable to record the state information conveyed in the
   DA parent subset.

   Receiving a DIO
   DAO message with will append the `D' destination advertisement bit
   set from a DAG parent stimulates next-hop address to the sending of a delayed destination
   advertisement back, with Reverse Route
   Stack, increment the collection of all known prefixes (that
   is RRCount, and then pass the prefixes learned via destination advertisements for nodes
   lower in the DAG, and
   advertisement on without recording any connected prefixes).  If additional state.  In this way
   the Reverse Route Stack will contain a vector of next hops that must
   be traversed along the Destination
   Advertisement Supported (A) bit is set in reverse path that the DIO DAO message for has
   traveled.  The vector will be ordered such that the
   DAG, then a destination advertisement is also sent node closest to a DAG parent
   once
   the destination will appear first in the list.  In such cases, if it has been added
   is useful to the DA parent set after a movement, or when implementation to try and provision redundant paths,
   the list of advertised prefixes has changed.

   A node that modifies its DAG Parent set may set the `D' bit in
   subsequent DIO propagation in order choose to trigger convey the destination
   advertisements to be updated advertisement to its one or
   more DAG Parents and other inward
   nodes on the DAG.  Additional recommendations and guidelines
   regarding the use of this mechanism are still under consideration and
   will be elaborated parents in a future revision order of this specification.

   Destination advertisements may advertise positive (prefix is present)
   or negative (removed) DAO messages, termed preference as no-DAOs.  A no-DAO is
   stimulated guided by an
   implementation specific policy.

   In certain cases (called hybrid cases), some nodes along the disappearance of a prefix below.  This is
   discovered by timing out after a request (a DIO message) or by
   receiving a no-DAO.  A no-DAO is a conveyed as a DAO message with path a
   DAO Lifetime of ZERO_LIFETIME.

   A node that is capable of recording
   destination advertisement follows up the DODAG may store state information conveyed in
   a unicast DAO message will do so upon receiving and processing the
   DAO message, thus building up routing state concerning destinations
   below it in
   some may not.  The destination advertisement mechanism allows for the DAG.  If a node capable
   provisioning of recording routing state
   information receives a DAO message containing such that when a Reverse Route Stack,
   then packet is traversing
   down the node knows that DODAG, some nodes may be able to directly forward to the DAO message has traversed one or more
   next hop, and other nodes that did not retain may be able to specify a piecewise source
   route in order to bridge spans of stateless nodes within the path on
   the way to the desired destination.

   In the case where no node is able to store any routing state as it traversed the path
   from
   destination advertisements pass by, and the DAG root ends up with DAO source
   messages that contain a completely specified route back to the node.  The
   originating node may then extract in the form of the inverted Reverse Route Stack and retain Stack.  A
   DAG root should not request (Destination Advertisement Trigger) nor
   indicate support (Destination Advertisement Supported) for
   destination advertisements if it is not able to store the included state Reverse
   Route Stack information in order this case.

   The destination advertisement mechanism requires stateful nodes to specify
   Source Routing instructions along
   maintain lists of known prefixes.  A prefix entry contains the return path towards
   following abstract information:

   o  A reference to the
   destination. ND entry that was created for the advertising
      neighbor.

   o  The node MUST set IPv6 address and interface for the advertising neighbor.

   o  The logical equivalent of the full destination advertisement
      information (including the prefixes, depth, and Reverse Route
      Stack, if any).

   o  A 'reported' Boolean to keep track whether this prefix was
      reported already, and to which of the RRCount back DA parents.

   o  A counter of retries to zero and clear count how many DIO messages were sent on
      the Reverse Route Stack prior interface to passing the DAO message advertising neighbor without reachability
      confirmation for the prefix.

   Note that nodes may receive multiple information
   on. from different
   neighbors for a specific destination, as different paths through the
   DODAG may be propagating information up the DODAG for the same
   destination.  A node that is unable to record the recording routing state will keep track
   of the information conveyed in from each neighbor independently, and when it
   comes time to propagate the DAO message will append the next-hop address for a particular prefix to
   the Reverse Route
   Stack, increment the RRCount, and DA parents, then pass the destination
   advertisement on without recording any additional state.  In this way the Reverse Route Stack DAO information will contain a vector of next hops that must be traversed along selected from among
   the reverse path that advertising neighbors who offer the DAO message has
   traveled.  The vector will be ordered such least depth to the
   destination.

   When a node loses connectivity to a child that is used as next hop
   for a route learned from a DAO, the node closest should cleanup all routes
   and DAO states that are related to that child.  If the destination will appear first in lost child was
   the list.  In such cases, if it
   is useful only adjacency leading to the implementation to try and build up redundant paths, DAO prefix, the node may choose to convey should poison
   the destination advertisement to one or
   more DAG parents in order of preference as guided route by an
   implementation specific policy.

   In some cases (called hybrid cases), some nodes along sending no-DAOs to the path a
   destination advertisement follows inward along parents to which it has
   advertised the DAG may store
   state and some may not. DAO prefixes.

   The destination advertisement mechanism
   allows for stores the provisioning prefix entries in
   one of routing state such that when a packet
   is traversing outwards along 3 abstract lists; the DAG, some nodes may be able to
   directly forward to Connected, the next hop, Reachable and other nodes may be able the
   Unreachable lists.

   The Connected list corresponds to
   specify a piecewise source route the prefixes owned and managed by
   the local node.

   The Reachable list contains prefixes for which the node keeps
   receiving DAO messages, and for those prefixes which have not yet
   timed out.

   The Unreachable list keeps track of prefixes which are no longer
   valid and in the process of being deleted, in order to bridge spans of
   stateless nodes within the path on the way send DAO
   messages with zero lifetime (also called no-DAO) to the desired
   destination.

   In DA parents.

6.8.1.1.1.  Destination Advertisement Timers

   The destination advertisement mechanism requires 2 timers; the case where no node
   DelayDAO timer and the RemoveTimer.

   o  The DelayDAO timer is able armed upon a stimulation to store any routing state as send a
      destination advertisements pass by, and advertisement (such as a DIO message from a DA
      parent).  When the DAG root ends up with DAO
   messages timer is armed, all entries in the Reachable
      list as well as all entries for Connected list are set to not be
      reported yet for that contain particular DA parent.

   o  For a completely specified route back to root, the
   originating DIO timer has a duration of DEF_DAO_LATENCY.  For
      a node in a DODAG iteration, the form DelayDAO timer has a duration
      that is randomized between (DEF_DAO_LATENCY divided by the Rank of
      the inverted Reverse Route Stack.  A
   DAG root should not request (Destination Advertisement Trigger) nor
   indicate support (Destination Advertisement Supported) for
   destination advertisements if it is not able to store node) and (DEF_DAO_LATENCY divided by the Reverse
   Route Stack information in this case. Rank of the parent).
      The destination advertisement mechanism requires stateful intention is that nodes located deeper in the DODAG iteration
      should have a shorter DelayDAO timer, allowing DAO messages a
      chance to
   maintain lists of known prefixes.  A prefix entry contains be reported from deeper in the
   following abstract information: DODAG and potentially
      aggregated along sub-DAGs before propagating further up.

   o  A reference  The RemoveTimer is used to clean up entries for which DAO messages
      are no longer being received from the ND entry sub-DAG.

      *  When a DIO message is sent that was created is requesting destination
         advertisements, a flag is set for all DAO entries in the advertising
      neighbor.

   o  The IPv6 address and interface
         routing table.

      *  If the flag has already been set for a DAO entry, the advertising neighbor.

   o  The logical equivalent of retry
         count is incremented.

      *  If a DAO message is received to confirm the full destination advertisement
      information (including entry, the prefixes, depth, entry is
         refreshed and Reverse Route
      Stack, if any).

   o  A 'reported' Boolean to keep track whether this prefix was
      reported already, the flag and count may be cleared.

      *  If at least one entry has reached a threshold value and to which of the DA parents.

   o  A counter of retries
         RemoveTimer is not running, the entry is considered to count how many DIO be
         probably gone and the RemoveTimer is started.

      *  When the RemoveTimer elapse, DAO messages were with lifetime 0, i.e.
         no-DAOs, are sent on
      the interface to explicitly inform DA parents that the advertising neighbor without reachability
      confirmation for
         entries which have reached the prefix.

   Note that nodes may receive multiple information from different
   neighbors for a specific destination, as different paths through threshold are no longer
         available, and the
   DAG related routing states may be propagating information inwards along the DAG propagated and
         cleaned up.

   o  The RemoveTimer has a duration of min (MAX_DESTROY_INTERVAL,
      TBD(DIO Trickle Timer Interval)).

6.8.1.2.  Multicast Destination Advertisement Messages

   It is also possible for the same
   destination.  A a node that is recording routing state will keep track
   of the information from each neighbor independently, and when it
   comes time to propagate the multicast a DAO message for a particular prefix to the DA parents, then the DAO information
   link-local scope all-nodes multicast address FF02::1.  This message
   will be selected from among
   the advertising neighbors who offer received by all node listening in range of the least depth emitting node.
   The objective is to enable direct P2P communication, between
   destinations directly supported by neighboring nodes, without needing
   the
   destination.

   The destination advertisement mechanism stores RPL routing structure to relay the prefix entries packets.

   A multicast DAO message MUST be used only to advertise information
   about self, i.e. prefixes in
   one of 3 abstract lists; the Connected, the Reachable and the
   Unreachable lists.

   The Connected list corresponds or addresses owned by
   this node.  This would typically be a multicast group that this node
   is listening to or a global address owned by this node, though it can
   be used to the prefixes advertise any prefix owned and managed by
   the local node.

   The Reachable list contains prefixes for which the this node keeps
   receiving as well.  A
   multicast DAO messages, and message is not used for those prefixes which have routing and does not yet
   timed out.

   The Unreachable list keeps track of prefixes which are no longer
   valid presume
   any DODAG relationship between the emitter and in the process of being deleted, in order to send DAO
   messages with zero lifetime (also called no-DAO) receiver; it MUST
   NOT be used to relay information learned (e.g. information in the DA parents.

5.10.1.1.1.  Destination Advertisement Timers

   The destination advertisement mechanism requires 2 timers;
   Reachable list) from another node; information obtained from a
   multicast DAO MAY be installed in the
   DelayDAO timer routing table and the RemoveTimer.

   o  The DelayDAO timer is armed upon a stimulation to send MAY be
   propagated by a
      destination advertisement (such as router in unicast DAOs.

   A node receiving a DIO multicast DAO message from a DA
      parent).  When addressed to FF02::1 MAY
   install prefixes contained in the timer is armed, all entries DAO message in the Reachable
      list as well as all entries for Connected list are set to not be
      reported yet routing table
   for that particular DA parent.

   o  The DelayDAO timer has a duration that is DEF_DAO_LATENCY divided
      by local use.  Such a multiple of the DAG rank of node MUST NOT perform any other processing on
   the node.  The intention DAO message (i.e. such a node does not presume it is that
      nodes located deeper in the DAG should have a shorter DelayDAO
      timer, allowing DAO messages DA
   parent).

6.8.1.3.  Unicast Destination Advertisement Messages from Child to
          Parent

   When sending a chance destination advertisement to be a DA parent, a node
   includes the DAOs for prefix entries not already reported (since the
   last DA Trigger from deeper an DIO message) in the DAG Reachable and potentially aggregated along sub-DAGs before
      propagating further inwards.

   o  The RemoveTimer is used to clean up entries for which DAO messages
      are no longer being received from the sub-DAG.

      *  When a DIO message is sent that is requesting destination
         advertisements, a flag is set Connected
   lists, as well as no-DAOs for all DAO the entries in the Unreachable
   list.  Depending on its policy and ability to retain routing table.

      *  If state,
   the flag has already been set for receiving node SHOULD keep a DAO entry, record of the retry
         count is incremented.

      * reported DAO message.
   If a the DAO message is received to confirm offers the entry, best route to the entry is
         refreshed prefix as determined
   by policy and other prefix records, the flag and count may be cleared.

      *  If at least one entry has reached node SHOULD install a threshold value and the
         RemoveTimer is not running, the entry is considered route
   to be
         probably gone and the RemoveTimer is started.

      *  When prefix reported in the RemoveTimer elapse, DAO messages with lifetime 0, i.e.
         no-DAOs, are sent to explicitly inform DA parents that the
         entries which have reached the threshold are no longer
         available, and message via the related routing states may be propagated and
         cleaned up.

   o  The RemoveTimer has a duration of min (MAX_DESTROY_INTERVAL,
      TBD(DIO Trickle Timer Interval)).

5.10.1.2.  Multicast Destination Advertisement Messages

   It is also possible for a node to multicast link local address
   of the reporting neighbor and it SHOULD further propagate the
   information in a DAO message.

   The DIO message from the DODAG root is used to synchronize the
   link-local scope all-nodes multicast address FF02::1.  This message
   will be received by all node listening in range whole
   DODAG iteration, including the periodic reporting of destination
   advertisements back up the emitting node.
   The objective DODAG.  Its period is expected to enable direct P2P communication, between
   destinations directly supported by neighboring nodes, without needing vary,
   depending on the RPL routing structure to relay configuration of the packets.

   A multicast DAO DIO trickle timer.

   When a node receives a DIO message MUST be used only over an LLN interface from a DA
   parent, the DelayDAO is armed to advertise information
   about self, i.e. prefixes in force a full update.

   When the Connected list or addresses owned by
   this node.  This would typically be node broadcasts a multicast group DIO message on an LLN interface, for all
   entries on that this node interface:

   o  If the entry is listening to or a global address owned by this node, though CONFIRMED, it can
   be used goes PENDING with the retry count
      set to advertise any prefix owned by this node as well.  A
   multicast DAO message 0.

   o  If the entry is PENDING, the retry count is incremented.  If it
      reaches a maximum threshold, the entry goes ELAPSED If at least
      one entry is ELAPSED at the end of the process: if the RemoveTimer
      is not used for routing and does not presume
   any DAG relationship between running then it is armed with a jitter.

   Since the emitter and DelayDAO timer has a duration that decreases with the receiver;
   depth, it MUST
   NOT be used is expected to relay information learned (e.g. information in the
   Reachable list) from another node; information obtained from a
   multicast receive all DAO MAY be installed in messages from all children
   before the routing table timer elapses and MAY the full update is sent to the DA
   parents.

   Once the RemoveTimer is elapsed, the prefix entry is scheduled to be
   propagated by a router in unicast DAOs.

   A node receiving a multicast DAO message addressed
   removed and moved to FF02::1 MAY
   install prefixes contained in the DAO message in Unreachable list if there are any DA parents
   that need to be informed of the routing table change in status for local use.  Such a node MUST NOT perform any other processing on the DAO message (i.e. such a node does not presume it prefix,
   otherwise the prefix entry is a DA
   parent).

5.10.1.3.  Unicast Destination Advertisement Messages cleaned up right away.  The prefix
   entry is removed from Child the Unreachable list when no more DA parents
   need to
           Parent

   When sending be informed.  This condition may be satisfied when a destination advertisement no-DAO
   is sent to a all current DA parent, a node
   includes parents indicating the DAOs for prefix entries not already reported (since loss of the
   last DA Trigger prefix,
   and noting that in some cases parents may have been removed from an DIO message) the
   set of DA parents.

6.8.1.4.  Other Events

   Finally, the destination advertisement mechanism responds to a series
   of events, such as:

   o  Destination advertisement operation stopped: All entries in the Reachable and Connected
   lists, as well as no-DAOs
      abstract lists are freed.  All the routes learned from DAO
      messages are removed.

   o  Interface going down: for all the entries in the Unreachable
   list.  Depending Reachable list on its policy
      that interface, the associated route is removed, and ability the entry is
      scheduled to retain be removed.

   o  Loss of routing state, adjacency: When the receiving node SHOULD keep routing adjacency for a record of
      neighbor is lost, as per the reported DAO message.
   If procedures described in Section 6.11,
      and if the DAO message offers associated entries are in the best route to Reachable list, the prefix as determined
   by policy
      associated routes are removed, and other prefix records, the node SHOULD install a route entries are scheduled to the prefix reported be
      destroyed.

   o  Changes to DA parent set: all entries in the DAO message via the link local address
   of the reporting neighbor Reachable list are
      set to not 'reported' and it SHOULD further propagate the
   information in DelayDAO is armed.

6.8.1.5.  Aggregation of Prefixes by a DAO message.

   The DIO message from the DAG root Node

   There may be number of cases where a aggregation may be shared within
   a group of nodes.  In such a case, it is used possible to synchronize the whole
   DAG, including the periodic reporting of use aggregation
   techniques with destination advertisements
   back up and improve scalability.

   Other cases might occur for which additional support is required:

   1.  The aggregating node is attached within the DAG.  Its period sub-DAG of the nodes
       it is aggregating for.

   2.  A node that is expected to vary, depending on be aggregated for is located somewhere else
       within the
   configuration DODAG iteration, not in the sub-DAG of the trickle timer aggregating
       node.

   3.  A node that governs is to be aggregated for is located somewhere else in
       the RAs.

   When LLN.

   Consider a node receives a DIO message over M that is performing an LLN interface from aggregation, and a DA
   parent, the DelayDAO node N
   that is armed to force be a full update.

   When member of the aggregation group.  A node broadcasts a DIO message on an LLN interface, for all
   entries on that interface:

   o  If Z situated
   above the entry is CONFIRMED, it goes PENDING with node M in the retry count
      set to 0.

   o  If DODAG, but not above node N, will see the entry is PENDING,
   advertisements for the retry count is incremented.  If it
      reaches a maximum threshold, aggregation owned by M but not that of the entry goes ELAPSED If at least
      one entry is ELAPSED at
   individual prefix for N. Such a node Z will route all the end of packets for
   node N towards node M, but node M will have no route to the process: if node N
   and will fail to forward.

   Additional protocols may be applied beyond the RemoveTimer
      is not running then it is armed with scope of this
   specification to dynamically elect/provision an aggregating node and
   groups of nodes eligible to be aggregated in order to provide route
   summarization for a jitter.

   Since the DelayDAO timer has sub-DAG.

6.9.  Loop Detection

   RPL loop avoidance mechanisms are kept simple and designed to
   minimize churn and states.  Loops may form for a duration that decreases with the
   depth, it is expected number of reasons,
   from control packet loss to receive all DAO messages sibling forwarding.  RPL includes a
   reactive loop detection technique that protects from all children
   before the timer elapses meltdown and the full update
   triggers repair of broken paths.

   RPL loop detection uses information that is sent to the DA
   parents.

   Once placed into the RemoveTimer is elapsed, packet in
   the prefix entry IPv6 flow label.  The IPv6 flow label is scheduled to be
   removed defined in [RFC2460] and moved to
   its operation is further specified in [RFC3697].  For the Unreachable list if there are any DA parents
   that need to be informed purpose of
   RPL operations, the change in status for the prefix,
   otherwise flow label is constructed as follows:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |O|S|R|F|  SenderRank   |  InstanceID   |
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 12: RPL Flow Label

   Down 'O' bit:  1-bit flag indicating whether the prefix entry packet is cleaned expected
         to progress up right away.  The prefix
   entry is removed from or down.  A router sets the Unreachable list when no more DA parents
   need to be informed.  This condition may be satisfied 'O' bit when a no-DAO the
         packet is sent expect to all current DA parents indicating the loss of the prefix, progress down (using DAO routes), and noting that in some cases parents may have been removed from the
   set of DA parents.

5.10.1.4.  Other Events

   Finally,
         resets it when forwarding towards the destination advertisement mechanism responds to a series root of events, such as:

   o  Destination advertisement operation stopped: All entries in the
      abstract lists are freed.  All the routes learned from DAO
      messages are removed.

   o  Interface going down: for all entries in the Reachable list on
      that interface, the associated route is removed, and DODAG
         iteration.  A host MUST set the entry is
      scheduled bit to be removed.

   o  Loss of routing adjacency: When 0.

   Sibling 'S' bit:  1-bit flag indicating whether the routing adjacency for packet has been
         forwarded via a
      neighbor is lost, as per sibling at the procedures described in Section 5.13, present rank, and if denotes a risk
         of a sibling loop.  A host sets the associated entries are bit to 0.

   Rank-Error 'R' bit:  1-bit flag indicating whether a rank error was
         detected.  A rank error is detected when there is a mismatch in
         the Reachable list, the
      associated routes are removed, relative ranks and the entries are scheduled to be
      destroyed.

   o  Changes to DA parent set: all entries direction as indicated in the Reachable list are 'O'
         bit.  A host MUST set the bit to 0.

   Forwarding-Error 'F' bit:  1-bit flag indicating that this node can
         not 'reported' and DelayDAO is armed.

5.10.1.5.  Aggregation of Prefixes forward the packet further towards the destination.  The
         'F' bit might be set by sibling that can not forward to a Node

   There may be number of cases where
         parent a aggregation may be shared within packet with the Sibling 'S' bit set, or by a group of nodes.  In such child
         node that does not have a case, it is possible route to use aggregation
   techniques with destination advertisements and improve scalability.

   Other cases might occur for which additional support is required:

   1.  The aggregating node is attached within a packet
         with the down 'O' bit set.  A host MUST set the bit to 0.

   SenderRank:  8-bit field set to zero by the source and to its rank by
         a router that forwards inside the RPL network.

   InstanceID:  8-bit field indicating the sub-DAG of DODAG instance along which
         the nodes
       it packet is aggregating for.

   2. sent.

6.9.1.  Source Node Operation

   A node packet that is sourced at a node connected to a RPL network or
   destined to a node connected to a RPL network MUST be aggregated issued with the
   flow label zeroed out, but for is located somewhere else
       within the DAG, not in InstanceID field.

   If the sub-DAG source is aware of the aggregating node.

   3.  A node InstanceID that is to be aggregated preferred for is located somewhere else the
   flow, then it MUST set the InstanceID field in the LLN.

   Consider a node M that is performing an aggregation, and flow label
   accordingly, otherwise it MUST set it to the RPL_DEFAULT_INSTANCE.

   If a node N
   that compression mechanism such as 6LoWPAN is applied to be a member of the aggregation group.  A node Z situated
   above the node M in the DAG, but not above node N, will see the
   advertisements for packet,
   the aggregation owned by M but not flow label MUST NOT be compressed even if it is set to all
   zeroes.

6.9.2.  Router Operation

6.9.2.1.  Conformance to RFC 3697

   [RFC3697] mandates that of the
   individual prefix for N. Such a node Z will route all Flow Label value set by the packets for
   node N towards node M, but node M will have no route source MUST
   be delivered unchanged to the node N
   and will fail destination node(s).

   In order to forward.

   Additional protocols may be applied beyond restore the scope of this
   specification flow label to dynamically elect/provision its original value, an aggregating node and
   groups of nodes eligible RPL
   router that delivers a packet to a destination connected to a RPL
   network or that routes a packet outside the RPL network MUST zero out
   all the fields but the InstanceID field that must be aggregated in order to provide route
   summarization for delivered
   without a sub-DAG.

5.11.  Loop Detection

   RPL loop avoidance mechanisms change.

6.9.2.2.  Instance Forwarding

   Instance IDs are kept simple and designed used to
   minimize churn and states.  Loops may form avoid loops between DODAGs from different
   origins.  DODAGs that constructed for antagonistic constraints might
   contain paths that, if mixed together, would yield loops.  Those
   loops are avoided by forwarding a number of reasons,
   from control packet loss along the DODAG that is
   associated to sibling forwarding.  RPL includes a
   reactive loop detection technique that protects from meltdown and
   triggers repair of broken paths.

   RPL loop detection uses information that given instance.

   The InstanceID is placed into by the packet source in the flow label.  It assumes that the flow label may be overloaded for
   this purpose.  The flow label is constructed as follows:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                               |O|S|R|D|  SenderRank   |  This
   InstanceID   |
                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 10: RPL Flow Label

   Outwards 'O' bit:  1-bit flag indicating whether MUST match the DODAG instance onto which the packet is
         expected to progress inwards
   placed by any node, be it a host or outwards.  A router.

   When a router sets receives a packet that is flagged with a given
   InstanceID and the
         'O' bit when node can forward the packet is expect along the DODAG
   associated to progress outwards (using
         DAO routes), that instance, then the router MUST do so and resets it when forwarding towards leave the
   InstanceID flag unchanged.

   If any node can not forward a packet along the DODAG associated to
   the root of InstanceID in the DAG.  A host MUST set flow label, then the bit to 0.

   Sibling 'S' bit:  1-bit flag indicating whether node SHOULD discard the packet has been
         forwarded via a sibling at
   packet.

6.9.2.3.  DAG Inconsistency Loop Detection

   The DODAG is inconsistent if the present rank, and denotes a risk direction of a sibling loop.  A host sets packet does not match
   the bit to 0.

   Rank-Error 'R' bit:  1-bit flag indicating whether a rank error was
         detected. relationship.  A rank error is detected when there is receiver detects an inconsistency if it
   receives a mismatch in
         the relative ranks and the direction as indicated in packet with either:

      the 'O'
         bit.  A host MUST bit set (to down) from a node of a higher rank.

      the 'O' bit to 0.

   DAO-Error 'D' bit:  1-bit flag indicating whether reset (for up) from a DAO error was
         detected.  An undetected DAO error would have resulted in an
         inward to outward transition that is not expected with this
         spec.  A host MUST set node of a lesser rank.

      the 'S' bit to 0.

   SenderRank:  8-bit field indicating the rank set (to sibling) from a node of a different rank.

   When the sender.  A host
         MUST set DODAG root increments the DAG Sequence Number a temporary
   rank to INFINITE_RANK.  A router MUST place its
         own discontinuity may form between the next iteration and the prior
   iteration, in particular if nodes are adjusting their rank in the flow label when forwarding.

   InstanceID:  8-bit field indicating the DAG instance along which
   next iteration and deferring their migration into the
         packet is sent.

5.11.1.  Host Basic Operation

   It is expected that a host next iteration.
   A router that does not participate to RPL in any
   fashion is configured to set still a member of the flow label prior iteration may choose to all zeroes in its
   outgoing packets.  The host MAY send
   forward a packet to any router
   regardless of the DAG and RPL operations at large.

   A host a (future) parent that participates is in the next iteration.
   In some cases this could cause the parent to RPL SHOULD zero out all detect an inconsistency
   because the rank-ordering in the prior iteration is not necessarily
   the same as in the flags, next iteration and it
   MUST set the sender rank packet may be judged to INFINITE_RANK. not
   be making forward progress.  If the host can map a
   flow to a given InstanceID sending router is aware that the
   chosen successor has already joined the next iteration, then it the
   sending router MUST set update the flow label
   accordingly.  Forwarding rules are SenderRank to INFINITE_RANK as it
   forwards the same for this host and a
   router, and are described in packets across the discontinuity into the next section.

5.11.2.  Instance Forwarding

   Instance IDs is used DODAG
   iteration in order to avoid loops between DAGs from different
   origins.  DAGs that constructed for antagonistic constraints might
   contain paths that, if mixed together, would yield loops.  Those
   loops are avoided by forwarding a packet false detection of rank inconsistency.

   One inconsistency along the DAG that path is
   associated to not considered as a given instance.

   The InstanceID critical
   error and the packet may continue.  But a second detection along the
   path of a same packet should not occur and the packet is placed dropped.

   This process is controlled by the source Rank-Error bit in the flow label.  It Flow Label.
   When an inconsistency, is not
   meaningful detected on a packet, if the packet has the flow label Rank-Error bit
   was not set to all zeroes.
   Otherwise then the Rank-Error bit is set.  If it MUST match was set the DAG instance onto which packet
   is discarded and the trickle timer is reset.

6.9.2.4.  Sibling Loop Avoidance

   When a packet is
   placed by any node, be forwarded along siblings, it cannot be checked for
   forward progress and may loop between siblings.  Experimental
   evidence has shown that one sibling hop can be very useful but is
   generally sufficient to avoid loops.  Based on that evidence, this
   specification enforces the simple rule that a packet may not make 2
   sibling hops in a row.

   When a host issues a packet or router.

   When when a router receives forwards a packet that is flagged with to a given instance
   ID and
   non-sibling, the node can forward Sibling bit in the packet along the DAG associated to
   that instance, then the must be reset.  When a
   router MUST do so and leave the instance ID
   flag unchanged.

   If any node can not forward forwards to a packet along sibling: if the DAG associated to Sibling bit was not set then the
   instance ID in
   Sibling bit is set.  If the flow label, Sibling bit was set then then the node MAY either change router
   SHOULD return the
   InstanceID packet to match a DAG the sibling that that passed it is using for this packet or discard with the packet.  That decision
   Forwarding-Error 'F' bit set.

6.9.2.5.  DAO Inconsistency Loop Detection and Recovery

   A DAO inconsistency happens when router that has an down DAO route
   via a child that is based on a policy.

   The default policy remnant from an obsolete state that is as follows: if not
   matched in the node child.  With DAO inconsistency loop recovery, a packet
   can forward be used to recursively explore and cleanup the obsolete DAO
   states along a sub-DAG.

   In a general manner, a packet that goes down should never go up
   again.  So rather than routing up a packet with the
   DAG associated to down bit set, the instance RPL_DEFAULT_INSTANCE then it should do
   so.  Otherwise it should drop
   router MUST discard the packet.

5.11.3.  DAG Inconsistency Loop Detection

   The DAG is inconsistent  If DAO inconsistency loop recovery
   is applied, then the router SHOULD send the direction of a packet does not match to the rank relationship.  A receiver detects an inconsistency if parent that
   passed it
   receives a packet with either: the 'O' Forwarding-Error 'F' bit set (to outwards) from set.

6.9.2.6.  Forward Path Recovery

   Upon receiving a node of packet with a higher rank.

      the 'O' Forwarding-Error bit reset (for inwards) from a set, the node of a lesser rank.
   MUST remove the 'S' routing states that caused forwarding to that
   neighbor, clear the Forwarding-Error bit set (to sibling) from a node of a different rank.

   The propagation of a new sequence creates local inconsistencies.  In
   particular, it is possible for a router and attempt to forward a send the
   packet again.  The packet may its way to a
   future parent (same instance, same DAGID, higher sequence) without a
   loop, regardless of the rank of that parent.  In an alternate neighbor.  If
   that case, alternate neighbor still has an inconsistent DAO state via this
   node, the
   sending router MUST present itself process will recurse, this node will set the Forwarding-
   Error 'F' bit and the routing state in the alternate neighbor will be
   cleaned up as a host on well.

6.10.  Multicast Operation

   This section describes further the future DAG multicast routing operations over
   an IPv6 RPL network, and
   use specifically how unicast DAOs can be used to
   relay group registrations up.  Wherever the following text mentions
   MLD, one can read MLDv2 or v3.

   As is traditional, a rank of INFINITE_RANK listener uses a protocol such as it forwards the packets via MLD with a future
   parent
   router to register to avoid a false positive.

   One inconsistency along multicast group.

   Along the path is not considered as a critical
   error between the router and the packet may continue.  But a second detection along DODAG root, MLD requests
   are mapped and transported as DAO messages within the
   path of RPL protocol;
   each hop coalesces the multiple requests for a same packet should not occur and the packet is dropped.

   This process is controlled by group as a single
   DAO message to the Rank-Error bit parent(s), in the Flow Label.
   When an inconsistency, is detected on a packet, if the Rank-Error bit
   was not set then the Rank-Error bit is set.  If it was set the packet
   is discarded fashion similar to proxy IGMP, but
   recursively between child router and parent up to the trickle timer is reset.

5.11.4.  Sibling Loop Avoidance

   When root.

   A router might select to pass a packet is forwarded along siblings, it cannot listener registration DAO message to
   its preferred parent only, in which case multicast packets coming
   back might be checked lost for
   forward progress and may loop between siblings.  Experimental
   evidence has shown that one sibling hop can be very useful but is
   generally sufficient to avoid loops.  Based on that evidence, this
   specification enforces all of its sub-DAG if the simple rule transmission fails
   over that a packet may not make 2
   sibling hops in a row.

   When a host issues a packet or when a link.  Alternatively the router forwards a packet might select to a
   non sibling, the Sibling bit copy
   additional parents as it would do for DAO messages advertising
   unicast destinations, in the packet must which case there might be reset.  When a duplicates that
   the router forwards will need to prune.

   As a sibling: if result, multicast routing states are installed in each router on
   the Sibling bit was not set then way from the
   Sibling bit is set.  If listeners to the Sibling bit was set then root, enabling the packet is
   discarded.  This does not denote root to copy a graph inconsistency but indicates
   multicast packet to all its children routers that had issued a new graph should probably be formed with a new sequence.

5.11.5. DAO Inconsistency Loop Detection and Recovery

   A
   message including a DAO inconsistency happens when router for that has an outwards DAO
   route via a child multicast group, as well as all the
   attached nodes that registered over MLD.

   For unicast traffic, it is a remnant from an obsolete state expected that is
   not matched in the child.  With DAO inconsistency loop recovery, a
   packet can be used to recursively explore grounded root of an
   DODAG terminates RPL and cleanup MAY redistribute the obsolete
   DAO states along a sub-DAG.

   In a general manner, a packet that goes outwards should never go
   inwards again.  So rather than RPL routes over the
   external infrastructure using whatever routing inwards protocol is used
   there.  For multicast traffic, the root MAY proxy MLD for all the
   nodes attached to the RPL routers (this would be needed if the
   multicast source is located in the external infrastructure).  For
   such a source, the packet with will be replicated as it flows down the
   Outwards bit set,
   DODAG based on the router MUST discard multicast routing table entries installed from the packet.  If
   DAO
   inconsistency loop recovery message.

   For a source inside the DODAG, the packet is applied, passed to the preferred
   parents, and if that fails then to the router SHOULD send alternates in the DODAG.  The
   packet is also copied to all the parent registered children, except for the
   one that passed it with the DAO-Error bit set.

   Upon a packet with packet.  Finally, if there is a DAO bit set, listener in the parent MUST remove
   external infrastructure then the routing
   states that caused forwarding DODAG root has to that child, clear DAO-Error bit and
   send further propagate
   the packet again.  The packet will make its way either to an
   alternate child or inwards to into the external infrastructure.

   As a parent.  If that parent still has result, the DODAG Root acts as an
   inconsistent DAO state via self, automatic proxy Rendezvous
   Point for the process will recurse RPL network, and that
   state will be cleaned up as well.

5.12.  Multicast Operation

   This section describes further source towards the Internet for all
   multicast routing operations over
   an IPv6 flows started in the RPL network, LLN.  So regardless of whether the
   root is actually attached to the Internet, and specifically how unicast DAOs regardless of whether
   the DODAG is grounded or floating, the root can be used serve inner multicast
   streams at all times.

6.11.  Maintenance of Routing Adjacency

   The selection of successors, along the default paths up along the
   DODAG, or along the paths learned from destination advertisements
   down along the DODAG, leads to
   relay group registrations inwards.  Wherever the following text
   mentions MLD, one can read MLDv2 formation of routing adjacencies
   that require maintenance.

   In IGPs such as OSPF [RFC4915] or v3.

   As IS-IS [RFC5120], the maintenance of
   a routing adjacency involves the use of Keepalive mechanisms (Hellos)
   or other protocols such as BFD ([I-D.ietf-bfd-base]) and MANET
   Neighborhood Discovery Protocol (NHDP [I-D.ietf-manet-nhdp]).
   Unfortunately, such an approach is traditional, a listener uses a protocol not desirable in constrained
   environments such as MLD LLN and would lead to excessive control traffic
   in light of the data traffic with a
   router to register negative impact on both link
   loads and nodes resources.  Overhead to a multicast group.

   Along the path between maintain the router and routing
   adjacency should be minimized.  Furthermore, it is not always
   possible to rely on the root link or transport layer to provide
   information of the DAG, MLD
   requests are mapped and transported as DAO messages within the associated link state.  The network layer needs to
   fall back on its own mechanism.

   Thus RPL
   protocol; each hop coalesces makes use of a different approach consisting of probing the multiple requests for
   neighbor using a same group
   as Neighbor Solicitation message (see [RFC4861]).  The
   reception of a single DAO Neighbor Advertisement (NA) message to with the parent(s), in a fashion similar to
   proxy IGMP, but recursively between child router and parent up
   "Solicited Flag" set is used to verify the
   root.

   A router might select to pass a listener registration DAO message to
   its preferred parent only, in which case multicast packets coming
   back might be lost for all validity of its sub-DAG if the transmission fails
   over that link.  Alternatively the router might select to copy
   additional parents as it would do for DAO messages advertising
   unicast destinations, in which case there might be duplicates that the router will need to prune.

   As a result, multicast routing states are installed in each router on
   the way from the listeners
   adjacency.  Such mechanism MAY be used prior to sending a data
   packet.  This allows for detecting whether or not the root, enabling routing
   adjacency is still valid, and should it not be the root case, select
   another feasible successor to copy forward the packet.

7.  Suggestions for Packet Forwarding

   When forwarding a
   multicast packet to all its children routers that had issued a DAO
   message including destination, precedence is given to
   selection of a DAO for that multicast group, as well next-hop successor as all follows:

   1.  In the
   attached nodes that registered over MLD.

   For unicast traffic, scope of this specification, it is expected preferred to select a
       successor from a DODAG iteration that matches the grounded root of an RPL
   DAG terminates RPL and MAY redistribute InstanceID
       marked in the RPL routes over IPv6 header of the
   external infrastructure using whatever packet being forwarded.

   2.  If a local administrative preference favors a route that has been
       learned from a different routing protocol than RPL, then use that
       successor.

   3.  If there is used
   there.  For an entry in the routing table matching the
       destination that has been learned from a multicast traffic, destination
       advertisement (e.g. the root MAY proxy MLD for all destination is a one-hop neighbor), then
       use that successor.

   4.  If there is an entry in the
   nodes attached to routing table matching the RPL routers (this would be needed if
       destination that has been learned from a unicast destination
       advertisement (e.g. the
   multicast source destination is located in down the external infrastructure).  For
   such sub-DAG),
       then use that successor.

   5.  If there is a source, DODAG iteration offering a route to a prefix
       matching the packet will be replicated destination, then select one of those DODAG parents
       as it flows outwards
   along the a successor.

   6.  If there is a DAG based on the multicast routing table entries installed
   from the DAO message.

   For parent offering a source inside the DAG, the packet default route then select
       that DAG parent as a successor.

   7.  If there is passed a DODAG iteration offering a route to a prefix
       matching the preferred
   parents, destination, but all DAG parents have been tried and if that fails then to
       are temporarily unavailable (as determined by the alternates in forwarding
       procedure), then select a DAG sibling as a successor.

   8.  Finally, if no DAG siblings are available, the DAG.  The packet is also copied to all the registered children, except for the
   one that passed dropped.
       ICMP Destination Unreachable may be invoked.  An inconsistency is
       detected.

   TTL MUST be decremented when forwarding.  If the packet.  Finally, if there packet is being
   forwarded via a listener in the
   external infrastructure sibling, then the DAG root has TTL MAY be decremented more
   aggressively (by more than one) to further propagate limit the packet into impact of possible
   loops.

   Note that the external infrastructure.

   As a result, chosen successor MUST NOT be the DAG Root acts as an automatic proxy Rendezvous Point
   for neighbor that was the RPL network, and as source towards
   predecessor of the Internet for all
   multicast flows started packet (split horizon), except in the RPL LLN.  So regardless of whether the
   root case where
   it is actually attached intended for the packet to change from an up to an down flow,
   such as switching from DIO routes to DAO routes as the destination is
   neared.

8.  Guidelines for Objective Functions

   An Objective Function (OF) allows for the Internet, selection of a DODAG to
   join, and regardless a number of whether
   the peers in that DAG as parents.  The OF is grounded or floating, the root can serve inner multicast
   streams at all times.

5.13.  Maintenance used
   to compute an ordered list of Routing Adjacency parents.  The selection OF is also responsible to
   compute the rank of successors, along the default paths inward along device within the
   DAG, or along DODAG iteration.

   The Objective Function is indicated in the paths learned from destination advertisements
   outward along DIO message using an
   Objective Code Point (OCP), as specified in
   [I-D.ietf-roll-routing-metrics], and indicates the DAG, leads method that must
   be used to compute the formation of routing adjacencies
   that require maintenance.

   In IGPs such as OSPF [RFC4915] or IS-IS [RFC5120], DODAG (e.g. "minimize the maintenance of
   a routing adjacency involves path cost using the use of Keepalive mechanisms (Hellos)
   or other protocols such as BFD ([I-D.ietf-bfd-base])
   ETX metric and MANET
   Neighborhood Discovery Protocol (NHDP [I-D.ietf-manet-nhdp]).
   Unfortunately, such an approach is not desirable avoid `Blue' links").  The Objective Code Points are
   specified in constrained
   environments such as LLN [I-D.ietf-roll-routing-metrics] and would lead related companion
   specifications.

   Most Objective Functions are expected to excessive control traffic
   in light follow the same abstract
   behavior:

   o  The parent selection is triggered each time an event indicates
      that a potential next hop information is updated.  This might
      happen upon the reception of a DIO message, a timer elapse, or a
      trigger indicating that the data traffic with state of a negative impact candidate neighbor has
      changed.

   o  An OF scans all the interfaces on both link
   loads the device.  Although there may
      typically be only one interface in most application scenarios,
      there might be multiple of them and nodes resources.  Overhead an interface might be
      configured to maintain the routing
   adjacency should be minimized.  Furthermore, it is usable or not always
   possible to rely on the link for RPL operation.  An interface
      can also be configured with a preference or transport layer to provide
   information of the associated link state.  The network layer needs dynamically learned to
   fall back on its own mechanism.

   Thus RPL makes use
      be better than another by some heuristics that might be link-layer
      dependent and are out of scope.  Finally an interface might or not
      match a different approach consisting of probing the
   neighbor using required criterion for an Objective Function, for instance
      a Neighbor Solicitation message (see [RFC4861]).  The
   reception degree of security.  As a Neighbor Advertisement (NA) message with result some interfaces might be
      completely excluded from the
   "Solicited Flag" set is used to verify computation, while others might be
      more or less preferred.

   o  An OF scans all the validity of candidate neighbors on the routing
   adjacency.  Such mechanism MAY be used prior possible interfaces
      to sending check whether they can act as a data
   packet.  This allows router for detecting whether or not the routing
   adjacency is still valid, a DODAG.  There
      might be multiple of them and should a candidate neighbor might need to
      pass some validation tests before it not can be used.  In particular,
      some link layers require experience on the case, select
   another feasible successor to forward the packet.

5.14.  Packet Forwarding

   When forwarding a packet to activity with a destination, precedence is given router
      to
   selection of a next-hop successor enable the router as follows:

   1.  In a next hop.

   o  An OF computes self's rank by adding the scope step of this specification, it is preferred rank to select a
       successor from a DAG that matches the InstanceID marked in
      candidate to the
       IPv6 header rank of the packet being forwarded.

   2.  If a local administrative preference favors a route that has been
       learned from a different routing protocol than RPL, then use that
       successor.

   3.  If there candidate.  The step of rank is an entry in the routing table matching
      computed by estimating the
       destination that has been learned link as follows:

      *  The step of rank might vary from 1 to 16.

         +  1 indicates a multicast destination
       advertisement (e.g. the destination is unusually good link, for instance a one-hop neighbor), then
       use that successor.

   4.  If there is an entry link
            between powered devices in a mostly battery operated
            environment.

         +  4 indicates a `normal'/typical link, as qualified by the routing table matching the
       destination
            implementation.

         +  16 indicates a link that has been learned from can hardly be used to forward any
            packet, for instance a unicast destination
       advertisement (e.g. the destination is located outwards along the
       sub-DAG), then use radio link with quality indicator or
            expected transmission count that successor.

   5.  If there is a DAG offering a route close to a prefix matching the
       destination, then select one of those DAG parents as a successor.

   6.  If there is a DAG parent offering a default route then select acceptable
            threshold.

      *  Candidate neighbors that DAG parent as a successor.

   7.  If there is a DAG offering a route would cause self's rank to a prefix matching increase
         are ignored

   o  Candidate neighbors that advertise an OF incompatible with the
       destination, but set
      of OF specified by the policy functions are ignored.

   o  As it scans all DAG parents have been tried the candidate neighbors, the OF keeps the current
      best parent and are
       temporarily unavailable (as determined by compares its capabilities with the forwarding
       procedure), then select a DAG sibling as current
      candidate neighbor.  The OF defines a successor.

   8.  Finally, if no DAG siblings number of tests that are available,
      critical to reach the packet is dropped.
       ICMP Destination Unreachable may be invoked.  An inconsistency is
       detected.

   TTL MUST be decremented when forwarding. objective.  A test between the routers
      determines an order relation.

      *  If the packet is being
   forwarded via a sibling, routers are roughly equal for that relation then the TTL MAY be decremented more
   aggressively (by more than one) to limit
         next test is attempted between the impact routers,

      *  Else the best of possible
   loops.

   Note that the chosen successor MUST NOT be 2 becomes the current best parent and the
         scan continues with the next candidate neighbor

      *  Some OFs may include a test to compare the ranks that was would
         result if the
   predecessor of node joined either router

   o  When the packet (split horizon), except in scan is complete, the case where
   it preferred parent is intended for elected and
      self's rank is computed as the packet to change from an inward preferred parent rank plus the step
      in rank with that parent.

   o  Other rounds of scans might be necessary to elect alternate
      parents and siblings.  In the next rounds:

      *  Candidate neighbors that are not in the same DODAG are ignored

      *  Candidate neighbors that are of greater rank than self are
         ignored

      *  Candidate neighbors of an outward
   flow, such as switching from DIO routes equal rank to DAO routes as the
   destination is neared.

6. self (siblings) are
         ignored

      *  Candidate neighbors of a lesser rank than self (non-siblings)
         are preferred

9.  RPL Constants and Variables

   Following is a summary of RPL constants and variables.  Some default
   values are to be determined in companion applicability statements.

   ZERO_LIFETIME  This is the special value of a lifetime that indicates
         immediate death and removal.  ZERO_LIFETIME has a value of 0.

   BASE_RANK  This is the rank for a virtual root that might be used to
         coordinate multiple roots.  BASE_RANK has a value of 0.

   ROOT_RANK  This is the rank for a DAG root.  ROOT_RANK has a value of
         1.

   INFINITE_RANK  This is the constant maximum for the rank.
         INFINITE_RANK has a value of 0xFF.

   RPL_DEFAULT_INSTANCE  This is the instance ID InstanceID that is used by this
         protocol by a node without a policy to know any better. overriding policy.
         RPL_DEFAULT_INSTANCE has a value of 0.

   DEFAULT_DIO_INTERVAL_MIN  To be determined

   DEFAULT_DIO_INTERVAL_DOUBLINGS  To be determined

   DEFAULT_DIO_REDUNDANCY_CONSTANT  To be determined

   DEF_DAO_LATENCY  To be determined

   MAX_DESTROY_INTERVAL  To be determined

   DIO Timer  One instance per DAG DODAG that a node is a member of.  Expiry
         triggers DIO message transmission.  Trickle timer with variable
         interval in [0, DIOIntervalMin..2^DIOIntervalDoublings].  See
         Section 5.4.4 6.3.4

   DAG Sequence Number Increment Timer  Up to one instance per DAG DODAG
         that the node is acting as DAG root of.  May not be supported
         in all implementations.  Expiry triggers revision of
         DAGSequenceNumber, causing a new series of updated DIO message
         to be sent.  Interval should be chosen appropriate to
         propagation time of DAG DODAG and as appropriate to application
         requirements (e.g. response time vs. overhead).  See
         Section 5.5

   DelayDAO Timer  Up to one instance per DA parent (the subset of DAG
         parents chosen to receive destination advertisements) per DAG.
         DODAG.  Expiry triggers sending of DAO message to the DA
         parent.  The interval is to be proportional to DEF_DAO_LATENCY/(node DEF_DAO_LATENCY/
         (node rank), such that nodes of greater rank (further outward down
         along the DAG) DODAG) expire first, coordinating the sending of DAO
         messages to allow for a chance of aggregation.  See
         Section 5.10.1.1.1 6.8.1.1.1

   RemoveTimer  Up to one instance per DA entry per neighbor (i.e. those
         neighbors that have given DAO messages to this node as a DAG
         parent) Expiry triggers a change in state for the DA entry,
         setting up to do unreachable (No-DAO) advertisements or
         immediately deallocating the DA entry if there are no DA
         parents.  The interval is min(MAX_DESTROY_INTERVAL, TBD(DIO
         Trickle Timer Interval)).  See Section 5.10.1.1.1

7. 6.8.1.1.1

10.  Manageability Considerations

   The aim of this section is to give consideration to the manageability
   of RPL, and how RPL will be operated in LLN beyond the use of a MIB
   module.  The scope of this section is to consider the following
   aspects of manageability: fault management, configuration, accounting
   and performance.

7.1.

10.1.  Control of Function and Policy

7.1.1.

10.1.1.  Initialization Mode

   When a node is first powered up, it may either choose to stay silent
   and not send any multicast DIO message until it has joined a DAG, DODAG,
   or to immediately root a transient DAG DODAG and start sending multicast
   DIO messages.  A RPL implementation SHOULD allow configuring whether
   the node should stay silent or should start advertising DIO messages.

   Furthermore, the implementation SHOULD to allow configuring whether
   or not the node should start sending an DIS message as an initial
   probe for nearby DAGs, DODAGs, or should simply wait until it received RA DIO
   messages from other nodes that are part of existing DAGs.

7.1.2. DODAGs.

10.1.2.  DIO Base option

   RPL specifies a number of protocol parameters.

   A RPL implementation SHOULD allow configuring the following routing
   protocol parameters, which are further described in Section 5.1.3.1: 6.1.3.1:

   DAGPreference
   InstanceID
   DAGObjectiveCodePoint
   DAGID
   Destination Prefixes
   DIOIntervalDoublings
   DIOIntervalMin
   DIORedundancyConstant

   DAG Root behavior:  In some cases, a node may not want to permanently
         act as a DAG root if it cannot join a grounded DAG. DODAG.  For
         example a battery-operated node may not want to act as a DAG
         root for a long period of time.  Thus a RPL implementation MAY
         support the ability to configure whether or not a node could
         act as a DAG root for a configured period of time.

   DAG Table Entry Suppression  A RPL implementation SHOULD provide the
         ability to configure a timer after the expiration of which the
         DAG table that contains all the records about a DAG is
         suppressed, to be invoked if the DAG parent set becomes empty.

7.1.3.

10.1.3.  Trickle Timers

   A RPL implementation makes use of trickle timer to govern the sending
   of DIO message.  Such an algorithm is determined a by a set of
   configurable parameters that are then advertised by the DAG root
   along the DAG DODAG in DIO messages.

   For each DAG, DODAG, a RPL implementation MUST allow for the monitoring of
   the following parameters, further described in Section 5.4.4: 6.3.4:

   I
   T
   C
   I_min

   I_doublings:
   I_doublings

   A RPL implementation SHOULD provide a command (for example via API,
   CLI, or SNMP MIB) whereby any procedure that detects an inconsistency
   may cause the trickle timer to reset.

7.1.4.

10.1.4.  DAG Sequence Number Increment

   A RPL implementation may allow by configuration at the DAG root to
   refresh the DAG DODAG states by updating the DAGSequenceNumber.  A RPL
   implementation SHOULD allow configuring whether or not periodic or
   event triggered mechanism are used by the DAG root to control
   DAGSequenceNumber change.

7.1.5.

10.1.5.  Destination Advertisement Timers

   The following set of parameters of the DAO messages SHOULD be
   configurable:

   o  The DelayDAO timer

   o  The Remove timer

7.1.6.

10.1.6.  Policy Control

   DAG discovery enables nodes to implement different policies for
   selecting their DAG parents.

   A RPL implementation SHOULD allow configuring the set of acceptable
   or preferred Objective Functions (OF) referenced by their Objective
   Codepoints (OCPs) for a node to join a DAG, DODAG, and what action should
   be taken if none of a node's candidate neighbors advertise one of the
   configured allowable Objective Functions.

   A node in an LLN may learn routing information from different routing
   protocols including RPL.  It is in this case desirable to control via
   administrative preference which route should be favored.  An
   implementation SHOULD allow for specifying an administrative
   preference for the routing protocol from which the route was learned.

   A RPL implementation SHOULD allow for the configuration of the "Route
   Tag" field of the DAO messages according to a set of rules defined by
   policy.

7.1.7.

10.1.7.  Data Structures

   Some RPL implementation may limit the size of the candidate neighbor
   list in order to bound the memory usage, in which case some otherwise
   viable candidate neighbors may not be considered and simply dropped
   from the candidate neighbor list.

   A RPL implementation MAY provide an indicator on the size of the
   candidate neighbor list.

7.2.

10.2.  Information and Data Models

   The information and data models necessary for the operation of RPL
   will be defined in a separate document specifying the RPL SNMP MIB.

7.3.

10.3.  Liveness Detection and Monitoring

   The aim of this section is to describe the various RPL mechanisms
   specified to monitor the protocol.

   As specified in Section 5.2, 6.2, an implementation must is expected to
   maintain a set of data structures in support of DAG discovery:

   o  The candidate neighbors data structure

   o  For each DAG: DODAG:

      *  A set of DAG parents

7.3.1.

10.3.1.  Candidate Neighbor Data Structure

   A node in the candidate neighbor list is a node discovered by the
   some means and qualified to potentially become of neighbor or a
   sibling (with high enough local confidence).  A RPL implementation
   SHOULD provide a way monitor the candidate neighbors list with some
   metric reflecting local confidence (the degree of stability of the
   neighbors) measured by some metrics.

   A RPL implementation MAY provide a counter reporting the number of
   times a candidate neighbor has been ignored, should the number of
   candidate neighbors exceeds the maximum authorized value.

7.3.2.

10.3.2.  Directed Acyclic Graph (DAG) Table

   For each DAG, a RPL implementation MUST is expected to keep track of the
   following
   DAG DODAG table values:

   o  DAGID

   o  DAGObjectiveCodePoint

   o  A set of Destination Prefixes offered inwards upwards along the DAG DODAG

   o  A set of DAG Parents

   o  timer to govern the sending of DIO messages for the DAG DODAG

   o  DAGSequenceNumber

   The set of DAG parents structure is itself a table with the following
   entries:

   o  A reference to the neighboring device which is the DAG parent

   o  A record of most recent information taken from the DAG Information
      Object last processed from the DAG Parent

   o  A flag reporting if the Parent is a DA Parent as described in
      Section 5.10

7.3.3. 6.8

10.3.3.  Routing Table

   For each route provisioned by RPL operation, a RPL implementation
   MUST keep track of the following:

   o  Destination Prefix

   o  Destination Prefix Length

   o  Lifetime Timer

   o  Next Hop

   o  Next Hop Interface

   o  Flag indicating that the route was provisioned from one of:

      *  Unicast DAO message

      *  DIO message

      *  Multicast DAO message

7.3.4.

10.3.4.  Other RPL Monitoring Parameters

   A RPL implementation SHOULD provide a counter reporting the number of
   a times the node has detected an inconsistency with respect to a DAG
   parent, e.g. if the DAGID has changed.

   A RPL implementation MAY log the reception of a malformed DIO message
   along with the neighbor identification if avialable.

7.3.5.

10.3.5.  RPL Trickle Timers

   A RPL implementation operating on a DAG root MUST allow for the
   configuration of the following trickle parameters:

   o  The DIOIntervalMin expressed in ms

   o  The DIOIntervalDoublings

   o  The DIORedundancyConstant

   A RPL implementation MAY provide a counter reporting the number of
   times an inconsistency (and thus the trickle timer has been reset).

7.4.

10.4.  Verifying Correct Operation

   This section has to be completed in further revision of this document
   to list potential Operations and Management (OAM) tools that could be
   used for verifying the correct operation of RPL.

7.5.

10.5.  Requirements on Other Protocols and Functional Components

   RPL does not have any impact on the operation of existing protocols.

7.6.

10.6.  Impact on Network Operation

   To be completed.

8.

11.  Security Considerations

   Security Considerations for RPL are to be developed in accordance
   with recommendations laid out in, for example,
   [I-D.tsao-roll-security-framework].

9.

12.  IANA Considerations

9.1.

12.1.  RPL Control Message

   The RPL Control Message is an ICMP information message type that is
   to be used carry DAG Information Objects, DAG Information
   Solicitations, and Destination Advertisement Objects in support of
   RPL operation.

   IANA has defined a ICMPv6 Type Number Registry.  The suggested type
   value for the RPL Control Message is 155, to be confirmed by IANA.

9.2.

12.2.  New Registry for RPL Control Codes

   IANA is requested to create a registry, RPL Control Codes, for the
   Code field of the ICMPv6 RPL Control Message.

   New codes may be allocated only by an IETF Consensus action.  Each
   code should be tracked with the following qualities:

   o  Code

   o  Description

   o  Defining RFC

   Three codes are currently defined:

        +------+----------------------------------+---------------+
        | Code | Description                      | Reference     |
        +------+----------------------------------+---------------+
        | 0x01 | DAG Information Solicitation     | This document |
        | 0x02 | DAG Information Object           | This document |
        | 0x04 | Destination Advertisement Object | This document |
        +------+----------------------------------+---------------+

                             RPL Control Codes

9.3.

12.3.  New Registry for the Control Field of the DIO Base Option

   IANA is requested to create a registry for the Control field of the
   DIO Base Option. Base.

   New bit numbers may be allocated only by an IETF Consensus action.
   Each bit should be tracked with the following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

   o  Defining RFC

   Four groups are currently defined:

      +-------+-------------------------------------+---------------+
      |  Bit  | Description                         | Reference     |
      +-------+-------------------------------------+---------------+
      |   0   | Grounded DAG DODAG                      | This document |
      |   1   | Destination Advertisement Trigger   | This document |
      |   2   | Destination Advertisement Supported | This document |
      | 5,6,7 | DAG Preference                      | This document |
      +-------+-------------------------------------+---------------+

                              DIO Base Option Flags

9.4.

12.4.  DAG Information Object (DIO) Suboption

   IANA is requested to create a registry for the DIO Base Option Suboptions
         +-------+------------------------------+---------------+
         | Value | Meaning                      | Reference     |
         +-------+------------------------------+---------------+
         |   0   | Pad1 - DIO Padding           | This document |
         |   1   | PadN - DIO suboption padding | This document |
         |   2   | DAG Metric Container         | This Document |
         |   3   | Destination Prefix           | This Document |
         |   4   | DAG Timer Configuration      | This Document |
         +-------+------------------------------+---------------+

               DAG Information Option (DIO) Base Option Suboptions

9.5.  Objective Code Point for the Default Objective Function OF0

   This specification specifies the Default Objective Function (called
   OF0) for which the OCP field of the OF object, as defined in
   [I-D.ietf-roll-routing-metrics], is equal to 0x0000

                    +-------+---------+---------------+
                    | Value | Meaning | Reference     |
                    +-------+---------+---------------+
                    |   0   | OF0     | This document |
                    +-------+---------+---------------+

                              OCP Allocation

10.

13.  Acknowledgements

   The authors would like to acknowledge the review, feedback, and
   comments from Emmanuel Baccelli, Dominique Barthel, Yusuf Bashir,
   Mathilde Durvy, Manhar Goindi, Mukul Goyal, Anders Jagd, Quentin
   Lampin, Jerry Martocci, Alexandru Petrescu, and Don Sturek.

   The authors would like to acknowledge the guidance and input provided
   by the ROLL Chairs, David Culler and JP Vasseur.

   The authors would like to acknowledge prior contributions of Robert
   Assimiti, Mischa Dohler, Julien Abeille, Ryuji Wakikawa, Teco Boot,
   Patrick Wetterwald, Bryan Mclaughlin, Carlos J. Bernardos, Thomas
   Watteyne, Zach Shelby, Caroline Bontoux, Marco Molteni, Billy Moon,
   and Arsalan Tavakoli, which have provided useful design
   considerations to RPL.

11.

14.  Contributors

   RPL is the result of the contribution of the following members of the
   ROLL Design Team, including the editors, and additional contributors
   as listed below:

   JP Vasseur
   Cisco Systems, Inc
   11, Rue Camille Desmoulins
   Issy Les Moulineaux,   92782
   France

   Email: jpv@cisco.com

   Jonathan W. Hui
   Arch Rock Corporation
   501 2nd St. Ste. 410
   San Francisco, CA  94107
   USA

   Email: jhui@archrock.com

   Thomas Heide Clausen
   LIX, Ecole Polytechnique, France

   Phone: +33 6 6058 9349
   EMail: T.Clausen@computer.org
   URI:   http://www.ThomasClausen.org/

   Richard Kelsey
   Ember Corporation
   Boston, MA
   USA

   Phone: +1 617 951 1225
   Email: kelsey@ember.com

   Philip Levis
   Stanford University
   358 Gates Hall, Stanford University
   Stanford, CA  94305-9030
   USA

   Email: pal@cs.stanford.edu

   Richard Kelsey
   Ember Corporation
   Boston, MA
   USA

   Phone: +1 617 951 1225
   Email: kelsey@ember.com

   Stephen Dawson-Haggerty
   UC Berkeley
   Soda Hall, UC Berkeley
   Berkeley, CA  94720
   USA

   Email: stevedh@cs.berkeley.edu

   Kris Pister
   Dust Networks
   30695 Huntwood Ave.
   Hayward,   94544
   USA
   Email: kpister@dustnetworks.com

   Anders Brandt
   Zensys, Inc.
   Emdrupvej 26
   Copenhagen, DK-2100
   Denmark

   Email: abr@zen-sys.com

12.

15.  References

12.1.

15.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

12.2.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

15.2.  Informative References

   [I-D.ietf-bfd-base]
              Katz, D. and D. Ward, "Bidirectional Forwarding
              Detection", draft-ietf-bfd-base-09 (work in progress),
              February 2009.

   [I-D.ietf-manet-nhdp]
              Clausen, T., Dearlove, C., and J. Dean, "MANET "Mobile Ad Hoc
              Network (MANET) Neighborhood Discovery Protocol (NHDP)",
              draft-ietf-manet-nhdp-10
              draft-ietf-manet-nhdp-11 (work in progress), July October 2009.

   [I-D.ietf-roll-building-routing-reqs]
              Martocci, J., Riou, N., Mil, P., and W. Vermeylen,
              "Building Automation Routing Requirements in Low Power and
              Lossy Networks", draft-ietf-roll-building-routing-reqs-07 draft-ietf-roll-building-routing-reqs-08
              (work in progress), September December 2009.

   [I-D.ietf-roll-home-routing-reqs]
              Brandt, A., Buron, J., A. and G. Porcu, J. Buron, "Home Automation Routing
              Requirements in Low Power and Lossy Networks",
              draft-ietf-roll-home-routing-reqs-08
              draft-ietf-roll-home-routing-reqs-09 (work in progress),
              September
              November 2009.

   [I-D.ietf-roll-routing-metrics]
              Vasseur, J. and D. Networks, "Routing Metrics used for
              Path Calculation in Low Power and Lossy Networks",
              draft-ietf-roll-routing-metrics-01
              draft-ietf-roll-routing-metrics-04 (work in progress),
              October
              December 2009.

   [I-D.ietf-roll-terminology]
              Vasseur, J., "Terminology in Low power And Lossy
              Networks", draft-ietf-roll-terminology-02 (work in
              progress), October 2009.

   [I-D.tsao-roll-security-framework]
              Tsao, T., Alexander, R., Dohler, M., Daza, V., and A.
              Lozano, "A Security Framework for Routing over Low Power
              and Lossy Networks", draft-tsao-roll-security-framework-01
              (work in progress), September 2009.

   [Levis08]  Levis, P., Brewer, E., Culler, D., Gay, D., Madden, S.,
              Patel, N., Polastre, J., Shenker, S., Szewczyk, R., and A.
              Woo, "The Emergence of a Networking Primitive in Wireless
              Sensor Networks", Communications of the ACM, v.51 n.7,
              July 2008,
              <http://portal.acm.org/citation.cfm?id=1364804>.

   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
              August 1996.

   [RFC2453]  Malkin, G., "RIP Version 2", STD 56, RFC 2453,
              November 1998.

   [RFC3697]  Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,
              "IPv6 Flow Label Specification", RFC 3697, March 2004.

   [RFC3819]  Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
              Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
              Wood, "Advice for Internet Subnetwork Designers", BCP 89,
              RFC 3819, July 2004.

   [RFC4101]  Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101,
              June 2005.

   [RFC4191]  Draves, R. and D. Thaler, "Default Router Preferences and
              More-Specific Routes", RFC 4191, November 2005.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
              Message Protocol (ICMPv6) for the Internet Protocol
              Version 6 (IPv6) Specification", RFC 4443, March 2006.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC4915]  Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
              Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
              RFC 4915, June 2007.

   [RFC5120]  Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
              Topology (MT) Routing in Intermediate System to
              Intermediate Systems (IS-ISs)", RFC 5120, February 2008.

   [RFC5548]  Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
              "Routing Requirements for Urban Low-Power and Lossy
              Networks", RFC 5548, May 2009.

   [RFC5673]  Pister, K., Thubert, P., Dwars, S., and T. Phinney,
              "Industrial Routing Requirements in Low-Power and Lossy
              Networks", RFC 5673, October 2009.

Appendix A.  Requirements

A.1.  Protocol Properties Overview

   RPL demonstrates the following properties, consistent with the
   requirements specified by the application-specific requirements
   documents.

A.1.1.  IPv6 Architecture

   RPL is strictly compliant with layered IPv6 architecture.

   Further, RPL is designed with consideration to the practical support
   and implementation of IPv6 architecture on devices which may operate
   under severe resource constraints, including but not limited to
   memory, processing power, energy, and communication.  The RPL design
   does not presume high quality reliable links, and operates over lossy
   links (usually low bandwidth with low packet delivery success rate).

A.1.2.  Typical LLN Traffic Patterns

   Multipoint-to-Point (MP2P) and Point-to-multipoint (P2MP) traffic
   flows from nodes within the LLN from and to egress points are very
   common in LLNs.  Low power and lossy network Border Router (LBR)
   nodes may typically be at the root of such flows, although such flows
   are not exclusively rooted at LBRs as determined on an application-
   specific basis.  In particular, several applications such as building
   or home automation do require P2P (Point-to-Point) communication.

   As required by the aforementioned routing requirements documents, RPL
   supports the installation of multiple paths.  The use of multiple
   paths include sending duplicated traffic along diverse paths, as well
   as to support advanced features such as Class of Service (CoS) based
   routing, or simple load balancing among a set of paths (which could
   be useful for the LLN to spread traffic load and avoid fast energy
   depletion on some, e.g. battery powered, nodes).  Conceptually,
   multiple instances of RPL can be used to send traffic along different
   topology instances, the construction of which is governed by
   different Objective Functions (OF).  Details of RPL operation in
   support of multiple instances are beyond the scope of the present
   specification.

A.1.3.  Constraint Based Routing

   The RPL design supports constraint based routing, based on a set of
   routing metrics and constraints.  The routing metrics and constraints
   for links and nodes with capabilities supported by RPL are specified
   in a companion document to this specification,
   [I-D.ietf-roll-routing-metrics].  RPL signals the metrics,
   constraints, and related Objective Functions (OFs) in use in a
   particular implementation by means of an Objective Code Point (OCP).
   Both the routing metrics, constraints, and the OF help determine the
   construction of the Directed Acyclic Graphs (DAG) using a distributed
   path computation algorithm.

A.2.  Deferred Requirements

   NOTE: RPL is still a work in progress.  At this time there remain
   several unsatisfied application requirements, but these are to be
   addressed as RPL is further specified.

Appendix B.  Examples

   Consider the example LLN physical topology in Figure 11. 13.  In this
   example the links depicted are all usable L2 links.  Suppose that all
   links are equally usable, and that the implementation specific policy
   function is simply to minimize hops.  This LLN physical topology then
   yields the DAG depicted in Figure 12, 14, where the links depicted are
   the edges toward DAG parents.  This topology includes one DAG, rooted
   by an LBR node (LBR) at rank 1.  The LBR node will issue DIO
   messages, as governed by a trickle timer.  Nodes (11), (12), (13),
   have selected (LBR) as their only parent, attached to the DAG at rank
   2, and periodically multicast DIOs.  Node (22) has selected (11) and
   (12) in its DAG parent set, and advertises itself at rank 3.  Node
   (22) thus has a set of DAG parents {(11), (12)} and siblings {((21),
   (23)}.

                                     (LBR)
                                     / | \
                                .---`  |  `----.
                               /       |        \
                            (11)------(12)------(13)
                             | \       | \       | \
                             |  `----. |  `----. |  `----.
                             |        \|        \|        \
                            (21)------(22)------(23)      (24)
                             |        /|        /|         |
                             |  .----` |  .----` |         |
                             | /       | /       |         |
                            (31)------(32)------(33)------(34)
                             |        /| \       | \       | \
                             |  .----` |  `----. |  `----. |  `----.
                             | /       |        \|        \|        \
                   .--------(41)      (42)      (43)------(44)------(45)
                  /         /         /| \       | \
            .----`    .----`    .----` |  `----. |  `----.
           /         /         /       |        \|        \
        (51)------(52)------(53)------(54)------(55)------(56)

   Note that the links depicted represent the usable L2 connectivity
   available in the LLN.  For example, Node (31) can communicate
   directly with its neighbors, Nodes (21), (22), (32), and (41).  Node
   (31) cannot communicate directly with any other nodes, e.g. (33),
   (23), (42).  In this example these links offer bidirectional
   communication, and `bad' links are not depicted.

                      Figure 11: 13: Example LLN Topology
                                     (LBR)
                                     / | \
                                .---`  |  `----.
                               /       |        \
                            (11)      (12)      (13)
                             | \       | \       | \
                             |  `----. |  `----. |  `----.
                             |        \|        \|        \
                            (21)      (22)      (23)      (24)
                             |        /|        /|         |
                             |  .----` |  .----` |         |
                             | /       | /       |         |
                            (31)      (32)      (33)      (34)
                             |        /| \       | \       | \
                             |  .----` |  `----. |  `----. |  `----.
                             | /       |        \|        \|        \
                   .--------(41)      (42)      (43)      (44)      (45)
                  /         /         /| \       | \
            .----`    .----`    .----` |  `----. |  `----.
           /         /         /       |        \|        \
        (51)      (52)      (53)      (54)      (55)      (56)

   Note that the links depicted represent directed links in the DAG
   overlaid on top of the physical topology depicted in Figure 11. 13.  As
   such, the depicted edges represent the relationship between nodes and
   their DAG parents, wherein all depicted edges are directed and
   oriented `up' on the page toward the DAG root (LBR).  The DAG may
   provide default routes within the LLN, and serves as the foundation
   on which RPL builds further routing structure, e.g. through the
   destination advertisement mechanism.

                          Figure 12: 14: Example DAG

B.1.  Destination Advertisement

   Consider the example DAG depicted in Figure 12. 14.  Suppose that Nodes
   (22) and (32) are unable to record routing state.  Suppose that Node
   (42) is able to perform prefix aggregation on behalf of Nodes (53),
   (54), and (55).

   o  Node (53) would send a DAO message to Node (42), indicating the
      availability of destination (53).

   o  Node (54) and Node (55) would similarly send DAO messages to Node
      (42) indicating their own destinations.

   o  Node (42) would collect and store the routing state for
      destinations (53), (54), and (55).

   o  In this example, Node (42) may then be capable of representing
      destinations (42), (53), (54), and (55) in the aggregation (42').

   o  Node (42) sends a DAO message advertising destination (42') to
      Node 32.

   o  Node (32) does not want to maintain any routing state, so it adds
      onto to the Reverse Route Stack in the DAO message and passes it
      on to Node (22) as (42'):[(42)].  It may send a separate DAO
      message to indicate destination (32).

   o  Node (22) does not want to maintain any routing state, so it adds
      on to the Reverse Route Stack in the DAO message and passes it on
      to Node (12) as (42'):[(42), (32)].  It also relays the DAO
      message containing destination (32) to Node 12 as (32):[(32)], and
      finally may send a DAO message for itself indicating destination
      (22).

   o  Node (12) is capable to maintain routing state again, and receives
      the DAO messages from Node (22).  Node (12) then learns:
      *  Destination (22) is available via Node (22)
      *  Destination (32) is available via Node (22) and the piecewise
         source route to (32)
      *  Destination (42') is available via Node (22) and the piecewise
         source route to (32), (42').

   o  Node (12) sends DAO messages to (LBR), allowing (LBR) to learn
      routes to the destinations (12), (22), (32), and (42'). (42),
      (53), (54), and (55) are available via the aggregation (42').  It
      is not necessary for Node (12) to propagate the piecewise source
      routes to (LBR).

B.2.  Example: DAG Parent Selection

   For example, suppose that a node (N) is not attached to any DAG, and
   that it is in range of nodes (A), (B), (C), (D), and (E).  Let all
   nodes be configured to use an OCP which defines a policy such that
   ETX is to be minimized and paths with the attribute `Blue' should be
   avoided.  Let the rank computation indicated by the OCP simply
   reflect the ETX aggregated along the path.  Let the links between
   node (N) and its neighbors (A-E) all have an ETX of 1 (which is
   learned by node (N) through some implementation specific method).
   Let node (N) be configured to send RPL DIS messages to probe for
   nearby DAGs.

   o  Node (N) transmits a RPL DIS message.

   o  Node (B) responds.  Node (N) investigates the DIO message, and
      learns that Node (B) is a member of DAGID 1 at rank 4, and not
      `Blue'.  Node (N) takes note of this, but is not yet confident.

   o  Similarly, Node (N) hears from Node (A) at rank 9, Node (C) at
      rank 5, and Node (E) at rank 4.

   o  Node (D) responds.  Node (D) has a DIO message that indicates that
      it is a member of DAGID 1 at rank 2, but it carries the attribute
      `Blue'.  Node (N)'s policy function rejects Node (D), and no
      further consideration is given.

   o  This process continues until Node (N), based on implementation
      specific policy, builds up enough confidence to trigger a decision to
      join DAGID 1.  Let Node (N) determine its most preferred parent to
      be Node (E).

   o  Node (N) adds Node (E) (rank 4) to its set of DAG parents for
      DAGID 1.  Following the mechanisms specified by the OCP, and given
      that the ETX is 1 for the link between (N) and (E), Node (N) is
      now at rank 5 in DAGID 1.

   o  Node (N) adds Node (B) (rank 4) to its set of DAG parents for
      DAGID 1.

   o  Node (N) is a sibling of Node (C), both are at rank 5.

   o  Node (N) may now forward traffic intended for the default
      destination inward upwards along DAGID 1 via nodes (B) and (E).  In some
      cases, e.g. if nodes (B) and (E) are tried and fail, node (N) may
      also choose to forward traffic to its sibling node (C), without
      making inward upwards progress but with the intention that node (C) or a
      following successor can make inward upwards progress.  Should Node (C)
      not have a viable parent, it should never send the packet back to
      Node (N) (to avoid a 2-node loop).

B.3.  Example: DAG Maintenance

          :                      :                      :
          :                      :                      :
         (A)                    (A)                    (A)
          |\                     |                      |
          | `-----.              |                      |
          |        \             |                      |
         (B)       (C)          (B)       (C)          (B)
                    |                      |             \
                    |                      |              `-----.
                    |                      |                     \
                   (D)                    (D)                    (C)
                                                                  |
                                                                  |
                                                                  |
                                                                 (D)

              -1-                    -2-                    -3-

                        Figure 13: 15: DAG Maintenance

   Consider the example depicted in Figure 13-1. 15-1.  In this example, Node
   (A) is attached to a DAG at some rank d.  Node (A) is a DAG parent of
   Nodes (B) and (C).  Node (C) is a DAG parent of Node (D).  There is
   also an undirected sibling link between Nodes (B) and (C).

   In this example, Node (C) may safely forward to Node (A) without
   creating a loop.  Node (C) may not safely forward to Node (D),
   contained within it's own sub-DAG, without creating a loop.  Node (C)
   may forward to Node (B) in some cases, e.g. the link (C)->(A) is
   temporarily unavailable, but with some chance of creating a loop
   (e.g. if multiple nodes in a set of siblings start forwarding
   `sideways' in a cycle) and requiring the intervention of additional
   mechanisms to detect and break the loop.

   Consider the case where Node (C) hears a DIO message from a Node (Z)
   at a lesser rank and superior position in the DAG than node (A).
   Node (C) may safely undergo the process to evict node (A) from its
   DAG parent set and attach directly to Node (Z) without creating a
   loop, because its rank will decrease.

   Now consider the case where the link (C)->(A) becomes nonviable, and
   node (C) must move to a deeper rank within the DAG:

   o  Node (C) must first detach from the DAG by removing Node (A) from
      its DAG parent set, leaving an empty DAG parent set.  Node (C) may
      become the root of its own floating, less preferred, DAG.

   o  Node (D), hearing a modified DIO message from Node (C), follows
      Node (C) into the floating DAG.  This is depicted in Figure 13-2. 15-2.
      In general, any node with no other options in the sub-DAG of Node
      (C) will follow Node (C) into the floating DAG, maintaining the
      structure of the sub-DAG.

   o  Node (C) hears a DIO message with an incremented DAGSequenceNumber
      from Node (B) and determines it is able to rejoin the grounded DAG
      by reattaching at a deeper rank to Node (B).  Node (C) adds Node
      (B) to its DAG parent set.  Node (C) has now safely moved deeper
      within the grounded DAG without creating any loops.

   o  Node (D), and any other sub-DAG of Node (C), will hear the
      modified DIO message sourced from Node (C) and follow Node (C) in
      a coordinated manner to reattach to the grounded DAG.  The final
      DAG is depicted in Figure 13-3 15-3

B.4.  Example: Greedy Parent Selection and Instability

         (A)                    (A)                    (A)
          |\                     |\                     |\
          | `-----.              | `-----.              | `-----.
          |        \             |        \             |        \
         (B)       (C)          (B)        \            |        (C)
                                  \        |            |        /
                                   `-----. |            | .-----`
                                          \|            |/
                                          (C)          (B)

              -1-                    -2-                    -3-

                  Figure 14: 16: Greedy DAG Parent Selection

   Consider the example depicted in Figure 14. 16.  A DAG is depicted in 3
   different configurations.  A usable link between (B) and (C) exists
   in all 3 configurations.  In Figure 14-1, 16-1, Node (A) is a DAG parent
   for Nodes (B) and (C), and (B)--(C) is a sibling link.  In
   Figure 14-2, 16-2, Node (A) is a DAG parent for Nodes (B) and (C), and Node
   (B) is also a DAG parent for Node (C).  In Figure 14-3, 16-3, Node (A) is a
   DAG parent for Nodes (B) and (C), and Node (C) is also a DAG parent
   for Node (B).

   If a RPL node is too greedy, in that it attempts to optimize for an
   additional number of parents beyond its preferred parent, then an
   instability can result.  Consider the DAG illustrated in Figure 14-1. 16-1.
   In this example, Nodes (B) and (C) may most prefer Node (A) as a DAG
   parent, but are operating under the greedy condition that will try to
   optimize for 2 parents.

   When the preferred parent selection causes a node to have only one
   parent and no siblings, the node may decide to insert itself at a
   slightly higher rank in order to have at least one sibling and thus
   an alternate forwarding solution.  This does not deprive other nodes
   of a forwarding solution and this is considered acceptable
   greediness.

   o  Let Figure 14-1 16-1 be the initial condition.

   o  Suppose Node (C) first is able to leave the DAG and rejoin at a
      lower rank, taking both Nodes (A) and (B) as DAG parents as
      depicted in Figure 14-2. 16-2.  Now Node (C) is deeper than both Nodes
      (A) and (B), and Node (C) is satisfied to have 2 DAG parents.

   o  Suppose Node (B), in its greediness, is willing to receive and
      process a DIO message from Node (C) (against the rules of RPL),
      and then Node (B) leaves the DAG and rejoins at a lower rank,
      taking both Nodes (A) and (C) as DAG parents.  Now Node (B) is
      deeper than both Nodes (A) and (C) and is satisfied with 2 DAG
      parents.

   o  Then Node (C), because it is also greedy, will leave and rejoin
      deeper, to again get 2 parents and have a lower rank then both of
      them.

   o  Next Node (B) will again leave and rejoin deeper, to again get 2
      parents

   o  And again Node (C) leaves and rejoins deeper...

   o  The process will repeat, and the DAG will oscillate between
      Figure 14-2 16-2 and Figure 14-3 16-3 until the nodes count to infinity and
      restart the cycle again.

   o  This cycle can be averted through mechanisms in RPL:

      *  Nodes (B) and (C) stay at a rank sufficient to attach to their
         most preferred parent (A) and don't go for any deeper (worse)
         alternate parents (Nodes are not greedy)

      *  Nodes (B) and (C) do not process DIO messages from nodes deeper
         than themselves (because such nodes are possibly in their own
         sub-DAGs)

Appendix C.  Outstanding Issues

   This section enumerates some outstanding issues that are to be
   addressed in future revisions of the RPL specification.

C.1.  Additional Support for P2P Routing

   In some situations the baseline mechanism to support arbitrary P2P
   traffic, by flowing inward upwards along the DAG until a common parent ancestor is
   reached and then flowing outward, down, may not be suitable for all
   application scenarios.  A related scenario may occur when the outward down
   paths setup along the DAG by the destination advertisement mechanism
   are not be the most desirable outward downward paths for the specific
   application scenario (in part because the DAG links may not be
   symmetric).  It may be desired to support within RPL the discovery
   and installation of more direct routes `across' the DAG.  Such
   mechanisms need to be investigated.

C.2.  Loop Detection

   It is under investigation to complement the loop avoidance strategies
   provided by RPL with a loop detection mechanism that may be employed
   when traffic is forwarded.

C.3.  Destination Advertisement / DAO Fan-out

   When DAO messages are relayed to more than one DAG parent, in some
   cases a situation may be created where a large number of DAO messages
   conveying information about the same destination flow inward upwards along
   the DAG.  It is desirable to bound/limit the multiplication/fan-out
   of DAO messages in this manner.  Some aspects of the Destination
   Advertisement mechanism remain under investigation, such as behavior
   in the face of links that may not be symmetric.

   In general, the utility of providing redundancy along outwards downwards
   routes by sending DAO messages to more than one parent is under
   investigation.

   The use of suitable triggers, such as the `D' bit, to trigger DA
   operation within an affected sub-DAG, is under investigation.
   Further, the ability to limit scope of the affected depth within the
   sub-DAG is under investigation (e.g. if a stateful node can proxy for
   all nodes `behind' it, then there may be no need to propagate the
   triggered `D' bit further).

C.4.  Source Routing

   In support of nodes that maintain minimal routing state, and to make
   use of the collection of piecewise source routes from the destination
   advertisement mechanism, there needs to be some investigation of a
   mechanism to specify, attach, and follow source routes for packets
   traversing the LLN.

C.5.  Address / Header Compression

   In order to minimize overhead within the LLN it is desirable to
   perform some sort of address and/or header compression, perhaps via
   labels, addresses aggregation, or some other means.  This is still
   under investigation.

Authors' Addresses

   Tim Winter (editor)

   Email: wintert@acm.org

   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

   ROLL Design Team
   IETF ROLL WG

   Email: rpl-authors@external.cisco.com