Re: [Roll] OF0 draft v9: preferred metric, Stretch-of-Rank, configuring parameters, and editorial comments

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Phoebus : )

Where have you been? We've been missing your excellent comments.

> 	Sorry these comments are coming so late, after last call.  I
hope you
> can at least incorporate some of them.

[Pascal] That's beyond me. I suppose that the shepherd has to decide.
Let's see:


> 
> 	My comments below are based on my current understanding that
> Phil and you are no longer using hop-count as the rank increment.
Instead,
> each node will have an implementation specific way of converting a
node or
> link cost to a rank.  I'm still unclear if there is a preference rule
to try to stick
> with using the same metrics as the metrics advertised in a received
DIO, if
> the current node has access to multiple types of metrics (energy, LQI,
ETX,
> etc.).  That would allow the root node to specify a preferred type of
metric to
> use in the instance.
> 
> 
> Major Points:
> *************
> 1) I'm still hoping that the format for writing Objective Function
specifications
> can be more uniform, as I mentioned in an earlier comment (point
number 7
> in http://www.ietf.org/mail-archive/web/roll/current/msg03240.html)
> Comparing MRHOF and OF0, I think that the discussion on Step-of-Rank /
> Stretch-of-Rank etc. can be moved to it's own subsection.
> 
> I suggest the following reorganization of sections:
> 
>     3.  Objective Function 0
>     3.1. Computing Rank-increase
>     3.2. Parent / Backup Successor Selection
>       3.2.1. Selection of the Preferred Parent
>       3.2.2. Selection of the backup feasible successor
>     3.3. Advertising Rank-increase
>     4.  Interface with RPL core
> 
[Pascal] Looks good. That much is doc organization and I suppose I can
accommodate it at this stage.
It would certainly be beneficial if both OF drafts have a common
structure.

> If you are allowing the root to specified a preferred metric type,
then Section
> 3.3. should state how to propagate this preference.  I would have
assumed
> it's by propagating an empty DAG/Metric Container, but in (Section
2.1, draft-
> ietf-roll-routing-metrics-19) it says "The object body carries one or
more sub-
> objects defined later in this document"
> which means you cannot have empty containers.

[Pascal] OF0 does not have metric containers at all, so they do not need
to be empty. That's because OF0 is generic, for the better or the worse.
Because we want all implementations to interop with OF0, regardless of
the medium etc...

So the idea is to have no constraint on what the implementation uses to
derive the Rank, no container, no configuration option, just the base
RPL spec.

Rather, we normalize the resulting values so they can compare between
implementations. 

Now, I understand that a configuration container could help make the OF
more self-contained/autonomic. 

> Maybe the overview in Section 3 should also state explicitly that the
> processing rules of a DIO must do 3.1, then 3.2, then 3.3, in that
order.

[Pascal] Yes, and this is what we mean by
  " As it scans all the candidate neighbors, OF0 keeps the parent that
is
   the best for the following criteria (in order):"
the language may not be perfect but I hardly think the reader can be
getting the text wrong.
I'm open to an editorial change if the sense is conserved.

> 
> 
> 2) There have been two variables and one parameter defined in the
> overview section, but they are not mentioned in Section 7, OF0
Constants
> and Variables.
> Variables: Step-of-Rank, Stretch-of-Rank
> Parameters: Rank-factor
> (I noticed that there is no MINIMUM_RANK_STRETCH and
> DEFAULT_RANK_STRETCH and presume this is intentional.)
> 
[Pascal] You're right. A stretch of 0 is acceptable so there is no
MINIMUM.
 If there was a DEFAULT I expect it should be zero as well. By
compliance with the main spec.
I'm fine adding it. What do you think?

> Also, it would be nice to use underscore instead of hyphen for
> variables, like in MRHOF (and use capital letters for parameters).
> 
[Pascal] OK. I did not really mean those as variables, but why not.

> Finally, how is Stretch-of-Rank computed?  Implementation dependent?

[Pascal] It is not computed. It is configured and can be left to 0. Does
not have to be there at all in an implementation.
I can clarify that.

