rfc3139.txt

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

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