Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7939

Definition of Managed Objects for the Neighborhood Discovery Protocol

Pages: 72
Proposed Standard
Obsoletes:  6779
Part 1 of 4 – Pages 1 to 11
None   None   Next

Top   ToC   RFC7939 - Page 1
Internet Engineering Task Force (IETF)                        U. Herberg
Request for Comments: 7939
Obsoletes: 6779                                                  R. Cole
Category: Standards Track                                 US Army CERDEC
ISSN: 2070-1721                                              I. Chakeres
                                                                  Delvin
                                                              T. Clausen
                                                     Ecole Polytechnique
                                                             August 2016


 Definition of Managed Objects for the Neighborhood Discovery Protocol

Abstract

This document replaces RFC 6779; it contains revisions and extensions to the original document. It defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The extensions described in this document add objects and values to support the NHDP optimization specified in RFC 7466. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications about NHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7939.
Top   ToC   RFC7939 - Page 2
Copyright Notice

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

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Differences from RFC 6779 . . . . . . . . . . . . . . . . 3 2. The Internet-Standard Management Framework . . . . . . . . . 3 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Structure of the MIB Module . . . . . . . . . . . . . . . . . 4 5.1. Notifications . . . . . . . . . . . . . . . . . . . . . . 5 5.1.1. Introduction . . . . . . . . . . . . . . . . . . . . 5 5.1.2. Notification Generation . . . . . . . . . . . . . . . 5 5.1.3. Limiting Frequency of Notifications . . . . . . . . . 5 5.2. The Configuration Group . . . . . . . . . . . . . . . . . 7 5.3. The State Group . . . . . . . . . . . . . . . . . . . . . 7 5.4. The Performance Group . . . . . . . . . . . . . . . . . . 8 5.5. Tables and Indexing . . . . . . . . . . . . . . . . . . . 8 6. Relationship to Other MIB Modules . . . . . . . . . . . . . . 10 6.1. Relationship to the SNMPv2-MIB . . . . . . . . . . . . . 10 6.2. Relationship to Routing Protocol MIB Modules Relying on the NHDP-MIB Module . . . . . . . . . . . . . . . . . . . 10 6.3. Relationship to the If-MIB . . . . . . . . . . . . . . . 10 6.4. MIB Modules Required for IMPORTS . . . . . . . . . . . . 11 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 66 9. Applicability Statement . . . . . . . . . . . . . . . . . . . 68 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 69 11.1. Normative References . . . . . . . . . . . . . . . . . . 69 11.2. Informative References . . . . . . . . . . . . . . . . . 71 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72
Top   ToC   RFC7939 - Page 3

1. Introduction

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) [RFC6130] process on a router. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications about NHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery.

1.1. Differences from RFC 6779

This document obsoletes [RFC6779], replacing that document as the specification of the MIB module for [RFC6130]. This revision to [RFC6779] is necessitated by the update to [RFC6130] specified in [RFC7466]. The MIB module for [RFC6130], specified in this document, captures the new information and states for each symmetric 2-hop neighbor, recorded in the Neighbor Information Base of a router and to be reflected in the appropriate tables, introduced by [RFC7466], specifically: o Addition of objects nhdpIib2HopSetN2Lost and nhdpIfPerfCounterDiscontinuityTime. o Addition of extra value (notconsidered) to nhdp2HopNbrState. o Revised full compliance state.

2. The Internet-Standard Management Framework

For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
Top   ToC   RFC7939 - Page 4

3. Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and OPTIONAL" in this document are to be interpreted as described in [RFC2119].

4. Overview

[RFC6130] allows a router to discover and track topological information of routers up to two hops away by virtue of exchanging HELLO messages. This information is useful for routers running various routing and multicast flooding protocols developed within the IETF MANET Working Group.

4.1. Terms

The following definitions apply throughout this document: o Notification Objects - triggers and associated notification messages allowing for asynchronous tracking of predefined events on the managed router. o Configuration Objects - switches, tables, and objects that are initialized to default settings or set through the management interface defined by this MIB module. o State Objects - automatically generated values that define the current operating state of the NHDP instance in the router. o Performance Objects - automatically generated values that help to assess the performance of the NHDP instance on the router and the overall discovery performance within the MANET.

