Subject: [Roll] I-D Action:draft-ietf-roll-of0-09.txt

From: [email-masked]
Date: Tue, 05 Apr 2011 09:00:02 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF.

	Title           : RPL Objective Function 0
	Author(s)       : P. Thubert
	Filename        : draft-ietf-roll-of0-09.txt
	Pages           : 10
	Date            : 2011-04-05

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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Phoebus Chen <[email-masked]>
Date: Mon, 11 Apr 2011 20:27:11 +0200

Pascal,

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

	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

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.

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.

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

Also, it would be nice to use underscore instead of hyphen for 
variables, like in MRHOF (and use capital letters for parameters).

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

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?

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.

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.

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

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

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: +33 497 23 26 34
    Email: [email-masked]

Thubert                  Expires October 7, 2011               [Page 10]