tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6632

 
 
 

An Overview of the IETF Network Management Standards

Part 5 of 5, p. 77 to 85
Prev RFC Part

 


prevText      Top      Up      ToC       Page 77 
Appendix A.  High-Level Classification of Management Protocols and Data
             Models

   The following subsections aim to guide the reader for the fast
   selection of the management standard in interest and can be used as a
   dispatcher to forward to the appropriate chapter.  The subsections
   below classify the protocols on one hand according to high-level
   criteria such as push versus pull mechanism, and passive versus
   active monitoring.  On the other hand, the protocols are categorized
   concerning the network management task they address or the data model
   extensibility they provide.  Based on the reader's requirements, a
   reduced set of standard protocols and associated data models can be
   selected for further reading.

   As an example, someone outside of IETF typically would look for the
   TWAMP protocol in the Operations and Management Area working groups
   as it addresses performance management.  However, the protocol TWAMP
   has been developed by the IPPM working group in the Transport Area.

   Note that not all protocols have been listed in all classification
   sections.  Some of the protocols, especially the protocols with
   specific focus in Section 3 cannot be clearly classified.  Note also
   that COPS and COPS-PR are not listed in the tables, as COPS-PR is not
   recommended to use (see Section 3.3).

A.1.  Protocols Classified by Standards Maturity in the IETF

   This section classifies the management protocols according their
   standard maturity in the IETF.  The IETF standard maturity levels
   Proposed, Draft, or Internet Standard, are defined in [RFC2026] (as
   amended by [RFC6410]).  An Internet Standard is characterized by a
   high degree of technical maturity and by a generally held belief that
   the specified protocol or service provides significant benefit to the
   Internet community.

   The table below covers the standard maturity of the different
   protocols listed in this document.  Note that only the main protocols
   (and not their extensions) are noted.  An RFC search tool listing the
   current document status is available at [RFCSEARCH].

Top      Up      ToC       Page 78 
   +---------------------------------------------+---------------------+
   | Protocol                                    | Maturity Level      |
   +---------------------------------------------+---------------------+
   | SNMP [STD62][RFC3411] (Section 2.1)         | Internet Standard   |
   |                                             |                     |
   | Syslog [RFC5424] (Section 2.2)              | Proposed Standard   |
   |                                             |                     |
   | IPFIX [RFC5101] (Section 2.3)               | Proposed Standard   |
   |                                             |                     |
   | PSAMP [RFC5476] (Section 2.3)               | Proposed Standard   |
   |                                             |                     |
   | NETCONF [RFC6241] (Section 2.4.1)           | Proposed Standard   |
   |                                             |                     |
   | DHCP for IPv4 [RFC2131] (Section 3.1.1)     | Draft Standard      |
   |                                             |                     |
   | DHCP for IPv6 [RFC3315] (Section 3.1.1)     | Proposed Standard   |
   |                                             |                     |
   | OWAMP [RFC4656] (Section 3.4)               | Proposed Standard   |
   |                                             |                     |
   | TWAMP [RFC5357] (Section 3.4)               | Proposed Standard   |
   |                                             |                     |
   | RADIUS [RFC2865] (Section 3.5)              | Draft Standard      |
   |                                             |                     |
   | Diameter [RFC3588] (Section 3.6)            | Proposed Standard   |
   |                                             |                     |
   | CAPWAP [RFC5416] (Section 3.7)              | Proposed Standard   |
   |                                             |                     |
   | ANCP [RFC6320] (Section 3.8)                | Proposed Standard   |
   |                                             |                     |
   | Ad hoc network configuration [RFC5889]      | Informational       |
   | (Section 3.1.2)                             |                     |
   |                                             |                     |
   | ACAP [RFC2244] (Section 3.9)                | Proposed Standard   |
   |                                             |                     |
   | XCAP [RFC4825] (Section 3.10)               | Proposed Standard   |
   +---------------------------------------------+---------------------+

      Table 1: Protocols Classified by Standard Maturity in the IETF

