Internet DRAFT - draft-franr-mpls-cops


   Internet Engineering Task Force 
   July 2000 
                                                       Francis Reichmeyer 
                                                            Steven Wright 
                                                              Mark Gibson 
                                                          Nortel Networks 

                   COPS Usage for MPLS/Traffic Engineering 


   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 

     To view the current status of any Internet-Draft, please check the 
     ``1id-abstracts.txt'' listing contained in an Internet-Drafts 
     Shadow Directory, see 

   Copyright Notice 

     Copyright (C) The Internet Society (2000).  All Rights Reserved. 



     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 

     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 

     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 

     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 

   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] 

     COPS-MPLS messages MUST contain: 

        Client-type = "COPS-MPLS Client" 

     in the Client-type field of the COPS Common Header (number to be 

   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 the 
     <Named ClientSI: Provisioning> object, 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 <Named 
     Decision Data: Provisioning> 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 
     <Named ClientSI: Provisioning> 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 

     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 

     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 

     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 

     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                                        

     Steven Wright                                                
     Science & Technology                                       
     BellSouth Telecommunications                                    
     41G70 BSC                                                         
     675 West Peachtree St. NE.                                   
     Atlanta, GA 30375                                              
     Phone +1 (404) 332-2194                                        

     Mark Gibson                                                   
     Nortel Networks                                               
     Harlow Laboratories, London Rd.                               
     Harlow, Essex UK CM17 9NA                                     
     Phone: +44(0)1279 402621                                      


   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 

   Reichmeyer, et. al.      Expires December 2000                [Page 13]