<?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-gnawali-roll-minrank-hysteresis-of-00" ipr="trust200902">

  <front>
    <title abbrev="draft-gnawali-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="14" month="June" 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 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 DAG
	roots.</t>
    </abstract>

  </front>

  <middle>

    <section title="Introduction">

      <t>An objective function allows
      RPL <xref target="I-D.ietf-roll-rpl"></xref> to optimize or
      constrain the routing metric of a path. 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. Different objective functions
      optimize or constrain metrics differently.</t>

      <t>The nodes running RPL might use a number of metrics to
      describe a
      link <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 metric value
      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 term:</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 metric:">Path metric quantifies a property
            of an end-to-end path. Path metric is composed using the
            selected metric of the links along the path. Path
            metrics 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 metric values
      while preventing excessive churn in the network. It does so by
      switching to the minimum metric path only if the path metric of
      the current path is larger than the path metric of the minimum
      metric 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 metric">
	
	<t>Nodes compute the path metric for each candidate neighbor
	  reachable on all the interfaces. The Path metric 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_metric to MIN_PATH_METRIC.</t>
	
	<t>A non-root node computes the path metric 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 cur_min_path_metric advertised by that neighbor.</t>
	  </list></t>

	  <t>A node SHOULD compute the path metric for the path
	  through each candidate neighbor reachable through all
	  interfaces. If a node cannot compute the path metric for the
	  path through a candidate neighbor, the node MUST NOT make
	  that candidate neighbor its preferred parent.</t>

	  <t>If the selected metric of the link to a neighbor is not
	    available, the path metric for the path through that
	    neighbor SHOULD be set to MAX_PATH_METRIC. This
	    metric value will prevent this path from being considered
	    for path selection.</t>


	<t>The path metric corresponding to a neighbor MUST 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 cur_min_path_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 cur_min_path_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 metric 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 metric corresponding to that neighbor
	is smaller than the path metric corresponding to the rest
	of the neighbors, except as indicated below:</t>

	<t><list style="numbers">

	  <t>If the smallest path metric for paths through the
	    candidate neighbors is smaller than cur_min_path_metric 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 metric
	    and that smallest path metric is smaller than
	    cur_min_path_metric 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 smallest path metric.</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_metric is greater than MAX_PATH_METRIC,
	    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_metric to
	    MAX_PATH_METRIC.</t>


	</list></t>

      </section>

      <section title="Advertising the path metric">
	<t>Once the preferred parent is selected, the node sets its
	cur_min_path_metric variable to the path metric corresponding to
	the preferred parent. Thus, cur_min_path_metric is the cost of the
	path with the smallest path metric from the node to the
	root. The value of the cur_min_path_metric 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_metric: The path metric 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_METRIC: Maximum allowed value for the path
	metric of a selected path.</t>

	<t>MIN_PATH_METRIC: 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_METRIC: 100. Disallow paths with greater
	    than 100 expected transmission count.</t>

	    <t>MIN_PATH_METRIC: 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>
