[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-gnawali-roll-minrank-hysteresis-of) 00 01 02 03 04 05 06 07 08 09 10 11 RFC 6719

Networking Working Group                                      O. Gnawali
Internet-Draft                                     University of Houston
Intended status: Standards Track                                P. Levis
Expires: December 31, 2012                           Stanford University
                                                           June 29, 2012


          The Minimum Rank with Hysteresis Objective Function
                draft-ietf-roll-minrank-hysteresis-of-11

Abstract

   The Routing Protocol for Low Power and Lossy Networks (RPL) uses
   objective functions to construct routes that optimize or constrain
   the routes it selects and uses.  This specification describes the
   Minimum Rank with Hysteresis Objective Function (MRHOF), an objective
   function that selects routes that minimize a metric, while using
   hysteresis to reduce churn in response to small metric changes.
   MRHOF works with metrics that are additive along a route, and the
   metric it uses is determined by the metrics RPL Destination
   Information Object (DIO) messages advertise.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on December 31, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Gnawali & Levis         Expires December 31, 2012               [Page 1]

Internet-Draft    draft-ietf-roll-minrank-hysteresis-of        June 2012


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  The Minimum Rank with Hysteresis Objective Function  . . . . .  4
     3.1.  Computing the Path cost  . . . . . . . . . . . . . . . . .  4
     3.2.  Parent Selection . . . . . . . . . . . . . . . . . . . . .  6
       3.2.1.  When Parent Selection Runs . . . . . . . . . . . . . .  6
       3.2.2.  Parent Selection Algorithm . . . . . . . . . . . . . .  6
     3.3.  Computing Rank . . . . . . . . . . . . . . . . . . . . . .  7
     3.4.  Advertising the Path Cost  . . . . . . . . . . . . . . . .  8
     3.5.  Working Without Metric Containers  . . . . . . . . . . . .  9
   4.  Using MRHOF for Metric Maximization  . . . . . . . . . . . . .  9
   5.  MRHOF Variables and Parameters . . . . . . . . . . . . . . . .  9
   6.  Manageability  . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.1.  Device Configuration . . . . . . . . . . . . . . . . . . . 11
     6.2.  Device Monitoring  . . . . . . . . . . . . . . . . . . . . 11
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13




















Gnawali & Levis         Expires December 31, 2012               [Page 2]

Internet-Draft    draft-ietf-roll-minrank-hysteresis-of        June 2012


1.  Introduction

   An objective function specifies how RPL [RFC6550] selects paths.  For
   example, if an RPL instance uses an objective function that minimizes
   hop-count, RPL will select paths with minimum hop count.  RPL
   requires that all nodes in a network use a common Objective Function
   (OF); relaxing this requirement may be a subject of future study.

   The nodes running RPL might use a number of metrics to describe a
   link or a node [RFC6551] and make these metrics available for route
   selection.  RPL advertises metrics in RPL Destination Information
   Object (DIO) messages with a Metric Container suboption.  An
   objective function can use these metrics to choose routes.

   To decouple the details of an individual metric or objective function
   from forwarding and routing, RPL describes routes through a value
   called Rank.  Rank, roughly speaking, corresponds to the distance
   associated with a route.  RPL defines how nodes decide on paths based
   on Rank and advertise their Rank.  An objective function defines how
   nodes calculate Rank, based on the Rank of its potential parents,
   metrics, and other network properties.

   This specification describes Minimum Rank with Hysteresis Objective
   Function (MRHOF), an objective function for RPL.  MRHOF uses
   hysteresis while selecting the path with the smallest metric value.
   The metric that MRHOF uses is determined by the metrics in the DIO
   Metric Container.  For example, the use of MRHOF with the latency
   metric allows RPL to find stable minimum-latency paths from the nodes
   to a root in the Directed Acyclic Graph (DAG) instance [RFC6550].
   The use of MRHOF with the Expected Transmission Count (ETX)
   metric[RFC6551] allows RPL to find the stable minimum-ETX paths from
   the nodes to a root in the DAG instance.  In the absence of a metric
   in the DIO Metric Container or the lack of a DIO Metric Container,
   MRHOF defaults to using ETX to compute Rank, as described in
   Section 3.5.

   Because MRHOF seeks to minimize path costs as described by metrics,
   it can only be used with additive metrics.  MRHOF does not support
   metrics that are not additive.


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




