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

Versions: (draft-mjkim-roll-routing-metrics) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 RFC 6551

Networking Working Group                                JP. Vasseur, Ed.
Internet-Draft                                        Cisco Systems, Inc
Intended status: Standards Track                             M. Kim, Ed.
Expires: April 22, 2011                   Corporate Technology Group, KT
                                                               K. Pister
                                                           Dust Networks
                                                               N. Dejean
                                                             Coronis SAS
                                                              D. Barthel
                                                   France Telecom Orange
                                                        October 19, 2010


    Routing Metrics used for Path Calculation in Low Power and Lossy
                                Networks
                   draft-ietf-roll-routing-metrics-10

Abstract

   Low power and Lossy Networks (LLNs) have unique characteristics
   compared with traditional wired and ad-hoc networks that require the
   specification of new routing metrics and constraints.  By contrast
   with typical Interior Gateway Protocol (IGP) routing metrics using
   hop counts or link metrics, this document specifies a set of link and
   node routing metrics and constraints suitable to LLNs to be used by
   the Routing for Low Power and lossy networks (RPL) routing protocol.

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




Vasseur, et al.          Expires April 22, 2011                 [Page 1]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


   This Internet-Draft will expire on April 22, 2011.

Copyright Notice

   Copyright (c) 2010 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
   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.



































Vasseur, et al.          Expires April 22, 2011                 [Page 2]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Object formats . . . . . . . . . . . . . . . . . . . . . . . .  7
     2.1.  DAG Metric Container format  . . . . . . . . . . . . . . .  7
     2.2.  Use of multiple DAG Metric Containers  . . . . . . . . . . 10
     2.3.  Metric usage . . . . . . . . . . . . . . . . . . . . . . . 10
   3.  Node Metric/Constraint objects . . . . . . . . . . . . . . . . 11
     3.1.  Node State and Attributes object . . . . . . . . . . . . . 11
     3.2.  Node Energy object . . . . . . . . . . . . . . . . . . . . 13
     3.3.  Hop-Count object . . . . . . . . . . . . . . . . . . . . . 16
   4.  Link Metric/Constraint objects . . . . . . . . . . . . . . . . 17
     4.1.  Throughput . . . . . . . . . . . . . . . . . . . . . . . . 17
     4.2.  Latency  . . . . . . . . . . . . . . . . . . . . . . . . . 18
     4.3.  Link reliability . . . . . . . . . . . . . . . . . . . . . 19
       4.3.1.  The Link Quality Level reliability metric  . . . . . . 20
       4.3.2.  The Expected Transmission Count (ETX) reliability
               object . . . . . . . . . . . . . . . . . . . . . . . . 22
     4.4.  Link Color object  . . . . . . . . . . . . . . . . . . . . 23
       4.4.1.  Link Color object description  . . . . . . . . . . . . 23
       4.4.2.  Mode of operation  . . . . . . . . . . . . . . . . . . 25
   5.  Computation of dynamic metrics and attributes  . . . . . . . . 25
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
     6.1.  Routing Metric/Constraint type . . . . . . . . . . . . . . 26
     6.2.  Routing Metric/Constraint common header  . . . . . . . . . 26
     6.3.  NSA object . . . . . . . . . . . . . . . . . . . . . . . . 27
     6.4.  Hop-Count object . . . . . . . . . . . . . . . . . . . . . 28
   7.  Security considerations  . . . . . . . . . . . . . . . . . . . 28
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     9.1.  Normative references . . . . . . . . . . . . . . . . . . . 29
     9.2.  Informative references . . . . . . . . . . . . . . . . . . 29
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30


















Vasseur, et al.          Expires April 22, 2011                 [Page 3]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


1.  Introduction

   This document makes use of the terminology defined in
   [I-D.ietf-roll-terminology].

   Low power and Lossy Networks (LLNs) have specific routing
   characteristics compared with traditional wired or ad-hoc networks
   that have been spelled out in [RFC5548], [RFC5673], [RFC5826] and
   [RFC5867].

   Historically, IGP such as OSPF ([RFC2328]) and IS-IS ([RFC1195]) have
   used quantitative static link metrics.  Other mechanisms such as
   Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) (see
   [RFC2702] and [RFC3209]) make use of other link attributes such as
   the available reserved bandwidth (dynamic) or link affinities (most
   of the time static) to compute constrained shortest paths for Traffic
   Engineering Label Switched Paths (TE LSPs).

   This document specifies routing metrics and constraints to be used in
   path calculation by the Routing Protocol for Low Power and Lossy
   Networks (RPL) specified in [I-D.ietf-roll-rpl].

   One of the prime objectives of this document is to propose a flexible
   mechanism for the advertisement of routing metrics and constraints
   used by RPL.  Some RPL implementations may elect to adopt an
   extremely simple approach based on the use of a single metric with no
   constraint whereas other implementations may use a larger set of link
   and node routing metrics and constraints.  This specification
   provides a high degree of flexibility and a set of routing metrics
   and constraints.  New routing metrics and constraints could be
   defined in the future, as needed.

   RPL is a distance vector routing protocol that builds Directed
   Acyclic Graphs (DAGs) based on routing metrics and constraints.  DAG
   formation rules are defined in [I-D.ietf-roll-rpl]:

   o  The DAG root may advertise a routing constraint used as a "filter"
      to prune links and nodes that do not satisfy specific properties.
      For example, it may be required for the path to only traverse
      nodes that are mains powered or links that have at least a minimum
      reliability or a specific "color" reflecting a user defined link
      characteristic (e.g the link layer supports encryption).

   o  A routing metric is a quantitative value that is used to evaluate
      the path cost.  Link and node metrics are usually (but not always)
      additive.

   The best path is the path with the lowest cost with respect to some



