One document matched: draft-ietf-roll-minrank-hysteresis-of-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>

<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>
<rfc category="std" docName="draft-ietf-roll-minrank-hysteresis-of-00" ipr="trust200902">

  <front>
    <title abbrev="draft-ietf-roll-minrank-hysteresis-of">The Minimum Rank Objective Function with Hysteresis</title>
    <author fullname="Omprakash Gnawali" initials="O.G." surname="Gnawali">
      <organization>Stanford University</organization>
      <address>
        <postal>
          <street>S255 Clark Center, 318 Campus Drive</street>
          <city>Stanford</city>
          <region>CA</region>
          <code>94305</code>
          <country>USA</country>
        </postal>
        <phone>+1 650 725 6086</phone>
        <email>gnawali@cs.stanford.edu</email>
      </address>
    </author>

    <author fullname="Philip Levis" initials="P.L." surname="Levis">
      <organization>Stanford University</organization>
      <address>
        <postal>
          <street>358 Gates Hall, Stanford University</street>
          <city>Stanford</city>
          <region>CA</region>
          <code>94305</code>
          <country>USA</country>
        </postal>
        <email>pal@cs.stanford.edu</email>
      </address>
    </author>

    <date day="11" month="October" year="2010" />
    <area>Routing Area</area>
    <workgroup>Networking Working Group</workgroup>
    <keyword>Draft</keyword>

    <abstract>
      <t>Hysteresis delays the effect of changes in link metric on
	parent selection. Such delay makes the topology stable despite
	jitters in link metrics. The Routing Protocol for Low Power
	and Lossy Networks (RPL) allows the use of objective functions
	to construct routes that optimize or constrain a routing
	metric on the paths. This specification describes the Minimum
	Rank Objective Function with Hysteresis (MRHOF), an objective
	function that minimizes the node rank in terms of a given
	metric, while using hysteresis to prevent excessive rank
	churn. The use of MRHOF with RPL results in nodes selecting
	stable paths that minimize the given routing metric to the
	roots of a Directed Acyclic Graph (DAG).</t>
    </abstract>

  </front>

  <middle>

    <section title="Introduction">

      <t>An objective function allows
      RPL <xref target="I-D.ietf-roll-rpl"></xref> to select paths
      that are best in terms of a given routing metric or select paths
      that meet certain constraints in terms of the routing
      metric. RPL achieves this goal by selecting the parent among the
      alternate parents as dictated by that objective function. For
      example, if an RPL instance uses an objective function that
      minimizes hop-count, RPL will select paths with minimum hop
      count.</t>

      <t>The nodes running RPL might use a number of metrics to
      describe a link or a
      node <xref target="I-D.ietf-roll-routing-metrics"></xref> and
      make it available for route selection. A metric can be used by
      different objective functions to optimize or constrain the
      metric in different ways.</t>

      <t>This specification describes MRHOF, an objective function for
      RPL. MRHOF uses hysteresis while selecting the path with the
      smallest metric value. The path with the minimum cost has
      different property depending on the metric used for path
      selection. 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 DAG instance. The use of MRHOF with the ETX
      metric allows RPL to find the stable minimum-ETX paths from the
      nodes to a root in the DAG instance.</t>

      <t>MRHOF can be used with additive metric that must be minimized
      on the paths selected for routing. Although MRHOF can be used
      with a number of metrics, this draft is based on experiences
      with the ETX metric.</t>

    </section>

    <section title="Terminology">

      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>

      <t>This terminology used in this document is consistent with the
      terminologies described
      in <xref target="I-D.ietf-roll-terminology"></xref>, <xref target="I-D.ietf-roll-rpl"></xref>,
      and <xref target="I-D.ietf-roll-routing-metrics"></xref>.</t>

      <t>This document introduces two terms:</t>

      <t><list hangIndent="6" style="hanging">
          <t hangText="Selected metric:">The metric chosen by the
          network operator to use for path selection. This metric can
          be any additive metric listed
          in <xref target="I-D.ietf-roll-routing-metrics"></xref></t>
	</list></t>

      <t><list hangIndent="6" style="hanging">
          <t hangText="Path cost:">Path cost quantifies a property
            of an end-to-end path. Path cost is composed using the
            selected metric of the links along the path. Path
            cost can be used by RPL to compare different paths.</t>
	</list></t>

    </section>


    <section title="The Minimum Rank Objective Function with Hysteresis">

      <t>The Minimum Rank Objective Function with Hysteresis, MRHOF,
      is designed to find the paths with the smallest path cost
      while preventing excessive churn in the network. It does so by
      switching to the minimum cost path only if the path cost of
      the current path is larger than the path cost of the minimum
      cost path by a given threshold. MRHOF may be used with any
      additive metric listed
      in <xref target="I-D.ietf-roll-routing-metrics"></xref> as long
      the routing objective is to minimize the given routing
      metric. MRHOF cannot be used if the routing objective is to
      maximize the metric.</t>

      <section title="Computing the Path cost">
	
	<t>Nodes compute the path cost for each candidate neighbor
	  reachable on all the interfaces. The Path cost represents
	  the cost of the path, in terms of the selected metric,
	  from a node to the root of the DODAG through the
	  neighbor. </t>
	
	<t>Root nodes (Grounded or Floating) set the variable
	  cur_min_path_cost to MIN_PATH_COST.</t>
	
	<t>A non-root node computes the path cost for a path to the
	  root through each candidate neighbor by adding these two
	  components:</t>

	<t><list style="numbers">
	    <t> The selected metric for the link to a candidate neighbor.</t>
	    <t> The value of the selected metric in the metric container
	    in the DIO sent by that neighbor.</t>
	  </list></t>

	  <t>A node SHOULD compute the path cost for the path through
	  each candidate neighbor reachable through all the
	  interfaces. 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 with one
	  exception. If the node does not have metrics to compute the
	  path cost through any of the candidate neighbors, it SHOULD
	  join one of the candidate neighbors as a leaf node.</t>

	  <t>If the selected 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.</t>


	<t>The path cost corresponding to a neighbor SHOULD be
	re-computed each time:</t>

	<t><list style="numbers">
	  <t>The selected metric of the link to the candidate neighbor is
	  updated.</t>
	  <t>A node receives a new metric advertisement from the
	  candidate neighbor.</t>
	</list></t>

	<t>This computation MAY also be performed
	periodically. However, long intervals between periodic
	computation or deferring the computation for too long after
	new metric advertisements or updates to the selected
	link metric prevents results in node making parent selection based
	on stale link and path information.</t>


      </section>

      <section title="Parent Selection">

	<t>After computing the path cost for all the candidate
	neighbors reachable through all the interfaces for the current
	DODAG iteration, a node selects the preferred parent. This
	process is called parent selection.</t>

	<t>A node MUST select a candidate neighbor as its preferred
	parent if the path cost corresponding to that neighbor
	is smaller than the path cost corresponding to the rest
	of the neighbors, except as indicated below:</t>

	<t><list style="numbers">

	  <t>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.</t>

	  <t>If there are multiple paths with the smallest path cost
	    and that the smallest path cost is smaller than
	    cur_min_path_cost by at least PARENT_SWITCH_THRESHOLD, a
	    node MAY use a different objective function to select the
	    preferred parent among the candidates which are first hop
	    on the path with the minimum cost.</t>

	  <t>A node MAY declare itself as a Floating root, and hence
	    no preferred parent, depending on the configuration.</t>

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

	  <t>If cur_min_path_cost is greater than MAX_PATH_COST,
	    the node MAY declare itself as a Floating root.</t>

	  <t>If the configuration disallows a node to be a Floating
	    root and no neighbors are discovered, the node does not have
	    a preferred parent, and MUST set cur_min_path_cost to
	    MAX_PATH_COST.</t>


	</list></t>

      </section>

      <section title="Computing Rank">
	<t>Once a node selects its preferred parent, it can use the
	  following table to covert its path cost to the DAG root
	  through its preferred parent (written as Cost in the table)
	  to its rank:</t>

	<texttable anchor="costrank" title="Conversion of metric to rank.">
	    <ttcol align='center'>Node/link Metric</ttcol>
	    <ttcol align='center'>Rank</ttcol>
	    <c>Node Energy</c><c>255 - Cost</c>
	    <c>Hop-Count</c><c>Cost</c>
	    <c>Latency</c><c>Cost/65536</c>
	    <c>Link Quality Level</c><c>Cost</c>
	    <c>ETX</c><c>Cost</c>
	  </texttable>

	    <t>Node rank is undefined for these node/link metrics:
	    Node state and attributes, node fanout ratio, throughput,
	    and link color.</t>

      </section>

      <section title="Advertising the path cost">
	<t>Once the preferred parent is selected, the node sets its
	cur_min_path_cost variable to the path cost corresponding to
	the preferred parent. Thus, cur_min_path_cost is the cost of the
	minimum cost path from the node to the
	root. The value of the cur_min_path_cost is carried in the
	metric container whenever DIO messages are sent.</t>
      </section>

    </section>

    <section title="MRHOF Variables and Parameters">
      
      <t>MRHOF uses the following variable:</t>

      <t><list>
	<t>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.</t>
      </list></t>


      <t>MRHOF uses the following parameters:</t>

      <t><list>
	<t>MAX_LINK_METRIC: Maximum allowed value for the
	selected link metric for each link on the path.</t>

	<t>MAX_PATH_COST: Maximum allowed value for the path
	metric of a selected path.</t>

	<t>MIN_PATH_COST: The minimum allowed value for the
	path metric of the selected path.</t>

	<t>PARENT_SWITCH_THRESHOLD: The difference between metric of
	   the path through the preferred parent and the minimum-metric
	   path to trigger new preferred parent selection.</t>
	
      </list></t>

	<t>The parameter values are assigned depending on the selected
	metric. Here is an example parameter assignment for the ETX
	metric:</t>

	<t><list>

	    <t>MAX_LINK_METRIC: 10. Disallow links with greater
	    than 10 expected transmission count on the selected
	    path.</t>

	    <t>MAX_PATH_COST: 100. Disallow paths with greater
	    than 100 expected transmission count.</t>

	    <t>MIN_PATH_COST: 0. At root, the expected
	    transmission count is 0.</t>

	    <t>PARENT_SWITCH_THRESHOLD: 1.0. Switch to a new
	    path only if it is requires at least one fewer
	    transmission than the current path.</t>
	    </list></t>

    </section>



    <section anchor="Acknowledgements" title="Acknowledgements">
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This specification requires an allocated OCP. A value of 1 is requested.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Security considerations to be developed in accordance to the output of the WG.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.draft-ietf-roll-rpl-05.xml'?>
      <?rfc include='reference.I-D.draft-ietf-roll-routing-metrics-01.xml'?>
      <?rfc include='reference.I-D.draft-ietf-roll-terminology-01.xml'?>
    </references>

  </back>
</rfc>