Network Working Group M. Ersue, Ed. Internet-Draft Nokia Siemens Networks Intended status: Informational B. Claise Expires: January 1, 2012 Cisco Systems, Inc. June 30, 2011 An Overview of the IETF Network Management Standards draft-ietf-opsawg-management-stds-01 Abstract This document gives an overview of the IETF network management standards and summarizes existing and ongoing development of IETF standards-track network management protocols and data models. The purpose of this document is on the one hand to help system developers and users to select appropriate standard management protocols and data models to address relevant management needs. On the other hand the document can be used as an overview and guideline by other Standard Development Organizations or bodies planning to use IETF management technologies and data models. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 1, 2012. Copyright Notice Copyright (c) 2011 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 Ersue & Claise Expires January 1, 2012 [Page 1] Internet-Draft IETF Management Standards June 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Scope and Target Audience . . . . . . . . . . . . . . . . 4 1.2. Related Work . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Core Network Management Protocols . . . . . . . . . . . . . . 7 2.1. Simple Network Management Protocol (SNMP) . . . . . . . . 7 2.1.1. Architectural Principles of SNMP . . . . . . . . . . . 7 2.1.2. SNMP and its Versions . . . . . . . . . . . . . . . . 8 2.1.3. Structure of Managed Information (SMI) . . . . . . . . 10 2.1.4. SNMP Security and Access Control Models . . . . . . . 11 2.1.5. SNMP Transport Subsystem and Transport Models . . . . 13 2.2. SYSLOG Protocol . . . . . . . . . . . . . . . . . . . . . 14 2.3. IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols . . . . . . . . . . . . . . . . . . . . 16 2.4. Network Configuration . . . . . . . . . . . . . . . . . . 19 2.4.1. Network Configuration Protocol (NETCONF) . . . . . . . 19 2.4.2. YANG - NETCONF Data Modeling Language . . . . . . . . 20 3. Network Management Protocols and Mechanisms with specific Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.1. IP Address Management . . . . . . . . . . . . . . . . . . 22 3.1.1. Dynamic Host Configuration Protocol (DHCP) . . . . . . 22 3.1.2. Ad-Hoc Network Autoconfiguration . . . . . . . . . . . 24 3.2. IPv6 Network Operations . . . . . . . . . . . . . . . . . 24 3.3. Policy-based Management . . . . . . . . . . . . . . . . . 25 3.3.1. IETF Policy Framework . . . . . . . . . . . . . . . . 25 3.3.2. Common Open Policy Service (COPS) and COPS Usage for Policy Provisioning (COPS-PR) . . . . . . . . . . 25 3.4. IP Performance Metrics (IPPM) . . . . . . . . . . . . . . 26 3.5. Remote Authentication Dial In User Service (RADIUS) . . . 28 3.6. Diameter Base Protocol (DIAMETER) . . . . . . . . . . . . 30 3.7. Control And Provisioning of Wireless Access Points (CAPWAP) . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.8. Access Node Control Protocol (ANCP) . . . . . . . . . . . 34 3.9. Application Configuration Access Protocol (ACAP) . . . . . 34 3.10. XML Configuration Access Protocol (XCAP) . . . . . . . . . 35 4. Network Management Data Models . . . . . . . . . . . . . . . . 36 4.1. Fault Management . . . . . . . . . . . . . . . . . . . . . 36 4.2. Configuration Management . . . . . . . . . . . . . . . . . 38 4.3. Accounting Management . . . . . . . . . . . . . . . . . . 39 4.4. Performance Management . . . . . . . . . . . . . . . . . . 41 Ersue & Claise Expires January 1, 2012 [Page 2] Internet-Draft IETF Management Standards June 2011 4.5. Security Management . . . . . . . . . . . . . . . . . . . 43 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 6. Security Considerations . . . . . . . . . . . . . . . . . . . 44 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 44 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45 9. Informative References . . . . . . . . . . . . . . . . . . . . 45 Appendix A. High Level Classification of Management Protocols and Data Models . . . . . . . . . . . . . . . . . . . 62 A.1. Protocols classified by the Standard Maturity at IETF . . 63 A.2. Protocols Matched to Management Tasks (FCAPS) . . . . . . 63 A.3. Push versus Pull Mechanism . . . . . . . . . . . . . . . . 64 A.4. Passive versus Active Monitoring . . . . . . . . . . . . . 65 A.5. Supported Data Model Types and their Extensibility . . . . 66 Appendix B. New Work related to IETF Management Standards . . . . 67 B.1. Energy Management (EMAN) . . . . . . . . . . . . . . . . . 67 Appendix C. Open issues . . . . . . . . . . . . . . . . . . . . . 69 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 69 D.1. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 69 D.2. draft-ersue-opsawg-management-fw-03-00 . . . . . . . . . . 70 D.3. Change Log from draft-ersue-opsawg-management-fw . . . . . 71 D.3.1. 02-03 . . . . . . . . . . . . . . . . . . . . . . . . 71 D.3.2. 01-02 . . . . . . . . . . . . . . . . . . . . . . . . 71 D.3.3. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . 71 Ersue & Claise Expires January 1, 2012 [Page 3] Internet-Draft IETF Management Standards June 2011 1. Introduction 1.1. Scope and Target Audience This document gives an overview of the IETF network management standards and summarizes existing and ongoing development of IETF standards-track network management protocols and data models. The target audience of the document is on the one hand IETF working groups, which aim to select appropriate standard management protocols and data models to address their management needs. On the other hand the document can be used as an overview and guideline by non-IETF Standard Development Organizations (SDO) planning to use IETF management technologies and data models. The document can be also used to initiate a discussion between the bodies with the goal to gather new requirements and to detect possible gaps. Finally, this document is directed to all interested parties, which seek to get an overview of the current set of the IETF management protocols such as network administrators or new comers to IETF. Section 2 gives an overview of the IETF core network management standards with a special focus on Simple Network Management Protocol (SNMP), SYSLOG, IP Flow Information Export/Packet Sampling (IPFIX/ PSAMP), and Network Configuration (NETCONF). Section 3 discusses IETF management protocols and mechanisms with a specific focus, e.g. IP address management or IP performance management. Section 4 discusses Proposed, Draft and Standard Level data models, such as MIB modules, IPFIX Information Elements, SYSLOG Structured Data Elements, and YANG modules designed to address specific set of management issues. The data models are structured following the management application view and mapped to the network management tasks fault, configuration, accounting, performance, and security management. Appendix A guides the reader for the high level selection of management standards. For this, the section classifies the protocols according to high level criteria such as push versus pull mechanism, passive versus active monitoring, as well as categorizes the protocols concerning the network management task they address and their data model extensibility. If the reader is interested only in a subset of the IETF network management protocols and data models described in this document, Appendix A can be used as a dispatcher to the corresponding chapter. Appendix B gives an overview of the new work on Energy Management at IETF. This document mainly refers to Proposed, Draft or Full Standard documents at IETF (see [RFCSEARCH]). As far as it is valuable Best Current Practice (BCP) documents are referenced. In exceptional cases and if the document provides substantial guideline for standard Ersue & Claise Expires January 1, 2012 [Page 4] Internet-Draft IETF Management Standards June 2011 usage or fills an essential gap, Experimental and Informational RFCs are noticed and ongoing work is mentioned. Information on active and concluded IETF working groups (e.g., their charters, published or currently active documents and mail archive) can be found at [IETF-WGS]. Note: The final document will not contain any references to Internet- Drafts. Current references in the document are assumed to be published soon. RFC Editor: Please delete the note above before publication. 1.2. Related Work [RFC6272] gives an overview and guidance on the key protocols of the Internet Protocol Suite. In analogy to [RFC6272] this document gives an overview of the IETF network management standards and its usage scenarios. [RFC3535] "Overview of the 2002 IAB Network Management Workshop" documented strengths and weaknesses of some IETF management protocols. In choosing existing protocol solutions to meet the management requirements, it is recommended that these strengths and weaknesses be considered, even though some of the recommendations from the 2002 IAB workshop have become outdated, some have been standardized, and some are being worked on at the IETF. [RFC5706] "Guidelines for Considering Operations and Management of New Protocols and Extensions" recommends working groups to consider operations and management needs, and then select appropriate management protocols and data models. This document can be used to ease surveying the IETF standards-track network management protocols and management data models. Note that the document does not cover OAM technologies on the data- path, e.g. OAM of tunnels, MPLS-TP OAM, Pseudowire, etc. [I-D.ietf- opsawg-oam-overview] gives an overview on the OAM toolset for detecting and reporting connection failures or measurement of connection performance parameters. [I-D.ietf-mpls-tp-oam-framework] describes the OAM Framework for MPLS-based Transport Networks. 1.3. Terminology This document does not describe standard requirements. Therefore key words from RFC2119 are not used in the document. Ersue & Claise Expires January 1, 2012 [Page 5] Internet-Draft IETF Management Standards June 2011 o 3GPP: 3rd Generation Partnership Project, a collaboration between groups of telecommunications associations, to prepare the third- generation (3G) mobile phone system specification. o Agent: A software module that performs the network management functions requested by network management stations. An agent may be implemented in any network element that is to be managed, such as a host, bridge, or router. The 'management server' in NETCONF terminology. o CLI: Command Line Interface. A management interface that system administrators can use to interact with networking equipment. o Data model: A mapping of the contents of an information model into a form that is specific to a particular type of data store or repository (see [RFC3444]). o Event: An occurrence of something in the "real world". Events can be indicated to managers through an event message or notification. o IAB: Internet Architecture Board o IANA: Internet Assigned Numbers Authority, an organization that oversees global IP address allocation, autonomous system number allocation, media types, and other Internet Protocol-related code point allocations. o Information model: An abstraction and representation of entities in a managed environment, their properties, attributes and operations, and the way they relate to each other. Independent of any specific repository, protocol, or platform (see [RFC3444]). o ITU-T: International Telecommunication Union - Telecommunication Standardization Sector o Managed object: A management abstraction of a resource; a piece of management information in a MIB module. In the context of SNMP, a structured set of data variables that represent some resource to be managed or other aspect of a managed device. o Manager: An entity that acts in a manager role, either a user or an application. The counterpart to an agent. A 'management client' in NETCONF terminology. o Management Information Base (MIB): An information repository with related collection of objects that represent an aggregation of resources to be managed. MIB modules are defined by using the modeling language SMI. Ersue & Claise Expires January 1, 2012 [Page 6] Internet-Draft IETF Management Standards June 2011 o MIB module: A MIB definition, typically for a particular network technology feature, that constitutes a subtree in an object identifier tree. A MIB that is provided by a management agent is typically composed of multiple instantiated MIB modules. o Modeling language: A modeling language is any artificial language that can be used to express information or knowledge or systems in a structure that is defined by a consistent set of rules. Examples are SMIv2, XSD, and YANG. o Notification: An event message. o OAM: Operations, Administration, and Maintenance o PDU: Protocol Data Unit, a unit of data, which is specified in a protocol of a given layer consisting protocol-control information and possibly layer-specific data. o Relax NG: REgular LAnguage for XML Next Generation, a schema language for XML. o SDO: Standard Development Organization o Trap: An unsolicited message sent by an agent to a management station to notify an unusual event. o URI: Uniform Resource Identifier, a string of characters used to identify a name or a resource on the Internet. Can be classified as locators (URLs), or as names (URNs), or as both. o XPATH: XML Path Language, a query language for selecting nodes from an XML document. 2. Core Network Management Protocols 2.1. Simple Network Management Protocol (SNMP) 2.1.1. Architectural Principles of SNMP The SNMPv3 Framework [RFC3410], builds upon both the original SNMPv1 and SNMPv2 framework. The basic structure and components for the SNMP framework did not change between its versions and comprises following components: o managed nodes, each with an SNMP entity providing remote access to management instrumentation (the agent), Ersue & Claise Expires January 1, 2012 [Page 7] Internet-Draft IETF Management Standards June 2011 o at least one SNMP entity with management applications (the manager), and o a management protocol used to convey management information between the SNMP entities, and management information. During its evolution, the fundamental architecture of the SNMP Management Framework remained consistent based on a modular architecture, which consists of: o a generic protocol definition independent of the data it is carrying, and o a protocol-independent data definition language, o an information repository containing a data set of management information definitions (the Management Information Base, or MIB), and o security and administration. As such following standards build up the basis of the current SNMP Management Framework: o SNMPv3 protocol [STD62], o the modeling language SMIv2 [RFC2578][RFC2579], and o MIB modules for different management issues. The SNMPv3 Framework extends the architectural principles of SNMPv1 and SNMPv2 by: o building on these three basic architectural components, in some cases incorporating them from the SNMPv2 Framework by reference, and o by using the same layering principles in the definition of new capabilities in the security and administration portion of the architecture. 2.1.2. SNMP and its Versions SNMP is based on three conceptual entities: Manager, Agent, and the Management Information Base (MIB). In any configuration, at least one manager node runs SNMP management software. Typically, network devices such as bridges, routers, and servers are equipped with an agent. The agent is responsible for providing access to a local MIB Ersue & Claise Expires January 1, 2012 [Page 8] Internet-Draft IETF Management Standards June 2011 of objects that reflects the resources and activity at its node. Following the manager-agent paradigm, an agent can generate notifications and send them as unsolicited messages to the management application. SNMPv2 enhances this basic functionality with a Trap PDU, an Inform message, a bulk transfer capability and other functional extensions like an administrative model for access control, security extensions, and Manager-to-Manager communication. SNMPv2 entities can have a dual role as manager and agent. However, neither SNMPv1 nor SNMPv2 offers sufficient security features. To address the security deficiencies of SNMPv1/v2, SNMPv3 was issued as a set of Proposed Standards (see [STD62]). [BCP74][RFC3584] "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework" gives an overview of the relevant standard documents on the three SNMP versions. The BCP document furthermore describes how to convert MIB modules from SMIv1 to SMIv2 format and how to translate notification parameters as well as describes the mapping between the message processing and security models (see [RFC3584]). SNMP utilizes the Management Information Base, a virtual information store of modules of managed objects. Generally, standard MIB modules support common functionality in a device. Operators often define additional MIB modules for their enterprise or use the Command Line Interface (CLI) to configure non-standard data in managed devices and their interfaces. SNMPv2 trap and inform PDUs can alert an operator or an application when some aspect of a protocol fails or encounters an error condition, and the contents of a notification can be used to guide subsequent SNMP polling to gather additional information about an event. SNMP is widely used for monitoring of fault and performance data and with its stateless nature SNMP also works well for status polling and determining the operational state of specific functionality. The widespread use of counters in standard MIB modules permits the interoperable comparison of statistics across devices from different vendors. Counters have been especially useful in monitoring bytes and packets going in and out over various protocol interfaces. SNMP is often used to poll basic parameter of a device (e.g. sysUpTime, which reports the time since the last reinitialization of the device) to check for operational liveliness, and to detect discontinuities in counters. Some operators use SNMP also for configuration management in their environment (e.g. for DOCSIS-based systems such as cable modems). Ersue & Claise Expires January 1, 2012 [Page 9] Internet-Draft IETF Management Standards June 2011 SNMPv1 [RFC1157] is a Full Standard that the IETF has declared Historic and it is not recommended due to its lack of security features. "Community-based SNMPv2" [RFC1901] is an Experimental RFC, which IETF has declared Historic and it is not recommended due to its lack of security features. SNMPv3 [STD62] is a Full Standard that is recommended due to its security features, including support for authentication, encryption, message timeliness and integrity checking, and fine-grained data access controls. An overview of the SNMPv3 document set is in [RFC3410]. Standards exist to use SNMP over diverse transport and link layer protocols, including Transmission Control Protocol (TCP) [STD7][RFC0793], User Datagram Protocol (UDP) [STD6][RFC0768], Ethernet [RFC4789], and others (see Section 2.1.5.1). 2.1.3. Structure of Managed Information (SMI) SNMP MIB modules are defined with the notation and grammar specified as the Structure of Managed Information (SMI). The SMI uses an adapted subset of Abstract Syntax Notation One (ASN.1) [ITU-X680]. The SMI is divided into three parts: module definitions, object definitions, and, notification definitions. o Module definitions are used when describing information modules. An ASN.1 macro, MODULE-IDENTITY, is used to concisely convey the semantics of an information module. o Object definitions are used when describing managed objects. An ASN.1 macro, OBJECT-TYPE, is used to concisely convey the syntax and semantics of a managed object. o Notification definitions are used when describing unsolicited transmissions of management information. An ASN.1 macro, NOTIFICATION-TYPE, is used to concisely convey the syntax and semantics of a notification. SMIv1 is specified in [STD16][RFC1155] "Structure and Identification of Management Information for TCP/IP-based Internets" and [STD16][RFC1212] "Concise MIB Definitions". [RFC1215] specifies conventions for defining SNMP traps. Note that SMIv1 is outdated and is not recommended to use. SMIv2 is the new notation for managed information definition and should be used to define MIB modules. SMIv2 is specified in following RFCs: Ersue & Claise Expires January 1, 2012 [Page 10] Internet-Draft IETF Management Standards June 2011 o [STD58][RFC2578] defines Version 2 of the Structure of Management Information (SMIv2), o [STD58][RFC2579] defines common MIB "Textual Conventions", o [STD58][RFC2580] defines Conformance Statements and requirements for defining agent and manager capabilities, and o [RFC3584] defines the mapping rules for and the conversion of MIB modules between SMIv1 and SMIv2 formats. 2.1.4. SNMP Security and Access Control Models 2.1.4.1. Security Requirements on the SNMP Management Framework Several of the classical threats to network protocols are applicable to management problem space and therefore applicable to any security model used in an SNMP Management Framework. This section lists principal threats, secondary threats, and threats which are of lesser importance (see [RFC3411] for the detailed description of the security threats). The principal threats against which SNMP Security Models can provide protection are, "modification of information" by an unauthorized entity, and "masquerade", i.e. the danger that management operations not authorized for some principal may be attempted by assuming the identity of another principal. Secondary threats against which SNMP Security Models within this architecture can provide protection are "message stream modification", e.g. re-ordering, delay or replay of messages, and "disclosure", i.e. the danger of eavesdropping on the exchanges between SNMP engines. There are two threats against which a Security Model within this architecture does not protect, since they are deemed to be of lesser importance in this context: "Denial of Service" and "Traffic Analysis" (see [RFC3411]). 2.1.4.2. User-Based Security Model (USM) SNMPv3 [STD62] introduced the User Security Model (USM). USM provides authentication and privacy services for SNMP and is specified in [RFC3414]. Specifically, USM is designed to secure against the principal and secondary threats discussed in Section 2.1.4.1. USM does not secure against Denial of Service and attacks based on Traffic Analysis. Ersue & Claise Expires January 1, 2012 [Page 11] Internet-Draft IETF Management Standards June 2011 The security services the USM security model supports are: o Data Integrity is the provision of the property that data has not been altered or destroyed in an unauthorized manner, nor have data sequences been altered to an extent greater than can occur non- maliciously. o Data Origin Authentication is the provision of the property that the claimed identity of the user on whose behalf received data was originated is supported. o Data Confidentiality is the provision of the property that information is not made available or disclosed to unauthorized individuals, entities, or processes. o Message timeliness and limited replay protection is the provision of the property that a message whose generation time is outside of a specified time window is not accepted. See [RFC3414] for a detailed description of SNMPv3 USM. 2.1.4.3. View-Based Access Control Model (VACM) SNMPv3 [STD62] introduced the View-Based Access Control (VACM) facility. The VACM [RFC3415] enables the configuration of agents to provide different levels of access to the agent's MIB. An agent entity can restrict access to its MIB for a particular manager entity in two ways: o The agent entity can restrict access to a certain portion of its MIB, e.g., an agent may restrict most manager principals to viewing performance-related statistics and allow only a single designated manager principal to view and update configuration parameters. o The agent can limit the operations that a principal can use on that portion of the MIB. E.g., a particular manager principal could be limited to read-only access to a portion of an agent's MIB. VACM defines five elements that make up the Access Control Model: groups, security level, contexts, MIB views, and access policy. Access to a MIB module is controlled by means of a MIB view. See [RFC3415] for a detailed description of SNMPv3 VACM. Ersue & Claise Expires January 1, 2012 [Page 12] Internet-Draft IETF Management Standards June 2011 2.1.5. SNMP Transport Subsystem and Transport Models The User-based Security Model (USM) was designed to be independent of other existing security infrastructures to ensure it could function when third-party authentication services were not available. As a result, USM utilizes a separate user and key-management infrastructure. Operators have reported that the deployment of a separate user and key-management infrastructure in order to use SNMPv3 is costly and hinders the deployment of SNMPv3. SNMP Transport Subsystem [RFC5590] extends the original SNMP architecture and transport model and enables the use of transport protocols to provide message security unifying the administrative security management for SNMP, and other management interfaces. Transport Models are tied into the SNMP framework through the Transport Subsystem. The Transport Security Model [RFC5591] has been designed to work on top of lower-layer, secure Transport Models. The SNMP Transport Model defines an alternative to existing standard transport mappings described in [RFC3417] e.g. for SNMP over UDP, in [RFC4789] for SNMP over IEEE 802 networks as well as in the Experimental RFC [RFC3430] defining SNMP over TCP. 2.1.5.1. SNMP Transport Security Model The SNMP Transport Security Model [RFC5591] is an alternative to the existing SNMPv1 Security Model [RFC3584], the SNMPv2c Security Model [RFC3584], and the User-based Security Model [RFC3414]. The Transport Security Model utilizes one or more lower-layer security mechanisms to provide message-oriented security services. These include authentication of the sender, encryption, timeliness checking, and data integrity checking. A secure transport model sets up an authenticated and possibly encrypted session between the Transport Models of two SNMP engines. After a transport-layer session is established, SNMP messages can be sent through this session from one SNMP engine to the other. The new Transport Model supports the sending of multiple SNMP messages through the same session to amortize the costs of establishing a security association. The Secure Shell (SSH) Transport Model [RFC5592] and the Transport Layer Security (TLS) Transport Model [RFC5953] are current examples for Transport Security Models. The SSH Transport Model makes use of the commonly deployed SSH Ersue & Claise Expires January 1, 2012 [Page 13] Internet-Draft IETF Management Standards June 2011 security and key-management infrastructure. [RFC5592] furthermore defines MIB objects for monitoring and managing the SSH Transport Model for SNMP. The Transport Layer Security (TLS) transport model uses either the TLS protocol or the Datagram TLS (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. TLS transport model supports the sending of SNMP messages over TLS and TCP and over DTLS and UDP. [RFC5953] furthermore defines MIB objects for managing the TLS Transport Model for SNMP. Note: Different IETF standards use security layers to address security threads (e.g. TLS [RFC5246], Simple Authentication and Security Layer (SASL) [RFC4422], and SSH [RFC4251]). Diverse management interfaces from IETF use a secure transport layer to provide secure information and message exchange to build management applications, e.g. SYSLOG [RFC5424], IPFIX [RFC5101] and NETCONF [RFC4741]. [RFC5608] describes the use of a 'Remote Authentication Dial-In User Service' (RADIUS) service by SNMP secure Transport Models for authentication of users and authorization of services. Access control authorization, i.e. how RADIUS attributes and messages are applied to the specific application area of SNMP Access Control Models, and VACM in particular has been specified in [RFC6065]. 2.2. SYSLOG Protocol SYSLOG is a mechanism for distribution of logging information initially used on Unix systems. IETF documented the status quo of the BSD SYSLOG protocol in the Informational [RFC3164]. The IETF SYSLOG protocol [RFC5424] obsoletes [RFC3164] and introduces a layered architecture allowing the use of any number of transport protocols, including reliable and secure transports, for transmission of SYSLOG messages. The body of an BSD SYSLOG message has traditionally been unstructured text. This content is human-friendly, but difficult to parse for applications. The content of BSD SYSLOG messages correlate across vendors and with other event reporting such as SNMP traps. The SYSLOG protocol enables a machine to send system log messages across networks to event message collectors. The protocol is simply designed to transport and distribute these event messages. By default, no acknowledgements of the receipt are made, except the reliable delivery extensions specified in [RFC3195] are used. The SYSLOG protocol and process does not require a stringent coordination Ersue & Claise Expires January 1, 2012 [Page 14] Internet-Draft IETF Management Standards June 2011 between the transport sender and the receiver. Indeed, the transmission of SYSLOG messages may be started on a device without a receiver being configured, or even actually physically present. Conversely, many devices will most likely be able to receive messages without explicit configuration or definitions. BSD SYSLOG had little uniformity for the message format and the content of SYSLOG messages. The IETF has standardized a new message header format, including timestamp, hostname, application, and message ID, to improve filtering, interoperability and correlation between compliant implementations. The SYSLOG protocol [RFC5424] introduces a mechanism for defining Structured Data Elements (SDEs). The SDEs allow vendors to define their own structured data elements to supplement standardized elements. [RFC5675] defines a mapping from SNMP notifications to SYSLOG messages. [RFC5676] defines a SNMP MIB module to represent SYSLOG messages for sending SYSLOG messages as notifications to SNMP notification receivers. [RFC5674] defines the way alarms are sent in SYSLOG, which includes the mapping of ITU perceived severities onto SYSLOG message fields and a number of alarm-specific definitions from ITU-T X.733 and the IETF Alarm MIB. [RFC5848] "Signed Syslog Messages" defines a mechanism to add origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to the transmitted SYSLOG messages to be used in conjunction with the SYSLOG protocol. The SYSLOG protocol layered architecture provides support for any number of transport mappings. However, for interoperability purposes, SYSLOG protocol implementers are required to support the transmission of SYSLOG Messages over UDP as defined in [RFC5426]. [RFC3195] describes mappings of the SYSLOG protocol to TCP connections, useful for reliable delivery of event messages. As such the specification provides robustness and security in message delivery with encryption and authentication over a connection- oriented protocol that is unavailable to the usual UDP-based SYSLOG protocol. IETF furthermore defined the TLS transport mapping for SYSLOG in [RFC5425], which provides a secure connection for the transport of SYSLOG messages. [RFC5425] describes the security threats to SYSLOG and how TLS can be used to counter such threats. [RFC6012] defines the Datagram Transport Layer Security (DTLS) Transport Mapping for SYSLOG, which can be used if a connectionless transport is desired. For information on MIB modules related to SYSLOG see Section 4.1. Ersue & Claise Expires January 1, 2012 [Page 15] Internet-Draft IETF Management Standards June 2011 2.3. IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols The IPFIX protocol [RFC5101], IP Flow Information eXport, is a Proposed Standard, which defines a push-based data export mechanism for transferring IP flow information in a compact binary format from an exporter to a collector. The IPFIX architecture [RFC5470] defines the components involved in IP flow measurement and reporting of information on IP flows, particularly, a metering process generating flow records, an exporting process that sends metered flow information using the IPFIX protocol, and a colleting process that receives flow information as IPFIX data records. The IPFIX protocol and the IPFIX architecture have been specified following the requirements in [RFC3917]. IPFIX can run over different transport protocols. The IPFIX protocol [RFC5101] specifies Stream Control Transmission Protocol (SCTP) [RFC4960] as the mandatory transport protocol to implement. Optional alternatives are TCP [STD7] and UDP [STD6]. SCTP is used with its Partial Reliability extension (PR-SCTP) specified in [RFC3758]. [I-D.ietf-ipfix-export-per-sctp-stream] specifies an extension to RFC 5101, when using the PR-SCTP [RFC3758]. The extension offers several advantages over IPFIX export, e.g. the ability to calculate Data Record losses for PR-SCTP, immediate reuse of Template IDs within an SCTP stream, reduced likelihood of Data Record loss, and reduced demands on the Collecting Process. IPFIX transmits IP flow information in data records containing IPFIX Information Elements (IEs) defined by the IPFIX information model [RFC5102]. IPFIX information elements are quantities with unit and semantics defined by the information model. When transmitted over the IPFIX protocol, only their values need to be carried in data records. This compact encoding allows efficient transport of large numbers of measured flow values. Remaining redundancy in data records can be further reduced by methods described in [RFC5473] (for further discussion on IPFIX IEs see Section 4). The IPFIX information model is extensible. New information elements can be registered at IANA (see 'IPFIX Information Elements' in [IANA- PROT]). IPFIX also supports the use of proprietary, i.e. enterprise- specific information elements. The PSAMP protocol [RFC5476] extends the IPFIX protocol by means of transferring information on individual packets. [RFC5475] specifies Ersue & Claise Expires January 1, 2012 [Page 16] Internet-Draft IETF Management Standards June 2011 a set of sampling and filtering techniques for IP packet selection and the PSAMP information model [RFC5477] provides a set of basic information elements for reporting packet information with the IPFIX/ PSAMP protocol. The IPFIX model of an IP traffic flow is uni-directional. [RFC5103] adds means to IPFIX for reporting bi-directional flows, for example both directions of packet flows of a TCP connection. When enterprise-specific information elements are transmitted with IPFIX, a collector receiving data records may not know the type of received data and cannot choose the right format for storing the contained information. [RFC5610] provides means for providing type information of enterprise-specific information Elements from an exporter to a collector. Collectors may store received flow information in files. The IPFIX file format [RFC5655] can be used for storing IP flow information in a way that facilitates exchange of traffic flow information between different systems and applications. In terms of IPFIX and PSAMP configurations, the metering and exporting processes are configured out of band. As the IPFIX protocol is a push mechanism only, IPFIX cannot configure the exporter. The actual configuration of selection processes, caches, exporting processes, and collecting processes of IPFIX and PSAMP compliant monitoring devices is executed using the NETCONF protocol [RFC4741] (see Section 2.4.1). The 'Configuration Data Model for IPFIX and PSAMP' is ongoing work and is specified using Unified Modeling Language (UML) class diagrams. The data model is formally defined using the YANG modeling language [RFC6020] in [I-D.draft-ietf-ipfix-configuration-model] (see Section 2.4.2). At the time of this writing a framework for IPFIX flow mediation is in preparation, which addresses the need for mediation of flow information in IPFIX applications in large operator networks, e.g. for aggregating huge amounts of flow data and for anonymization of flow information (see the problem statement in [RFC5982]). The IPFIX Mediation Framework [RFC6183] defines the intermediate device between exporters and collectors, which provides an IPFIX mediation by receiving a record stream from e.g. a collecting process, hosting one or more intermediate processes to transform this stream, and exporting the transformed record stream into IPFIX messages via an exporting process. Examples for mediation functions are flow aggregation, flow selection [I-D.ietf-ipfix-flow-selection-tech], and anonymization of traffic Ersue & Claise Expires January 1, 2012 [Page 17] Internet-Draft IETF Management Standards June 2011 information [RFC6235]. Privacy, integrity, and authentication of exporter and collector are important security requirements for IPFIX [RFC3917]. Confidentiality, integrity, and authenticity of IPFIX data transferred from an exporting process to a collecting process must be ensured. The IPFIX and PSAMP protocols do not define any new security mechanism and rely on the security mechanism of the underlying transport protocol, such as TLS [RFC5246] and DTLS [RFC4347]. While the primary goal of IPFIX is the reporting of the flow accounting for flexible flow definitions and usage-based accounting, there are several other applications such as traffic profiling, traffic engineering, intrusion detection, and QoS monitoring, that require flow-based traffic measurements and can be realized using IPFIX. Similar flow information could be also used for security monitoring. The addition of performance metrics in the IPFIX IANA registry [IANA-IPFIX], will extend the IPFIX use case to performance management. With further information elements, IPFIX can also be applied to monitoring of application-level protocols, for example, Session Initiation Protocol (SIP) [RFC3261] and related media transfer protocols. Requirements to such a monitoring on the application level include measuring signaling quality (e.g., session request delay, session completion ratio, or hops for request), media Quality of Service (QoS) (e.g., jitter, delay or bit rate), and user experience (e.g., Mean Opinion Score). Note that even if the initial IPFIX focus has been around IP flow information exchange, non IP-related information elements are now specified in IPFIX IANA registration (e.g. MAC (Media Access Control) address, MPLS (Multiprotocol Label Switching) labels, etc.). At the time of this writing, there are requests to widen the focus of IPFIX and to export also non-IP related information elements (such as SIP monitoring IEs). The IPFIX Structured Data [I-D.draft-ietf-ipfix-structured-data] is an extension to the IPFIX protocol, which supports hierarchical structured data and lists (sequences) of Information Elements in data records. This extension allows the definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between templates. Furthermore the extension provides the semantics to express the relationship among multiple list elements in a structured data record. Ersue & Claise Expires January 1, 2012 [Page 18] Internet-Draft IETF Management Standards June 2011 For information on data models related to the management of the IPFIX and PSAMP protocols see Section 4.1 and Section 4.2. For information on IPFIX/PSAMP IEs see Section 4.3. 2.4. Network Configuration 2.4.1. Network Configuration Protocol (NETCONF) The IAB workshop on Network Management [RFC3535] determined advanced requirements for configuration management: o Robustness: Minimizing disruptions and maximizing stability, o Support of task-oriented view, o Extensible for new operations, o Standardized error handling, o Clear distinction between configuration data and operational state, o Distribution of configurations to devices under transactional constraints, o Single and multi-system transactions and scalability in the number of transactions and managed devices, o Operations on selected subsets of management data, o Dump and reload a device configuration in a textual format in a standard manner across multiple vendors and device types, o Support a human interface and a programmatic interface, o Data modeling language with a human friendly syntax, o Easy conflict detection and configuration validation, and o Secure transport, authentication, and robust access control. The NETCONF protocol [RFC4741] is a Proposed Standard that provides mechanisms to install, manipulate, and delete the configuration of network devices and aims to address the configuration management requirements pointed in the IAB workshop. It uses an XML-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple and reliable Remote Procedure Call (RPC) layer. A key aspect of NETCONF Ersue & Claise Expires January 1, 2012 [Page 19] Internet-Draft IETF Management Standards June 2011 is that it allows the functionality of the management protocol to closely mirror the native command line interface of the device. The NETCONF working group developed the NETCONF Event Notifications Mechanism as an optional capability, which provides an asynchronous message notification delivery service for NETCONF [RFC5277]. NETCONF notification mechanism enables using general purpose notification streams, where the originator of the notification stream can be any managed device (e.g. SNMP notifications). NETCONF Partial Locking specification introduces fine-grained locking of the configuration datastore to enhance NETCONF for fine-grained transactions on parts of the datastore [RFC5717]. The NETCONF working group also defined the necessary data model to monitor the NETCONF protocol by using the modeling language YANG [RFC6022] (see Section 2.4.2). The monitoring data model includes information about NETCONF datastores, sessions, locks, and statistics, which facilitate the management of a NETCONF server. NETCONF connections are required to provide authentication, data integrity, confidentiality, and replay protection. NETCONF depends on the underlying transport protocol for this capability. For example, connections can be encrypted in TLS or SSH, depending on the underlying protocol. The NETCONF working group defined the SSH transport protocol as the mandatory transport binding [RFC4742]. Other optional transport bindings are TLS [RFC5539], BEEP (over TLS) [RFC4744], and SOAP (over HTTP over TLS) [RFC4743]. The NETCONF working group updated the NETCONF base protocol standard as [RFC6241] and the SSH transport protocol mapping as [RFC6242]. At the time of this writing NETCONF Access Control Model (NACM) is being specified. NACM proposes standard mechanisms to restrict protocol access to particular users with a pre-configured subset of operations and content. 2.4.2. YANG - NETCONF Data Modeling Language Following the guidelines of the IAB management workshop [RFC3535], the NETMOD working group developed a data modeling language defining the semantics of operational and configuration data, notifications, and operations [RFC6020]. The new data modeling language maps directly to XML-encoded content (on the wire) and will serve as the normative description of NETCONF data models. Ersue & Claise Expires January 1, 2012 [Page 20] Internet-Draft IETF Management Standards June 2011 YANG has following properties addressing specific requirements on a modeling language for configuration management: o YANG provides the means to define hierarchical data models. It supports reusable data types and groupings, i.e., a set of schema nodes that can be reused across module boundaries. o YANG supports the distinction between configuration and state data. In addition, it provides support for modeling event notifications and the specification of operations that extend the base NETCONF operations. o YANG allows to express constraints on data models by means of type restrictions and XPATH 1.0 [XPATH] expressions. XPATH expressions can also be used to make certain portions of a data model conditional. o YANG supports the integration of standard and vendor defined data models. YANG's augmentation mechanism allows to seamlessly augment standard data models with proprietary extensions. o YANG data models can be partitioned into collections of features, allowing low-end devices to only implement the core features of a data model while high-end devices may choose to support all features. The supported features are announced via the NETCONF capability exchange to management applications. o The syntax of the YANG language is compact and optimized for human readers. An associated XML-based syntax called the YANG Independent Notation (YIN) [RFC6020] is available to allow the processing of YANG data models with XML-based tools. The mapping rules for the translation of YANG data models into Document Schema Definition Languages (DSDL), of which Relax NG is a major component, are defined in [RFC6110]. o Devices implementing standard data models can document deviations from the data model in separate YANG modules. Applications capable of discovering deviations can make allowances that would otherwise not be possible. A collection of common data types for IETF-related standards is provided in [RFC6021]. This standard data type library has been derived to a large extend from common SMIv2 data types, generalizing them to a less constrained NETCONF framework. The document "An Architecture for Network Management using NETCONF and YANG" describes how NETCONF and YANG can be used to build network management applications that meet the needs of network operators Ersue & Claise Expires January 1, 2012 [Page 21] Internet-Draft IETF Management Standards June 2011 [RFC6244]. The Experimental RFC [RFC6095] specifies extensions for YANG introducing language abstractions such as class inheritance and recursive data structures. [RFC6087] gives guidelines for the use of YANG within IETF and other standardization organizations. Work is underway to standardize a translation of SMIv2 data models into YANG data models preserving investments into SNMP MIB modules, which are widely available for monitoring purposes. Several independent and open source implementations of the YANG data modeling language and associated tools are available. While YANG is a relatively recent data modeling language, some data models have already been produced. The specification of the base NETCONF protocol operations has been revised and uses YANG as the normative modeling language to specify its operations [RFC6241]. The IPFIX working group is currently preparing the normative model for configuring and monitoring IPFIX and PSAMP compliant monitoring devices using the YANG modeling language [I-D.draft-ietf-ipfix-configuration-model]. At the time of this writing the NETMOD working group is developing core system and interface data models. Following the example of the IPFIX configuration model, IETF working groups will prepare models for their specific needs. For information on data models developed using the YANG modeling language see Section 4.1 and Section 4.2. 3. Network Management Protocols and Mechanisms with specific Focus This section reviews additional protocols IETF offers for management and discusses for which applications they were designed and/or already successfully deployed. These are protocols that have mostly reached Proposed Standard status or higher within the IETF. 3.1. IP Address Management 3.1.1. Dynamic Host Configuration Protocol (DHCP) The Draft Standard Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network and enables as such auto-configuration in IP networks. In addition to IP address management, DHCP can also Ersue & Claise Expires January 1, 2012 [Page 22] Internet-Draft IETF Management Standards June 2011 provide other configuration information, such as default routers, the IP addresses of recursive DNS servers and the IP addresses of NTP servers. As described in [RFC6272] DHCP can be used for IPv4 and IPv6 Address Allocation and Assignment as well as for Service Discovery. There are two versions of DHCP, one for IPv4 (DHCPv4) [RFC2131] and one for IPv6 (DHCPv6) [RFC3315]. DHCPv4 was defined as an extension to BOOTP (Bootstrap Protocol) [RFC0951]. DHCPv6 was subsequently defined to accommodate new functions required by IPv6 such as assignment of multiple addresses to an interface and to address limitations in the design of DHCPv4 resulting from its origins in BOOTP. While both versions bear the same name and perform the same functionality, the details of DHCPv4 and DHCPv6 are sufficiently different that they can be considered separate protocols. In addition to the assignment of IP addresses and other configuration information, DHCP options like the Relay Agent Information option (DHCPv4) [RFC3046] and, the Interface-Id Option (DHCPv6) [RFC3315] are widely used by ISPs. DHCPv6 includes Prefix Delegation [RFC3633], which is used to provision a router with an IPv6 prefix for use in the DHCPv6 includes Prefix Delegation [RFC3633], which is used to provision a router with an IPv6 prefix for use in the subnetwork supported by the router. Following are examples of DHCP options that provide configuration information or access to specific servers. A complete lists of DHCP options are available at [IANA-PROT]. o [RFC3646] describes DHCPv6 options for passing a list of available DNS recursive name servers and a domain search list to a client. o [RFC2610] describes DHCPv4 options and methods through which entities using the Service Location Protocol can find out the address of Directory Agents in order to transact messages and how the assignment of scope for configuration of SLP User and Service Agents can be achieved. o [RFC3319] specifies DHCPv6 options that allow SIP clients to locate a local SIP server that is to be used for all outbound SIP requests, a so-called outbound proxy server. o [RFC4280] defines DHCPv6 options to discover the Broadcast and Multicast Service (BCMCS) controller in an IP network. Ersue & Claise Expires January 1, 2012 [Page 23] Internet-Draft IETF Management Standards June 2011 3.1.2. Ad-Hoc Network Autoconfiguration Ad-hoc nodes need to configure their network interfaces with locally unique addresses as well as globally routable IPv6 addresses, in order to communicate with devices on the Internet. The IETF AUTOCONF working group developed [RFC5889], which describes the addressing model for ad-hoc networks and how nodes in these networks configure their addresses. The ad-hoc nodes under consideration are expected to be able to support multi-hop communication by running MANET (Mobile ad-hoc network) routing protocols as developed by the IETF MANET working group. From the IP layer perspective, an ad hoc network presents itself as a layer 3 multi-hop network formed over a collection of links. The addressing model aims to avoid problems for ad-hoc-unaware parts of the system, such as standard applications running on an ad-hoc node or regular Internet nodes attached to the ad-hoc nodes. 3.2. IPv6 Network Operations The IPv6 Operations Working Group develops guidelines for the operation of a shared IPv4/IPv6 Internet and provides operational guidance on how to deploy IPv6 into existing IPv4-only networks, as well as into new network installations. o The Proposed Standard [RFC4213] specifies IPv4 compatibility mechanisms for dual stack and configured tunneling that can be implemented by IPv6 hosts and routers. Dual stack implies providing complete implementations of both IPv4 and IPv6, and configured tunneling provides a means to carry IPv6 packets over unmodified IPv4 routing infrastructures. o [RFC3574] lists different scenarios in 3GPP defined packet network that would need IPv6 and IPv4 transition, where [RFC4215] does a more detailed analysis of the transition scenarios that may come up in the deployment phase of IPv6 in 3GPP packet networks. o [RFC4029] describes and analyzes different scenarios for the introduction of IPv6 into an ISP's existing IPv4 network. [RFC5181] provides a detailed description of IPv6 deployment, integration methods and scenarios in wireless broadband access networks (802.16) in coexistence with deployed IPv4 services. [RFC4057] describes the scenarios for IPv6 deployment within enterprise networks. Ersue & Claise Expires January 1, 2012 [Page 24] Internet-Draft IETF Management Standards June 2011 o [RFC4038] specifies scenarios and application aspects of IPv6 transition considering how to enable IPv6 support in applications running on IPv6 hosts, and giving guidance for the development of IP version-independent applications. 3.3. Policy-based Management 3.3.1. IETF Policy Framework IETF specified a general policy framework [RFC2753] for managing, sharing, and reusing policies in a vendor independent, interoperable, and scalable manner. [RFC3460] specifies the Policy Core Information Model (PCIM) as an object-oriented information model for representing policy information. PCIM has been developed jointly in the IETF Policy Framework working group and the Common Information Model (CIM) activity in the Distributed Management Task Force (DMTF). PCIM has been published as extensions to CIM [DMTF-CIM]. The IETF Policy Framework is based on a policy-based admission control specifying two main architectural elements, the Policy Enforcement Point (PEP) and the Policy Decision Point (PDP). For the purpose of network management, policies allow an operator to specify how the network is to be configured and monitored by using a descriptive language. Furthermore, it allows the automation of a number of management tasks, according to the requirements set out in the policy module. IETF Policy Framework has been accepted by the industry as a standard-based policy management approach and has been adopted by different SDOs e.g. for 3GGP charging standards. 3.3.2. Common Open Policy Service (COPS) and COPS Usage for Policy Provisioning (COPS-PR) [RFC3159] defines the Structure of Policy Provisioning Information (SPPI), an extension to the SMIv2 modeling language used to write Policy Information Base (PIB) modules. COPS-PR [RFC3084] uses the Common Open Policy Service (COPS) protocol [RFC2748] for provisioning of policy information. The COPS-PR specification is independent of the type of policy being provisioned (QoS, Security, etc.) but focuses on the mechanisms and conventions used to communicate provisioned information between policy-decision-points (PDPs) and policy enforcement points (PEPs). Policy data is modeled using Policy Information Base (PIB) modules. COPS-PR has not been widely deployed, and operators have stated that its use of binary encoding (BER) for management data makes it difficult to develop automated scripts for simple configuration Ersue & Claise Expires January 1, 2012 [Page 25] Internet-Draft IETF Management Standards June 2011 management tasks in most text-based scripting languages. In the IAB Workshop on Network Management [RFC3535], the consensus of operators and protocol developers indicated a lack of interest in PIB modules for use with COPS-PR. As a result, even if COPS-PR and the Structure of Policy Provisioning Information (SPPI) were initially approved as Proposed Standards, the IESG has not approved any PIB modules as IETF standard, and the use of COPS-PR is not recommended. 3.4. IP Performance Metrics (IPPM) The IPPM working group has defined metrics for accurately measuring and reporting the quality, performance, and reliability of Internet data delivery. The metrics include connectivity, one-way delay and loss, round-trip delay and loss, delay variation, loss patterns, packet reordering, bulk transport capacity, and link bandwidth capacity. These metrics are designed for use by network operators and their customers, and provide unbiased quantitative measures of performance. The IPPM metrics have been developed inside an active measurement context, that is, the devices used to measure the metrics produce their own traffic. However, most of the metrics can be used inside a passive context as well. At the time of this writing there is no work planned in the area of passive measurement. As a property individual IPPM performance and reliability metrics need to be well-defined and concrete thus implementable. Furthermore, the methodology used to implement a metric needs to be repeatable with consistent measurements. IETF IP Performance Metrics have been introduced widely in the industry and adopted by different SDOs such as the Metro Ethernet Forum. Following are examples of essential IPPM documents published as Proposed Standard: o IPPM Framework document [RFC2330] defines a general framework for particular metrics developed by IPPM working group and defines the fundamental concepts of 'metric' and 'measurement methodology' and discusses the issue of measurement uncertainties and errors as well as introduces the notion of empirically defined metrics and how metrics can be composed. o [RFC2679] "One-way Delay Metric for IPPM", defines a metric for one-way delay of packets across Internet paths. It builds on Ersue & Claise Expires January 1, 2012 [Page 26] Internet-Draft IETF Management Standards June 2011 notions introduced in the IPPM Framework document. o [RFC2681] "Round-trip Delay Metric for IPPM", defines a metric for round-trip delay of packets across network paths and follows closely the corresponding metric for One-way Delay. o [RFC3393] "IP Packet Delay Variation Metric", refers to a metric for variation in delay of packets across network paths and is based on the difference in the One-Way-Delay of selected packets called "IP Packet Delay Variation (ipdv)". o [RFC2680] "One-way Packet Loss Metric for IPPM", defines a metric for one-way packet loss across Internet paths. o [RFC5560] "One-Way Packet Duplication Metric", defines a metric for the case, where multiple copies of a packet are received and discusses methods to summarize the results of streams. o [RFC4737] "Packet Reordering Metrics", defines metrics to evaluate whether a network has maintained packet order on a packet-by- packet basis and discusses the measurement issues, including the context information required for all metrics. o [RFC2678] "IPPM Metrics for Measuring Connectivity", defines a series of metrics for connectivity between a pair of Internet hosts. o [RFC5835] "Framework for Metric Composition", describes a detailed framework for composing and aggregating metrics. Next to the metrics, two protocols to measure these metrics have been standardized: o [RFC4656] "A One-way Active Measurement Protocol (OWAMP)", measures unidirectional characteristics such as one-way delay and one-way loss between network devices and enables the interoperability of these measurements. o [RFC5357] "A Two-Way Active Measurement Protocol (TWAMP)", adds round-trip or two-way measurement capabilities to OWAMP. o [RFC3432] "Network performance measurement with Periodic Streams", describes a periodic sampling method and relevant metrics for assessing the performance of IP networks, as an alternative to the Poisson sampling method described in [RFC2330]. For information on MIB modules related to IP Performance Metrics see Section 4.4. Ersue & Claise Expires January 1, 2012 [Page 27] Internet-Draft IETF Management Standards June 2011 3.5. Remote Authentication Dial In User Service (RADIUS) RADIUS [RFC2865], the Remote Authentication Dial In User Service, is a Draft Standard that describes a client/server protocol for carrying authentication, authorization, and configuration information between a Network Access Server (NAS), which desires to authenticate its links and a shared Authentication Server. The companion document [RFC2866] 'Radius Accounting' describes a protocol for carrying accounting information between a network access server and a shared accounting server. [RFC2867] adds required new RADIUS accounting attributes and new values designed to support the provision of tunneling in dial-up networks. The RADIUS protocol is widely implemented and is used in environments like enterprise networks, where a single administrative authority manages the network, and protects the privacy of user information. RADIUS is widely deployed in fixed broadband access provider networks as well as in certain cellular broadband operators' networks. RADIUS uses attributes to carry the specific authentication, authorization, information and configuration details. RADIUS is extensible with a known limitation of maximum 255 attribute codes and 253 octets as attribute content length. RADIUS has Vendor-Specific Attributes (VSA), which have been used both for vendor-specific purposes as an addition to standardized attributes as well as to extend the limited attribute code space. IETF has been working on a solution to extend the attribute space beyond 255 and allowing attributes longer than 253 octets. A recent proposal [I-D.dekok- radext-radius-extensions] extends the 'conventional' attribute space up to ~1000 attributes and add another ~500 'long' attributes with a length bound by the RADIUS packet size. As a side product, the attribute extension also introduces a new RADIUS attribute type Type- Length-Value (TLV) in a similar fashion as DIAMETER Attribute-Value Pairs (AVP) (see [RFC3588]). TLVs allow grouping and nesting of attributes in a similar way as DIAMETER Grouped AVPs. The RADIUS protocol uses a shared secret along with the MD5 (Message- Digest algorithm 5) hashing algorithm to secure passwords. Based on the known threads additional protection like IPsec tunnels are used to further protect the RADIUS traffic. However, building and administering large IPsec protected networks may become a management burden, especially when IPsec protected RADIUS infrastructure should provide inter-provider connectivity. A trend has been moving towards TLS-based security solutions and establishing dynamic trust relationships between RADIUS servers. Once TCP transport was introduced to RADIUS, it became natural to have a TLS support for RADIUS [I-D.ietf-radext-radsec]. Ersue & Claise Expires January 1, 2012 [Page 28] Internet-Draft IETF Management Standards June 2011 [RFC2868] 'RADIUS Attributes for Tunnel Protocol Support' defines a number of RADIUS attributes designed to support the provision compulsory of tunneling in dial-up network access. Some applications involve compulsory tunneling i.e. the tunnel is created without any action from the user and without allowing the user any choice in the matter. In order to provide this functionality, specific RADIUS attributes are needed to carry the tunneling information from the RADIUS server to the tunnel end points. [RFC3868] defines the necessary attributes, attribute values and the required IANA registries. [RFC3162] 'RADIUS and IPv6' specifies the operation of RADIUS over IPv6 and the RADIUS attributes used to support the IPv6 network access. [RFC4818] describes how to transport delegated IPv6 prefix information over RADIUS [RFC4675] 'RADIUS Attributes for Virtual LAN and Priority Support' defines additional attributes for dynamic Virtual LAN assignment and prioritization, for use in provisioning of access to IEEE 802 local area networks usable with RADIUS and DIAMETER. [RFC5080] 'Common RADIUS Implementation Issues and Suggested Fixes' describes common issues seen in RADIUS implementations and suggests some fixes. Where applicable, unclear statements and errors in previous RADIUS specifications are clarified. People designing extensions to RADIUS protocol for various deployment cases should get familiar with RADIUS Design Guidelines [I-D.ietf-radext-design] in order to avoid e.g. known interoperability challenges. [RFC5090] 'RADIUS Extension for Digest Authentication' defines an extension to the RADIUS protocol to enable support of Digest Authentication, for use with HTTP-style protocols like the Session Initiation Protocol (SIP) and HTTP. [RFC5580] 'Carrying Location Objects in RADIUS and DIAMETER describes procedures for conveying access-network ownership and location information based on civic and geospatial location formats in RADIUS and DIAMETER. [RFC5607] specifies required RADIUS attributes and their values for authorizing a management access to a NAS. Both local and remote management are supported, with access rights and management privileges. Specific provisions are made for remote management via Framed Management protocols, such as SNMP and NETCONF, and for management access over a secure transport protocols. [RFC3579] describes how to use RADIUS to convey Extensible Authentication Protocol (EAP) payload between the authenticator and Ersue & Claise Expires January 1, 2012 [Page 29] Internet-Draft IETF Management Standards June 2011 the EAP server using RADIUS. RFC3579 is widely implemented, for example, in WLAN and 802.1X environment. [RFC3580] describes how to use RADIUS with IEEE 802.1X authenticators. In the context of 802.1X and EAP-based authentication, the Vendor Specific Attributes described in [RFC2458] have been widely accepted by the industry. [RFC2869] 'RADIUS extensions' is another important RFC related to EAP use. RFC2869 describes additional attributes for carrying AAA information between a NAS and a shared Accounting Server using RADIUS. It also defines attributes to encapsulate EAP message payload. There are an extensive number of MIB modules defined for multiple purposes to use with RADIUS (see Section 4.3 and Section 4.5 ). RADIUS is catching up DIAMETER functionality-wise (see Section 3.6). However, it should be noted that newly introduced features such as TCP-based transport, extended attributes or new security features are not yet widely implemented, and are unlikely to be upgraded to the deployed legacy in a near future. 3.6. Diameter Base Protocol (DIAMETER) DIAMETER [RFC3588] is a Proposed Standard that provides an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. DIAMETER is also intended to work in local AAA and in roaming scenarios. DIAMETER provides an upgrade path for RADIUS but is not directly backwards compatible. DIAMETER is designed to resolve a number of known problems with RADIUS. DIAMETER supports server failover, reliable transport over TCP and SCTP, well documented functions for proxy, redirect and relay agent functions, server-initiated messages, auditability, and capability negotiation. DIAMETER also provides a larger attribute space for Attribute-Value Pairs (AVP) and identifiers than RADIUS. DIAMETER features make it especially appropriate for environments, where the providers of services are in different administrative domains than the maintainer (protector) of confidential user information. Other important differences to RADIUS are: o Network and transport layer security (IPsec or TLS), o Stateful and stateless models, o Dynamic discovery of peers (using DNS SRV and NAPTR), Ersue & Claise Expires January 1, 2012 [Page 30] Internet-Draft IETF Management Standards June 2011 o Concept of an application that describes how a specific set of commands and Attribute-Value Pairs (AVPs) are treated by DIAMETER nodes. Each application has an IANA assigned unique identifier, o Support of application layer acknowledgements, failover methods and state machines, o Basic support for user-sessions and accounting, o Better roaming support, o Error notification, and o Easy extensibility. The DIAMETER protocol is designed to be extensible to support e.g. proxies, brokers, mobility and roaming, Network Access Servers (NASREQ), and Accounting and Resource Management. DIAMETER applications extend the DIAMETER base protocol by adding new commands and/or attributes. Each application is defined by an unique IANA assigned application identifier and can add new command codes and/or new mandatory AVPs. The DIAMETER application identifier space has been divided into Standards Track and 'First Come First Served' vendor-specific applications. Following are DIAMETER applications published at IETF: o Diameter Base Protocol Application [RFC3588], o Diameter Base Accounting Application [RFC3588], o Diameter Mobile IPv4 Application [RFC4004], o Diameter Network Access Server Application (NASREQ, [RFC4005]), o Diameter Extensible Authentication Protocol Application [RFC4072], o Diameter Credit-Control Application [RFC4006], o Diameter Session Initiation Protocol Application [RFC4740], and o Diameter Quality-of-Service Application [RFC5866]. o Diameter Mobile IPv6 IKE (MIP6I) Application [RFC5778]. o Diameter Mobile IPv6 Auth (MIP6A) Application [RFC5778]. Ersue & Claise Expires January 1, 2012 [Page 31] Internet-Draft IETF Management Standards June 2011 o Diameter Relay Agent Application [RFC3588]. The large majority of DIAMETER applications are vendor-specific and mainly used in various SDOs outside IETF. One example SDO using DIAMETER extensively is 3GPP. For example the whole 3GPP 'IP Multimedia Subsystem' (IMS) uses DIAMETER based interfaces (e.g. Cx) [3GPPIMS]. Recently, during the standardization of the '3GPP Evolved Packet Core' [3GPPEPC], DIAMETER was chosen as the only AAA signaling protocol. One part of the DIAMETER extensibility mechanism is an easy and consistent way of creating new commands for the need of applications. RFC3588 proposes to define DIAMETER command code allocations by 'IETF Consensus', which requires an RFC to pass through the IETF publication process. This policy decision caused undesired use and redefinition of existing Commands Codes within SDOs. Secondly, diverse RFCs have been published as simple command code allocations for other SDO purposes (see [RFC3589], [RFC5224], [RFC5431] and [RFC5516]). [RFC5719] changed the Command Code policy and added a range for vendor-specific Command Codes to be allocated on a 'First Come First Served' basis by IANA. The implementation and deployment experience of DIAMETER has led to the currently ongoing development of an update of the base protocol [I-D.ietf-dime-rfc3588bis]. One of the major changes is the introduction of TLS as the preferred security mechanism and deprecating the in-band security negotiation for TLS. Some DIAMETER protocol enhancements and clarifications that logically fit better into [I-D.ietf-dime-rfc3588bis], are also needed on the existing RFC3588 based deployments. Therefore, protocol extensions specifically usable in large inter-provider roaming network settlements are made available for RFC3588. Two currently existing specifications are mentioned below: o "Clarifications on the Routing of DIAMETER Requests Based on the Username and the Realm" [RFC5729] defines the behavior required for DIAMETER agents to route requests when the User-Name AVP contains a Network Access Identifier formatted with multiple realms. These multi-realm Network Access Identifiers are used in order to force the routing of request messages through a predefined list of mediating realms. o The ongoing work on "Diameter Extended NAPTR" [I-D.ietf-dime- extended-naptr] describes an improved DNS-based dynamic DIAMETER Agent discovery mechanism without having to do DIAMETER capability exchange beforehand with a number of agents. Ersue & Claise Expires January 1, 2012 [Page 32] Internet-Draft IETF Management Standards June 2011 Experience has shown, that it is hard for IETF to develop DIAMETER applications that actually get adopted and deployed by other SDOs. As a result, there have been a growing number of IETF-defined DIAMETER framework documents that basically are just a collection of AVPs for a specific purpose or system architecture with semantical AVP descriptions and a logic for "imaginary" applications. From standardization point of view, this practice allows the development of larger system architecture documents that do not need to reference AVPs or application logic outside IETF. Below are examples of a few recent AVP and framework documents: o 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction' [RFC5447] describes the bootstrapping of the Mobile IPv6 framework and the support of interworking with existing Authentication, Authorization, and Accounting (AAA) infrastructures by using the DIAMETER Network Access Server to home AAA server interface. o 'Traffic Classification and Quality of Service (QoS) Attributes for Diameter' [RFC5777] defines a number of DIAMETER AVPs for traffic classification with actions for filtering and QoS treatment. o 'Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server' [RFC5779] defines AAA interactions between Proxy Mobile IPv6 (PMIPv6) entities (Mobile Access Gateway and Local Mobility Anchor) and a AAA server within a PMIPv6 Domain. For information on MIB modules related to DIAMETER see Section 4.5. 3.7. Control And Provisioning of Wireless Access Points (CAPWAP) Wireless LAN (WLAN) product architectures have evolved from single autonomous Access Points to systems consisting of a centralized Access Controller (AC) and Wireless Termination Points (WTPs). The general goal of centralized control architectures is to move access control, including user authentication and authorization, mobility management, and radio management from the single access point to a centralized controller, where an Access Points pulls the information from the Access Controller. Based on the CAPWAP Architecture Taxonomy work [RFC4118] the CAPWAP working group developed the CAPWAP protocol [RFC5415] to facilitate control, management and provisioning of WTPs specifying the services, functions and resources relating to 802.11 WLAN Termination Points in order to allow for interoperable implementations of WTPs and ACs. The protocol defines the CAPWAP control plane including the Ersue & Claise Expires January 1, 2012 [Page 33] Internet-Draft IETF Management Standards June 2011 primitives to control data access. The protocol document also specifies how configuration management of WTPs can be done and defines CAPWAP operations responsible for debugging, gathering statistics, logging, and firmware management as well as discusses operational and transport considerations. The CAPWAP protocol is prepared to be independent of Layer 2 technologies, and meets the objectives in "Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)" [RFC4564]. Separate binding extensions enable the use with additional wireless technologies. [RFC5416] defines CAPWAP Protocol Binding for IEEE 802.11. CAPWAP Control messages, and optionally CAPWAP Data messages, are secured using DTLS [RFC4347]. DTLS is used as a tightly integrated, secure wrapper for the CAPWAP protocol. For information on MIB modules related to CAPWAP see Section 4.2. 3.8. Access Node Control Protocol (ANCP) The Access Node Control Protocol (ANCP) [I-D.ietf-ancp-protocol] realizes a control plane between a service-oriented layer 3 edge device, the Network Access Server (NAS) and a layer 2 Access Node (AN), e.g., Digital Subscriber Line Access Module (DSLAM). As such ANCP operates in a multi-service reference architecture and communicates QoS-, service- and subscriber-related configuration and operation information between a NAS and an Access Node. The main goal of this protocol is to configure and manage access equipments and allow them to report information to the NAS in order to enable and optimize configuration. The framework and requirements for an Access Node control mechanism and the use cases for ANCP are documented in [RFC5851]. The ANCP protocol offers authentication, and authorization between AN and NAS nodes and provides replay protection and data-origin authentication. ANCP protocol solution is also robust against Denial-of-Service (DoS) attacks. Furthermore, the ANCP protocol solution is recommended to offer confidentiality protection. Security Threats and Security Requirements for ANCP are discussed in [RFC5713]. 3.9. Application Configuration Access Protocol (ACAP) The Application Configuration Access Protocol (ACAP) [RFC2244] is a Proposed Standard protocol designed to support remote storage and Ersue & Claise Expires January 1, 2012 [Page 34] Internet-Draft IETF Management Standards June 2011 access of program option, configuration and preference information. The data store model is designed to allow a client relatively simple access to interesting data, to allow new information to be easily added without server re-configuration, and to promote the use of both standardized data and custom or proprietary data. Key features include "inheritance" which can be used to manage default values for configuration settings and access control lists which allow interesting personal information to be shared and group information to be restricted. ACAP's primary purpose is to allow applications access to their configuration data from multiple network-connected computers. Users can then use any network-connected computer, run any ACAP-enabled application and have access to their own configuration data. To enable wide usage client simplicity has been preferred to server or protocol simplicity whenever reasonable. The ACAP 'authenticate' command uses Simple Authentication and Security Layer (SASL) [RFC4422] to provide basic authentication, authorization, integrity and privacy services. All ACAP implementations are required to implement the CRAM-MD5 (Challenge- Response Authentication Mechanism) [RFC2195] for authentication, which can be disabled based on the site security policy. 3.10. XML Configuration Access Protocol (XCAP) The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) [RFC4825] is a Proposed Standard protocol that allows a client to read, write, and modify application configuration data stored in XML format on a server. XCAP is a protocol that can be used to manipulate per-user data. XCAP is a set of conventions for mapping XML documents and document components into HTTP URIs, rules for how the modification of one resource affects another, data validation constraints, and authorization policies associated with access to those resources. Because of this structure, normal HTTP primitives can be used to manipulate the data. Like ACAP, XCAP supports the configuration needs for a multiplicity of applications. All XCAP servers are required to implement HTTP Digest Authentication [RFC2617]. Furthermore, XCAP servers are required to implement HTTP over TLS (HTTPS) [RFC2818]. It is recommended that administrators use an HTTPS URI as the XCAP root URI, so that the digest client authentication occurs over TLS. Ersue & Claise Expires January 1, 2012 [Page 35] Internet-Draft IETF Management Standards June 2011 4. Network Management Data Models This section lists management data models standardized at IETF, which can be reused and applied to different management solutions. The subsections below are structured following the management application view and focus mainly on the management data models for the network management tasks fault, configuration, accounting, performance, and security management. The different data models covered in this section are MIB modules, IPFIX Information Elements, SYSLOG Structured Data Elements, and YANG modules. The advancement process for management data models beyond Proposed Standard status, has been defined in [BCP27][RFC2438] with a more pragmatic approach and special considerations on data model specification interoperability. However, most IETF management data models never advance beyond Proposed Standard. 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 referred. 4.1. Fault Management Draft Standards: [RFC3418], part of SNMPv3 standard [STD62], contains 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 a system has rebooted, and counters have been reinitialized. [RFC3413], part of SNMPv3 standard [STD62], includes objects designed for managing notifications, including tables for addressing, retry parameters, security, lists of targets for notifications, and user customization filters. An RMON (Remote Network Monitoring) monitor [RFC2819] can be configured to recognize conditions, most notably error conditions, and continuously to 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.4). Proposed Standards: DISMAN-EVENT-MIB in [RFC2981] and DISMAN-EXPRESSION-MIB in [RFC2982] provide a superset of the capabilities of the RMON alarm and event Ersue & Claise Expires January 1, 2012 [Page 36] Internet-Draft IETF Management Standards June 2011 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: - a mechanism for expressing state transition models for persistent problem states, - a mechanism to correlate a notification with subsequent state transition notifications about the same entity/object, and - a generic alarm reporting mechanism (extends ITU-T work on X.733 [ITU-X733). [RFC3878] in particular defines objects for controlling the reporting of alarm conditions and extends ITU-T work 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 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. 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 Ersue & Claise Expires January 1, 2012 [Page 37] Internet-Draft IETF Management Standards June 2011 on PSAMP MIB module extends the IPFIX MIB modules by managed objects for monitoring PSAMP implementations [I-D.ietf-ipfix-psamp-mib]. The NETCONF working group defined the necessary data model to monitor the NETCONF protocol with the modeling language YANG [RFC6022]. The monitoring data model includes information about NETCONF datastores, sessions, locks, and statistics, which facilitate the management of a NETCONF server. NETCONF monitoring RFC also defines methods for NETCONF clients to discover the data models supported by a NETCONF server and defines the operation to retrieve them. 4.2. Configuration Management MIB modules for monitoring of network configuration (e.g. for physical and logical network topologies) already exist and provide some of the desired capabilities. New MIB modules might be developed for the target functionality to allow operators to monitor and modify the operational parameters, such as timer granularity, event reporting thresholds, target addresses, etc. Draft standards: [RFC3418] contains objects in the system group useful e.g. for identifying the type of device, the location of the device, the person responsible for the device. [RFC3413], part of STD 62 SNMPv3, includes objects designed for configuring notification destinations, and for configuring proxy- forwarding SNMP agents, which can be used to forward messages through firewalls and Network Address Translation (NAT) devices. The Interfaces MIB [RFC2863] is used for managing Network Interfaces. This includes the 'interfaces' group of MIB-II and discusses the experience gained from the definition of numerous media-specific MIB modules for use in conjunction with the 'interfaces' group for managing various sub-layers beneath the internetwork-layer. Proposed standards: The Entity MIB [RFC4133] is used for managing multiple logical and physical entities managed by a single SNMP agent. This module provides a useful mechanism for identifying the entities comprising a system. There are also event notifications defined for configuration changes that may be useful to management applications. [RFC3165] supports the use of user-written scripts to delegate management functionality. Policy Based Management MIB [RFC4011] defines objects that enable Ersue & Claise Expires January 1, 2012 [Page 38] Internet-Draft IETF Management Standards June 2011 policy-based monitoring using SNMP, using a scripting language, and a script execution environment. Few vendors have implemented MIB modules that support scripting. Some vendors consider running user-developed scripts within the managed device as a violation of support agreements. For configuring IPFIX and PSMAP devices, the IPFIX working group is currently developing an XML-based configuration data model [I-D.ietf- ipfix-configuration-model], in close collaboration with the NETMOD working group. IPFIX configuration data model uses YANG as modeling language (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. Non-standard data models: The CAPWAP protocol exchanges Type Length Values (TLV). The base TLVs are specified in [RFC5415], while the TLVs for IEEE 802.11 are specified in [RFC5416]. CAPWAP Base MIB [RFC5833] specifies managed objects for modeling the CAPWAP Protocol and provides configuration and WTP status-monitoring aspects of CAPWAP, where CAPWAP Binding MIB [RFC5834] defines managed objects for modeling of 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. 4.3. Accounting Management Non-standard data models: [RFC4670] 'RADIUS Accounting Client MIB for IPv6' defines RADIUS Accounting Client MIB objects that support version-neutral IP addressing formats. [RFC4671] 'RADIUS Accounting Server MIB for IPv6' 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 Ersue & Claise Expires January 1, 2012 [Page 39] Internet-Draft IETF Management Standards June 2011 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 (IE) have been initially defined in the IPFIX Information Model [RFC5102] and registered at the IANA [IANA-IPFIX]. The IPFIX IEs are composed of two types: IEs related to identification of IP flows and IEs related to counter and timestamps. Following are examples of IEs related to identification of IP flows: o Identifiers for line cards, ports, interfaces, etc... o IP header fields such as source and destination IP addresses o Transport header fields such as UDP and TCP ports o Sub-IP header fields such as source and destination MAC address, MPLS label stack entries o Derived packet properties such as IGP and BGP next hop IP address, BGP AS, etc. o Min/max flow properties such as the minimum and maximum IP total length and Time To Live (TTL) Below are examples for IEs related to counter and timestamps: o Flow timestamps such as flow start times, flow end times, and flow duration, o Per flow counters such as octets count, packets count, o Miscellaneous flow properties such as flow duration. The Information Elements specified in the IPFIX information model [RFC5102] are used by the PSAMP protocol where applicable. Packet Sampling (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 fulfil the requirements on reporting of different sampling and filtering techniques specified in [RFC5475]. Ersue & Claise Expires January 1, 2012 [Page 40] Internet-Draft IETF Management Standards June 2011 4.4. Performance Management RMON (Remote Network Monitoring) MIB [RFC2819] has the Full Standard status [STD59] and defines objects for managing remote network devices and collecting data related to network performance and traffic. An organization may employ many remote management probes, one per network segment, to manage its internet. These devices may be used by a network service provider to access a client network, often geographically remote. Most of the objects in the RMON MIB module are suitable for the management of any type of network, where some of them are specific to management 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. The RMON host group discovers hosts on the network by keeping a list of source and destination MAC Addresses seen in good packets promiscuously received from the network, and contains statistics associated with each host. The hostTopN group is used to prepare reports that describe the hosts that top a list ordered by one of their statistics. The available statistics are samples of one of their base statistics over an interval specified by the management station. Thus, these statistics are rate based. The management station also selects how many such hosts are reported. The RMON matrix group stores statistics for conversations between sets of two addresses. The filter group allows packets to be matched by a filter equation. These matched packets form a data stream that may be captured or may generate events. The Packet Capture group allows packets to be captured after they flow through a channel. The event group controls the generation and notification of events from this device. Draft standards: 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. Proposed standards: RMON MIB Extensions for High Capacity Alarms [RFC3434] describes managed objects for extending the alarm thresholding capabilities Ersue & Claise Expires January 1, 2012 [Page 41] Internet-Draft IETF Management Standards June 2011 found in the RMON MIB and provides similar threshold monitoring of objects based on the Counter64 data type. RMON MIB Extensions for High Capacity Networks [RFC3273] defines objects for managing RMON devices for use on high-speed networks. RMON 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 is part of the RMON protocol family, and supports end-2-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 [RFC2819] and describes managed objects used for real-time application Quality of Service (QoS) monitoring. [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. Application performance measurement measures 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 standards organizations' documents. The IPPM working group defined an Information Model and XML Data Model for Traceroute Measurements [RFC5388], which defines a common information model dividing the information elements 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. The IPPM working group has defined [BCP108][RFC4148] "IP Performance Ersue & Claise Expires January 1, 2012 [Page 42] Internet-Draft IETF Management Standards June 2011 Metrics (IPPM) Metrics Registry". The IANA-assigned registry contains an initial set of OBJECT IDENTITIES to currently defined metrics in the IETF as well as defines the rules for adding IP Performance Metrics that are defined in the future. However, the current registry structure has been found to be insufficiently detailed to uniquely identify IPPM metrics. Due to the ambiguities between the current metrics registrations and the metrics used, and the apparent non-adoption of the registry in practice, it has been proposed to reclassify [RFC4148] as Obsolete and to withdraw the current IPPM Metrics Registry from use. Note: With the publication of [RFC6248] the latest IANA registry for IPFIX metrics has been declared Obsolete and IANA prevents registering new metrics. Actual users can continue using the current registry and its contents. SIP 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. Traffic Flow Measurement: Meter MIB [RFC2720] defines a MIB for use in the 'Traffic Flow Measurement: Architecture' [RFC2722], in particular for specifying the flows to be measured and provides a mechanism for retrieving flow data from the meter using SNMP. 4.5. Security Management There are numerous MIB modules defined for multiple purposes to use with RADIUS: o [RFC4668] 'RADIUS Authentication Client MIB for IPv6' 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 [RFC4669] 'RADIUS Authentication Server MIB for IPv6' 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 [RFC4670] 'RADIUS Accounting Client MIB for IPv6' defines RADIUS Accounting Client MIB that objects that support version-neutral IP addressing formats. o [RFC4671] 'RADIUS Accounting Server MIB for IPv6' defines RADIUS Accounting Server MIB that objects that support version-neutral IP addressing formats. Ersue & Claise Expires January 1, 2012 [Page 43] Internet-Draft IETF Management Standards June 2011 o [RFC4672] 'RADIUS Dynamic Authorization Client MIB' defines the MIB module for entities implementing the client side of the Dynamic Authorization Extensions to RADIUS [RFC5176]. o [RFC4673] 'RADIUS Dynamic Authorization Server MIB' 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], [RFC4670], [RFC4671], [RFC4672], [RFC4673] are intended to be used only for RADIUS over UDP and therefore do not support RADIUS/TCP. There is also a recommendation that RADIUS clients and servers implementing RADIUS/TCP should not re-use earlier listed MIB modules to perform statistics counting for RADIUS/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. There are ongoing efforts to produce standard MIBs for the 'Diameter Base Protocol' [I-D.ietf-dime- diameter-base-protocol-mib] and the 'Diameter Credit-Control Application' [I-D.ietf-dime-diameter-cc-appl-mib]. 5. IANA Considerations This document does not introduce any new code-points or namespaces for registration with IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 6. Security Considerations This document introduces no new security concerns. Note to RFC Editor: this section may be removed on publication as an RFC. 7. Contributors Following persons made significant contributions to this document: o Ralph Droms (Cisco) - revised the section on IP address management and DHCP. o Jouni Korhonen (Nokia Siemens Networks) - contributed the sections on RADIUS and DIAMETER. Ersue & Claise Expires January 1, 2012 [Page 44] Internet-Draft IETF Management Standards June 2011 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 section on YANG. 8. Acknowledgements The editor would like to thank to Tom Petch, Dan Romascanu, Henk Uijterwaal, and Alex Clemm for their valuable suggestions, comments in the OPSAWG sessions and mailing list. The editor would like to especially thank Dave Harrington, who created the document "Survey of IETF Network Management Standards" a few years ago. While this draft expired, the editor used it as a starting point and enhanced it with a special focus on the description of the IETF network management standards and management data models. 9. Informative References [3GPPEPC] 3GPP, "Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP access networks", December 2010, . [3GPPIMS] 3GPP, "Release 10, IP Multimedia Subsystem (IMS); Stage 2", September 2010, . [BCP108] Emile, S., "IP Performance Metrics (IPPM) Metrics Registry", August 2005. [BCP27] D. O'Dell, M., "Advancement of MIB specifications on the IETF Standards Track", October 1998. [BCP74] Frye, R., "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", August 2003. [DMTF-CIM] DMTF, "Common Information Model Schema, Version 2.27.0", November 2010, . [IANA-AAA] Internet Assigned Numbers Authority, "IANA AAA Parameters", June 2011, . Ersue & Claise Expires January 1, 2012 [Page 45] Internet-Draft IETF Management Standards June 2011 [IANA-IPFIX] Internet Assigned Numbers Authority, "IANA IPFIX Information Elements", February 2011, . [IANA-PROT] Internet Assigned Numbers Authority, "IANA Protocol Registries", October 2010, . [IANA-PSAMP] Internet Assigned Numbers Authority, "IANA PSAMP Parameters", April 2009, . [IETF-WGS] IETF, "IETF Working Groups", . [ITU-M3100] International Telecommunication Union, "M.3100: Generic network information model", January 2006, . [ITU-X680] International Telecommunication Union, "X.680: Abstract Syntax Notation One (ASN.1): Specification of basic notation", July 2002, . [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985. [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of management information for TCP/ IP-based internets", STD 16, RFC 1155, May 1990. [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990. [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB definitions", STD 16, RFC 1212, March 1991. [RFC1215] Rose, M., "Convention for defining traps for use with the SNMP", RFC 1215, March 1991. [RFC1901] Case, J., McCloghrie, K., McCloghrie, K., Rose, M., and Ersue & Claise Expires January 1, 2012 [Page 46] Internet-Draft IETF Management Standards June 2011 S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997. [RFC2244] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997. [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. [RFC2438] O'Dell, M., Alvestrand, H., Wijnen, B., and S. Bradner, "Advancement of MIB specifications on the IETF Standards Track", BCP 27, RFC 2438, October 1998. [RFC2458] Lu, H., Krishnaswamy, M., Conroy, L., Bellovin, S., Burg, F., DeSimone, A., Tewani, K., Davidson, P., Schulzrinne, H., and K. Vishwanathan, "Toward the PSTN/ Internet Inter-Networking --Pre-PINT Implementations", RFC 2458, November 1998. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2610] Perkins, C. and E. Guttman, "DHCP Options for Service Location Protocol", RFC 2610, June 1999. [RFC2613] Waterman, R., Lahaye, B., Romascanu, D., and S. Ersue & Claise Expires January 1, 2012 [Page 47] Internet-Draft IETF Management Standards June 2011 Waldbusser, "Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0", RFC 2613, June 1999. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring Connectivity", RFC 2678, September 1999. [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round- trip Delay Metric for IPPM", RFC 2681, September 1999. [RFC2720] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC 2720, October 1999. [RFC2722] Brownlee, N., Mills, C., and G. Ruth, "Traffic Flow Measurement: Architecture", RFC 2722, October 1999. [RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2819] Waldbusser, S., "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, May 2000. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. Ersue & Claise Expires January 1, 2012 [Page 48] Internet-Draft IETF Management Standards June 2011 [RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000. [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000. [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000. [RFC2981] Kavasseri, R., "Event MIB", RFC 2981, October 2000. [RFC2982] Kavasseri, R., "Distributed Management Expression MIB", RFC 2982, October 2000. [RFC3014] Kavasseri, R., "Notification Log MIB", RFC 3014, November 2000. [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001. [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001. [RFC3144] Romascanu, D., "Remote Monitoring MIB Extensions for Interface Parameters Monitoring", RFC 3144, August 2001. [RFC3159] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, S., Sahita, R., Smith, A., and F. Reichmeyer, "Structure of Policy Provisioning Information (SPPI)", RFC 3159, August 2001. [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001. [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001. [RFC3165] Levi, D. and J. Schoenwaelder, "Definitions of Managed Objects for the Delegation of Management Scripts", RFC 3165, August 2001. [RFC3195] New, D. and M. Rose, "Reliable Delivery for syslog", RFC 3195, November 2001. Ersue & Claise Expires January 1, 2012 [Page 49] Internet-Draft IETF Management Standards June 2011 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3273] Waldbusser, S., "Remote Network Monitoring Management Information Base for High Capacity Networks", RFC 3273, July 2002. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers", RFC 3319, July 2003. [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, Ersue & Claise Expires January 1, 2012 [Page 50] Internet-Draft IETF Management Standards June 2011 December 2002. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [RFC3430] Schoenwaelder, J., "Simple Network Management Protocol Over Transmission Control Protocol Transport Mapping", RFC 3430, December 2002. [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network performance measurement with periodic streams", RFC 3432, November 2002. [RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor Management Information Base", RFC 3433, December 2002. [RFC3434] Bierman, A. and K. McCloghrie, "Remote Monitoring MIB Extensions for High Capacity Alarms", RFC 3434, December 2002. [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, January 2003. [RFC3460] Moore, B., "Policy Core Information Model (PCIM) Extensions", RFC 3460, January 2003. [RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network Management Workshop", RFC 3535, May 2003. [RFC3574] Soininen, J., "Transition Scenarios for 3GPP Networks", RFC 3574, August 2003. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003. [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Ersue & Claise Expires January 1, 2012 [Page 51] Internet-Draft IETF Management Standards June 2011 Framework", BCP 74, RFC 3584, August 2003. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC3589] Loughney, J., "Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5", RFC 3589, September 2003. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003. [RFC3729] Waldbusser, S., "Application Performance Measurement MIB", RFC 3729, March 2004. [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004. [RFC3868] Loughney, J., Sidebottom, G., Coene, L., Verwimp, G., Keller, J., and B. Bidulock, "Signalling Connection Control Part User Adaptation Layer (SUA)", RFC 3868, October 2004. [RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management Information Base (MIB)", RFC 3877, September 2004. [RFC3878] Lam, H., Huynh, A., and D. Perkins, "Alarm Reporting Control Management Information Base (MIB)", RFC 3878, September 2004. [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004. [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, August 2005. [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005. Ersue & Claise Expires January 1, 2012 [Page 52] Internet-Draft IETF Management Standards June 2011 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, "Diameter Credit-Control Application", RFC 4006, August 2005. [RFC4011] Waldbusser, S., Saperia, J., and T. Hongal, "Policy Based Management MIB", RFC 4011, March 2005. [RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005. [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005. [RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, June 2005. [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005. [RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4118, June 2005. [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", RFC 4133, August 2005. [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics Registry", BCP 108, RFC 4148, August 2005. [RFC4150] Dietz, R. and R. Cole, "Transport Performance Metrics MIB", RFC 4150, August 2005. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks", RFC 4215, October 2005. [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268, November 2005. Ersue & Claise Expires January 1, 2012 [Page 53] Internet-Draft IETF Management Standards June 2011 [RFC4280] Chowdhury, K., Yegani, P., and L. Madour, "Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers", RFC 4280, November 2005. [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006. [RFC4502] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2", RFC 4502, May 2006. [RFC4564] Govindan, S., Cheng, H., Yao, ZH., Zhou, WH., and L. Yang, "Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4564, July 2006. [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, September 2006. [RFC4668] Nelson, D., "RADIUS Authentication Client MIB for IPv6", RFC 4668, August 2006. [RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6", RFC 4669, August 2006. [RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC 4670, August 2006. [RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6", RFC 4671, August 2006. [RFC4672] De Cnodder, S., Jonnala, N., and M. Chiba, "RADIUS Dynamic Authorization Client MIB", RFC 4672, September 2006. [RFC4673] De Cnodder, S., Jonnala, N., and M. Chiba, "RADIUS Dynamic Authorization Server MIB", RFC 4673, September 2006. [RFC4675] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Attributes for Virtual LAN and Priority Support", RFC 4675, September 2006. [RFC4710] Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real- time Application Quality-of-Service Monitoring (RAQMON) Framework", RFC 4710, October 2006. Ersue & Claise Expires January 1, 2012 [Page 54] Internet-Draft IETF Management Standards June 2011 [RFC4711] Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real- time Application Quality-of-Service Monitoring (RAQMON) MIB", RFC 4711, October 2006. [RFC4712] Siddiqui, A., Romascanu, D., Golovinsky, E., Rahman, M., and Y. Kim, "Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU)", RFC 4712, October 2006. [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, November 2006. [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., Canales-Valenzuela, C., and K. Tammi, "Diameter Session Initiation Protocol (SIP) Application", RFC 4740, November 2006. [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. [RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure SHell (SSH)", RFC 4742, December 2006. [RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access Protocol (SOAP)", RFC 4743, December 2006. [RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, December 2006. [RFC4789] Schoenwaelder, J. and T. Jeffree, "Simple Network Management Protocol (SNMP) over IEEE 802 Networks", RFC 4789, November 2006. [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", RFC 4818, April 2007. [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Ersue & Claise Expires January 1, 2012 [Page 55] Internet-Draft IETF Management Standards June 2011 Suggested Fixes", RFC 5080, December 2007. [RFC5090] Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D., and W. Beck, "RADIUS Extension for Digest Authentication", RFC 5090, February 2008. [RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008. [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008. [RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export Using IP Flow Information Export (IPFIX)", RFC 5103, January 2008. [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008. [RFC5181] Shin, M-K., Han, Y-H., Kim, S-E., and D. Premec, "IPv6 Deployment Scenarios in 802.16 Networks", RFC 5181, May 2008. [RFC5224] Brenner, M., "Diameter Policy Processing Application", RFC 5224, March 2008. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008. [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, October 2008. [RFC5388] Niccolini, S., Tartarelli, S., Quittek, J., Dietz, T., and M. Swany, "Information Model and XML Data Model for Traceroute Measurements", RFC 5388, December 2008. [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, March 2009. Ersue & Claise Expires January 1, 2012 [Page 56] Internet-Draft IETF Management Standards June 2011 [RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11", RFC 5416, March 2009. [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. [RFC5425] Miao, F., Ma, Y., and J. Salowey, "Transport Layer Security (TLS) Transport Mapping for Syslog", RFC 5425, March 2009. [RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP", RFC 5426, March 2009. [RFC5427] Keeni, G., "Textual Conventions for Syslog Management", RFC 5427, March 2009. [RFC5431] Sun, D., "Diameter ITU-T Rw Policy Enforcement Interface Application", RFC 5431, March 2009. [RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and K. Chowdhury, "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction", RFC 5447, February 2009. [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009. [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports", RFC 5473, March 2009. [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, March 2009. [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009. [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, March 2009. [RFC5516] Jones, M. and L. Morand, "Diameter Command Code Registration for the Third Generation Partnership Ersue & Claise Expires January 1, 2012 [Page 57] Internet-Draft IETF Management Standards June 2011 Project (3GPP) Evolved Packet System (EPS)", RFC 5516, April 2009. [RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", RFC 5539, May 2009. [RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric", RFC 5560, May 2009. [RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B. Aboba, "Carrying Location Objects in RADIUS and Diameter", RFC 5580, August 2009. [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem for the Simple Network Management Protocol (SNMP)", RFC 5590, June 2009. [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", RFC 5591, June 2009. [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)", RFC 5592, June 2009. [RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management", RFC 5607, July 2009. [RFC5608] Narayan, K. and D. Nelson, "Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models", RFC 5608, August 2009. [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, "Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements", RFC 5610, July 2009. [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, "Specification of the IP Flow Information Export (IPFIX) File Format", RFC 5655, October 2009. [RFC5674] Chisholm, S. and R. Gerhards, "Alarms in Syslog", RFC 5674, October 2009. [RFC5675] Marinov, V. and J. Schoenwaelder, "Mapping Simple Network Management Protocol (SNMP) Notifications to Ersue & Claise Expires January 1, 2012 [Page 58] Internet-Draft IETF Management Standards June 2011 SYSLOG Messages", RFC 5675, October 2009. [RFC5676] Schoenwaelder, J., Clemm, A., and A. Karmakar, "Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications", RFC 5676, October 2009. [RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, November 2009. [RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)", RFC 5713, January 2010. [RFC5717] Lengyel, B. and M. Bjorklund, "Partial Lock Remote Procedure Call (RPC) for NETCONF", RFC 5717, December 2009. [RFC5719] Romascanu, D. and H. Tschofenig, "Updated IANA Considerations for Diameter Command Code Allocations", RFC 5719, January 2010. [RFC5729] Korhonen, J., Jones, M., Morand, L., and T. Tsou, "Clarifications on the Routing of Diameter Requests Based on the Username and the Realm", RFC 5729, December 2009. [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., and A. Lior, "Traffic Classification and Quality of Service (QoS) Attributes for Diameter", RFC 5777, February 2010. [RFC5778] Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction", RFC 5778, February 2010. [RFC5779] Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A., and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server", RFC 5779, February 2010. [RFC5815] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, "Definitions of Managed Objects for IP Flow Information Export", RFC 5815, April 2010. Ersue & Claise Expires January 1, 2012 [Page 59] Internet-Draft IETF Management Standards June 2011 [RFC5833] Shi, Y., Perkins, D., Elliott, C., and Y. Zhang, "Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Base MIB", RFC 5833, May 2010. [RFC5834] Shi, Y., Perkins, D., Elliott, C., and Y. Zhang, "Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding MIB for IEEE 802.11", RFC 5834, May 2010. [RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric Composition", RFC 5835, April 2010. [RFC5848] Kelsey, J., Callas, J., and A. Clemm, "Signed Syslog Messages", RFC 5848, May 2010. [RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, "Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks", RFC 5851, May 2010. [RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., and G. Zorn, "Diameter Quality-of-Service Application", RFC 5866, May 2010. [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad Hoc Networks", RFC 5889, September 2010. [RFC5953] Hardaker, W., "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", RFC 5953, August 2010. [RFC5982] Kobayashi, A. and B. Claise, "IP Flow Information Export (IPFIX) Mediation: Problem Statement", RFC 5982, August 2010. [RFC6012] Salowey, J., Petch, T., Gerhards, R., and H. Feng, "Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog", RFC 6012, October 2010. [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, October 2010. [RFC6022] Scott, M. and M. Bjorklund, "YANG Module for NETCONF Monitoring", RFC 6022, October 2010. Ersue & Claise Expires January 1, 2012 [Page 60] Internet-Draft IETF Management Standards June 2011 [RFC6035] Pendleton, A., Clark, A., Johnston, A., and H. Sinnreich, "Session Initiation Protocol Event Package for Voice Quality Reporting", RFC 6035, November 2010. [RFC6065] Narayan, K., Nelson, D., and R. Presuhn, "Using Authentication, Authorization, and Accounting Services to Dynamically Provision View-Based Access Control Model User-to-Group Mappings", RFC 6065, December 2010. [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG Data Model Documents", RFC 6087, January 2011. [RFC6095] Linowski, B., Ersue, M., and S. Kuryla, "Extending YANG with Language Abstractions", RFC 6095, March 2011. [RFC6110] Lhotka, L., "Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content", RFC 6110, February 2011. [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, "IP Flow Information Export (IPFIX) Mediation: Framework", RFC 6183, April 2011. [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization Support", RFC 6235, May 2011. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, June 2011. [RFC6244] Shafer, P., "An Architecture for Network Management Using NETCONF and YANG", RFC 6244, June 2011. [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete", RFC 6248, April 2011. [RFC6272] Baker, F. and D. Meyer, "Internet Protocols for the Smart Grid", RFC 6272, June 2011. [RFCSEARCH] IETF, "RFC Index Search Engine", January 2006, . [STD16] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/ Ersue & Claise Expires January 1, 2012 [Page 61] Internet-Draft IETF Management Standards June 2011 IP-based Internets", May 1990. [STD58] McCloghrie, K., David, D., and J. Juergen, "Structure of Management Information Version 2 (SMIv2)", April 1999. [STD59] Waldbusser, S., "Remote Network Monitoring Management Information Base", May 2000. [STD6] Postel, J., "User Datagram Protocol", August 1980. [STD62] Harrington, D., "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", December 2002. [STD7] Postel, J., "Transmission Control Protocol", September 1981. [XPATH] World Wide Web Consortium, "XML Path Language (XPath) Version 1.0", November 1999, . 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 categorize the protocols 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 they are not recommended to use (see Section 3.3). Ersue & Claise Expires January 1, 2012 [Page 62] Internet-Draft IETF Management Standards June 2011 A.1. Protocols classified by the Standard Maturity at IETF This section classifies the management protocols according their standard maturity at the IETF. The IETF standard maturity levels Proposed, Draft or Full Standard, are defined in [RFC2026]. IETF specifications must have "multiple, independent, and interoperable implementations" before they can be advanced from Proposed to Draft Standard status. An Internet or Full Standard (also referred as 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] | Full Standard | | SYSLOG [RFC5424] | Proposed Standard | | IPFIX [RFC5101] | Proposed Standard | | PSAMP [RFC5476] | Proposed Standard | | NETCONF [RFC4741] | Full Standard | | DHCP for IPv4 [RFC2131] | Draft Standard | | DHCP for IPv6 [RFC3315] | Proposed Standard | | OWAMP [RFC4656] | Proposed Standard | | TWAMP [RFC5357] | Full Standard | | RADIUS [RFC2865] | Draft Standard | | DIAMETER [RFC3588] | Proposed Standard | | CAPWAP [RFC5416] | Proposed Standard | | ANCP [I-D.ietf-ancp-protocol] (in RFCed | Proposed Standard | | queue) | | | Ad-hoc network configuration [RFC5889] | Informational | | ACAP [RFC2244] | Proposed Standard | | XCAP [RFC4825] | Proposed Standard | +-----------------------------------------------+-------------------+ Table 1: Protocols classified by Standard Maturity at IETF A.2. Protocols Matched to Management Tasks (FCAPS) This subsection classifies the management protocols matching to the management tasks for fault, configuration, accounting, performance, and security management. Ersue & Claise Expires January 1, 2012 [Page 63] Internet-Draft IETF Management Standards June 2011 +------------+-------------+------------+-----------+---------------+ | Fault | Configurati | Accounting | Performan | Security | | Management | on | Management | ce | Management | | | Management | | Manageme | | | | | | nt | | +------------+-------------+------------+-----------+---------------+ | SNMP | SNMP | SNMP | SNMP | | | (notificat | (configurat | (monitorin | (monitori | | | ion with | ion with se | gwith get | ng with | | | trap | toperation) | operation | get | | | operation | | ) | operatio | | | ) | | | n) | | | IPFIX | | IPFIX | IPFIX | | | PSAMP | | PSAMP | PSAMP | | | | | RADIUS | | RADIUS | | | | (Accountin | | (Authenticati | | | | g) | | on & | | | | | | Authorizatio | | | | | | n) | | | | DIAMETER | | DIAMETER | | | | (Accountin | | (Authenticati | | | | g) | | on & | | | | | | Authorizatio | | | | | | n) | | | CAPWAP | | | | | SYSLOG | | | | | | | NETCONF | | | | | | ANCP | | | | | | AUTOCONF | | | | | | ACAP | | | | | | XCAP | | | | | | DHCP | | | | +------------+-------------+------------+-----------+---------------+ Table 2: Protocols Matched to Management Tasks 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. The client/ server protocols, such as RADIUS, DIAMETER, and DHCP are not listed here. Ersue & Claise Expires January 1, 2012 [Page 64] Internet-Draft IETF Management Standards June 2011 +---------------------------------+---------------------------------+ | Protocols supporting the Pull | Protocols supporting the Push | | mechanism | mechanism | +---------------------------------+---------------------------------+ | SNMP (except notifications) | SNMP notifications | | NETCONF (except notifications) | NETCONF notifications | | CAPWAP | SYSLOG | | | IPFIX | | | PSAMP | +---------------------------------+---------------------------------+ 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. +---------------------------------+---------------------------------+ | Protocols supporting passive | Protocols supporting active | | monitoring | monitoring | +---------------------------------+---------------------------------+ | IPFIX (network) | OWAMP (network) | | PSAMP (network) | TWAMP (network) | | SNMP (network and device) | | | NETCONF (device) | | | RADIUS (accounting) | | | DIAMETER (accounting) | | | CAPWAP (device) | | +---------------------------------+---------------------------------+ 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, SNMP protocol itself does not have operations, which support active monitoring. NETCONF can be used for Ersue & Claise Expires January 1, 2012 [Page 65] Internet-Draft IETF Management Standards June 2011 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 as 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 | Approach to | Proprietary | | | | extend the Data | Data | | | | Model | Modeling | | | | | Extensions | +-------------+--------------------+------------------+-------------+ | SNMP | MIB modules | New MIB modules | Enterprise | | | defined with SMI | specified in new | specific | | | | RFCs | MIB modules | | SYSLOG | Structured Data | EDITOR'S NOTE: | Enterprise | | | Elements (SDE) | to be checked | specific | | | | | SDEs | | IPFIX | IPFIX Information | With the | Enterprise | | | Elements, IPFIX | procedure to add | specific | | | IANA registry at | Information | Information | | | [IANA-IPFIX] | Elements | Elements | | | | specified in | | | | | [RFC5102] | | | PSAMP | PSAMP Information | With the | Enterprise | | | Elements, PSAMP | procedure to add | specific | | | IANA registry at | Information | Information | | | [IANA-PSAMP] | Elements | Elements | | | | specified in | | | | | [RFC5102] | | | NETCONF | YANG modules | New YANG modules | Enterprise | | | | specified in new | specific | | | | RFCs following | YANG | | | | the guideline in | modules | | | | [RFC6087] | | | IPPM | IPPM metrics (*) | New IPPM metrics | Not | | OWAMP/TWAMP | | | applicable | Ersue & Claise Expires January 1, 2012 [Page 66] Internet-Draft IETF Management Standards June 2011 | RADIUS | Type-Length-Values | RADIUS related | Vendor | | | (TLV) | registries at | Specific | | | | [IANA-AAA] and | Attributes | | | | [IANA-PROT] | (VSA) | | DIAMETER | Attribute-Value | DIAMETER related | Vendor | | | Pairs (AVP) | registry at | Specific | | | | [IANA-AAA] | Attributes | | | | | (VSA) | | CAPWAP | Type-Length-Values | New bindings | Vendor | | | (TLV) | specified in new | specific | | | | RFCs | TLVs | +-------------+--------------------+------------------+-------------+ Table 5: Data Models and their Extensibility (*): Note: 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 the regulation of governments on energy consumption and production. The basic objective of energy management is operating communication networks and other equipments 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 control 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, in which cases 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 Ersue & Claise Expires January 1, 2012 [Page 67] Internet-Draft IETF Management Standards June 2011 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 works on the management of energy-aware devices, covered by the following items: o 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 Energy management framework, which will describe extensions to 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 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 Power and Energy Monitoring MIB document will document defining managed objects for monitoring of power states and energy consumption/production. The monitoring of power states includes: retrieving power states, properties of power states, current power state, power state transitions, and power state statistics. The managed objects will provide means for reporting detailed properties of the actual energy rate (power) and of accumulated energy. Further, it will provide information on electrical power quality. o Battery MIB document will define managed objects for battery monitoring, which will provide means for reporting detailed Ersue & Claise Expires January 1, 2012 [Page 68] Internet-Draft IETF Management Standards June 2011 properties of the actual charge, age, and state of a battery and of battery statistics. o 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 the other existing standards such as those from the IEC, ANSI, DMTF, and others. 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. Appendix C. Open issues o Discuss the focus of Table 4 "Protocol classification by Passive versus Active Monitoring" in the WG. o Add a section or appendix for the high-level overview of IETF MIB modules in contrast to the MIB overview following the FCAPS-based application view o Missing a few cross-references in the HTML version. o Some EDITOR'S NOTES in the draft. Appendix D. Change Log D.1. 00-01 o Reduced text for the Security Requirements on SNMP and referenced to RFC 3411 o Reduced subsection on VACM o Merged subsection on "RADIUS Authentication and Authorization with SNMP Transport Models" into the section "SNMP Transport Security Model" o Section on Dynamic Host Configuration Protocol (DHCP) revised by Ralph Droms o Subsections on DHCP and Autoconf assembled in section "IP Address Management" Ersue & Claise Expires January 1, 2012 [Page 69] Internet-Draft IETF Management Standards June 2011 o Removed subsection on "Extensible Provision Protocol (EPP)" o Introduced new Appendix on "High Level Classification of Management Protocols and Data Models" o Deleted detailed positive comments o Resolved some of the I-D references with the correct reference to the published RFC number o Added RFC references o Removed text on expired drafts o Resolved bugs, nits and open issues D.2. draft-ersue-opsawg-management-fw-03-00 o Diverse bug fixing o Incorporated comments from Juergen Schoenwaelder o Reduced detailed text on pro and contra on management technologies o Extended Terminology section with terms and abbreviations o Explained the structure based on the management application view o Definition of 'MIB module' aligned in different sections o Text on SNMP security reduced o All protocol sections discuss now security and AAA as far as relevant o Added IPFIX IEs, SYSLOG SDEs and YANG modules to the data model definition o Added text on YANG data modules to section 4.2. o Added text on IPFIX IEs to section 4.3. o Added numerous references Ersue & Claise Expires January 1, 2012 [Page 70] Internet-Draft IETF Management Standards June 2011 D.3. Change Log from draft-ersue-opsawg-management-fw D.3.1. 02-03 o Rearranged the document structure using a flat structure putting all protocols onto the same level. o Incorporated contributions for RADIUS/DIAMETER, IPFIX/PSAMP, YANG, and EMAN. o Added diverse references. o Added Contributors and Acknowledgements sections. o Bug fixing and issue solving. D.3.2. 01-02 o Added terminology section. o Changed the language for neutral standard description addressing diverse SDOs. o Extended NETCONF and NETMOD related text. o Extended section for 'IPv6 Network Operations'. o Bug fixing. D.3.3. 00-01 o Extended text for SNMP o Extended RADIUS and DIAMETER sections. o Added references. o Bug fixing. Ersue & Claise Expires January 1, 2012 [Page 71] Internet-Draft IETF Management Standards June 2011 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 Ersue & Claise Expires January 1, 2012 [Page 72]