4.2. Notation

The same notations as defined in [RFC6130] are used throughout this document.

5. Structure of the MIB Module

This section presents the structure of the NHDP-MIB module. The MIB module is arranged into the following structure: o nhdpNotifications - objects defining NHDP-MIB notifications.
Top   ToC   RFC7939 - Page 5
   o  nhdpObjects - defining objects within this MIB module.  The
      objects are arranged into the following groups:

      *  Configuration Group - defining objects related to the
         configuration of the NHDP instance on the router.

      *  State Group - defining objects that reflect the current state
         of the NHDP instance running on the router.

      *  Performance Group - defining objects that are useful to a
         management station when characterizing the performance of NHDP
         on the router and in the MANET.

   o  nhdpConformance - defining the minimal and maximal conformance
      requirements for implementations of this MIB module.

5.1. Notifications

This section describes the use of notifications and mechanisms to enhance the ability to manage NHDP routing domains.

5.1.1. Introduction

Notifications can be emitted by a router running an instance of this specification as a reaction to a specific event. This allows an observer of these events to efficiently determine the source of problems or significant changes of configuration or topology, instead of polling a possibly large number of routers.

5.1.2. Notification Generation

When an exception event occurs, the application notifies the local agent, which sends a notification to the appropriate SNMP management stations. The message includes the notification type and may include a list of notification-specific variables. Section 7 contains the notification definitions, which includes the variable lists. At least one IP address of the router that originates the notification is included in the variable list so that the source of the notification may be determined.

5.1.3. Limiting Frequency of Notifications

To limit the frequency of notifications, the following additional mechanisms are suggested, similar to those in [RFC4750].
Top   ToC   RFC7939 - Page 6
5.1.3.1. Ignoring Initial Activity
The majority of critical events occur when NHDP is first enabled on a router, at which time, the symmetric neighbors and 2-hop neighbors of the router are discovered. During this initial period, a potential flood of notifications is unnecessary since the events are expected. To avoid unnecessary notifications, a router SHOULD NOT originate expected notifications until a predefined and administratively configured time interval has elapsed. It is RECOMMENDED that this time interval be at least 3 times nhdpHelloInterval so that symmetric neighbors are discovered. The suppression window for notifications is started when the nhdpIfStatus transitions from its default value of 'false(2)' to 'true(1)'.
5.1.3.2. Throttling Notifications
The mechanism for throttling the notifications is the same as in [RFC4750] (i.e., the number of transmitted notifications per time is bounded). Appropriate values for the window time and upper bound are to be administratively configured and depend on the deployment of the MANET. If NHDP is deployed on a lossy, wireless medium, sending too many notifications in a short time interval may lead to collisions and dropped packets. In particular, in dense deployments of routers running NHDP (i.e., where each router has many neighbors), a change of the local topology may trigger many notifications at the same time. [RFC4750] recommends "7 traps with a window time of 10 seconds" as the upper bound. As NHDP is expected to be deployed in more lossy channels than OSPF, it is RECOMMENDED to choose a lower threshold for the number of notifications per time than that. Specifically, it is RECOMMENDED that the threshold value for the objects reflecting the change be set to a value of '10' and the DEFAULT values for these objects within the Notifications Group be set to this value. Further, a time window for the change objects is defined within this MIB module. If the number of occurrences exceeds the change threshold within the previous change window, then it is RECOMMENDED that the notification be sent. Furthermore, it is RECOMMENDED that the value for this window be set to at least 5 times the nhdpHelloInterval. The following objects are used to define the thresholds and time windows for specific notifications defined in the NHDP-MIB module: nhdpNbrStateChangeThreshold, nhdpNbrStateChangeWindow, nhdp2HopNbrStateChangeThreshold, and nhdp2HopNbrStateChangeWindow.
Top   ToC   RFC7939 - Page 7
5.1.3.3. One Notification per Event
Similar to the mechanism in [RFC4750], only one notification is sent per event.

5.2. The Configuration Group

