Network Working Group M. Ersue Internet-Draft Nokia Siemens Networks Intended status: Informational October 18, 2010 Expires: April 21, 2011 An Overview of the IETF Network Management Framework and Standards draft-ersue-opsawg-management-fw-00 Abstract This document gives an overview of the IETF standard management framework 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 SDOs 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 April 21, 2011. Copyright Notice Copyright (c) 2010 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 carefully, as they describe your rights and restrictions with respect Ersue Expires April 21, 2011 [Page 1] Internet-Draft IETF Management Framework October 2010 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. IETF Standard Management Framework . . . . . . . . . . . . . . 6 2.1. Simple Network Management Protocol (SNMP) and its Architectural Principles . . . . . . . . . . . . . . . . . 6 2.2. SNMP and its Versions . . . . . . . . . . . . . . . . . . 7 2.3. SNMP Security . . . . . . . . . . . . . . . . . . . . . . 8 2.3.1. Security Requirements on the SNMP Management Framework . . . . . . . . . . . . . . . . . . . . . . 8 2.3.2. User-Based Security Model (USM) . . . . . . . . . . . 10 2.3.3. View-Based Access Control Model (VACM) . . . . . . . . 11 2.3.4. SNMP Transport Subsystem and Transport Security Model . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.5. RADIUS Authentication and Authorization with SNMP Transport Models . . . . . . . . . . . . . . . . . . . 13 2.4. Supplementary Components of the IETF Management Framework . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4.1. NETCONF . . . . . . . . . . . . . . . . . . . . . . . 13 2.4.2. SYSLOG . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4.3. IPFIX/PSAMP . . . . . . . . . . . . . . . . . . . . . 18 3. Management Protocols and Mechanisms with specific Focus . . . 20 3.1. IP Address Management and Server Discovery with DHCP . . . 21 3.2. IPv6 Network Operations . . . . . . . . . . . . . . . . . 22 3.3. SNMP Agent Extensibility (AgentX) Protocol . . . . . . . . 22 3.4. Radius . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.5. Diameter . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.6. CAPWAP . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.7. EPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.8. Access Node Control Protocol . . . . . . . . . . . . . . . 25 3.9. Ad-Hoc Network Autoconfiguration (autoconf) . . . . . . . 25 3.10. Policy-based Management . . . . . . . . . . . . . . . . . 25 3.10.1. IETF Policy Framework . . . . . . . . . . . . . . . . 25 3.10.2. COPS-PR . . . . . . . . . . . . . . . . . . . . . . . 26 3.11. Network Performance Management . . . . . . . . . . . . . . 26 3.11.1. IP Performance Metrics (IPPM) . . . . . . . . . . . . 26 3.11.2. Real-time Flow Measurement (RTFM) . . . . . . . . . . 28 3.12. Application Management Protocols . . . . . . . . . . . . . 28 3.12.1. ACAP . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.12.2. XCAP . . . . . . . . . . . . . . . . . . . . . . . . . 29 4. Proposed, Draft and Standard Level Data Models . . . . . . . . 29 4.1. Fault Management . . . . . . . . . . . . . . . . . . . . . 30 Ersue Expires April 21, 2011 [Page 2] Internet-Draft IETF Management Framework October 2010 4.2. Configuration Management . . . . . . . . . . . . . . . . . 31 4.3. Accounting Management . . . . . . . . . . . . . . . . . . 32 4.4. Performance Management . . . . . . . . . . . . . . . . . . 32 4.5. Security Management . . . . . . . . . . . . . . . . . . . 35 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 6. Security Considerations . . . . . . . . . . . . . . . . . . . 35 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 9. Informative References . . . . . . . . . . . . . . . . . . . . 36 Appendix A. New Work related to IETF Management Framework . . . . 52 A.1. Energy Management (eman) . . . . . . . . . . . . . . . . . 52 Appendix B. Open issues . . . . . . . . . . . . . . . . . . . . . 53 Ersue Expires April 21, 2011 [Page 3] Internet-Draft IETF Management Framework October 2010 1. Introduction This document gives an overview of the IETF standard management framework 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 SDOs or bodies 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 management requirements and to detect possible gaps. [I-D.baker-ietf-core] identifies the key protocols of the Internet Protocol Suite for use in the Smart Grid. The target audience is those people seeking guidance on how to construct an appropriate Internet Protocol Suite profile for the Smart Grid. In analogy to [I-D.baker-ietf-core] this document gives an overview on the IETF management framework and technologies and will show usage scenarios addressing the Smart Grid environment. The Overview of the 2002 IAB Network Management Workshop [RFC3535] 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. 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. Guidelines for Considering Operations and Management of New Protocols and Extensions [RFC5706] 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. Section 2 gives an overview of the IETF standard management framework with a special focus on Simple Network Management Protocol (SNMP) and supplementary components of the IETF management framework such as NETCONF, SYSLOG and IPFIX. Section 3 discusses IETF management protocols and mechanisms with a specific focus and their use cases. Section 4 discusses Proposed, Draft and Standard Level data models, such as MIBs designed to address specific set of issues and maps them to different management tasks. IETF specifications must have "multiple, independent, and interoperable implementations" before they can be advanced to Draft Ersue Expires April 21, 2011 [Page 4] Internet-Draft IETF Management Framework October 2010 Standard status. An Internet Standard, which may simply be referred to as a 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 [RFC2026]. This document mainly refers to Proposed, Draft or Full Standard documents at IETF. As far as it is valuable standard track I-Ds just before publication and Best Current Practice (BCP) documents are referenced. In exceptional cases and if the document provides substantial guideline for standard usage Informational RFCs are noticed. Note: This document uses the expired draft [I-D.ietf-opsawg-survey- management] edited by Dave Harrington as a starting point and enhances it with a special focus on the description of the IETF Standard Management Framework and SNMP security as well as aims to extend it with explanation of the standards, their usage scenarios and new development at IETF. Note: 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.1. Terminology This document does not describe standard requirements. Therefore key words from RFC2119 are not used in the document. o CLI: Command Line Interface 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. o Information model: An abstraction and representation of the entities in a managed environment, their properties, attributes and operations, and the way that they relate to each other. It is independent of any specific repository, software usage, protocol, or platform. NOTE: To be filled out! Ersue Expires April 21, 2011 [Page 5] Internet-Draft IETF Management Framework October 2010 2. IETF Standard Management Framework 2.1. Simple Network Management Protocol (SNMP) and its Architectural Principles As described in [RFC3410] the current version of the Internet Standard Management Framework, the SNMPv3 Framework, builds upon both the original SNMPv1 and SNMPv2 Management Framework. The basic structure and components for the Internet Standard Management 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), 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 Internet Standard 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 a virtual database containing data sets of management information definitions (the Management Information Base, or MIB), and o security and administration. o SNMPv3 protocol, o the modeling language SMIv2, and o MIBs 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 Ersue Expires April 21, 2011 [Page 6] Internet-Draft IETF Management Framework October 2010 o by using the same layering principles in the definition of new capabilities in the security and administration portion of the architecture. NOTE: Add more. 2.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. Network devices such as bridges, routers, and servers are equipped with an agent. The agent is responsible for providing access to a local MIB 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. To enhance this basic functionality, a new version of SNMP has been introduced in 1993. SNMPv2 added 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 in January 1998 (see [STD62]). The BCP document [BCP0074] "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 format 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. MIB module support is uneven across vendors, and even within devices. The lack of standard MIB module support for all functionality in a device forces operators to use other protocols such as a command line interface (CLI) to do configuration of some aspects of their managed devices. Many operators have found it easier to use one protocol for all configurations rather than to split the task across multiple protocols. SNMP is good at determining the operational state of specific functionality, but not necessarily for the complete operational state of a managed device. SNMP is also good for statistics gathering for specific functionality. The widespread use of counters in standard Ersue Expires April 21, 2011 [Page 7] Internet-Draft IETF Management Framework October 2010 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 a device for sysUpTime, which serves to report the time since the last reinitialization of the device, to check for operational liveness, and to detect discontinuities in some counters. SNMP traps and informs 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 fault and performance data. Some operators use SNMP for configuration in various environments, while others find SNMP an inappropriate choice for configuration in their environments. During the IAB Network Management Workshop the attendees expected that the so-called evolutionary approaches would fail and more focus should be put on new approaches, such as XML- based configuration management. SNMPv1 [RFC1157] is a Full Standard that the IETF has declared Historic and it is not recommended due to its lack of security features. SNMPv2c [RFC1901] is an Experimental specification (not a standard of any kind) that the 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, 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 multiple network protocols, including TCP, UDP, Ethernet, OSI, and others. 2.3. SNMP Security 2.3.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 as defined in [RFC3411]. The principal threats against which SNMP Security Models should provide protection are: Ersue Expires April 21, 2011 [Page 8] Internet-Draft IETF Management Framework October 2010 Modification of Information: Information might be altered by an unauthorized entity, e.g. in- transit SNMP messages can be generated to effect unauthorized management operations, including falsifying the value of an object. Masquerade: The masquerade threat is the danger that management operations not authorized for some principal may be attempted by assuming the identity of another principal that has the appropriate authorizations. Secondary threats against which any Security Model used within this architecture should provide protection are: Message Stream Modification: The SNMP protocol is typically based upon a connectionless transport service which may operate over any subnetwork service. The re-ordering, delay or replay of messages can and does occur through the natural operation of many such subnetwork services. The message stream modification threat is the danger that messages may be maliciously re-ordered, delayed or replayed to an extent which is greater than what can occur through the natural operation of a subnetwork service, in order to effect unauthorized management operations. Disclosure: The disclosure threat is the danger of eavesdropping on the exchanges between SNMP engines. Protecting against this threat may be required as a matter of local policy. There are at least two threats against which a Security Model within this architecture need not protect, since they are deemed to be of lesser importance in this context: Denial of Service: A Security Model need not attempt to address the broad range of attacks by which service on behalf of authorized users is denied. Indeed, such denial-of-service attacks are in many cases indistinguishable from the type of network failures with which any viable management protocol must cope as a matter of course. Traffic Analysis: A Security Model need not attempt to address traffic analysis attacks. Many traffic patterns are predictable - entities may be managed on a regular basis by a relatively small number of management stations - and therefore there is no significant advantage afforded by protecting against traffic analysis. Ersue Expires April 21, 2011 [Page 9] Internet-Draft IETF Management Framework October 2010 NOTE: Other requirements to mention from ISMS WG? 2.3.2. User-Based Security Model (USM) The User Security Model (USM) provides authentication and privacy services for SNMP (RFC3414). Specifically, USM is designed to secure against the following principal threats: o Modification of Information: Alteration of an in-transit message generated by an authorized entity in such a way as to effect unauthorized management operations, including the setting of object values. o Masquerade: Management operations that are not authorized for some entity may be attempted by that entity by assuming the identity of an authorized entity. o Message Stream Modification: SNMP messages (transported over a connectionless protocol) could be reordered, delayed, or replayed (duplicated) to affect unauthorized management operations. o Disclosure: An entity could observe exchanges between a manager and an agent and thereby learn the values of managed objects, and learn of notification events. USM does not secure against Denial of Service and attacks based on Traffic Analysis. The security services the SNMP 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] in [STD62] for a detailed description of SNMPv3 USM. Ersue Expires April 21, 2011 [Page 10] Internet-Draft IETF Management Framework October 2010 2.3.3. View-Based Access Control Model (VACM) The View-Based Access Control facility of SNMP 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 It 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. The access control policy to be used by an agent must be pre- configured for each manager. The policy is based on a table that details the access privileges of the various authorized managers. VACM defines five elements that make up the Access Control Model: groups, security level, contexts, MIB views, and access policy. See [RFC3415] in [STD62] for a detailed description of SNMPv3 VACM. 2.3.4. SNMP Transport Subsystem and Transport Security Model 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 having to deploy another user and key-management infrastructure in order to use SNMPv3 is costly and hinders the deployment of SNMPv3. SNMP Transport Subsystem [RFC5590] extends the existing SNMP framework 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 has been designed to work on top of lower-layer, secure Transport Models. The Transport Security Model [RFC5591] and the Secure Shell Transport Model [RFC5592] utilize the Transport Subsystem. The Transport Security Model is an alternative to the existing SNMPv1 Ersue Expires April 21, 2011 [Page 11] Internet-Draft IETF Management Framework October 2010 Security Model [RFC3584], the SNMPv2c Security Model [RFC3584], and the User-based Security Model [RFC3414]. The Secure Shell Transport Model defines furthermore an alternative to existing transport mappings as described in [RFC3417]. The new SNMP Transport Subsystem modifies the Abstract Service Interfaces to pass transport-specific security parameters to other subsystems. This includes transport-specific security parameters that are translated into the transport-independent parameters such as securityName and securityLevel. The SNMP Transport Subsystem 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 establishes an authenticated and possibly encrypted link between the Transport Models of two SNMP engines. After a transport-layer tunnel is established, SNMP messages can be sent through this tunnel from one SNMP engine to the other. The new Transport Model supports sending multiple SNMP messages through the same tunnel to amortize the costs of establishing a security association. The Transport Model on top of a secure transport protocol performs security functions within the Transport Subsystem, including the translation of transport-security parameters to/from Security-Model- independent parameters. To accommodate this, an implementation- specific cache of transport-specific information is introduced and the data flows on this path are extended to pass Security-Model- independent values. For this purpose, the Transport Subsystem extends SNMPv3 Abstract Service Interfaces (ASI). New Security Models can be defined using the modified ASIs and the transport- information cache. [RFC5592] introduces a Transport Model (Secure Shell Transport Model), which makes use of the commonly deployed Secure Shell security infrastructure establishing a channel between itself and the SSH Transport Model of another SNMP engine. Different IETF standards use security layers at the transport or application layer to address security threads (e.g. TLS [RFC5246], Simple Authentication and Security Layer (SASL) [RFC4422], and SSH [RFC4251]). Different management interfaces, e.g. CLI, SYSLOG [RFC5424] and NETCONF [RFC4741], use a secure transport layer to provide secure information and message exchange to build management applications. Ersue Expires April 21, 2011 [Page 12] Internet-Draft IETF Management Framework October 2010 Detailed description of the Transport Subsystem for SNMP and Transport Security Model for SNMP can be found in [RFC5590] and [RFC5591]. Secure Shell Transport Model for SNMP is specified in [RFC5592] and Transport Layer Security (TLS) Transport Model for SNMP is described in [RFC5953]. 2.3.5. RADIUS Authentication and Authorization with SNMP Transport Models [RFC5608] describes the use of a RADIUS (Remote Authentication Dial-In User Service) authentication and authorization service by SNMP secure Transport Models for authentication of users and authorization of secure transport session creation. The secure transport protocols selected for use with RADIUS and SNMP need to support user authentication methods that are compatible with those that exist in RADIUS. Transport Models rely upon the underlying secure transport for user authentication services. The SSH protocol provides a secure transport channel with support for channel authentication via local accounts and integration with various external authentication and authorization services such as RADIUS, Kerberos, etc. SSH Server integration with RADIUS traditionally uses the username and password mechanism. There are two use cases for RADIUS support of management access via SNMP: service authorization and access control authorization, where user authentication needs to be done prior to each of the use cases. Service authorization allows a RADIUS server to authorize an authenticated principal to use SNMP, optionally over a secure transport, typically using an SNMP Transport Model (see [RFC5608]). 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 is currently being specified in the ISMS (Integrated Security Model for SNMP) WG [I-D.ietf-isms-radius- vacm]. 2.4. Supplementary Components of the IETF Management Framework 2.4.1. NETCONF SNMP works well for device monitoring and with its stateless nature SNMP is also useful for statistics and status polling but SNMP has limited configuration management support. o There is a semantic mismatch between the task-oriented view preferred by operators and the data-centric view provided by SNMP, Ersue Expires April 21, 2011 [Page 13] Internet-Draft IETF Management Framework October 2010 o SNMP does not separate clearly between configuration data and operational state, o Implementing SNMP transactional model and the protocol constraints is complex, and o SNMP modeling language has limited support for structured data types and relationships among managed objects. The IAB workshop on Network Management determined advanced requirements for configuration management [IAB2002]: 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 advanced configuration management requirements pointed in the IAB workshop. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF Ersue Expires April 21, 2011 [Page 14] Internet-Draft IETF Management Framework October 2010 protocol operations are realized on top of a simple and reliable Remote Procedure Call (RPC) layer. A key aspect of NETCONF is that it allows the functionality of the management protocol to closely mirror the native command line interface of the device. This reduces implementation costs and allows timely access to new features. In addition, applications can access both the syntactic and semantic content of the device's native user interface. Additionally NETCONF WG 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, which can not only transport NETCONF notifications but also alarms from other sources, where the originator of the NETCONF notification stream can be any managed device (e.g. SNMP alarms). NETCONF Partial Locking introduces fine-grained locking of the configuration datastore to enhance NETCONF for fine-grained transactions on parts of the datastore [RFC5717]. NETCONF WG also defined the necessary data model to monitor the NETCONF protocol by using YANG. The monitoring data model includes information about NETCONF datastores, sessions, locks, and statistics, which facilitate the management of a NETCONF server. NETCONF monitoring document also defines methods for NETCONF clients to discover data models supported by a NETCONF server and defines a new operation to retrieve them [RFC6022]. ADD: Describe how an SNMP agent and a NETCONF server may co-exist on the same managed device using the same datastore for the management data model. NETCONF defined SSH transport binding as the mandatory secure transport of its RPC messages [RFC4742]. Other optional secure transport bindings are available for TLS [RFC5539], BEEP (over TLS) [RFC4744], and SOAP (over HTTP over TLS) [RFC4743]. There is an implementation available using NETCONF over SOAP as a Web Service [RFC5381]. Currently NETCONF workgroup is focusing on bug fixing of the NETCONF base protocol standard [4741bis] and the SSH transport protocol mapping [4742bis] as well as the specification of the NETCONF Access Control Model (NACM). NACM is going to provide a secure operating environment for NETCONF and proposes standard mechanisms to restrict protocol access to particular users with a pre-configured subset of operations and content. Ersue Expires April 21, 2011 [Page 15] Internet-Draft IETF Management Framework October 2010 NETMOD WG developed YANG as the normative modeling language for the modeling of configuration data for usage with NETCONF. YANG follows following design goals addressing specific requirements on a modeling language for configuration management: o Allow modeling of standard and vendor defined modules for multi- vendor interoperability, o Define semantics and data organization, i.e. models operational and configuration data, notifications, and operations, o "human-readable", easy to use and text-based, o Enable addition of new content to existing data models and can be extended at IETF as necessary, o Map directly to XML content (on the wire), and o Basic types compatible with SMIv2 and preserves therefore investments in SNMP MIBs. NETMOD WG furthermore developed Common YANG Data Types to be used with YANG [RFC6021] and a guidelines document for authors and reviewers of YANG Data Model Documents [I-D draft-ietf-netmod-yang-usage] as well as the mapping rules for translating YANG data models into Document Schema Definition Languages (DSDL) [I-D.ietf-netmod-dsdl-map]. The architecture document "An Architecture for Network Management using NETCONF and YANG" describes how NETCONF and YANG can help to build network management applications that meet the needs of network operators [I-D.draft-ietf-netmod-arch]. IPFIX WG prepared the normative IPFIX/PSAMP configuration model for configuring and monitoring IPFIX and PSAMP compliant Monitoring Devices with the YANG modeling language and is proposing to use NETCONF for the configuration of these entities [I-D.ietf-ipfix- configuration-model]. At the time of this writing, the rechartering discussion of the NETMOD WG is ongoing. NETMOD WG aims to focus in its second phase on the development of core system and core interface data models. The WG will not develop models for specific topic areas or workgroups at IETF. Such modeling work will be done in corresponding WGs, e.g. DNSOP WG will develop the DNS configuration model using YANG. Ersue Expires April 21, 2011 [Page 16] Internet-Draft IETF Management Framework October 2010 2.4.1.1. YANG - NETCONF Modeling Language Following the guideline and requests of the IAB management workshop the NETMOD workgroup developed a "human-friendly" modeling language defining the semantics of operational data, configuration data, notifications, and operations [RFC6020]. The new modeling language focuses on readability and ease of use and will serve as the normative description of NETCONF data models. ADD: Input from YANG team? 2.4.2. SYSLOG The SYSLOG protocol [RFC5424] allows a machine to send system log messages across networks to event message collectors. The protocol is simply designed to transport these event messages. No acknowledgement of the receipt is made. One of the fundamental tenets of the SYSLOG protocol and process is its simplicity. No stringent coordination is required between the transmitters and the receivers. 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. This simplicity has greatly aided the acceptance and deployment of SYSLOG. Since each process, application and operating system was written somewhat independently, there has been little uniformity to the message format or content of SYSLOG messages. The IETF has developed a new Proposed Standard version of the protocol that allows the use of any number of transport protocols including reliable transports and secure transports [RFC5424]. The IETF has also standardized the application of message security for SYSLOG messages using TLS [RFC5425], and has defined a mechanism to digitally sign log data to ensure its integrity as log data is moved across the network and/or copied to different data stores [RFC5848]. 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. SYSLOG message content has traditionally been unstructured natural language text. This content is human-friendly, but difficult for applications to parse and correlate across vendors, or correlate with other event reporting such as SNMP traps. The IETF syslog protocol includes structured data elements to aid application-parsing. The Ersue Expires April 21, 2011 [Page 17] Internet-Draft IETF Management Framework October 2010 structured data element design allows vendors to define their own structured data elements to supplement standardized elements. [RFC5675] defines a mapping from SNMP notifications to SYSLOG messages and [RFC5676] defines the corresponding managed objects for this purpose. And [RFC5674] defines the way alarms are send 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. 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. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. [RFC5427] [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 for support of 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]. IETF furthermore defined the TLS transport mapping for Syslog in [RFC5425], which provides a secure connection for the transport of syslog messages and describes the security threats to syslog and how TLS can be used to counter such threats. Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog is defined in [RFC6012], which can be used in cases where a connection-less transport is desired. IETF working groups are encouraged to standardize structured data elements, extensible human-friendly text, and consistent facility/ severity values for SYSLOG to report events specific to their protocol. 2.4.3. IPFIX/PSAMP IPFIX [RFC5101] is a Proposed Standard, which defines a push-based data export mechanism for formatting and transferring IP flow information from an exporter to a collector. PSAMP defines a standard set of capabilities for network elements to sample subsets of packets by statistical and other methods. The IPFIX working group has specified the Information Model (to describe IP flows) and the IPFIX protocol for the export of flow Ersue Expires April 21, 2011 [Page 18] Internet-Draft IETF Management Framework October 2010 information from routers or measurement probes to external systems [RFC5101], [RFC5102]. IPFIX protocol exports flow data e.g. from routers and probes (IPv4, IPv6) and works on top of UDP, TCP or SCTP. Several applications using the IPFIX protocol are available. IPFIX [RFC5101] is a Proposed Standard approach for transmitting IP traffic flow information over the network from an exporting process to an information collecting process. IPFIX defines a common representation of flow data and a standard means of communicating the data over a number of transport protocols. [RFC3917] specifies the observation point, flows, exporting and the collecting process as well as a metering process that consists of a packet header capturing, time stamping, classifying, sampling, and maintaining flow records. IPFIX Information Model defines Information Elements (IEs) for distinguishing flows and for reporting flow characteristics [RFC5102]. Information Model for PSAMP extends the IPFIX information model by IEs for packet header and payload information [RFC5477] and defines packet selection methods for filtering and sampling of such data. IPFIX and PSAMP packet sampling use the same packet processing (aka. packet mediation). PSAMP packet information is exported with the IPFIX protocol based on a shared information model. The IPFIX WG has developed an XML-based configuration data model in close collaboration with the NETMOD WG and uses YANG as modeling language [I-D.ietf-ipfix-configuration-model]. 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 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. IPFIX Mediation Framework 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 [I-D.ietf-ipfix-mediators- framework]. The work on IP Flow Anonymization Support describes anonymization techniques for IP flow data and the export of anonymized data [I-D.ietf-ipfix-anon]. Ersue Expires April 21, 2011 [Page 19] Internet-Draft IETF Management Framework October 2010 The document 'IPFIX Export per SCTP Stream' [I-D.ietf-ipfix-export- per-sctp-stream] specifies a reliability extension based on a method for exporting a Template Record and its associated Data Sets in a single SCTP stream, for limiting each Template ID to a single SCTP stream and imposing in-order transmission. [I-D.ietf-ipfix-structured-data] proposes an extension to the IPFIX protocol to support the export of hierarchically structured data and lists (sequences) of Information Elements in data records. The document describes how to distribute structured data with an abstract data type and a new Information Element, e.g. for the distribution of security keys or performance measures. This application can also be used for the distribution of logging information if standard SYSLOG based logging is not available. There are several applications such as usage-based accounting, traffic profiling, traffic engineering, intrusion detection, and QoS monitoring, that require flow-based traffic measurements, which can be realized on top of IPFIX. IPFIX can also be used e.g. for the monitoring of the protocols like SIP and the related media transfer, which is indeed based on flows on application layer. The requirements to such a monitoring application are e.g. measuring signaling quality (e.g., session request delay, session completion ratio, or hops for request), media QoS (e.g., jitter, delay or bit rate), and user experience (e.g., Mean Opinion Score). Several applications require sampling packets from specific data flows, or across multiple data flows, and reporting information about the packets. Measurement-based network management is a prime example. The PSAMP WG developed the protocol for reporting observed packets by extending the IPFIX protocol. In order to reduce the amount of data to be processed for selecting observed IP packets, packet selection methods have been defined. PSAMP standardizes sampling, selection, metering, and reporting strategies for different purposes and includes support for packet sampling in IPv4, IPv6, and MPLS-based networks. To simplify the solution, the IPFIX protocol is used for the export of the PSAMP reports to collector applications. ADD: Input from IPFIX persons? NOTE: It would be good if an IPFIX person edits this chapter. 3. 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 Ersue Expires April 21, 2011 [Page 20] Internet-Draft IETF Management Framework October 2010 reached or short before Proposed Standard status or higher within the IETF. 3.1. IP Address Management and Server Discovery with DHCP BOOTP (Bootstrap Protocol), originally defined in [RFC951], has been used by network clients during the bootstrap process to obtain an IP address from a configuration server. BOOTP requires manual intervention to add configuration information for each client, and does not provide a mechanism for reclaiming disused IP addresses. The Draft Standard Dynamic Host Configuration Protocol (DHCP) [RFC2131] was defined as an extension to BOOTP. DHCP provides a framework for passing configuration information to hosts on a TCP/IP network and does as such enable autoconfiguration in IP networks. In addition to IP address management, DHCP can also provide other configuration information, particularly the IP addresses of local caching DNS resolvers or servers providing servers. As described in [I-D.baker-ietf-core] DHCP can be used for IPv4 and IPv6 Address Allocation and Assignment as well as Service Discovery. There are two versions of DHCP, one for IPv4 [RFC2131] and one for IPv6 [RFC3315]. While both versions bear the same name and perform much the same purpose, the details of the protocol for IPv4 and IPv6 are sufficiently different that they can be considered separate protocols. Following are examples, where DHCP options have been used to provide configuration information or access to specific servers. o [RFC3646] describes two DHCPv6 options for passing a list of available DNS recursive name servers and a domain search list to a client. o [RFC2610] describes how 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 two 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 new options to discover the Broadcast and Multicast Service (BCMCS) controller in an IP network. Ersue Expires April 21, 2011 [Page 21] Internet-Draft IETF Management Framework October 2010 3.2. IPv6 Network Operations The IPv6 Operations Working Group (v6ops) 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. NOTE: Input planned from V6ops Workgroup 3.3. SNMP Agent Extensibility (AgentX) Protocol The Draft Standard [RFC2741] "Agent Extensibility (AgentX) Protocol" defines a framework for extensible SNMP agents including master agents and subagents, the AgentX protocol used to communicate between them, and how the extensible agent processes SNMP protocol messages. Within the SNMP framework, a managed node contains a processing entity called agent, which has access to management information. Within the AgentX framework, an agent is further defined to consist of: o a single processing entity called the master agent, which sends and receives SNMP protocol messages in an agent role (as specified by the SNMP framework documents) but typically has little or no direct access to management information, and o zero or more processing entities called subagents, which are "shielded" from the SNMP protocol messages processed by the master agent, but which have access to management information. The internal operations of AgentX are invisible to an SNMP entity operating in a manager role. From a manager's point of view, an extensible agent behaves exactly as would a non-extensible (monolithic) agent that has access to the same management instrumentation. [RFC2741] specifies furthermore a TCP binding for the AgentX protocol. The Draft Standard [RFC2742] "Definitions of Managed Objects for Extensible SNMP Agents" describes objects managing SNMP agents that use the AgentX Protocol and specifies a MIB module, which is compliant to the SMIv2, and semantically identical to the peer SMIv1 definitions. Ersue Expires April 21, 2011 [Page 22] Internet-Draft IETF Management Framework October 2010 3.4. Radius Radius [RFC2865], the remote Authentication Dial In User Service, is a Draft Standard that describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. This 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. NOTE: Need more text and discussion of Radius RFCs. 3.5. 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 Authentication, Authorization, Accounting situations and in roaming situations. Diameter is designed to resolve a number of known problems with RADIUS. Diameter supports server failover, transmission-level security, reliable transport over TCP, agents for proxy and redirect and relay, server-initiated messages, auditability, capability negotiation, peer discovery and configuration, and roaming support. Diameter also provides a larger attribute space 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. NOTE: Need more text and discussion of Diameter RFCs. 3.6. CAPWAP Wireless LAN 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. Based on the CAPWAP Architecture Taxonomy work [RFC4118] CAPWAP workgroup developed the CAPWAP protocol to facilitate control, management and provisioning of WLAN Termination Points (WTPs) Ersue Expires April 21, 2011 [Page 23] Internet-Draft IETF Management Framework October 2010 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 primitives to control data access. The protocol document also defines 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. CAPWAP protocol is defined 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 Base MIB [RFC5833] describes managed objects for modeling the CAPWAP Protocol and provides configuration and WTP status-monitoring aspects of CAPWAP, where CAPWAP Binding MIB [RFC5834] describes managed objects for modeling of CAPWAP protocol for IEEE 802.11 wireless binding. (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.) NOTE: More to add? 3.7. EPP The Extensible Provision Protocol [RFC5730] is an Internet Standard [STD69] that describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. EPP permits multiple service providers to perform object provisioning operations using a shared central object repository, and addresses the requirements for a generic registry registrar protocol. EPP is specified in XML and defines generic object management operations and an extensible framework that maps protocol operations to objects. EPP is a stateful XML protocol that can be layered over multiple transport protocols. Protected using lower-layer security protocols, clients exchange identification, authentication, and option information, and then engage in a series of client-initiated command-response exchanges. EPP has been adopted by numerous domain name registries mainly for the communication between domain name registries and domain name registrars and for allocating objects within registries over the Internet. Ersue Expires April 21, 2011 [Page 24] Internet-Draft IETF Management Framework October 2010 NOTE: Is EPP important for the management framework? 3.8. Access Node Control Protocol 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 (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 configurations and operations 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. Framework and Requirements for an Access Node Control Mechanism and the use cases for ANCP are documented in [RFC5851]. Security Threats and Security Requirements for ANCP are discussed in [RFC5713]. 3.9. Ad-Hoc Network Autoconfiguration (autoconf) 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. AUTOCONF WG 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 routing protocols as developed by the IETF MANET WG. 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.10. Policy-based Management 3.10.1. IETF Policy Framework IETF specified a general framework for managing, sharing, and reusing policies in a vendor independent, interoperable, and scalable manner as well as defining an extensible information model for representing policies. The policy framework is based on a policy-based admission control specifying the two main architectural elements the Policy Enforcement Point (PEP) and the Policy Decision Point (PDP). Ersue Expires April 21, 2011 [Page 25] Internet-Draft IETF Management Framework October 2010 For the purposes of network management, policies allow an operator to specify how the network is to be configured and monitored through 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 [RFC2753] has been accepted by the industry as a standard-based policy approach and has been adopted by different SDOs e.g. 3GGP charging standards. ADD: More to mention? 3.10.2. COPS-PR [RFC3159] defines the Structure of Policy Provisioning Information (SPPI), an extension to the SMI modeling language used to write Policy Information Base (PIB) modules. COPS-PR [RFC3084] uses the Common Open Policy Service (COPS) protocol for support of policy provisioning. COPS-PR and the Structure of Policy Provisioning Information (SPPI) have been approved as Proposed Standards. 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). COPS-PR does not make any assumptions about the policy data model being communicated, but describes the message formats and objects that carry the modeled policy data. Policy data is modeled using Policy Information Base modules (PIB modules). COPS-PR has not had wide deployment, and operators have stated that its use of binary encoding (BER) for management data makes it difficult to develop automated scripts for simple configuration management tasks in most text-based scripting languages. In an 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, the IESG has not approved any policy models (PIB modules) as IETF standard, and the use of COPS-PR is not recommended. 3.11. Network Performance Management 3.11.1. IP Performance Metrics (IPPM) The IPPM WG has defined metrics for accurately measuring and reporting the quality, performance, and reliability of Internet data delivery services. The metrics include connectivity, one-way delay Ersue Expires April 21, 2011 [Page 26] Internet-Draft IETF Management Framework October 2010 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 network operator use and provide unbiased quantitative measures of performance. The main properties of individual IPPM performance and reliability metrics are that the metrics should be well-defined and concrete thus implementable, and they should exhibit no bias for IP clouds implemented with identical technology. In addition, the methodology used to implement a metric should have the property of being repeatable with consistent measurements. IETF IP Performance Metrics have been introduced widely in the industry and adopted by different SDOs such as ITU-T. 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 WG 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 One-way Delay Metric for IPPM [RFC2679] defines a metric for one- way delay of packets across Internet paths. It builds on notions introduced in the IPPM Framework document. o Round-trip Delay Metric for IPPM [RFC2681] defines a metric for round-trip delay of packets across network paths and follows closely the corresponding metric for One-way Delay. o IP Packet Delay Variation Metric [RFC3393] 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 One-way Packet Loss Metric for IPPM [RFC2680] defines a metric for one-way packet loss across Internet paths. o One-Way Packet Duplication Metric [RFC5560] defines a metric for the case, where multiple copies of a packet are received and discusses methods to summarize the results of streams. Ersue Expires April 21, 2011 [Page 27] Internet-Draft IETF Management Framework October 2010 o Packet Reordering Metrics [RFC4737] 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 IPPM Metrics for Measuring Connectivity [RFC2678] defines a series of metrics for connectivity between a pair of Internet hosts. o Framework for Metric Composition [RFC5835] describes a detailed framework for composing and aggregating metrics. o A One-way Active Measurement Protocol (OWAMP) [RFC4656] measures unidirectional characteristics such as one-way delay and one-way loss between network devices and enables the interoperability of these measurements. o A Two-Way Active Measurement Protocol (TWAMP) [RFC5357] adds round-trip or two-way measurement capabilities to OWAMP. For the "Information Model and XML Data Model for Traceroute Measurements [RFC5388] and the BCP document [BCP108] "IP Performance Metrics (IPPM) Metrics Registry" see section 4.4 'Performance Management'. 3.11.2. Real-time Flow Measurement (RTFM) (Real-Time) Traffic Flow Measurement: Architecture [RFC2722] specifies the general framework for describing network traffic flows, an architecture for traffic flow measurement and reporting, and indicates how it can be used within the Internet. As such RTFM is a mechanism for configuring meters and meter readers, and for collecting the flow data from remote meters. RTFM is e.g. used for the measurement of DNS performance. NOTE: Is RTFM really important? ADD: Anything to add to Network Performance Management? 3.12. Application Management Protocols 3.12.1. ACAP The Application Configuration Access Protocol (ACAP) [RFC2244] is designed to support remote storage and 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- Ersue Expires April 21, 2011 [Page 28] Internet-Draft IETF Management Framework October 2010 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 users access to their configuration data from multiple network-connected computers. Users can then sit down in front of any network-connected computer, run any ACAP-enabled application and have access to their own configuration data. Because it is hoped that many applications will become ACAP- enabled, client simplicity was preferred to server or protocol simplicity whenever reasonable. 3.12.2. XCAP 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. XCAP is meant to support the configuration needs for a multiplicity of applications, rather than just a single one. XCAP was not designed as a general purpose XML search protocol, XML database update protocol, nor a general purpose, XML-based configuration protocol for network elements. 4. Proposed, Draft and Standard Level Data Models This section lists solutions for which information or data models have been standardized at the IETF, so that existing solutions can be reused and the data models can be applied to new solutions. Management data models have a slightly different interpretation for interoperability. This is discussed in detail in [BCP27] "Advancement of MIB specifications on the IETF Standards Track" [RFC2438] with special considerations about the advancement process for management data models. However most IETF management data models never advance beyond Proposed Standard. This section discusses management data models that have reached at Ersue Expires April 21, 2011 [Page 29] Internet-Draft IETF Management Framework October 2010 least Proposed Standard status in the IETF. 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 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 'Performance Management'). Proposed Standards: The IETF SYSLOG protocol [RFC5424] is a Proposed Standard that includes a mechanism for defining Structured Data Elements (SDEs). The SYSLOG protocol document defines an initial set of SDEs that relate to content time quality, content origin, and meta-information about the message, such as language. Proprietary SDEs can be used to supplement the IETF-defined SDEs. DISMAN-EVENT-MIB in [RFC2981] and DISMAN-EXPRESSION-MIB in [RFC2982] provide a superset of the capabilities of the RMON alarm and event groups. These modules provide mechanisms for thresholding and reporting anomalous events to management applications. The ALARM MIB in [RFC3877] and the Alarm Reporting Control MIB in [RFC3878] specify mechanisms for expressing state transition models for persistent problem states. ALARM MIB defines: - a mechanisms 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 X.733 [ITU- X733). Ersue Expires April 21, 2011 [Page 30] Internet-Draft IETF Management Framework October 2010 [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 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). 4.2. Configuration Management Draft standards: It is expected that standard XML-based data models will be developed for use with NETCONF, and working groups might identify specific NETCONF data models that would be applicable to the new protocol. Note: At the time of this writing, only the YANG module for the monitoring of the NETCONF protocol exists as proposed standard. NETMOD WG is going to be rechartered to develop core system models in YANG. 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, and so on. [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 caused potential discontinuity in counters. Other objects in the system MIB are useful for identifying the type of device, the location of the device, the person responsible for the device, etc. [RFC3413], part of STD 62 SNMPv3, includes objects designed for configuring notification destinations, and for configuring proxy- Ersue Expires April 21, 2011 [Page 31] Internet-Draft IETF Management Framework October 2010 forwarding SNMP agents, which can be used to forward messages through firewalls and 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 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. 4.3. Accounting Management DIAMETER [RFC3588] and RADIUS [RFC2866] can be used to exchange accounting related information. IETF so far did only develop Informational RFCs as data model for accounting. RADIUS Accounting Client MIB for IPv6 [RFC4670] and RADIUS Accounting Server MIB for IPv6 [RFC4671] allow the gathering of accounting data. 4.4. Performance Management MIB modules typically contain counters to determine the frequency and rate of an occurrence. RMON [RFC2819] has the full standard status [STD59] and defines objects for managing remote network monitoring devices. An organization may employ many remote management probes, one per network segment, to manage its internet. These devices may be used for a network management service provider to access a client network, Ersue Expires April 21, 2011 [Page 32] Internet-Draft IETF Management Framework October 2010 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 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. 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 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 Ersue Expires April 21, 2011 [Page 33] Internet-Draft IETF Management Framework October 2010 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. TODO: Check whether RFC3729 is widely deployed?? 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. IPPM WG 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. IPPM WG has furthermore defined the BCP document [BCP108] "IP Performance Metrics (IPPM) Metrics Registry", which defines a registry for IP Performance Metrics [RFC4148]. 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. SIP Package for Voice Quality Reporting [I-D.ietf-sipping-rtcp- Ersue Expires April 21, 2011 [Page 34] Internet-Draft IETF Management Framework October 2010 summary] 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 controlling an RTFM Traffic Meter, 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 Proposed standards: RADIUS Authentication Server MIB for IPv6 [RFC4669] defines a set of extensions that instrument RADIUS authentication server functions and RADIUS Authentication Client MIB for IPv6 [RFC4668] defines a set of extensions for RADIUS authentication client functions. Both RFCs add support for version-neutral IP address formats. Using these extensions, IP-based management stations can manage RADIUS authentication clients and servers. Informational RFCs: RADIUS Dynamic Authorization Client MIB [RFC4672] describes the Dynamic Authorization Client (DAC) functions that support the dynamic authorization extensions defined in [RFC5176]. RADIUS Dynamic Authorization Server MIB [RFC4673] describes the Dynamic Authorization Server (DAS) functions that support the dynamic authorization extensions defined in [RFC5176]. 5. IANA Considerations This document does not introduce any new codepoints or name spaces 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. 7. Contributors This document uses the expired draft [I-D.ietf-opsawg-survey- management] edited by Dave Harrington as a starting point. Ersue Expires April 21, 2011 [Page 35] Internet-Draft IETF Management Framework October 2010 8. Acknowledgements The authors would like to thank to ... 9. Informative References [I-D.baker-ietf-core] Baker, F. and D. Meyer, "Internet Protocols for the Smart Grid", draft-baker-ietf-core-08 (work in progress), September 2010. [I-D.ietf-ancp-protocol] Wadhwa, S., Moisand, J., Haag, T., Voigt, N., and T. Taylor, "Protocol for Access Node Control Mechanism in Broadband Networks", draft-ietf-ancp-protocol-12 (work in progress), August 2010. [I-D.ietf-ipfix-anon] Boschi, E. and B. Trammell, "IP Flow Anonymisation Support", draft-ietf-ipfix-anon-04 (work in progress), October 2010. [I-D.ietf-ipfix-configuration-model] Muenz, G., Claise, B., and P. Aitken, "Configuration Data Model for IPFIX and PSAMP", draft-ietf-ipfix- configuration-model-07 (work in progress), August 2010. [I-D.ietf-ipfix-export-per-sctp-stream] Claise, B., Aitken, P., Johnson, A., and G. Muenz, "IPFIX Export per SCTP Stream", draft-ietf-ipfix- export-per-sctp-stream-08 (work in progress), May 2010. [I-D.ietf-ipfix-mediators-framework] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, "IPFIX Mediation: Framework", draft-ietf- Ersue Expires April 21, 2011 [Page 36] Internet-Draft IETF Management Framework October 2010 ipfix-mediators-framework-08 (work in progress), August 2010. [I-D.ietf-ipfix-structured-data] Yates, S., "Export of Structured Data in IPFIX", d raft-ietf-ipfix-structured- data-03 (work in progress), October 2010. [I-D.ietf-isms-radius-vacm] 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", dra ft-ietf-isms-radius-vacm-11 (work in progress), September 2010. [I-D.ietf-mpls-tp-oam-framework] Allan, D., Busi, I., Niven- Jenkins, B., Fulignoli, A., Hernandez-Valencia, E., Levrau, L., Sestito, V., Sprecher, N., Helvoort, H., Vigoureux, M., Weingarten, Y., and R. Winter, "Operations, Administration and Maintenance Framework for MPLS- based Transport Networks", draft-ietf-mpls- tp-oam-framework-09 (work in progress), October 2010. [I-D.ietf-netmod-dsdl-map] Lhotka, L., "Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content", draft- ietf-netmod-dsdl-map-08 (work in progress), September 2010. [I-D.ietf-netmod-yang-usage] Bierman, A., "Guidelines for Authors and Reviewers of YANG Data Model Documents", draft-ietf-netmod-yang- Ersue Expires April 21, 2011 [Page 37] Internet-Draft IETF Management Framework October 2010 usage-11 (work in progress), October 2010. [I-D.ietf-opsawg-oam-overview] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, "An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms", draft-ietf- opsawg-oam-overview-02 (work in progress), October 2010. [I-D.ietf-opsawg-survey-management] Harrington, D., "Survey of IETF Network Management Standards", draft-ietf- opsawg-survey-management-00 (work in progress), March 2009. [I-D.ietf-sipping-rtcp-summary] Pendleton, A., Clark, A., Johnston, A., and H. Sinnreich, "Session Initiation Protocol Event Package for Voice Quality Reporting", draft-ietf- sipping-rtcp-summary-13 (work in progress), August 2010. [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985. [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community- based SNMPv2", RFC 1901, January 1996. [RFC2026] Bradner, S., "The Internet Standards Process -- Ersue Expires April 21, 2011 [Page 38] Internet-Draft IETF Management Framework October 2010 Revision 3", BCP 9, RFC 2026, October 1996. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 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. [RFC2613] Waterman, R., Lahaye, B., Romascanu, D., and S. Waldbusser, "Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0", RFC 2613, 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, Ersue Expires April 21, 2011 [Page 39] Internet-Draft IETF Management Framework October 2010 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. [RFC2741] Daniele, M., Wijnen, B., Ellison, M., and D. Francisco, "Agent Extensibility (AgentX) Protocol Version 1", RFC 2741, January 2000. [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 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, Ersue Expires April 21, 2011 [Page 40] Internet-Draft IETF Management Framework October 2010 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. [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. [RFC3165] Levi, D. and J. Schoenwaelder, "Definitions of Managed Objects for the Delegation of Management Scripts", RFC 3165, August 2001. [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. Ersue Expires April 21, 2011 [Page 41] Internet-Draft IETF Management Framework October 2010 [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 Expires April 21, 2011 [Page 42] Internet-Draft IETF Management Framework October 2010 December 2002. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 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. [RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network Management Workshop", RFC 3535, May 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 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. [RFC3729] Waldbusser, S., "Application Performance Measurement MIB", RFC 3729, March 2004. [RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management Information Base (MIB)", Ersue Expires April 21, 2011 [Page 43] Internet-Draft IETF Management Framework October 2010 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. [RFC4011] Waldbusser, S., Saperia, J., and T. Hongal, "Policy Based Management MIB", RFC 4011, March 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. [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", Ersue Expires April 21, 2011 [Page 44] Internet-Draft IETF Management Framework October 2010 RFC 4268, November 2005. [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. Ersue Expires April 21, 2011 [Page 45] Internet-Draft IETF Management Framework October 2010 [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. [RFC4710] Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real- time Application Quality-of- Service Monitoring (RAQMON) Framework", RFC 4710, October 2006. [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. [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. [RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Ersue Expires April 21, 2011 [Page 46] Internet-Draft IETF Management Framework October 2010 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. [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007. [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. [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 Ersue Expires April 21, 2011 [Page 47] Internet-Draft IETF Management Framework October 2010 Measurement Protocol (TWAMP)", RFC 5357, October 2008. [RFC5381] Iijima, T., Atarashi, Y., Kimura, H., Kitani, M., and H. Okita, "Experience of Implementing NETCONF over SOAP", RFC 5381, 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. [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. [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Ersue Expires April 21, 2011 [Page 48] Internet-Draft IETF Management Framework October 2010 Model for Packet Sampling Exports", RFC 5477, March 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. [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. [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. [RFC5674] Chisholm, S. and R. Gerhards, "Alarms in Syslog", RFC 5674, October 2009. [RFC5675] Marinov, V. and J. Schoenwaelder, "Mapping Ersue Expires April 21, 2011 [Page 49] Internet-Draft IETF Management Framework October 2010 Simple Network Management Protocol (SNMP) Notifications to 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. [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 Ersue Expires April 21, 2011 [Page 50] Internet-Draft IETF Management Framework October 2010 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. [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. [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 Expires April 21, 2011 [Page 51] Internet-Draft IETF Management Framework October 2010 Appendix A. New Work related to IETF Management Framework A.1. Energy Management (eman) Energy management (eman) is a new workgroup at IETF and will develop an energy management framework and standard track MIB documents, which are potentially relevant for the Smart Grid environment. Energy management is already an additional requirement for network management systems due to several factors including the rising energy costs, the increased awareness of the ecological impact of operating networks and devices, and the regulation of governments. 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. There are very few IETF documents on energy management discussing the areas of power monitoring, energy monitoring, and power state control. IETF started working on MIB modules for monitoring energy consumption and power states of energy-aware devices. However, it has been found that a new framework for energy management is necessary to address known issues sufficiently. A concrete issue, which needs to be addressed, is the differentiation between devices reporting energy consumption and remote devices for which monitoring information is provided. One usage scenario is 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 a wireless building network. The EMAN workgroup will work on the management of energy-aware devices covering following standard track WG items: Energy-aware Networks and Devices MIB document: Focus on monitoring energy-aware networks and devices addressing device identification, context information, and potential relationship between reporting devices, remote devices, and monitoring probes. Power and Energy Monitoring MIB document: Managed objects for monitoring of power states and energy consumption/production including retrieving of power states, properties of power states, current power state, power state transitions, and power state statistics. Ersue Expires April 21, 2011 [Page 52] Internet-Draft IETF Management Framework October 2010 Battery MIB document: Managed objects for battery monitoring, which will provide means for reporting detailed properties of the actual charge, age, and state of a battery and of battery statistics. The WG will furthermore provide following RFCs as a guidance for the development of standard track documents: Requirements for energy management: Specification of energy management properties that will allow networks and devices to become energy aware. Energy management framework: Extensions to current management framework required for energy management of IP-based network equipment including power and energy monitoring, power states, power state control, and potential power state transitions. Applicability statement: Description of applications that can use the energy framework and associated MIB modules and the discussion of relationships of the framework to other frameworks like Smart Grid and existing standards such as those from the IEC, ANSI, DMTF, and others. NOTE: This is mainly based on eman charter text. It would be interesting if an eman expert edits the text and adds use cases. Appendix B. Open issues o Some chapters (e.g. Radius, Diameter) are a bit bare and need a discussion of standard documents in this area. o Usage scenarios need to be added and discussed for different RFCs. o Co-existence and inter-operation of SNMP and NETCONF e.g. for joint monitoring via the same manager needs to be discussed. o Is Experimental RFC3179 "Script MIB Extensibility Protocol Version 1.1" worth to discuss? o Relevance to Smart Grid environment needs to be discussed in an appendix. o An appendix is needed to discuss management in Smart Grid environment with a hierarchical architecture with different proxy entities with possible involvement of SNMP master-agent and sub- agent. Ersue Expires April 21, 2011 [Page 53] Internet-Draft IETF Management Framework October 2010 o Management of constrained devices needs a discussion. New work is available e.g. for optimized SNMP in 6LowPAN environment (draft-hamid-6lowpan-snmp-optimizations-02.txt). o Discuss the potential gap for an optimized NETCONF for constrained devices. Author's Address Mehmet Ersue Nokia Siemens Networks St.-Martin-Strasse 53 Munich 81541 Germany EMail: mehmet.ersue@nsn.com Ersue Expires April 21, 2011 [Page 54]