Gnawali & Levis         Expires December 31, 2012               [Page 3]

Internet-Draft    draft-ietf-roll-minrank-hysteresis-of        June 2012


   The terminologies used in this document are consistent with the
   terminologies described in [I-D.ietf-roll-terminology] and [RFC6551].

   The terminologies used in this document are also consistent with the
   terminologies described in [RFC6550], except the term Rank.  In this
   document, Rank refers to the value of the Rank field, not DAGRank as
   in [RFC6550].

   This document introduces three terms:

   Selected metric:  The metric chosen by the network operator to use
         for path selection.  MRHOF supports using a single metric for
         path selection.  The decision to use a metric (other than ETX)
         as the selected metric is indicated by the presence of the
         chosen metric in the DIO metric container.  The selection of
         the ETX metric is indicated by the absence of the metric
         container.

   Path cost:  Path cost quantifies a property of an end-to-end path.
         Path cost is obtained by each node summing up the selected link
         metric to the path cost advertised by the parent.  Path cost
         can be used by RPL to compare different paths.

   Worst parent:  The node in the parent set with the largest path cost.


3.  The Minimum Rank with Hysteresis Objective Function

   The Minimum Rank with Hysteresis Objective Function, MRHOF, is
   designed to find the paths with the smallest path cost while
   preventing excessive churn in the network.  It does so by using two
   mechanisms.  First, it finds the minimum cost path, i.e., path with
   the minimum Rank.  Second, it switches to that minimum Rank path only
   if it is shorter (in terms of path cost) than the current path by at
   least a given threshold.  This second mechanism is called hysteresis.

   MRHOF may be used with any additive metric listed in [RFC6551] as
   long the routing objective is to minimize the given routing metric.
   Nodes MUST support at least one of these metrics:hop count, latency,
   and ETX.  Nodes SHOULD support the ETX metric.  MRHOF does not
   support non-additive metrics.

3.1.  Computing the Path cost

   Root nodes (Grounded or Floating) set the variable cur_min_path_cost
   to the metric value that most closely computes to a Rank of
   MinHopRankIncrease.




Gnawali & Levis         Expires December 31, 2012               [Page 4]

Internet-Draft    draft-ietf-roll-minrank-hysteresis-of        June 2012


   If a non-root node does not have metrics to compute the path cost
   through any of the candidate neighbors, it MUST join one of the
   candidate neighbors as a RPL Leaf.

   Otherwise, nodes compute the path cost for each candidate neighbor
   reachable on an interface.  The path cost of a neighbor represents
   the cost of the path, in terms of the selected metric, from a node to
   the root of the DODAG through that neighbor.  A non-root node
   computes a neighbor's path cost by adding two components:

   1.  If the selected metric is a link metric, the selected metric for
       the link to a candidate neighbor.  If the selected metric is a
       node metric, the selected metric for the node.

   2.  The value of the selected metric in the metric container in the
       DIO sent by that neighbor.

   A node SHOULD compute the path cost for the path through each
   candidate neighbor reachable through an interface.  If a node cannot
   compute the path cost for the path through a candidate neighbor, the
   node MUST NOT select the candidate neighbor as its preferred parent,
   except if it cannot compute the path cost through any neighbor, in
   which case it may join as a leaf as described above.

   If the selected metric is a link metric and the metric of the link to
   a neighbor is not available, the path cost for the path through that
   neighbor SHOULD be set to MAX_PATH_COST.  This cost value will
   prevent this path from being considered for path selection.

   If the selected metric is a node metric, and the metric is not
   available, the path cost through all the neighbors SHOULD be set to
   MAX_PATH_COST.

   The path cost corresponding to a neighbor SHOULD be re-computed each
   time any of the following conditions are met:

   1.  The selected metric of the link to the candidate neighbor is
       updated.

   2.  If the selected metric is a node metric and the metric is
       updated.

   3.  A node receives a new metric advertisement from the candidate
       neighbor.

   This computation SHOULD also be performed periodically.  While it is
   harmless to delay this computation up to minimum Trickle interval
   [RFC6550], longer delays in updating the path cost after the metric