> 3) How does one configure the parameter(s) (Rank-Factor) from the
root?
>   (I just realized that this same comment applies to the parameters in
> MRHOF as well).   Or is that not configurable from the root, but must
be
> configured before deployment of the nodes?

[Pascal] The Rank factor has to be a per node policy, like the
Stretch-of-Rank. Right now, we do not have config containers to
distribute it.


> 
> 4) I think it would be nice to adopt the format of
> draft-ietf-roll-rpl-19 and draft-ietf-roll-minrank-hysteresis-of for
the
> Terminology section.  That is, write the word, then the definition
(this
> is not done for "feasible successor" in this section).  Some other
words
> to define in this section are "Rank-increase," "RPL core," and "higher
> order interface."  Unless the last one is common IPv6 terminology that
I
> am unaware of... I was unable to tell if that meant the higher order
> bits of the interface are higher, or if the interface is somehow
preferred.

I think that the RPL terminology is the place for having those in
common.

> 
> 5) Just a reminder that the discussion on Rank-increase in the
> introduction section
> "OF0 uses a unit of Rank-increase of 0x100 so that Rank value can be
> stored in one octet."
> needs to be aligned with text in Section 3,
> "Ri = Rf*Sp + Sr"
> so that they are consistent.  I see you are discussing this with
Omprakash.

Sp and Sr are expressed as units of 0x100 and Rf is integer, so they are
consistent. Do I miss something?

> 
> 6) I like the "Abstract Interface with RPL core" section, but would it
> be better to separate them into "Input" and "Output"?  That would end
up
> splitting up "Providing DAG information" and "Providing a Parent List"
> into two pieces though.
> 
> 
> More minor editorial comments to follow below, preceded by PC>.

Thanks for those. I'll include them in a rev.

> 
> --
> Phoebus Chen
> Postdoctoral Researcher
> Automatic Control Lab, KTH (Royal Institute of Technology)
> http://www.ee.kth.se/~phoebus
> 
> 
> 
> 
> 
> 
> 
> 
> ROLL                                                     P. Thubert,
Ed.
> Internet-Draft                                             Cisco
Systems
> Intended status: Standards Track                           April 5,
2011
> Expires: October 7, 2011
> 
> 
>                          RPL Objective Function 0
>                           draft-ietf-roll-of0-09
> 
> Abstract
> 
>     The Routing Protocol for Low Power and Lossy Networks defines a
>     generic Distance Vector protocol for Low Power and Lossy Networks.
>     That generic protocol requires a specific Objective Function to
>     establish a desired routing topology.  This specification defines
a
>     basic Objective Function that operates solely with the protocol
>     elements defined in the generic protocol specification.
> 
> Requirements Language
> 
>     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT",
>     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
> this
>     document are to be interpreted as described in RFC 2119 [RFC2119].
> 
> 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 October 7, 2011.
> 
> Copyright Notice
> 
>     Copyright (c) 2011 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
> 
> 
> 
> Thubert                  Expires October 7, 2011                [Page
1]
> 

