Subject: [Roll] [roll] #48: Manageability section - next update

From: "roll issue tracker" <[email-masked]>
Date: Mon, 07 Jun 2010 09:00:29 -0000

#48: Manageability section - next update
--------------------------------+-------------------------------------------
 Reporter:  jpv@…               |       Owner:  jpv@…        
     Type:  defect              |      Status:  new          
 Priority:  minor               |   Milestone:               
Component:  rpl                 |     Version:               
 Severity:  Active WG Document  |    Keywords:               
--------------------------------+-------------------------------------------
 Add:
 * comments on Default values not derived to experimental/field experience
 * security updates

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/roll/trac/ticket/48>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Sat, 12 Jun 2010 06:46:22 -0000

Comment(by jpv@…):

 Also add:

 Phoebus> Umm, are you sure it's a good idea to punt on this issue? Limited
 memory and interoperability has been stressed so much on this mailing
 list. I would hate to be the poor guy trying to debug a network where the
 devices came from different vendors and each had a different table
 eviction policy. Are you going to at least specify some sort of a standard
 error message to send back to the root in this situation?

 JP> The answer to this question is "yes", this will go in the
 manageability section of the I-D (I'll open a ticket for this), good
 point.

-- 
Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/48#comment:1>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Sat, 26 Jun 2010 07:36:40 -0000

#48: Manageability section - next update
--------------------------------+-------------------------------------------
 Reporter:  jpv@…               |        Owner:  jpv@…        
     Type:  defect              |       Status:  closed       
 Priority:  minor               |    Milestone:               
Component:  rpl                 |      Version:               
 Severity:  Active WG Document  |   Resolution:  fixed        
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by jpv@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 ---------------------------------------
 Here is the new text closing the issue to be posted in
 revision 10 of RPL (to be posted on June 28 or 29)

 15.  Manageability Considerations

    The aim of this section is to give consideration to the manageability
    of RPL, and how RPL will be operated in a LLN.  The scope of this
    section is to consider the following aspects of manageability:
    configuration, monitoring, fault management, accounting, and
    performance of the protocol in light of the recommendations set forth
    in [RFC5706].

 Winter, et al.          Expires December 13, 2010              [Page 80]
 Internet-Draft           draft-ietf-roll-rpl-09                 Jun 2010

 15.1.  Introduction

    Most of the existing IETF management standards are Structure of
    Management Information (SMI) based data models (MIB modules) to
    monitor and manage networking devices.

    For a number of protocols, the IETF community has used the IETF
    Standard Management Framework, including the Simple Network
    Management Protocol [RFC3410], the Structure of Management
    Information [RFC2578], and MIB data models for managing new
    protocols.

    As pointed out in [RFC5706], the common policy in terms of operation
    and management has been expanded to a policy that is more open to a
    set of tools and management protocols rather than strictly relying on
    a single protocol such as SNMP.

    In 2003, the Internet Architecture Board (IAB) held a workshop on
    Network Management [RFC3535] that discussed the strengths and
    weaknesses of some IETF network management protocols and compared
    them to operational needs, especially configuration.

    One issue discussed was the user-unfriendliness of the binary format
    of SNMP [RFC3410].  In the case of LLNs, it must be noted that at the
    time of writing, the CoRE Working Group is actively working on
    resource management of devices in LLNs.  Still, it is felt that this
    section provides important guidance on how RPL should be deployed,
    operated, and managed.

    As stated in [RFC5706], "A management information model should
    include a discussion of what is manageable, which aspects of the
    protocol need to be configured, what types of operations are allowed,
    what protocol-specific events might occur, which events can be
    counted, and for which events an operator should be notified".  These
    aspects are discussed in detail in the following sections.

    RPL will be used on a variety of devices that may have resources such
    as memory varying from a very few Kbytes to several hundreds of
    Kbytes and even Mbytes.  When memory is highly constrained, it may
    not be possible to satisfy all the requirements listed in this
    section.  Still it is worth listing all of these in an exhaustive
    fashion, and implementers will then determine which of these
    requirements could be satisfied according to the available resources
    on the device.

 Winter, et al.          Expires December 13, 2010              [Page 81]
 Internet-Draft           draft-ietf-roll-rpl-09                 Jun 2010

 15.2.  Configuration Management

 15.2.1.  Initialization Mode

    "Architectural Principles of the Internet" [RFC1958], Section 3.8,
    states: "Avoid options and parameters whenever possible.  Any options
    and parameters should be configured or negotiated dynamically rather
    than manually.  This especially true in LLNs where the number of
    devices may be large and manual configuration is infeasible.  This
    has been taken into account in the design of RPL whereby the DODAG
    root provides a number of parameters to the devices joining the
    DODAG, thus avoiding cumbersome configuration on the routers and
    potential sources of misconfiguration (e.g. values of trickle timers,
    ...).  Still there are additional RPL parameters that a RPL
    implementation should allow to be configured, which are discussed in
    this section.

 15.2.1.1.  DIS mode of operation upon boot-up

    When a node is first powered up, it may choose:

 (1) To stay silent, waiting to receive DIO messages from DODAG of interest
 (advertizing a supported OF and metrics/constraints) and not send any
 multicast DIO messages until it has joined a DODAG.
 (2) The node may decide to send one or more DIS messages (optionally
 requesting DIO for a specific DODAG) message as an initial probe for
 nearby DODAGs, and in the absence of DIO messages in reply after some
 configurable period of time, the node may decide to root a floating DODAG
 and start sending multicast DIO messages.

 A RPL implementation SHOULD allow configuring the preferred mode of
 operation listed above along with the required parameters (in the second
 mode: number of DIS messages and related timer).

 15.2.2.  DIO and DAO Base Message and Options Configuration

    RPL specifies a number of protocol parameters considering the large
    spectrum of applications where it will be used.  That said,
    particular attention has been given to limiting the number of these
    parameters that must be configured on each RPL router.  Instead, a
    number of the default values can be used, and when required these
    parameters can be provided by the DODAG root thus allowing for
    dynamic parameter setting.

    A RPL implementation SHOULD allow configuring the following routing
    protocol parameters.  As pointed out above, note that a large set of
    parameters is configured on the DODAG root.

 Winter, et al.          Expires December 13, 2010              [Page 82]
 Internet-Draft           draft-ietf-roll-rpl-09                 Jun 2010

 15.2.3.  Protocol Parameters to be configured on every router in the LLN

    o  RPLInstanceID [DIO message, in DIO base message].  Although the
       RPLInstanceID must be configured on the DODAG root, it must also
       be configured as a policy on every node in order to determine
       whether or not the node should join a particular DODAG.  Note that
       a second RPLInstance can be configured on the node, should it
       become root of a floating DODAG.

    o  Objective Code Point (OCP)

    o List of supported metrics: [I-D.ietf-roll-routing-metrics] specifies
 a number of metrics and constraints used for the DAG formation. Thus a RPL
 implementation should allow configuring the list of metrics that a node
 can accept and understand.  If a DIO is received with a metric and/or
 constraint that is not understood or supported, as specified in Section
 7.5, the node would join as a leaf node.

    o  DODAGID [DIO, DIO base option] and [DAO message when the D flag of
       the DAO message is set).

    o  Route Information (and preference) [DIO message, in Route
       Information option]

    o  Solicited Information [DIS message, in Solicited Information
       option].  Note that an RPL implementation SHOULD allow configuring
       when such messages should be sent and under which circumstances,
       along with the value of the RPLInstance ID, V/I/D flags.

    o  K flag [DAO message, in DAO base message].

    o  MOP (Mode of Operation) [DIO message, in DIO base message]

 15.2.4.  Protocol Parameters to be configured on every non-root router in
 the LLN

    o  Target prefix [DAO, in RPL Target option and DIO messages]

    o  Transit information [DAO, Transit information option]: A RPL
       implementation SHOULD allow configuring whether a non-storing node
       provides the transit information in DAO messages.

    A node whose DODAG parent set is empty may become the DODAG root of a
    floating DODAG.  It may also set its DAGPreference such that it is
    less preferred.  Thus a RPL implementation MUST allow configuring the
    set of actions that the node should initiate in this case:

 Winter, et al.          Expires December 13, 2010              [Page 83]
 Internet-Draft           draft-ietf-roll-rpl-09                 Jun 2010

    o  Start its own (floating) DODAG: the new DODAGID must be configured
       in addition to its DAGPreference

    o  Poison the broken path (see procedure in Section 7.2.2.5)

    o  Trigger a local repair

 15.2.5.  Parameters to be configured on the DODAG root

    In addition, several other parameters are configured only on the
    DODAG root and advertised in options carried in DIO messages.

    As specified in Section 7.3, a RPL implementation makes use of
    trickle timers to govern the sending of DIO messages.  The operation
    of the trickle algorithm is determined by a set of configurable
    parameters, which MUST be configurable and that are then advertised
    by the DODAG root along the DODAG in DIO messages.

    o  DIOIntervalDoublings [DIO, in DODAG configuration option]

    o  DIOIntervalMin [DIO, in DODAG configuration option]

    o  DIORedundancyConstant [DIO, in DODAG configuration option]

    In addition, a RPL implementation SHOULD allow for configuring the
    following set of RPL parameters:

    o  Path Control Size [DIO, in DODAG configuration option]

    o  MinHopRankIncrease [DIO, in DODAG configuration option]

    o  The following flags: A, MOP (Mode of Operation), DODAGPreference
       field [DIO message, DIO Base object]

    o  Route information (list of prefixes with preference) [DIO message,
       in Route Information option]

    o  The T flag allows for triggering a refresh of the downward routes.
       A RPL implementation SHOULD support manual setting of the T flag
       or upon the occurrence of a set of event such as the expiration of
       a configurable periodic timer.

    o  List of metrics and constraints used for the DODAG.

    o  Prefix information along with valid and preferred lifetime and the
       L and A flags.  [DIO message, Prefix Information option].  A RPL
       implementation SHOULD allow configuring if the Prefix Information
       Option must be carried with the DIO message to distribute the

 Winter, et al.          Expires December 13, 2010              [Page 84]
 Internet-Draft           draft-ietf-roll-rpl-09                 Jun 2010

       prefix information for auto-configuration.  In that case, the RPL
       implementation MUST allow the list of prefixes to be advertised in
       the Prefix Information Option along with the corresponding flags.

    DAG Root behavior: in some cases, a node may not want to permanently
    act as a floating DODAG root if it cannot join a grounded DODAG.  For
    example a battery-operated node may not want to act as a floating
    DODAG root for a long period of time.  Thus a RPL implementation MAY
    support the ability to configure whether or not a node could act as a
    floating DODAG root for a configured period of time.

    DAG Version Number Increment: a RPL implementation may allow by
    configuration at the DODAG root to refresh the DODAG states by
    updating the DODAGVersionNumber.  A RPL implementation SHOULD allow
    configuring whether or not periodic or event triggered mechanisms are
    used by the DODAG root to control DODAGVersionNumber change (which
    triggers a global repair as specified in Section 3.3.2.

 15.2.6.  Configuration of RPL Parameters related to DAO-based mechanisms

    DAO messages are optional and used in DODAGs that require downward
    routing operation.  This section deals with the set of parameters
    related to DAO message and provides recommendations on their
    configuration.

    An implementation SHOULD bound the time that the entry is allocated
    in the UNREACHABLE state.  Upon the equivalent expiry of the related
    timer (RemoveTimer), the entry SHOULD be suppressed.  Thus a RPL
    implementation MAY allow for the configuration of the RemoveTimer.

    While the entry is in the UNREACHABLE state a node SHOULD make a
    reasonable attempt to report a No-Path to each of the DAO parents.
    That number of attempts MAY be configurable.

    When the associated Retry Counter for a REACHABLE(Pending) entry
    reaches a maximum threshold, the entry is placed into the UNREACHABLE
    state and No-Path should be scheduled to send to the node's DAO
    Parents.  The maximum threshold MAY be configurable.

    An implementation should support rate-limiting the sending of DAO
    messages.  The related parameters MAY be configurable.

    When scheduling to send a DAO, an implementation should equivalently
    start a timer (DelayDAO) to delay sending the DAO, thus helping to
    potentially aggregate DAOs.  The DelayDAO timer MAY be configurable.

 15.2.7.  Default Values

 Winter, et al.          Expires December 13, 2010              [Page 85]
 Internet-Draft           draft-ietf-roll-rpl-09                 Jun 2010

 This document specifies default values for the following set of RPL
 variables:
 •       DEFAULT_PATH_CONTROL_SIZE
 •       DEFAULT_DIO_INTERVAL_MIN
 •       DEFAULT_DIO_INTERVAL_DOUBLINGS
 •       DEFAULT_DIO_REDUNDANCY_CONSTANT
 •       DEFAULT_MIN_HOP_RANK_INCREASE

 It is recommended to specify default values in protocols; that being said,
 as discussed in [RFC5706], default values may make less and less sense.
 RPL is a routing protocol that is expected to be used in a number of
 contexts where network characteristics such as the number of nodes, link
 and nodes types are expected to vary significantly. Thus, these default
 values are likely to change with the context and as the technology will
 evolve. Indeed, LLNs’ related technology (e.g. hardware, link layers) have
 been evolving dramatically over the past few years and such technologies
 are expected to change and evolve considerably in the coming years.

 The proposed values are not based on extensive best current practices and
 are considered to be conservative.

 15.3.  Monitoring of RPL Operation

    Several RPL parameters should be monitored to verify the correct
    operation of the routing protocol and the network itself.  This
    section lists the set of monitoring parameters of interest.

 15.3.1.  Monitoring a DODAG parameters

    A RPL implementation SHOULD provide information about the following
    parameters:

    o  DODAG Version number [DIO message, in DIO base message]

    o  Status of the G flag [DIO message, in DIO base message]

    o  Status of the A flag [DIO message, in DIO base message]

    o  Value of the DTSN [DIO message, in DIO base message]

    o  Value of the rank [DIO message, in DIO base message]

    o  DAOSequence: Incremented at each unique DAO message, echoed in the
       DAO-ACK message [DAO and DAO-ACK messages]

    o  Route Information [DIO message, Route Information option] (list of
       IPv6 prefixes per parent along with lifetime and preference]

    o  Trickle parameters:

       *  DIOIntervalDoublings [DIO, in DODAG configuration option]

       *  DIOIntervalMin [DIO, in DODAG configuration option]

       *  DIORedundancyConstant [DIO, in DODAG configuration option]

    o  Path Control Size [DIO, in DODAG configuration option]

    o  MinHopRankIncrease [DIO, in DODAG configuration option]

    Values that may be monitored only on the DODAG root

    o  Transit Information [DAO, Transit Information option]: A RPL
       implementation SHOULD allow configuring whether the set of
       received Transit Information options should be displayed on the
       DODAG root.  In this case, the RPL database of received Transit
       Information should also contain: the path-sequence, path control,
       path lifetime and parent address.

 Winter, et al.          Expires December 13, 2010              [Page 86]
 Internet-Draft           draft-ietf-roll-rpl-09                 Jun 2010

 15.3.2.  Monitoring a DODAG inconsistencies and loop detection

    Detection of DODAG inconsistencies is particularly critical in RPL
    networks.  Thus it is recommended for a RPL implementation to provide
    appropriate monitoring tools.  A RPL implementation SHOULD provide a
    counter reporting the number of a times the node has detected an
    inconsistency with respect to a DODAG parent, e.g. if the DODAGID has
    changed.

    When possible more granular information about inconsistency detection
    should be provided.  A RPL implementation MAY provide counters
    reporting the number of following inconsistencies:

    o  Packets received with O bit set (to down) from a node with a
       higher rank

    o  Packets received with O bit reset (to up) from a node with a lower
       rank

    o  Number of packets with the F bit set

    o  Number of packets with the R bit set

 15.4.  Monitoring of the RPL data structures

 15.4.1.  Candidate Neighbor Data Structure

    A node in the candidate neighbor list is a node discovered by the
    some means and qualified to potentially become a parent (with high
    enough local confidence).  A RPL implementation SHOULD provide a way
    to monitor the candidate neighbor list with some metric reflecting
    local confidence (the degree of stability of the neighbors) as
    measured by some metrics.

    A RPL implementation MAY provide a counter reporting the number of
    times a candidate neighbor has been ignored, should the number of
    candidate neighbors exceeds the maximum authorized value.

 15.4.2.  Destination Oriented Directed Acyclic Graph (DAG) Table

    For each DODAG, a RPL implementation is expected to keep track of the
    following DODAG table values:

    o  RPLInstanceID

    o  DODAGID

 Winter, et al.          Expires December 13, 2010              [Page 87]
 Internet-Draft           draft-ietf-roll-rpl-09                 Jun 2010

    o  DODAGVersionNumber

    o  Rank

    o  Objective Code Point

    o  A set of DODAG Parents

    o  A set of prefixes offered upwards along the DODAG

    o  Trickle timers used to govern the sending of DIO messages for the
       DODAG

    o  List of DAO parents

    o  DTSN

    o  Node status (router versus leaf)

    A RPL implementation SHOULD allow for monitoring the set of
    parameters listed above.

 15.4.3.  Routing Table and DAO Routing Entries

    A RPL implementation maintains several information elements related
    to the DODAG and the DAO entries (for storing nodes).  In the case of
    a non storing node, a limited amount of information is maintained
    (the routing table is mostly reduced to a set of DODAG parents along
    with characteristics of the DODAG as mentioned above) whereas in the
    case of storing nodes, this information is augmented with routing
    entries.

    A RPL implementation SHOULD provide the ability to monitor the
    following parameters:

    o  Next Hop (DODAG parent)

    o  Next Hop Interface

    o  Path metrics value for each DODAG parent

    A DAO Routing Table Entry conceptually contains the following
    elements (for storing nodes only):

    o  Advertising Neighbor Information

    o  IPv6 Address

 Winter, et al.          Expires December 13, 2010              [Page 88]
 Internet-Draft           draft-ietf-roll-rpl-09                 Jun 2010

    o  Interface ID to which DAO Parents has this entry been reported

    o  Retry Counter

    o  Logical equivalent of DAO Content:

       *  DAO Sequence

       *  DAO Lifetime

       *  DAO Path Control

    o  Destination Prefix (or Address or Mcast Group)

    A RPL implementation SHOULD provide information about the state of
    each DAO Routing Table entry states.

 15.5.  Fault Management

    Fault management is a critical component used for troubleshooting,
    verification of the correct mode of operation of the protocol,
    network design, and is also a key component of network performance
    monitoring.  A RPL implementation SHOULD allow providing the
    following information related to fault managements:

    o  Memory overflow along with the cause (e.g. routing tables
       overflow, ...)

    o  Number of times a packet could not be sent to a DODAG parent
       flagged as valid

    o  Number of times a packet has been received for which the router
       did not have a corresponding RPLInstanceID

    o  Number of times a local repair procedure was triggered

    o  Number of times a global repair was triggered by the DODAG root

    o  Number of received malformed messages

    o  Number of seconds with packets to forward and no next hop (DODAG
       parent)

   o Number of seconds without next hop (DODAG parent)

  o Number of times a node has joined a DODAG as a leaf because it received
 a DIO with metric/constraint not understood and it was configured to join
 as a leaf node in this case (see section 15.6).

 It is RECOMMENDED to report faults via at least error log messages. Other
 protocols may be used to report such faults.

 Winter, et al.          Expires December 13, 2010              [Page 89]
 Internet-Draft           draft-ietf-roll-rpl-09                 Jun 2010

 15.6.  Policy

    Policy rules can be used by a RPL implementation to determine whether
    or not the node is allowed to join a particular DODAG advertised by a
    neighbor by means of DIO messages.

    This document specifies operation within a single DODAG.  A DODAG is
    characterized by the following tuple (RPLInstanceID, DODAGID).
    Furthermore, as pointed out above, DIO messages are used to advertise
    other DODAG characteristics such as the routing metrics and
    constraints used to build to the DODAG and the Objective Function in
    use (specified by OCP).

    The first policy rules consists of specifying the following
    conditions that a RPL node must satisfy to join a DODAG:

    o  RPLInstanceID

    o  DODAGID

    o  List of supported routing metrics and constraints

    o  Objective Function (OCP values)

    A RPL implementation MUST allow configuring these parameters and
    SHOULD specify whether the node must simply ignore the DIO if the
    advertised DODAG is not compliant with the local policy or whether
    the node should join as the leaf node if only the list of supported
    routing metrics and constraints, and the OF is not supported.

    A RPL implementation SHOULD allow configuring the set of acceptable
    or preferred Objective Functions (OF) referenced by their Objective
    Codepoints (OCPs) for a node to join a DODAG, and what action should
    be taken if none of a node's candidate neighbors advertise one of the
    configured allowable Objective Functions, or if the advertized
 metrics/constraint is not understood/supported. Two actions can be taken
 in this case:

 o The node joins the DODAG as a leaf node as specified in Section 7.5
 o The node does not join the DODAG

    A node in an LLN may learn routing information from different routing
    protocols including RPL.  It is in this case desirable to control via
    administrative preference which route should be favored.  An
    implementation SHOULD allow for specifying an administrative
    preference for the routing protocol from which the route was learned.

    Internal Data Structures: some RPL implementations may limit the size
    of the candidate neighbor list in order to bound the memory usage, in
    which case some otherwise viable candidate neighbors may not be
    considered and simply dropped from the candidate neighbor list.

    A RPL implementation MAY provide an indicator on the size of the

 Winter, et al.          Expires December 13, 2010              [Page 90]
 Internet-Draft           draft-ietf-roll-rpl-09                 Jun 2010

    candidate neighbor list.

 15.7.  Liveness Detection and Monitoring

    By contrast with several other routing protocols, RPL does not define
    any 'keep-alive' mechanisms to detect routing adjacency failure: this
    is in most cases, because such a mechanism may be too expensive in
    terms of bandwidth and even more importantly energy (a battery
    operated device could not afford to send periodic Keep alive).  Still
    RPL requires mechanisms to detect that a neighbor is no longer
    reachable: this can be performed by using mechanisms such as NUD
    (Neighbor Unreachability Detection) or even some form of Keep-alive
    that are outside of this document.

 15.8.  Fault Isolation

    It is RECOMMENDED to quarantine neighbors that start emitting
    malformed messages at unacceptable rates.

 15.9.  Impact on Other Protocols

    RPL has very limited impact on other protocols.  Where more than one
    routing protocol is required on a router such as a LBR, it is
    expected for the device to support routing redistribution functions
    between the routing protocols to allow for reachability between the
    two routing domains.  Such redistribution SHOULD be governed by the
    use of user configurable policy.

    With regards to the impact in terms of traffic on the network, RPL
    has been designed to limit the control traffic thanks to mechanisms
    such as Trickle timers (Section 7.3).  Thus the impact of RPL on
    other protocols should be extremely limited.

 15.10.  Performance Management

    Performance management is always an important aspect of a protocol
    and RPL is not an exception.  Several metrics of interest have been
    specified by the IP Performance Monitoring (IPPM) Working Group: that
    being said, they will be hardly applicable to LLN considering the
    cost of monitoring these metrics in terms of resources on the devices
    and required bandwidth.  Still, RPL implementation MAY support some
    of these, and other parameters of interest are listed below:

    o  Number of repairs and time to repair in seconds (average,
       variance)

    o  Number of times and duration during which a devices could not
       forward a packet because of a lack of reachable neighbor in its

 Winter, et al.          Expires December 13, 2010              [Page 91]
 Internet-Draft           draft-ietf-roll-rpl-09                 Jun 2010

       routing table

    o  Monitoring of resources consumption by RPL itself in terms of
       bandwidth and required memory

    o  Number of RPL control messages sent and received

 More may be added later on the security aspects of manageability

-- 
Ticket URL: <http://tools.ietf.org/wg/roll/trac/ticket/48#comment:2>
roll <http://tools.ietf.org/wg/roll/>