Gnawali & Levis         Expires December 31, 2012               [Page 5]

Internet-Draft    draft-ietf-roll-minrank-hysteresis-of        June 2012


   is updated or a new metric advertisement is received can lead to
   stale information.

3.2.  Parent Selection

   After computing the path cost for all the candidate neighbors
   reachable through an interface for the current Destination Oriented
   DAG iteration (DODAG) [RFC6550], a node selects the preferred parent.
   This process is called parent selection.  To allow hysteresis, parent
   selection maintains a variable, cur_min_path_cost, which is the path
   cost of the current preferred parent.

3.2.1.  When Parent Selection Runs

   A MRHOF implementation SHOULD perform Parent Selection each time:

   1.  The path cost for an existing candidate neighbor, including the
       preferred parent, changes.  This condition can be checked
       immediately after the path cost is computed.

   2.  A new candidate neighbor is inserted into the neighbor table.

   If, despite the above, it is necessary to defer the parent selection
   until a later time (e.g., up to Trickle minimum interval [RFC6550]),
   note that doing so can delay the use of better paths available in the
   network.

3.2.2.  Parent Selection Algorithm

   If the selected metric for a link is greater than MAX_LINK_METRIC,
   the node SHOULD exclude that link from consideration during parent
   selection.

   A node MUST select the candidate neighbor with the lowest path cost
   as its preferred parent, except as indicated below:

   1.  A node MAY declare itself as a Floating root, and hence have no
       preferred parent, depending on system configuration.

   2.  If cur_min_path_cost is greater than MAX_PATH_COST, the node MAY
       declare itself as a Floating root.

   3.  If the smallest path cost for paths through the candidate
       neighbors is smaller than cur_min_path_cost by less than
       PARENT_SWITCH_THRESHOLD, the node MAY continue to use the current
       preferred parent.  This is the hysteresis component of MRHOF.





Gnawali & Levis         Expires December 31, 2012               [Page 6]

Internet-Draft    draft-ietf-roll-minrank-hysteresis-of        June 2012


   4.  If ALLOW_FLOATING_ROOT is 0 and no neighbors are discovered, the
       node does not have a preferred parent, and MUST set
       cur_min_path_cost to MAX_PATH_COST.

   If there are multiple neighbors which share the smallest path cost, a
   node MAY use a different selection criteria to select which of these
   neighbors should be considered to have the lowest cost.

   A node MAY include up to PARENT_SET_SIZE-1 additional candidate
   neighbors in its parent set.  The cost of path through the nodes in
   the parent set is smaller than or equal to the cost of the paths
   through any of the nodes that are not in the parent set.  If the cost
   of the path through the preferred parent and the worst parent is too
   large, a node MAY keep a smaller parent set than PARENT_SET_SIZE.

   Once the preferred parent is selected, the node sets its
   cur_min_path_cost variable to the path cost corresponding to the
   preferred parent.  The value of the cur_min_path_cost is carried in
   the metric container corresponding to the selected metric when DIO
   messages are sent.

3.3.  Computing Rank

   DAG roots set their Rank to MinHopRankIncrease.

   Once a non-root node selects its parent set, it can use the following
   table to covert the path cost of a parent (written as Cost in the
   table) to a Rank value:

                     +------------------+------------+
                     | Node/link Metric |    Rank    |
                     +------------------+------------+
                     |     Hop-Count    |    Cost    |
                     |      Latency     | Cost/65536 |
                     |        ETX       |    Cost    |
                     +------------------+------------+

                  Table 1: Conversion of metric to rank.

   Rank is undefined for these node/link metrics: node state and
   attributes, throughput, and link color.  If the rank is undefined,
   the node must join one of the neighbors as a RPL Leaf node according
   to [RFC6550].

   MRHOF uses this Rank value to compute the Rank it associates with the
   path through each member of the parent set.  The Rank associated with
   a path through a member of the parent set is the maximum of two
   values.  The first is corresponding Rank value calculated with the