> Internet-Draft             draft-ietf-roll-of0                April
2011
> 
> 
>     (http://trustee.ietf.org/license-info) in effect on the date of
>     publication of this document.  Please review these documents
>     carefully, as they describe your rights and restrictions with
respect
>     to this document.  Code Components extracted from this document
must
>     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  . . . . . . . . . . . . . . . . . . . . . . . . .
4
>     3.  Objective Function 0 Overview  . . . . . . . . . . . . . . . .
4
>     4.  Selection of the Preferred Parent  . . . . . . . . . . . . . .
6
>     5.  Selection of the backup feasible successor . . . . . . . . . .
7
>     6.  Abstract Interface with RPL core . . . . . . . . . . . . . . .
7
>     7.  OF0 Constants and Variables  . . . . . . . . . . . . . . . . .
8
>     8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .
8
>     9.  Security Considerations  . . . . . . . . . . . . . . . . . . .
8
>     10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .
9
>     11. References . . . . . . . . . . . . . . . . . . . . . . . . . .
9
>       11.1.  Normative References  . . . . . . . . . . . . . . . . . .
9
>       11.2.  Informative References  . . . . . . . . . . . . . . . . .
9
>     Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .
10
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Thubert                  Expires October 7, 2011                [Page
2]
> 

> Internet-Draft             draft-ietf-roll-of0                April
2011
> 
> 
> 1.  Introduction
> 
>     The IETF ROLL Working Group has defined application-specific
routing
>     requirements for a Low Power and Lossy Network (LLN) routing
>     protocol, specified in [RFC5548], [RFC5673], [RFC5826], and
>     [RFC5867].
> 
>     The Routing Protocol for Low Power and Lossy Networks
>     [I-D.ietf-roll-rpl] was designed as a generic core that is
agnostic
>     to metrics and that is adapted to a given problem using Objective
>     Functions (OF).  This separation of Objective Functions from the
core
>     protocol specification allows RPL to adapt to meet the different
>     optimization criteria the wide range of use cases requires.
> 
> PC> s/the wide range of use cases requires/required by the wide range
of
> use cases/
> 
>     RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs)
>     within instances of the protocol.  Each instance is associated
with
>     an Objective Function that is designed to solve the problem that
is
>     addressed by that instance.
> 
> PC> remove "that is designed to solve the problem that is addressed by
> that instance".  Sounds almost like a tautology.
> 
> 
>     An Objective Function selects the DODAG Version that a device
joins,
>     and a number of neighbor routers within that Version as parents or
>     feasible successors.  The OF generates the Rank of the device,
that
>     represents an abstract distance to the root within the DODAG.  In
>     turn, the Rank is used by the generic RPL core to enable a degree
of
>     loop avoidance and verify forward progression towards a
destination,
>     as specified in [I-D.ietf-roll-rpl].
> 
> PC> Do you intend to capitalize "Rank" and "Version" here?
> 
>     The Objective Function 0 (OF0) corresponds to the Objective Code
>     Point 0 (OCP0).  OF0 only requires the information in the RPL DIO
>     base container, such as Rank and the DODAGPreference field that
>     describes an administrative preference [I-D.ietf-roll-rpl].  The
Rank
>     of a node is obtained by adding a normalized scalar Rank-increase
to
> 
> PC> s/Rank-increase/, Rank-increase,/
> 
>     the Rank of a selected preferred parent.  OF0 uses a unit of Rank-
>     increase of 0x100 so that Rank value can be stored in one octet.
>     This allows up to at least 28 hops even when default settings are
>     used and each hop has the worst Rank-increase of 9.
> 
>     Since there is no default OF or metric container in the RPL main
>     specification, it might happen that, unless given two
implementations
> 
> PC> s/given two/two given/
> 
>     follow a same guidance for a specific problem or environment,
those
> 
> PC> s/a same/the same/
> 
>     implementations will not support a common OF with which they could
>     interoperate.  OF0 is designed to be used as a common denominator
> 
> PC> I'm not sure what you mean by "common denominator" here.  Are you
> just trying to say that OF0 must be supported by all implementations
of
> RPL?  What is a "generic implementation"?
> 
>     between all generic implementations.  This is why it is very
abstract
>     as to how the link properties are transformed into a Rank-increase
>     and leaves that responsibility to implementation; rather, OF0
>     enforces normalized values for the Rank-increase of a normal link
and
>     its acceptable range, as opposed to formulating the details of the
> 
> PC> s/details of the/details of/
> 
>     its computation.  This is also why OF0 ignores metric containers.
> 
> 
> 
> Thubert                  Expires October 7, 2011                [Page
3]
> 