The router running NHDP is configured with a set of controls. The authoritative list of configuration controls within the NHDP-MIB module are found within the MIB module itself. Generally, an attempt was made in developing the NHDP-MIB module to support all configuration objects defined in [RFC6130]. For all of the configuration parameters, the same constraints and default values of these parameters as defined in [RFC6130] are followed. Refer to [RFC5148] for guidance on setting jitter-related parameters, e.g., nhdpMaxJitter.

5.3. The State Group

The State Group reports current state information of a router running NHDP. The NHDP-MIB State Group tables were designed to contain the complete set of state information defined within the information bases specified in Sections 6, 7, and 8 of [RFC6130]. Two constructs, i.e., TEXTUAL-CONVENTIONs, are defined to support the tables in the State Group. NHDP stores and indexes information through sets of (dynamically defined) addresses, i.e., address sets. Within SMIv2, it is not possible to index tables with variably defined address sets. Hence, these TEXTUAL-CONVENTIONs are defined to provide a local mapping between NHDP-managed address sets and SMIv2 table indexing. These constructs are the NeighborIfIndex and NeighborRouterIndex. These are locally (to the router) defined, unique identifiers of virtual neighbors and neighbor interfaces. Due to the nature of NHDP, the local router may have identified distinct address sets but is not able to associate these as a single interface. Hence, two or more NeighborIfIndexes pointing to multiple distinct address sets may, in fact, be related to a common neighbor interface. This ambiguity may also hold with respect to the assignment of the NeighborRouterIndex. The local MIB agent is responsible for managing, aggregating, and retiring the defined indexes and for updating MIB tables using these indexes as the local router learns more about its neighbors' topologies. These constructs are used to define indexes to the appropriate State Group tables and to correlate table entries to address sets, virtual neighbor interfaces, and virtual neighbors within the MANET.
Top   ToC   RFC7939 - Page 8

5.4. The Performance Group

The Performance Group reports values relevant to system performance. Unstable neighbors or 2-hop neighbors and frequent changes of sets can have a negative influence on the performance of NHDP. This MIB module defines several objects that can be polled in order to, e.g., calculate histories or monitor frequencies of changes. This may help an observer determining unusual topology changes or other changes that affect stability and reliability of the MANET.

5.5. Tables and Indexing

The NHDP-MIB module contains a number of tables that record data related to: o the local router, o a local MANET interface on the router, o other routers that are one hop removed from the local router, o interfaces on other routers that are one hop removed from the local router, and o other routers that are two hops removed from the local router. The NHDP-MIB module's tables are indexed via the following constructs: o nhdpIfIndex - the IfIndex of the local router on which NHDP is configured. o nhdpDiscIfIndex - a locally managed index representing a known interface on a neighboring router. o nhdpDiscRouterIndex - a locally managed index representing an ID of a known neighboring router. These tables and their indexing are: o nhdpInterfaceTable - describes the configuration of the interfaces of this router. This table has INDEX { nhdpIfIndex }. o nhdpLibLocalIfSetTable - records all network addresses that are defined as local interface network addresses on this router. This table has INDEX { nhdpLibLocalIfSetIndex }.
Top   ToC   RFC7939 - Page 9
   o  nhdpLibRemovedIfAddrSetTable - records network addresses that were
      recently used as local interface network addresses on this router
      but have been removed.  This table has INDEX
      { nhdpLibRemovedIfAddrSetIndex }.

   o  nhdpInterfaceStateTable - records state information related to
      specific interfaces of this router.  This table has INDEX
      { nhdpIfIndex }.

   o  nhdpDiscIfSetTable - includes the nhdpDiscRouterIndex of the
      discovered router, the nhdpDiscIfIndex of the discovered
      interface, and the current set of addresses associated with this
      neighbor interface.  This table has INDEX { nhdpDiscIfSetIndex }.

   o  nhdpIibLinkSetTable - for each local interface, records all links
      belonging to other routers that are, or recently were, 1-hop
      neighbors to this router.  This table has INDEX { nhdpIfIndex,
      nhdpDiscIfIndex }.

   o  nhdpIib2HopSetTable - for each local interface, records network
      addresses (one at a time) of symmetric 2-hop neighbors and the
      symmetric links to symmetric 1-hop neighbors of this router
      through which these symmetric 2-hop neighbors can be reached.
      This table has INDEX { nhdpIfIndex, nhdpDiscIfIndex,
      nhdpIib2HopSetIpAddressType, nhdpIib2HopSetIpAddress }.

   o  nhdpNibNeighborSetTable - records all network addresses of each
      1-hop neighbor to this router.  This table has INDEX
      { nhdpDiscRouterIndex }.

   o  nhdpNibLostNeighborSetTable - records network addresses of other
      routers that were recently symmetric 1-hop neighbors to this
      router but are now advertised as lost.  This table has INDEX
      { nhdpDiscRouterIndex }.

   o  nhdpInterfacePerfTable - records performance objects that are
      measured for each local NHDP interface on this router.  This table
      has INDEX { nhdpIfIndex }.

   o  nhdpDiscIfSetPerfTable - records performance objects that are
      measured for each discovered interface of a neighbor of this
      router.  This table has INDEX { nhdpDiscIfIndex }.

   o  nhdpDiscNeighborSetPerfTable - records performance objects that
      are measured for discovered neighbors of this router.  This table
      has INDEX { nhdpDiscRouterIndex }.