Gnawali & Levis         Expires December 31, 2012               [Page 7]

Internet-Draft    draft-ietf-roll-minrank-hysteresis-of        June 2012


   table above, the second is that node's advertised Rank plus
   MinHopRankIncrease.

   A node sets its Rank to the maximum of three values:

   1.  The Rank calculated for the path through the preferred parent

   2.  The Rank of the member of the parent set with the highest
       advertised Rank, rounded to the next higher integral Rank, ie, to
       MinHopRankIncrease * (1 + floor(Rank/MinHopRankIncrease)).

   3.  The largest calculated Rank among paths through the parent set,
       minus MaxRankIncrease

   The first case is the Rank associated with the path through the
   preferred parent.  The second case covers requirement 5 of Rank
   advertisements in Section 8.2.1 of [RFC6550].  The third case ensures
   that a node does not advertise a Rank which then precludes it from
   using members of its parent set.

   Note that the third case means that a node advertises a conservative
   Rank value based on members of its parent set.  This conservative
   value might be significantly higher than the Rank calculated for the
   path through the preferred parent.  Accordingly, picking a parent set
   whose paths have a large range of Ranks will likely result in sub-
   optimal routing: nodes might not choose good paths because they are
   advertised as much worse than they actually are.  The exact selection
   of a parent set is an implementation decision.

3.4.  Advertising the Path Cost

   Once the preferred parent is selected, the node sets its
   cur_min_path_cost variable to the path cost corresponding to its
   preferred parent.  It then calculates the metric it will advertise in
   its metric container.  This value is the path cost of the member of
   the parent set with the highest path cost.  Thus, while
   cur_min_path_cost is the cost through the preferred parent, a node
   advertises the highest cost path from the node to the root through a
   member of the parent set.  The value of the highest cost path is
   carried in the metric container corresponding to the selected metric
   when DIO messages are sent.

   If ETX is the selected metric, a node SHOULD NOT advertise it in a
   metric container.  Instead, a node MUST advertise an approximation of
   its ETX in its advertised Rank value, following the rules described
   in Section 3.3.  If a node receives a DIO with a metric container
   holding an ETX metric, MRHOF MUST ignore the ETX metric value in its
   Rank calculations.



Gnawali & Levis         Expires December 31, 2012               [Page 8]

Internet-Draft    draft-ietf-roll-minrank-hysteresis-of        June 2012


   DODAG Roots advertise a metric value which mostly closely computes to
   a Rank value of MinHopRankIncrease.

3.5.  Working Without Metric Containers

   In the absence of metric container, MRHOF uses ETX as its metric.  It
   locally computes the ETX of links to its neighbors and adds this
   value to their advertised Rank to compute the associated Rank of
   routes.  Once parent selection and rank computation is performed
   using the ETX metric, the node advertises a Rank equal to the ETX
   cost and MUST NOT include a metric container in its DIO messages.


4.  Using MRHOF for Metric Maximization

   MRHOF cannot be directly used for parent selection using metrics
   which require finding paths with maximum value of the selected
   metric, such as path reliability.  It is possible to convert such a
   metric maximization problem to a metric minimization problem for some
   metrics and use MRHOF provided:

      There is a fixed and well-known maximum metric value corresponding
      to the best path.  This is the path cost for the DAG root.  For
      example, the logarithm of the best link reliability has a value of
      0.

      The metrics in the maximization problem are all negative.  The
      logarithm of the link reliability is always negative.

   For metrics meeting the above conditions, the problem of maximizing
   the metric value is equivalent to minimizing the modified metric
   value, e.g., logarithm of link reliability.  MRHOF is not required to
   work with these metrics.