Vasseur, et al.          Expires April 22, 2011                 [Page 4]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


   metrics that satisfies all constraints (if any).  It is also called
   the shortest constrained path (in the presence of constraints).

   Routing metrics can be classified according to the following set of
   characteristics:

   o  Link versus Node metrics

   o  Qualitative versus quantitative

   o  Dynamic versus static

   As pointed out in various routing requirements documents (see
   [RFC5673], [RFC5826] [RFC5548] and [RFC5867]), it must be possible to
   take into account a variety of node constraints/metrics during path
   computation.

   Some link or node characteristics (e.g. link reliability flag,
   remaining energy on the node) may either be used by RPL as routing
   constraints or metrics.  For example, the path may be computed to
   avoid links that do not provide a sufficient level of reliability
   (use as a constraint) or as the path offering most links with a
   specified reliability level (use as a metric).  The document provides
   the flexibility to use link and node characterisics either as
   constraints and/or metrics.

   The use of link and node routing metrics and constraints is not
   exclusive.

   It is also worth mentioning that it is fairly common for links in
   LLNs to have fast changing node and link characteristics, which must
   be taken into account when specifying routing metrics.  For instance,
   in addition to the dynamic nature of some links (e.g. wireless but
   also Powerline Communication (PLC) links), nodes' resources such as
   residual energy and other link's characteristics such as the
   throughput are changing continuously and may have to be taken into
   account during the path computation.  Similarly, link attributes
   including throughput and reliability may drastically change over time
   due to multi-path interference.

   It must be noted that the use of dynamic metrics is not new and has
   been experimented in ARPANET 2 [Khanna1989], with moderate success.
   The use of dynamic metrics is not trivial and great care must be
   given to the use of dynamic metrics since it may lead to potential
   routing instabilities. it must be noted that the use of dynamic
   metrics has been largely experimented and deployed in a number of
   (non IP) networks in the past decade.




Vasseur, et al.          Expires April 22, 2011                 [Page 5]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


   Very careful attention must be given when using dynamic metrics and
   attributes that affect routing decisions in order to preserve routing
   stability.  Routing metrics and constraints may either be static or
   dynamic.  When dynamic, a RPL implementation SHOULD make use of a
   multi-threshold scheme rather than fine granular metric updates so as
   to avoid constant routing changes.

   Furthermore, it is a time and energy consuming process to update
   dynamic metrics and recompute the routing tables on a frequent basis.
   Therefore, it may be desirable to use a set of discrete values to
   reduce computational overhead and bandwidth utilization.  Of course,
   this comes with a cost, namely, reduced metric accuracy.  In other
   cases, a set of flags may be defined to reflect a node state without
   having to define discrete values.

   The requirements on reporting frequency may differ among metrics,
   thus different reporting rates may be used for each category and are
   consequently implementation-specific.

   The set of routing metrics and constraints used by an RPL
   implementation is signaled along the Directed Acyclic Graph (DAG)
   that is built according to the Objective Function (rules governing
   how to build a DAG) and the routing metrics and constraints are
   advertised in the DAG Information Option (DIO) message specified in
   [I-D.ietf-roll-rpl].  RPL may be used to build DAGs with different
   characteristics.  For example, it may be desirable to build a DAG
   with the goal to maximize reliability by using the link reliability
   metric to compute the "best" path.  Another example might be to use
   the energy node characteristic (e.g. mains powered versus battery
   operated) as a node constraint when building the DAG so as to avoid
   battery powered nodes in the DAG while optimizing the link
   throughput.

   The specification of objective functions used to compute the DAG
   built by RPL is out of the scope of this document.  Routing metrics
   and constraints are decoupled from the objective function.  So a
   generic objective function could for example specify the rules to
   select the best parents in the DAG, the number of backup parents,
   etc.  Such objective function can be used with any routing metrics
   and/or constraints such as the ones specified in this document.

   Some metrics are either aggregated or recorded.  In the former case,
   the metric is adjusted as the DIO message travels along the DAG.  For
   example, if the metric is the link latency, each node updates the
   latency metric along the DAG.  By contrast, a metric may be recorded
   in which case each node adds a sub-object reflecting the local
   metric.  For example, it might be desirable to record the link
   quality level along the path.  In this case, each visited node adds a



Vasseur, et al.          Expires April 22, 2011                 [Page 6]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


   sub-object reporting the local link quality level.  In order to limit
   the number of sub-objects, the use of a counter may be desirable
   (e.g. record the number of links with a certain link quality level),
   thus compressing the information to reduce the message length.  Upon
   receiving the DIO message from a set of parents, a node can decide
   according to the OF and local policy which node to choose as a parent
   based on the maximum number of links with a specific link reliability
   level, for example.

   Note that the routing metrics and constraints specified in this
   document are not specific to any link layer.  An internal API between
   the MAC layer and RPL may be used to accurately reflect the metrics
   values of the link (wireless, wired, PLC).

   Since a set of metrics and constraints will be used for links and
   nodes in LLN, it is particularly critical to ensure the use of
   consistent metric calculation mechanisms for all links and nodes in
   the network, similarly to the case of inter-domain IP routing.


2.  Object formats

2.1.  DAG Metric Container format

   Routing metrics and constraints are carried within the DAG Metric
   Container object defined in [I-D.ietf-roll-rpl].  Should multiple
   metrics and/or constraints be present in the DAG Metric Container,
   their use to determine the "best" path can be defined by an Objective
   Function or a new TLV to be defined in future documents.


0               1               2               3               4
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
|     Type=2    |  Option Len   |  Routing Metric/Constraint objects
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

        Figure 1: DAG Metric Container format

   The Routing Metric/Constraint objects have a common format consisting
   of one or more 8-bit words with a common header:










Vasseur, et al.          Expires April 22, 2011                 [Page 7]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


    0               1               2               3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Routing-MC-Type|  Flags  |P|C|O|R| A   |  Prec | Length (bytes)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                        (object body)                        //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 2: Routing Metric/Constraint object generic format

   The object body carries one or more sub-objects.

   Note that the Routing Metric/Constraint objects defined in this
   document can appear in any order in the DAG Metric Container.

   Routing-MC-Type (Routing Metric/Constraint Type - 8 bits): the
   Routing Metric/Constraint Type field uniquely identifies each Routing
   Metric/Constraint object and is managed by IANA.

   Length: this field defines the length of the object body, in bytes.

   The Flag field of the Routing Metric/Constraint object is managed by
   IANA.  Unassigned bits are considered as reserved.  They MUST be set
   to zero on transmission and MUST be ignored on receipt.

   o  C Flag.  When set, this indicates that the Routing Metric/
      Constraint object refers to a routing constraint.  When cleared,
      the routing object refers to a routing metric.

   o  O Flag: The O flag is used exclusively for routing constraints (C
      flag is set).  When set, this indicates that the constraint is
      optional.  When cleared, the constraint is mandatory.  If the C
      flag is zero, the O flag MUST be set to zero on transmission and
      ignored on reception.

   o  R Flag: The R Flag is only relevant for routing metric (C=0) and
      MUST be cleared for C=1.  When set, this indicates that the
      routing metric is recorded along the path.  Conversely, when
      cleared, the routing metric is aggregated.

   o  A Field: The A field is used to indicate whether an aggregated
      routing metric is additive, multiplicative, reports a maximum or a
      minimum.

      *  A=0x00: The routing metric is additive




Vasseur, et al.          Expires April 22, 2011                 [Page 8]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


      *  A=0x01: The routing metric reports a maximum

      *  A=0x02: The routing metric reports a minimum

      *  A=0x03: The routing metric is multiplicative

      The A field has no meaning when the C Flag is set (i.e. when the
      Routing Metric/Constraint object refers to a routing constraint)
      and MUST be written to 0x00.

   o  Prec field: The Prec field indicates the precedence of this
      Routing Metric/Constraint object.  This is useful when a DAG
      Metric Container contains several Routing Metric objects.  The
      value 0 means the highest precedence.

   o  P field: the P field is only used for recorded metrics.  When
      cleared, all nodes along the path successfully recorded the
      corresponding metric.  When set, this indicates than one or
      several nodes along the path could not record the metric of
      interest (either because of lack of knowledge or because this was
      prevented by policy).

   Example 1: A DAG formed by RPL where all nodes must be mains-powered
   and the best path is the one with lower aggregated ETX.  In this case
   the DAG Metric container carries two Routing Metric/Constraint
   objects: one is an ETX metric object with header (C=0, O=0, A=00,
   R=0) and the second one is a Node Energy constraint object with
   header (C=1, O=0, A=00, R=0).  Note that a RPL instance may use the
   metric object to report a maximum (A=0x01) or a minimum (A=0x02).
   If, for example, the best path is characterized by the path avoiding
   low quality links, then the path metric reports a maximum (A=0x01)
   (note that higher values mean lower link quality): when the link
   quality metric (ETX) is processed along a path, each node updates the
   value carried in the metric object by replacing it with its local
   link ETX value if and only if the latter is higher.

   Example 2: A DAG formed by RPL where the link metric is the link
   quality level and link quality levels must be recorded along the
   path.  In this case, the DAG Metric Container carries a Routing
   Metric/Constraint object: link quality level metric (C=0, O=0, A=00,
   R=1) containing multiple sub-objects.

   A Routing Metric/Constraint object may also include one or more
   type-length-value (TLV) encoded data sets.  Each Routing Metric/
   Constraint TLV has the same structure:






Vasseur, et al.          Expires April 22, 2011                 [Page 9]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


   Type: 1 byte
   Length: 1 byte
   Value: variable

   A Routing Metric/Constraint TLV is comprised of 1 byte for the type,
   1 byte specifying the TLV length, and a value field.  The TLV length
   field defines the length of the value field in bytes.

   Unrecognized TLVs MUST be ignored.

   IANA management of the Routing Metric/Constraint objects identifier
   codespace is described in Section 6.

2.2.  Use of multiple DAG Metric Containers

   Since the length of RPL options is encoded using 1 octet, they cannot
   exceed 256 bytes, which also applies to the DAG Metric Container.  In
   the vast majority of cases, the advertised routing metrics and
   constraints will not require that much space.  However, there might
   be circumstances where larger space is required, should for example a
   set of routing metrics be recorded along a long path.  In this case,
   as specified in [I-D.ietf-roll-rpl], routing metrics will be carried
   using multiple DAG Metric Containers.

   In the rest of this document, this use of multiple DAG Metric
   Containers will be considered as if they were actually just one long
   DAG Metric Container.

2.3.  Metric usage

   This section describes how metrics carried in the DAG Metric
   Container shall be used.

   When the DAG Metric Container contains a single aggregated metric
   (scalar value), the order relation to select the best path is
   implicitly derived from the metric type.  For example, lower is
   better for Hop Count, Link Latency and ETX.  Conversely, for Node
   Energy or Throughput, higher is better.

   An example of using such a single aggregated metric is optimizing
   routing for node energy.  The Node Energy metric (E-E field) is
   aggregated along paths with an explicit min function (A field), and
   the best path is selected through an implied Max function because the
   metric is Energy.

   When the DAG Metric Container contains several aggregated metrics,
   they are to be used as tie-breakers according to their precedence
   defined by their Prec field values.



Vasseur, et al.          Expires April 22, 2011                [Page 10]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


   An example of such use of multiple aggregated metrics is the
   following: Hop-Count as the primary criterion, LQL as the secondary
   criterion and Node Energy as the ultimate tie-breaker.  In such a
   case, the Hop-Count, LQL and Node Energy metric objects' Prec fields
   should bear strictly increasing values such as 0, 1 and 2,
   respectively.

   If several aggregated metrics happen to bear the same Prec value, the
   behavior is implementation-dependant.


