summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3139.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3139.txt')
-rw-r--r--doc/rfc/rfc3139.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc3139.txt b/doc/rfc/rfc3139.txt
new file mode 100644
index 0000000..2c661ff
--- /dev/null
+++ b/doc/rfc/rfc3139.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group L. Sanchez
+Request for Comments: 3139 Megisto
+Category: Informational K. McCloghrie
+ Cisco
+ J. Saperia
+ JDS Consultant
+ June 2001
+
+
+ Requirements for Configuration Management of IP-based Networks
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Abstract
+
+ This memo discusses different approaches to configure networks and
+ identifies a set of configuration management requirements for IP-
+ based networks.
+
+Table of Contents
+
+ 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1 Motivation, Scope and Goals of this document . . . . . . . 2
+ 1.2 Requirements Terminology . . . . . . . . . . . . . . . . . 3
+ 1.3 Audience . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.4 Definition of Technical Terms. . . . . . . . . . . . . . . 3
+ 2.0 Statement of the Problem . . . . . . . . . . . . . . . . . . 4
+ 3.0 Requirements for an IP-based Configuration Management System . 7
+ 4.0 Security Considerations . . . . . . . . . . . . . . . . . . . 9
+ Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ References. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 10
+ Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 11
+
+
+
+
+
+
+
+
+
+
+Sanchez, et al. Informational [Page 1]
+
+RFC 3139 Requirements for Configuration Management June 2001
+
+
+1.0 Introduction
+
+1.1 Motivation, Scope and Goals of this document
+
+ A number of IETF working groups have introduced new technologies
+ which offer integrated and differentiated services. To support these
+ new technologies, working group members found that they had new
+ requirements for configuration of these technologies. One of these
+ new requirements was for the provisioning (configuration) of behavior
+ at the network level.
+
+ An example of this type of configuration would be instructing all
+ routers in a network to provide 'gold' service to a particular set of
+ customers. Depending on the specific network equipment and
+ definition of 'gold' service, this configuration request might
+ translate to different configuration parameters on different vendors
+ equipment and many individual configuration commands at the router.
+ This higher level of configuration management has come to commonly be
+ known as policy based management.
+
+ Working groups associated with these new technologies believed that
+ the existing SNMP based management framework, while adequate for
+ fault, configuration management at the individual instance (e.g.,
+ interface) level, performance and other management functions commonly
+ associated with it, was not able to meet these new needs. As a
+ result they began working on new solutions and approaches.
+
+ COPS [COPS] for RSVP [RSVP] provides routers with the opportunity to
+ ask their Policy Server for an admit/reject decision for a particular
+ RSVP session. This model allows routers to outsource their resource
+ allocation decisions to some other entity. However, this model does
+ not work with DiffServ [DSARCH] where there is no signalling
+ protocol. Therefore, the policies that affect resource allocation
+ decisions must be provisioned to the routers. It became evident that
+ there was a need for coordinating both RSVP-based and DiffServ-based
+ policies to provide end2end QoS. Working groups began to extend and
+ leverage approaches such as COPS for RSVP to support Diffserv
+ policies. This gave birth to COPS-PR [COPS-PR].
+
+ These extensions caused concern that the IETF was about to develop a
+ set of fragmented solutions which were locally optimized for specific
+ technologies and not well integrated in the existing Internet
+ Management Framework. The concern prompted some of the Area
+ Directors associated with the Operations and Management, Transport
+ and General areas, and some IAB members to organize a two day meeting
+ in mid September 1999. The primary purpose of the meeting was to
+ examine the requirements for configuration management and evaluate
+ the COPS/PIB and SNMP/MIB approaches in light of these requirements.
+
+
+
+Sanchez, et al. Informational [Page 2]
+
+RFC 3139 Requirements for Configuration Management June 2001
+
+
+ At the end of the two day meeting there was no consensus on several
+ issues and as a result a number of 'design teams' were created. This
+ document is the output of the design team chartered with the
+ identification of a global set of configuration management
+ requirements. This document has benefited from feedback received
+ during the Configuration Management BOF that took place on November
+ 11, 1999 during the 46th IETF in Washington DC, USA. The document
+ has also benefited from comments sent to the confmgt@ops.ietf.org
+ mailing list.
+
+1.2 Requirements Terminology
+
+ Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
+ "MAY" that appear in this document are to be interpreted as described
+ in RFC 2119 [Bra97].
+
+1.3 Audience
+
+ The target audience for this document includes system designers,
+ implementers of network configuration and management technology and
+ others interested in gaining a general background understanding of
+ the issues related to configuration management in general, and in the
+ Internet in particular along with associated requirements. This
+ document assumes that the reader is familiar with the Internet
+ Protocol, related networking technology, and general network
+ management terms and concepts.
+
+1.4 Definition of Terms
+
+ Device-Local Configuration
+
+ Configuration data that is specific to a particular network device.
+ This is the finest level of granularity for configuring network
+ devices.
+
+ Network-Wide Configuration
+
+ Configuration data that is not specific to any particular network
+ device and from which multiple device-local configurations can be
+ derived. Network-wide configuration provides a level of abstraction
+ above device-local configurations.
+
+ Configuration Data Translator
+
+ A function that transforms Configuration Management Data (high-level
+ policies) or Network-wide configuration data (middle-level policies)
+ into device local configurations (low-level policies) based on the
+
+
+
+
+Sanchez, et al. Informational [Page 3]
+
+RFC 3139 Requirements for Configuration Management June 2001
+
+
+ generic capabilities of network devices. This function can be
+ performed either by devices themselves or by some intermediate
+ entity.
+
+2.0 Statement of the Problem
+
+ Configuring large networks is becoming an increasingly difficult
+ task. The problem intensifies as networks increase their size, not
+ only in terms of number of devices, but also with a greater variety
+ of devices, with each device having increasing functionality and
+ complexity. That is, networks are getting more complex in multiple
+ dimensions simultaneously (number of devices, time scales for
+ configuration, etc.) making the task of configuring these more
+ complex.
+
+ In the past, configuring a network device has been a three step
+ process. The network operator, engineer or entity responsible for
+ the network created a model of the network and its expected behavior.
+ Next, this (model + expected behavior) was formalized and recorded in
+ the form of high-level policies. Finally, these policies were then
+ translated into device-local configurations and provisioned into each
+ network device for enforcement.
+
+ Any high-level policy changes (changes in the network topology and/or
+ its expected behavior) needed to be translated and provisioned to all
+ network devices affected by the change. Figure 1 depicts this model
+ and shows how high-level policies for a network could be translated
+ into four device-local configurations. In this model, network
+ operators or engineers functioned as configuration data translators;
+ they translated the high-level policies to device-local configuration
+ data.
+
+ A configuration data translator could take the topology independent
+ behavior description such as high-level policies (first input source)
+ combine it with topology information (second input source) as well as
+ status/performance/monitoring information (third input source) to
+ derive device-local configurations. Note that there could be several
+ configuration data translators operating in tandem on a set of
+ devices. However, there could be only one configuration data
+ translator operating at a particular device at any given instance.
+
+
+
+
+
+
+
+
+
+
+
+Sanchez, et al. Informational [Page 4]
+
+RFC 3139 Requirements for Configuration Management June 2001
+
+
+ Configuration Management
+ Data (High-level Policies)
+ |
+ |
+ |
+ |
+ Network V Network
+ Topology -----> Configuration <---- Status/performance
+ Information Data Translator(s) Information
+ |
+ |
+ |
+ |
+ -------------------------------------------------
+ | | | |
+ Device Device Device Device
+ Local Local Local Local
+ Conf(1) Conf(2) Conf(3) Conf(4)
+
+
+ Figure 1. Current model for configuring network devices.
+
+ Historically, network operators and engineers used protocols and
+ mechanisms such as SNMP and CLI applications to provision or
+ configure network devices. In their current versions, these
+ mechanisms have proven to be difficult to use because of their low-
+ level of granularity and their device-specific nature. This problem
+ is worse when provisioning multiple network devices requiring large
+ amounts of configuration data.
+
+ It is evident that network administrators and existing configuration
+ management software can not keep up with the growth in complexity of
+ networks and that an efficient, integrated configuration management
+ solution is needed. Several IETF Working Groups working on this
+ problem converged into adding a layer of abstraction to the
+ traditional configuration management process described in figure 1.
+ Figure 2 depicts this process after the layer of abstraction is
+ added. As in the previous figure, first the network operator,
+ engineer or entity responsible for the network creates a model of the
+ network and its expected behavior. This is formalized and recorded
+ in the form of high-level policies.
+
+ These policies are combined with topology information as well as
+ status/performance information to generate network-wide configuration
+ data. These middle level-policies are simpler to manage and
+ represent behaviors shared by multiple network devices.
+
+
+
+
+
+Sanchez, et al. Informational [Page 5]
+
+RFC 3139 Requirements for Configuration Management June 2001
+
+
+ Configuration Management
+ Data (High-level Policies)
+ |
+ |
+ |
+ |
+ Network V Network
+ Topology -----> Network-Wide <---- Status/performance
+ Information Configuration Information
+ Data
+ |
+ |
+ |
+ |
+ V
+ Configuration
+ Data Translator(s)
+ |
+ |
+ |
+ |
+ -------------------------------------------------
+ | | | |
+ Device Device Device Device
+ Local Local Local Local
+ Conf(1) Conf(2) Conf(3) Conf(4)
+
+ Figure 2. Proposed model for configuring network devices.
+
+ Device local configurations are generated by automated configuration
+ data translators and are supplied to each network device for
+ enforcement. Note how this model only describes the function of the
+ configuration data translators and it does not dictate its functional
+ location. This is to say that translators may reside outside of the
+ devices (as it was the case in figure 1 since they were humans) or
+ may be possibly collocated with each device.
+
+ As in the previous model, any high-level policy changes (changes in
+ the network topology and/or its expected behavior) needs to be
+ propagated to all network devices affected by the change. However,
+ in the configuration model depicted in figure 2 network operators and
+ engineers can specify the behavior of the network in a simplified
+ manner reducing the amount of device specific knowledge needed.
+
+ One should keep in mind that in some cases per instance device local
+ configuration is needed in network devices. An integrated solution
+ MUST allow room for this. Also, the introduction of automated
+ configuration data translators assumes that all information needed to
+
+
+
+Sanchez, et al. Informational [Page 6]
+
+RFC 3139 Requirements for Configuration Management June 2001
+
+
+ make an error free conversion of network-wide configuration data into
+ device-local configuration data is available. In the event that such
+ data is not available the solution MUST detect this and act
+ accordingly.
+
+3.0 Requirements for an IP-based Configuration Management System
+
+ All IETF WGs active in this area agrees upon the following
+ requirements for configuration management. An integrated
+ configuration management solution MUST:
+
+ 1) provide means by which the behavior of the network can be
+ specified at a level of abstraction (network-wide
+ configuration) higher than a set of configuration information
+ specific to individual devices,
+
+ 2) be capable of translating network-wide configurations into
+ device-local configuration. The identification of the relevant
+ subset of the network-wide policies to be down-loaded is
+ according to the capabilities of each device,
+
+ 3) be able to interpret device-local configuration, status and
+ monitoring information within the context of network-wide
+ configurations,
+
+ 4) be capable of provisioning (e.g., adding, modifying, deleting,
+ dumping, restoring) complete or partial configuration data to
+ network devices simultaneously or in a synchronized fashion as
+ necessary,
+
+ 4a) be able to provision multiple device-local configurations
+ to support fast switch-overs without the need to down-
+ load potentially large configuration changes to many
+ devices,
+
+ 5) provide means by which network devices can send feedback
+ information (configuration data confirmation, network status
+ and monitoring information, specific events, etc.) to the
+ management system,
+
+ 6) be capable of provisioning complete or partial configuration
+ data to network devices dynamically as a result of network
+ specific or network-wide events,
+
+ 7) provide efficient and reliable means compared to current
+ versions of today's mechanisms (CLI, SNMP) to provision large
+ amounts of configuration data,
+
+
+
+
+Sanchez, et al. Informational [Page 7]
+
+RFC 3139 Requirements for Configuration Management June 2001
+
+
+ 8) provide secure means to provision configuration data. The
+ system must provide support for access control, authentication,
+ integrity-checking, replay- protection and/or privacy security
+ services. The minimum level of granularity for access control
+ and authentication is host based. The system SHOULD support
+ user/role based access control and authentication for users in
+ different roles with different access privileges,
+
+ 9) provide expiration time and effective time capabilities to
+ configuration data. It is required that some configuration
+ data items be set to expire, and other items be set to never
+ expire,
+
+ 10) provide error detection (including data-specific errors) and
+ failure recovery mechanisms (including prevention of
+ inappropriately partial configurations when needed) for the
+ provisioning of configuration data,
+
+ 11) eliminate the potential for mis-configuration occurring through
+ concurrent shared write access to the device's configuration
+ data,
+
+ 12) provide facilities (with host and user-based authentication
+ granularity) to help in tracing back configuration changes,
+
+ 13) allow for the use of redundant components, both network
+ elements and configuration application platforms, and for the
+ configuration of redundant network elements.
+
+ 14) be flexible and extensible to accommodate future needs.
+ Configuration management data models are not fixed for all time
+ and are subject to evolution like any other management data
+ model. It is therefore necessary to anticipate that changes
+ will be needed, but it is not possible to anticipate what those
+ changes might be. Such changes could be to the configuration
+ data model, supporting message types, data types, etc., and to
+ provide mechanisms that can deal with these changes effectively
+ without causing inter-operability problems or having to
+ replace/update large amounts of fielded networking devices,
+
+ 15) leverage knowledge of the existing SNMP management
+ infrastructure. The system MUST leverage knowledge of and
+ experience with MIBs and SMI.
+
+
+
+
+
+
+
+
+Sanchez, et al. Informational [Page 8]
+
+RFC 3139 Requirements for Configuration Management June 2001
+
+
+Security Considerations
+
+ This document reflects the current requirements that the IETF
+ believes configuration management systems MUST have to properly
+ support IP-based networks. The authors believe that a configuration
+ management system MUST provide mechanisms by which one can ascertain
+ the integrity and authenticity of the configuration data at all
+ times. In some cases the privacy of the data is important therefore
+ configuration management system MUST provide facilities to support
+ this services as required not only while the data is stored but also
+ during provisioning or reception. Requirements eight and twelve
+ capture the required security services.
+
+Acknowledgments
+
+ The authors thank Juergen Schoenwaelder for his contributions to this
+ document. The authors also thank Walter Weiss and Andrew Smith for
+ providing feedback to early versions of this document. Finally, the
+ authors thank the IESG for motivating and supporting this work.
+
+References
+
+ [Bra97] Bradner, S., "Key Words for use in RFCs to indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R.
+ and A. Sastry, "The COPS (Common Open Policy Service)
+ Protocol", RFC 2748, August 1999.
+
+ [RSVP] Braden, R., Editor, et al., "Resource ReSerVation
+ Protocol (RSVP) Version 1 - Functional Specification",
+ RFC 2205, September 1997.
+
+ [COPS-RSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R.
+ and A. Sastry, "COPS usage for RSVP", RFC 2749, June
+ 1999.
+
+ [COPS-PROV] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie,
+ K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A.
+ Smith, "COPS Usage for Policy Provisioning (COPS-PR)",
+ RFC 3084, March 2001.
+
+
+
+
+
+
+
+
+
+
+Sanchez, et al. Informational [Page 9]
+
+RFC 3139 Requirements for Configuration Management June 2001
+
+
+Authors' Addresses
+
+ Keith McCloghrie
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134-1706
+ USA
+
+ Phone: +1 (408) 526-5260
+ EMail: kzm@cisco.com
+
+
+ Luis A. Sanchez
+ Megisto Systems
+ 20251 Century Boulevard
+ Germantown, MD 02138
+ USA
+
+ Phone: +1 (301) 444-1747
+ EMail: lsanchez@megisto.com
+
+
+ Jon Saperia
+ JDS Consulting, Inc.
+ 174 Chapman Street
+ Watertown, MA 02472
+ USA
+
+ Phone: +1 (617) 744-1079
+ EMail: saperia@jdscons.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sanchez, et al. Informational [Page 10]
+
+RFC 3139 Requirements for Configuration Management June 2001
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sanchez, et al. Informational [Page 11]
+