5.  MRHOF Variables and Parameters

   MRHOF uses the following variable:

      cur_min_path_cost: The cost of the path from a node through its
      preferred parent to the root computed at the last parent
      selection.

   MRHOF uses the following parameters:

      MAX_LINK_METRIC: Maximum allowed value for the selected link
      metric for each link on the path.




Gnawali & Levis         Expires December 31, 2012               [Page 9]

Internet-Draft    draft-ietf-roll-minrank-hysteresis-of        June 2012


      MAX_PATH_COST: Maximum allowed value for the path metric of a
      selected path.

      PARENT_SWITCH_THRESHOLD: The difference between the cost of the
      path through the preferred parent and the minimum cost path in
      order to trigger the selection of a new preferred parent.

      PARENT_SET_SIZE: The number of candidate parents, including the
      preferred parent, in the parent set.

      ALLOW_FLOATING_ROOT: If set to 1, allows a node to become a
      floating root.

   The parameter values are assigned depending on the selected metric.
   The best values for these parameters are determined by the
   requirement of the specific RPL deployment.  For instance, if we use
   ETX as the selected metric and UDP as the transport protocol, we
   should use a small MAX_LINK_METRIC (e.g., ETX of 1.1) so that link
   layer retransmissions are sufficient to provide a good chance of end-
   to-end reliability.

   The working group has long experience routing with the ETX
   metric[Hui08b].  Based on those experiences, these values are
   RECOMMENDED:

      MAX_LINK_METRIC: 512.  Disallow links with greater than 4 expected
      transmission count on the selected path.

      MAX_PATH_COST: 32768.  Disallow paths with greater than 256
      expected transmission count.

      PARENT_SWITCH_THRESHOLD: 192.  Switch to a new path only if it is
      expected to require at least 1.5 fewer transmissions than the
      current path.

      PARENT_SET_SIZE: 3.  If the preferred parent is not available, two
      candidate parents are still available without triggering a new
      round of route discovery.

      ALLOW_FLOATING_ROOT: 0.  Do not allow a node to become a floating
      root.


6.  Manageability

   Section 18 of [RFC6550] depicts the management of RPL.  This
   specification inherits from that section and its subsections, with
   the exception that metrics as specified in [RFC6551] are not used and



Gnawali & Levis         Expires December 31, 2012              [Page 10]

Internet-Draft    draft-ietf-roll-minrank-hysteresis-of        June 2012


   do not require management.

6.1.  Device Configuration

   An implementation SHOULD allow the following parameters to be
   configured at installation time: MAX_LINK_METRIC, MAX_PATH_COST,
   PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and ALLOW_FLOATING_ROOT.
   An implementation MAY allow these parameters to be configured
   dynamically at run time once a network has been deployed.

   A MRHOF implementation MUST support the DODAG Configuration option as
   described in [RFC6550] and apply the parameters it specifies.  Care
   should be taken in the relationship between the MRHOF
   PARENT_SWITCH_THRESHOLD parameter and the RPL MaxRankIncrease
   parameter.  For example, if MaxRankIncrease is smaller than
   PARENT_SWITCH_THRESHOLD, a RPL node using MRHOF could enter a
   situation where its current preferred parent causes the nodes Rank to
   increase more than MaxRankIncrease but MRHOF does not change
   preferred parents: this could cause the node to leave the routing
   topology even though there may be other members of the parent set
   which would allow the node's Rank to remain within MaxRankIncrease.

   Unless configured otherwise, a MRHOF implementation SHOULD use the
   default parameters as specified in Section 5.

   Because of the partially-coupled relationship between Rank and metric
   values, networks using MRHOF require care in setting
   MinHopRankIncrease.  A large MinHopRankIncrease will cause MRHOF to
   be unable to select paths with different hop counts but similar
   metric values.  If MinHopRankIncrease is large enough that its
   increment is greater than that caused by link cost, then metrics will
   be used to select a preferred parent but the advertised Rank will be
   a simple hopcount.  This behavior might be desirable, but it also
   might be unintended: care is recommended.

   RPL's Rank advertisement rules can require a DODAG Root to advertise
   a Rank higher than its corresponding ETX value, as a DODAG Root
   advertises a Rank of MinHopRankIncrease.  Because all DODAG Roots
   within a DODAG Version advertise the same Rank, this constant value
   typically does not affect route selection.  Nevertheless, it means
   that if a DODAG Version has a MinHopRankIncrease of M and a path has
   an advertised ETX of E, then the actual ETX of the path is likely
   closer to a value of E-M than a value of E.

