FCAPS]). Note that the IETF does not use the FCAPS view as an organizing principle for its data models. However, the FCAPS view is used widely outside of the IETF for the realization of management tasks and applications. Section 4.2 aims to address the FCAPS view to enable people outside of the IETF to understand the relevant data models in the IETF. The different data models covered in this section are MIB modules, IPFIX Information Elements, Syslog Structured Data Elements, and YANG modules. There are many technology-specific IETF data models, such as transmission and protocol MIBs, which are not mentioned in this document and can be found at [RFCSEARCH]. This section gives an overview of management data models that have reached Draft or Proposed Standard status at the IETF. In exceptional cases, important Informational RFCs are referenced. The advancement process for management data models beyond Proposed Standard status, has been defined in [BCP027] with a more pragmatic approach and special considerations on data model specification interoperability. However, most IETF management data models never advanced beyond Proposed Standard.
Figure 1. +-----------+ +-------------------------------+ +-----------+ | | | application-layer data models | | network | | generic | +-------------------------------+ | management| | infra- | | transport-layer data models | | infra- | | structure | +-------------------------------+ | structure | | data | | network-layer data models | | data | | models | +-------------------------------+ | models | | | | link-layer data models | | | +-----------+ +-------------------------------+ +-----------+ Figure 1: Categories of Network Management Data Models Each of the categories is briefly described below. Note that the classification used here is intended to provide orientation and reflects how most data models have been developed in the IETF by the various working groups. This classification does not aim to classify correctly all data models that have been defined by the IETF so far. The network layering model in the middle of Figure 1 follows the four-layer model of the Internet as defined in [RFC1021]. The network management object identifiers for use with IETF MIB modules defined in the IETF can be found under the IANA registry at [SMI-NUMBERS]. RFC2863]. It provides the basic notion of network interfaces and allows expressing stacking/layering relationships between interfaces. The interfaces data model also provides basic monitoring objects that are widely used for performance and fault management. The second important infrastructure data model is defined in the Entity MIB [RFC4133]. It exports the containment hierarchy of the physical entities (slots, modules, ports) that make up a networking device and, as such, it is a key data model for inventory management. Physical entities can have pointers to other data models that provide more specific information about them (e.g., physical ports usually point to the related network interface). Entity MIB extensions exist for physical sensors such as temperature sensors embedded on line cards or sensors that report fan rotation speeds [RFC3433]. The
Entity State MIB [RFC4268] models states and alarms of physical entities. Some vendors have extended the basic Entity MIB with several proprietary data models. RFC4706], Very high bit-rate Digital Subscriber Line (VDSL) [RFC5650], GMPLS [RFC4803], ISDN [RFC2127], ATM [RFC2515] [RFC3606], Cable Modems [RFC4546], or Ethernet [RFC4188] [RFC4318] [RFC4363]. These so-called transmission data models typically extend the generic network interfaces data model with interface type specific information. Most of the link-layer data models focus on monitoring capabilities that can be used for performance and fault management functions and, to some lesser extent, for accounting and security management functions. Meanwhile, the IEEE has taken over the responsibility to maintain and further develop data models for the IEEE 802 family of protocols [RFC4663]. The cable modem industry consortium DOCSIS is working with the IETF to publish data models for cable modem networks as IETF Standards Track specifications. RFC4293] [RFC4292] network protocols and their extensions (e.g., Mobile IP), the core protocols of the Internet. In addition, there are data models covering popular unicast routing protocols (OSPF [RFC4750], IS-IS [RFC4444], BGP-4 [RFC4273]) and multicast routing protocols (PIM [RFC5060]). Detailed models also exist for performance measurements in the form of IP Performance Metrics [RFC2330] (see Section 3.4). The necessary data model infrastructure for configuration data models covering network layers are currently being defined using NETCONF [RFC6242] and YANG [RFC6020]. RFC4022], UDP [RFC4113], and SCTP [RFC3873]. For TCP, a data model providing extended statistics is defined in [RFC4898].
RFC4780]). In addition, there are data models that provide a generic infrastructure for instrumenting applications in order to obtain data useful primarily for performance management and fault management [RFC2287] [RFC2564]. In general, however, generic application MIB modules have been less successful in gaining widespread deployment. RFC3410], some MIB modules providing generic functions such as the calculation of expressions over MIB objects, generic functions for thresholding and event generation, event notification logging functions, and data models to represent alarms [RFC2981] [RFC2982] [RFC3014] [RFC3877]. In addition, there are data models that allow the execution of basic reachability and path discovery tests [RFC4560]. Another collection of MIB modules provides remote monitoring functions, ranging from the data link layer up to the application layer. This is known as the "RMON family of MIB modules" [RFC3577]. The IPFIX Protocol [RFC5101] (Section 2.3) is used to export information about network flows collected at so-called Observation Points (typically, a network interface). The IEs [RFC5102] carried in IPFIX cover the majority of the network and transport layer header fields and a few link-layer-specific fields. Work is underway to further extend the standardized information that can be carried in IPFIX. The Syslog Protocol document [RFC5424] (Section 2.2) defines an initial set of Structured Data Elements (SDEs) that relate to content time quality, content origin, and meta-information about the message, such as language. Proprietary SDEs can be used to supplement the IETF-defined SDEs. FCAPS]). As OAM is a general term that refers to a toolset, which can be used for fault detection, isolation, and performance measurement, aspects of FCAPS in the context of the data path, such
as fault and performance management, are also discussed in "An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms" [OAM-OVERVIEW]. Some of the data models do not fit into one single FCAPS category per design but span multiple areas. For example, there are many technology-specific IETF data models, such as transmission and protocol MIBs, which cover multiple FCAPS categories, and therefore are not mentioned in this subsection and can be found at [RFCSEARCH]. RFC3418], part of SNMPv3 standard [STD62], is a MIB module containing objects in the system group that are often polled to determine if a device is still operating, and sysUpTime can be used to detect if the network management portion of the system has restarted and counters have been re-initialized. [RFC3413], part of SNMPv3 standard [STD62], is a MIB module including objects designed for managing notifications, including tables for addressing, retry parameters, security, lists of targets for notifications, and user customization filters. The Interfaces Group MIB [RFC2863] builds on the old standard for MIB II [STD17] and is used as a primary MIB module for managing and monitoring the status of network interfaces. The Interfaces Group MIB defines a generic set of managed objects for network interfaces, and it provides the infrastructure for additional managed objects specific to particular types of network interfaces, such as Ethernet. [RFC4560] defines a MIB module for performing ping, traceroute, and lookup operations at a host. For troubleshooting purposes, it is useful to be able to initiate and retrieve the results of ping or traceroute operations when they are performed at a remote host. The RMON (Remote Network Monitoring) MIB [STD59] can be configured to recognize conditions on existing MIB variables (most notably error conditions) and continuously check for them. When one of these conditions occurs, the event may be logged, and management stations may be notified in a number of ways (for further discussion on RMON, see Section 4.2.4).
DISMAN-EVENT-MIB in [RFC2981] and DISMAN-EXPRESSION-MIB in [RFC2982] provide a superset of the capabilities of the RMON alarm and event groups. These modules provide mechanisms for thresholding and reporting anomalous events to management applications. The Alarm MIB in [RFC3877] and the Alarm Reporting Control MIB in [RFC3878] specify mechanisms for expressing state transition models for persistent problem states. Alarm MIB defines the following: o a mechanism for expressing state transition models for persistent problem states, o a mechanism to correlate a notification with subsequent state transition notifications about the same entity/object, and o a generic alarm reporting mechanism (extends ITU-T work on X.733 [ITU-X733]). In particular, [RFC3878] defines objects for controlling the reporting of alarm conditions and extends ITU-T work on M.3100 Amendment 3 [ITU-M3100]. Other MIB modules that may be applied to fault management with SNMP include: o NOTIFICATION-LOG-MIB [RFC3014] describes managed objects used for logging SNMP Notifications. o ENTITY-STATE-MIB [RFC4268] describes extensions to the Entity MIB to provide information about the state of physical entities. o ENTITY-SENSOR-MIB [RFC3433] describes managed objects for extending the Entity MIB to provide generalized access to information related to physical sensors, which are often found in networking equipment (such as chassis temperature, fan RPM, power supply voltage). The Syslog protocol document [RFC5424] defines an initial set of SDEs that relate to content time quality, content origin, and meta- information about the message, such as language. Proprietary SDEs can be used to supplement the IETF-defined SDEs. The IETF has standardized MIB Textual-Conventions for facility and severity labels and codes to encourage consistency between syslog and MIB representations of these event properties [RFC5427]. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations.
An IPFIX MIB module [RFC5815] has been defined for monitoring IPFIX Meters, Exporters, and Collectors (see Section 2.3). The ongoing work on the PSAMP MIB module extends the IPFIX MIB modules by managed objects for monitoring PSAMP implementations [PSAMP-MIB]. The NETCONF working group defined the data model necessary to monitor the NETCONF protocol [RFC6022] with the modeling language YANG. The monitoring data model includes information about NETCONF datastores, sessions, locks, and statistics, which facilitate the management of a NETCONF server. The NETCONF monitoring document also defines methods for NETCONF clients to discover the data models supported by a NETCONF server and defines the operation <get-schema> to retrieve them. RFC3418], part of [STD62], contains objects in the system group useful, e.g., for identifying the type of device and the location of the device, the person responsible for the device. The SNMPv3 standard [STD62] furthermore includes objects designed for configuring principals, access control rules, notification destinations, and for configuring proxy-forwarding SNMP agents, which can be used to forward messages through firewalls and NAT devices. The Entity MIB [RFC4133] supports mainly inventory management and is used for managing multiple logical and physical entities matched to a single SNMP agent. This module provides a useful mechanism for identifying the entities comprising a system and defines event notifications for configuration changes that may be useful to management applications. [RFC3165] defines a set of managed objects that enable the delegation of management scripts to distributed managers.
For configuring IPFIX and PSAMP devices, the IPFIX working group developed the IPFIX Configuration Data Model [CONF-MODEL], by using the YANG modeling language and in close collaboration with the NETMOD working group (see Section 2.4.2). The model specifies the necessary data for configuring and monitoring Selection Processes, caches, Exporting Processes, and Collecting Processes of IPFIX- and PSAMP- compliant monitoring devices. At the time of this writing, the NETMOD working group is developing core system and interface models in YANG. The CAPWAP protocol exchanges message elements using the Type-Length- Value (TLV) format. The base TLVs are specified in [RFC5415], while the TLVs for IEEE 802.11 are specified in [RFC5416]. The CAPWAP Base MIB [RFC5833] specifies managed objects for the modeling the CAPWAP protocol and provides configuration and WTP status-monitoring aspects of CAPWAP, where the CAPWAP Binding MIB [RFC5834] defines managed objects for the modeling of the CAPWAP protocol for IEEE 802.11 wireless binding. Note: RFC 5833 and RFC 5834 have been published as Informational RFCs to provide the basis for future work on a SNMP management of the CAPWAP protocol. RFC4670] defines RADIUS Accounting Client MIB objects that support version-neutral IP addressing formats. "RADIUS Accounting Server MIB for IPv6" [RFC4671] defines RADIUS Accounting Server MIB objects that support version-neutral IP addressing formats. IPFIX/PSAMP Information Elements: As expressed in Section 2.3, the IPFIX Architecture [RFC5470] defines components involved in IP flow measurement and reporting of information on IP flows. As such, IPFIX records provide fine-grained measurement data for flexible and detailed usage reporting and enable usage-based accounting.
The IPFIX Information Elements (IEs) have been initially defined in the IPFIX Information Model [RFC5102] and registered with IANA [IANA-IPFIX]. The IPFIX IEs are composed of two types: o IEs related to identification of IP flows such as header information, derived packet properties, IGP and BGP next-hop IP address, BGP AS, etc., and o IEs related to counter and timestamps, such as per-flow counters (e.g., octet count, packet count), flow start times, flow end times, and flow duration, etc. The Information Elements specified in the IPFIX Information Model [RFC5102] are used by the PSAMP protocol where applicable. PSAMP Parameters defined in the PSAMP protocol specification are registered at [IANA-PSAMP]. An additional set of PSAMP Information Elements for reporting packet information with the IPFIX/PSAMP protocol such as Sampling-related IEs are specified in the PSAMP Information Model [RFC5477]. These IEs fulfill the requirements on reporting of different sampling and filtering techniques specified in [RFC5475]. STD59] defines objects for collecting data related to network performance and traffic from remote monitoring devices. An organization may employ many remote monitoring probes, one per network segment, to monitor its network. These devices may be used by a network service provider to access a (distant) client network. Most of the objects in the RMON MIB module are suitable for the monitoring of any type of network, while some of them are specific to the monitoring of Ethernet networks. RMON allows a probe to be configured to perform diagnostics and to collect network statistics continuously, even when communication with the management station may not be possible or efficient. The alarm group periodically takes statistical samples from variables in the probe and compares them to previously configured thresholds. If the monitored variable crosses a threshold, an event is generated.
"Introduction to the Remote Monitoring (RMON) Family of MIB Modules" [RFC3577] describes the documents associated with the RMON Framework and how they relate to each other. The RMON-2 MIB [RFC4502] extends RMON by providing RMON analysis up to the application layer and defines performance data to monitor. The SMON MIB [RFC2613] extends RMON by providing RMON analysis for switched networks. "Remote Monitoring MIB Extensions for High Capacity Alarms" [RFC3434] describes managed objects for extending the alarm thresholding capabilities found in the RMON MIB and provides similar threshold monitoring of objects based on the Counter64 data type. "Remote Network Monitoring Management Information Base for High Capacity Networks" [RFC3273] defines objects for managing RMON devices for use on high-speed networks. "Remote Monitoring MIB Extensions for Interface Parameters Monitoring" [RFC3144] describes an extension to the RMON MIB with a method of sorting the interfaces of a monitored device according to values of parameters specific to this interface. [RFC4710] describes Real-Time Application Quality of Service Monitoring (RAQMON), which is part of the RMON protocol family. RAQMON supports end-to-end QoS monitoring for multiple concurrent applications and does not relate to a specific application transport. RAQMON is scalable and works well with encrypted payload and signaling. RAQMON uses TCP to transport RAQMON PDUs. [RFC4711] proposes an extension to the Remote Monitoring MIB [STD59] and describes managed objects used for RAQMON. [RFC4712] specifies two transport mappings for the RAQMON information model using TCP as a native transport and SNMP to carry the RAQMON information from a RAQMON Data Source (RDS) to a RAQMON Report Collector (RRC). "Application Performance Measurement MIB" [RFC3729] uses the architecture created in the RMON MIB and defines objects by providing measurement and analysis of the application performance as experienced by end-users. [RFC3729] enables the measurement of the quality of service delivered to end-users by applications. "Transport Performance Metrics MIB" [RFC4150] describes managed objects used for monitoring selectable Performance Metrics and statistics derived from the monitoring of network packets and sub- application level transactions. The metrics can be defined through reference to existing IETF, ITU, and other SDOs' documents.
The IPPM working group has defined "IP Performance Metrics (IPPM) Metrics Registry" [RFC4148]. Note that with the publication of [RFC6248], [RFC4148] and the corresponding IANA registry for IPPM metrics have been declared Obsolete and shouldn't be used. The IPPM working group defined the "Information Model and XML Data Model for Traceroute Measurements" [RFC5388], which defines a common information model dividing the IEs into two semantically separated groups (configuration elements and results elements) with an additional element to relate configuration elements and results elements by means of a common unique identifier. Based on the information model, an XML data model is provided to store the results of traceroute measurements. "Session Initiation Protocol Event Package for Voice Quality Reporting" [RFC6035] defines a SIP event package that enables the collection and reporting of metrics that measure the quality for Voice over Internet Protocol (VoIP) sessions. RFC3414], part of [STD62], specifies the procedures for providing SNMPv3 message-level security and includes a MIB module for remotely monitoring and managing the configuration parameters for the USM. [RFC3415], part of [STD62], describes the procedures for controlling access to management information in the SNMPv3 architecture and includes a MIB module, which defines managed objects to access portions of an SNMP engine's Local Configuration Datastore (LCD). As such, this MIB module enables remote management of the configuration parameters of the VACM. The NETCONF Access Control Model (NACM) [RFC6536] addresses the need for access control mechanisms for the operation and content layers of NETCONF, as defined in [RFC6241]. As such, the NACM proposes standard mechanisms to restrict NETCONF protocol access for particular users to a pre-configured subset of all available NETCONF protocol operations and content within a particular server.
There are numerous MIB modules defined for multiple purposes to use with RADIUS: o "RADIUS Authentication Client MIB for IPv6" [RFC4668] defines RADIUS Authentication Client MIB objects that support version- neutral IP addressing formats and defines a set of extensions for RADIUS authentication client functions. o "RADIUS Authentication Server MIB for IPv6" [RFC4669] defines RADIUS Authentication Server MIB objects that support version- neutral IP addressing formats and defines a set of extensions for RADIUS authentication server functions. o "RADIUS Dynamic Authorization Client MIB" [RFC4672] defines the MIB module for entities implementing the client side of the Dynamic Authorization Extensions to RADIUS [RFC5176]. o "RADIUS Dynamic Authorization Server MIB" [RFC4673] defines the MIB module for entities implementing the server side of the Dynamic Authorization Extensions to RADIUS [RFC5176]. The MIB Module definitions in [RFC4668], [RFC4669], [RFC4672], [RFC4673] are intended to be used only for RADIUS over UDP and do not support RADIUS over TCP. There is also a recommendation that RADIUS clients and servers implementing RADIUS over TCP should not reuse earlier listed MIB modules to perform statistics counting for RADIUS- over-TCP connections. Currently, there are no standardized MIB modules for diameter applications, which can be considered as a lack on the management side of diameter nodes. Section 18.104.22.168,
o User-based Security Model (USM) in Section 22.214.171.124, o View-based Access Control Model (VACM) in Section 126.96.36.199, o SNMP Transport Security Model in Section 188.8.131.52, o Secure syslog message delivery in Section 2.2, o Use of secure NETCONF message transport and the NETCONF Access Control Model (NACM) in Section 2.4.1, o Message authentication for Dynamic Host Configuration Protocol (DHCP) in Section 3.1.1, o Security for Remote Authentication Dial-In User Service (RADIUS) in conjunction with EAP and IEEE 802.1X authenticators in Section 3.5, o Built-in and transport security for the Diameter Base Protocol in Section 3.6, o Transport security for Control And Provisioning of Wireless Access Points (CAPWAP) in Section 3.7, o Built-in security for Access Node Control Protocol (ANCP) in Section 3.8, o Security for Application Configuration Access Protocol (ACAP) in Section 3.9, o Security for XML Configuration Access Protocol (XCAP) in Section 3.10, and o Data models for Security Management in Section 4.2.5. The authors would also like to refer to detailed security consideration sections for specific management standards described in this document, which contain comprehensive discussion of security implications of the particular management protocols and mechanisms. Among others, security consideration sections of following documents should be carefully read before implementing the technology. o For SNMP security in general, subsequent security consideration sections in [STD62], which includes RFCs 3411-3418, o Security considerations section in Section 8 of [BCP074] for the coexistence of SNMP versions 1, 2, and 3,
o Security considerations for the SNMP Transport Security Model in Section 8 of [RFC5591], o Security considerations for the Secure Shell Transport Model for SNMP in Section 9 of [RFC5592], o Security considerations for the TLS Transport Model for SNMP in Section 9 of [RFC6353], o Security considerations for the TLS Transport Mapping for syslog in Section 6 of [RFC5425], o Security considerations for the IPFIX Protocol Specification in Section 11 of [RFC5101], o Security considerations for the NETCONF protocol in Section 9 of [RFC6241] and the SSH transport in Section 6 of [RFC6242], o Security considerations for the NETCONF Access Control Model (NACM) in Section 3.7 of [RFC6536], o Security considerations for DHCPv4 and DHCPv6 in Section 7 of [RFC2131] and Section 23. of [RFC3315], o Security considerations for RADIUS in Section 8 of [RFC2865], o Security considerations for diameter in Section 13 of [RFC3588], o Security considerations for the CAPWAP protocol in Section 12 of [RFC5415], o Security considerations for the ANCP protocol in Section 11 of [RFC6320], and o Security considerations for the XCAP protocol in Section 14 of [RFC4825].
o Al Morton (AT&T) - contributed to the section on IP Performance Metrics. o Juergen Quittek (NEC) - contributed the section on IPFIX/PSAMP. o Juergen Schoenwaelder (Jacobs University Bremen) - contributed the sections on IETF Network Management Data Models and YANG.