3.  Node Metric/Constraint objects

   It is fairly common for LLNs to be made of nodes with heterogeneous
   attributes and capabilities (e.g. nodes being battery operated or
   not, amount of memory, etc).  More capable and stable nodes may
   assist the most constrained ones for routing packets, which results
   in extension of network lifetime and efficient network operations.
   This is a typical (but non-exclusive) use of constraint-based
   routing, where the computed path may not be the shortest path
   according to some specified metrics.  Another use is to find the
   shortest path according to a pre-defined metric while avoiding links
   with a specific color (for example "non-secured link").

3.1.  Node State and Attributes object

   The Node State and Attribute (NSA) object is used to provide
   information on the nodes characteristics.

   The NSA object MAY be present in the DAG Metric Container.  There
   MUST be no more than one NSA object as a constraint per DAG Metric
   Container, and no more than one NSA object as a metric per DAG Metric
   Container.

   The NSA object may also contain a set of TLVs used to convey various
   node characteristics.  No TLV is currently defined.

   The NSA Routing Metric/Constraint Type is to be assigned by IANA
   (recommended value=1).












Vasseur, et al.          Expires April 22, 2011                [Page 11]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


   The format of the NSA object body is as follows:

     0               1               2               3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
    |     Res       |  Flags    |A|O|  Optional TLVs
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...

                Figure 3: NSA object format

   Node workload may be hard to determine and express in some scalar
   form.  However, node workload could be a useful metric to consider
   during path calculation, in particular when queuing delays must be
   minimized for highly sensitive traffic considering Medium Access
   Control (MAC) layer delay.  Node workload MAY be set upon CPU
   overload, lack of memory or any other node related conditions.  Using
   a simple 1-bit flag to characterize the node workload provides a
   sufficient level of granularity, similarly to the "overload" bit used
   in routing protocols such as IS-IS.  Algorithms used to set the
   overload bit and to compute paths to potentially avoid nodes with
   their overload bit set are outside the scope of this document, but it
   is RECOMMENDED to avoid frequent changes of this bit to avoid routing
   oscillations.

   Data Aggregation Attribute: data fusion involves more complicated
   processing to improve the accuracy of the output data, while data
   aggregation mostly aims at reducing the amount of data.  This is
   listed as a requirement in Section 6.2 of [RFC5548].  Some
   applications may make use of the aggregation node attribute in their
   routing decision so as to minimize the amount of traffic on the
   network, thus potentially increasing its lifetime in battery operated
   environments.  Applications where highly directional data flow is
   expected on a regular basis may take advantage of data aggregation
   supported routing.

   The following two bits of the NSA object are currently defined:

   o  A Flag: When set, this indicates that the node can act as a
      traffic aggregator.  An implementation MAY decide to add optional
      TLVs (not currently defined) to further describe the node traffic
      aggregator functionality.

   o  O Flag: When set, this indicates that the node is overloaded and
      may not be able to process traffic.

   The Flag field of the NSA Routing Metric/Constraint object is managed
   by IANA.  Unassigned bits are considered as reserved.  They MUST be
   set to zero on transmission and MUST be ignored on receipt.



Vasseur, et al.          Expires April 22, 2011                [Page 12]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


3.2.  Node Energy object

   Whenever possible, a node with low residual energy should not be
   selected as a router, thus the support for constraint-based routing
   is needed.  In such cases, the routing protocol engine may compute a
   longer path (constraint based) for some traffic in order to increase
   the network life duration.

   The routing engine may prefer a "longer" path that traverses mains-
   powered nodes (in particular for routine traffic) or nodes equipped
   with energy scavenging, rather than a "shorter" path through battery
   operated nodes.

   Power and energy are clearly critical resources in most LLNs.  As yet
   there is no simple abstraction which adequately covers the broad
   range of power sources and energy storage devices used in existing
   LLN nodes.  These include mains-powered, primary batteries, energy
   scavengers, and a variety of secondary storage mechanisms.
   Scavengers may provide a reliable low level of power, such as might
   be available from a 4-20mA loop; a reliable but periodic stream of
   power, such as provided by a well-positioned solar cell; or
   unpredictable power, such as might be provided by a vibrational
   energy scavenger on an intermittently powered pump.  Routes which are
   viable when the sun is shining may disappear at night.  A pump
   turning on may connect two previously disconnected sections of a
   network.

   Storage systems like rechargeable batteries often suffer substantial
   degradation if regularly used to full discharge, leading to different
   residual energy numbers for regular versus emergency operation.  A
   route for emergency traffic may have a different optimum than one for
   regular reporting.

   Batteries used in LLNs often degrade substantially if their average
   current consumption exceeds a small fraction of the peak current that
   they can deliver.  It is not uncommon for self-supporting nodes to
   have a combination of primary storage, energy scavenging, and
   secondary storage, leading to three different values for acceptable
   average current depending on the time frame being considered, e.g.
   milliseconds, seconds, and hours/years.

   Raw power and energy values are meaningless without knowledge of the
   energy cost of sending and receiving packets, and lifetime estimates
   have no value without some higher-level constraint on the lifetime
   required of a device.  In some cases the path that exhausts the
   battery of a node on the bed table in a month may be preferable to a
   route that reduces the lifetime of a node in the wall to a decade.




