RFC 6632
An Overview of the IETF Network Management Standards
Pages: 85
Informational
Informational
Part 5 of 5 – Pages 77 to 85
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].
+---------------------------------------------+---------------------+ | 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
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.
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 MechanismA.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].
+---------------------------------+---------------------------------+ | 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.
+-------------+---------------+------------------+------------------+
| 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) | | | |
| | | | | | 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
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.
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