Internet Draft Internet Engineering Task Force INTERNET-DRAFT July 2000 Francis Reichmeyer IPHighway Steven Wright BellSouth Mark Gibson Nortel Networks COPS Usage for MPLS/Traffic Engineering <draft-franr-mpls-cops-00.txt> 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 made obsolete 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.'' To view the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in an Internet-Drafts Shadow Directory, see http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This draft describes the application of the COPS for Provisioning (COPS-PR) protocol for managing MPLS and its traffic engineering functionality. A new COPS client type is described, the COPS-MPLS client type, and the use of the basic COPS messages by this client type is described. Reichmeyer, et. al. [Page 1] Internet Draft draft-franr-mpls-cops-00.txt July 2000 Table of Contents 1. Introduction.....................................................3 2. MPLS/TE Policy Management Model..................................5 3. COPS-MPLS Policy Management......................................6 3.1. COPS-MPLS Client Type.......................................6 3.2. MPLS/TE PIBs................................................7 3.3. Client Handles..............................................7 3.4. Request States..............................................8 4. COPS-MPLS Messages...............................................8 4.1. Protocol Objects............................................9 4.2. Request Message.............................................9 4.3. Decision Message............................................9 4.4. Report Message..............................................9 5. Common Operations...............................................10 6. Security Considerations.........................................12 7. References......................................................12 8. Author's Addresses..............................................13 9. Full Copyright Statement........................................13 Reichmeyer, et. al. Expires December 2000 [Page 2] Internet Draft draft-franr-mpls-cops-00.txt July 2000 1. Introduction This document describes how COPS can be used in an MPLS network for managing MPLS and Traffic Engineering. A new client type is described, the COPS-MPLS client type, which defines the usage of the COPS-PR protocol specification for MPLS and Traffic Engineering. Policy controls enable improved administrative control of network capabilities to meet service objectives. MPLS provides efficient explicit routing capabilities for IP networks, a key element in the traffic engineering of those networks. A goal of specifying a policy control protocol for MPLS is to enable improved network service implementations. A primary concern in traffic engineering is the classification and proper handling of different traffic within the network [TE/MPLS]. For example, forwarding certain flows along a path known to have the necessary resources for the type and amount of traffic in the flow, even if the path is different from the hop-by-hop routed path. The use of MPLS for traffic engineering requires configuring the LSRs in the network to support this type of TE functionality, then applying admission control policy at the ingress to the network to manage the usage of the resources. In general, there are two basic categories of policies for MPLS/TE management: LSP/tunnel management (or LSP life cycle) policies and LSP admission control (or flow management) policies. LSP/tunnel management policy deals with LSR configuration related to initiating, maintaining, and removing LSPs/tunnels. LSP admission control policy deals with classification directives for mapping data flows onto LSPs/tunnels according to characteristics of the data packets and traffic engineering objectives. In effect, these policies define finer-grained forwarding equivalence classes (FECs) for a tunnel and map them to a label for the tunnel. Policy management coordinates the two types of policy in the MPLS network and enables policy-based administration for a number of traffic engineering objectives e.g. protection, load distribution [LOAD- DIS], etc. MPLS supports explicit traffic engineering via several mechanisms that allow LSPs to be managed based on QoS and other constraints, for example [CR-LDP] and [RSVP-TE]. The architecture of the policy management system used to control MPLS/traffic engineering functionality should be independent of the MPLS mechanisms used. It is these mechanisms that we target with policy management. That is, the focus here is on managing MPLS mechanisms to provide consistent, predictable network services. Reichmeyer, et. al. Expires December 2000 [Page 3] Internet Draft draft-franr-mpls-cops-00.txt July 2000 Note that although LSPs can also be established via the LDP label distribution protocol, for the purpose of traffic engineering, this is less interesting and generally are not considered in the context of MPLS policy management. This may change in future versions of this draft if/when the scope of MPLS policy management is expanded beyond its current traffic engineering focus. Also, non-MPLS networks may in the future use COPS for managing some TE functions, but these are beyond the scope of the current draft. The CR-LDP and RSVP-TE label distribution mechanisms considered here share similar attributes that are exploited by the COPS-MPLS client specification. In the effort to achieve abstraction of policy throughout the policy management system, the details of the underlying MPLS label distribution should not affect the policy protocol (e.g. COPS-MPLS), though it will show up in the data model (e.g. MPLS/TE PIB) defined for use with the protocol. For example, the way in which LSP/tunnels are uniquely identified in the two label distribution mechanisms is different and since the policy system needs to identify LSP/tunnels for flow management policies, it needs to be aware of the different formats. This is done through the data model specifying classes and/or parameters specific to the use of CR-LDP or RSVP-TE. Also, then, if one of the MPLS mechanisms were to be extended or amended to support some new TE functionality in the future, the protocol need not change, just the data model. This example highlights the advantage of separating the protocol from the data model, as done, for example, with COPS-PR and PIBs. The primary benefit of policy-based networking within the context of MPLS networks is in the area of management of traffic engineering features and functions offered by the MPLS specifications. When we refer to MPLS policy, then, we are usually referring to configuration and policy management with respect to traffic engineering as achieved by MPLS mechanisms. That is, this draft does not consider general purpose configuration management for MPLS LSRs, just those mechanisms related to traffic engineering. Policy control for MPLS provides a richer environment for the creation of network services in an efficient manner. The use of a higher abstraction level policy specification provides a mechanism to abstract away some of the implementation options within MPLS, such as label distribution protocols used to create tunnels. While MPLS may be operated in an autonomous fashion, e.g. with topology driven LSP establishment, this does not necessarily provide the explicit routes and QoS required for traffic engineering. Also, while manual establishment of explicit route LSPs with associated QoS parameters may be feasible, this is expected to have some issues of scale, and consistency when applied in large networks. The COPS-PR protocol is well suited for MPLS and Traffic Engineering policy and configuration management. Separation of policy protocol (COPS-PR) and data model (e.g. PIB) accommodates the higher level abstraction required for MPLS policy control. Reichmeyer, et. al. Expires December 2000 [Page 4] Internet Draft draft-franr-mpls-cops-00.txt July 2000 Also, applying COPS-PR to the MPLS/TE environment allows us to re- use the existing work on Diff Serv policy management. This draft describes the application of COPS-PR for use in managing MPLS/TE in IP network environments. 2. MPLS/TE Policy Management Model When thinking about defining the COPS-MPLS client type and COPS usage for MPLS/TE policy management, we need to consider which policy management model is appropriate. For LSP admission control policy, the provisioning model of COPS-PR is a good fit. For LSP/tunnel management, however, the outsourcing model of COPS-RSVP might be considered since MPLS supports RSVP-TE for label distribution. Although RSVP-TE is supported in MPLS, this use of the RSVP protocol is slightly different than the way it is supported by COPS-RSVP. In MPLS, an RSVP-TE session is initiated by an edge LSR, as opposed to an end station. This implies that the initiating LSR must be configured or somehow directed to start the session by sending a Path message to the appropriate destination. A natural place to decide to setup an LSP/tunnel, and tell the LSR to initiate the setup, is in the PDP. But COPS-RSVP is designed for the PDP to issue policy decisions based on requests triggered by RSVP messages received at edge routers. For the PDP to initiate the RSVP-TE session, it needs to send an unsolicited message to the LSR containing the parameters for the Path message, such as resource requirements, explicit route information, etc. Sending this unsolicited decision fits more closely with the provisioning model of COPS-PR. In MPLS, with RSVP-TE, the PEP does not necessarily outsource a policy decision with regards to allowing the reservation since, as discussed above the PDP initiates the reservation. For example when a Resv message is received at an ingress LSR, the router notifies the PDP that resources have (or have not) been reserved for a tunnel but does not necessarily need to ask the PDP if it should be allowed. The PDPÆs decision, then, is not whether to accept or deny the reservation request, but to issue a LSP admission control policy for the tunnel. Thus, although RSVP-TE is supported in MPLS, the policy management model it calls for is different than that of COPS-RSVP and is more similar to the COPS-PR model. So, COPS-MPLS described in this draft is based on COPS-PR. Both CR-LDP and RSVP-TE label distribution mechanisms may potentially need to be supported in an MPLS network. At the policy protocol level, the details of whether one mechanism or the other, or both, are used to establish a tunnel should be abstracted away. What are of interest is the ability for policy control to: - establish the tunnel with some set of constraints Reichmeyer, et. al. Expires December 2000 [Page 5] Internet Draft draft-franr-mpls-cops-00.txt July 2000 - uniquely identify the tunnel - define flow management policy for the tunnel. Using the provisioning model of COPS-PR and separate data model, for example an MPLS/TE PIB, allows us to isolate the details of the label distribution mechanism in the data model. The LSR notifies the PDP of the label distribution mechanism(s) it supports, for example by advertising its capabilities to the PDP, and the PDP provides decisions including the parameters needed by that mechanism. The LSR then uses the data to initiate the tunnel with whichever mechanism it supports. This also makes it easier to expand support for new traffic engineering features that may be added to MPLS in the future, by updating just the data model and not the protocol. Also, it is already necessary to define a COPS-PR based protocol and data model for COPS-MPLS to support packet classification for LSP admission control policy, and LSR capability notification to the PDP. So extending that model for general LSP/tunnel policy saves the work and confusion of defining two policy management protocols for MPLS/TE policy. 3. COPS-MPLS Policy Management This section describes the application of COPS-PR protocol features to the COPS-MPLS policy management model. 3.1. COPS-MPLS Client Type The COPS-PR architecture [COPS-PR] provides the flexibility to define different client types that can all make use of the COPS-PR protocol specification and policy management model. Differentiation among client types is made when the COPS client in the PEP (Policy Enforcement Point) opens a connection to the COPS server in the PDP (Policy Decision Point), specifying the client type. Each client type uses the basic COPS messages to exchange general and client specific policy information between the PDP and PEP. In an MPLS environment, the PEP resides in the LSRs (Label Switch Routers) that require a connection to the policy server. A router MAY contain multiple COPS clients of different type, e.g a Diff Serv provisioning client, COPS-MPLS client, etc., depending on the different functions the router performs in the network (Diff Serv router, LSR, etc.) Each client opens a separate COPS connection to the PDP, over a single TCP connection using the Client-type to distinguish between them [COPS]. An LSR opening a connection to a PDP for MPLS/TE policy management MUST use the COPS-MPLS Client- type defined here. The COPS client type is used to differentiate between different types of policy data that will be exchanged between a COPS client and COPS server. For example, different classes of policy data, as defined in the PIB [FRAME-PIB], are accessed by different COPS Reichmeyer, et. al. Expires December 2000 [Page 6] Internet Draft draft-franr-mpls-cops-00.txt July 2000 client types. In the case of the COPS-MPLS client type, there will be defined, in a separate draft, the appropriate policy data model in the form of an MPLS/TE PIB. 3.2. MPLS/TE PIBs As part of the specification of COPS usage for MPLS and TE, we need to define the data model for the MPLS/TE policy information exchanged between the PEP and PDP. One possible data model will be defined in an accompanying MPLS/TE PIB draft [MPLS-PIB]. Other data models may be defined as well. MPLS/TE PIBs specify the data content carried in COPS-MPLS client specific objects. For example, QoS constraints, explicit route information, and other parameters for LSP tunnel configuration are carried in COPS Decision messages to tell an edge LSR to initiate the tunnel setup. MPLS-specific device capabilities may also be defined in the MPLS/TE PIB. For example information about label spaces used by the LSR, or label distribution mechanism(s) supported, may be sent to the PDP by the LSR in the initial Request message. The PDP could then use this information when generating policy decisions that affect the LSR. MPLS/TE PIBs are also used for coordinating MPLS policy and other related policy, such as Diff Serv, on an interface via the specification and distribution of policy rules based on roles and interface types. The intent when defining the MPLS/TE PIB classes is to make use of existing PIB modules already defined for Diff Serv [DS-PIB] as well as those defined for all COPS-PR client types [FRAME-PIB]. Indeed, the MPLS/TE PIB should contain extensions to those PIBs, using the mechanisms defined in the SPPI [SPPI]. For example, it should be possible to define MPLS/TE PIB classes for LSP admission control policies by extending the qosIpAce class to include classification on incoming label, and the qosAction class, to include assigning MPLS labels to packets for a created LSP tunnel. Other extensions would be likely, as well. As previously discussed, the MPLS/TE PIB needs to contain classes and parameters specific to the different MPLS technologies, such as CR-LDP and RSVP-TE, to be flexible enough to handle cases where the mechanisms differ. An example of this includes the different information that can be carried in the "LSP/tunnel initiation" message (i.e. Label Request or Path). Support for specifying named path (LSP-ID) in the explicit route specification vary, as does support for carrying objects to record the route (RRO) taken by the LSP/tunnel through the network. 3.3. Client Handles COPS-MPLS follows the Client Handle usage as defined in COPS-PR. After opening a COPS connection to the PDP, the PEP sends a REQ (config-request) to the PDP containing a Client Handle which is Reichmeyer, et. al. Expires December 2000 [Page 7] Internet Draft draft-franr-mpls-cops-00.txt July 2000 unique to that COPS-MPLS client. In return, the PDP sends policy DECs to the PEP using that same handle. The PEP may send multiple config-requests for the COPS-MPLS client and may receive policy from the PDP for any of them. Each config-request corresponds to a separate request state (see next section) and has a unique Client Handle associated with it. The PDP must send MPLS policy decisions to the PEP using the Client Handle for the appropriate request state. 3.4. Request States COPS-PR supports the notion of the PDP configuring policy information for different request states at the PEP. That is, policy decisions can be installed for separate virtual policy stores associated with different request states, for example different time of day, day of week, etc. Then, the PDP can instruct the PEP to switch request states, activating the policy configuration of one and de-activating another. Only one request state may be active at any time. In the COPS-MPLS case, switching contexts may result in the need to tear down LSP tunnel(s) associated with the policy for one request state and establish new tunnels associated with the configuration of the new request state. In addition, flow management policies for a new request state may also be desirable. However, if a policy rule is dependent on a label or tunnel identifier from a previous policy decision, and that decision is not active in the current request state, the policy rule cannot be installed (results in an error returned to the PDP). When a request state switch occurs, an attempt to install a flow management policy that references a label or tunnel identifier that has not been previously established for that request state MUST result in an error message sent by the PEP to the PDP. Upon processing the error, the PDP MAY instruct the LSR revert back to the previous request state or it MAY issue additional DECs to address the error(s) reported. 4. COPS-MPLS Messages This section describes the usage of the COPS protocol messages for the COPS-MPLS client type. Message types not described here require no client specific definition and are to be implemented according to the COPS-PR [COPS-PR] and/or COPS base protocol [COPS] specifications. COPS-MPLS messages MUST contain: Client-type = "COPS-MPLS Client" in the Client-type field of the COPS Common Header (number to be assigned). Reichmeyer, et. al. Expires December 2000 [Page 8] Internet Draft draft-franr-mpls-cops-00.txt July 2000 4.1. Protocol Objects COPS-MPLS messages use the client specific message content and protocol objects as specified in [COPS-PR]. 4.2. Request Message The Request (REQ) message is used after the PEP has first established COPS connectivity with the PDP, to notify the PDP of the LSRÆs capabilities and limitations with regard to MPLS/TE functionality. The REQ is sent with the æconfiguration requestÆ context flag in the Context object. Multiple REQ messages can be sent by the PEP to open multiple policy request states. Each request state gets associated with a unique Client Handle, chosen by the COPS-MPLS client, included in the REQ message. COPS-MPLS policy request data is carried in the Named ClientSI request data object. The format of this object is defined by theobject, for REQ, in [COPS-PR]. 4.3. Decision Message The Decision (DEC) message is used by the PDP to send LSP tunnel and flow management policy decisions to the PEP. For setting up LSP tunnels, the PDP sends a DEC to the PEP with the QoS resource requirements for the tunnel, explicit route information, if applicable, and an æInstallÆ Decision Flags object. The PEP MUST respond with a Report message containing either æFailureÆ or æSuccessÆ Report-Type object indicating whether the tunnel was established or not. When tearing down a tunnel, the PDP sends a DEC with æRemoveÆ Decision Flags object and reference to the existing policy to be removed. For MPLS admission control policies, the PDP sends a DEC to the PEP with flow classification information and MPLS/TE policy action, for example assigning a label, or labels, to forward the traffic onto a particular LSP tunnel. The PEP MUST respond with a Report message containing either æSuccessÆ or æFailureÆ Report-Type object indicating whether the policy rule(s) were successfully installed at the LSR. The Client Handle used in the DEC message MUST corresponds to a Client Handle sent in a REQ by the PEP to the PDP. COPS-MPLS policy decision data is carried in the Named Decision Data object. The format of this object is defined by the object in [COPS-PR]. 4.4. Report Message The Report (RPT) message is used by the PEP to acknowledge DEC messages sent by the PDP and report LSP performance monitoring Reichmeyer, et. al. Expires December 2000 [Page 9] Internet Draft draft-franr-mpls-cops-00.txt July 2000 information for traffic engineering purposes. The PEP must send a RPT in response to a DEC message from the PDP. When the PEP receives a DEC for a LSP tunnel policy, a RPT message must be returned indicating: - Failure: notification of errors/warnings that occurred in processing the DEC message or in establishing the LSP tunnel - Success: notification of successful establishment of LSP tunnel (including tunnel identifier and other relevant information). When the PEP receives a DEC for a MPLS admission control policy, a RPT message must be returned indicating: - Failure: notification of errors/warnings that occurred in processing the DEC message or installing the policy at the LSR - Success: notification of successful installation of the policy. Monitoring tunnel performance is critical to the traffic engineering process. The PEP can perform LSP monitoring and send performance information to the PDP in a RPT message, with Report- Type = æAccountingÆ. This monitoring information may be used by the PDP in making adjustments to the current MPLS network configuration as well as in future MPLS-related policy decisions. The æAccountingÆ RPT message is also used to send other state and network information to the PDP, that is relevant to the MPLS policy controlled by the PDP. COPS-MPLS policy report data is carried in the Named ClientSI request data object. The format of this object is defined by the object, for RPT, in [COPS-PR]. 5. Common Operations COPS-MPLS is based on the COPS-PR policy management model. In COPS-MPLS, PEPs reside at LSRs that are to interact with the PDP. The PEP establishes a connection with the PDP as described in [COPS-PR] and sends a REQ (config-request) to the PDP. The REQ contains capabilities and limitations of the LSR with respect to MPLS/TE policy management and a unique Client Handle for the client request state. The PDP responds with policy DECs for the COPS-MPLS client. LSP tunnels are established by the PDP sending an æInstallÆ DEC to the PEP that is the ingress edge LSR (E-LSR) for the tunnel. The COPS-MPLS Named Decision Data object carries the MPLS policy data for setting up the tunnel, such as the label distribution mechanism to be used, and appropriate QoS constraints and explicit route information. The PEP processes the DEC and, if no errors are found, such as invalid protocol objects, etc., proceeds to attempt to establish the tunnel across the network. Reichmeyer, et. al. Expires December 2000 [Page 10] Internet Draft draft-franr-mpls-cops-00.txt July 2000 When the ingress LSR receives notification that the tunnel is successfully established, e.g. via either Label Mapping message or Resv message, depending on the label distribution protocol used, the PEP sends a RPT to the PDP. The æSuccessÆ Report-Type is used and the Named ClientSI Report object carries the information being reported by the PEP. In response to a tunnel set up policy DEC, the RPT message SHOULD contain a tunnel identifier, label used to forward traffic to the next-hop LSR in the tunnel and possibly any return route information specifying the exact path taken by the tunnel. If notification is received by the E-LSR that the tunnel could not be set up, the PEP sends a RPT with a æFailureÆ Report-Type and information on the error that occurred. For example, a path with the specified QoS constraints may not have been available or one of the nodes in the explicit route may not have sufficient resources available. The PDP, upon receiving a æSuccessÆ RPT, may then send DECs to the PEP with MPLS flow management policy for the existing tunnel. The Named Decision Data contains classification information, similar to that used for Diff Serv QoS policy, specifying data flows and conditions for forwarding the flows over the tunnel. The policy rule actions specified in these policy DECs MAY include applying a certain label associated with the tunnel. The PEP processes these DECs and replies with a RPT indicating success or failure in installing the policy. Tunnel performance measurements, taken by the LSR(s) along the path of a tunnel, are reported by the PEP to the PDP by sending RPT messages containing the æAccountingÆ Report-Type and appropriate measurement data/statistics in the COPS-MPLS Named ClientSI Report object. Over the life of the tunnel, performance is measured and analyzed by the PDP for traffic engineering and planning and for making incremental changes to the configuration as necessary. Changes to existing tunnels are made by the PDP sending a DEC that references an existing tunnel policy, but specifies new parameters for the tunnel. The PEP processes the changes as before and replies with a RPT to the PDP. Changes to MPLS flow management DECs are made in a similar manner, by the PDP sending a DEC with the new parameters. To delete a tunnel, the PDP sends a æRemoveÆ DEC to the ingress E- LSR of the tunnel. The PEP processes the DEC and tears down the tunnel by issuing the appropriate label distribution protocol message, Path Tear if RSVP-TE, or Label Release if CR-LDP, to the next-hop LSR. A RPT message from the PEP indicates whether the tunnel was successfully removed. Prior to deleting a tunnel, all MPLS flow management policies that reference the tunnel, for example via label assignment or tunnel identifier, should be removed first. This is to avoid the timing problem of an E-LSR Reichmeyer, et. al. Expires December 2000 [Page 11] Internet Draft draft-franr-mpls-cops-00.txt July 2000 enforcing a flow classification policy and assigning a label to a packet for a LSP tunnel which has been removed. 6. Security Considerations The use of COPS for MPLS/TE introduces no new security issues over the base COPS protocol [COPS] or COPS-PR protocol [COPS-PR]. The security mechanism described in [COPS] should be deployed in a COPS-MPLS environment. 7. References [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., Sastry, A., "The COPS (Common Open Policy Service) Protocol," RFC 2748, January 2000. [COPS-PR] Chan, K., Durham, D., Gai, S., Herzog, S., McCloghrie, K., Reichmeyer, F., Seligson, J., Smith, A., Yavatkar, R., "COPS Usage for Policy Provisioning," draft-ietf- rap-cops-pr-02.txt, March 2000. [CR-LDP] Jamoussi, B., et. al., "Constraint-Based LSP Setup Using LDP," draft-ietf-mpls-cr-ldp-03.txt, September 1999. [DS-PIB] Fine, F., McCloghrie, K., Seligson, J., Chan K., Hahn, S., Smith, A., Reichmeyer, F., "Differentiated Services Quality of Service Policy Information Base," draft-ietf- diffserv-pib-00.txt, March 2000. [FRAME-PIB] Fine, F., McCloghrie, K., Seligson, J., Chan K., Hahn, S., Smith, A., Reichmeyer, F., "Framework Policy Information Base," draft-ietf-rap-frameworkpib-00.txt, March 2000 [LOAD-DIS] Wright, S., Jaeger, R., Reichmeyer, F., "Traffic Engineering of Load Distribution," draft-wright-load- distribution-00.txt, July 2000. [MPLS-PIB] "MPLS/Traffic Engineering Policy Information Base," work in progress. [RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Swallow, G., Srinivasan, V., "RSVP-TE: Extensions to RSVP for LSP Tunnels," draft-ietf-mpls-rsvp-lsp-tunnel-05.txt, February 2000. [SPPI] McCloghrie, K., et. al., "Structure of Policy Provisioning Information," draft-ietf-rap-sppi-00.txt, March 2000. [TE/MPLS] Awduche, D., et. al., "Requirements for Traffic Engineering over MPLS," RFC 2702, September 1999. Reichmeyer, et. al. Expires December 2000 [Page 12] Internet Draft draft-franr-mpls-cops-00.txt July 2000 8. Author's Addresses Francis Reichmeyer IPHighway, Inc. 55 New York Ave. Framingham, MA 01701 Phone: +1 201 665 8714 Email: franr@iphighway.com Steven Wright Science & Technology BellSouth Telecommunications 41G70 BSC 675 West Peachtree St. NE. Atlanta, GA 30375 Phone +1 (404) 332-2194 Email: steven.wright@snt.bellsouth.com Mark Gibson Nortel Networks Harlow Laboratories, London Rd. Harlow, Essex UK CM17 9NA Phone: +44(0)1279 402621 Email: mrg@nortelnetworks.com 9. Full Copyright Statement Copyright (C) The Internet Society (2000). 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 assignees. 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. Reichmeyer, et. al. Expires December 2000 [Page 13]