Internet Draft Luis Sanchez, BBN draft-ops-mumble-conf-management-00.txt Keith McCloghrie, Cisco Expires in Six Months Jon Saperia, Consultant October 22, 1999 Evaluation of COPS/PIB and SNMP/MIB approaches for configuration management of IP-based networks. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document is the output of a design team chartered with the identification of a global set of configuration management requirements for IP-based networks. The document includes evaluations of the COPS/PIB and SNMP/MIB based approaches with respect to these requirements. In addition, the document discusses possible enhancements to both of these approaches and includes evaluations of the costs associated with their development and deployment. L. Sanchez, K. McCloghrie, J. Saperia [page 1] Internet Draft October 22, 1999 Table of Contents 1. 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. Statement of the Problem . . . . . . . . . . . . . . . . . . . 4 3. Requirements for an IP-based Configuration Management System . 7 4. Evaluation of COPS-PR/SoPI . . . . . . . . . . . . . . . . . . 8 4.1 The COPS+SNMP solution: Introduction . . . . . . . . . . . 8 4.2 Does COPS-PR meet the requirements? . . . . . . . . . . .10 4.3 Status of COPS-PR . . . . . . . . . . . . . . . . . . . . 17 4.4 Summary for COPS-PR. . . . . . . . . . . . . . . . . . . 17 5. Evaluation of SNMP/SMI. . . . . . . . . . . . . . . . . . . . 17 5.1 Does SNMP/SMI meet the requirements?. . . . . . . . . . . 17 5.2 Areas of Improvement for SNMP/SMI . . . . . . . . . . . . 24 5.3 Cost of Implementation for SNMP/SMI . . . . . . . . . . . 25 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 L. Sanchez, K. McCloghrie, J. Saperia [page 2] Internet Draft October 22, 1999 1. Introduction 1.1 Motivation, Scope and Goals of this document Over the past months, 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 Operations and Management, the 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. L. Sanchez, K. McCloghrie, J. Saperia [page 3] Internet Draft October 22, 1999 By 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 and the further evaluation of the COPS/PIB and SNMP/MIB based approaches with respect to these requirements. In addition, the design team was chartered with investigation of enhancements to both of these approaches and evaluation of the costs associated with their development and deployment. 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. In addition, the audience are those people who wish to gain additional information about how COPS-PR and SNMP have been measured against those 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 generic capabilities of network devices. This function can be performed either by devices themselves or by some intermediate entity. L. Sanchez, K. McCloghrie, J. Saperia [page 4] Internet Draft October 22, 1999 2. 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. Network operators or engineers 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. L. Sanchez, K. McCloghrie, J. Saperia [page 5] Internet Draft October 22, 1999 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. L. Sanchez, K. McCloghrie, J. Saperia [page 6] Internet Draft October 22, 1999 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. Propose model for configuring network devices. 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. 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 collocated with each device if possible. 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. L. Sanchez, K. McCloghrie, J. Saperia [page 7] Internet Draft October 22, 1999 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 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. Requirements for an IP-based Configuration Management System The following requirements for configuration management will be used in evaluating the cost effectiveness of the extension to SNMP and/or the use of COPS-PR with modifications 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, 5) provide efficient means compare to today's mechanisms (CLI, SNMP) to provision large amounts of configuration data, 6) provide secure means to provision configuration data. The system must provide 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, 7) provide expiration 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, 8) provide error detection (including data-specific errors) and failure recovery mechanisms for the provisioning of configuration data, L. Sanchez, K. McCloghrie, J. Saperia [page 8] Internet Draft October 22, 1999 9) eliminate the potential for mis-configuration occurring through shared write access to the device's configuration data, 10) provide facilities (with host and user-based authentication granularity) to help in tracing back configuration changes, 11) allow for the configuration of redundant components (both as network elements and configuration application platforms). In addition, the system should support the concept of individuals (humans) in different roles with different access privileges, 12) be flexible and extensible to accommodate for 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, 13) leverage knowledge of the existing SNMP management infrastructure. The system MUST leverage knowledge of and experience with MIBs and SMI. 4. Evaluation of COPS-PR/SoPI This section describes how COPS-PR meets the requirements listed in section 3. It also provides an introduction to COPS and the WG status. Keith McCloghrie provided the text for this section and his views are not necessarily shared by the co-authors of this document. 4.1 The COPS+SNMP solution: Introduction For the past decade, the use of SNMP and the Internet Management Framework has been used very successfully both to monitor devices and to set device-local configuration data in devices. The low-level access which SNMP provides has proved to be the appropriate level for these tasks. There are some improvements to SNMP which would be beneficial in performing these tasks, but the already-achieved success speaks to the fact that wholesale changes are not required. L. Sanchez, K. McCloghrie, J. Saperia [page 9] Internet Draft October 22, 1999 Indeed, any significant set of changes to SNMP would be detrimental to its stability. SNMP's most pressing need at this time is to get significant deployment of the recently approved SNMPv3 specifications, and stability will be a major factor in SNMPv3 being successfully deployed. Therefore, this COPS+SNMP solution uses SNMP as defined today (with whatever improvements can be made without causing instability) for the tasks of monitoring devices and setting small amounts of device-local configuration. These are the tasks for which SNMP was designed and to which it is well suited. However, the advent of policy-based configuration (as described in the preceding sections of this document) has introduced new requirements, many of which are listed in section 3 above. Today's SNMP has difficulty with many of these requirements, and thus, this COPS+SNMP solution uses COPS-for-Provisioning to meet the new policy-based requirements. COPS-for-PR is also aligned with the use of COPS for outsourcing; this is another requirement for policy-based management (but outside the scope of configuration management). The COPS framework defines the notion of Policy Servers, called Policy Decision Points (PDPs), and devices, called Policy Enforcement Points (PEPs). A PDP and a PEP communicate via the COPS protocol. The COPS protocol defines the notion of Client Types. The first Client-Type was defined for use in RSVP-outsourcing, i.e., with Integrated Services (IntServ), a router/PEP on receiving a RSVP message sends a request message to the PDP to ask for a policy decision concerning that RSVP message, and the PDP responds with a decision. With Differentiated Services (DiffServ), a router typically does not receive a signalling message telling it about the forthcoming packet stream; instead, it must be pre-loaded/provisioned with the policy decision ready for use when the packets arrive. For this provisioning of policy decisions/data, COPS-for-PR has been defined as a new COPS Client-Type. With COPS-for-PR, the network-wide policy/configuration data that a PDP downloads to a PEP is defined in Policy Information Bases (PIBs). New PIBs can be defined as and when necessary to extend the usage of COPS-for-PR to new data items without changing the protocol. This is the same strategy as MIBs provide for SNMP. In fact, the design of COPS-for-PR has purposely been defined to leverage as many SNMP strategies/mechanisms as are appropriate in meeting the new requirements. Further examples of this leverage are: - PIBs are defined using a variant of SNMP's SMI used to define MIBs; i.e., PIBs are easily recognizable to those engineers and operators who are already familiar with MIBs. The differences in the rules for defining a PIB are solely those needed for use with the COPS-for-PR protocol and network-wide policies/configuration. L. Sanchez, K. McCloghrie, J. Saperia [page 10] Internet Draft October 22, 1999 - PIBs define a "policy rule class", which is equivalent to a row definition in a MIB table, and a "policy rule instance" which is equivalent to a particular row in a MIB table. - PIBs name policy rule classes via OIDs (i.e., the same naming mechanism use in MIBs). The COPS model specifies that a single PDP has exclusive access to a PEP at any one time for a particular set of PIBs. The TCP connection used for the COPS protocol is initiated by the PEP to the IP-address of the PDP contained in the PEP's device-local configuration. This avoids the complications that SNMP has through allowing multiple Network Management Stations to have concurrent write-access to its MIBs. (See below for more details of how this works.) This section can obviously not go into full details of the protocols and PIB. The reader is encouraged to consult [COPS], [COPS-RSVP], [COPS-PR] and [PIB] for more details. 4.2 Does COPS-PR meet the requirements? The COPS+SNMP solution meets the requirements listed in section 3 as follows: 1. PIBs are defined to contain (higher-level) network-wide policies/configuration data, while MIBs continue to be used to define (lower-level) device-local data, both for configuration and monitoring, i.e., the same usage of MIBs as exists today. This separation of function between PIBs and MIBs provides clarity, and fosters understanding of, and focus on using the right tool for each task. 2. A significant difficulty with current Management Stations is the scalability problem (mentioned in an earlier section) of being able to keep up with the ever expanding set of devices-types, each of which has multiple versions supporting a different variety of low-level features, each with their own type of device-local configuration. With the COPS+SNMP solution, it is the network-wide configurations which are downloaded from the PDP into the devices, and the devices which perform the "Configuration Data Translator" function of translating the received network-wide configurations into the specific device-local configuration needed by the individual device. This eases the scalability problems of the PDP/Policy Server, since it can now concentrate on understanding the abstractions of the network-wide configurations and delegate the understanding of each device's low-level device-local configurations to that device itself. L. Sanchez, K. McCloghrie, J. Saperia [page 11] Internet Draft October 22, 1999 COPS-for-PR also defines a mechanism to upload from the PEP to the PDP the capabilities (and "roles", see [PIB] for more details) of the PEP. The particular items of capability data are defined in the PIBs (via the use of "notify" in a PIB's POLICY-ACCESS clause, see [PIB] for more details). The PDP uses the information provided by these capabilities to determine what subset of the (complete set of) network-wide policies that need to be downloaded into a particular device. That is, the PDP does not need to have a priori knowledge of what subset of policies are needed by particular device-types, which again helps to ease the scalability problem. 3. A particular device's capabilities (and "roles") are not only contained in a PIB, but also in a device's MIB. However, in the MIB, they are defined at a lower-level of granularity. For example, a PIB contains just the set of "roles" a device has; it is only in the MIB that "roles" are associated (configured) to individual interfaces. (This means that the PIB, and therefore, the PDP also, does not have to know all the details and names of the individual interfaces on a device.) It is these linkage mechanisms between the PIBs and the MIBs which enable a monitoring application to interpret the device-local configuration, status and monitoring information (contained in MIBs) within the context of network-wide configurations (contained in PIBs). For example, a monitoring application can determine how successful a particular policy associated with a "role", by summarizing the activity on all interfaces that have that "role". 4. COPS-for-PR provides for the installing of new policies or the modification of existing policies. It also provides for the deletion of previously downloaded policies, either an individual policy rule instance, or all policies within a particular OID subtree (which could potentially be all policies contained in the device). In addition, the PIB defines a "Policy Incarnation Table", this has a POLICY-ACCESS clause of "install-notify" which means that it is not only uploaded along with the device's capabilities, but the PDP is also able to store information into it. One of the items in this table is an Incarnation-id. This incarnation-id allows the PDP to set the value according to the current set of policies loaded into the PEP; it also allows a new PDP (e.g., a secondary PDP taking over from a failed primary) to know what is currently loaded into the PEP without needing to dump the whole or partial configuration. If a secondary PDP determined that it needed to restore a whole or partial set of configuration, it could delete those policies which are not wanted, and download the set of policies which are to be used instead. L. Sanchez, K. McCloghrie, J. Saperia [page 12] Internet Draft October 22, 1999 COPS-for-PR has also specified the potential of algorithmically converting a PIB into a read-only MIB. This read-only MIB would be available for reading via SNMP by a Management Station other the current PDP to query the device for its current configuration (i.e., the ability to dump the whole or a partial set of the policies contained in the device). Note that such a algorithmically-defined MIB would NOT be redundant with the existing device-local configuration MIB, as depicted in the Figure 3. | Defined | Algorithmically- | | by Human | converted | -----------------------------|----------|-------------------| Network-wide Configuration | PIB ---|--> read-only MIB | -----------------------------|----------|-------------------| Device-local Configuration | MIB | | ------------------------------------------------------------- Figure 3: Distinction between PIBs and MIBs 5. One of the advantages of COPS-for-PR over SNMP is its higher-level of access. This provides a much more efficient means than today's mechanisms (CLI, SNMP). This gain in efficiency is not only with respect to bandwidth, but also a reduced number of exchanged messages, and most significantly, a reduction in complexity. This is important for the ever increasingly large amounts of configuration data that today's devices need. While SNMP will still be used for device-local configuration, the amount of device-local configuration will be significantly reduced, since an increasing amount of it will be replaced by the downloading of network-wide configuration data via COPS-for-PR. One gain in efficiency over today's SNMP/CLI is the ability to load network-wide policies into a device and have those policies apply to multiple components of the device. For example, rather than having to load device-local configuration data for each individual interface, those interfaces which have the same function (same "role") can share the same network-wide configuration data, so that if twenty interfaces on a Wiring Closet switch all need the same configuration, then that configuration can be downloaded once, rather than twenty times. Other gains in efficiency over SNMP result from differences in the protocols: - COPS-for-PR uses TCP. - COPS-for-PR uses large messages, e.g., messages of up to 64kBytes (or longer) in length (without needing to suffer the disadvantages of IP fragmentation). L. Sanchez, K. McCloghrie, J. Saperia [page 13] Internet Draft October 22, 1999 - Large messages are efficient in multiple ways, including the ability of a PDP to download much more data as a single "transaction", which avoids the complications of downloading individual pieces one at a time and having to worry about the inconsistency of each incremental set of pieces. - COPS-for-PR access to policy data is at the granularity of a policy rule instance, (equivalent to a whole row in SNMP). COPS-for-PR does not provide access to individual leaf instances like SNMP does. - Atomic access to whole policy rule instances allows COPS-for-PR to name whole rows, not individual leaf instances. So, COPS messages include an OID naming the row, plus a vector of values, one for each value in the row. In contrast, SNMP messages contain a varbindlist, consisting of the name and value of each referenced columnar object in the row. This results in a significant difference in message size, since OIDs are notoriously long. For example, consider a row consisting of 10 integers, with OIDs of length 15 bytes, and integer values of length 2 bytes: this would use up 210 bytes of an SNMP message, but only 57 bytes in a COPS message. - Atomic access to whole policy rule instances also allows devices to process whole rows at a time, which is more efficient in processing, and produces less error/corner cases than when a row is received a few data values at a time. This results in less code, which is easier to implement and easier to test. Like COPS-for-PR, CLI access to a device also uses TCP and provides access only on a "per-row" basis, but it does so via human-understandable words, which is intrinsically less efficient than the transfer of binary information. 6. With the use of COPS being exclusively over TCP, COPS provides the following security choices: - a (mandatory to implement) COPS-specific message integrity object, providing authentication and replay protection, but not encryption. - IPSEC, providing per-host authentication and access-control, message integrity, replay protection and/or encryption; presumably sharing the same key distribution mechanism as other uses of IPSEC. - session level security mechanisms (SSL/TLS), which provide increased security (and increased overhead!!). Some of SNMP security's complications derive from the granularity of its authentication and authorization mechanisms: L. Sanchez, K. McCloghrie, J. Saperia [page 14] Internet Draft October 22, 1999 - for authentication, SNMP provides per-user granularity. - for access control, SNMP provides granularity to the object-level or instance-level, and to the types of allowed operations (read, write, etc.). These low levels of granularity are necessary when multiple network managers are using multiple network management stations to access multiple MIBs. Their design accommodates, for example, access from an on-call network manager in the middle of the night to fix network problems, as well as out-of-band management. In contrast, these low- levels are not needed in the COPS model where the PDP has exclusive access to the PEP. So, COPS is only required to provide per-IP-host authentication, and per-session access control. In the COPS model, the provision of different levels of access-control for various users having different operational responsibilities is performed by the PDP. All such users get access to devices via the PDP. The PDP itself has full access to all PIBs associated with its particular Client-Type. The PDP authenticates individual users and restricts their access according to their individual privileges. As a result, COPS security (including its configuration) is always simpler than SNMP's, and the reduced burden of configuring COPS security can sometimes be further reduced through its commonality with the security of other applications. Furthermore, the deployment of SNMP security faces the difficulty of overcoming the inertia of the installed base of SNMP systems which lack security. The deployment of COPS security will be a simpler task since security is included in its initial (standardized) specification. 7. COPS provides for downloaded policies to have an expiration time. This expiration time comes into play when a PEP looses its communication with its PDP, both its primary and any secondaries which might be defined for it. On loss of communication, the expiration timer is started and continues to run until communication with a PDP is re-established. If the expiration timer reaches the value of a policy's expiration time, then that policy expires. For example, security policies might need to have infinite expiration timers, so that they never time out. On the other hand, particular bandwidth reservations might have relatively small expiration times. 8. For failure recovery, COPS uses a Keep-alive mechanism to ensure that at least one message is exchanged over the TCP connection between the PEP and PDP within a timer value. If no message is received within the timer value, the connection is assumed to have failed and the PEP initiates a TCP connection to a Secondary PDP. L. Sanchez, K. McCloghrie, J. Saperia [page 15] Internet Draft October 22, 1999 For errors that occur in the downloaded policies, COPS provides not only a generic error code applicable to all types of policy rule classes, but allows individual policy rule classes to be defined (in the PIB) with their own individual error codes. These error codes are returned in a COPS Report message to the PDP. This ability to have errors specific to policy rule classes greatly simplifies the task of a PDP in diagnosing why a particular problem occurred. For example, if an "inconsistentValue" error needs to be returned, COPS-for-PR makes it possible for the PEP to specify what it is inconsistent with. 9. When multiple Management Stations have write access to a device's configuration, there is no mechanism to prevent one of them from undoing the configuration which was set by another, nor to prevent the configuration from any of them from being modified via the CLI. COPS grants a single PDP exclusive access to an associated set of PIBs. This is not only exclusive of other PDPs, but also exclusive of SNMP and the CLI. Of course, SNMP and/or the CLI is able to disable the use of COPS (via device-local configuration) if and when local control of the device is required (e.g., for emergency network debugging), but the PDP is informed of this through the closure of the COPS TCP connection. When COPS is enabled again, the TCP connection is re-established, and the PDP can restore the configuration to what the higher-level policies require it to be. This eliminates the potential for mis-configuration occurring through shared write access to the device's network-wide configuration. 10. Since all changes to the network-wide policies downloaded into a device are made by a single PDP, this PDP can keep a full audit log of all changes to the configuration. Assuming that the PDP makes these changes based on input from particular users, then the audit log can include the particular user who made each change. 11. As mentioned above, a PEP can be configured with a Primary PDP and a Secondary PDP, with the PEP connecting to the Secondary whenever it cannot reach the Primary. When two devices are used such that one is a backup for the other, they will likely both share the same network-wide configuration data to be downloaded either by the same PDP for both, or by their respective PDPs (which might share policies via the Directory). In the COPS model, the provision of different levels of access-control for various users having different operational responsibilities is performed by the PDP. All such users get access to devices via the PDP. The PDP itself has full access to all PIBs associated with its particular Client-Type. The PDP authenticates individual users and restricts their access according to their individual privileges. L. Sanchez, K. McCloghrie, J. Saperia [page 16] Internet Draft October 22, 1999 12. PIBs allow the definition of new policy rule classes, and the extension of existing policy rule classes. Procedures by which a PDP can interoperate with a PEP when they support different versions of a PIB are currently being added to the COPS-for-PR specification. Briefly, these will allow policy rule classes to be extended with additional columns; a PDP will know in advance the policy rule classes and their columns that the PEP supports through the uploading of the policyPrcSupportTable as part of the device capabilities, and can either take special actions or use the following default procedures: a PEP supporting more columns than a PDP will supply its own default values for any additional columns it receives; a PEP supporting fewer columns than a PDP will ignore any additional columns it receives; for obsolete columns, a PDP can supply a null value. The COPS protocol is inherently extensible in that it does not have fixed message formats except for its common message header (containing version, flags, op-code and Client-Type). The remainder of each message contains "objects" defined using a TLV format, such that new objects can be added to a particular message type, as and when that might be necessary. PIB objects are contained in Client-Specific objects defined for COPS-for-PR Client-Types. New message types can be added, and new data types can be added over time. Error codes are being defined such that if and when a PDP/PEP receives a message-type or data-type that it doesn't understand, it will report the occurrence as an error. 13. The design of COPS-for-PR has purposely been defined to leverage as many SNMP strategies/mechanisms as are appropriate in meeting the new requirements. Examples of this leverage are: - PIBs are defined using a variant of SNMP's SMI used to define MIBs; i.e., PIBs are easily recognizable to those engineers and operators who are already familiar with MIBs. The differences in the rules for defining a PIB are solely those needed for use with the COPS-for-PR protocol. - PIBs define a "policy rule class", which is equivalent to a row definition in a MIB table, and a "policy rule instance" which is equivalent to a particular row in a MIB table. - PIBs name policy rule classes via OIDs (i.e., the same naming mechanisms used in MIBs) - COPS-for-PR uses the same BER-encodings of OIDs and data values as SNMP uses. L. Sanchez, K. McCloghrie, J. Saperia [page 17] Internet Draft October 22, 1999 4.3 Status of COPS-PR The COPS protocol and the COPS-for-RSVP specifications have passed their Working Group Last Calls, and are awaiting approval by the IESG. The COPS-for-PR spec and an initial PIB are newer and have only recently become a topic of Working Group discussions. While its specification is complete enough such that several initial implementations have been completed, further details need to be defined and existing details will no doubt be refined as the specification progresses through the Working Group process. 4.4 Summary for COPS-PR The COPS+SNMP solution leverages SNMP for monitoring devices and for setting small amounts of device-local configuration data in devices. These are tasks for which its low-level of access has been very successful over the past decade. In addition, the COPS+SNMP solution adds the capability to download network-wide configuration data into devices through the use of COPS-for-PR, as a new "tool" in the Configuration Management toolkit. This tool provides for a higher-level of Configuration Management, which results in much-needed simplifications and efficiencies to the overall implementation and usage. This solution avoids the "swiss army knife" approach of having a single tool to perform all functions; instead, it defines a set of tools each tailored to perform their specific tasks well. 5. Evaluation of SNMP/SMI This section describes how SNMP meets the requirements listed in section 3. It also provides a list of possible areas where SNMP could be improved and the cost associated with implementing these improvements. Jon Saperia provided the text for this section and his views are not necessarily shared by the co-authors of this document. 5.1 Does SNMP/SMI meet the requirements? The SNMP solution meets the requirements listed in section 3 as follows: 1. For the purposes of this document SNMP is meant broadly in that it refers to the Internet Standard Management Framework which includes many components. See RFC 2570, Introduction to Version 3 of the Internet-standard Network Management Framework and RFC 2571, Architecture for SNMP Frameworks, for additional details. The current Structure of Management Information (SMI) in L. Sanchez, K. McCloghrie, J. Saperia [page 18] Internet Draft October 22, 1999 use by the Internet Standard Management Framework allows full expression of the required higher level (network-wide) configuration parameters. In addition, the Simple Network Management Protocol (SNMP), can carry this information without modification. Network-wide behaviors such as: for traffic of a particular type cause a particular action or behavior can easily be specified. An example is: for all inbound traffic marked with a Differentiated Services Code Point of a specific value, when forwarded over all interfaces in the router (or a specific sub-set), treat the traffic as high priority. High priority could be specified in the policy by a set of Weighted Fair Queue or other reasonable parameter combinations. Using this SNMP-based approach, policies (network-wide behaviors) would exist in MIB Groups/Tables. These behaviors would exist as entries which would have standard indices and sub-indices. The nature of the indices and sub-indices would be as required by the nature of the data elements (MIB Objects) used to specify the various network wide behaviors in the table(s). In addition, it is possible to have control tables activate one or many more than one of these behaviors at a time. All these capabilities are a function of MIB design. For those that use this approach, they can create and control policies with a minimum of data exchange between the configuration application and the managed device. Further, the use of control tables can be used to eliminate the need for the use of the row status textual convention for those that wish to avoid it's use. A control table could be a very simple table with the behavior index and an on/off control which would turn the entire policy on or off. A richer set of other attributes could also be implemented in the control table if desired such as policy refresh/time out values etc. 2. A consistent name space is essential to efficiently achieve this goal. Through the use of a common data definition language, the SMI, as a means of defining these network wide configuration parameters (policies) the 'translation' to the device local configuration becomes much easier. In effect what happens with this approach is that as one moves from the abstract to the specific, names get increasingly refined. In the most refined level they are instance specific object identifiers. Use of the standard SMI provides this ability to move from the very abstract to the specific efficiently for the computer systems since translation is not necessary given this integrated model. This consistency also aids the understanding of the people who will have to develop, debug, and deploy the technology. L. Sanchez, K. McCloghrie, J. Saperia [page 19] Internet Draft October 22, 1999 The requirement also states that the network wide configuration information sent to a device should be 'according to the capabilities' of the device. Many capabilities are already expressed in terms of the SMI, using this standard would facilitate the collection from the devices of their capabilities and reduce cost of implementation where the code for the capabilities already exists. An important feature of the SMI is its ability to represent scalar information which can be helpful when representing a devices capability set such as the queuing methods available, maximum sustained packet rate, etc. This capability will clearly be of benefit as the specification of network wide behavior increases. 3. To the extent that network wide configuration information uses a name space which is consistent with device local naming, and to the extent that the naming and retrieval mechanisms are compatible with the tools for retrieving and processing status such as fault or performance data, then the task of the management of network wide behavior is simplified. All the components of the SNMP Framework use this consistent name space which makes the achievement of this requirement much easier than with other approaches. It would be extremely difficult without writing large amounts of new code for both the end systems and the management application area to achieve these results. Below are some examples of network wide behavior which is only fully realizable when configuration data is integrated with capabilities of the device and performance and status information - an area that SNMP has been doing with increasing success for many years. - Reserve up to 50% of the networks capacity for 'preferential' treatment of traffic from one department to another. - In the event of a network/component failure, only allow a maximum of X packets or octets of data per unit of time to move through the network which are of low priority or 'best effort' service. - Give gold service (e.g., expedited forwarding) to certain kinds of traffic from a particular customer. This may be further refined with upper limits on the amount of traffic per unit time to pass through the network. The requirement and the examples above show the importance of the integration of all types of management data (e.g., fault, configuration, performance, security, etc.). In fact, the requirement is not achievable without this integration. The configuration management system must be capable of both expressing the desired network wide behavior and monitoring ongoing performance and status to verify operation within the specified behavior patterns. IP networks have achieved this level of integration in the past only through the use of labor intensive L. Sanchez, K. McCloghrie, J. Saperia [page 20] Internet Draft October 22, 1999 and expensive approaches, that is through the use of many very highly skilled individuals. The requirements in this document along with others will drive network operations to seek more automated and timely software based approaches. There are examples in other fields such as the telco industry and earlier proprietary network technologies where this type of integration has been realized. These examples all have had integrated solutions. SNMP is already widely deployed and used to collect information about utilization and is the method most often used to make an initial detection of a failure. There is a wide body of code in place to count packets, make interface status available, etc. through SNMP. Without a great deal of work any other approach would have to re-invent much of this capability. This capability [collection of fault and performance data] is just the start of being able to write software which will help simplify the task of management as networks become larger and more complex. Reinventing this capability will delay the ultimate goal of an integrated system suggested by the requirement. 4. It is inefficient to reconfigure an entire system based on a single change. The requirement above suggests that portions of a device can be (re)configured on an as needed basis. Once a device has been provisioned to be IP communicative (e.g., initial IP address), SNMP provides the capability to monitor or provision (add, modify, or delete) all or a portion of a system's configuration at a time. Further it has mechanisms when properly applied to help ensure that when partial configuration changes are made, inconsistent results to not occur. It is far more efficient to download a portion of a configuration when that is useful than all of it. The cost in not only in the network transfer but in the delay caused by the managed element while it 'parses' the new configuration information. In the case of downloading a network wide behavior to a device there is relatively little data since it is not 'instance specific'. There can be significant cost in converting the network wide behavior to the necessary instance specific values. There is no magic here, this conversion to instance specific information will have to take place regardless of the method used to send the network wide behavior to the managed system. If each time a change were needed, the entire configuration or a significant portion must be down loaded, there will be significant cost. The incremental approach used by SNMP helps avoid these costly major configuration events. The only way to reduce these large operations is to have more and more specialized separate 'policy servers' in the COPS/PIB approach - a management problem itself. L. Sanchez, K. McCloghrie, J. Saperia [page 21] Internet Draft October 22, 1999 This capability (partial download or modify/delete) is particularly important when there are failures in one or more of the network components, including the configuration application platforms. Since SNMP does not require a large resynchronization when a managed element looses contact with its manager(s) and vice versa, there is not the potential for oscillation in times of network stress that could occur when entire or large portions of (re)configurations are needed as with persistent connection based approaches. The other capability that the SNMP based approach allows is for 'emergency' type reconfigurations, even if they were to be done by a CLI. It will continue to be the case that network 'events' will happen and experts will need to tweak configurations a bit here and there to make the system regain normal operation. An SNMP based environment is well suited to this since it does not assume a single owner for each major type of configuration element (type of policy). There are SNMP based systems which exist today with the capability to have changes made from the CLI or other methods and which prevent the manager station multiple write condition feared in requirement 9. 5. SNMP is not used too widely today for configuration management. The most widely deployed configuration tool is the Command Line Interface. One of the problems with this approach is that it does not have a level of abstraction above the box (or standards to support it). As a result it is inefficient in many dimensions. It is inefficient because of the large number of configuration operations that are necessary to configure a system and it is inefficient because each implementation is different which prevents the development of standards. If we were to use SNMP and MIBs for policies as described under requirement 1, we could develop a wider range of standards while still allowing individual vendor distinctions. The term efficiency is not only a measure of the number round trips between a manager and a managed element required to configure it, it is a measure of how much work it will take to convert the high level network wide information into a form that is usable by the device. As noted previously, a common name space such as that offered by the SNMP aids in this efficiency. Control over one or more 'policies' with control tables as provided in the extant Management Framework also gives far more efficient control over the installation deletion and modification of policies on a managed device. With regard to efficiency of implementation, SNMP also offers significant benefits. These include the large knowledge base of people familiar with MIBs, their specification and implementation. In addition, the simple suggestion in requirement 1 which allows for a single simple communication between a manager and a managed device which may have potentially many instances created on the device not improves efficiency over the wire as previously described, it can improve efficiency of implementation for those who wish to write simple policies and not use the row status conventions. L. Sanchez, K. McCloghrie, J. Saperia [page 22] Internet Draft October 22, 1999 6. The administrative framework for SNMP has been specifically designed to meet all of the requirements in item 6. More importantly from a security perspective, some people feel that having the authentication and access control at the device granting the access is an inherently more secure method than when that authority is delegated across a network to other systems. The SNMP administrative features include the ability to control access at the user/role level. This is extremely important since some users would be allowed to modify some policies and others only to read them. Others might have access to a variety of sub sets. It is for this reason that managed systems should have local access control capabilities by users/roles rather than delegating this to a remote system to implement. This approach is not only more flexible, and in some views more secure, it is also more resilient in times of network stress when individuals might want to gain control of systems in a secure way from different locations. 7. This is an issue for the data an not a protocol. As such SNMP provides an excellent mechanism for this requirement. At whatever level of granularity is appropriate, expiration times can be set to any configuration element, even those that are network wide in scope very much like how the TTL in the SOA record works. The level of granularity and control is an issue of the MIB design. A MIB based approach to this requirement also allows for on-the-fly updates to the expiry value for a network wide or instance specific item which is not provided in other approaches. In certain circumstances the effective duration a policy might need to be extended. An example is the case of types of transit traffic to permit over certain links in failure conditions such as when an important peer has been lost. It is far more efficient to update a single value (perhaps from an authorized source which is NOT the main configuration application platform) than to reload the entire configuration or significant sub sets from a configuration application server. 8. Recent improvements to the SNMP protocol address the first part of this requirement, protocol error reporting. The second part of the requirement, the data specific part, can be met by design of the tables. A table which is indexed by set serial number and other index information could be constructed which makes it possible to include why the set failed - the data specific part. So the return could include not only that there was an 'inconsistent value' by why there was an inconsistent value. Also note that such a table would be retrievable even in times of network stress whereas having return information in a response PDU might be lost or lost in the event of a broken connection in a connection oriented approach. If the information were lost in transit, it could be retrieved via the MIB on the managed element. L. Sanchez, K. McCloghrie, J. Saperia [page 23] Internet Draft October 22, 1999 9. The current SNMP framework provides a number of mechanisms which address this requirement without imposing the significant restrictions of having only one manager in control at one time and the associated costs or manager change in the COPS/PIB approach. This [SNMP] approach also provides for user/role based authentication at the managed device which is far more flexible that IP address or host based authentication. Some of the mechanisms which address this requirement include the row status textual convention, context locking and the advisory locks which can be placed on tables which give clear indication of who is in control while allowing the flexibility to have another manager take over some or all of a system in a secure fashion when need arises. 10. The extant SNMP administrative framework provides for these capabilities. Systems have been built which track all levels of configuration change based on users and the machines from which they accessed the managed device. In effect an SNMPv3 based system can produce an 'audit' trail of who made changes, from where and when. SNMPv3 based systems also exist which can provide this information even when changes have been made with a CLI. Correctly implemented these two tools can coexist and compliment each other. For additional details on how the security mechanisms work please see the reference section. 11. As described in requirement 10, the existing SNMP provides for monitoring and control based on individuals and roles, not at a remote system but at the managed element itself. Additionally it has several features which further support this requirement. They include: - Use of informs sent to multiple sites based on configuration. This allows management staff to more rapidly know about failures of either the managed elements or the management systems. It also allows for rapid fall back in the case of management system failure. - Multiple destination addresses further reduce the likelihood of management system isolation as would be the case of only a single back up system. - The ability to perform 'trap directed polling' in the same name space as the configuration name space can improve time to fault isolation or determine the source of a configuration failure (see requirement 8). All of this is accomplished without the unnecessary instability created in a system where it is necessary to have extensive resync operations or reload significant portions of a devices configuration in the event of a communication loss with a single manager. L. Sanchez, K. McCloghrie, J. Saperia [page 24] Internet Draft October 22, 1999 12. This has been a feature of SNMP since its earliest stages. The OID assignment process allows for evolution without knowing what the changes would be. New software has been deployed without replacement/upgrade of large amounts of fielded network devices. Managers exist today which speak to devices with SNMPv1 which have never been upgraded (and are not likely to be) as well as the newest SNMPv3 devices. 13. The existing SNMP management infrastructure consists of several components which include: 1. The language for the definition of MIBs, the Structure of Management Information. 2. The extant standards-based MIBs. 3. The extant vendor specific MIBs. 4. The SNMP itself. 5. The public and private domain support for MIB writing and verification tools. 6. The public and private domain support for agent writing tools and utilities. 7. The public and private domain support for management applications. 8. Software Engineering expertise in all of the above areas 9. Network engineering and Network Operations Center Staff experience and training with the applications, tools, MIBs (data objects), etc. Clearly and SNMP based approach would leverage all these investments. Further the enhancements suggested are small and inexpensive in terms of computing, network and human resources. 5.2 Areas of Improvement for SNMP/SMI Clearly the evaluation above leads to the conclusion that; for configuration management, SNMP can be a very effective tool. This effectiveness extends to the domain of the configuration of network wide data (policy). As with all tools, as additional requirements arise, enhancements can be beneficial. SNMP as currently defined in the RFCs can meet all of the requirements listed in this document. Even the enhancement pointed to in requirement 1 can be accomplished without any change to the existing standards. Essentially it is a MIB design question. L. Sanchez, K. McCloghrie, J. Saperia [page 25] Internet Draft October 22, 1999 This is not to say that SNMP should remain static or that improvements would not be beneficial. Here are recommendations for the improvement to the Internet Standard Management Framework which would benefit not only the area of configuration management, but all areas served by the SNMP. 1. A new data type, any, which would allow any valid value to be returned and its value would be conveyed by it's type and value. 2. It would be nice to have people be members of multiple groups at a time. Now a group has to be created which is the union of all the security/access features desired for a set of people. This is a minor change. 3. The 'set history' table as described in requirement 8. This does not really require changes, just the specification of a standard way to do this function. 4. Standardization of transactions at a higher level than currently supported. There have been several studies on how this could be achieved. A review of these should be made and a single solution selected and standardized. 5. A more powerful way to specify 'aggregate' objects. 6. OID compression/Performance improvement. People have noted for some time that the OID can represent a significant amount of the total amount of data in an SNMP communication. There have been several methods proposed for improvement in this area as well. A study should be made in this area as well and the best choice selected. 5.3 Cost of Implementation for SNMP/SMI The costs for the suggested approach are to have been evaluated with respect to cost and time of implementation, impact on deployed systems and management staffs. Note that without change, the SNMP framework currently meets all the requirements so there is not incremental cost. Below is an investigation of costs for the suggested improvements to the SNMP. Taken in turn. The cost and time to implement these changes will be small since the potential solutions have already been discussed in some areas and prototypes of some are available. Their incremental computational cost is small, indeed some will reduce the computational and network cost of using SNMP. The biggest win is in using the method proposed in recommendation 1 (see section 5.2). This eliminates the need for instance level sets to configure much of a device and uses the framework we have today. As a result of this approach, impact on deployed systems and management staffs will be small. L. Sanchez, K. McCloghrie, J. Saperia [page 26] Internet Draft October 22, 1999 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", RFC2119, March 1997. [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol", draft-ietf-rap-cops-07.txt, work-in-progress, August 1999. [RSVP] Braden, R. ed. 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", draft-ietf-rap-cops-rsvp-05.txt, work-in-progress, June 1999. [COPS-PROV] Reichmeyer, F., Herzog, S., Chan, K., Durham, D., Yavatkar, R., Gai, S., McCloghrie, K., and A. Smith, "COPS Usage for Policy Provisioning", draft-ietf-rap-pr-00.txt, work-in-progress, June 1999. [PIB] Fine, M., McCloghrie, K., Seligson, J., Chan, K., Hahn, S., and A. Smith, "Quality of Service Policy Information Base", draft- mfine-cops-pib-01.txt, work-in-progress, June 1999. [SMIv2] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [TCv2] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [SNMP] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [SNMPTCP] Schoenwaelder, J., "SNMP-over-TCP Transport Mapping", draft-irtf- nmrg-snmp-tcp-01.txt, work-in-progress, June 1999. [SNMPCOMP] Schoenwaelder, J., "SNMP Compression", draft-irtf-nmrg-snmp-compression-00.txt, work-in-progress, June 1999. L. Sanchez, K. McCloghrie, J. Saperia [page 27] Internet Draft October 22, 1999 [USEC] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, January 1998. [VACM] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, January 1998. Disclaimer The views and specification here are those of the authors and are not necessarily those of their employers. The authors and their employers specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification. Copyright (C) The Internet Society (November 1997). 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. L. Sanchez, K. McCloghrie, J. Saperia [page 28] Internet Draft October 22, 1999 Author Information Keith McCloghrie Jon Saperia Cisco Systems, Inc. Independent Consultant 170 West Tasman Drive 174 Chapman Street San Jose, CA 95134-1706 Watertown, MA 02472 USA USA Email: kzm@cisco.com" Email: saperia@mediaone.net Phone: 408-526-5260 Telephone: +1 (617) 744-1079 Luis A. Sanchez BBN Technologies 10 Moulton Street Cambridge, MA 02138 USA Email: lsanchez@bbn.com Telephone: +1 (617) 873-3351 L. Sanchez, K. McCloghrie, J. Saperia [page 29]