Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6632

An Overview of the IETF Network Management Standards

Pages: 85
Informational
Part 5 of 5 – Pages 77 to 85
First   Prev   None

Top   ToC   RFC6632 - Page 77   prevText

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