6.2.  Device Monitoring

   A MRHOF implementation should provide an interface for monitoring its
   operation.  At a minimum, the information provided should include:



Gnawali & Levis         Expires December 31, 2012              [Page 11]

Internet-Draft    draft-ietf-roll-minrank-hysteresis-of        June 2012


      DAG information as specified in Section 6.3.1 of [RFC6550], and
      including the DODAGID, the RPLInstanceID, the Mode of Operation,
      the Rank of this node, the current Version Number, and the value
      of the Grounded flag.

      A list of neighbors indicating the preferred parent.  The list
      should indicate, for each neighbor, the Rank, the current Version
      Number, the value of the Grounded flag, and associated metrics.


7.  Acknowledgements

   Thanks to Antonio Grilo, Nicolas Tsiftes, Matteo Paris, JP Vasseur,
   and Phoebus Chen for their comments.  Thanks to Barry Leiba, Brian
   Haberman, Martin Stiemerling, Ralph Droms, Robert Sparks, Russ
   Housley, Stephen Farrell, Wesley Eddy, Miguel A. Garcia, Mukul Goyal,
   and Michael Richardson for their feedback during the publication
   phase of this document.


8.  IANA Considerations

   This specification requires a value allocated from the "Objective
   Code Point (OCP)" sub-registry of the "Routing Protocol for Low Power
   and Lossy Networks (RPL)" registry.  A value of 1 is suggested.


9.  Security Considerations

   This specification makes simple extensions to RPL and so is
   vulnerable to and benefits from the security issues and mechanisms
   described in [RFC6550] and [I-D.ietf-roll-security-framework].  This
   document does not introduce new flows or new messages, thus requires
   no specific mitigation for new threats.

   MRHOF depends on information exchanged in a number RPL protocol
   elements.  If those elements were compromised, then an implementation
   of MRHOF might generate the wrong path for a packet, resulting in it
   being misrouted.  Therefore, deployments are RECOMMENDED to use RPL
   security mechanisms if there is a risk that routing information might
   be modified or spoofed.


10.  References







Gnawali & Levis         Expires December 31, 2012              [Page 12]

Internet-Draft    draft-ietf-roll-minrank-hysteresis-of        June 2012


10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6550]  Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
              Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
              Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
              Lossy Networks", RFC 6550, March 2012.

   [RFC6551]  Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D.
              Barthel, "Routing Metrics Used for Path Calculation in
              Low-Power and Lossy Networks", RFC 6551, March 2012.

10.2.  Informative References

   [Hui08b]   Hui, J. and D. Culler, "IP is dead, long live IP for
              wireless sensor networks", Proceedings of the 6th ACM
              Conference on Embedded Networked Systems SenSys 2008,
              November 2008,
              <http://portal.acm.org/citation.cfm?id=1460412.1460415>.

   [I-D.ietf-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-ietf-roll-security-framework-07
              (work in progress), January 2012.

   [I-D.ietf-roll-terminology]
              Vasseur, J., "Terminology in Low power And Lossy
              Networks", draft-ietf-roll-terminology-05 (work in
              progress), March 2011.


Authors' Addresses

   Omprakash Gnawali
   University of Houston
   PGH 577, University of Houston
   Houston, TX  77204
   USA

   Phone: +1 713 743 3356
   Email: gnawali@cs.uh.edu







Gnawali & Levis         Expires December 31, 2012              [Page 13]

Internet-Draft    draft-ietf-roll-minrank-hysteresis-of        June 2012


   Philip Levis
   Stanford University
   412 Gates Hall, Stanford University
   Stanford, CA  94305
   USA

   Email: pal@cs.stanford.edu












































Gnawali & Levis         Expires December 31, 2012              [Page 14]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/