Top      Up      ToC       Page 79 
A.2.  Protocols Matched to Management Tasks

   This subsection classifies the management protocols matching to the
   management tasks for fault, configuration, accounting, performance,
   and security management.

   +------------+------------+-------------+--------------+------------+
   | Fault Mgmt | Config.    | Accounting  | Performance  | Security   |
   |            | Mgmt       | Mgmt        | Mgmt         | Mgmt       |
   +------------+------------+-------------+--------------+------------+
   | SNMP       | SNMP       | SNMP        | SNMP         |            |
   | notif.     | config.    | monitoring  | monitoring   |            |
   | with trap  | with set   | with get    | with get     |            |
   | operation  | operation  | operation   | operation    |            |
   | (S. 2.1.1) | (S. 2.1.1) | (S. 2.1.1)  | (S. 2.1.1)   |            |
   |            |            |             |              |            |
   | IPFIX      | CAPWAP     | IPFIX       | IPFIX        |            |
   | (S. 2.3)   | (S. 3.7)   | (S. 2.3)    | (S. 2.3)     |            |
   |            |            |             |              |            |
   | PSAMP      | NETCONF    | PSAMP       | PSAMP        |            |
   | (S. 2.3)   | (S. 2.4.1) | (S. 2.3)    | (S. 2.3)     |            |
   |            |            |             |              |            |
   | Syslog     | ANCP       | RADIUS      |              | RADIUS     |
   | (S. 2.2)   | (S. 3.8)   | Accounting  |              | Authent.&  |
   |            |            | (S. 3.5)    |              | Authoriz.  |
   |            |            |             |              | (S. 3.5)   |
   |            |            |             |              |            |
   |            | AUTOCONF   | Diameter    |              | Diameter   |
   |            | (S. 3.1.2) | Accounting  |              | Authent.&  |
   |            |            | (S. 3.6)    |              | Authoriz.  |
   |            |            |             |              | (S. 3.6)   |
   |            |            |             |              |            |
   |            | ACAP       |             |              |            |
   |            | (S. 3.9)   |             |              |            |
   |            |            |             |              |            |
   |            | XCAP       |             |              |            |
   |            | (S. 3.10)  |             |              |            |
   |            |            |             |              |            |
   |            | DHCP       |             |              |            |
   |            | (S. 3.1.1) |             |              |            |
   +------------+------------+-------------+--------------+------------+

              Table 2: Protocols Matched to Management Tasks

   Note: Corresponding section numbers are given in parentheses.

Top      Up      ToC       Page 80 
A.3.  Push versus Pull Mechanism

   A pull mechanism is characterized by the Network Management System
   (NMS) pulling the management information out of network elements,
   when needed.  A push mechanism is characterized by the network
   elements pushing the management information to the NMS, either when
   the information is available or on a regular basis.

   Client/Server protocols, such as DHCP, ANCP, ACAP, and XCAP are not
   listed in Table 3.

   +---------------------------------+---------------------------------+
   | Protocols supporting the Pull   | Protocols supporting the Push   |
   | mechanism                       | mechanism                       |
   +---------------------------------+---------------------------------+
   | SNMP (except notifications)     | SNMP notifications              |
   | (Section 2.1)                   | (Section 2.1)                   |
   | NETCONF (except notifications)  | NETCONF notifications           |
   | (Section 2.4.1)                 | (Section 2.4.1)                 |
   | CAPWAP (Section 3.7)            | Syslog (Section 2.2)            |
   |                                 | IPFIX (Section 2.3)             |
   |                                 | PSAMP (Section 2.3)             |
   |                                 | RADIUS accounting               |
   |                                 | (Section 3.5)                   |
   |                                 | Diameter accounting             |
   |                                 | (Section 3.6)                   |
   +---------------------------------+---------------------------------+

      Table 3: Protocol Classification by Push versus Pull Mechanism

A.4.  Passive versus Active Monitoring

   Monitoring can be divided into two categories: passive and active
   monitoring.  Passive monitoring can perform the network traffic
   monitoring, monitoring of a device, or the accounting of network
   resource consumption by users.  Active monitoring, as used in this
   document, focuses mainly on active network monitoring and relies on
   the injection of specific traffic (also called "synthetic traffic"),
   which is then monitored.  The monitoring focus is indicated in the
   table below as "network", "device", or "accounting".

   This classification excludes non-monitoring protocols, such as
   configuration protocols: Ad hoc network autoconfiguration, ANCP, and
   XCAP.  Note that some of the active monitoring protocols, in the
   context of the data path, e.g., ICMP Ping and Traceroute [RFC1470],
   Bidirectional Forwarding Detection (BFD) [RFC5880], and PWE3 Virtual
   Circuit Connectivity Verification (VCCV) [RFC5085] are covered in
   [OAM-OVERVIEW].