> Internet-Draft             draft-ietf-roll-of0                April
2011
> 
> 
> 2.  Terminology
> 
>     The terminology used in this document is consistent with and
>     incorporates that described in `Terminology in Low power And Lossy
>     Networks' [I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl].
> 
>     The term feasible successor is used to refer to a neighbor that
can
>     possibly be used as a next-hop for upwards traffic following the
loop
>     avoidance and forwarding rules that the nodes implements and that
are
>     defined outside of this specification, in particular in the RPL
>     specification.
> 
> PC> Remove "that the nodes implements and that are defined outside of
> this specification, in particular"
> 
> 
> 3.  Objective Function 0 Overview
> 
>     The core RPL specification describes constraints on how nodes
select
>     potential parents, called a parent set, from their neighbors.  All
>     parents are feasible successors for upgoing traffic (towards the
>     root).  Additionally, RPL allows the use of parents in a
subsequent
>     Version of a same DODAG as feasible successors, in which case this
> 
> PC> again, capitalize Version?
> 
>     node acts as a leaf in the subsequent DODAG Version.  Further
>     specifications might extend the set of feasible successors, for
>     instance to nodes of a same Rank, aka siblings.
> 
>     The Goal of the OF0 is for a node to join a DODAG Version that
offers
>     connectivity to a specific set of nodes or to a larger routing
>     infrastructure.  For the purpose of OF0, Grounded thus means that
the
>     root provides such connectivity.  How that connectivity is
asserted
>     and maintained is out of scope.
> 
>     Objective Function 0 is designed to find the nearest Grounded
root.
>     This can be achieved if the Rank of a node represents closely its
>     distance to the root.  This need is balanced with the other need
of
>     maintaining some path diversity.
> 
>     In the absence of a Grounded root, LLN inner connectivity is still
>     desirable and floating DAGs will form, rooted at the nodes with
the
>     highest administrative preference.
> 
> PC> the above two paragraphs can be combined.
> 
>     OF0 selects a preferred parent and a backup feasible successor if
one
>     is available.  All the upward traffic is normally routed via the
>     preferred parent.  When the link conditions do not let an upward
>     packet through the preferred parent, the packet is passed to the
>     backup feasible successor.
> 
> PC> Replace "When the link conditions do not let an upward
> PC> packet through the preferred parent"
> PC> with
> PC> "When a node is unable to send a packet trough the preferred
parent".
> 
>     OF0 assigns a Step-of-Rank to each link to another node that it
> 
> PC> remove "to another node"
> 
>     monitors.  The exact method for computing the Step-of-Rank is
>     implementation-dependent.
> 
> 
> 
> Thubert                  Expires October 7, 2011                [Page
4]
> 

> Internet-Draft             draft-ietf-roll-of0                April
2011
> 
> 
>     One trivial OF0 implementation might compute the Step-of-Rank from
as
> 
> PC> remove "as"
> 
>     a classical administrative cost that is assigned to the link.
Using
>     a metric similar to hop count implies that the OF0 implementation
> 
> PC> "classical administrative cost" refers to "hop count" here?  It's
> not clear from the writing.
> 
>     only considers neighbors with good enough connectivity, for
instance
>     neighbors that are reachable over an Ethernet link, or a WIFI link
in
> 
> PC> s/WIFI/WiFi/
> 
>     infrastructure mode.
> 
>     In most wireless networks, a Rank that is analogous to an
unweighted
>     hop count favors paths with long distance links and poor
connectivity
>     properties.  Other link properties such as the expected
transmission
>     count metric (ETX) [DeCouto03] should be used instead to compute
the
>     Step-of-Rank.  For instance, the Minimum Rank Objective Function
with
>     Hysteresis [I-D.ietf-roll-minrank-hysteresis-of] provides guidance
on
>     how link cost can be computed and on how hysteresis can improve
Rank
>     stability.
> 
>     An implementation MAY allow to stretch the Step-of-Rank with a
>     Stretch-of-Rank up to no more than MAXIMUM_RANK_STRETCH in order
> to
>     enable the selection of a feasible successor in order to maintain
>     some path diversity.  The use of a Stretch-of-Rank augments the
>     apparent distance from the node to the root and distorts the
DODAG;
>     it should be used with care so as to avoid instabilities due to
>     greedy behaviours.
> 
>     The Step-of-Rank is expressed in units of MINIMUM_STEP_OF_RANK.
As
> a
>     result, the least significant octet in the RPL Rank is not used.
The
>     default Step-of-Rank is DEFAULT_STEP_OF_RANK for each hop.  An
>     implementation MUST maintain the stretched Step-of-Rank between
>     MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK, which
> allows to
>     reflect a large variation of link quality.
> 
> PC> Remove ", which allows to reflect a large variation of link
> PC> quality."  If you wish to point out that stretch of rank may be
> PC> computed from link quality, this should be mentioned earlier where
> PC> you point out that the exact method for computing it is
> PC> implementation-dependent.
> 
>     The gap between MINIMUM_STEP_OF_RANK and
> MAXIMUM_RANK_STRETCH may not
>     be sufficient in every case to strongly distinguish links of
>     different types or categories in order to favor, say, powered over
>     battery-operated or wired over wireless, within a same DAG.  An
> 
> PC> s/a same DAG/the same DAG/
> 
>     implementation SHOULD allow a configurable factor called
Rank-factor
>     and to apply the factor on all links and peers.
> 
>     An implementation MAY recognizes sub-categories of peers and
links,
>     such as different MAC types, in which case it SHOULD be able to
>     configure a more specific Rank-factor to those categories.  The
Rank-
>     factor SHOULD be set between MINIMUM_RANK_FACTOR and
>     MAXIMUM_RANK_FACTOR.  The Step-of-Rank Sp that is computed for
> that
> 
> PC> I though "Sp" was a typo.    s/Sp that is computed/, Sp, computed/
> 
>     link s multiplied by the Rank-factor Rf and then possibly
stretched
> 
> PC> s/Rf/,Rf,/;  s/link s/link is/
> 
>     by a Stretch-of-Rank Sr. The resulting Rank-increase Ri is added
to
> 
> PC> s/ Sr/, Sr/;    s/ Ri/, Ri,/;  And so forth below, you get the
idea.
> 
>     the Rank of preferred parent R(P) to obtain that of this node
R(N):
> 
> PC> s/obtain that of this node/obtain the rank of the current node/
> 
>     R(N) = R(P) + Ri where Ri = Rf*Sp + Sr.
> 
> PC> Insert comma and space for readability,
> PC> R(N) = R(P) + Ri,         where Ri = Rf*Sp + Sr.
> 
> 
> 
> Thubert                  Expires October 7, 2011                [Page
5]
> 

> Internet-Draft             draft-ietf-roll-of0                April
2011
> 
> 
>     Optionally, the administrative preference of a root MAY be
configured
>     to supersede the goal to join a Grounded DODAG.  In that case,
nodes
>     will associate to the root with the highest preference available,
>     regardless of whether that root is Grounded or not.  Compared to a
>     deployment with a multitude of Grounded roots that would result in
a
>     same multitude of DODAGs, such a configuration may result in
possibly
> 
> PC> remove "same"
> 
>     less but larger DODAGs, as many as roots configured with the
highest
>     priority in the reachable vicinity.
> 
> PC> I don't understand "as many as roots configured with the highest
> PC> priority in the reachable vicinity."  Is that necessary?
> 
> 4.  Selection of the Preferred Parent
> 
>     As it scans all the candidate neighbors, OF0 keeps the parent that
is
>     the best for the following criteria (in order):
> 
>     1.   [I-D.ietf-roll-rpl] spells out the generic rules for a node
to
>          reparent and in particular the boundaries to augment its Rank
>          within a DODAG Version.  A candidate that would not satisfy
>          those rules MUST NOT be considered.
> 
>     2.   An implementation should validate a router prior to selecting
it
>          as preferred.  This validation process is implementation and
>          link type dependent, and is out of scope.  A router that has
>          been validated is preferable.
> 
>     3.   When multiple interfaces are available, a policy might be
>          locally configured to prioritize them and that policy applies
>          first; that is a router on a higher order interface is
>          preferable.
> 
>     4.   If the administrative preference of the root is configured to
>          supersede the goal to join a Grounded DODAG, a router that
>          offers connectivity to a more preferable root SHOULD be
>          preferred.
> 
>     5.   A router that offers connectivity to a grounded DODAG Version
>          SHOULD be preferred over one that does not.
> 
>     6.   A router that offers connectivity to a more preferable root
>          SHOULD be preferred.
> 
>     7.   When comparing 2 routers that belong to the same DODAG, a
router
>          that offers connectivity to the freshest Version SHOULD be
>          preferred.
> 
>     8.   The parent that causes the lesser resulting Rank for this
node
>          SHOULD be preferred.
> 
> 
> 
> 
> Thubert                  Expires October 7, 2011                [Page
6]
> 

> Internet-Draft             draft-ietf-roll-of0                April
2011
> 
> 
>     9.   A DODAG Version for which there is an alternate parent SHOULD
be
>          preferred.  This check is optional.  It is performed by
>          computing the backup feasible successor while assuming that
the
>          router that is currently examined is finally selected as
>          preferred parent.
> 
>     10.  The preferred parent that was in use already SHOULD be
>          preferred.
> 
>     11.  A router that has announced a DIO message more recently
SHOULD
>          be preferred.
> 
> 
> 5.  Selection of the backup feasible successor
> 
>     When selecting a backup feasible successor, the OF performs in
order
>     the following checks:
> 
>     1.  When multiple interfaces are available, a router on a higher
>         order interface is preferable.
> 
>     2.  The backup feasible successor MUST NOT be the preferred
parent.
> 
>     3.  The backup feasible successor MUST be either in the same DODAG
>         Version as this node or in an subsequent Version.
> 
>     4.  Along with RPL rules, a Router in the same DODAG Version as
this
>         node and with a Rank that is higher than the Rank computed for
>         this node MUST NOT be selected as a feasible successor.
> 
>     5.  A router with a lesser Rank SHOULD be preferred.
> 
>     6.  A router that has been validated as usable by an
implementation
>         dependant validation process SHOULD be preferred.
> 
>     7.  The backup feasible successor that was in use already SHOULD
be
>         preferred.
> 
> 
> 6.  Abstract Interface with RPL core
> 
>     Objective Function 0 interacts with the core RPL in the following
> 
> PC> s/core RPL/RPL core/
> 
>     ways:
> 
>     Processing DIO:  This core RPL triggers the OF when a new DIO was
> 
> PC> s/This core RPL/The RPL core/
> 
>                received.  OF0 analyses the information in the DIO and
may
>                select the source as a parent or sibling.
> 
> 
> 
> 
> Thubert                  Expires October 7, 2011                [Page
7]
> 

> Internet-Draft             draft-ietf-roll-of0                April
2011
> 
> 
>     Providing DAG information  The OF0 support can be required to
provide
> 
> PC> s/information/information:/
> PC> s/The OF0 support can be required to/OF0 SHOULD/
> 
>                the DAG information for a given instance to the RPL
core.
>                This includes the material that is contained in a DIO
base
>                header.
> 
> PC> what is "material" referring to here?  all the information
> PC> contained in a DIO base header?  I suppose OF0 is tasked with
> PC> keeping all that information, not the RPL core?
> 
>     Providing a Parent List  The OF0 support can be required to
provide
> 
> PC> s/List/List:/
> PC> s/The OF0 support can be required to/OF0 SHOULD/
> 
>                the ordered list of the parents and feasible successors
>                for a given instance to the RPL core.  This includes
the
>                material that is contained in the transit option for
each
>                entry.
> 
> PC> same comment, maybe replace "material" with "all the information"
> 
>     Trigger    The OF0 support may trigger the RPL core to inform it
that
> 
> PC> s/Trigger/Trigger:/
> PC> s/The OF0 support may/OF0 SHOULD/
> 
>                a change occurred.  This can be used to indicate
whether
>                the change requires a new DIO to be fired or whether
>                trickle timers need to be reset.
> 
> 
> 7.  OF0 Constants and Variables
> 
>     OF0 uses the following constants:
> 
>     MinHopRankIncrease:  256
> 
>     DEFAULT_STEP_OF_RANK:  3 * MinHopRankIncrease
> 
>     MINIMUM_STEP_OF_RANK:  1 * MinHopRankIncrease
> 
>     MAXIMUM_STEP_OF_RANK:  9 * MinHopRankIncrease
> 
>     MAXIMUM_RANK_STRETCH:  5 * MinHopRankIncrease
> 
>     DEFAULT_RANK_FACTOR:  1
> 
>     MINIMUM_RANK_FACTOR:  1
> 
>     MAXIMUM_RANK_FACTOR:  4
> 
> 
> 8.  IANA Considerations
> 
>     This specification requires the assignment of an OCP for OF0.  The
>     value of 0 is suggested.
> 
> 
> 9.  Security Considerations
> 
>     Security Considerations for OCP/OF are to be developed in
accordance
>     with recommendations laid out in, for example,
> 
> 
> 
> Thubert                  Expires October 7, 2011                [Page
8]
> 

> Internet-Draft             draft-ietf-roll-of0                April
2011
> 
> 
>     [I-D.tsao-roll-security-framework].
> 
> 
> 10.  Acknowledgements
> 
>     Most specific thanks to Philip Levis for his help in finalizing
this
>     document, in particular WRT wireless links, to Tim Winter, JP
> 
> PC> s/WRT/with respect to/
> 
>     Vasseur, Julien Abeille, Mathilde Durvy, Teco Boot, Navneet
Agarwal
>     and Henning Rogge for in-depth review and first hand implementer's
>     feedback.
> 
> 
> 11.  References
> 
> 11.1.  Normative References
> 
>     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>                Requirement Levels", BCP 14, RFC 2119, March 1997.
> 
> 11.2.  Informative References
> 
>     [DeCouto03]
>                De Couto, Aguayo, Bicket, and Morris, "A
High-Throughput
>                Path Metric for Multi-Hop Wireless Routing", MobiCom
>                '03 The 9th ACM International Conference on Mobile
>                Computing and Networking, San Diego, California,, 2003,
<h
>
ttp://pdos.csail.mit.edu/papers/grid:mobicom03/paper.pdf>.
> 
>     [I-D.ietf-roll-minrank-hysteresis-of]
>                Gnawali, O. and P. Levis, "The Minimum Rank Objective
>                Function with Hysteresis",
>                draft-ietf-roll-minrank-hysteresis-of-01 (work in
>                progress), February 2011.
> 
>     [I-D.ietf-roll-routing-metrics]
>                Vasseur, J., Kim, M., Pister, K., Dejean, N., and D.
>                Barthel, "Routing Metrics used for Path Calculation in
Low
>                Power and Lossy Networks",
>                draft-ietf-roll-routing-metrics-19 (work in progress),
>                March 2011.
> 
>     [I-D.ietf-roll-rpl]
>                Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui,
J.,
>                Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
>                Vasseur, "RPL: IPv6 Routing Protocol for Low power and
>                Lossy Networks", draft-ietf-roll-rpl-19 (work in
>                progress), March 2011.
> 
> 
> 
> 
> Thubert                  Expires October 7, 2011                [Page
9]
> 

> Internet-Draft             draft-ietf-roll-of0                April
2011
> 
> 
>     [I-D.ietf-roll-terminology]
>                Vasseur, J., "Terminology in Low power And Lossy
>                Networks", draft-ietf-roll-terminology-05 (work in
>                progress), March 2011.
> 
>     [I-D.tsao-roll-security-framework]
>                Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A
>                Security Framework for Routing over Low Power and Lossy
>                Networks", draft-tsao-roll-security-framework-02 (work
in
>                progress), March 2010.
> 
>     [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.
> 
>     [RFC5826]  Brandt, A., Buron, J., and G. Porcu, "Home Automation
>                Routing Requirements in Low-Power and Lossy Networks",
>                RFC 5826, April 2010.
> 
>     [RFC5867]  Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
>                "Building Automation Routing Requirements in Low-Power
and
>                Lossy Networks", RFC 5867, June 2010.
> 
> 
> Author's Address
> 
>     Pascal Thubert (editor)
>     Cisco Systems
>     Village d'Entreprises Green Side
>     400, Avenue de Roumanille
>     Batiment T3
>     Biot - Sophia Antipolis  06410
>     FRANCE
> 
>     Phone: [phone]
>     Email: [e-mail]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Thubert                  Expires October 7, 2011               [Page
10]
>