idnits 2.17.1 draft-ietf-opsawg-management-stds-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 19, 2012) is 4419 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-dime-rfc3588bis-31 == Outdated reference: A later version (-06) exists of draft-ietf-ipfix-psamp-mib-04 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-tp-mib-management-overview-07 == Outdated reference: A later version (-16) exists of draft-ietf-opsawg-oam-overview-06 -- Obsolete informational reference (is this intentional?): RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 2679 (Obsoleted by RFC 7679) -- Obsolete informational reference (is this intentional?): RFC 2680 (Obsoleted by RFC 7680) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 3164 (Obsoleted by RFC 5424) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) -- Obsolete informational reference (is this intentional?): RFC 4006 (Obsoleted by RFC 8506) -- Obsolete informational reference (is this intentional?): RFC 4133 (Obsoleted by RFC 6933) -- Obsolete informational reference (is this intentional?): RFC 4148 (Obsoleted by RFC 6248) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5101 (Obsoleted by RFC 7011) -- Obsolete informational reference (is this intentional?): RFC 5102 (Obsoleted by RFC 7012) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5539 (Obsoleted by RFC 7589) -- Obsolete informational reference (is this intentional?): RFC 5719 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 5815 (Obsoleted by RFC 6615) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) -- Obsolete informational reference (is this intentional?): RFC 6021 (Obsoleted by RFC 6991) -- Obsolete informational reference (is this intentional?): RFC 6087 (Obsoleted by RFC 8407) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 25 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Ersue, Ed. 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Informational B. Claise 5 Expires: September 20, 2012 Cisco Systems, Inc. 6 March 19, 2012 8 An Overview of the IETF Network Management Standards 9 draft-ietf-opsawg-management-stds-07 11 Abstract 13 This document gives an overview of the IETF network management 14 standards and summarizes existing and ongoing development of IETF 15 standards-track network management protocols and data models. The 16 document refers to other overview documents, where they exist and 17 classifies the standards for easy orientation. The purpose of this 18 document is on the one hand to help system developers and users to 19 select appropriate standard management protocols and data models to 20 address relevant management needs. On the other hand, the document 21 can be used as an overview and guideline by other Standard 22 Development Organizations or bodies planning to use IETF management 23 technologies and data models. This document does not cover OAM 24 technologies on the data-path, e.g. OAM of tunnels, MPLS-TP OAM, and 25 Pseudowire as well as the corresponding management models. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 20, 2012. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.1. Scope and Target Audience . . . . . . . . . . . . . . . . 4 63 1.2. Related Work . . . . . . . . . . . . . . . . . . . . . . 5 64 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 65 2. Core Network Management Protocols . . . . . . . . . . . . . . 8 66 2.1. Simple Network Management Protocol (SNMP) . . . . . . . . 8 67 2.1.1. Architectural Principles of SNMP . . . . . . . . . . 8 68 2.1.2. SNMP and its Versions . . . . . . . . . . . . . . . . 9 69 2.1.3. Structure of Managed Information (SMI) . . . . . . . 11 70 2.1.4. SNMP Security and Access Control Models . . . . . . . 12 71 2.1.5. SNMP Transport Subsystem and Transport Models . . . . 13 72 2.2. SYSLOG Protocol . . . . . . . . . . . . . . . . . . . . . 15 73 2.3. IP Flow Information Export (IPFIX) and Packet Sampling 74 (PSAMP) Protocols . . . . . . . . . . . . . . . . . . . . 16 75 2.4. Network Configuration . . . . . . . . . . . . . . . . . . 19 76 2.4.1. Network Configuration Protocol (NETCONF) . . . . . . 19 77 2.4.2. YANG - NETCONF Data Modeling Language . . . . . . . . 21 78 3. Network Management Protocols and Mechanisms with specific 79 Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 80 3.1. IP Address Management . . . . . . . . . . . . . . . . . . 23 81 3.1.1. Dynamic Host Configuration Protocol (DHCP) . . . . . 23 82 3.1.2. Ad-Hoc Network Autoconfiguration . . . . . . . . . . 24 83 3.2. IPv6 Network Operations . . . . . . . . . . . . . . . . . 24 84 3.3. Policy-based Management . . . . . . . . . . . . . . . . . 25 85 3.3.1. IETF Policy Framework . . . . . . . . . . . . . . . . 25 86 3.3.2. Use of Common Open Policy Service (COPS) for 87 Policy Provisioning (COPS-PR) . . . . . . . . . . . . 26 88 3.4. IP Performance Metrics (IPPM) . . . . . . . . . . . . . . 27 89 3.5. Remote Authentication Dial In User Service (RADIUS) . . . 29 90 3.6. Diameter Base Protocol (DIAMETER) . . . . . . . . . . . . 31 91 3.7. Control And Provisioning of Wireless Access Points 92 (CAPWAP) . . . . . . . . . . . . . . . . . . . . . . . . 34 93 3.8. Access Node Control Protocol (ANCP) . . . . . . . . . . . 35 94 3.9. Application Configuration Access Protocol (ACAP) . . . . 36 95 3.10. XML Configuration Access Protocol (XCAP) . . . . . . . . 36 96 4. Network Management Data Models . . . . . . . . . . . . . . . 37 97 4.1. IETF Network Management Data Models . . . . . . . . . . . 38 98 4.1.1. Generic Infrastructure Data Models . . . . . . . . . 39 99 4.1.2. Link Layer Data Models . . . . . . . . . . . . . . . 39 100 4.1.3. Network Layer Data Models . . . . . . . . . . . . . . 39 101 4.1.4. Transport Layer Data Models . . . . . . . . . . . . . 40 102 4.1.5. Application Layer Data Models . . . . . . . . . . . . 40 103 4.1.6. Network Management Infrastructure Data Models . . . . 40 104 4.2. Network Management Data Models - FCAPS View . . . . . . . 41 105 4.2.1. Fault Management . . . . . . . . . . . . . . . . . . 41 106 4.2.2. Configuration Management . . . . . . . . . . . . . . 43 107 4.2.3. Accounting Management . . . . . . . . . . . . . . . . 44 108 4.2.4. Performance Management . . . . . . . . . . . . . . . 45 109 4.2.5. Security Management . . . . . . . . . . . . . . . . . 47 110 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 111 6. Security Considerations . . . . . . . . . . . . . . . . . . . 49 112 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51 113 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 114 9. Informative References . . . . . . . . . . . . . . . . . . . 52 115 Appendix A. High Level Classification of Management Protocols 116 and Data Models . . . . . . . . . . . . . . . . . . 90 117 A.1. Protocols classified by the Standard Maturity at IETF . . 91 118 A.2. Protocols Matched to Management Tasks . . . . . . . . . . 92 119 A.3. Push versus Pull Mechanism . . . . . . . . . . . . . . . 93 120 A.4. Passive versus Active Monitoring . . . . . . . . . . . . 93 121 A.5. Supported Data Model Types and their Extensibility . . . 94 122 Appendix B. New Work related to IETF Management Standards . . . 96 123 B.1. Energy Management (EMAN) . . . . . . . . . . . . . . . . 96 124 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 98 125 C.1. 06-07 . . . . . . . . . . . . . . . . . . . . . . . . . . 98 126 C.2. 05-06 . . . . . . . . . . . . . . . . . . . . . . . . . . 98 127 C.3. 04-05 . . . . . . . . . . . . . . . . . . . . . . . . . . 98 128 C.4. 03-04 . . . . . . . . . . . . . . . . . . . . . . . . . . 98 129 C.5. 02-03 . . . . . . . . . . . . . . . . . . . . . . . . . . 99 130 C.6. 01-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 99 131 C.7. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 99 132 C.8. draft-ersue-opsawg-management-fw-03-00 . . . . . . . . . 100 133 C.9. Change Log from draft-ersue-opsawg-management-fw . . . . 101 134 C.9.1. 02-03 . . . . . . . . . . . . . . . . . . . . . . . . 101 135 C.9.2. 01-02 . . . . . . . . . . . . . . . . . . . . . . . . 101 136 C.9.3. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . 101 138 1. Introduction 140 1.1. Scope and Target Audience 142 This document gives an overview of the IETF network management 143 standards and summarizes existing and ongoing development of IETF 144 standards-track network management protocols and data models. The 145 document refers to other overview documents where they exist and 146 classifies the standards for easy orientation. 148 The target audience of the document is on the one hand IETF working 149 groups, which aim to select appropriate standard management protocols 150 and data models to address their needs concerning network management. 151 On the other hand the document can be used as an overview and 152 guideline by non-IETF Standard Development Organizations (SDO) 153 planning to use IETF management technologies and data models for the 154 realization of management applications. The document can be also 155 used to initiate a discussion between the bodies with the goal to 156 gather new requirements and to detect possible gaps. Finally, this 157 document is directed to all interested parties, which seek to get an 158 overview of the current set of the IETF network management protocols 159 such as network administrators or newcomers to IETF. 161 Section 2 gives an overview of the IETF core network management 162 standards with a special focus on Simple Network Management Protocol 163 (SNMP), SYSLOG, IP Flow Information Export/Packet Sampling (IPFIX/ 164 PSAMP), and Network Configuration (NETCONF). Section 3 discusses 165 IETF management protocols and mechanisms with a specific focus, e.g. 166 IP address management or IP performance management. Section 4 167 discusses IETF data models, such as MIB modules, IPFIX Information 168 Elements, SYSLOG Structured Data Elements, and YANG modules designed 169 to address specific set of management issues and provides two 170 complementary overviews for the network management data models 171 standardized at IETF. Section 4.1 focuses on a broader view of 172 models classified into categories such as generic and infrastructure 173 data models as well as data models matched to different layers. 174 Where section 4.2 structures the data models following the management 175 application view and maps them to the network management tasks fault, 176 configuration, accounting, performance, and security management. 178 Appendix A guides the reader for the high-level selection of 179 management standards. For this, the section classifies the protocols 180 according to high-level criteria such as push versus pull mechanism, 181 passive versus active monitoring, as well as categorizes the 182 protocols concerning the network management task they address and 183 their data model extensibility. If the reader is interested only in 184 a subset of the IETF network management protocols and data models 185 described in this document, Appendix A can be used as a dispatcher to 186 the corresponding chapter. Appendix B gives an overview of the new 187 work on Energy Management at IETF. 189 This document mainly refers to Proposed, Draft or Internet Standard 190 documents at IETF (see [RFCSEARCH]). As far as valuable Best Current 191 Practice (BCP) documents are referenced. In exceptional cases and if 192 the document provides substantial guideline for standard usage or 193 fills an essential gap, Experimental and Informational RFCs are 194 noticed and ongoing work is mentioned. 196 Information on active and concluded IETF working groups (e.g., their 197 charters, published or currently active documents and mail archive) 198 can be found at [IETF-WGS]). 200 Note that this document does not cover OAM technologies on the data- 201 path including MPLS forwarding plane, and control plane protocols 202 (e.g. OAM of tunnels, MPLS-TP OAM, and Pseudowire) as well as the 203 corresponding management models and MIB modules. For a list of 204 related work see Section 1.2 "Related Work". 206 1.2. Related Work 208 [RFC6272] "Internet Protocols for the Smart Grid" gives an overview 209 and guidance on the key protocols of the Internet Protocol Suite. In 210 analogy to [RFC6272] this document gives an overview of the IETF 211 network management standards and its usage scenarios. 213 [RFC3535] "Overview of the 2002 IAB Network Management Workshop" 214 documented strengths and weaknesses of some IETF management 215 protocols. In choosing existing protocol solutions to meet the 216 management requirements, it is recommended that these strengths and 217 weaknesses be considered, even though some of the recommendations 218 from the 2002 IAB workshop have become outdated, some have been 219 standardized, and some are being worked on at the IETF. 221 [RFC5706] "Guidelines for Considering Operations and Management of 222 New Protocols and Extensions" recommends working groups to consider 223 operations and management needs, and then select appropriate 224 management protocols and data models. This document can be used to 225 ease surveying the IETF standards-track network management protocols 226 and management data models. 228 [RFC4221] "Multiprotocol Label Switching (MPLS) Management Overview" 229 describes the management architecture for MPLS and indicates the 230 interrelationships between the different MIB modules used for MPLS 231 network management, where [RFC6371] "Operations, Administration, and 232 Maintenance Framework for MPLS-Based Transport Networks" describes 233 the OAM Framework for MPLS-based Transport Networks. 235 [I-D.ietf-mpls-tp-oam-analysis] "An Overview of the OAM Tool Set for 236 MPLS-based Transport Networks" provides an overview of the OAM 237 toolset for MPLS-based Transport Networks including a brief summary 238 of MPLS-TP OAM requirements and functions, and of generic mechanisms 239 created in the MPLS data plane to allow the OAM packets run in-band 240 and share their fate with data packets. The protocol definitions for 241 each MPLS-TP OAM tools are defined in separate documents, which are 242 referenced. 244 [I-D.ietf-opsawg-oam-overview] "An Overview of Operations, 245 Administration, and Maintenance (OAM) Mechanisms" gives an overview 246 of the OAM toolset for detecting and reporting connection failures or 247 measurement of connection performance parameters. 249 [I-D.ietf-mpls-tp-mib-management-overview] "MPLS-TP MIB-based 250 Management Overview" describes the MIB-based architecture for 251 MPLS-TP, and indicates the interrelationships between different 252 existing MIB modules that can be leveraged for MPLS-TP network 253 management and identifies areas where additional MIB modules are 254 required. 256 Note that IETF so far has not developed specific technologies for the 257 management of sensor networks. IP-based sensors or constrained 258 devices in such an environment, i.e. with very limited memory and CPU 259 resources, can use e.g. application layer protocols to do simple 260 resource management and monitoring. 262 1.3. Terminology 264 This document does not describe standard requirements. Therefore, 265 key words from RFC2119 are not used in the document. 267 o 3GPP: 3rd Generation Partnership Project, a collaboration between 268 groups of telecommunications associations, to prepare the third- 269 generation (3G) mobile phone system specification. 271 o Agent: A software module that performs the network management 272 functions requested by network management stations. An agent may 273 be implemented in any network element that is to be managed, such 274 as a host, bridge, or router. The 'management server' in NETCONF 275 terminology. 277 o BCP: An IETF Best Current Practice document. 279 o CLI: Command Line Interface. A management interface that system 280 administrators can use to interact with networking equipment. 282 o Data model: A mapping of the contents of an information model into 283 a form that is specific to a particular type of data store or 284 repository (see [RFC3444]). 286 o Event: An occurrence of something in the "real world". Events can 287 be indicated to managers through an event message or notification. 289 o IAB: Internet Architecture Board 291 o IANA: Internet Assigned Numbers Authority, an organization that 292 oversees global IP address allocation, autonomous system number 293 allocation, media types, and other Internet Protocol-related code 294 point allocations. 296 o Information model: An abstraction and representation of entities 297 in a managed environment, their properties, attributes and 298 operations, and the way they relate to each other. Independent of 299 any specific repository, protocol, or platform (see [RFC3444]). 301 o ITU-T: International Telecommunication Union - Telecommunication 302 Standardization Sector 304 o Managed object: A management abstraction of a resource; a piece of 305 management information in a MIB module. In the context of SNMP, a 306 structured set of data variables that represent some resource to 307 be managed or other aspect of a managed device. 309 o Manager: An entity that acts in a manager role, either a user or 310 an application. The counterpart to an agent. A 'management 311 client' in NETCONF terminology. 313 o Management Information Base (MIB): An information repository with 314 a collection of related objects that represent the resources to be 315 managed. 317 o MIB module: MIB modules usually contain object definitions, may 318 contain definitions of event notifications, and sometimes include 319 compliance statements in terms of appropriate object and event 320 notification groups. A MIB that is provided by a management agent 321 is typically composed of multiple instantiated MIB modules. 323 o Modeling language: A modeling language is any artificial language 324 that can be used to express information or knowledge or systems in 325 a structure that is defined by a consistent set of rules. 326 Examples are SMIv2 [STD58], XSD [XSD-1], and YANG [RFC6020]. 328 o Notification: An unsolicited message sent by an agent to a 329 management station to notify an unusual event. 331 o OAM: Operations, Administration, and Maintenance 333 o PDU: Protocol Data Unit, a unit of data, which is specified in a 334 protocol of a given layer consisting protocol-control information 335 and possibly layer-specific data. 337 o Principal: An application, an individual, or a set of individuals 338 acting in a particular role, on whose behalf access to a service 339 or MIB is allowed. 341 o Relax NG: REgular LAnguage for XML Next Generation, a schema 342 language for XML [RELAX-NG]. 344 o SDO: Standard Development Organization 346 o SMI: Structure of Managed Information, the notation and grammar 347 for managed information definition used to define MIB modules 348 [STD58]. 350 o STDnn: An Internet Standard published at IETF, also referred as 351 Standard, e.g. [STD62]. 353 o URI: Uniform Resource Identifier, a string of characters used to 354 identify a name or a resource on the Internet [STD66]. Can be 355 classified as locators (URLs), or as names (URNs), or as both. 357 o XPATH: XML Path Language, a query language for selecting nodes 358 from an XML document [XPATH]. 360 2. Core Network Management Protocols 362 2.1. Simple Network Management Protocol (SNMP) 364 2.1.1. Architectural Principles of SNMP 366 The SNMPv3 Framework [RFC3410], builds upon both the original SNMPv1 367 and SNMPv2 framework. The basic structure and components for the 368 SNMP framework did not change between its versions and comprises 369 following components: 371 o managed nodes, each with an SNMP entity providing remote access to 372 management instrumentation (the agent), 374 o at least one SNMP entity with management applications (the 375 manager), and 377 o a management protocol used to convey management information 378 between the SNMP entities, and management information. 380 During its evolution, the fundamental architecture of the SNMP 381 Management Framework remained consistent based on a modular 382 architecture, which consists of: 384 o a generic protocol definition independent of the data it is 385 carrying, and 387 o a protocol-independent data definition language, 389 o an information repository containing a data set of management 390 information definitions (the Management Information Base, or MIB), 391 and 393 o security and administration. 395 As such following standards build up the basis of the current SNMP 396 Management Framework: 398 o SNMPv3 protocol [STD62], 400 o the modeling language SMIv2 [STD58], and 402 o MIB modules for different management issues. 404 The SNMPv3 Framework extends the architectural principles of SNMPv1 405 and SNMPv2 by: 407 o building on these three basic architectural components, in some 408 cases incorporating them from the SNMPv2 Framework by reference, 409 and 411 o by using the same layering principles in the definition of new 412 capabilities in the security and administration portion of the 413 architecture. 415 2.1.2. SNMP and its Versions 417 SNMP is based on three conceptual entities: Manager, Agent, and the 418 Management Information Base (MIB). In any configuration, at least 419 one manager node runs SNMP management software. Typically, network 420 devices such as bridges, routers, and servers are equipped with an 421 agent. The agent is responsible for providing access to a local MIB 422 of objects that reflects the resources and activity at its node. 423 Following the manager-agent paradigm, an agent can generate 424 notifications and send them as unsolicited messages to the management 425 application. 427 SNMPv2 enhances this basic functionality with an Inform PDU, a bulk 428 transfer capability and other functional extensions like an 429 administrative model for access control, security extensions, and 430 Manager-to-Manager communication. SNMPv2 entities can have a dual 431 role as manager and agent. However, neither SNMPv1 nor SNMPv2 offers 432 sufficient security features. To address the security deficiencies 433 of SNMPv1/v2, SNMPv3 [STD62] has been issued. 435 [BCP74] "Coexistence between Version 1, Version 2, and Version 3 of 436 the Internet-standard Network Management Framework" gives an overview 437 of the relevant standard documents on the three SNMP versions. The 438 BCP document furthermore describes how to convert MIB modules from 439 SMIv1 to SMIv2 format and how to translate notification parameters as 440 well as describes the mapping between the message processing and 441 security models. 443 SNMP utilizes the Management Information Base, a virtual information 444 store of modules of managed objects. Generally, standard MIB modules 445 support common functionality in a device. Operators often define 446 additional MIB modules for their enterprise or use the Command Line 447 Interface (CLI) to configure non-standard data in managed devices and 448 their interfaces. 450 SNMPv2 trap and inform PDUs can alert an operator or an application 451 when some aspect of a protocol fails or encounters an error 452 condition, and the contents of a notification can be used to guide 453 subsequent SNMP polling to gather additional information about an 454 event. 456 SNMP is widely used for monitoring of fault and performance data and 457 with its stateless nature, SNMP also works well for status polling 458 and determining the operational state of specific functionality. The 459 widespread use of counters in standard MIB modules permits the 460 interoperable comparison of statistics across devices from different 461 vendors. Counters have been especially useful in monitoring bytes 462 and packets going in and out over various protocol interfaces. SNMP 463 is often used to poll basic parameter of a device (e.g. sysUpTime, 464 which reports the time since the last re-initialization of the 465 network management portion of the device) to check for operational 466 liveliness, and to detect discontinuities in counters. Some 467 operators use SNMP also for configuration management in their 468 environment (e.g. for DOCSIS-based systems such as cable modems). 470 SNMPv1 [RFC1157] has been declared Historic and it is not recommended 471 to use due to its lack of security features. [RFC1901] "Community- 472 based SNMPv2" is an Experimental RFC, which has been declared 473 Historic and it is not recommended to use due to its lack of security 474 features. 476 SNMPv3 [STD62] is recommended to use due to its security features, 477 including support for authentication, encryption, message timeliness 478 and integrity checking, and fine-grained data access controls. An 479 overview of the SNMPv3 document set is in [RFC3410]. 481 Standards exist to use SNMP over diverse transport and link layer 482 protocols, including Transmission Control Protocol (TCP) [STD7], User 483 Datagram Protocol (UDP) [STD6], Ethernet [RFC4789], and others (see 484 Section 2.1.5.1). 486 2.1.3. Structure of Managed Information (SMI) 488 SNMP MIB modules are defined with the notation and grammar specified 489 as the Structure of Managed Information (SMI). The SMI uses an 490 adapted subset of Abstract Syntax Notation One (ASN.1) [ITU-X680]. 492 The SMI is divided into three parts: module definitions, object 493 definitions, and, notification definitions. 495 o Module definitions are used when describing information modules. 496 An ASN.1 macro, MODULE-IDENTITY, is used to concisely convey the 497 semantics of an information module. 499 o Object definitions are used when describing managed objects. An 500 ASN.1 macro, OBJECT-TYPE, is used to concisely convey the syntax 501 and semantics of a managed object. 503 o Notification definitions are used when describing unsolicited 504 transmissions of management information. An ASN.1 macro, 505 NOTIFICATION-TYPE, is used to concisely convey the syntax and 506 semantics of a notification. 508 SMIv1 is specified in [STD16][RFC1155] "Structure and Identification 509 of Management Information for TCP/IP-based Internets" and 510 [STD16][RFC1212] "Concise MIB Definitions". [RFC1215] specifies 511 conventions for defining SNMP traps. Note that SMIv1 is outdated and 512 is not recommended to use. 514 SMIv2 is the new notation for managed information definition and 515 should be used to define MIB modules. SMIv2 is specified in 516 following RFCs: 518 o [RFC2578], part of [STD58], defines Version 2 of the Structure of 519 Management Information (SMIv2), 521 o [RFC2579], part of [STD58], defines the "Textual Conventions" 522 macro for defining new types and it provides a core set of 523 generally useful "Textual Convention" definitions, 525 o [RFC2580], part of [STD58], defines Conformance Statements and 526 requirements for defining agent and manager capabilities, and 528 o [BCP74] defines the mapping rules for and the conversion of MIB 529 modules between SMIv1 and SMIv2 formats. 531 2.1.4. SNMP Security and Access Control Models 533 2.1.4.1. Security Requirements on the SNMP Management Framework 535 Several of the classical threats to network protocols are applicable 536 to management problem space and therefore applicable to any security 537 model used in an SNMP Management Framework. This section lists 538 primary and secondary threats, and threats which are of lesser 539 importance (see [RFC3411] for the detailed description of the 540 security threats). 542 The primary threats against which SNMP Security Models can provide 543 protection are, "modification of information" by an unauthorized 544 entity, and "masquerade", i.e. the danger that management operations 545 not authorized for some principal may be attempted by assuming the 546 identity of another principal. 548 Secondary threats against which SNMP Security Models can provide 549 protection are "message stream modification", e.g. re-ordering, 550 delay, or replay of messages, and "disclosure", i.e. the danger of 551 eavesdropping on the exchanges between SNMP engines. 553 There are two threats against which SNMP Security Model does not 554 protect, since they are deemed to be of lesser importance in this 555 context: "Denial of Service" and "Traffic Analysis" (see [RFC3411]). 557 2.1.4.2. User-Based Security Model (USM) 559 SNMPv3 [STD62] introduced the User Security Model (USM). USM is 560 specified in [RFC3414] and provides authentication and privacy 561 services for SNMP. Specifically, USM is designed to secure against 562 the primary and secondary threats discussed in Section 2.1.4.1. USM 563 does not secure against Denial of Service and attacks based on 564 Traffic Analysis. 566 The security services the USM security model supports are: 568 o Data Integrity is the provision of the property that data has not 569 been altered or destroyed in an unauthorized manner, nor have data 570 sequences been altered to an extent greater than can occur non- 571 maliciously. 573 o Data Origin Authentication is the provision of the property that 574 the claimed identity of the user on whose behalf received data was 575 originated is supported. 577 o Data Confidentiality is the provision of the property that 578 information is not made available or disclosed to unauthorized 579 individuals, entities, or processes. 581 o Message timeliness and limited replay protection is the provision 582 of the property that a message whose generation time is outside of 583 a specified time window is not accepted. 585 See [RFC3414] for a detailed description of SNMPv3 USM. 587 2.1.4.3. View-Based Access Control Model (VACM) 589 SNMPv3 [STD62] introduced the View-Based Access Control (VACM) 590 facility. The VACM is defined in [RFC3415] and enables the 591 configuration of agents to provide different levels of access to the 592 agent's MIB. An agent entity can restrict access to a certain 593 portion of its MIB, e.g. restrict some principals to view only 594 performance-related statistics, or disallow other principals to read 595 those performance-related statistics. An agent entity can also 596 restrict the access to monitoring (read-only) as opposed to 597 monitoring and configuration (read-write) of a certain portion of its 598 MIB, e.g. allowing only a single designated principal to update 599 configuration parameters. 601 VACM defines five elements that make up the Access Control Model: 602 groups, security level, contexts, MIB views, and access policy. 603 Access to a MIB module is controlled by means of a MIB view. 605 See [RFC3415] for a detailed description of SNMPv3 VACM. 607 2.1.5. SNMP Transport Subsystem and Transport Models 609 The User-based Security Model (USM) was designed to be independent of 610 other existing security infrastructures to ensure it could function 611 when third-party authentication services were not available. As a 612 result, USM utilizes a separate user and key-management 613 infrastructure. Operators have reported that the deployment of a 614 separate user and key-management infrastructure in order to use 615 SNMPv3 is costly and hinders the deployment of SNMPv3. 617 SNMP Transport Subsystem [RFC5590] extends the original SNMP 618 architecture and transport model and enables the use of transport 619 protocols to provide message security unifying the administrative 620 security management for SNMP, and other management interfaces. 622 Transport Models are tied into the SNMP framework through the 623 Transport Subsystem. The Transport Security Model [RFC5591] has been 624 designed to work on top of lower-layer, secure Transport Models. 626 The SNMP Transport Model defines an alternative to existing standard 627 transport mappings described in [RFC3417] e.g. for SNMP over UDP, in 628 [RFC4789] for SNMP over IEEE 802 networks as well as in the 629 Experimental RFC [RFC3430] defining SNMP over TCP. 631 2.1.5.1. SNMP Transport Security Model 633 The SNMP Transport Security Model [RFC5591] is an alternative to the 634 existing SNMPv1 and SNMPv2 Community-based Security Models [BCP74], 635 and the User-based Security Model [STD62][RFC3414]. 637 The Transport Security Model utilizes one or more lower-layer 638 security mechanisms to provide message-oriented security services. 639 These include authentication of the sender, encryption, timeliness 640 checking, and data integrity checking. 642 A secure transport model sets up an authenticated and possibly 643 encrypted session between the Transport Models of two SNMP engines. 644 After a transport-layer session is established, SNMP messages can be 645 sent through this session from one SNMP engine to the other. The new 646 Transport Model supports the sending of multiple SNMP messages 647 through the same session to amortize the costs of establishing a 648 security association. 650 The Secure Shell (SSH) Transport Model [RFC5592] and the Transport 651 Layer Security (TLS) Transport Model [RFC6353] are current examples 652 for Transport Security Models. 654 The SSH Transport Model makes use of the commonly deployed SSH 655 security and key-management infrastructure. [RFC5592] furthermore 656 defines MIB objects for monitoring and managing the SSH Transport 657 Model for SNMP. 659 The Transport Layer Security (TLS) transport model [RFC6353] uses 660 either the TLS protocol [RFC5246] or the Datagram Transport Layer 661 Security (DTLS) [RFC6347] protocol. The TLS and DTLS protocols 662 provide authentication and privacy services for SNMP applications. 663 TLS transport model supports the sending of SNMP messages over TLS 664 and TCP and over DTLS and UDP. [RFC6353] furthermore defines MIB 665 objects for managing the TLS Transport Model for SNMP. 667 [RFC5608] describes the use of a 'Remote Authentication Dial-In User 668 Service' (RADIUS) service by SNMP secure Transport Models for 669 authentication of users and authorization of services. Access 670 control authorization, i.e. how RADIUS attributes and messages are 671 applied to the specific application area of SNMP Access Control 672 Models, and VACM in particular has been specified in [RFC6065]. 674 2.2. SYSLOG Protocol 676 Syslog is a mechanism for distribution of logging information 677 initially used on Unix systems (see [RFC3164] for BSD Syslog). The 678 IETF SYSLOG protocol [RFC5424] introduces a layered architecture 679 allowing the use of any number of transport protocols, including 680 reliable and secure transports, for transmission of SYSLOG messages. 682 The SYSLOG protocol enables a machine to send system log messages 683 across networks to event message collectors. The protocol is simply 684 designed to transport and distribute these event messages. By 685 default, no acknowledgements of the receipt are made, except the 686 reliable delivery extensions specified in [RFC3195] are used. The 687 SYSLOG protocol and process does not require a stringent coordination 688 between the transport sender and the receiver. Indeed, the 689 transmission of SYSLOG messages may be started on a device without a 690 receiver being configured, or even actually physically present. 691 Conversely, many devices will most likely be able to receive messages 692 without explicit configuration or definitions. 694 BSD Syslog had little uniformity for the message format and the 695 content of Syslog messages. The body of a BSD Syslog message has 696 traditionally been unstructured text. This content is human- 697 friendly, but difficult to parse for applications. The IETF has 698 standardized a new message header format, including timestamp, 699 hostname, application, and message ID, to improve filtering, 700 interoperability and correlation between compliant implementations. 702 The SYSLOG protocol [RFC5424] introduces a mechanism for defining 703 Structured Data Elements (SDEs). The SDEs allow vendors to define 704 their own structured data elements to supplement standardized 705 elements. [RFC5675] defines a mapping from SNMP notifications to 706 SYSLOG messages. [RFC5676] defines a SNMP MIB module to represent 707 SYSLOG messages for sending SYSLOG messages as notifications to SNMP 708 notification receivers. [RFC5674] defines the way alarms are sent in 709 SYSLOG, which includes the mapping of ITU perceived severities onto 710 SYSLOG message fields and a number of alarm-specific definitions from 711 ITU-T X.733 [ITU-X733] and the IETF Alarm MIB [RFC3877]. 713 [RFC5848] "Signed Syslog Messages" defines a mechanism to add origin 714 authentication, message integrity, replay resistance, message 715 sequencing, and detection of missing messages to the transmitted 716 SYSLOG messages to be used in conjunction with the SYSLOG protocol. 718 The SYSLOG protocol layered architecture provides support for a 719 number of transport mappings. For interoperability purposes and 720 especially in managed networks, where the network path has been 721 explicitly provisioned for UDP syslog traffic, SYSLOG protocol can be 722 used over UDP [RFC5426]. However, to support congestion control and 723 reliability, [RFC5426] strongly recommends the use of the TLS 724 transport. 726 [RFC3195] "Reliable Delivery for syslog" describes mappings of the 727 SYSLOG protocol to TCP connections, useful for reliable delivery of 728 event messages. As such the specification provides robustness and 729 security in message delivery with encryption and authentication over 730 a connection-oriented protocol that is unavailable to the usual UDP- 731 based SYSLOG protocol. 733 IETF furthermore defined the TLS transport mapping for SYSLOG in 734 [RFC5425], which provides a secure connection for the transport of 735 SYSLOG messages. [RFC5425] describes the security threats to SYSLOG 736 and how TLS can be used to counter such threats. [RFC6012] defines 737 the Datagram Transport Layer Security (DTLS) Transport Mapping for 738 SYSLOG, which can be used if a connectionless transport is desired. 740 For information on MIB modules related to SYSLOG see Section 4.2.1. 742 2.3. IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) 743 Protocols 745 The IPFIX protocol [RFC5101], IP Flow Information eXport, defines a 746 push-based data export mechanism for transferring IP flow information 747 in a compact binary format from an exporter to a collector. 749 The IPFIX architecture [RFC5470] defines the components involved in 750 IP flow measurement and reporting of information on IP flows, 751 particularly, a metering process generating flow records, an 752 exporting process that sends metered flow information using the IPFIX 753 protocol, and a colleting process that receives flow information as 754 IPFIX data records. 756 After listing the IPFIX requirements in [RFC3917], NetFlow Version 9 757 [RFC3954] was taken as the basis for the IPFIX protocol and the IPFIX 758 architecture. 760 IPFIX can run over different transport protocols. The IPFIX protocol 761 [RFC5101] specifies Stream Control Transmission Protocol (SCTP) 762 [RFC4960] as the mandatory transport protocol to implement. Optional 763 alternatives are TCP [STD7] and UDP [STD6]. 765 SCTP is used with its Partial Reliability extension (PR-SCTP) 766 specified in [RFC3758]. [I-D.ietf-ipfix-export-per-sctp-stream] 767 specifies an extension to [RFC5101], when using the PR-SCTP 768 [RFC3758]. The extension offers several advantages over IPFIX 769 export, e.g. the ability to calculate Data Record losses for PR-SCTP, 770 immediate reuse of Template IDs within an SCTP stream, reduced 771 likelihood of Data Record loss, and reduced demands on the Collecting 772 Process. 774 IPFIX transmits IP flow information in data records containing IPFIX 775 Information Elements (IEs) defined by the IPFIX information model 776 [RFC5102]. IPFIX information elements are quantities with unit and 777 semantics defined by the information model. When transmitted over 778 the IPFIX protocol, only their values need to be carried in data 779 records. This compact encoding allows efficient transport of large 780 numbers of measured flow values. Remaining redundancy in data 781 records can be further reduced by methods described in [RFC5473] (for 782 further discussion on IPFIX IEs see Section 4). 784 The IPFIX information model is extensible. New information elements 785 can be registered at IANA (see 'IPFIX Information Elements' in 786 [IANA-PROT]). IPFIX also supports the use of proprietary, i.e. 787 enterprise-specific information elements. 789 The PSAMP protocol [RFC5476] extends the IPFIX protocol by means of 790 transferring information on individual packets. [RFC5475] specifies 791 a set of sampling and filtering techniques for IP packet selection, 792 based on the PSAMP framework [RFC5474]. The PSAMP information model 793 [RFC5477] provides a set of basic information elements for reporting 794 packet information with the IPFIX/PSAMP protocol. 796 The IPFIX model of an IP traffic flow is uni-directional. [RFC5103] 797 adds means of reporting bi-directional flows to IPFIX, for example 798 both directions of packet flows of a TCP connection. 800 When enterprise-specific information elements are transmitted with 801 IPFIX, a collector receiving data records may not know the type of 802 received data and cannot choose the right format for storing the 803 contained information. [RFC5610] provides means of exporting 804 extended type information for enterprise-specific Information 805 Elements from an exporter to a collector. 807 Collectors may store received flow information in files. The IPFIX 808 file format [RFC5655] can be used for storing IP flow information in 809 a way that facilitates exchange of traffic flow information between 810 different systems and applications. 812 In terms of IPFIX and PSAMP configurations, the metering and 813 exporting processes are configured out of band. As the IPFIX 814 protocol is a push mechanism only, IPFIX cannot configure the 815 exporter. The actual configuration of selection processes, caches, 816 exporting processes, and collecting processes of IPFIX and PSAMP 817 compliant monitoring devices is executed using the NETCONF protocol 818 [RFC6241] (see Section 2.4.1). The 'Configuration Data Model for 819 IPFIX and PSAMP' [I-D.ietf-ipfix-configuration-model] has been 820 specified using Unified Modeling Language (UML) class diagrams. The 821 data model is formally defined using the YANG modeling language 822 [RFC6020] (see Section 2.4.2). 824 At the time of this writing a framework for IPFIX flow mediation is 825 in preparation, which addresses the need for mediation of flow 826 information in IPFIX applications in large operator networks, e.g. 827 for aggregating huge amounts of flow data and for anonymization of 828 flow information (see the problem statement in [RFC5982]). 830 The IPFIX Mediation Framework [RFC6183] defines the intermediate 831 device between exporters and collectors, which provides an IPFIX 832 mediation by receiving a record stream from e.g. a collecting 833 process, hosting one or more intermediate processes to transform this 834 stream, and exporting the transformed record stream into IPFIX 835 messages via an exporting process. 837 Examples for mediation functions are flow aggregation, flow 838 selection, and anonymization of traffic information (see [RFC6235]). 840 Privacy, integrity, and authentication of exporter and collector are 841 important security requirements for IPFIX [RFC3917]. 842 Confidentiality, integrity, and authenticity of IPFIX data 843 transferred from an exporting process to a collecting process must be 844 ensured. The IPFIX and PSAMP protocols do not define any new 845 security mechanism and rely on the security mechanism of the 846 underlying transport protocol, such as TLS [RFC5246] and DTLS 847 [RFC6347]. 849 The primary goal of IPFIX is the reporting of the flow accounting for 850 flexible flow definitions and usage-based accounting. As described 851 in the IPFIX Applicability Statement [RFC5472], there are also other 852 applications such as traffic profiling, traffic engineering, 853 intrusion detection, and QoS monitoring, that require flow-based 854 traffic measurements and can be realized using IPFIX. IPFIX 855 Applicability Statement explains furthermore the relation of IPFIX to 856 other framework and protocols such as PSAMP, RMON (Remote Network 857 Monitoring MIB Section 4.2.1), and IPPM (IP Performance Metrics 858 Section 3.4)). Similar flow information could be also used for 859 security monitoring. The addition of performance metrics in the 860 IPFIX IANA registry [IANA-IPFIX], will extend the IPFIX use case to 861 performance management. 863 Note that even if the initial IPFIX focus has been around IP flow 864 information exchange, non-IP-related information elements are now 865 specified in IPFIX IANA registration (e.g. MAC (Media Access 866 Control) address, MPLS (Multiprotocol Label Switching) labels, etc.). 867 At the time of this writing, there are requests to widen the focus of 868 IPFIX and to export also non-IP related information elements (such as 869 SIP monitoring IEs). 871 The IPFIX Structured Data [RFC6313] is an extension to the IPFIX 872 protocol, which supports hierarchical structured data and lists 873 (sequences) of Information Elements in data records. This extension 874 allows the definition of complex data structures such as variable- 875 length lists and specification of hierarchical containment 876 relationships between templates. Furthermore, the extension provides 877 the semantics to express the relationship among multiple list 878 elements in a structured data record. 880 For information on data models related to the management of the IPFIX 881 and PSAMP protocols see Section 4.2.1 and Section 4.2.2. For 882 information on IPFIX/PSAMP IEs, see Section 4.2.3. 884 2.4. Network Configuration 886 2.4.1. Network Configuration Protocol (NETCONF) 888 The IAB workshop on Network Management [RFC3535] determined advanced 889 requirements for configuration management: 891 o Robustness: Minimizing disruptions and maximizing stability, 893 o Support of task-oriented view, 895 o Extensible for new operations, 897 o Standardized error handling, 899 o Clear distinction between configuration data and operational 900 state, 902 o Distribution of configurations to devices under transactional 903 constraints, 905 o Single and multi-system transactions and scalability in the number 906 of transactions and managed devices, 908 o Operations on selected subsets of management data, 909 o Dump and reload a device configuration in a textual format in a 910 standard manner across multiple vendors and device types, 912 o Support a human interface and a programmatic interface, 914 o Data modeling language with a human friendly syntax, 916 o Easy conflict detection and configuration validation, and 918 o Secure transport, authentication, and robust access control. 920 The NETCONF protocol [RFC6241] provides mechanisms to install, 921 manipulate, and delete the configuration of network devices and aims 922 to address the configuration management requirements pointed in the 923 IAB workshop. It uses an XML-based data encoding for the 924 configuration data as well as the protocol messages. The NETCONF 925 protocol operations are realized on top of a simple and reliable 926 Remote Procedure Call (RPC) layer. A key aspect of NETCONF is that 927 it allows the functionality of the management protocol to closely 928 mirror the native command line interface of the device. 930 The NETCONF working group developed the NETCONF Event Notifications 931 Mechanism as an optional capability, which provides an asynchronous 932 message notification delivery service for NETCONF [RFC5277]. NETCONF 933 notification mechanism enables using general purpose notification 934 streams, where the originator of the notification stream can be any 935 managed device (e.g. SNMP notifications). 937 NETCONF Partial Locking specification introduces fine-grained locking 938 of the configuration datastore to enhance NETCONF for fine-grained 939 transactions on parts of the datastore [RFC5717]. 941 The NETCONF working group also defined the necessary data model to 942 monitor the NETCONF protocol by using the modeling language YANG 943 [RFC6022] (see Section 2.4.2). The monitoring data model includes 944 information about NETCONF datastores, sessions, locks, and 945 statistics, which facilitate the management of a NETCONF server. 947 NETCONF connections are required to provide authentication, data 948 integrity, confidentiality, and replay protection. NETCONF depends 949 on the underlying transport protocol for this capability. For 950 example, connections can be encrypted in TLS or SSH, depending on the 951 underlying protocol. 953 The NETCONF working group defined the SSH transport protocol as the 954 mandatory transport binding [RFC6242]. Other optional transport 955 bindings are TLS [RFC5539], BEEP (over TLS) [RFC4744], and SOAP (over 956 HTTP over TLS) [RFC4743]. 958 The NETCONF Access Control Model (NACM) [RFC6536] provides standard 959 mechanisms to restrict protocol access to particular users with a 960 pre-configured subset of operations and content. 962 2.4.2. YANG - NETCONF Data Modeling Language 964 Following the guidelines of the IAB management workshop [RFC3535], 965 the NETMOD working group developed a data modeling language defining 966 the semantics of operational and configuration data, notifications, 967 and operations [RFC6020]. The new data modeling language maps 968 directly to XML-encoded content (on the wire) and will serve as the 969 normative description of NETCONF data models. 971 YANG has following properties addressing specific requirements on a 972 modeling language for configuration management: 974 o YANG provides the means to define hierarchical data models. It 975 supports reusable data types and groupings, i.e., a set of schema 976 nodes that can be reused across module boundaries. 978 o YANG supports the distinction between configuration and state 979 data. In addition, it provides support for modeling event 980 notifications and the specification of operations that extend the 981 base NETCONF operations. 983 o YANG allows to express constraints on data models by means of type 984 restrictions and XPATH 1.0 [XPATH] expressions. XPATH expressions 985 can also be used to make certain portions of a data model 986 conditional. 988 o YANG supports the integration of standard and vendor defined data 989 models. YANG's augmentation mechanism allows to seamlessly 990 augment standard data models with proprietary extensions. 992 o YANG data models can be partitioned into collections of features, 993 allowing low-end devices to only implement the core features of a 994 data model while high-end devices may choose to support all 995 features. The supported features are announced via the NETCONF 996 capability exchange to management applications. 998 o The syntax of the YANG language is compact and optimized for human 999 readers. An associated XML-based syntax called the YANG 1000 Independent Notation (YIN) [RFC6020] is available to allow the 1001 processing of YANG data models with XML-based tools. The mapping 1002 rules for the translation of YANG data models into Document Schema 1003 Definition Languages (DSDL), of which Relax NG is a major 1004 component, are defined in [RFC6110]. 1006 o Devices implementing standard data models can document deviations 1007 from the data model in separate YANG modules. Applications 1008 capable of discovering deviations can make allowances that would 1009 otherwise not be possible. 1011 A collection of common data types for IETF-related standards is 1012 provided in [RFC6021]. This standard data type library has been 1013 derived to a large extend from common SMIv2 data types, generalizing 1014 them to a less constrained NETCONF framework. 1016 The document "An Architecture for Network Management using NETCONF 1017 and YANG" describes how NETCONF and YANG can be used to build network 1018 management applications that meet the needs of network operators 1019 [RFC6244]. 1021 The Experimental RFC [RFC6095] specifies extensions for YANG 1022 introducing language abstractions such as class inheritance and 1023 recursive data structures. 1025 [RFC6087] gives guidelines for the use of YANG within IETF and other 1026 standardization organizations. 1028 Work is underway to standardize a translation of SMIv2 data models 1029 into YANG data models preserving investments into SNMP MIB modules, 1030 which are widely available for monitoring purposes. 1032 Several independent and open source implementations of the YANG data 1033 modeling language and associated tools are available. 1035 While YANG is a relatively recent data modeling language, some data 1036 models have already been produced. The specification of the base 1037 NETCONF protocol operations has been revised and uses YANG as the 1038 normative modeling language to specify its operations [RFC6241]. The 1039 IPFIX working group prepared the normative model for configuring and 1040 monitoring IPFIX and PSAMP compliant monitoring devices using the 1041 YANG modeling language [I-D.ietf-ipfix-configuration-model]. 1043 At the time of this writing the NETMOD working group is developing 1044 core system and interface data models. Following the example of the 1045 IPFIX configuration model, IETF working groups will prepare models 1046 for their specific needs. 1048 For information on data models developed using the YANG modeling 1049 language see Section 4.2.1 and Section 4.2.2. 1051 3. Network Management Protocols and Mechanisms with specific Focus 1053 This section reviews additional protocols IETF offers for management 1054 and discusses for which applications they were designed and/or 1055 already successfully deployed. These are protocols that have mostly 1056 reached Proposed Standard status or higher within the IETF. 1058 3.1. IP Address Management 1060 3.1.1. Dynamic Host Configuration Protocol (DHCP) 1062 Dynamic Host Configuration Protocol (DHCP) [RFC2131] provides a 1063 framework for passing configuration information to hosts on a TCP/IP 1064 network and enables as such auto-configuration in IP networks. In 1065 addition to IP address management, DHCP can also provide other 1066 configuration information, such as default routers, the IP addresses 1067 of recursive DNS servers and the IP addresses of NTP servers. As 1068 described in [RFC6272] DHCP can be used for IPv4 and IPv6 Address 1069 Allocation and Assignment as well as for Service Discovery. 1071 There are two versions of DHCP, one for IPv4 (DHCPv4) [RFC2131] and 1072 one for IPv6 (DHCPv6) [RFC3315]. DHCPv4 was defined as an extension 1073 to BOOTP (Bootstrap Protocol) [RFC0951]. DHCPv6 was subsequently 1074 defined to accommodate new functions required by IPv6 such as 1075 assignment of multiple addresses to an interface and to address 1076 limitations in the design of DHCPv4 resulting from its origins in 1077 BOOTP. While both versions bear the same name and perform the same 1078 functionality, the details of DHCPv4 and DHCPv6 are sufficiently 1079 different that they can be considered separate protocols. 1081 In addition to the assignment of IP addresses and other configuration 1082 information, DHCP options like the Relay Agent Information option 1083 (DHCPv4) [RFC3046] and, the Interface-Id Option (DHCPv6) [RFC3315] 1084 are widely used by ISPs. 1086 DHCPv6 includes Prefix Delegation [RFC3633], which is used to 1087 provision a router with an IPv6 prefix for use in the subnetwork 1088 supported by the router. 1090 Following are examples of DHCP options that provide configuration 1091 information or access to specific servers. A complete list of DHCP 1092 options is available at [IANA-PROT]. 1094 o [RFC3646] "DNS Configuration options for DHCPv6" describes DHCPv6 1095 options for passing a list of available DNS recursive name servers 1096 and a domain search list to a client. 1098 o [RFC2610] "DHCP Options for Service Location Protocol" describes 1099 DHCPv4 options and methods through which entities using the 1100 Service Location Protocol can find out the address of Directory 1101 Agents in order to transact messages and how the assignment of 1102 scope for configuration of SLP User and Service Agents can be 1103 achieved. 1105 o [RFC3319] "DHCPv6 Options for Session Initiation Protocol (SIP) 1106 Servers" specifies DHCPv6 options that allow SIP clients to locate 1107 a local SIP server that is to be used for all outbound SIP 1108 requests, a so-called outbound proxy server. 1110 o [RFC4280] "DHCP Options for Broadcast and Multicast Control 1111 Servers" defines DHCPv6 options to discover the Broadcast and 1112 Multicast Service (BCMCS) controller in an IP network. 1114 Built directly on UDP and IP, DHCP itself has no security provisions. 1115 There are two different classes of potential security issues related 1116 to DHCP: unauthorized DHCP Servers and unauthorized DHCP Clients. 1117 The recommended solutions to these risks generally involve providing 1118 security at lower layers, e.g. careful control over physical access 1119 to the network, security techniques implemented at layer two but also 1120 IPSec at layer three can be used to provide authentication. 1122 3.1.2. Ad-Hoc Network Autoconfiguration 1124 Ad-hoc nodes need to configure their network interfaces with locally 1125 unique addresses as well as globally routable IPv6 addresses, in 1126 order to communicate with devices on the Internet. The IETF AUTOCONF 1127 working group developed [RFC5889], which describes the addressing 1128 model for ad-hoc networks and how nodes in these networks configure 1129 their addresses. 1131 The ad-hoc nodes under consideration are expected to be able to 1132 support multi-hop communication by running MANET (Mobile ad-hoc 1133 network) routing protocols as developed by the IETF MANET working 1134 group. 1136 From the IP layer perspective, an ad hoc network presents itself as a 1137 layer 3 multi-hop network formed over a collection of links. The 1138 addressing model aims to avoid problems for ad-hoc-unaware parts of 1139 the system, such as standard applications running on an ad-hoc node 1140 or regular Internet nodes attached to the ad-hoc nodes. 1142 3.2. IPv6 Network Operations 1144 The IPv6 Operations Working Group develops guidelines for the 1145 operation of a shared IPv4/IPv6 Internet and provides operational 1146 guidance on how to deploy IPv6 into existing IPv4-only networks, as 1147 well as into new network installations. 1149 o [RFC4213] "Basic Transition Mechanisms for IPv6 Hosts and Routers" 1150 specifies IPv4 compatibility mechanisms for dual stack and 1151 configured tunneling that can be implemented by IPv6 hosts and 1152 routers. Dual stack implies providing complete implementations of 1153 both IPv4 and IPv6, and configured tunneling provides a means to 1154 carry IPv6 packets over unmodified IPv4 routing infrastructures. 1156 o [RFC3574] "Transition Scenarios for 3GPP Networks" lists different 1157 scenarios in 3GPP defined packet network that would need IPv6 and 1158 IPv4 transition, where [RFC4215] "Analysis on IPv6 Transition in 1159 Third Generation Partnership Project (3GPP) Networks" does a more 1160 detailed analysis of the transition scenarios that may come up in 1161 the deployment phase of IPv6 in 3GPP packet networks. 1163 o [RFC4029] "Scenarios and Analysis for Introducing IPv6 into ISP 1164 Networks" describes and analyzes different scenarios for the 1165 introduction of IPv6 into an ISP's existing IPv4 network. 1166 [RFC5181] "IPv6 Deployment Scenarios in 802.16 Networks" provides 1167 a detailed description of IPv6 deployment, integration methods and 1168 scenarios in wireless broadband access networks (802.16) in 1169 coexistence with deployed IPv4 services. [RFC4057] describes the 1170 scenarios for IPv6 deployment within enterprise networks. 1172 o [RFC4038] "Application Aspects of IPv6 Transition" specifies 1173 scenarios and application aspects of IPv6 transition considering 1174 how to enable IPv6 support in applications running on IPv6 hosts, 1175 and giving guidance for the development of IP version-independent 1176 applications. 1178 o The ongoing work on an IANA-reserved IPv4 prefix for shared 1179 address spaces [I-D.weil-shared-transition-space-request] "IANA 1180 Reserved IPv4 Prefix for Shared Address Space" updates RFC 5735 1181 and requests the allocation of an IPv4/10 address block to be used 1182 as "Shared Carrier Grade Network Address Translation (CGN) Space" 1183 by service providers to number the interfaces that connect CGN 1184 devices to Customer Premise Equipment (CPE). 1186 3.3. Policy-based Management 1188 3.3.1. IETF Policy Framework 1190 IETF specified a general policy framework [RFC2753] for managing, 1191 sharing, and reusing policies in a vendor independent, interoperable, 1192 and scalable manner. [RFC3460] specifies the Policy Core Information 1193 Model (PCIM) as an object-oriented information model for representing 1194 policy information. PCIM has been developed jointly in the IETF 1195 Policy Framework working group and the Common Information Model (CIM) 1196 activity in the Distributed Management Task Force (DMTF). PCIM has 1197 been published as extensions to CIM [DMTF-CIM]. 1199 The IETF Policy Framework is based on a policy-based admission 1200 control specifying two main architectural elements, the Policy 1201 Enforcement Point (PEP) and the Policy Decision Point (PDP). For the 1202 purpose of network management, policies allow an operator to specify 1203 how the network is to be configured and monitored by using a 1204 descriptive language. Furthermore, it allows the automation of a 1205 number of management tasks, according to the requirements set out in 1206 the policy module. 1208 IETF Policy Framework has been accepted by the industry as a 1209 standard-based policy management approach and has been adopted by 1210 different SDOs e.g. for 3GGP charging standards. 1212 3.3.2. Use of Common Open Policy Service (COPS) for Policy Provisioning 1213 (COPS-PR) 1215 [RFC3159] defines the Structure of Policy Provisioning Information 1216 (SPPI), an extension to the SMIv2 modeling language used to write 1217 Policy Information Base (PIB) modules. COPS-PR [RFC3084] uses the 1218 Common Open Policy Service (COPS) protocol [RFC2748] for provisioning 1219 of policy information. COPS provides a simple client/server model 1220 for supporting policy control over QoS signaling protocols. The 1221 COPS-PR specification is independent of the type of policy being 1222 provisioned (QoS, security, etc.) but focuses on the mechanisms and 1223 conventions used to communicate provisioned information between 1224 policy-decision-points (PDPs) and policy enforcement points (PEPs). 1225 Policy data is modeled using Policy Information Base (PIB) modules. 1227 COPS-PR has not been widely deployed, and operators have stated that 1228 its use of binary encoding (BER) for management data makes it 1229 difficult to develop automated scripts for simple configuration 1230 management tasks in most text-based scripting languages. In the IAB 1231 Workshop on Network Management [RFC3535], the consensus of operators 1232 and protocol developers indicated a lack of interest in PIB modules 1233 for use with COPS-PR. 1235 As a result, even if COPS-PR and the Structure of Policy Provisioning 1236 Information (SPPI) were initially approved as Proposed Standards, the 1237 IESG has not approved any PIB modules as IETF standard, and the use 1238 of COPS-PR is not recommended. 1240 3.4. IP Performance Metrics (IPPM) 1242 The IPPM working group has defined metrics for accurately measuring 1243 and reporting the quality, performance, and reliability of Internet 1244 data delivery. The metrics include connectivity, one-way delay and 1245 loss, round-trip delay and loss, delay variation, loss patterns, 1246 packet reordering, bulk transport capacity, and link bandwidth 1247 capacity. 1249 These metrics are designed for use by network operators and their 1250 customers, and provide unbiased quantitative measures of performance. 1251 The IPPM metrics have been developed inside an active measurement 1252 context, that is, the devices used to measure the metrics produce 1253 their own traffic. However, most of the metrics can be used inside a 1254 passive context as well. At the time of this writing there is no 1255 work planned in the area of passive measurement. 1257 As a property individual IPPM performance and reliability metrics 1258 need to be well-defined and concrete thus implementable. 1259 Furthermore, the methodology used to implement a metric needs to be 1260 repeatable with consistent measurements. 1262 IETF IP Performance Metrics have been adopted by different 1263 organizations, e.g. Metro Ethernet Forum. 1265 Note that this document does not aim to cover OAM technologies on the 1266 data-path and as such the discussion of IPPM-based active vs. passive 1267 monitoring as well as the data plane measurement and its diagnostics 1268 is rather incomplete. For a detailed overview and discussion of IETF 1269 OAM standards and IPPM measurement mechanisms the reader is referred 1270 to the documents listed at the end of Section 1.2 "Related Work" but 1271 especially to [I-D.ietf-opsawg-oam-overview]. 1273 Following are examples of essential IPPM documents: 1275 o IPPM Framework document [RFC2330] defines a general framework for 1276 particular metrics developed by IPPM working group and defines the 1277 fundamental concepts of 'metric' and 'measurement methodology' and 1278 discusses the issue of measurement uncertainties and errors as 1279 well as introduces the notion of empirically defined metrics and 1280 how metrics can be composed. 1282 o [RFC2679] "One-way Delay Metric for IPPM", defines a metric for 1283 one-way delay of packets across Internet paths. It builds on 1284 notions introduced in the IPPM Framework document. 1286 o [RFC2681] "Round-trip Delay Metric for IPPM", defines a metric for 1287 round-trip delay of packets across network paths and follows 1288 closely the corresponding metric for One-way Delay. 1290 o [RFC3393] "IP Packet Delay Variation Metric", refers to a metric 1291 for variation in delay of packets across network paths and is 1292 based on the difference in the One-Way-Delay of selected packets 1293 called "IP Packet Delay Variation (ipdv)". 1295 o [RFC2680] "One-way Packet Loss Metric for IPPM", defines a metric 1296 for one-way packet loss across Internet paths. 1298 o [RFC5560] "One-Way Packet Duplication Metric", defines a metric 1299 for the case, where multiple copies of a packet are received and 1300 discusses methods to summarize the results of streams. 1302 o [RFC4737] "Packet Reordering Metrics", defines metrics to evaluate 1303 whether a network has maintained packet order on a packet-by- 1304 packet basis and discusses the measurement issues, including the 1305 context information required for all metrics. 1307 o [RFC2678] "IPPM Metrics for Measuring Connectivity", defines a 1308 series of metrics for connectivity between a pair of Internet 1309 hosts. 1311 o [RFC5835] "Framework for Metric Composition", describes a detailed 1312 framework for composing and aggregating metrics. 1314 o [BCP170] "Guidelines for Considering New Performance Metric 1315 Development" describes the framework and process for developing 1316 Performance Metrics of protocols and applications transported over 1317 IETF-specified protocols. 1319 To measure these metrics two protocols and a sampling method have 1320 been standardized: 1322 o [RFC4656] "A One-way Active Measurement Protocol (OWAMP)", 1323 measures unidirectional characteristics such as one-way delay and 1324 one-way loss between network devices and enables the 1325 interoperability of these measurements. OWAMP is discussed in 1326 more detail in [I-D.ietf-opsawg-oam-overview]. 1328 o [RFC5357] "A Two-Way Active Measurement Protocol (TWAMP)", adds 1329 round-trip or two-way measurement capabilities to OWAMP. TWAMP is 1330 discussed in more detail in [I-D.ietf-opsawg-oam-overview]. 1332 o [RFC3432] "Network performance measurement with Periodic Streams", 1333 describes a periodic sampling method and relevant metrics for 1334 assessing the performance of IP networks, as an alternative to the 1335 Poisson sampling method described in [RFC2330]. 1337 For information on MIB modules related to IP Performance Metrics see 1338 Section 4.2.4. 1340 3.5. Remote Authentication Dial In User Service (RADIUS) 1342 RADIUS [RFC2865], the Remote Authentication Dial In User Service, 1343 describes a client/server protocol for carrying authentication, 1344 authorization, and configuration information between a Network Access 1345 Server (NAS), which desires to authenticate its links and a shared 1346 Authentication Server. The companion document [RFC2866] 'Radius 1347 Accounting' describes a protocol for carrying accounting information 1348 between a network access server and a shared accounting server. 1349 [RFC2867] adds required new RADIUS accounting attributes and new 1350 values designed to support the provision of tunneling in dial-up 1351 networks. 1353 The RADIUS protocol is widely used in environments like enterprise 1354 networks, where a single administrative authority manages the 1355 network, and protects the privacy of user information. RADIUS is 1356 deployed in fixed broadband access provider networks as well as in 1357 cellular broadband operators' networks. 1359 RADIUS uses attributes to carry the specific authentication, 1360 authorization, information, and configuration details. RADIUS is 1361 extensible with a known limitation of maximum 255 attribute codes and 1362 253 octets as attribute content length. RADIUS has Vendor-Specific 1363 Attributes (VSA), which have been used both for vendor-specific 1364 purposes as an addition to standardized attributes as well as to 1365 extend the limited attribute code space. 1367 The RADIUS protocol uses a shared secret along with the MD5 (Message- 1368 Digest algorithm 5) hashing algorithm to secure passwords [RFC1321]. 1369 Based on the known threads additional protection like IPsec tunnels 1370 [RFC4301] are used to further protect the RADIUS traffic. However, 1371 building and administering large IPsec protected networks may become 1372 a management burden, especially when IPsec protected RADIUS 1373 infrastructure should provide inter-provider connectivity. A trend 1374 has been moving towards TLS-based security solutions [RFC5246] and 1375 establishing dynamic trust relationships between RADIUS servers. 1376 Since the introduction of TCP transport for RADIUS, it became natural 1377 to have TLS support for RADIUS. An ongoing work specifies the 'TLS 1378 encryption for RADIUS'. 1380 [RFC2868] 'RADIUS Attributes for Tunnel Protocol Support' defines a 1381 number of RADIUS attributes designed to support the compulsory 1382 provision of tunneling in dial-up network access. Some applications 1383 involve compulsory tunneling i.e. the tunnel is created without any 1384 action from the user and without allowing the user any choice in the 1385 matter. In order to provide this functionality, specific RADIUS 1386 attributes are needed to carry the tunneling information from the 1387 RADIUS server to the tunnel end points. [RFC3868] defines the 1388 necessary attributes, attribute values and the required IANA 1389 registries. 1391 [RFC3162] 'RADIUS and IPv6' specifies the operation of RADIUS over 1392 IPv6 and the RADIUS attributes used to support the IPv6 network 1393 access. [RFC4818] describes how to transport delegated IPv6 prefix 1394 information over RADIUS. 1396 [RFC4675] 'RADIUS Attributes for Virtual LAN and Priority Support' 1397 defines additional attributes for dynamic Virtual LAN assignment and 1398 prioritization, for use in provisioning of access to IEEE 802 local 1399 area networks usable with RADIUS and DIAMETER. 1401 [RFC5080] 'Common RADIUS Implementation Issues and Suggested Fixes' 1402 describes common issues seen in RADIUS implementations and suggests 1403 some fixes. Where applicable, unclear statements and errors in 1404 previous RADIUS specifications are clarified. People designing 1405 extensions to RADIUS protocol for various deployment cases should get 1406 familiar with RADIUS Design Guidelines [RFC6158] in order to avoid 1407 e.g. known interoperability challenges. 1409 [RFC5090] 'RADIUS Extension for Digest Authentication' defines an 1410 extension to the RADIUS protocol to enable support of Digest 1411 Authentication, for use with HTTP-style protocols like the Session 1412 Initiation Protocol (SIP) and HTTP. 1414 [RFC5580] 'Carrying Location Objects in RADIUS and DIAMETER describes 1415 procedures for conveying access-network ownership and location 1416 information based on civic and geospatial location formats in RADIUS 1417 and DIAMETER. 1419 [RFC5607] specifies required RADIUS attributes and their values for 1420 authorizing a management access to a NAS. Both local and remote 1421 management are supported, with access rights and management 1422 privileges. Specific provisions are made for remote management via 1423 Framed Management protocols, such as SNMP and NETCONF, and for 1424 management access over a secure transport protocols. 1426 [RFC3579] describes how to use RADIUS to convey Extensible 1427 Authentication Protocol (EAP) [RFC3748] payload between the 1428 authenticator and the EAP server using RADIUS. RFC3579 is widely 1429 implemented, for example, in WLAN and 802.1 X environments. 1430 [RFC3580] describes how to use RADIUS with IEEE 802.1X 1431 authenticators. In the context of 802.1X and EAP-based 1432 authentication, the Vendor Specific Attributes described in [RFC2458] 1433 have been widely accepted by the industry. [RFC2869] 'RADIUS 1434 extensions' is another important RFC related to EAP use. RFC2869 1435 describes additional attributes for carrying AAA information between 1436 a NAS and a shared Accounting Server using RADIUS. It also defines 1437 attributes to encapsulate EAP message payload. 1439 There are different MIB modules defined for multiple purposes to use 1440 with RADIUS (see Section 4.2.3 and Section 4.2.5 ). 1442 3.6. Diameter Base Protocol (DIAMETER) 1444 DIAMETER [RFC3588] provides an Authentication, Authorization and 1445 Accounting (AAA) framework for applications such as network access or 1446 IP mobility. DIAMETER is also intended to work in local AAA and in 1447 roaming scenarios. DIAMETER provides an upgrade path for RADIUS but 1448 is not directly backwards compatible. 1450 DIAMETER is designed to resolve a number of known problems with 1451 RADIUS. DIAMETER supports server failover, reliable transport over 1452 TCP and SCTP, well documented functions for proxy, redirect and relay 1453 agent functions, server-initiated messages, auditability, and 1454 capability negotiation. DIAMETER also provides a larger attribute 1455 space for Attribute-Value Pairs (AVP) and identifiers than RADIUS. 1456 DIAMETER features make it especially appropriate for environments, 1457 where the providers of services are in different administrative 1458 domains than the maintainer (protector) of confidential user 1459 information. 1461 Other notable differences to RADIUS are: 1463 o Network and transport layer security (IPsec or TLS), 1465 o Stateful and stateless models, 1467 o Dynamic discovery of peers (using DNS SRV and NAPTR), 1469 o Concept of an application that describes how a specific set of 1470 commands and Attribute-Value Pairs (AVPs) are treated by DIAMETER 1471 nodes. Each application has an IANA assigned unique identifier, 1473 o Support of application layer acknowledgements, failover methods 1474 and state machines, 1476 o Basic support for user-sessions and accounting, 1478 o Better roaming support, 1479 o Error notification, and 1481 o Easy extensibility. 1483 The DIAMETER protocol is designed to be extensible to support e.g. 1484 proxies, brokers, mobility and roaming, Network Access Servers 1485 (NASREQ), and Accounting and Resource Management. DIAMETER 1486 applications extend the DIAMETER base protocol by adding new commands 1487 and/or attributes. Each application is defined by a unique IANA 1488 assigned application identifier and can add new command codes and/or 1489 new mandatory AVPs. 1491 The DIAMETER application identifier space has been divided into 1492 Standards Track and 'First Come First Served' vendor-specific 1493 applications. Following are examples for DIAMETER applications 1494 published at IETF: 1496 o Diameter Base Protocol Application [RFC3588]: Required to support 1497 by all Diameter implementations. 1499 o Diameter Base Accounting Application [RFC3588]: A DIAMETER 1500 application using an accounting protocol based on a server 1501 directed model with capabilities for real-time delivery of 1502 accounting information. 1504 o Diameter Mobile IPv4 Application [RFC4004]: A DIAMETER application 1505 that allows a DIAMETER server to authenticate, authorize and 1506 collect accounting information for Mobile IPv4 services rendered 1507 to a mobile node. 1509 o Diameter Network Access Server Application (NASREQ, [RFC4005]): A 1510 DIAMETER application used for AAA services in the NAS environment. 1512 o Diameter Extensible Authentication Protocol Application [RFC4072]: 1513 A DIAMETER application that carries EAP packets between a NAS and 1514 a back-end authentication server. 1516 o Diameter Credit-Control Application [RFC4006]: A DIAMETER 1517 application that can be used to implement real-time credit-control 1518 for a variety of end user services such as network access, Session 1519 Initiation Protocol (SIP) services, messaging services, and 1520 download services. 1522 o Diameter Session Initiation Protocol Application [RFC4740]: A 1523 DIAMETER application designed to be used in conjunction with SIP 1524 and provides a DIAMETER client co-located with a SIP server, with 1525 the ability to request the authentication of users and 1526 authorization of SIP resources usage from a DIAMETER server. 1528 o Diameter Quality-of-Service Application [RFC5866]: A DIAMETER 1529 application allowing network elements to interact with Diameter 1530 servers when allocating QoS resources in the network. 1532 o Diameter Mobile IPv6 IKE (MIP6I) Application [RFC5778]: A DIAMETER 1533 application, which enables the interaction between a Mobile IP 1534 home agent and a Diameter server and is used when the mobile node 1535 is authenticated and authorized using IKEv2 [RFC5996]. 1537 o Diameter Mobile IPv6 Auth (MIP6A) Application [RFC5778]: A 1538 DIAMETER application, which enables the interaction between a 1539 Mobile IP home agent and a DIAMETER server and is used when the 1540 mobile node is authenticated and authorized using the Mobile IPv6 1541 Authentication Protocol [RFC4285]. 1543 The large majority of DIAMETER applications are vendor-specific and 1544 mainly used in various SDOs outside IETF. One example SDO using 1545 DIAMETER extensively is 3GPP (e.g. 3GPP 'IP Multimedia Subsystem' 1546 (IMS) uses DIAMETER based interfaces (e.g. Cx) [3GPPIMS]). 1547 Recently, during the standardization of the '3GPP Evolved Packet 1548 Core' [3GPPEPC], DIAMETER was chosen as the only AAA signaling 1549 protocol. 1551 One part of DIAMETER's extensibility mechanism is an easy and 1552 consistent way of creating new commands for the need of applications. 1553 RFC3588 proposed to define DIAMETER command code allocations with a 1554 new RFC. This policy decision caused undesired use and redefinition 1555 of existing Commands Codes within SDOs. Diverse RFCs have been 1556 published as simple command code allocations for other SDO purposes 1557 (see [RFC3589], [RFC5224], [RFC5431] and [RFC5516]). [RFC5719] 1558 changed the Command Code policy and added a range for vendor-specific 1559 Command Codes to be allocated on a 'First Come First Served' basis by 1560 IANA. 1562 The implementation and deployment experience of DIAMETER has led to 1563 the currently ongoing development of an update of the base protocol 1564 [I-D.ietf-dime-rfc3588bis], which introduces TLS as the preferred 1565 security mechanism and deprecates the in-band security negotiation 1566 for TLS. 1568 Some DIAMETER protocol enhancements and clarifications that logically 1569 fit better into [I-D.ietf-dime-rfc3588bis], are also needed on the 1570 existing RFC3588 based deployments. Therefore, protocol extensions 1571 specifically usable in large inter-provider roaming network scenarios 1572 are made available for RFC3588. Two currently existing 1573 specifications are mentioned below: 1575 o "Clarifications on the Routing of DIAMETER Requests Based on the 1576 Username and the Realm" [RFC5729] defines the behavior required 1577 for DIAMETER agents to route requests when the User-Name AVP 1578 contains a Network Access Identifier formatted with multiple 1579 realms. These multi-realm Network Access Identifiers are used in 1580 order to force the routing of request messages through a 1581 predefined list of mediating realms. 1583 o "Diameter Extended NAPTR" [RFC6408] describes an improved DNS- 1584 based dynamic DIAMETER Agent discovery mechanism without having to 1585 do DIAMETER capability exchange beforehand with a number of 1586 agents. 1588 There have been a growing number of DIAMETER framework documents at 1589 IETF that basically are just a collection of AVPs for a specific 1590 purpose or a system architecture with semantical AVP descriptions and 1591 a logic for "imaginary" applications. From standardization point of 1592 view, this practice allows the development of larger system 1593 architecture documents that do not need to reference AVPs or 1594 application logic outside IETF. Below are examples of a few recent 1595 AVP and framework documents: 1597 o "Diameter Mobile IPv6: Support for Network Access Server to 1598 Diameter Server Interaction" [RFC5447] describes the bootstrapping 1599 of the Mobile IPv6 framework and the support of interworking with 1600 existing Authentication, Authorization, and Accounting (AAA) 1601 infrastructures by using the DIAMETER Network Access Server to 1602 home AAA server interface. 1604 o "Traffic Classification and Quality of Service (QoS) Attributes 1605 for Diameter" [RFC5777] defines a number of DIAMETER AVPs for 1606 traffic classification with actions for filtering and QoS 1607 treatment. 1609 o "Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local 1610 Mobility Anchor Interaction with Diameter Server" [RFC5779] 1611 defines AAA interactions between Proxy Mobile IPv6 (PMIPv6) 1612 entities (Mobile Access Gateway and Local Mobility Anchor) and a 1613 AAA server within a PMIPv6 Domain. 1615 For information on MIB modules related to DIAMETER see Section 4.2.5. 1617 3.7. Control And Provisioning of Wireless Access Points (CAPWAP) 1619 Wireless LAN (WLAN) product architectures have evolved from single 1620 autonomous Access Points to systems consisting of a centralized 1621 Access Controller (AC) and Wireless Termination Points (WTPs). The 1622 general goal of centralized control architectures is to move access 1623 control, including user authentication and authorization, mobility 1624 management, and radio management from the single access point to a 1625 centralized controller, where an Access Points pulls the information 1626 from the Access Controller. 1628 Based on the CAPWAP Architecture Taxonomy work [RFC4118] the CAPWAP 1629 working group developed the CAPWAP protocol [RFC5415] to facilitate 1630 control, management and provisioning of WTPs specifying the services, 1631 functions and resources relating to 802.11 WLAN Termination Points in 1632 order to allow for interoperable implementations of WTPs and ACs. 1633 The protocol defines the CAPWAP control plane including the 1634 primitives to control data access. The protocol document also 1635 specifies how configuration management of WTPs can be done and 1636 defines CAPWAP operations responsible for debugging, gathering 1637 statistics, logging, and firmware management as well as discusses 1638 operational and transport considerations. 1640 The CAPWAP protocol is prepared to be independent of Layer 2 1641 technologies, and meets the objectives in "Objectives for Control and 1642 Provisioning of Wireless Access Points (CAPWAP)" [RFC4564]. Separate 1643 binding extensions enable the use with additional wireless 1644 technologies. [RFC5416] defines CAPWAP Protocol Binding for IEEE 1645 802.11. 1647 CAPWAP Control messages, and optionally CAPWAP Data messages, are 1648 secured using DTLS [RFC6347]. DTLS is used as a tightly integrated, 1649 secure wrapper for the CAPWAP protocol. 1651 For information on MIB modules related to CAPWAP see Section 4.2.2. 1653 3.8. Access Node Control Protocol (ANCP) 1655 The Access Node Control Protocol (ANCP) [RFC6320] realizes a control 1656 plane between a service-oriented layer 3 edge device, the Network 1657 Access Server (NAS) and a layer 2 Access Node (AN), e.g., Digital 1658 Subscriber Line Access Module (DSLAM). As such ANCP operates in a 1659 multi-service reference architecture and communicates QoS-, service- 1660 and subscriber-related configuration and operation information 1661 between a NAS and an Access Node. 1663 The main goal of this protocol is to configure and manage access 1664 equipments and allow them to report information to the NAS in order 1665 to enable and optimize configuration. 1667 The framework and requirements for an Access Node control mechanism 1668 and the use cases for ANCP are documented in [RFC5851]. 1670 The ANCP protocol offers authentication, and authorization between AN 1671 and NAS nodes and provides replay protection and data-origin 1672 authentication. ANCP protocol solution is also robust against 1673 Denial-of-Service (DoS) attacks. Furthermore, the ANCP protocol 1674 solution is recommended to offer confidentiality protection. 1675 Security Threats and Security Requirements for ANCP are discussed in 1676 [RFC5713]. 1678 3.9. Application Configuration Access Protocol (ACAP) 1680 The Application Configuration Access Protocol (ACAP) [RFC2244] is 1681 designed to support remote storage and access of program option, 1682 configuration and preference information. The data store model is 1683 designed to allow a client relatively simple access to interesting 1684 data, to allow new information to be easily added without server re- 1685 configuration, and to promote the use of both standardized data and 1686 custom or proprietary data. Key features include "inheritance" which 1687 can be used to manage default values for configuration settings and 1688 access control lists which allow interesting personal information to 1689 be shared and group information to be restricted. 1691 ACAP's primary purpose is to allow applications access to their 1692 configuration data from multiple network-connected computers. Users 1693 can then use any network-connected computer, run any ACAP-enabled 1694 application and have access to their own configuration data. To 1695 enable wide usage client simplicity has been preferred to server or 1696 protocol simplicity whenever reasonable. 1698 The ACAP 'authenticate' command uses Simple Authentication and 1699 Security Layer (SASL) [RFC4422] to provide basic authentication, 1700 authorization, integrity and privacy services. All ACAP 1701 implementations are required to implement the CRAM-MD5 (Challenge- 1702 Response Authentication Mechanism) [RFC2195] for authentication, 1703 which can be disabled based on the site security policy. 1705 3.10. XML Configuration Access Protocol (XCAP) 1707 The Extensible Markup Language (XML) Configuration Access Protocol 1708 (XCAP) [RFC4825] has been designed for and is commonly used with SIP- 1709 based solutions, in particular for instant message, presence, and SIP 1710 conference. XCAP is a protocol that allows a client to read, write, 1711 and modify application configuration data stored in XML format on a 1712 server, where the main functionality is provided by so called "XCAP 1713 Application Usages". 1715 XCAP is a protocol that can be used to manipulate per-user data. 1716 XCAP is a set of conventions for mapping XML documents and document 1717 components into HTTP URIs, rules for how the modification of one 1718 resource affects another, data validation constraints, and 1719 authorization policies associated with access to those resources. 1720 Because of this structure, normal HTTP primitives can be used to 1721 manipulate the data. Like ACAP, XCAP supports the configuration 1722 needs for a multiplicity of applications. 1724 All XCAP servers are required to implement HTTP Digest Authentication 1725 [RFC2617]. Furthermore, XCAP servers are required to implement HTTP 1726 over TLS (HTTPS) [RFC2818]. It is recommended that administrators 1727 use an HTTPS URI as the XCAP root URI, so that the digest client 1728 authentication occurs over TLS. 1730 Following list summarizes important XCAP application usages: 1732 o XCAP server capabilities [RFC4825] can be read by clients to 1733 determine which extensions, application usages, or namespaces a 1734 server supports. 1736 o A resource lists application is any application that needs access 1737 to a list of resources, identified by a URI, to which operations, 1738 such as subscriptions, can be applied [RFC4826]. 1740 o A Resource List Server (RLS) Services application is a Session 1741 Initiation Protocol (SIP) application, where a server receives SIP 1742 SUBSCRIBE requests for resources, and generates subscriptions 1743 towards the resource list [RFC4826]. 1745 o A Presence Rules application uses authorization policies, also 1746 known as authorization rules, to specify what presence information 1747 can be given to which watchers, and when [RFC4827]. 1749 o A Pidf-manipulation application defines how XCAP is used to 1750 manipulate the contents of PIDF based presence documents 1751 [RFC4827]. 1753 4. Network Management Data Models 1755 This section provides two complementary overviews for the network 1756 management data models standardized at IETF. The first subsection 1757 focuses on a broader view of models classified into categories such 1758 as generic and infrastructure data models as well as data models 1759 matched to different layers. The second subsection is structured 1760 following the management application view and focuses mainly on the 1761 data models for the network management tasks fault, configuration, 1762 accounting, performance, and security management (see [FCAPS]). 1764 Note that IETF does not use the FCAPS view as an organizing principle 1765 for its data models. However, FCAPS view is used widely outside of 1766 IETF for the realization of management tasks and applications. 1768 Section 4.2 aims to address the FCAPS view to enable people outside 1769 of IETF to understand the relevant data models at IETF. 1771 The different data models covered in this section are MIB modules, 1772 IPFIX Information Elements, SYSLOG Structured Data Elements, and YANG 1773 modules. There are many technology-specific IETF data models, such 1774 as transmission and protocol MIBs, which are not mentioned in this 1775 document and can be found at [RFCSEARCH]. 1777 This section gives an overview of management data models that have 1778 reached Draft or Proposed Standard status at the IETF. In 1779 exceptional cases, important Informational RFCs are referred. The 1780 advancement process for management data models beyond Proposed 1781 Standard status, has been defined in [BCP27] with a more pragmatic 1782 approach and special considerations on data model specification 1783 interoperability. However, most IETF management data models never 1784 advanced beyond Proposed Standard. 1786 4.1. IETF Network Management Data Models 1788 The data models defined by the IETF can be broadly classified into 1789 the following categories depicted in Figure 1. 1791 +-----------+ +-------------------------------+ +-----------+ 1792 | | | application layer data models | | network | 1793 | generic | +-------------------------------+ | management| 1794 | infra- | | transport layer data models | | infra- | 1795 | structure | +-------------------------------+ | structure | 1796 | data | | network layer data models | | data | 1797 | models | +-------------------------------+ | models | 1798 | | | link layer data models | | | 1799 +-----------+ +-------------------------------+ +-----------+ 1801 Figure 1: Categories of network management data models 1803 Each of the categories is briefly described below. Note that the 1804 classification used here intends to provide orientation and reflects 1805 how most data models have been developed in the IETF by the various 1806 working groups. This classification does not aim to classify 1807 correctly all data models that have been defined by the IETF so far. 1808 The network layering model in the middle of Figure 1 follows the four 1809 layer model of the Internet as defined in [RFC1021]. 1811 The network management object identifiers for use with IETF MIB 1812 modules defined at IETF can be found under the IANA registry at [SMI- 1813 NUMBERS]. 1815 4.1.1. Generic Infrastructure Data Models 1817 Generic infrastructure data models provide core abstractions that 1818 many other data models are built upon. The most important example is 1819 the interfaces data model defined in the IF-MIB [RFC2863]. It 1820 provides the basic notion of network interfaces and allows expressing 1821 stacking/layering relationships between interfaces. The interfaces 1822 data model also provides basic monitoring objects that are widely 1823 used for performance and fault management. 1825 The second important infrastructure data model is defined in the 1826 Entity MIB [RFC4133]. It exports the containment hierarchy of the 1827 physical entities (slots, modules, ports) that make up a networking 1828 device and as such, it is a key data model for inventory management. 1829 Physical entities can have pointers to other data models that provide 1830 more specific information about them (e.g. physical ports usually 1831 point to the related network interface). Entity MIB extensions exist 1832 for physical sensors such as temperature sensors embedded on line 1833 cards or sensors that report fan rotation speeds [RFC3433]. Another 1834 extension models states and alarms of physical entities [RFC4268]. 1835 Some vendors have extended the basic Entity MIB with several 1836 proprietary data models. 1838 4.1.2. Link Layer Data Models 1840 A number of data models exist in the form of MIB modules covering the 1841 link layers IP runs over, such as ADSL [RFC4706], VDSL [RFC5650], 1842 GMPLS [RFC4803], ISDN [RFC2127], ATM [RFC2515] [RFC3606], Cable 1843 Modems [RFC4546] or Ethernet [RFC4188] [RFC4318] [RFC4363]. These so 1844 called transmission data models typically extend the generic network 1845 interfaces data model with interface type specific information. Most 1846 of the link layer data models focus on monitoring capabilities that 1847 can be used for performance and fault management functions and to 1848 some lesser extend for accounting and security management functions. 1849 The IEEE has meanwhile taken over the responsibility to maintain and 1850 further develop data models for the IEEE 802 family of protocols 1851 [RFC4663]. The cable modem industry consortium DOCSIS is working 1852 with the IETF to publish data models for cable modem networks as IETF 1853 standards-track specifications. 1855 4.1.3. Network Layer Data Models 1857 There are data models in the form of MIB modules covering IP/ICMP 1858 [RFC4293] [RFC4292] network protocols and their extensions (e.g., 1859 Mobile IP), the core protocols of the Internet. In addition, there 1860 are data models covering popular unicast routing protocols (OSPF 1861 [RFC4750], ISIS [RFC4444], BGP-4 [RFC4273]) and multicast routing 1862 protocols (PIM [RFC5060]). 1864 Detailed models also exist for performance measurements in the form 1865 of IP performance metrics [RFC2330] (see Section 3.4). 1867 The necessary data model infrastructure for configuration data models 1868 covering network layers are currently being defined using NETCONF 1869 [RFC6242] and YANG [RFC6020]. 1871 4.1.4. Transport Layer Data Models 1873 There are data models for the transport protocols TCP [RFC4022], UDP 1874 [RFC4113], and SCTP [RFC3873]. For TCP, a data model providing 1875 extended statistics is defined in [RFC4898]. 1877 4.1.5. Application Layer Data Models 1879 Some data models have been developed for specific application 1880 protocols (e.g., SIP [RFC4780]). In addition, there are data models 1881 that provide a generic infrastructure for instrumenting applications 1882 in order to obtain data useful primarily for performance management 1883 and fault management [RFC2287] [RFC2564]. In general, however, 1884 generic application MIB modules have been less successful in gaining 1885 widespread deployment. 1887 4.1.6. Network Management Infrastructure Data Models 1889 A number of data models are concerned with the network management 1890 system itself. This includes, in addition to a set of SNMP MIB 1891 modules for monitoring and configuring SNMP itself [RFC3410], some 1892 MIB modules providing generic functions such as the calculation of 1893 expressions over MIB objects, generic functions for thresholding and 1894 event generation, event notification logging functions and data 1895 models to represent alarms [RFC2981] [RFC2982] [RFC3014] [RFC3877]. 1896 In addition, there are data models that allow to execute basic 1897 reachability and path discovery tests [RFC4560]. Another collection 1898 of MIB modules provides remote monitoring functions, ranging from the 1899 data link layer up to the application layer. This is known as the 1900 RMON family of MIB modules [RFC3577]. 1902 The IPFIX protocol [RFC5101] (Section 2.3) is used to export 1903 information about network flows collected at so called observation 1904 points (typically a network interface). The information elements 1905 [RFC5102] carried in IPFIX cover the network and transport layer very 1906 well but also provides some link layer specific information elements. 1907 Work is underway to further extend the standardized information that 1908 can be carried in IPFIX. 1910 The SYSLOG protocol document [RFC5424] (Section 2.2) defines an 1911 initial set of Structured Data Elements (SDEs) that relate to content 1912 time quality, content origin, and meta-information about the message, 1913 such as language. Proprietary SDEs can be used to supplement the 1914 IETF- defined SDEs. 1916 4.2. Network Management Data Models - FCAPS View 1918 This subsection follows the management application view and aims to 1919 match the data models to network management tasks for fault, 1920 configuration, accounting, performance, and security management 1921 ([FCAPS]). As OAM is a general term that refers to a toolset, which 1922 can be used for fault detection, isolation, and performance 1923 measurement, aspects of FCAPS in the context of the data path, such 1924 as fault and performance management, are also discussed in [I-D.ietf- 1925 opsawg-oam-overview] "An Overview of Operations, Administration, and 1926 Maintenance (OAM) Mechanisms". 1928 Some of the data models do not fit into one single FCAPS category per 1929 design but span multiple areas. For example, there are many 1930 technology-specific IETF data models, such as transmission and 1931 protocol MIBs, which cover multiple FCAPS categories, and therefore 1932 are not mentioned in this sub section and can be found at 1933 [RFCSEARCH]. 1935 4.2.1. Fault Management 1937 Fault management encloses a set of functions to detect, isolate, 1938 notify, and correct faults encountered in a network as well as to 1939 maintain and examine error logs. The data models below can be 1940 utilized to realize a fault management application. 1942 [RFC3418], part of SNMPv3 standard [STD62], is a MIB module 1943 containing objects in the system group that are often polled to 1944 determine if a device is still operating, and sysUpTime can be used 1945 to detect if the network management portion of the system has 1946 restarted, and counters have been reinitialized. 1948 [RFC3413], part of SNMPv3 standard [STD62], is a MIB module including 1949 objects designed for managing notifications, including tables for 1950 addressing, retry parameters, security, lists of targets for 1951 notifications, and user customization filters. 1953 The Interfaces Group MIB [RFC2863] builds on the old standard for MIB 1954 II [STD17] and is used as a primary MIB module for managing and 1955 monitoring the status of network interfaces. The Interfaces Group 1956 MIB defines a generic set of managed objects for network interfaces 1957 and it provides the infrastructure for additional managed objects 1958 specific to particular types of network interfaces, such as Ethernet. 1960 [RFC4560] defines a MIB module for performing ping, traceroute, and 1961 lookup operations at a host. For troubleshooting purposes, it is 1962 useful to be able to initiate and retrieve the results of ping or 1963 traceroute operations when they are performed at a remote host. 1965 The RMON (Remote Network Monitoring) MIB [STD59][RFC2819] can be 1966 configured to recognize conditions on existing MIB variables (most 1967 notably error conditions) and continuously to check for them. When 1968 one of these conditions occurs, the event may be logged, and 1969 management stations may be notified in a number of ways (for further 1970 discussion on RMON see Section 4.2.4). 1972 DISMAN-EVENT-MIB in [RFC2981] and DISMAN-EXPRESSION-MIB in [RFC2982] 1973 provide a superset of the capabilities of the RMON alarm and event 1974 groups. These modules provide mechanisms for thresholding and 1975 reporting anomalous events to management applications. 1977 The ALARM MIB in [RFC3877] and the Alarm Reporting Control MIB in 1978 [RFC3878] specify mechanisms for expressing state transition models 1979 for persistent problem states. ALARM MIB defines: 1980 - a mechanism for expressing state transition models for persistent 1981 problem states, 1982 - a mechanism to correlate a notification with subsequent state 1983 transition notifications about the same entity/object, and 1984 - a generic alarm reporting mechanism (extends ITU-T work on X.733 1985 [ITU-X733]). 1987 [RFC3878] in particular defines objects for controlling the reporting 1988 of alarm conditions and extends ITU-T work on M.3100 Amendment 3 1989 [ITU-M3100]. 1991 Other MIB modules that may be applied to fault management with SNMP 1992 include: 1994 o NOTIFICATION-LOG-MIB [RFC3014] describes managed objects used for 1995 logging SNMP Notifications. 1997 o ENTITY-STATE-MIB [RFC4268] describes extensions to the Entity MIB 1998 to provide information about the state of physical entities. 2000 o ENTITY-SENSOR-MIB [RFC3433] describes managed objects for 2001 extending the Entity MIB to provide generalized access to 2002 information related to physical sensors, which are often found in 2003 networking equipment (such as chassis temperature, fan RPM, power 2004 supply voltage). 2006 The SYSLOG protocol document [RFC5424] defines an initial set of 2007 Structured Data Elements (SDEs) that relate to content time quality, 2008 content origin, and meta-information about the message, such as 2009 language. Proprietary SDEs can be used to supplement the IETF- 2010 defined SDEs. 2012 The IETF has standardized MIB Textual-Conventions for facility and 2013 severity labels and codes to encourage consistency between SYSLOG and 2014 MIB representations of these event properties [RFC5427]. The intent 2015 is that these textual conventions will be imported and used in MIB 2016 modules that would otherwise define their own representations. 2018 An IPFIX MIB module [RFC5815] has been defined for monitoring IPFIX 2019 meters, exporters and collectors (see Section 2.3). The ongoing work 2020 on PSAMP MIB module extends the IPFIX MIB modules by managed objects 2021 for monitoring PSAMP implementations [I-D.ietf-ipfix-psamp-mib]. 2023 The NETCONF working group defined the data model necessary to monitor 2024 the NETCONF protocol [RFC6022] with the modeling language YANG. The 2025 monitoring data model includes information about NETCONF datastores, 2026 sessions, locks, and statistics, which facilitate the management of a 2027 NETCONF server. NETCONF monitoring document also defines methods for 2028 NETCONF clients to discover the data models supported by a NETCONF 2029 server and defines the operation to retrieve them. 2031 4.2.2. Configuration Management 2033 Configuration management focuses on establishing and maintaining 2034 consistency of a system and defines the functionality to configure 2035 its functional and physical attributes as well as operational 2036 information throughout its life. Configuration management includes 2037 configuration of network devices, inventory management, and software 2038 management. The data models below can be used to utilize 2039 configuration management. 2041 MIB modules for monitoring of network configuration (e.g. for 2042 physical and logical network topologies) already exist and provide 2043 some of the desired capabilities. New MIB modules might be developed 2044 for the target functionality to allow operators to monitor and modify 2045 the operational parameters, such as timer granularity, event 2046 reporting thresholds, target addresses, etc. 2048 [RFC3418], part of [STD62], contains objects in the system group 2049 useful e.g. for identifying the type of device, and the location of 2050 the device, the person responsible for the device. The SNMPv3 2051 standard [STD62] furthermore includes objects designed for 2052 configuring principals, access control rules, notification 2053 destinations, and for configuring proxy-forwarding SNMP agents, which 2054 can be used to forward messages through firewalls and Network Address 2055 Translation (NAT) devices. 2057 The Entity MIB [RFC4133] supports mainly inventory management and is 2058 used for managing multiple logical and physical entities matched to a 2059 single SNMP agent. This module provides a useful mechanism for 2060 identifying the entities comprising a system and defines event 2061 notifications for configuration changes that may be useful to 2062 management applications. 2064 [RFC3165] defines a set of managed objects that enable the delegation 2065 of management scripts to distributed managers. 2067 For configuring IPFIX and PSMAP devices, the IPFIX working group 2068 developed the IPFIX configuration data model [I-D.ietf-ipfix- 2069 configuration-model], by using the YANG modeling language and in 2070 close collaboration with the NETMOD working group (see 2071 Section 2.4.2). The model specifies the necessary data for 2072 configuring and monitoring selection processes, caches, exporting 2073 processes, and collecting processes of IPFIX and PSAMP compliant 2074 monitoring devices. 2076 At the time of this writing the NETMOD working group is developing 2077 core system and interface models in YANG. 2079 The CAPWAP protocol exchanges Type Length Values (TLV). The base 2080 TLVs are specified in [RFC5415], while the TLVs for IEEE 802.11 are 2081 specified in [RFC5416]. CAPWAP Base MIB [RFC5833] specifies managed 2082 objects for modeling the CAPWAP Protocol and provides configuration 2083 and WTP status-monitoring aspects of CAPWAP, where CAPWAP Binding MIB 2084 [RFC5834] defines managed objects for modeling of CAPWAP protocol for 2085 IEEE 802.11 wireless binding. 2086 Note: RFC 5833 and RFC 5834 have been published as Informational RFCs 2087 to provide the basis for future work on a SNMP management of the 2088 CAPWAP protocol. 2090 4.2.3. Accounting Management 2092 Accounting management collects usage information of network 2093 resources. Note that IETF does not define any mechanisms related to 2094 billing and charging. Many technology specific MIBs (link layer, 2095 network layer, transport layer or application layer) contain counters 2096 but are not primarily targeted for accounting, and therefore not 2097 included in this section. 2099 [RFC4670] 'RADIUS Accounting Client MIB for IPv6' defines RADIUS 2100 Accounting Client MIB objects that support version-neutral IP 2101 addressing formats. 2103 [RFC4671] 'RADIUS Accounting Server MIB for IPv6' defines RADIUS 2104 Accounting Server MIB objects that support version-neutral IP 2105 addressing formats. 2107 IPFIX/PSAMP Information Elements: 2109 As expressed in Section 2.3, the IPFIX architecture [RFC5470] defines 2110 components involved in IP flow measurement and reporting of 2111 information on IP flows. As such, IPFIX records provide fine-grained 2112 measurement data for flexible and detailed usage reporting and enable 2113 usage-based accounting. 2115 The IPFIX Information Elements (IE) have been initially defined in 2116 the IPFIX Information Model [RFC5102] and registered at the IANA 2117 [IANA-IPFIX]. The IPFIX IEs are composed of two types: 2119 o IEs related to identification of IP flows such as header 2120 information, derived packet properties, IGP and BGP next hop IP 2121 address, BGP AS, etc., and 2123 o IEs related to counter and timestamps, such as per-flow counters 2124 (e.g. octet count, packet count), flow start times, flow end 2125 times, and flow duration, etc. 2127 The Information Elements specified in the IPFIX information model 2128 [RFC5102] are used by the PSAMP protocol where applicable. Packet 2129 Sampling (PSAMP) Parameters defined in the PSAMP protocol 2130 specification are registered at [IANA-PSAMP]. An additional set of 2131 PSAMP Information Elements for reporting packet information with the 2132 IPFIX/PSAMP protocol such as Sampling-related IEs are specified in 2133 the PSAMP Information Model [RFC5477]. These IEs fulfill the 2134 requirements on reporting of different sampling and filtering 2135 techniques specified in [RFC5475]. 2137 4.2.4. Performance Management 2139 Performance management covers a set of functions that evaluate and 2140 report the performance of network elements and the network, with the 2141 goal to maintain the overall network performance at a defined level. 2142 Performance management functionality includes monitoring and 2143 measurement of network performance parameters, gathering statistical 2144 information, maintaining and examining activity logs. The data 2145 models below can be used for performance management tasks. 2147 The RMON (Remote Network Monitoring) MIB [STD59][RFC2819] defines 2148 objects for collecting data related to network performance and 2149 traffic from remote monitoring devices. An organization may employ 2150 many remote monitoring probes, one per network segment, to monitor 2151 its network. These devices may be used by a network service provider 2152 to access a client network, often geographically remote. Most of the 2153 objects in the RMON MIB module are suitable for the monitoring of any 2154 type of network, while some of them are specific to the monitoring of 2155 Ethernet networks. 2157 RMON allows a probe to be configured to perform diagnostics and to 2158 collect network statistics continuously, even when communication with 2159 the management station may not be possible or efficient. The alarm 2160 group periodically takes statistical samples from variables in the 2161 probe and compares them to previously configured thresholds. If the 2162 monitored variable crosses a threshold, an event is generated. 2164 [RFC3577] 'Introduction to the Remote Monitoring (RMON) Family of MIB 2165 Modules' describes the documents associated with the RMON framework 2166 and how they relate to each other. 2168 The RMON-2 MIB [RFC4502] extends RMON by providing RMON analysis up 2169 to the application layer and defines performance data to monitor. 2170 The SMON MIB [RFC2613] extends RMON by providing RMON analysis for 2171 switched networks. 2173 RMON MIB Extensions for High Capacity Alarms [RFC3434] describes 2174 managed objects for extending the alarm thresholding capabilities 2175 found in the RMON MIB and provides similar threshold monitoring of 2176 objects based on the Counter64 data type. 2178 RMON MIB Extensions for High Capacity Networks [RFC3273] defines 2179 objects for managing RMON devices for use on high-speed networks. 2181 RMON MIB Extensions for Interface Parameters Monitoring [RFC3144] 2182 describes an extension to the RMON MIB with a method of sorting the 2183 interfaces of a monitored device according to values of parameters 2184 specific to this interface. 2186 [RFC4710] describes Real-Time Application Quality of Service 2187 Monitoring (RAQMON), which is part of the RMON protocol family. 2188 RAQMON supports end-to-end QoS monitoring for multiple concurrent 2189 applications and does not relate to a specific application transport. 2190 RAQMON is scalable and works well with encrypted payload and 2191 signaling. RAQMON uses TCP to transport RAQMON PDUs. 2193 [RFC4711] proposes an extension to the Remote Monitoring MIB 2194 [STD59][RFC2819] and describes managed objects used for RAQMON. 2195 [RFC4712] specifies two transport mappings for the RAQMON information 2196 model using TCP as a native transport and SNMP to carry the RAQMON 2197 information from a RAQMON Data Source (RDS) to a RAQMON Report 2198 Collector (RRC). 2200 Application Performance Measurement MIB [RFC3729] uses the 2201 architecture created in the RMON MIB and defines objects by providing 2202 measurement and analysis of the application performance as 2203 experienced by end-users. [RFC3729] enables the measurement of the 2204 quality of service delivered to end-users by applications. 2206 Transport Performance Metrics MIB [RFC4150] describes managed objects 2207 used for monitoring selectable performance metrics and statistics 2208 derived from the monitoring of network packets and sub-application 2209 level transactions. The metrics can be defined through reference to 2210 existing IETF, ITU, and other standards organizations' documents. 2212 The IPPM working group has defined [RFC4148] "IP Performance Metrics 2213 (IPPM) Metrics Registry". Note that with the publication of 2214 [RFC6248], [RFC4148] and the corresponding IANA registry for IPPM 2215 metrics have been declared Obsolete and shouldn't be used. 2217 The IPPM working group defined an Information Model and XML Data 2218 Model for Traceroute Measurements [RFC5388], which defines a common 2219 information model dividing the information elements into two 2220 semantically separated groups (configuration elements and results 2221 elements) with an additional element to relate configuration elements 2222 and results elements by means of a common unique identifier. Based 2223 on the information model, an XML data model is provided to store the 2224 results of traceroute measurements. 2226 SIP Package for Voice Quality Reporting [RFC6035] defines a SIP event 2227 package that enables the collection and reporting of metrics that 2228 measure the quality for Voice over Internet Protocol (VoIP) sessions. 2230 4.2.5. Security Management 2232 The security management provides the set of functions to protect the 2233 network and system from unauthorized access and includes functions 2234 such as creating, deleting, and controlling security services and 2235 mechanisms; key management, reporting security-relevant events, and 2236 authorizing user access and privileges. Based on their support for 2237 authentication and authorization, RADIUS and DIAMETER are seen as 2238 security management protocols. The data models below can be used to 2239 utilize security management. 2241 [RFC3414], part of [STD62], specifies the procedures for providing 2242 SNMPv3 message level security and includes a MIB module for remotely 2243 monitoring and managing the configuration parameters for the USM 2244 security model. 2246 [RFC3415], part of [STD62], describes the procedures for controlling 2247 access to management information in the SNMPv3 architecture and 2248 includes a MIB module, which defines managed objects to access 2249 portions of an SNMP engine's Local Configuration Datastore (LCD). As 2250 such, this MIB module enables remote management of the configuration 2251 parameters of the View-based Access Control Model. 2253 NETCONF Access Control Model (NACM) [RFC6536] addresses the need for 2254 access control mechanisms for the operation and content layers of 2255 NETCONF, as defined in [RFC6241]. As such NACM proposes standard 2256 mechanisms to restrict NETCONF protocol access for particular users 2257 to a pre-configured subset of all available NETCONF protocol 2258 operations and content within a particular server. 2260 There are numerous MIB modules defined for multiple purposes to use 2261 with RADIUS: 2263 o [RFC4668] 'RADIUS Authentication Client MIB for IPv6' defines 2264 RADIUS Authentication Client MIB objects that support version- 2265 neutral IP addressing formats and defines a set of extensions for 2266 RADIUS authentication client functions. 2268 o [RFC4669] 'RADIUS Authentication Server MIB for IPv6' defines 2269 RADIUS Authentication Server MIB objects that support version- 2270 neutral IP addressing formats and defines a set of extensions for 2271 RADIUS authentication server functions. 2273 o [RFC4672] 'RADIUS Dynamic Authorization Client MIB' defines the 2274 MIB module for entities implementing the client side of the 2275 Dynamic Authorization Extensions to RADIUS [RFC5176]. 2277 o [RFC4673] 'RADIUS Dynamic Authorization Server MIB' defines the 2278 MIB module for entities implementing the server side of the 2279 Dynamic Authorization Extensions to RADIUS [RFC5176]. 2281 The MIB Module definitions in [RFC4668], [RFC4669], [RFC4672], 2282 [RFC4673] are intended to be used only for RADIUS over UDP and do not 2283 support RADIUS over TCP. There is also a recommendation that RADIUS 2284 clients and servers implementing RADIUS over TCP should not reuse 2285 earlier listed MIB modules to perform statistics counting for RADIUS 2286 over TCP connections. 2288 Currently there are no standardized MIB modules for DIAMETER 2289 applications, which can be considered as a lack on the management 2290 side of DIAMETER nodes. There are ongoing efforts to produce 2291 standard MIBs for the 'Diameter Base Protocol' and the 'Diameter 2292 Credit-Control Application'. 2294 5. IANA Considerations 2296 This document does not introduce any new code-points or namespaces 2297 for registration with IANA. 2299 Note to RFC Editor: this section may be removed on publication as an 2300 RFC. 2302 6. Security Considerations 2304 This document gives an overview of IETF network management standards 2305 and summarizes existing and ongoing development of IETF standards- 2306 track network management protocols and data models. As such it does 2307 not have any security implications in or of itself. 2309 For each specific technology discussed in the document a summary of 2310 its security usage has been given in corresponding chapters. In a 2311 few cases, e.g. for SNMP, a detailed description of developed 2312 security mechanisms has been provided. 2314 The attention of the reader is particularly drawn to the security 2315 discussion in following document sections: 2317 o SNMP Security and Access Control Models in Section 2.1.4.1, 2319 o User-Based Security Model (USM) in Section 2.1.4.2, 2321 o View-Based Access Control Model (VACM) in Section 2.1.4.3, 2323 o SNMP Transport Security Model in Section 2.1.5.1, 2325 o Secure SYSLOG message delivery in Section 2.2, 2327 o Use of secure NETCONF message transport and the NETCONF Access 2328 Control Model (NACM) in Section 2.4.1, 2330 o Message authentication for Dynamic Host Configuration Protocol 2331 (DHCP) in Section 3.1.1, 2333 o Security for Remote Authentication Dial In User Service (RADIUS) 2334 in conjunction with EAP and IEEE 802.1X authenticators in 2335 Section 3.5, 2337 o Built in and transport security for Diameter Base Protocol 2338 (DIAMETER) in Section 3.6, 2340 o Transport security for Control And Provisioning of Wireless Access 2341 Points (CAPWAP) in Section 3.7, 2343 o Built in security for Access Node Control Protocol (ANCP) in 2344 Section 3.8, 2346 o Security for Application Configuration Access Protocol (ACAP) in 2347 Section 3.9, 2349 o Security for XML Configuration Access Protocol (XCAP) in 2350 Section 3.10, and 2352 o Data models for the Security Management in Section 4.2.5. 2354 The authors would like to refer also to detailed security 2355 consideration sections for specific management standards described in 2356 this document, which contain comprehensive discussion of security 2357 implications of the particular management protocols and mechanisms. 2358 Among others security consideration sections of following documents 2359 should be carefully read before implementing the technology. 2361 o For SNMP security in general, subsequent security consideration 2362 sections in [STD62], which includes RFCs 3411-3418, 2364 o Security consideration section in Section 8. of [BCP74] for the 2365 coexistence between SNMP v1, v2, and v3, 2367 o Security considerations for the SNMP Transport Security Model in 2368 Section 8. of [RFC5591], 2370 o Security considerations for the Secure Shell Transport Model for 2371 SNMP in Section 9 of [RFC5592], 2373 o Security considerations for the TLS Transport Model for SNMP in 2374 Section 9. of [RFC6353], 2376 o Security considerations for the TLS Transport Mapping for Syslog 2377 in Section 6 of [RFC5425], 2379 o Security considerations for the IPFIX Protocol Specification in 2380 Section 11. of [RFC5101], 2382 o Security considerations for the NETCONF protocol in Section 9. of 2383 [RFC6241] and the SSH transport in Section 6. of [RFC6242], 2385 o Security considerations for the NETCONF Access Control Model 2386 (NACM) in Section 3.7. of [RFC6536], 2388 o Security considerations for DHCPv4 and DHCPv6 in Section 7. of 2389 [RFC2131] and Section 23. of [RFC3315], 2391 o Security considerations for RADIUS in Section 8. of [RFC2865], 2393 o Security considerations for DIAMETER in Section 13. of [RFC3588], 2395 o Security considerations for the CAPWAP protocol in Section 12. of 2396 [RFC5415], 2398 o Security considerations for the ANCP protocol in Section 11. of 2399 [RFC6320], and 2401 o Security considerations for the XCAP protocol in Section 14. of 2402 [RFC4825]. 2404 7. Contributors 2406 Following persons made significant contributions to and reviewed this 2407 document: 2409 o Ralph Droms (Cisco) - revised the section on IP address management 2410 and DHCP. 2412 o Jouni Korhonen (Nokia Siemens Networks) - contributed the sections 2413 on RADIUS and DIAMETER. 2415 o Al Morton (AT&T) - contributed to the section on IP Performance 2416 Metrics. 2418 o Juergen Quittek (NEC) - contributed the section on IPFIX/PSAMP. 2420 o Juergen Schoenwaelder (Jacobs University Bremen) - contributed the 2421 sections on IETF Network Management Data Models and YANG. 2423 8. Acknowledgements 2425 The editor would like to thank to Fred Baker, Alex Clemm, Miguel A. 2426 Garcia, Simon Leinen, Christopher Liljenstolpe, Tom Petch, Randy 2427 Presuhn, Dan Romascanu, Juergen Schoenwaelder, Tina Tsou, and Henk 2428 Uijterwaal, for their valuable suggestions, comments in the OPSAWG 2429 sessions and mailing list. 2431 The editor would like to especially thank Dave Harrington, who 2432 created the document "Survey of IETF Network Management Standards" a 2433 few years ago, which has been used as a starting point and enhanced 2434 with a special focus on the description of the IETF network 2435 management standards and management data models. 2437 9. Informative References 2439 [3GPPEPC] 3GPP, "Access to the 3GPP 2440 Evolved Packet Core (EPC) 2441 via non-3GPP access 2442 networks", December 2010, 2443 . 2447 [3GPPIMS] 3GPP, "Release 10, IP 2448 Multimedia Subsystem 2449 (IMS); Stage 2", 2450 September 2010, . 2454 [BCP170] Clark, A. and B. Claise, 2455 "Guidelines for 2456 Considering New 2457 Performance Metric 2458 Development", 2459 October 2011. 2461 [BCP27] D. O'Dell, M., 2462 "Advancement of MIB 2463 specifications on the 2464 IETF Standards Track", 2465 October 1998. 2467 [BCP74] Frye, R., "Coexistence 2468 between Version 1, 2469 Version 2, and Version 3 2470 of the Internet-standard 2471 Network Management 2472 Framework", August 2003. 2474 [DMTF-CIM] DMTF, "Common Information 2475 Model Schema, Version 2476 2.27.0", November 2010, < 2477 http://www.dmtf.org/ 2478 standards/cim>. 2480 [FCAPS] International 2481 Telecommunication Union, 2482 "X.700: Management 2483 Framework For Open 2484 Systems Interconnection 2485 (OSI) For CCITT 2486 Applications", 2487 September 1992, . 2491 [I-D.ietf-dime-rfc3588bis] Fajardo, V., Arkko, J., 2492 Loughney, J., and G. 2493 Zorn, "Diameter Base 2494 Protocol", draft-ietf- 2495 dime-rfc3588bis-31 (work 2496 in progress), March 2012. 2498 [I-D.ietf-ipfix-configuration-model] Muenz, G., Claise, B., 2499 and P. Aitken, 2500 "Configuration Data Model 2501 for IPFIX and PSAMP", dra 2502 ft-ietf-ipfix- 2503 configuration-model-10 2504 (work in progress), 2505 July 2011. 2507 [I-D.ietf-ipfix-export-per-sctp-stream] Claise, B., Aitken, P., 2508 Johnson, A., and G. 2509 Muenz, "IPFIX Export per 2510 SCTP Stream", draft-ietf- 2511 ipfix-export-per-sctp- 2512 stream-08 (work in 2513 progress), June 2010. 2515 [I-D.ietf-ipfix-psamp-mib] Dietz, T., Claise, B., 2516 and J. Quittek, 2517 "Definitions of Managed 2518 Objects for Packet 2519 Sampling", draft-ietf- 2520 ipfix-psamp-mib-04 (work 2521 in progress), 2522 October 2011. 2524 [I-D.ietf-mpls-tp-mib-management-overview] King, D. and V. 2525 Mahalingam, 2526 "Multiprotocol Label 2527 Switching Transport 2528 Profile (MPLS-TP) MIB- 2529 based Management 2530 Overview", draft-ietf- 2531 mpls-tp-mib-management- 2532 overview-07 (work in 2533 progress), March 2012. 2535 [I-D.ietf-mpls-tp-oam-analysis] Sprecher, N. and L. Fang, 2536 "An Overview of the OAM 2537 Tool Set for MPLS based 2538 Transport Networks", draf 2539 t-ietf-mpls-tp-oam- 2540 analysis-08 (work in 2541 progress), March 2012. 2543 [I-D.ietf-opsawg-oam-overview] Mizrahi, T., Sprecher, 2544 N., Bellagamba, E., and 2545 Y. Weingarten, "An 2546 Overview of Operations, 2547 Administration, and 2548 Maintenance (OAM) 2549 Mechanisms", draft-ietf- 2550 opsawg-oam-overview-06 2551 (work in progress), 2552 March 2012. 2554 [I-D.weil-shared-transition-space-request] Weil, J., Kuarsingh, V., 2555 Donley, C., Liljenstolpe, 2556 C., and M. Azinger, "IANA 2557 Reserved IPv4 Prefix for 2558 Shared Address Space", dr 2559 aft-weil-shared- 2560 transition-space-request- 2561 15 (work in progress), 2562 February 2012. 2564 [IANA-AAA] Internet Assigned Numbers 2565 Authority, "IANA AAA 2566 Parameters", June 2011, < 2567 http://www.iana.org/ 2568 assignments/ 2569 aaa-parameters/ 2570 aaa-parameters.xml>. 2572 [IANA-IPFIX] Internet Assigned Numbers 2573 Authority, "IANA IPFIX 2574 Information Elements", 2575 February 2011, . 2579 [IANA-PROT] Internet Assigned Numbers 2580 Authority, "IANA Protocol 2581 Registries", 2582 October 2010, . 2585 [IANA-PSAMP] Internet Assigned Numbers 2586 Authority, "IANA PSAMP 2587 Parameters", April 2009, 2588 . 2593 [IETF-WGS] IETF, "IETF Working 2594 Groups", . 2598 [ITU-M3100] International 2599 Telecommunication Union, 2600 "M.3100: Generic network 2601 information model", 2602 January 2006, . 2606 [ITU-X680] International 2607 Telecommunication Union, 2608 "X.680: Abstract Syntax 2609 Notation One (ASN.1): 2610 Specification of basic 2611 notation", July 2002, . 2617 [ITU-X733] International 2618 Telecommunication Union, 2619 "X.733: Systems 2620 Management: Alarm 2621 Reporting Function", 2622 October 1992, . 2626 [RELAX-NG] OASIS, "RELAX NG 2627 Specification, Committee 2628 Specification 3 December 2629 2001", December 2001, . 2634 [RFC0951] Croft, B. and J. Gilmore, 2635 "Bootstrap Protocol", 2636 RFC 951, September 1985. 2638 [RFC1021] Partridge, C. and G. 2639 Trewitt, "High-level 2640 Entity Management System 2641 (HEMS)", RFC 1021, 2642 October 1987. 2644 [RFC1155] Rose, M. and K. 2645 McCloghrie, "Structure 2646 and identification of 2647 management information 2648 for TCP/IP-based 2649 internets", STD 16, 2650 RFC 1155, May 1990. 2652 [RFC1157] Case, J., Fedor, M., 2653 Schoffstall, M., and J. 2654 Davin, "Simple Network 2655 Management Protocol 2656 (SNMP)", STD 15, 2657 RFC 1157, May 1990. 2659 [RFC1212] Rose, M. and K. 2660 McCloghrie, "Concise MIB 2661 definitions", STD 16, 2662 RFC 1212, March 1991. 2664 [RFC1215] Rose, M., "Convention for 2665 defining traps for use 2666 with the SNMP", RFC 1215, 2667 March 1991. 2669 [RFC1321] Rivest, R., "The MD5 2670 Message-Digest 2671 Algorithm", RFC 1321, 2672 April 1992. 2674 [RFC1470] Enger, R. and J. 2675 Reynolds, "FYI on a 2676 Network Management Tool 2677 Catalog: Tools for 2678 Monitoring and Debugging 2679 TCP/IP Internets and 2680 Interconnected Devices", 2681 RFC 1470, June 1993. 2683 [RFC1901] Case, J., McCloghrie, K., 2684 McCloghrie, K., Rose, M., 2685 and S. Waldbusser, 2686 "Introduction to 2687 Community-based SNMPv2", 2688 RFC 1901, January 1996. 2690 [RFC2026] Bradner, S., "The 2691 Internet Standards 2692 Process -- Revision 3", 2693 BCP 9, RFC 2026, 2694 October 1996. 2696 [RFC2127] Roeck, G., "ISDN 2697 Management Information 2698 Base using SMIv2", 2699 RFC 2127, March 1997. 2701 [RFC2131] Droms, R., "Dynamic Host 2702 Configuration Protocol", 2703 RFC 2131, March 1997. 2705 [RFC2195] Klensin, J., Catoe, R., 2706 and P. Krumviede, "IMAP/ 2707 POP AUTHorize Extension 2708 for Simple Challenge/ 2709 Response", RFC 2195, 2710 September 1997. 2712 [RFC2244] Newman, C. and J. Myers, 2713 "ACAP -- Application 2714 Configuration Access 2715 Protocol", RFC 2244, 2716 November 1997. 2718 [RFC2287] Krupczak, C. and J. 2719 Saperia, "Definitions of 2720 System-Level Managed 2721 Objects for 2722 Applications", RFC 2287, 2723 February 1998. 2725 [RFC2330] Paxson, V., Almes, G., 2726 Mahdavi, J., and M. 2727 Mathis, "Framework for IP 2728 Performance Metrics", 2729 RFC 2330, May 1998. 2731 [RFC2458] Lu, H., Krishnaswamy, M., 2732 Conroy, L., Bellovin, S., 2733 Burg, F., DeSimone, A., 2734 Tewani, K., Davidson, P., 2735 Schulzrinne, H., and K. 2736 Vishwanathan, "Toward the 2737 PSTN/Internet Inter- 2738 Networking --Pre-PINT 2739 Implementations", 2740 RFC 2458, November 1998. 2742 [RFC2515] Tesink, K., "Definitions 2743 of Managed Objects for 2744 ATM Management", 2745 RFC 2515, February 1999. 2747 [RFC2564] Kalbfleisch, C., 2748 Krupczak, C., Presuhn, 2749 R., and J. Saperia, 2750 "Application Management 2751 MIB", RFC 2564, May 1999. 2753 [RFC2578] McCloghrie, K., Ed., 2754 Perkins, D., Ed., and J. 2755 Schoenwaelder, Ed., 2756 "Structure of Management 2757 Information Version 2 2758 (SMIv2)", STD 58, 2759 RFC 2578, April 1999. 2761 [RFC2579] McCloghrie, K., Ed., 2762 Perkins, D., Ed., and J. 2763 Schoenwaelder, Ed., 2764 "Textual Conventions for 2765 SMIv2", STD 58, RFC 2579, 2766 April 1999. 2768 [RFC2580] McCloghrie, K., Perkins, 2769 D., and J. Schoenwaelder, 2770 "Conformance Statements 2771 for SMIv2", STD 58, 2772 RFC 2580, April 1999. 2774 [RFC2610] Perkins, C. and E. 2775 Guttman, "DHCP Options 2776 for Service Location 2777 Protocol", RFC 2610, 2778 June 1999. 2780 [RFC2613] Waterman, R., Lahaye, B., 2781 Romascanu, D., and S. 2782 Waldbusser, "Remote 2783 Network Monitoring MIB 2784 Extensions for Switched 2785 Networks Version 1.0", 2786 RFC 2613, June 1999. 2788 [RFC2617] Franks, J., Hallam-Baker, 2789 P., Hostetler, J., 2790 Lawrence, S., Leach, P., 2791 Luotonen, A., and L. 2792 Stewart, "HTTP 2793 Authentication: Basic and 2794 Digest Access 2795 Authentication", 2796 RFC 2617, June 1999. 2798 [RFC2678] Mahdavi, J. and V. 2799 Paxson, "IPPM Metrics for 2800 Measuring Connectivity", 2801 RFC 2678, September 1999. 2803 [RFC2679] Almes, G., Kalidindi, S., 2804 and M. Zekauskas, "A One- 2805 way Delay Metric for 2806 IPPM", RFC 2679, 2807 September 1999. 2809 [RFC2680] Almes, G., Kalidindi, S., 2810 and M. Zekauskas, "A One- 2811 way Packet Loss Metric 2812 for IPPM", RFC 2680, 2813 September 1999. 2815 [RFC2681] Almes, G., Kalidindi, S., 2816 and M. Zekauskas, "A 2817 Round-trip Delay Metric 2818 for IPPM", RFC 2681, 2819 September 1999. 2821 [RFC2748] Durham, D., Boyle, J., 2822 Cohen, R., Herzog, S., 2823 Rajan, R., and A. Sastry, 2824 "The COPS (Common Open 2825 Policy Service) 2826 Protocol", RFC 2748, 2827 January 2000. 2829 [RFC2753] Yavatkar, R., Pendarakis, 2830 D., and R. Guerin, "A 2831 Framework for Policy- 2832 based Admission Control", 2833 RFC 2753, January 2000. 2835 [RFC2818] Rescorla, E., "HTTP Over 2836 TLS", RFC 2818, May 2000. 2838 [RFC2819] Waldbusser, S., "Remote 2839 Network Monitoring 2840 Management Information 2841 Base", STD 59, RFC 2819, 2842 May 2000. 2844 [RFC2863] McCloghrie, K. and F. 2845 Kastenholz, "The 2846 Interfaces Group MIB", 2847 RFC 2863, June 2000. 2849 [RFC2865] Rigney, C., Willens, S., 2850 Rubens, A., and W. 2851 Simpson, "Remote 2852 Authentication Dial In 2853 User Service (RADIUS)", 2854 RFC 2865, June 2000. 2856 [RFC2866] Rigney, C., "RADIUS 2857 Accounting", RFC 2866, 2858 June 2000. 2860 [RFC2867] Zorn, G., Aboba, B., and 2861 D. Mitton, "RADIUS 2862 Accounting Modifications 2863 for Tunnel Protocol 2864 Support", RFC 2867, 2865 June 2000. 2867 [RFC2868] Zorn, G., Leifer, D., 2868 Rubens, A., Shriver, J., 2869 Holdrege, M., and I. 2871 Goyret, "RADIUS 2872 Attributes for Tunnel 2873 Protocol Support", 2874 RFC 2868, June 2000. 2876 [RFC2869] Rigney, C., Willats, W., 2877 and P. Calhoun, "RADIUS 2878 Extensions", RFC 2869, 2879 June 2000. 2881 [RFC2981] Kavasseri, R., "Event 2882 MIB", RFC 2981, 2883 October 2000. 2885 [RFC2982] Kavasseri, R., 2886 "Distributed Management 2887 Expression MIB", 2888 RFC 2982, October 2000. 2890 [RFC3014] Kavasseri, R., 2891 "Notification Log MIB", 2892 RFC 3014, November 2000. 2894 [RFC3046] Patrick, M., "DHCP Relay 2895 Agent Information 2896 Option", RFC 3046, 2897 January 2001. 2899 [RFC3084] Chan, K., Seligson, J., 2900 Durham, D., Gai, S., 2901 McCloghrie, K., Herzog, 2902 S., Reichmeyer, F., 2903 Yavatkar, R., and A. 2904 Smith, "COPS Usage for 2905 Policy Provisioning 2906 (COPS-PR)", RFC 3084, 2907 March 2001. 2909 [RFC3144] Romascanu, D., "Remote 2910 Monitoring MIB Extensions 2911 for Interface Parameters 2912 Monitoring", RFC 3144, 2913 August 2001. 2915 [RFC3159] McCloghrie, K., Fine, M., 2916 Seligson, J., Chan, K., 2917 Hahn, S., Sahita, R., 2918 Smith, A., and F. 2920 Reichmeyer, "Structure of 2921 Policy Provisioning 2922 Information (SPPI)", 2923 RFC 3159, August 2001. 2925 [RFC3162] Aboba, B., Zorn, G., and 2926 D. Mitton, "RADIUS and 2927 IPv6", RFC 3162, 2928 August 2001. 2930 [RFC3164] Lonvick, C., "The BSD 2931 Syslog Protocol", 2932 RFC 3164, August 2001. 2934 [RFC3165] Levi, D. and J. 2935 Schoenwaelder, 2936 "Definitions of Managed 2937 Objects for the 2938 Delegation of Management 2939 Scripts", RFC 3165, 2940 August 2001. 2942 [RFC3195] New, D. and M. Rose, 2943 "Reliable Delivery for 2944 syslog", RFC 3195, 2945 November 2001. 2947 [RFC3273] Waldbusser, S., "Remote 2948 Network Monitoring 2949 Management Information 2950 Base for High Capacity 2951 Networks", RFC 3273, 2952 July 2002. 2954 [RFC3315] Droms, R., Bound, J., 2955 Volz, B., Lemon, T., 2956 Perkins, C., and M. 2957 Carney, "Dynamic Host 2958 Configuration Protocol 2959 for IPv6 (DHCPv6)", 2960 RFC 3315, July 2003. 2962 [RFC3319] Schulzrinne, H. and B. 2963 Volz, "Dynamic Host 2964 Configuration Protocol 2965 (DHCPv6) Options for 2966 Session Initiation 2967 Protocol (SIP) Servers", 2968 RFC 3319, July 2003. 2970 [RFC3393] Demichelis, C. and P. 2971 Chimento, "IP Packet 2972 Delay Variation Metric 2973 for IP Performance 2974 Metrics (IPPM)", 2975 RFC 3393, November 2002. 2977 [RFC3410] Case, J., Mundy, R., 2978 Partain, D., and B. 2979 Stewart, "Introduction 2980 and Applicability 2981 Statements for Internet- 2982 Standard Management 2983 Framework", RFC 3410, 2984 December 2002. 2986 [RFC3411] Harrington, D., Presuhn, 2987 R., and B. Wijnen, "An 2988 Architecture for 2989 Describing Simple Network 2990 Management Protocol 2991 (SNMP) Management 2992 Frameworks", STD 62, 2993 RFC 3411, December 2002. 2995 [RFC3413] Levi, D., Meyer, P., and 2996 B. Stewart, "Simple 2997 Network Management 2998 Protocol (SNMP) 2999 Applications", STD 62, 3000 RFC 3413, December 2002. 3002 [RFC3414] Blumenthal, U. and B. 3003 Wijnen, "User-based 3004 Security Model (USM) for 3005 version 3 of the Simple 3006 Network Management 3007 Protocol (SNMPv3)", 3008 STD 62, RFC 3414, 3009 December 2002. 3011 [RFC3415] Wijnen, B., Presuhn, R., 3012 and K. McCloghrie, "View- 3013 based Access Control 3014 Model (VACM) for the 3015 Simple Network Management 3016 Protocol (SNMP)", STD 62, 3017 RFC 3415, December 2002. 3019 [RFC3417] Presuhn, R., "Transport 3020 Mappings for the Simple 3021 Network Management 3022 Protocol (SNMP)", STD 62, 3023 RFC 3417, December 2002. 3025 [RFC3418] Presuhn, R., "Management 3026 Information Base (MIB) 3027 for the Simple Network 3028 Management Protocol 3029 (SNMP)", STD 62, 3030 RFC 3418, December 2002. 3032 [RFC3430] Schoenwaelder, J., 3033 "Simple Network 3034 Management Protocol Over 3035 Transmission Control 3036 Protocol Transport 3037 Mapping", RFC 3430, 3038 December 2002. 3040 [RFC3432] Raisanen, V., Grotefeld, 3041 G., and A. Morton, 3042 "Network performance 3043 measurement with periodic 3044 streams", RFC 3432, 3045 November 2002. 3047 [RFC3433] Bierman, A., Romascanu, 3048 D., and K. Norseth, 3049 "Entity Sensor Management 3050 Information Base", 3051 RFC 3433, December 2002. 3053 [RFC3434] Bierman, A. and K. 3054 McCloghrie, "Remote 3055 Monitoring MIB Extensions 3056 for High Capacity 3057 Alarms", RFC 3434, 3058 December 2002. 3060 [RFC3444] Pras, A. and J. 3061 Schoenwaelder, "On the 3062 Difference between 3063 Information Models and 3064 Data Models", RFC 3444, 3065 January 2003. 3067 [RFC3460] Moore, B., "Policy Core 3068 Information Model (PCIM) 3069 Extensions", RFC 3460, 3070 January 2003. 3072 [RFC3535] Schoenwaelder, J., 3073 "Overview of the 2002 IAB 3074 Network Management 3075 Workshop", RFC 3535, 3076 May 2003. 3078 [RFC3574] Soininen, J., "Transition 3079 Scenarios for 3GPP 3080 Networks", RFC 3574, 3081 August 2003. 3083 [RFC3577] Waldbusser, S., Cole, R., 3084 Kalbfleisch, C., and D. 3085 Romascanu, "Introduction 3086 to the Remote Monitoring 3087 (RMON) Family of MIB 3088 Modules", RFC 3577, 3089 August 2003. 3091 [RFC3579] Aboba, B. and P. Calhoun, 3092 "RADIUS (Remote 3093 Authentication Dial In 3094 User Service) Support For 3095 Extensible Authentication 3096 Protocol (EAP)", 3097 RFC 3579, September 2003. 3099 [RFC3580] Congdon, P., Aboba, B., 3100 Smith, A., Zorn, G., and 3101 J. Roese, "IEEE 802.1X 3102 Remote Authentication 3103 Dial In User Service 3104 (RADIUS) Usage 3105 Guidelines", RFC 3580, 3106 September 2003. 3108 [RFC3588] Calhoun, P., Loughney, 3109 J., Guttman, E., Zorn, 3110 G., and J. Arkko, 3111 "Diameter Base Protocol", 3112 RFC 3588, September 2003. 3114 [RFC3589] Loughney, J., "Diameter 3115 Command Codes for Third 3116 Generation Partnership 3117 Project (3GPP) Release 3118 5", RFC 3589, 3119 September 2003. 3121 [RFC3606] Ly, F., Noto, M., Smith, 3122 A., Spiegel, E., and K. 3123 Tesink, "Definitions of 3124 Supplemental Managed 3125 Objects for ATM 3126 Interface", RFC 3606, 3127 November 2003. 3129 [RFC3633] Troan, O. and R. Droms, 3130 "IPv6 Prefix Options for 3131 Dynamic Host 3132 Configuration Protocol 3133 (DHCP) version 6", 3134 RFC 3633, December 2003. 3136 [RFC3646] Droms, R., "DNS 3137 Configuration options for 3138 Dynamic Host 3139 Configuration Protocol 3140 for IPv6 (DHCPv6)", 3141 RFC 3646, December 2003. 3143 [RFC3729] Waldbusser, S., 3144 "Application Performance 3145 Measurement MIB", 3146 RFC 3729, March 2004. 3148 [RFC3748] Aboba, B., Blunk, L., 3149 Vollbrecht, J., Carlson, 3150 J., and H. Levkowetz, 3151 "Extensible 3152 Authentication Protocol 3153 (EAP)", RFC 3748, 3154 June 2004. 3156 [RFC3758] Stewart, R., Ramalho, M., 3157 Xie, Q., Tuexen, M., and 3158 P. Conrad, "Stream 3159 Control Transmission 3160 Protocol (SCTP) Partial 3161 Reliability Extension", 3162 RFC 3758, May 2004. 3164 [RFC3868] Loughney, J., Sidebottom, 3165 G., Coene, L., Verwimp, 3166 G., Keller, J., and B. 3167 Bidulock, "Signalling 3168 Connection Control Part 3169 User Adaptation Layer 3170 (SUA)", RFC 3868, 3171 October 2004. 3173 [RFC3873] Pastor, J. and M. 3174 Belinchon, "Stream 3175 Control Transmission 3176 Protocol (SCTP) 3177 Management Information 3178 Base (MIB)", RFC 3873, 3179 September 2004. 3181 [RFC3877] Chisholm, S. and D. 3182 Romascanu, "Alarm 3183 Management Information 3184 Base (MIB)", RFC 3877, 3185 September 2004. 3187 [RFC3878] Lam, H., Huynh, A., and 3188 D. Perkins, "Alarm 3189 Reporting Control 3190 Management Information 3191 Base (MIB)", RFC 3878, 3192 September 2004. 3194 [RFC3917] Quittek, J., Zseby, T., 3195 Claise, B., and S. 3196 Zander, "Requirements for 3197 IP Flow Information 3198 Export (IPFIX)", 3199 RFC 3917, October 2004. 3201 [RFC3954] Claise, B., "Cisco 3202 Systems NetFlow Services 3203 Export Version 9", 3204 RFC 3954, October 2004. 3206 [RFC4004] Calhoun, P., Johansson, 3207 T., Perkins, C., Hiller, 3208 T., and P. McCann, 3209 "Diameter Mobile IPv4 3210 Application", RFC 4004, 3211 August 2005. 3213 [RFC4005] Calhoun, P., Zorn, G., 3214 Spence, D., and D. 3215 Mitton, "Diameter Network 3216 Access Server 3217 Application", RFC 4005, 3218 August 2005. 3220 [RFC4006] Hakala, H., Mattila, L., 3221 Koskinen, J-P., Stura, 3222 M., and J. Loughney, 3223 "Diameter Credit-Control 3224 Application", RFC 4006, 3225 August 2005. 3227 [RFC4022] Raghunarayan, R., 3228 "Management Information 3229 Base for the Transmission 3230 Control Protocol (TCP)", 3231 RFC 4022, March 2005. 3233 [RFC4029] Lind, M., Ksinant, V., 3234 Park, S., Baudot, A., and 3235 P. Savola, "Scenarios and 3236 Analysis for Introducing 3237 IPv6 into ISP Networks", 3238 RFC 4029, March 2005. 3240 [RFC4038] Shin, M-K., Hong, Y-G., 3241 Hagino, J., Savola, P., 3242 and E. Castro, 3243 "Application Aspects of 3244 IPv6 Transition", 3245 RFC 4038, March 2005. 3247 [RFC4057] Bound, J., "IPv6 3248 Enterprise Network 3249 Scenarios", RFC 4057, 3250 June 2005. 3252 [RFC4072] Eronen, P., Hiller, T., 3253 and G. Zorn, "Diameter 3254 Extensible Authentication 3255 Protocol (EAP) 3256 Application", RFC 4072, 3257 August 2005. 3259 [RFC4113] Fenner, B. and J. Flick, 3260 "Management Information 3261 Base for the User 3262 Datagram Protocol (UDP)", 3263 RFC 4113, June 2005. 3265 [RFC4118] Yang, L., Zerfos, P., and 3266 E. Sadot, "Architecture 3267 Taxonomy for Control and 3268 Provisioning of Wireless 3269 Access Points (CAPWAP)", 3270 RFC 4118, June 2005. 3272 [RFC4133] Bierman, A. and K. 3273 McCloghrie, "Entity MIB 3274 (Version 3)", RFC 4133, 3275 August 2005. 3277 [RFC4148] Stephan, E., "IP 3278 Performance Metrics 3279 (IPPM) Metrics Registry", 3280 BCP 108, RFC 4148, 3281 August 2005. 3283 [RFC4150] Dietz, R. and R. Cole, 3284 "Transport Performance 3285 Metrics MIB", RFC 4150, 3286 August 2005. 3288 [RFC4188] Norseth, K. and E. Bell, 3289 "Definitions of Managed 3290 Objects for Bridges", 3291 RFC 4188, September 2005. 3293 [RFC4213] Nordmark, E. and R. 3294 Gilligan, "Basic 3295 Transition Mechanisms for 3296 IPv6 Hosts and Routers", 3297 RFC 4213, October 2005. 3299 [RFC4215] Wiljakka, J., "Analysis 3300 on IPv6 Transition in 3301 Third Generation 3302 Partnership Project 3303 (3GPP) Networks", 3304 RFC 4215, October 2005. 3306 [RFC4221] Nadeau, T., Srinivasan, 3307 C., and A. Farrel, 3308 "Multiprotocol Label 3309 Switching (MPLS) 3310 Management Overview", 3311 RFC 4221, November 2005. 3313 [RFC4268] Chisholm, S. and D. 3314 Perkins, "Entity State 3315 MIB", RFC 4268, 3316 November 2005. 3318 [RFC4273] Haas, J. and S. Hares, 3319 "Definitions of Managed 3320 Objects for BGP-4", 3321 RFC 4273, January 2006. 3323 [RFC4280] Chowdhury, K., Yegani, 3324 P., and L. Madour, 3325 "Dynamic Host 3326 Configuration Protocol 3327 (DHCP) Options for 3328 Broadcast and Multicast 3329 Control Servers", 3330 RFC 4280, November 2005. 3332 [RFC4285] Patel, A., Leung, K., 3333 Khalil, M., Akhtar, H., 3334 and K. Chowdhury, 3335 "Authentication Protocol 3336 for Mobile IPv6", 3337 RFC 4285, January 2006. 3339 [RFC4292] Haberman, B., "IP 3340 Forwarding Table MIB", 3341 RFC 4292, April 2006. 3343 [RFC4293] Routhier, S., "Management 3344 Information Base for the 3345 Internet Protocol (IP)", 3346 RFC 4293, April 2006. 3348 [RFC4301] Kent, S. and K. Seo, 3349 "Security Architecture 3350 for the Internet 3351 Protocol", RFC 4301, 3352 December 2005. 3354 [RFC4318] Levi, D. and D. 3355 Harrington, "Definitions 3356 of Managed Objects for 3357 Bridges with Rapid 3358 Spanning Tree Protocol", 3359 RFC 4318, December 2005. 3361 [RFC4363] Levi, D. and D. 3362 Harrington, "Definitions 3363 of Managed Objects for 3364 Bridges with Traffic 3365 Classes, Multicast 3366 Filtering, and Virtual 3367 LAN Extensions", 3368 RFC 4363, January 2006. 3370 [RFC4422] Melnikov, A. and K. 3371 Zeilenga, "Simple 3372 Authentication and 3373 Security Layer (SASL)", 3374 RFC 4422, June 2006. 3376 [RFC4444] Parker, J., "Management 3377 Information Base for 3378 Intermediate System to 3379 Intermediate System 3380 (IS-IS)", RFC 4444, 3381 April 2006. 3383 [RFC4502] Waldbusser, S., "Remote 3384 Network Monitoring 3385 Management Information 3386 Base Version 2", 3387 RFC 4502, May 2006. 3389 [RFC4546] Raftus, D. and E. 3390 Cardona, "Radio Frequency 3391 (RF) Interface Management 3392 Information Base for Data 3393 over Cable Service 3394 Interface Specifications 3395 (DOCSIS) 2.0 Compliant RF 3396 Interfaces", RFC 4546, 3397 June 2006. 3399 [RFC4560] Quittek, J. and K. White, 3400 "Definitions of Managed 3401 Objects for Remote Ping, 3402 Traceroute, and Lookup 3403 Operations", RFC 4560, 3404 June 2006. 3406 [RFC4564] Govindan, S., Cheng, H., 3407 Yao, ZH., Zhou, WH., and 3408 L. Yang, "Objectives for 3409 Control and Provisioning 3410 of Wireless Access Points 3411 (CAPWAP)", RFC 4564, 3412 July 2006. 3414 [RFC4656] Shalunov, S., Teitelbaum, 3415 B., Karp, A., Boote, J., 3416 and M. Zekauskas, "A One- 3417 way Active Measurement 3418 Protocol (OWAMP)", 3419 RFC 4656, September 2006. 3421 [RFC4663] Harrington, D., 3422 "Transferring MIB Work 3423 from IETF Bridge MIB WG 3424 to IEEE 802.1 WG", 3425 RFC 4663, September 2006. 3427 [RFC4668] Nelson, D., "RADIUS 3428 Authentication Client MIB 3429 for IPv6", RFC 4668, 3430 August 2006. 3432 [RFC4669] Nelson, D., "RADIUS 3433 Authentication Server MIB 3434 for IPv6", RFC 4669, 3435 August 2006. 3437 [RFC4670] Nelson, D., "RADIUS 3438 Accounting Client MIB for 3439 IPv6", RFC 4670, 3440 August 2006. 3442 [RFC4671] Nelson, D., "RADIUS 3443 Accounting Server MIB for 3444 IPv6", RFC 4671, 3445 August 2006. 3447 [RFC4672] De Cnodder, S., Jonnala, 3448 N., and M. Chiba, "RADIUS 3449 Dynamic Authorization 3450 Client MIB", RFC 4672, 3451 September 2006. 3453 [RFC4673] De Cnodder, S., Jonnala, 3454 N., and M. Chiba, "RADIUS 3455 Dynamic Authorization 3456 Server MIB", RFC 4673, 3457 September 2006. 3459 [RFC4675] Congdon, P., Sanchez, M., 3460 and B. Aboba, "RADIUS 3461 Attributes for Virtual 3462 LAN and Priority 3463 Support", RFC 4675, 3464 September 2006. 3466 [RFC4706] Morgenstern, M., Dodge, 3467 M., Baillie, S., and U. 3468 Bonollo, "Definitions of 3469 Managed Objects for 3470 Asymmetric Digital 3471 Subscriber Line 2 3472 (ADSL2)", RFC 4706, 3473 November 2006. 3475 [RFC4710] Siddiqui, A., Romascanu, 3476 D., and E. Golovinsky, 3477 "Real-time Application 3478 Quality-of-Service 3479 Monitoring (RAQMON) 3480 Framework", RFC 4710, 3481 October 2006. 3483 [RFC4711] Siddiqui, A., Romascanu, 3484 D., and E. Golovinsky, 3485 "Real-time Application 3486 Quality-of-Service 3487 Monitoring (RAQMON) MIB", 3488 RFC 4711, October 2006. 3490 [RFC4712] Siddiqui, A., Romascanu, 3491 D., Golovinsky, E., 3492 Rahman, M., and Y. Kim, 3493 "Transport Mappings for 3494 Real-time Application 3495 Quality-of-Service 3496 Monitoring (RAQMON) 3497 Protocol Data Unit 3498 (PDU)", RFC 4712, 3499 October 2006. 3501 [RFC4737] Morton, A., Ciavattone, 3502 L., Ramachandran, G., 3503 Shalunov, S., and J. 3504 Perser, "Packet 3505 Reordering Metrics", 3506 RFC 4737, November 2006. 3508 [RFC4740] Garcia-Martin, M., 3509 Belinchon, M., Pallares- 3510 Lopez, M., Canales- 3511 Valenzuela, C., and K. 3512 Tammi, "Diameter Session 3513 Initiation Protocol (SIP) 3514 Application", RFC 4740, 3515 November 2006. 3517 [RFC4743] Goddard, T., "Using 3518 NETCONF over the Simple 3519 Object Access Protocol 3520 (SOAP)", RFC 4743, 3521 December 2006. 3523 [RFC4744] Lear, E. and K. Crozier, 3524 "Using the NETCONF 3525 Protocol over the Blocks 3526 Extensible Exchange 3527 Protocol (BEEP)", 3528 RFC 4744, December 2006. 3530 [RFC4750] Joyal, D., Galecki, P., 3531 Giacalone, S., Coltun, 3532 R., and F. Baker, "OSPF 3533 Version 2 Management 3534 Information Base", 3535 RFC 4750, December 2006. 3537 [RFC4780] Lingle, K., Mule, J-F., 3538 Maeng, J., and D. Walker, 3539 "Management Information 3540 Base for the Session 3541 Initiation Protocol 3542 (SIP)", RFC 4780, 3543 April 2007. 3545 [RFC4789] Schoenwaelder, J. and T. 3546 Jeffree, "Simple Network 3547 Management Protocol 3548 (SNMP) over IEEE 802 3549 Networks", RFC 4789, 3550 November 2006. 3552 [RFC4803] Nadeau, T. and A. Farrel, 3553 "Generalized 3554 Multiprotocol Label 3555 Switching (GMPLS) Label 3556 Switching Router (LSR) 3557 Management Information 3558 Base", RFC 4803, 3559 February 2007. 3561 [RFC4818] Salowey, J. and R. Droms, 3562 "RADIUS Delegated-IPv6- 3563 Prefix Attribute", 3564 RFC 4818, April 2007. 3566 [RFC4825] Rosenberg, J., "The 3567 Extensible Markup 3568 Language (XML) 3569 Configuration Access 3570 Protocol (XCAP)", 3571 RFC 4825, May 2007. 3573 [RFC4826] Rosenberg, J., 3574 "Extensible Markup 3575 Language (XML) Formats 3576 for Representing Resource 3577 Lists", RFC 4826, 3578 May 2007. 3580 [RFC4827] Isomaki, M. and E. 3581 Leppanen, "An Extensible 3582 Markup Language (XML) 3583 Configuration Access 3584 Protocol (XCAP) Usage for 3585 Manipulating Presence 3586 Document Contents", 3587 RFC 4827, May 2007. 3589 [RFC4898] Mathis, M., Heffner, J., 3590 and R. Raghunarayan, "TCP 3591 Extended Statistics MIB", 3592 RFC 4898, May 2007. 3594 [RFC4960] Stewart, R., "Stream 3595 Control Transmission 3596 Protocol", RFC 4960, 3597 September 2007. 3599 [RFC5060] Sivaramu, R., Lingard, 3600 J., McWalter, D., Joshi, 3601 B., and A. Kessler, 3602 "Protocol Independent 3603 Multicast MIB", RFC 5060, 3604 January 2008. 3606 [RFC5080] Nelson, D. and A. DeKok, 3607 "Common Remote 3608 Authentication Dial In 3609 User Service (RADIUS) 3610 Implementation Issues and 3611 Suggested Fixes", 3612 RFC 5080, December 2007. 3614 [RFC5085] Nadeau, T. and C. 3615 Pignataro, "Pseudowire 3616 Virtual Circuit 3617 Connectivity Verification 3618 (VCCV): A Control Channel 3619 for Pseudowires", 3620 RFC 5085, December 2007. 3622 [RFC5090] Sterman, B., Sadolevsky, 3623 D., Schwartz, D., 3624 Williams, D., and W. 3625 Beck, "RADIUS Extension 3626 for Digest 3627 Authentication", 3628 RFC 5090, February 2008. 3630 [RFC5101] Claise, B., 3631 "Specification of the IP 3632 Flow Information Export 3633 (IPFIX) Protocol for the 3634 Exchange of IP Traffic 3635 Flow Information", 3636 RFC 5101, January 2008. 3638 [RFC5102] Quittek, J., Bryant, S., 3639 Claise, B., Aitken, P., 3640 and J. Meyer, 3641 "Information Model for IP 3642 Flow Information Export", 3643 RFC 5102, January 2008. 3645 [RFC5103] Trammell, B. and E. 3646 Boschi, "Bidirectional 3647 Flow Export Using IP Flow 3648 Information Export 3649 (IPFIX)", RFC 5103, 3650 January 2008. 3652 [RFC5176] Chiba, M., Dommety, G., 3653 Eklund, M., Mitton, D., 3654 and B. Aboba, "Dynamic 3655 Authorization Extensions 3656 to Remote Authentication 3657 Dial In User Service 3658 (RADIUS)", RFC 5176, 3659 January 2008. 3661 [RFC5181] Shin, M-K., Han, Y-H., 3662 Kim, S-E., and D. Premec, 3663 "IPv6 Deployment 3664 Scenarios in 802.16 3665 Networks", RFC 5181, 3666 May 2008. 3668 [RFC5224] Brenner, M., "Diameter 3669 Policy Processing 3670 Application", RFC 5224, 3671 March 2008. 3673 [RFC5246] Dierks, T. and E. 3674 Rescorla, "The Transport 3675 Layer Security (TLS) 3676 Protocol Version 1.2", 3677 RFC 5246, August 2008. 3679 [RFC5277] Chisholm, S. and H. 3680 Trevino, "NETCONF Event 3681 Notifications", RFC 5277, 3682 July 2008. 3684 [RFC5357] Hedayat, K., Krzanowski, 3685 R., Morton, A., Yum, K., 3686 and J. Babiarz, "A Two- 3687 Way Active Measurement 3688 Protocol (TWAMP)", 3689 RFC 5357, October 2008. 3691 [RFC5388] Niccolini, S., 3692 Tartarelli, S., Quittek, 3693 J., Dietz, T., and M. 3694 Swany, "Information Model 3695 and XML Data Model for 3696 Traceroute Measurements", 3697 RFC 5388, December 2008. 3699 [RFC5415] Calhoun, P., Montemurro, 3700 M., and D. Stanley, 3701 "Control And Provisioning 3702 of Wireless Access Points 3703 (CAPWAP) Protocol 3704 Specification", RFC 5415, 3705 March 2009. 3707 [RFC5416] Calhoun, P., Montemurro, 3708 M., and D. Stanley, 3709 "Control and Provisioning 3710 of Wireless Access Points 3711 (CAPWAP) Protocol Binding 3712 for IEEE 802.11", 3713 RFC 5416, March 2009. 3715 [RFC5424] Gerhards, R., "The Syslog 3716 Protocol", RFC 5424, 3717 March 2009. 3719 [RFC5425] Miao, F., Ma, Y., and J. 3720 Salowey, "Transport Layer 3721 Security (TLS) Transport 3722 Mapping for Syslog", 3723 RFC 5425, March 2009. 3725 [RFC5426] Okmianski, A., 3726 "Transmission of Syslog 3727 Messages over UDP", 3728 RFC 5426, March 2009. 3730 [RFC5427] Keeni, G., "Textual 3731 Conventions for Syslog 3732 Management", RFC 5427, 3733 March 2009. 3735 [RFC5431] Sun, D., "Diameter ITU-T 3736 Rw Policy Enforcement 3737 Interface Application", 3738 RFC 5431, March 2009. 3740 [RFC5447] Korhonen, J., Bournelle, 3741 J., Tschofenig, H., 3742 Perkins, C., and K. 3743 Chowdhury, "Diameter 3744 Mobile IPv6: Support for 3745 Network Access Server to 3746 Diameter Server 3747 Interaction", RFC 5447, 3748 February 2009. 3750 [RFC5470] Sadasivan, G., Brownlee, 3751 N., Claise, B., and J. 3752 Quittek, "Architecture 3753 for IP Flow Information 3754 Export", RFC 5470, 3755 March 2009. 3757 [RFC5472] Zseby, T., Boschi, E., 3758 Brownlee, N., and B. 3759 Claise, "IP Flow 3760 Information Export 3761 (IPFIX) Applicability", 3762 RFC 5472, March 2009. 3764 [RFC5473] Boschi, E., Mark, L., and 3765 B. Claise, "Reducing 3766 Redundancy in IP Flow 3767 Information Export 3768 (IPFIX) and Packet 3769 Sampling (PSAMP) 3770 Reports", RFC 5473, 3771 March 2009. 3773 [RFC5474] Duffield, N., Chiou, D., 3774 Claise, B., Greenberg, 3775 A., Grossglauser, M., and 3776 J. Rexford, "A Framework 3777 for Packet Selection and 3778 Reporting", RFC 5474, 3779 March 2009. 3781 [RFC5475] Zseby, T., Molina, M., 3782 Duffield, N., Niccolini, 3783 S., and F. Raspall, 3784 "Sampling and Filtering 3785 Techniques for IP Packet 3786 Selection", RFC 5475, 3787 March 2009. 3789 [RFC5476] Claise, B., Johnson, A., 3790 and J. Quittek, "Packet 3791 Sampling (PSAMP) Protocol 3792 Specifications", 3793 RFC 5476, March 2009. 3795 [RFC5477] Dietz, T., Claise, B., 3796 Aitken, P., Dressler, F., 3797 and G. Carle, 3798 "Information Model for 3799 Packet Sampling Exports", 3800 RFC 5477, March 2009. 3802 [RFC5516] Jones, M. and L. Morand, 3803 "Diameter Command Code 3804 Registration for the 3805 Third Generation 3806 Partnership Project 3807 (3GPP) Evolved Packet 3808 System (EPS)", RFC 5516, 3809 April 2009. 3811 [RFC5539] Badra, M., "NETCONF over 3812 Transport Layer Security 3813 (TLS)", RFC 5539, 3814 May 2009. 3816 [RFC5560] Uijterwaal, H., "A One- 3817 Way Packet Duplication 3818 Metric", RFC 5560, 3819 May 2009. 3821 [RFC5580] Tschofenig, H., Adrangi, 3822 F., Jones, M., Lior, A., 3823 and B. Aboba, "Carrying 3824 Location Objects in 3825 RADIUS and Diameter", 3826 RFC 5580, August 2009. 3828 [RFC5590] Harrington, D. and J. 3829 Schoenwaelder, "Transport 3830 Subsystem for the Simple 3831 Network Management 3832 Protocol (SNMP)", 3833 RFC 5590, June 2009. 3835 [RFC5591] Harrington, D. and W. 3836 Hardaker, "Transport 3837 Security Model for the 3838 Simple Network Management 3839 Protocol (SNMP)", 3840 RFC 5591, June 2009. 3842 [RFC5592] Harrington, D., Salowey, 3843 J., and W. Hardaker, 3844 "Secure Shell Transport 3845 Model for the Simple 3846 Network Management 3847 Protocol (SNMP)", 3848 RFC 5592, June 2009. 3850 [RFC5607] Nelson, D. and G. Weber, 3851 "Remote Authentication 3852 Dial-In User Service 3853 (RADIUS) Authorization 3854 for Network Access Server 3855 (NAS) Management", 3856 RFC 5607, July 2009. 3858 [RFC5608] Narayan, K. and D. 3859 Nelson, "Remote 3860 Authentication Dial-In 3861 User Service (RADIUS) 3862 Usage for Simple Network 3863 Management Protocol 3864 (SNMP) Transport Models", 3865 RFC 5608, August 2009. 3867 [RFC5610] Boschi, E., Trammell, B., 3868 Mark, L., and T. Zseby, 3869 "Exporting Type 3870 Information for IP Flow 3871 Information Export 3872 (IPFIX) Information 3873 Elements", RFC 5610, 3874 July 2009. 3876 [RFC5650] Morgenstern, M., Baillie, 3877 S., and U. Bonollo, 3878 "Definitions of Managed 3879 Objects for Very High 3880 Speed Digital Subscriber 3881 Line 2 (VDSL2)", 3882 RFC 5650, September 2009. 3884 [RFC5655] Trammell, B., Boschi, E., 3885 Mark, L., Zseby, T., and 3886 A. Wagner, "Specification 3887 of the IP Flow 3888 Information Export 3889 (IPFIX) File Format", 3890 RFC 5655, October 2009. 3892 [RFC5674] Chisholm, S. and R. 3893 Gerhards, "Alarms in 3894 Syslog", RFC 5674, 3895 October 2009. 3897 [RFC5675] Marinov, V. and J. 3898 Schoenwaelder, "Mapping 3899 Simple Network Management 3900 Protocol (SNMP) 3901 Notifications to SYSLOG 3902 Messages", RFC 5675, 3903 October 2009. 3905 [RFC5676] Schoenwaelder, J., Clemm, 3906 A., and A. Karmakar, 3907 "Definitions of Managed 3908 Objects for Mapping 3909 SYSLOG Messages to Simple 3910 Network Management 3911 Protocol (SNMP) 3912 Notifications", RFC 5676, 3913 October 2009. 3915 [RFC5706] Harrington, D., 3916 "Guidelines for 3917 Considering Operations 3918 and Management of New 3919 Protocols and Protocol 3920 Extensions", RFC 5706, 3921 November 2009. 3923 [RFC5713] Moustafa, H., Tschofenig, 3924 H., and S. De Cnodder, 3925 "Security Threats and 3926 Security Requirements for 3927 the Access Node Control 3928 Protocol (ANCP)", 3929 RFC 5713, January 2010. 3931 [RFC5717] Lengyel, B. and M. 3932 Bjorklund, "Partial Lock 3933 Remote Procedure Call 3934 (RPC) for NETCONF", 3935 RFC 5717, December 2009. 3937 [RFC5719] Romascanu, D. and H. 3938 Tschofenig, "Updated IANA 3939 Considerations for 3940 Diameter Command Code 3941 Allocations", RFC 5719, 3942 January 2010. 3944 [RFC5729] Korhonen, J., Jones, M., 3945 Morand, L., and T. Tsou, 3946 "Clarifications on the 3947 Routing of Diameter 3948 Requests Based on the 3949 Username and the Realm", 3950 RFC 5729, December 2009. 3952 [RFC5777] Korhonen, J., Tschofenig, 3953 H., Arumaithurai, M., 3954 Jones, M., and A. Lior, 3955 "Traffic Classification 3956 and Quality of Service 3957 (QoS) Attributes for 3958 Diameter", RFC 5777, 3959 February 2010. 3961 [RFC5778] Korhonen, J., Tschofenig, 3962 H., Bournelle, J., 3963 Giaretta, G., and M. 3964 Nakhjiri, "Diameter 3965 Mobile IPv6: Support for 3966 Home Agent to Diameter 3967 Server Interaction", 3968 RFC 5778, February 2010. 3970 [RFC5779] Korhonen, J., Bournelle, 3971 J., Chowdhury, K., 3972 Muhanna, A., and U. 3973 Meyer, "Diameter Proxy 3974 Mobile IPv6: Mobile 3975 Access Gateway and Local 3976 Mobility Anchor 3977 Interaction with Diameter 3978 Server", RFC 5779, 3979 February 2010. 3981 [RFC5815] Dietz, T., Kobayashi, A., 3982 Claise, B., and G. Muenz, 3983 "Definitions of Managed 3984 Objects for IP Flow 3985 Information Export", 3986 RFC 5815, April 2010. 3988 [RFC5833] Shi, Y., Perkins, D., 3989 Elliott, C., and Y. 3990 Zhang, "Control and 3991 Provisioning of Wireless 3992 Access Points (CAPWAP) 3993 Protocol Base MIB", 3994 RFC 5833, May 2010. 3996 [RFC5834] Shi, Y., Perkins, D., 3997 Elliott, C., and Y. 3998 Zhang, "Control and 3999 Provisioning of Wireless 4000 Access Points (CAPWAP) 4001 Protocol Binding MIB for 4002 IEEE 802.11", RFC 5834, 4003 May 2010. 4005 [RFC5835] Morton, A. and S. Van den 4006 Berghe, "Framework for 4007 Metric Composition", 4008 RFC 5835, April 2010. 4010 [RFC5848] Kelsey, J., Callas, J., 4011 and A. Clemm, "Signed 4012 Syslog Messages", 4013 RFC 5848, May 2010. 4015 [RFC5851] Ooghe, S., Voigt, N., 4016 Platnic, M., Haag, T., 4017 and S. Wadhwa, "Framework 4018 and Requirements for an 4019 Access Node Control 4020 Mechanism in Broadband 4021 Multi-Service Networks", 4022 RFC 5851, May 2010. 4024 [RFC5866] Sun, D., McCann, P., 4025 Tschofenig, H., Tsou, T., 4026 Doria, A., and G. Zorn, 4027 "Diameter Quality-of- 4028 Service Application", 4029 RFC 5866, May 2010. 4031 [RFC5880] Katz, D. and D. Ward, 4032 "Bidirectional Forwarding 4033 Detection (BFD)", 4034 RFC 5880, June 2010. 4036 [RFC5889] Baccelli, E. and M. 4037 Townsley, "IP Addressing 4038 Model in Ad Hoc 4039 Networks", RFC 5889, 4040 September 2010. 4042 [RFC5982] Kobayashi, A. and B. 4043 Claise, "IP Flow 4044 Information Export 4045 (IPFIX) Mediation: 4046 Problem Statement", 4047 RFC 5982, August 2010. 4049 [RFC5996] Kaufman, C., Hoffman, P., 4050 Nir, Y., and P. Eronen, 4051 "Internet Key Exchange 4052 Protocol Version 2 4053 (IKEv2)", RFC 5996, 4054 September 2010. 4056 [RFC6012] Salowey, J., Petch, T., 4057 Gerhards, R., and H. 4058 Feng, "Datagram Transport 4059 Layer Security (DTLS) 4060 Transport Mapping for 4061 Syslog", RFC 6012, 4062 October 2010. 4064 [RFC6020] Bjorklund, M., "YANG - A 4065 Data Modeling Language 4066 for the Network 4067 Configuration Protocol 4068 (NETCONF)", RFC 6020, 4069 October 2010. 4071 [RFC6021] Schoenwaelder, J., 4072 "Common YANG Data Types", 4073 RFC 6021, October 2010. 4075 [RFC6022] Scott, M. and M. 4076 Bjorklund, "YANG Module 4077 for NETCONF Monitoring", 4078 RFC 6022, October 2010. 4080 [RFC6035] Pendleton, A., Clark, A., 4081 Johnston, A., and H. 4082 Sinnreich, "Session 4083 Initiation Protocol Event 4084 Package for Voice Quality 4085 Reporting", RFC 6035, 4086 November 2010. 4088 [RFC6065] Narayan, K., Nelson, D., 4089 and R. Presuhn, "Using 4090 Authentication, 4091 Authorization, and 4092 Accounting Services to 4093 Dynamically Provision 4094 View-Based Access Control 4095 Model User-to-Group 4096 Mappings", RFC 6065, 4097 December 2010. 4099 [RFC6087] Bierman, A., "Guidelines 4100 for Authors and Reviewers 4101 of YANG Data Model 4102 Documents", RFC 6087, 4103 January 2011. 4105 [RFC6095] Linowski, B., Ersue, M., 4106 and S. Kuryla, "Extending 4107 YANG with Language 4108 Abstractions", RFC 6095, 4109 March 2011. 4111 [RFC6110] Lhotka, L., "Mapping YANG 4112 to Document Schema 4113 Definition Languages and 4114 Validating NETCONF 4115 Content", RFC 6110, 4116 February 2011. 4118 [RFC6158] DeKok, A. and G. Weber, 4119 "RADIUS Design 4120 Guidelines", BCP 158, 4121 RFC 6158, March 2011. 4123 [RFC6183] Kobayashi, A., Claise, 4124 B., Muenz, G., and K. 4126 Ishibashi, "IP Flow 4127 Information Export 4128 (IPFIX) Mediation: 4129 Framework", RFC 6183, 4130 April 2011. 4132 [RFC6235] Boschi, E. and B. 4133 Trammell, "IP Flow 4134 Anonymization Support", 4135 RFC 6235, May 2011. 4137 [RFC6241] Enns, R., Bjorklund, M., 4138 Schoenwaelder, J., and A. 4139 Bierman, "Network 4140 Configuration Protocol 4141 (NETCONF)", RFC 6241, 4142 June 2011. 4144 [RFC6242] Wasserman, M., "Using the 4145 NETCONF Protocol over 4146 Secure Shell (SSH)", 4147 RFC 6242, June 2011. 4149 [RFC6244] Shafer, P., "An 4150 Architecture for Network 4151 Management Using NETCONF 4152 and YANG", RFC 6244, 4153 June 2011. 4155 [RFC6248] Morton, A., "RFC 4148 and 4156 the IP Performance 4157 Metrics (IPPM) Registry 4158 of Metrics Are Obsolete", 4159 RFC 6248, April 2011. 4161 [RFC6272] Baker, F. and D. Meyer, 4162 "Internet Protocols for 4163 the Smart Grid", 4164 RFC 6272, June 2011. 4166 [RFC6313] Claise, B., Dhandapani, 4167 G., Aitken, P., and S. 4168 Yates, "Export of 4169 Structured Data in IP 4170 Flow Information Export 4171 (IPFIX)", RFC 6313, 4172 July 2011. 4174 [RFC6320] Wadhwa, S., Moisand, J., 4175 Haag, T., Voigt, N., and 4176 T. Taylor, "Protocol for 4177 Access Node Control 4178 Mechanism in Broadband 4179 Networks", RFC 6320, 4180 October 2011. 4182 [RFC6347] Rescorla, E. and N. 4183 Modadugu, "Datagram 4184 Transport Layer Security 4185 Version 1.2", RFC 6347, 4186 January 2012. 4188 [RFC6353] Hardaker, W., "Transport 4189 Layer Security (TLS) 4190 Transport Model for the 4191 Simple Network Management 4192 Protocol (SNMP)", 4193 RFC 6353, July 2011. 4195 [RFC6371] Busi, I. and D. Allan, 4196 "Operations, 4197 Administration, and 4198 Maintenance Framework for 4199 MPLS-Based Transport 4200 Networks", RFC 6371, 4201 September 2011. 4203 [RFC6408] Jones, M., Korhonen, J., 4204 and L. Morand, "Diameter 4205 Straightforward-Naming 4206 Authority Pointer 4207 (S-NAPTR) Usage", 4208 RFC 6408, November 2011. 4210 [RFC6536] Bierman, A. and M. 4211 Bjorklund, "Network 4212 Configuration Protocol 4213 (NETCONF) Access Control 4214 Model", RFC 6536, 4215 March 2012. 4217 [RFCSEARCH] IETF, "RFC Index Search 4218 Engine", January 2006, . 4222 [SMI-NUMBERS] IANA, "Network Management 4223 Parameters - IANA SMI OID 4224 List", March 2012, . 4228 [STD16] Rose, M. and K. 4229 McCloghrie, "Structure 4230 and Identification of 4231 Management Information 4232 for TCP/IP-based 4233 Internets", May 1990. 4235 [STD17] McCloghrie, K. and M. 4236 Rose, "Management 4237 Information Base for 4238 Network Management of 4239 TCP/IP-based internets: 4240 MIB-II", March 1991. 4242 [STD58] McCloghrie, K., Perkins, 4243 D., and J. Schoenwaelder, 4244 "Structure of Management 4245 Information Version 2 4246 (SMIv2)", April 1999. 4248 [STD59] Waldbusser, S., "Remote 4249 Network Monitoring 4250 Management Information 4251 Base", May 2000. 4253 [STD6] Postel, J., "User 4254 Datagram Protocol", 4255 August 1980. 4257 [STD62] Harrington, D., "An 4258 Architecture for 4259 Describing Simple Network 4260 Management Protocol 4261 (SNMP) Management 4262 Frameworks", 4263 December 2002. 4265 [STD66] Berners-Lee, T., 4266 Fielding, R., and L. 4267 Masinter, "Uniform 4268 Resource Identifier 4269 (URI): Generic Syntax", 4270 January 2005. 4272 [STD7] Postel, J., "Transmission 4273 Control Protocol", 4274 September 1981. 4276 [XPATH] World Wide Web 4277 Consortium, "XML Path 4278 Language (XPath) Version 4279 1.0", November 1999, . 4283 [XSD-1] Beech, D., Thompson, H., 4284 Maloney, M., Mendelsohn, 4285 N., and World Wide Web 4286 Consortium Recommendation 4287 REC-xmlschema-1-20041028, 4288 "XML Schema Part 1: 4289 Structures Second 4290 Edition", October 2004, < 4291 http://www.w3.org/TR/ 4292 2004/ 4293 REC-xmlschema-1- 4294 20041028>. 4296 Appendix A. High Level Classification of Management Protocols and Data 4297 Models 4299 The following subsections aim to guide the reader for the fast 4300 selection of the management standard in interest and can be used as a 4301 dispatcher to forward to the appropriate chapter. The subsections 4302 below classify the protocols on one hand according to high-level 4303 criteria such as push versus pull mechanism, and passive versus 4304 active monitoring. On the other hand, the protocols are categorized 4305 concerning the network management task they address or the data model 4306 extensibility they provide. Based on the reader's requirements a 4307 reduced set of standard protocols and associated data models can be 4308 selected for further reading. 4310 As an example, someone outside of IETF typically would look for the 4311 TWAMP protocol in the Operations and Management Area working groups 4312 as it addresses performance management. However, the protocol TWAMP 4313 has been developed by the IPPM working group in the Transport Area. 4315 Note that not all protocols have been listed in all classification 4316 sections. Some of the protocols, especially the protocols with 4317 specific focus in Section 3 cannot be clearly classified. Note also 4318 that COPS and COPS-PR are not listed in the tables, as COPS-PR is not 4319 recommended to use (see Section 3.3). 4321 A.1. Protocols classified by the Standard Maturity at IETF 4323 This section classifies the management protocols according their 4324 standard maturity at the IETF. The IETF standard maturity levels 4325 Proposed, Draft or Internet Standard, are defined in [RFC2026]. An 4326 Internet Standard is characterized by a high degree of technical 4327 maturity and by a generally held belief that the specified protocol 4328 or service provides significant benefit to the Internet community. 4330 The table below covers the standard maturity of the different 4331 protocols listed in this document. Note that only the main protocols 4332 (and not their extensions) are noted. An RFC search tool listing the 4333 current document status is available at [RFCSEARCH]. 4335 +-------------------------------------------------+-----------------+ 4336 | Protocol | Maturity Level | 4337 +-------------------------------------------------+-----------------+ 4338 | SNMP [STD62][RFC3411] (Section 2.1) | Internet | 4339 | | Standard | 4340 | SYSLOG [RFC5424] (Section 2.2) | Proposed | 4341 | | Standard | 4342 | IPFIX [RFC5101] (Section 2.3) | Proposed | 4343 | | Standard | 4344 | PSAMP [RFC5476] (Section 2.3) | Proposed | 4345 | | Standard | 4346 | NETCONF [RFC6241] (Section 2.4.1) | Proposed | 4347 | | Standard | 4348 | DHCP for IPv4 [RFC2131] (Section 3.1.1) | Draft Standard | 4349 | DHCP for IPv6 [RFC3315] (Section 3.1.1) | Proposed | 4350 | | Standard | 4351 | OWAMP [RFC4656] (Section 3.4) | Proposed | 4352 | | Standard | 4353 | TWAMP [RFC5357] (Section 3.4) | Proposed | 4354 | | Standard | 4355 | RADIUS [RFC2865] (Section 3.5) | Draft Standard | 4356 | DIAMETER [RFC3588] (Section 3.6) | Proposed | 4357 | | Standard | 4358 | CAPWAP [RFC5416] (Section 3.7) | Proposed | 4359 | | Standard | 4360 | ANCP [RFC6320] (Section 3.8) | Proposed | 4361 | | Standard | 4362 | Ad-hoc network configuration [RFC5889] | Informational | 4363 | (Section 3.1.2) | | 4364 | ACAP [RFC2244] (Section 3.9) | Proposed | 4365 | | Standard | 4366 | XCAP [RFC4825] (Section 3.10) | Proposed | 4367 | | Standard | 4368 +-------------------------------------------------+-----------------+ 4370 Table 1: Protocols classified by Standard Maturity at IETF 4372 A.2. Protocols Matched to Management Tasks 4374 This subsection classifies the management protocols matching to the 4375 management tasks for fault, configuration, accounting, performance, 4376 and security management. 4378 +-------------+--------------+------------+-------------+-----------+ 4379 | Fault Mgmt | Configuratio | Accounting | Performance | Security | 4380 | | nMgmt | Mgmt | Mgmt | Mgmt | 4381 +-------------+--------------+------------+-------------+-----------+ 4382 | SNMP | SNMP | SNMP | SNMP | | 4383 | notificatio | configuratio | monitoring | monitoring | | 4384 | nwith trap | nwith set | with get | with get | | 4385 | operation | operation | operation | operation | | 4386 | (S. 2.1.1) | (S. 2.1.1) | (S. 2.1.1) | (S. 2.1.1) | | 4387 | IPFIX | CAPWAP | IPFIX | IPFIX | | 4388 | (S. 2.3) | (S. 3.7) | (S. 2.3) | (S. 2.3) | | 4389 | PSAMP | NETCONF | PSAMP | PSAMP | | 4390 | (S. 2.3) | (S. 2.4) | (S. 2.3) | (S. 2.3) | | 4391 | SYSLOG (S. | ANCP (S. | RADIUS | | RADIUS | 4392 | 2.2) | 3.8) | Accounting | | Authent.& | 4393 | | | (S. 3.5) | | Authoriz. | 4394 | | | | | (S. 3.5) | 4395 | | AUTOCONF (S. | DIAMETER | | DIAMETER | 4396 | | 3.1.2) | Accounting | | Authent.& | 4397 | | | (S. 3.6) | | Authoriz. | 4398 | | | | | (S. 3.6) | 4399 | | ACAP | | | | 4400 | | (S. 3.9) | | | | 4401 | | XCAP | | | | 4402 | | (S. 3.10) | | | | 4403 | | DHCP | | | | 4404 | | (S. 3.11) | | | | 4405 +-------------+--------------+------------+-------------+-----------+ 4407 Table 2: Protocols Matched to Management Tasks 4409 Note: Corresponding section numbers are given in parenthesis. 4411 A.3. Push versus Pull Mechanism 4413 A pull mechanism is characterized by the Network Management System 4414 (NMS) pulling the management information out of network elements, 4415 when needed. A push mechanism is characterized by the network 4416 elements pushing the management information to the NMS, either when 4417 the information is available, or on a regular basis. 4419 Client/Server protocols, such as DHCP, ANCP, ACAP, and XCAP are not 4420 listed in Table 3. 4422 +---------------------------------+---------------------------------+ 4423 | Protocols supporting the Pull | Protocols supporting the Push | 4424 | mechanism | mechanism | 4425 +---------------------------------+---------------------------------+ 4426 | SNMP (except notifications) | SNMP notifications | 4427 | (Section 2.1) | (Section 2.1) | 4428 | NETCONF (except notifications) | NETCONF notifications | 4429 | (Section 2.4.1) | (Section 2.4.1) | 4430 | CAPWAP (Section 3.7) | SYSLOG (Section 2.2) | 4431 | | IPFIX (Section 2.3) | 4432 | | PSAMP (Section 2.3) | 4433 | | RADIUS accounting | 4434 | | (Section 3.5) | 4435 | | DIAMETER accounting | 4436 | | (Section 3.6) | 4437 +---------------------------------+---------------------------------+ 4439 Table 3: Protocol classification by Push versus Pull Mechanism 4441 A.4. Passive versus Active Monitoring 4443 Monitoring can be divided into two categories, passive and active 4444 monitoring. Passive monitoring can perform the network traffic 4445 monitoring, monitoring of a device or the accounting of network 4446 resource consumption by users. Active monitoring, as used in this 4447 document, focuses mainly on active network monitoring and relies on 4448 the injection of specific traffic (also called "synthetic traffic"), 4449 which is then monitored. The monitoring focus is indicated in the 4450 table below as "network", "device" or "accounting". 4452 This classification excludes non-monitoring protocols, such as 4453 configuration protocols: Ad-hoc network autoconfiguration, ANCP, and 4454 XCAP. Note that some of the active monitoring protocols, in the 4455 context of the data path, e.g. ICMP Ping and Traceroute [RFC1470], 4456 Bidirectional Forwarding Detection (BFD) [RFC5880], and PWE3 Virtual 4457 Circuit Connectivity Verification (VCCV) [RFC5085] are covered in 4458 [I-D.ietf-opsawg-oam-overview]. 4460 +---------------------------------+---------------------------------+ 4461 | Protocols supporting passive | Protocols supporting active | 4462 | monitoring | monitoring | 4463 +---------------------------------+---------------------------------+ 4464 | IPFIX (network) (Section 2.3) | OWAMP (network) (Section 3.4) | 4465 | PSAMP (network) (Section 2.3) | TWAMP (network) (Section 3.4) | 4466 | SNMP (network and device) | | 4467 | (Section 2.1) | | 4468 | NETCONF (device) | | 4469 | (Section 2.4.1) | | 4470 | RADIUS (accounting) | | 4471 | (Section 3.5) | | 4472 | DIAMETER (accounting) | | 4473 | (Section 3.6) | | 4474 | CAPWAP (device) (Section 3.7) | | 4475 +---------------------------------+---------------------------------+ 4477 Table 4: Protocols for passive and active monitoring and their 4478 monitoring focus 4480 The application of SNMP to passive traffic monitoring (e.g. with 4481 RMON-MIB) or active monitoring (with IPPM MIB) depends on the MIB 4482 modules used. However, SNMP protocol itself does not have 4483 operations, which support active monitoring. NETCONF can be used for 4484 passive monitoring, e.g. with the NETCONF Monitoring YANG module 4485 [RFC6022] for the monitoring of the NETCONF protocol. CAPWAP 4486 monitors the status of a Wireless Termination Point. 4488 RADIUS and DIAMETER are considered as passive monitoring protocols as 4489 they perform accounting, i.e. counting the number of packets/bytes 4490 for a specific user. 4492 A.5. Supported Data Model Types and their Extensibility 4494 The following table matches the protocols to the associated data 4495 model types. Furthermore, the table indicates how the data model can 4496 be extended based on the available content today and whether the 4497 protocol contains a built-in mechanism for proprietary extensions of 4498 the data model. 4500 +----------------+--------------------+---------------+-------------+ 4501 | Protocol | Data Modeling | Data Model | Proprietary | 4502 | | | Extensions | Data | 4503 | | | | Modeling | 4504 | | | | Extensions | 4505 +----------------+--------------------+---------------+-------------+ 4506 | SNMP | MIB modules | New MIB | Enterprise | 4507 | (Section 2.1) | defined with SMI | modules | specific | 4508 | | (Section 2.1.3) | specified in | MIB modules | 4509 | | | new RFCs | | 4510 | SYSLOG | Structured Data | With the | Enterprise | 4511 | (Section 2.2) | Elements (SDE) | procedure to | specific | 4512 | | (Section 4.2.1) | add | SDEs | 4513 | | | Structured | | 4514 | | | Data ID in | | 4515 | | | [RFC5424] | | 4516 | IPFIX | IPFIX Information | With the | Enterprise | 4517 | (Section 2.3) | Elements, IPFIX | procedure to | specific | 4518 | | IANA registry at | add | Information | 4519 | | [IANA-IPFIX] | Information | Elements | 4520 | | (Section 2.3) | Elements | [RFC5101] | 4521 | | | specified in | | 4522 | | | [RFC5102] | | 4523 | PSAMP | PSAMP Information | With the | Enterprise | 4524 | (Section 2.3) | Elements, as an | procedure to | specific | 4525 | | extension to IPFIX | add | Information | 4526 | | [IANA-IPFIX], and | Information | Elements | 4527 | | PSAMP IANA | Elements | [RFC5101] | 4528 | | registry at | specified in | | 4529 | | [IANA-PSAMP] | [RFC5102] | | 4530 | | (Section 2.3) | | | 4531 | NETCONF | YANG modules | New YANG | Enterprise | 4532 | (Section 2.4.1 | (Section 2.4.2) | modules | specific | 4533 | ) | | specified in | YANG | 4534 | | | new RFCs | modules | 4535 | | | following the | | 4536 | | | guideline in | | 4537 | | | [RFC6087] | | 4538 | IPPM | IPPM metrics (*) | New IPPM | Not | 4539 | OWAMP/TWAMP | (Section 3.4) | metrics | applicable | 4540 | (Section 3.4) | | (Section 3.4) | | 4541 | RADIUS | Type-Length-Values | RADIUS | Vendor | 4542 | (Section 3.5) | (TLV) | related | Specific | 4543 | | | registries at | Attributes | 4544 | | | [IANA-AAA] | [RFC2865] | 4545 | | | and | | 4546 | | | [IANA-PROT] | | 4547 | DIAMETER | Attribute-Value | DIAMETER | Vendor | 4548 | (Section 3.6) | Pairs (AVP) | related | Specific | 4549 | | | registry at | Attributes | 4550 | | | [IANA-AAA] | [RFC2865] | 4551 | CAPWAP | Type-Length-Values | New bindings | Vendor | 4552 | (Section 3.7) | (TLV) | specified in | specific | 4553 | | | new RFCs | TLVs | 4554 +----------------+--------------------+---------------+-------------+ 4556 Table 5: Data Models and their Extensibility 4558 (*): With the publication of [RFC6248] the latest IANA registry for 4559 IPFIX metrics has been declared Obsolete. 4561 Appendix B. New Work related to IETF Management Standards 4563 B.1. Energy Management (EMAN) 4565 Energy management is becoming an additional requirement for network 4566 management systems due to several factors including the rising and 4567 fluctuating energy costs, the increased awareness of the ecological 4568 impact of operating networks and devices, and the regulation of 4569 governments on energy consumption and production. 4571 The basic objective of energy management is operating communication 4572 networks and other equipments with a minimal amount of energy while 4573 still providing sufficient performance to meet service level 4574 objectives. Today, most networking and network-attached devices 4575 neither monitor nor allow control energy usage as they are mainly 4576 instrumented for functions such as fault, configuration, accounting, 4577 performance, and security management. These devices are not 4578 instrumented to be aware of energy consumption. There are very few 4579 means specified in IETF documents for energy management, which 4580 includes the areas of power monitoring, energy monitoring, and power 4581 state control. 4583 A particular difference between energy management and other 4584 management tasks is that in some cases energy consumption of a device 4585 is not measured at the device itself but reported by a different 4586 place. For example, at a Power over Ethernet (PoE) sourcing device 4587 or at a smart power strip, where one device is effectively metering 4588 another remote device. This requires a clear definition of the 4589 relationship between the reporting devices and identification of 4590 remote devices for which monitoring information is provided. Similar 4591 considerations will apply to power state control of remote devices, 4592 for example, at a PoE sourcing device that switches on and off power 4593 at its ports. Another example scenario for energy management is a 4594 gateway to low resourced and lossy network devices in wireless a 4595 building network. Here the energy management system talks directly 4596 to the gateway but not necessarily to other devices in the building 4597 network. 4599 At the time of this writing the EMAN working group works on the 4600 management of energy-aware devices, covered by the following items: 4602 o Requirements for energy management, specifying energy management 4603 properties that will allow networks and devices to become energy 4604 aware. In addition to energy awareness requirements, the need for 4605 control functions will be discussed. Specifically the need to 4606 monitor and control properties of devices that are remote to the 4607 reporting device should be discussed. 4609 o Energy management framework, which will describe extensions to 4610 current management framework, required for energy management. 4611 This includes: power and energy monitoring, power states, power 4612 state control, and potential power state transitions. The 4613 framework will focus on energy management for IP-based network 4614 equipment (routers, switches, PCs, IP cameras, phones and the 4615 like). Particularly, the relationships between reporting devices, 4616 remote devices, and monitoring probes (such as might be used in 4617 low-power and lossy networks) need to be elaborated. For the case 4618 of a device reporting on behalf of other devices and controlling 4619 those devices, the framework will address the issues of discovery 4620 and identification of remote devices. 4622 o Energy-aware Networks and Devices MIB document, for monitoring 4623 energy-aware networks and devices, will address devices 4624 identification, context information, and potential relationship 4625 between reporting devices, remote devices, and monitoring probes. 4627 o Power and Energy Monitoring MIB document will document defining 4628 managed objects for monitoring of power states and energy 4629 consumption/production. The monitoring of power states includes: 4630 retrieving power states, properties of power states, current power 4631 state, power state transitions, and power state statistics. The 4632 managed objects will provide means of reporting detailed 4633 properties of the actual energy rate (power) and of accumulated 4634 energy. Further, it will provide information on electrical power 4635 quality. 4637 o Battery MIB document will define managed objects for battery 4638 monitoring, which will provide means of reporting detailed 4639 properties of the actual charge, age, and state of a battery and 4640 of battery statistics. 4642 o Applicability statement will describe the variety of applications 4643 that can use the energy framework and associated MIB modules. 4644 Potential examples are building networks, home energy gateway, 4645 etc. Finally, the document will also discuss relationships of the 4646 framework to other architectures and frameworks (such as Smart 4647 Grid). The applicability statement will explain the relationship 4648 between the work in this WG and other existing standards e.g. from 4649 the IEC, ANSI, DMTF, etc. Note that the EMAN WG will be looking 4650 into existing standards such as those from the IEC, ANSI, DMTF and 4651 others, and reuse existing work as much as possible. 4653 Appendix C. Change Log 4655 RFC EDITOR: Please remove this appendix before publication. 4657 C.1. 06-07 4659 o Addressed IESG requests. 4661 C.2. 05-06 4663 o Added a description for each DIAMETER application. 4665 o Extend text for XCAP and added descriptions for XCAP application 4666 usages. 4668 o Addressed GEN-area review comments. 4670 o Fixed nits and references. 4672 C.3. 04-05 4674 o Fixed nits. 4676 C.4. 03-04 4678 o Resolved many bugs, nits and open issues. 4680 o Reduced text on old and less used RFCs. 4682 o Formulated text on drafts, which are not expected to be published 4683 in IETF 83 time frame, as ongoing work and deleted the reference. 4685 o Reduced I-D references and edited remaining ones as easily 4686 replaceable with RFC references. 4688 o Removed textual references that RFCs are Proposed or Draft 4689 standard. 4691 o Removed the categories for Draft, Proposed and Full standards in 4692 section 4.2. 4694 C.5. 02-03 4696 o Added the new subsection 4.1 giving a broader overview of IETF 4697 management data models. 4699 o Reduced text on RMON in section 4.2.4 Performance Management 4701 o Resolved bugs, nits and open issues 4703 o Added RFC references 4705 C.6. 01-02 4707 o Resolved bugs, nits and open issues 4709 o Reduced subsections RADIUS and DIAMETER with text on expired 4710 drafts. 4712 o Extended dispatcher tables in Appendix A 4714 o Added a note indicating that IETF has not developed so far 4715 specific technologies for the management of sensor networks. 4717 o Added a note that IETF has not used the FCAPS view as an 4718 organizing principle for its data models. 4720 o Added draft-weil-shared-transition-space-request assuming that 4721 it'll get published pretty fast 4723 o Added RFC references 4725 o Removed text on expired drafts 4727 C.7. 00-01 4729 o Reduced text for the Security Requirements on SNMP and referenced 4730 to RFC 3411 4732 o Reduced subsection on VACM 4734 o Merged subsection on "RADIUS Authentication and Authorization with 4735 SNMP Transport Models" into the section "SNMP Transport Security 4736 Model" 4738 o Section on Dynamic Host Configuration Protocol (DHCP) revised by 4739 Ralph Droms 4741 o Subsections on DHCP and Autoconf assembled in section "IP Address 4742 Management" 4744 o Removed subsection on "Extensible Provision Protocol (EPP)" 4746 o Introduced new Appendix on "High Level Classification of 4747 Management Protocols and Data Models" 4749 o Deleted detailed positive comments 4751 o Resolved some of the I-D references with the correct reference to 4752 the published RFC number 4754 o Added RFC references 4756 o Removed text on expired drafts 4758 o Resolved bugs, nits and open issues 4760 C.8. draft-ersue-opsawg-management-fw-03-00 4762 o Diverse bug fixing 4764 o Incorporated comments from Juergen Schoenwaelder 4766 o Reduced detailed text on pro and contra on management technologies 4768 o Extended Terminology section with terms and abbreviations 4770 o Explained the structure based on the management application view 4772 o Definition of 'MIB module' aligned in different sections 4774 o Text on SNMP security reduced 4776 o All protocol sections discuss now security and AAA as far as 4777 relevant 4779 o Added IPFIX IEs, SYSLOG SDEs, and YANG modules to the data model 4780 definition 4782 o Added text on YANG data modules to section 4.2. 4784 o Added text on IPFIX IEs to section 4.3. 4786 o Added numerous references 4788 C.9. Change Log from draft-ersue-opsawg-management-fw 4790 C.9.1. 02-03 4792 o Rearranged the document structure using a flat structure putting 4793 all protocols onto the same level. 4795 o Incorporated contributions for RADIUS/DIAMETER, IPFIX/PSAMP, YANG, 4796 and EMAN. 4798 o Added diverse references. 4800 o Added Contributors and Acknowledgements sections. 4802 o Bug fixing and issue solving. 4804 C.9.2. 01-02 4806 o Added terminology section. 4808 o Changed the language for neutral standard description addressing 4809 diverse SDOs. 4811 o Extended NETCONF and NETMOD related text. 4813 o Extended section for 'IPv6 Network Operations'. 4815 o Bug fixing. 4817 C.9.3. 00-01 4819 o Extended text for SNMP 4821 o Extended RADIUS and DIAMETER sections. 4823 o Added references. 4825 o Bug fixing. 4827 Authors' Addresses 4829 Mehmet Ersue (editor) 4830 Nokia Siemens Networks 4831 St.-Martin-Strasse 53 4832 Munich 81541 4833 Germany 4835 EMail: mehmet.ersue@nsn.com 4837 Benoit Claise 4838 Cisco Systems, Inc. 4839 De Kleetlaan 6a b1 4840 Diegem 1831 4841 Belgium 4843 EMail: bclaise@cisco.com