Vasseur, et al.          Expires April 22, 2011                [Page 13]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


   Given the complexity of trying to address such a broad collection of
   constraints, this document defines three levels of fidelity in the
   solution.

   The simplest solution relies on a 2-bit field encoding three types of
   power sources: "powered", "battery", "scavenger".  This simple
   approach may be sufficient for many applications.

   The mid-complexity solution is a single parameter that can be used to
   encode the energetic happiness of both battery powered and scavenging
   nodes.  For scavenging nodes, the 8 bit quantity is the power
   provided by the scavenger divided by the power consumed by the
   application, H=P_in/P_out, in units of percent.  Nodes which are
   scavenging more power than they are consuming will register above
   100.  A good time period for averaging power in this calculation may
   be related to the discharge time of the energy storage device on the
   node, but specifying this is out of the scope of this document.  For
   battery powered devices, H is the current expected lifetime divided
   by the desired minimum lifetime.  The estimation of remaining battery
   energy and actual power consumption can be difficult, and the
   specifics of this calculation are out of scope of this document, but
   two examples are presented.  If the node can measure its average
   power consumption, then H can be calculated as the ratio of desired
   max power (initial energy E_0 divided by desired lifetime T) to
   actual power, H=P_max/P_now.  Alternatively, if the energy in the
   battery E_bat can be estimated, and the total elapsed lifetime, t, is
   available, then H can be calculated as the total stored energy
   remaining versus the target energy remaining: H= E_bat / [E_0
   (T-t)/T].

   An example of optimized route is max(min(H)) for all battery operated
   nodes along the route, subject to the constraint that H>=100 for all
   scavengers along the route.

   Note that the estimated percentage of remaining energy indicated in
   the E-E field may not be useful in the presence of nodes powered by
   battery or energy scavengers when the amount of energy accumulated by
   the device significantly differ.  Indeed, X% of remaining energy on a
   node that can store a large amount of energy cannot be easily
   compared to the same percentage of remaining energy on a node powered
   by a tiny source of energy.  That being said, in networks where nodes
   have relatively close energy storage, such a percentage of remaining
   energy is useful.  Other documents may define more complex/detailed
   mechanisms to represent these metric.

   The Node Energy (NE) object is used to provide information related to
   node energy and may be used as a metric or as constraint.




Vasseur, et al.          Expires April 22, 2011                [Page 14]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


   The NE object MAY be present in the DAG Metric Container.  There MUST
   be no more than one NE object as a constraint per DAG Metric
   Container, and no more than one NE object as a metric per DAG Metric
   Container.

   The NE object Type is to be assigned by IANA (recommended value=2).

   The format of the NE object body is as follows:

     0               1               2               3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
    |     NE Sub-objects
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...

      Figure 4: NE object format

   The format of the NE sub-object body is as follows:

     0               1               2               3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
    | Flags |I| T |E|      E-E      |   Optional TLVs
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...

            Figure 5: NE sub-object format

   The NE sub-object may also contain a set of TLVs used to convey
   various nodes' characteristics.

   The following flags are currently defined:

   o  I (Included): the I bit is only relevant when the node type is
      used as a constraint.  For example, the path must only traverse
      mains-powered nodes.  Conversely, battery operated nodes must be
      excluded.  The I bit is used to stipulate inclusion versus
      exclusion.  When set, this indicates that nodes of the type
      specified in the node type field MUST be included.  Conversely,
      when cleared, this indicates that nodes of type specified in the
      node type field MUST be excluded.

   o  T (node Type): 2-bit field indicating the node type.  E=0x00
      designates a mains-powered node, E=0x01 a battery-powered node and
      E=0x02 a node powered by an energy scavenger.

   o  E (Estimation): when the E bit is set for a metric, the estimated
      percentage of remaining energy on the node is indicated in the E-E
      8-bit field.  When cleared, the estimated percentage of remaining



Vasseur, et al.          Expires April 22, 2011                [Page 15]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


      energy is not provided.  When the E bit is set for a constraint,
      the E-E field defines a threshold for the inclusion/exclusion: if
      an inclusion, nodes with values higher than the threshold are to
      be included; if an exclusion, nodes with values lower than the
      threshold are to be excluded.

   E-E (Estimated-Energy): 8-bit unsigned integer field indicating an
   estimated percentage of remaining energy.  The E-E field is only
   relevant when the E flag is set, and MUST be set to 0 when the E flag
   is cleared.

   If the NE object comprises several sub-objects when used as a
   constraint, each sub-object adds or subtracts node subsets as the
   sub-objects are parsed in order.  The initial set (full or empty) is
   defined by the I bit of the first sub-object: full if that I bit is
   an exclusion, empty is that I bit is an inclusion.

   No TLV is currently defined.

   Future addenda to this document may include more complex solutions
   involving a half dozen TLV parameters representing energy storage,
   consumption, and generation capabilities of the node, as well as
   desired lifetime.

3.3.  Hop-Count object

   The HoP-Count (HP) object is used to report the number of traversed
   nodes along the path.

   The HP object MAY be present in the DAG Metric Container.  There MUST
   be no more than one HP object as a constraint per DAG Metric
   Container, and no more than one HP object as a metric per DAG Metric
   Container.

   The HP object may also contain a set of TLVs used to convey various
   node characteristics.  No TLV is currently defined.

   The HP routing metric object Type is to be assigned by IANA
   (recommended value=3)












Vasseur, et al.          Expires April 22, 2011                [Page 16]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


   The format of the Hop Count object body is as follows:

     0               1               2               3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
    |  Res  | Flags |   Hop Count   |  Optional TLVs
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...

               Figure 6: Hop Count object format

   No Flag is currently defined.

   The HP object may be used as a constraint or a metric.  When used as
   a constraint, the DAG root indicates the maximum number of hops that
   a path may traverse.  When that number is reached, no other node can
   join that path.  When used as a metric, each visited node simply
   increments the Hop Count field.


4.  Link Metric/Constraint objects

4.1.  Throughput

   Many LLNs support a wide range of throughputs.  For some links, this
   may be due to variable coding.  For the deeply duty-cycled links
   found in many LLNs, the variability comes as a result of trading
   power consumption for bit rate.  There are several MAC layer
   protocols which allow for the effective bit rate and power
   consumption of a link to vary over more than three orders of
   magnitude, with a corresponding change in power consumption.  For
   efficient operation, it may be desirable for nodes to report the
   range of throughput that their links can handle in addition to the
   currently available throughput.

   The Throughput object MAY be present in the DAG Metric Container.
   There MUST be no more than one Throughput object as a constraint per
   DAG Metric Container, and no more than one Throughput object as a
   metric per DAG Metric Container.

   The Throughput object is made of throughput sub-objects and MUST at
   least comprise one Throughput sub-object.  The first Throughput sub-
   object MUST be the most recently estimated actual throughput.  The
   actual estimation of the throughput is outside the scope of this
   document.

   Each Throughput sub-object has a fixed length of 4 bytes.

   The Throughput object does not contain any additional TLV.



