rfc3139.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 620 行 · 第 1/2 页

   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: [phone]
   EMail: [e-mail]


   Luis A. Sanchez
   Megisto Systems
   20251 Century Boulevard
   Germantown, MD  02138
   USA

   Phone: [phone]
   EMail: [e-mail]


   Jon Saperia
   JDS Consulting, Inc.
   174 Chapman Street
   Watertown, MA 02472
   USA

   Phone: [phone]
   EMail: [e-mail]





















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]