Top      Up      ToC       Page 81 
   +---------------------------------+---------------------------------+
   | Protocols supporting passive    | Protocols supporting active     |
   | monitoring                      | monitoring                      |
   +---------------------------------+---------------------------------+
   | IPFIX (network) (Section 2.3)   | OWAMP (network) (Section 3.4)   |
   | PSAMP (network) (Section 2.3)   | TWAMP (network) (Section 3.4)   |
   | SNMP (network and device)       |                                 |
   | (Section 2.1)                   |                                 |
   | NETCONF (device)                |                                 |
   | (Section 2.4.1)                 |                                 |
   | RADIUS (accounting)             |                                 |
   | (Section 3.5)                   |                                 |
   | Diameter (accounting)           |                                 |
   | (Section 3.6)                   |                                 |
   | CAPWAP (device) (Section 3.7)   |                                 |
   +---------------------------------+---------------------------------+

      Table 4: Protocols for Passive and Active Monitoring and Their
                             Monitoring Focus

   The application of SNMP to passive traffic monitoring (e.g., with
   RMON-MIB) or active monitoring (with IPPM MIB) depends on the MIB
   modules used.  However, the SNMP protocol itself does not have
   operations, which support active monitoring.  NETCONF can be used for
   passive monitoring, e.g., with the NETCONF Monitoring YANG module
   [RFC6022] for the monitoring of the NETCONF protocol.  CAPWAP
   monitors the status of a Wireless Termination Point.

   RADIUS and diameter are considered passive monitoring protocols as
   they perform accounting, i.e., counting the number of packets/bytes
   for a specific user.

A.5.  Supported Data Model Types and Their Extensibility

   The following table matches the protocols to the associated data
   model types.  Furthermore, the table indicates how the data model can
   be extended based on the available content today and whether the
   protocol contains a built-in mechanism for proprietary extensions of
   the data model.

Top      Up      ToC       Page 82 
   +-------------+---------------+------------------+------------------+
   | Protocol    | Data Modeling | Data Model       | Proprietary Data |
   |             |               | Extensions       | Modeling         |
   |             |               |                  | Extensions       |
   +-------------+---------------+------------------+------------------+
   | SNMP        | MIB modules   | New MIB modules  | Enterprise-      |
   | (S. 2.1)    | defined with  | specified in new | specific MIB     |
   |             | SMI           | RFCs             | modules          |
   |             | (S. 2.1.3)    |                  |                  |
   |             |               |                  |                  |
   | Syslog      | Structured    | With the         | Enterprise-      |
   | (S. 2.2)    | Data Elements | procedure to add | specific SDEs    |
   |             | (SDEs)        | Structured Data  |                  |
   |             | (S. 4.2.1)    | ID in [RFC5424]  |                  |
   |             |               |                  |                  |
   | IPFIX       | IPFIX         | With the         | Enterprise-      |
   | (S. 2.3)    | Information   | procedure to add | specific         |
   |             | Elements,     | Information      | Information      |
   |             | IPFIX IANA    | Elements         | Elements         |
   |             | registry at   | specified in     | [RFC5101]        |
   |             | [IANA-IPFIX]  | [RFC5102]        |                  |
   |             | (S. 2.3)      |                  |                  |
   |             |               |                  |                  |
   | PSAMP       | PSAMP         | With the         | Enterprise-      |
   | (S. 2.3)    | Information   | procedure to add | specific         |
   |             | Elements, as  | Information      | Information      |
   |             | an extension  | Elements         | Elements         |
   |             | to IPFIX      | specified in     | [RFC5101]        |
   |             | [IANA-IPFIX], | [RFC5102]        |                  |
   |             | and PSAMP     |                  |                  |
   |             | IANA registry |                  |                  |
   |             | at            |                  |                  |
   |             | [IANA-PSAMP]  |                  |                  |
   |             | (S. 2.3)      |                  |                  |
   |             |               |                  |                  |
   | NETCONF     | YANG modules  | New YANG modules | Enterprise-      |
   | (S. 2.4.1)  | (S. 2.4.2)    | specified in new | specific YANG    |
   |             |               | RFCs following   | modules          |
   |             |               | the guideline in |                  |
   |             |               | [RFC6087]        |                  |
   |             |               |                  |                  |
   | IPPM OWAMP/ | IPPM metrics  | New IPPM metrics | Not applicable   |
   | TWAMP       | (*) (S. 3.4)  | (S. 3.4)         |                  |
   | (S. 3.4)    |               |                  |                  |

Top      Up      ToC       Page 83 
   |             |               |                  |                  |
   | RADIUS      | TLVs          | RADIUS-related   | Vendor-Specific  |
   | (S. 3.5)    |               | registries at    | Attributes       |
   |             |               | [IANA-AAA] and   | [RFC2865]        |
   |             |               | [IANA-PROT]      |                  |
   |             |               |                  |                  |
   | Diameter    | AVPs          | Diameter-related | Vendor-Specific  |
   | (S. 3.6)    |               | registry at      | Attributes       |
   |             |               | [IANA-AAA]       | [RFC2865]        |
   |             |               |                  |                  |
   | CAPWAP      | TLVs          | New bindings     | Vendor-specific  |
   | (S. 3.7)    |               | specified in new | TLVs             |
   |             |               | RFCs             |                  |
   +-------------+---------------+------------------+------------------+

               Table 5: Data Models and Their Extensibility

   (*): With the publication of [RFC6248], the latest IANA registry for
        IPFIX metrics has been declared Obsolete.