Vasseur, et al.          Expires April 22, 2011                [Page 17]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


   The Throughput object Type is to be assigned by IANA (recommended
   value=4)

   The format of the Throughput object body is as follows:

    0               1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  (sub-object) .....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 8: Throughput object body format


    0               1               2               3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Throughput                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 9: Throughput sub-object format

   Throughput: 32 bits.  The Throughput is encoded in 32 bits in
   unsigned integer format, expressed in bytes per second.

4.2.  Latency

   Similarly to throughput, the latency of many LLN MAC sub-layers can
   vary over many orders of magnitude, again with a corresponding change
   in current consumption.  Some LLN MAC link layers will allow the
   latency to be adjusted globally on the subnet, on a link-by-link
   basis, or not at all.  Some will insist that it be fixed for a given
   link, but allow it to be variable from link to link.

   The Latency object MAY be present in the DAG Metric Container.  There
   MUST be no more than one Latency object as a constraint per DAG
   Metric Container, and no more than one Latency object as a metric per
   DAG Metric Container.

   The Latency object is made of Latency sub-objects and MUST at least
   comprise one Latency sub-object.  Each Latency sub-object has a fixed
   length of 4 bytes.

   The Latency object does not contain any additional TLV.

   The Latency object Type is to be assigned by IANA (recommended
   value=5)




Vasseur, et al.          Expires April 22, 2011                [Page 18]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


   The Latency object is a metric or constraint.

   The format of the Latency object body is as follows:

    0               1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  (sub-object) .....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 10: Latency object body format


    0               1               2               3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Latency                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 11: Latency sub-object format

   Latency: 32 bits.  The Latency is encoded in 32 bits in unsigned
   integer format, expressed in microseconds.

   The Latency object may be used as a constraint or a path metric.  For
   example, one may want the latency not to exceed some value.  In this
   case, the Latency object common header indicates that the provided
   value relates to a constraint.  In another example, the Latency
   object may be used as an aggregated additive metric where the value
   is updated along the path to reflect the path latency.

4.3.  Link reliability

   In LLNs, link reliability is degraded by external interference and
   multi-path interference (wireless links).  Multipath typically
   affects both directions on the link equally, whereas external
   interference is sometimes unidirectional.  Time scales vary from
   milliseconds to days, and are often periodic and linked to human
   activity.  Packet error rates can generally be measured directly, and
   other metrics (e.g. bit error rate, mean time between failures) are
   typically derived from that.  Note that such variability is not
   specific to wireless link but also applies to PLC links.

   A change in link quality can affect network connectivity, thus, link
   quality may be taken into account as a critical routing metric.

   A number of link reliability metrics could be defined reflecting
   several reliability aspects.  Two link reliability metrics are



Vasseur, et al.          Expires April 22, 2011                [Page 19]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


   defined in this document: the Link Quality Level (LQL) and the
   Expected Transmission count Metric (ETX).

   Note that an RPL implementation MAY either use the LQL, the ETX or
   both.