Top   ToC   RFC7939 - Page 10
   o  nhdpIib2HopSetPerfTable - records performance objects that are
      measured for discovered 2-hop neighbors of this router.  This
      table has INDEX { nhdpDiscRouterIndex }.

6. Relationship to Other MIB Modules

This section specifies the relationship of the MIB module contained in this document to other standards, particularly to standards containing other MIB modules. MIB modules and specific definitions imported from MIB modules that SHOULD be implemented in conjunction with the MIB module contained within this document are identified in this section.

6.1. Relationship to the SNMPv2-MIB

The System Group in the SNMPv2-MIB module [RFC3418] is defined as being mandatory for all systems, and the objects apply to the entity as a whole. The System Group provides identification of the management entity and certain other system-wide data. The NHDP-MIB module does not duplicate those objects.

6.2. Relationship to Routing Protocol MIB Modules Relying on the NHDP- MIB Module

[RFC6130] allows routing protocols to rely on the neighborhood information that is discovered by means of HELLO message exchange. In order to allow for troubleshooting, fault isolation, and management of such routing protocols through a routing protocol MIB module, it may be desired to align the State Group tables of the NHDP-MIB module and the routing protocol MIB module. This is accomplished through the definition of two TEXTUAL-CONVENTIONs in the NHDP-MIB module: the NeighborIfIndex and the NeighborRouterIndex. These object types are used to develop indexes into common NHDP-MIB module and routing protocol State Group tables. These objects are locally significant but should be locally common to the NHDP-MIB module and the routing protocol MIB module implemented on a common networked router. This will allow for improved cross-referencing of information across the two MIB modules.

6.3. Relationship to the If-MIB

The nhdpInterfaceTable in this MIB module describes the configuration of the interfaces of this router that are intended to use MANET control protocols. As such, this table 'sparse augments' the ifTable [RFC2863] specifically when NHDP is to be configured to operate over this interface. The interface is identified by the ifIndex from the Interfaces Group defined in the Interfaces Group MIB module [RFC2863].
Top   ToC   RFC7939 - Page 11
   A conceptual row in the nhdpInterfaceTable exists if and only if
   either the row has been administratively created or there is an
   interface on the managed device that supports and runs NHDP.  This
   implies that for each entry in the nhdpInterfaceTable, there is a
   corresponding entry in the Interface Table where nhdpIfIndex and
   ifIndex are equal.  If that corresponding entry in the Interface
   Table is deleted, then the entry in nhdpInterfaceTable is
   automatically deleted, NHDP is disabled on this interface, and all
   configuration and state information related to this interface is to
   be removed from memory.

6.4. MIB Modules Required for IMPORTS

The following NHDP-MIB module IMPORTS objects from SNMPv2-SMI [RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], IF-MIB [RFC2863], SNMP-FRAMEWORK-MIB [RFC3411], INET-ADDRESS-MIB [RFC4001], and FLOAT-TC-MIB [RFC6340].


(page 11 continued on part 2)

Next Section