Appendix B.  New Work Related to IETF Management Standards

B.1.  Energy Management (EMAN)

   Energy management is becoming an additional requirement for network
   management systems due to several factors including the rising and
   fluctuating energy costs, the increased awareness of the ecological
   impact of operating networks and devices, and government regulation
   on energy consumption and production.

   The basic objective of energy management is operating communication
   networks and other equipment with a minimal amount of energy while
   still providing sufficient performance to meet service-level
   objectives.  Today, most networking and network-attached devices
   neither monitor nor allow controlled energy usage as they are mainly
   instrumented for functions such as fault, configuration, accounting,
   performance, and security management.  These devices are not
   instrumented to be aware of energy consumption.  There are very few
   means specified in IETF documents for energy management, which
   includes the areas of power monitoring, energy monitoring, and power
   state control.

   A particular difference between energy management and other
   management tasks is that in some cases energy consumption of a device
   is not measured at the device itself but reported by a different
   place.  For example, at a Power over Ethernet (PoE) sourcing device
   or at a smart power strip, where one device is effectively metering
   another remote device.  This requires a clear definition of the

Top      Up      ToC       Page 84 
   relationship between the reporting devices and identification of
   remote devices for which monitoring information is provided.  Similar
   considerations will apply to power state control of remote devices,
   for example, at a PoE sourcing device that switches on and off power
   at its ports.  Another example scenario for energy management is a
   gateway to low resourced and lossy network devices in wireless a
   building network.  Here the energy management system talks directly
   to the gateway but not necessarily to other devices in the building
   network.

   At the time of this writing, the EMAN working group is working on the
   management of energy-aware devices, covered by the following items:

   o  The requirements for energy management, specifying energy
      management properties that will allow networks and devices to
      become energy aware.  In addition to energy awareness
      requirements, the need for control functions will be discussed.
      Specifically, the need to monitor and control properties of
      devices that are remote to the reporting device should be
      discussed.

   o  The energy management framework, which will describe extensions to
      the current management framework, required for energy management.
      This includes: power and energy monitoring, power states, power
      state control, and potential power state transitions.  The
      framework will focus on energy management for IP-based network
      equipment (routers, switches, PCs, IP cameras, phones and the
      like).  Particularly, the relationships between reporting devices,
      remote devices, and monitoring probes (such as might be used in
      low-power and lossy networks) need to be elaborated.  For the case
      of a device reporting on behalf of other devices and controlling
      those devices, the framework will address the issues of discovery
      and identification of remote devices.

   o  The Energy-aware Networks and Devices MIB document, for monitoring
      energy-aware networks and devices, will address devices
      identification, context information, and potential relationship
      between reporting devices, remote devices, and monitoring probes.

   o  The Power and Energy Monitoring MIB document will document
      defining managed objects for the monitoring of power states and
      energy consumption/production.  The monitoring of power states
      includes the following: retrieving power states, properties of
      power states, current power state, power state transitions, and
      power state statistics.  The managed objects will provide means of
      reporting detailed properties of the actual energy rate (power)
      and of accumulated energy.  Further, they will provide information
      on electrical power quality.

Top      Up      ToC       Page 85 
   o  The Battery MIB document will define managed objects for battery
      monitoring, which will provide means of reporting detailed
      properties of the actual charge, age, and state of a battery and
      of battery statistics.

   o  The applicability statement will describe the variety of
      applications that can use the energy framework and associated MIB
      modules.  Potential examples are building networks, home energy
      gateway, etc.  Finally, the document will also discuss
      relationships of the framework to other architectures and
      frameworks (such as Smart Grid).  The applicability statement will
      explain the relationship between the work in this WG and other
      existing standards, e.g., from the IEC, ANSI, DMTF, etc.  Note
      that the EMAN WG will be looking into existing standards such as
      those from the IEC, ANSI, DMTF and others, and reuse existing work
      as much as possible.

   The documents of the EMAN working group can be found at [EMAN-WG].

Authors' Addresses

   Mehmet Ersue (editor)
   Nokia Siemens Networks
   St.-Martin-Strasse 53
   Munich  81541
   Germany

   EMail: mehmet.ersue@nsn.com


   Benoit Claise
   Cisco Systems, Inc.
   De Kleetlaan 6a b1
   Diegem  1831
   Belgium

   EMail: bclaise@cisco.com