4.3.1.  The Link Quality Level reliability metric

   The Link Quality Level (LQL) object is used to quantify the link
   reliability using a discrete value, from 0 to 7 where 0 indicates
   that the link quality level is unknown and 1 reports the highest link
   quality level.  The mechanisms and algorithms used to compute the LQL
   are implementation specific and outside of the scope of this
   document.

   The LQL can either be used as a metric or a constraint.  When used as
   a metric, the LQL metric can be recorded or aggregated.  For example,
   the DAG Metric object may request all traversed nodes to record the
   LQL of their incoming link into the LQL object.  Each node can then
   use the LQL record to select its parent based on some user defined
   rules (e.g. something like "select the path with most links reporting
   a LQL value of 3 or less").  By contrast, the LQL link metric may be
   aggregated, in which case the sum of all LQLs may be reported
   (additive metric) or the minimum value may be reported along the
   path.

   When used as a recorded metric, counters are used to compress the
   information: for each encountered LQL value, only the number of
   matching links is reported.

   The LQL object MAY be present in the DAG Metric Container.  There
   MUST be no more than one LQL object as a constraint per DAG Metric
   Container, and no more than one LQL object as a metric per DAG Metric
   Container.

   The LQL object MUST contain one or more sub-object used to report the
   number of links along with their LQL.

   The LQL object Type is to be assigned by IANA (recommended value=6)












Vasseur, et al.          Expires April 22, 2011                [Page 20]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


   The format of the LQL object body is as follows:

     0               1               2               3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
    |       Res     | LQL sub-object
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...

      Figure 12: LQL object format

   When the LQL metric is recorded, the LQL object body comprises one or
   more LQL Type 1 sub-object.

   The format of the LQL Type 1 sub-object is as follows

     0
     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    | Val | Counter |
    +-+-+-+-+-+-+-+-+

    Figure 13: LQL Type 1 sub-object format

   Val: LQL value from 0 to 7 where 0 means undetermined and 1 indicates
   the highest link quality.

   Counter: number of links with that value.

   When the LQL metric is aggregated, the LQL object body comprises one
   LQL Type 2 sub-object:

   The format of the LQL Type 2 sub-object is as follows

     0               1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Aggregated LQL Value     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 14: LQL Type 2 sub-object format

   Aggregated LQL Value: when used as an additive metric (A=0x00), the
   aggregated LQL value reports the sum of all the LQL values for all
   links along the path.  When used to report a minimum (A=0x02), the
   field reports the minimum LQL value of all links along the path,
   ignoring undetermined LQLs (Aggregated LQL Value = 0).  When used to
   report a maximum (A=0x01), the field reports the maximum LQL value of
   all links along the path.  When used to report a multiplication



Vasseur, et al.          Expires April 22, 2011                [Page 21]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


   (A=0x03), and the LQL field of one of the links along the path is
   undetermined (LQL=0), the undetermined LQL will be ignored and not be
   aggregated (i.e. no reset to Aggregated LQL Value field).

4.3.2.  The Expected Transmission Count (ETX) reliability object

   The Expected Transmission Count (ETX) metric is the number of
   transmissions a node expects to make to a destination in order to
   successfully deliver a packet.

   For example, an implementation may use the following formula: ETX= 1
   / (Df * Dr) where Df is the measured probability that a packet is
   received by the neighbor and Dr is the measured probability that the
   acknowledgment packet is successfully received.  This document does
   not mandate the use of a specific formula to compute the ETX value.

   The ETX object MAY be present in the DAG Metric Container.  There
   MUST be no more than one ETX object as a constraint per DAG Metric
   Container, and no more than one ETX object as a metric per DAG Metric
   Container.

   The ETX object is made of ETX sub-objects and MUST at least comprise
   one ETX sub-object.  Each ETX sub-object has a fixed length of 8
   bits.

   The ETX object does not contain any additional TLV.

   The ETX object Type is to be assigned by IANA (recommended value=7)























Vasseur, et al.          Expires April 22, 2011                [Page 22]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


   The format of the ETX object body is as follows:

    0               1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  (sub-object) .....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 15: ETX object body format


    0               1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              ETX              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 16: ETX sub-object format

   ETX: 16 bits.  The ETX * 128 is encoded using 16 bits in unsigned
   integer format, rounded off to the nearest whole number.  For
   example, if ETX = 3.569, the object value will be 457.  If ETX >
   511.9921875, the object value will be the maximum which is 65535.

   The ETX object may be used as a constraint or a path metric.  For
   example, it may be required that the ETX must not exceed some
   specified value.  In this case, the ETX object common header
   indicates that the value relates to a constraint.  In another
   example, the ETX object may be used as an aggregated additive metric
   where the value is updated along the path to reflect the path
   quality.

4.4.  Link Color object

4.4.1.  Link Color object description

   The Link Color (LC) object is an administrative 10-bit link
   constraint (which may either be static or dynamically adjusted) used
   to avoid or attract specific links for specific traffic types.

   The LC object can either be used as a metric or as a constraint.
   When used as a metric, the LC metric can only be recorded.  For
   example, the DAG may require recording the link colors for all
   traversed links.  Each node can then use the LC to select the parent
   based on user defined rules (e.g. "select the path with the maximum
   number of links having their first bit set 1 (e.g. encrypted
   links)").  The LC object may also be used as a constraint.




Vasseur, et al.          Expires April 22, 2011                [Page 23]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


   When used as a recorded metric, a counter is used to compress the
   information where the number of links for each Link Color is
   reported.

   The Link Color (LC) object MAY be present in the DAG Metric
   Container.  There MUST be no more than one LC object as a constraint
   per DAG Metric Container, and no more than one LC object as a metric
   per DAG Metric Container.

   There MUST be a at least one LC sub-object per LC object.

   The LC object does not contain any additional TLV.

   The LC object Type is to be assigned by IANA (recommended value=8)

   The format of the LC object body is as follows:

     0               1               2               3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
    |      Res      | LC sub-objects
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...

      Figure 17: LC object format

   When the LC object is used as a recorded metric, the LC object body
   comprises one or more LC Type 1 sub-objects.

   The format of the LC Type 1 sub-object body is as follows:

    0               1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Link Color     |  Counter  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 18: LC Type 1 sub-object format

   When the LC object is used as a constraint, the LC object body
   comprises one or more LC Type 2 sub-objects.











Vasseur, et al.          Expires April 22, 2011                [Page 24]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


   The format of the LC Type 2 sub-object body is as follows:

    0               1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Link Color        |I|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 19: LC Type 2 sub-object format

   I Bit: The I bit is only relevant when the Link Color is used as a
   constraint.  When cleared, this indicates that links with the
   specified color must be included.  When set, this indicates that
   links with the specified color must be excluded.

   The use of the LC object is outside the scope of this document.

4.4.2.  Mode of operation

   The link color may be used as a constraint or a metric.

   o  When used as constraint, the LC object may be inserted in the DAG
      Metric Container to indicate that links with a specific color
      should be included or excluded from the computed path.

   o  When used as recorded metric, each node along the path may insert
      a LC object in the DAG Metric Container to report the color of the
      local link.  If there is already a LC object reporting a similar
      color, the node MUST NOT add another identical LC sub-object and
      MUST increment the counter field.


5.  Computation of dynamic metrics and attributes

   As already pointed out, dynamically calculated metrics are of the
   utmost importance in many circumstances in LLNs.  This is mainly
   because a variety of metrics change on a frequent basis, thus
   implying the need to adapt the routing decisions.  That being said,
   care must be given to the pace at which changes are reported in the
   network.  The attributes will change according to their own time
   scales.  RPL controls the reporting rate.

   To minimize metric updates, multi-threshold algorithms MAY be used to
   determine when updates should be sent.  When practical, low-pass
   filtering and/or hysteresis should be used to avoid rapid
   fluctuations of these values.  Finally, although the specification of
   path computation algorithms using dynamic metrics are out the scope
   of this document, it is RECOMMENDED to carefully design the route



Vasseur, et al.          Expires April 22, 2011                [Page 25]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


   optimization algorithm to avoid too frequent computation of new
   routes upon metric values changes.

   Controlled adaptation of the routing metrics and rate at which paths
   are computed are critical to avoid undesirable routing instabilities
   resulting in increased latencies and packet loss because of temporary
   micro-loops.  Furthermore, excessive route changes will adversely
   impact the traffic and power consumption in the network, thus
   potentially impacting its scalability.


6.  IANA Considerations

   IANA is requested to establish a new top-level registry to contain
   all Routing Metric/Constraint objects codepoints and sub-registries.

   The allocation policy for each new registry is by IETF Consensus: new
   values are assigned through the IETF consensus process (see
   [RFC5226]).  Specifically, new assignments are made via RFCs approved
   by the IESG.  Typically, the IESG will seek input on prospective
   assignments from appropriate persons (e.g., a relevant Working Group
   if one exists).

6.1.  Routing Metric/Constraint type

   IANA is requested to create a registry for Routing Metric/Constraint
   objects.  Each Routing Metric/Constraint object has a type value.

   Value     Meaning                          Reference
     1       Node State and Attribute      This document
     2       Node Energy                   This document
     3       Hop Count                     This document
     4       Link Throughput               This document
     5       Link Latency                  This document
     6       Link Quality Level            This document
     7       Link ETX                      This document
     8       Link Color                    This document

6.2.  Routing Metric/Constraint common header

   IANA is requested to create a registry to manage the codespace of the
   A field of the Routing Metric/Constraint common header.









Vasseur, et al.          Expires April 22, 2011                [Page 26]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


   Codespace of the A field (Routing Metric/Constraint common header)
    Value  Meaning                              Reference

      0    Routing metric is additive           This document
      1    Routing metric reports a maximum     This document
      2    Routing metric reports a minimum     This document
      3    Routing metric is multiplicative     This document

   IANA is requested to create a registry to manage the Flag field of
   the Routing Metric/Constraint common header.

   New bit numbers may be allocated only by an IETF Consensus action.
   Each bit should be tracked with the following qualities:

   o  Bit number

   o  Capability Description

   o  Defining RFC

   Several bits are defined for the Routing Metric/Constraint common
   header in this document.  The following values have been assigned:

   Codespace of the Flag field (Routing Metric/Constraint common header)
     Bit      Description              Reference

      12-15   Precedence               This document
      9-11   Additive/Max/Min/Multi   This document
      8       Recorded/Aggregated      This document
      7       Optional Constraint      This document
      6       Constraint/Metric        This document
      5       P (Partial)              This document

6.3.  NSA object

   IANA is requested to create a registry to manage the codespace of the
   Flag field of the NSA object.

   New bit numbers may be allocated only by an IETF Consensus action.
   Each bit should be tracked with the following qualities:

   o  Bit number

   o  Capability Description

   o  Defining RFC

   Several bits are defined for the NSA object flag field in this



Vasseur, et al.          Expires April 22, 2011                [Page 27]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


   document.  The following values have been assigned:

   Codespace of the Flag field (NSA object)
     Bit      Description              Reference

      14      Aggregator               This document
      15      Overloaded               This document

6.4.  Hop-Count object

   IANA is requested to create a registry to manage the codespace of the
   Flag field of the Hop-count object.

   New bit numbers may be allocated only by an IETF Consensus action.
   Each bit should be tracked with the following qualities:

   o  Bit number

   o  Capability Description

   o  Defining RFC

   No Flag is currently defined.


7.  Security considerations

   Routing metrics should be handled in a secure and trustful manner.
   For instance, RPL should not allow a malicious node to falsely
   advertise that it has good metrics for routing, be added as a router
   for other nodes' traffic and intercept packets.  Since the routing
   metrics/constraints are carried within RPL message, the security
   routing mechanisms defined in [I-D.ietf-roll-rpl] applies here.


8.  Acknowledgements

   The authors would like to acknowledge the contributions of Young Jae
   Kim, Hakjin Chong, David Meyer, Mischa Dohler, Anders Brandt, Philip
   Levis, Pascal Thubert, Richard Kelsey, Jonathan Hui, Alexandru
   Petrescu, Richard Kelsey, Mathilde Durvy, Phoebus Chen, Tim Winter,
   Mukul Goyal, Yoav Ben-Yehezkel, Matteo Paris, Omprakash Gnawali, Mads
   Westergreen and Mukul Goyal for their review and valuable comments.


9.  References





Vasseur, et al.          Expires April 22, 2011                [Page 28]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


9.1.  Normative references

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

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

9.2.  Informative references

   [I-D.ietf-roll-rpl]
              Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
              Kelsey, R., Levis, P., Networks, D., Struik, R., and J.
              Vasseur, "RPL: IPv6 Routing Protocol for Low power and
              Lossy Networks", draft-ietf-roll-rpl-12 (work in
              progress), October 2010.

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

   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, December 1990.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC2702]  Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
              McManus, "Requirements for Traffic Engineering Over MPLS",
              RFC 2702, September 1999.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.

   [RFC3471]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Functional Description", RFC 3471,
              January 2003.

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




Vasseur, et al.          Expires April 22, 2011                [Page 29]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


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


Authors' Addresses

   JP Vasseur (editor)
   Cisco Systems, Inc
   11, Rue Camille Desmoulins
   Issy Les Moulineaux,   92782
   France

   Email: jpv@cisco.com


   Mijeom Kim (editor)
   Corporate Technology Group, KT
   17 Woomyeon-dong, Seocho-gu
   Seoul,   137-792
   Korea

   Email: mjkim@kt.com


   Kris Pister
   Dust Networks
   30695 Huntwood Ave.
   Hayward, CA  95544
   USA

   Email: kpister@dustnetworks.com


   Nicolas Dejean
   Coronis SAS
   Espace Concorde, 120 impasse JB Say
   Perols,   34470
   France

   Email: nicolas.dejean@coronis.com






Vasseur, et al.          Expires April 22, 2011                [Page 30]

Internet-Draft     draft-ietf-roll-routing-metrics-10       October 2010


   Dominique Barthel
   France Telecom Orange
   28 chemin du Vieux Chene, BP 98
   Meylan,   38243
   France

   Email: dominique.barthel@orange-ftgroup.com












































Vasseur, et al.          Expires April 22, 2011                [Page 31]


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