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