[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04                                                
Network Working Group                                       C. Jacquenet
Internet Draft                                            France Telecom
Document: draft-jacquenet-ip-te-cops-04.txt                 January 2003
Category: Experimental
Expires July 2003


             A COPS client-type for IP traffic engineering
                  <draft-jacquenet-ip-te-cops-04.txt>


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026 [1].

   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 draft specifies a COPS (Common Open Policy Service) client-type
   designed for the enforcement of IP Routing and Traffic Engineering
   (TE) policies. The usage of this IP TE COPS client-type is based upon
   the activation of the COPS protocol for policy provisioning purposes.

Table of Contents

   1.      Introduction................................................2
   2.      Changes since the previous version..........................3
   3.      Conventions used in this Document...........................3
   4.      Terminology Considerations..................................3
   5.      The generic model of an IP routing/TE policy
             enforcement scheme........................................4
   6.      IP TE Client-Type Specific Information to be carried in
             COPS Messages.............................................6
   6.1.    Client-Type Field of the Common Header of every COPS
             Message...................................................7
   6.2.    COPS Message Content........................................7
   6.2.1.  Request Messages (REQ)......................................7

Jacquenet           Experimental - Expires July 2003            [Page 1]


Internet Draft   COPS Usage for IP Traffic Engineering     January 2003


   6.2.2.  Decision Messages (DEC).....................................8
   6.2.3.  Report messages (RPT).......................................8
   6.3.    Backward Compatibility Issues...............................9
   7.      COPS-PR Usage of the IP TE Client-Type.....................10
   8.      IANA Considerations........................................11
   9.      Security Considerations....................................11
   10.     References.................................................11
   11.     Acknowledgments............................................12
   12.     Author's Address...........................................12
   13.     Full Copyright Statement...................................13

1. Introduction

   The deployment of value-added IP services (such as quality-of-
   service-based IP Virtual Private Networks) over the Internet has
   become one of the most competing challenges for service providers, as
   well as a complex technical issue, from a (dynamic) resource
   provisioning perspective.

   From this perspective, the COPS protocol ([2]) and its usage for the
   support of Policy Provisioning ([3]) is one of the ongoing
   specification efforts of the Resource Allocation Protocol (rap)
   Working Group of the IETF that should help service providers by
   introducing a high level of automation for the dynamic production of
   a wide range of services and policies.

   Such policies include routing and traffic engineering policies. Such
   policies aim at appropriately provisioning, allocating/de-allocating,
   and using the switching and the transmission resources of an IP
   network (i.e. the routers and the links that connect these routers,
   respectively), according to a set of constraints like Quality of
   Service (QoS) requirements (e.g. rate, one-way delay, inter-packet
   delay variation, etc.) that have been possibly negotiated between the
   customers and the service providers, as well as routing metrics,
   which can reflect the network conditions.

   Within the context of this document, the actual enforcement of IP
   routing and traffic engineering policies is primarily based upon the
   activation of both intra- and inter-domain routing protocols (e.g.
   [4], [5], not to mention the use of multicast routing protocols [6])
   that will be activated in the network to appropriately select,
   install, maintain and possibly withdraw routes that will comply with
   the aforementioned QoS requirements and/or specific routing
   constraints, depending on the type of traffic that will be conveyed
   along these routes.

   It is therefore necessary to provide the route selection processes
   with the information that will depict the routing policies that are
   to be enforced within a domain and, whenever appropriate, the
   aforementioned constraints and metrics, given the dynamic routing
   protocols actually support traffic engineering capabilities for the
   calculation and the selection of such routes.

Jacquenet           Experimental - Expires July 2003            [Page 2]


Internet Draft   COPS Usage for IP Traffic Engineering     January 2003



   These capabilities are currently being specified in [7] and [8] for
   the OSPF (Open Shortest Path First, [4]) and the IS-IS (Intermediate
   System to Intermediate System routing protocol, [9]) interior routing
   protocols respectively, while there is an equivalent specification
   effort for the BGP4 (Border Gateway Protocol, version 4) protocol, as
   described in [10], for example.

   To provide the routers that will participate in the dynamic
   enforcement of an IP routing and/or traffic engineering policy with
   the appropriate configuration information (such as metrics' values),
   one possibility is to use the COPS protocol and its usage for policy
   provisioning. To do so, a new COPS client-type is specified, called
   the "IP Traffic Engineering" (IP TE) client-type, and this
   specification effort is the purpose of this draft.

   This document is organized into the following sections:

   - Section 4 introduces terminology as well as basic assumptions,
   - Section 5 introduces the generic architecture,
   - Section 6 defines the contents of the COPS messages that MUST
     include the IP TE client-type specific information,
   - Section 7 defines the usage of the IP TE client-type, including
     its mode of operation with the PDP (Policy Decision Point, [11])
     with whom a COPS communication has been established,
   - Finally, sections 8 and 9 introduce IANA and some security
     considerations, respectively.

2. Changes since the previous version

   The current version of this draft reflects the following changes:

   - Updated bibliography,

   - Re-wording of sections 1 and 6, to reflect the support of any kind
     of routing and/or traffic engineering policy more explicitly,

   - Correction of remaining typos.

3. Conventions used in this Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [12].

4. Terminology Considerations

   The enforcement of an IP routing/TE policy is based upon the
   processing of configuration information that reflects the
   characteristics of these policies (IGP metric values, BGP attributes'
   values, QoS requirements and/or constraints, etc.).


Jacquenet           Experimental - Expires July 2003            [Page 3]


Internet Draft   COPS Usage for IP Traffic Engineering     January 2003


   This information is called the "QoS-related" information within the
   context of this draft.

   Then, this QoS-related information must be taken into account by the
   routing processes that will participate in the calculation, the
   selection, the installation and the maintenance of the routes that
   will comply with the aforementioned requirements. The algorithms
   invoked by the routing processes take into account the cost metrics
   (whose corresponding values can possibly be inferred by a DSCP
   (DiffServ Code Point, [13]) value) that have been assigned by the
   network administrators.

   This metric-related information is called the "IP TE"-related
   information within the context of this draft.

   Thus, this draft makes a distinction between QoS-related information
   and IP TE-related information, where:

   - QoS-related information is negotiated between customers and
     service providers,

   - IP TE-related configuration information is dynamically provided to
     routers, and is exchanged between routers so that they can
     compute, select, install, and maintain the (traffic-engineered)
     routes accordingly.

   From this perspective, QoS-related information provides information
   on the traffic (both unicast and multicast) to be forwarded in the
   network (such as source address, destination address, protocol
   identification, DSCP marking, etc.), whereas IP TE-related
   information provides information for the routing processes that will
   indicate the routers of the network how to forward the aforementioned
   traffic, i.e. compute and select the routes that will convey such
   traffic.

   Given these basic assumptions, this draft aims at specifying a COPS-
   based IP-TE client-type that has the following characteristics:

   - The IP-TE client-type is supported by the PEP (Policy Enforcement
     Point) capability that allows a router to enforce a collection of
     policies, thanks to a COPS communication that has been established
     between the PEP and the PDP,

   - The actual enforcement of an IP routing/TE policy is based upon
     the TE-related configuration information that will be exchanged
     between the PDP and the PEP, and that will be used by the router
     for selecting, installing, maintaining and possibly withdrawing IP
     TE routes.

5. The generic model of an IP routing/TE policy enforcement scheme



Jacquenet           Experimental - Expires July 2003            [Page 4]


Internet Draft   COPS Usage for IP Traffic Engineering     January 2003


   The use of the COPS protocol for dynamically enforcing an IP
   routing/TE policy yields the generic model depicted in figure 1.

             +----------------+
             |                |
             |    IP Router   |
             |                |
             |     +-----+    |   COPS-PR     +-----+    +-----------+
             |     | PEP |<---|-------------->| PDP |<-->| IP TE PIB |
             |     +-----+    |               +-----+    +-----------+
             |        |       |
             |        |       |
             |     +-----+    |
             |     | LPDP|    |
             |     +-----+    |
             |        |       |
             |        |       |
             |    /-------\   |
             |    |       |   |
             | +-----+ +-----+|
             | | RIB |.| RIB ||
             | +-----+ +-----+|
             |    |       |   |
             |    |       |   |
             |    \-------/   |
             |        |       |
             |     +-----+    |
             |     | FIB |    |
             |     +-----+    |
             +----------------+

      Figure 1: Generic model of an IP routing/TE policy enforcement
                                  scheme.

   As depicted in figure 1, the routers embed the following components:

   - A PEP capability, which supports the IP TE client-type. The
     support of the IP TE client-type is notified by the PEP to the
     PDP, and is unique for the area covered by the IP routing/traffic
     engineering policy, so that the PEP can treat all the COPS client-
     types it supports as non-overlapping and independent namespaces,

   - A Local Policy Decision Point (LPDP), which can be assimilated to
     the routing processes that have been activated in the router. The
     LPDP will therefore contribute to the computation and the
     selection of the IP routes (see section 6 of this draft),

   - Several instances of Routing Information Bases (RIB), according to
     the different (unicast and multicast) routing processes that have
     been activated - one can easily assume the activation of at least
     one IGP (Interior Gateway Protocol, like OSPF) and BGP4,


Jacquenet           Experimental - Expires July 2003            [Page 5]


Internet Draft   COPS Usage for IP Traffic Engineering     January 2003


   - Conceptually one Forwarding Information Base (FIB), which will
     store the routes that have been selected by the routing processes,
     but this draft makes no assumption about the number of FIBs that
     can be supported by a router (e.g. within the context of an IP VPN
     (Virtual Private Network) service offering).

   As suggested in [14], the enforcement of an IP routing/traffic
   engineering policy is based upon the use of a policy server (the PDP
   in the above figure) that sends IP TE-related information towards the
   PEP capability embedded in the IP router.

   The IP TE-related information is stored and maintained in an IP TE
   Policy Information Base ([15]), which will be accessed by the PDP to
   retrieve and update the IP TE-related information whenever necessary
   (see section 6 of this draft).

   The IP TE-related information is conveyed between the PDP and the PEP
   thanks to the establishment of a COPS-PR connection between these two
   entities. The COPS-PR protocol assumes a named data structure (the
   PIB), so as to identify the type and purpose of the policy
   information that is sent by the PDP to the PEP for the provisioning
   of a given policy.

   Within the context of this draft, the data structure of the PIB
   refers to the IP routing/TE policy that is described in the PIB as a
   collection of PRovisioning Classes (PRC). Furthermore, these classes
   contain attributes that actually describe the IP TE-related policy
   provisioning data that will be sent by the PDP to the PEP. Some of
   these attributes consist of the link and traffic engineering metrics
   that will be manipulated by the routing processes being activated in
   the routers to compute the IP routes.

   The IP TE classes are instantiated as multiple PRI (PRovisioning
   Instance) instances, each of which being identified by PRovisioning
   Instance iDentifier (PRID). A given PRI specifies the data content
   carried in the IP TE client specific objects. An IP TE PRI typically
   contains a value for each attribute that has been defined for the IP
   TE PRC.

   Currently, the IP TE PIB has identified a per-DSCP IP TE PRC
   instantiation scheme, because the DSCP value conveyed in each IP
   datagram that will be processed by the routers privileges the notion
   of "DSCP-based" routing. Such a routing scheme aims at reflecting the
   IP routing/TE policies that have been defined by a service provider,
   assuming a restricted number of DSCP-identified classes of service
   that will service the customers' requirements.

6. IP TE Client-Type Specific Information to be carried in COPS Messages

   This section describes the formalism that is specific to the use of
   an IP TE client-type, given that only the COPS messages that require
   an IP TE client-type specific definition are described in this

Jacquenet           Experimental - Expires July 2003            [Page 6]


Internet Draft   COPS Usage for IP Traffic Engineering     January 2003


   section, i.e. the other COPS messages to be exchanged between a PEP
   that supports the IP TE client-type and a PDP, and which do not need
   to carry IP TE client-type specific information, are those described
   in the corresponding [2] and [3] documents, without any further
   elaboration.

   It must be noted that, whatever the contents of the COPS messages
   that MAY be exchanged between the PEP supporting the IP TE client-
   type and the PDP, the actual calculation, selection, installation,
   maintenance and possible withdrawal of IP routes in the router's FIB
   is left to the routers.

   Nevertheless, the information contained in the router's FIB MUST be
   consistent with the information contained in the IP TE PIB: this is
   done thanks to the synchronization features of the COPS architecture,
   as defined in [2].

6.1. Client-Type Field of the Common Header of every COPS Message

   All of the IP TE client-type COPS messages MUST contain the COPS
   Common Header with the 2-byte encoded Client-Type field valued with
   the yet-to-be assigned IANA number (see section 8 of this draft) for
   the IP TE client-type.

6.2. COPS Message Content

6.2.1. Request Messages (REQ)

   The REQ message is sent by the IP TE client-type to issue a
   configuration request to the PDP, as specified in the COPS Context
   Object. The REQ message includes the current configuration
   information related to the enforcement of an IP routing/TE policy.
   Such configuration information is encoded according to the ClientSI
   format that is defined for the Named ClientSI object of the REQ
   message.

   The configuration information is encoded as a collection of bindings
   that associate a PRID object and an Encoded Provisioning Instance
   Data (EPD).

   Such information MAY consist of:

   - The identification information of the router, e.g. the
     identification information that is conveyed in OSPF LSA (Link
     State Advertisement) Type 1 messages. The use of a loopback
     interface's IP address is highly recommended for the instantiation
     of the corresponding EPD,

   - The link metric values that have been currently assigned to each
     (physical/logical) interface of the router, as described in [4]
     for example. Such values MAY vary with an associated DSCP value,
     i.e. the link metric assigned to an interface is a function of the

Jacquenet           Experimental - Expires July 2003            [Page 7]


Internet Draft   COPS Usage for IP Traffic Engineering     January 2003


     DSCP value encoded in each IP datagram that this router may have
     to forward,

   - The traffic engineering metric values that specify the link metric
     values for traffic engineering purposes, as defined in [7], for
     example. These values MAY be different from the above-mentioned
     link metric values and they MAY also vary according to DSCP
     values.

6.2.2. Decision Messages (DEC)

   The DEC messages are used by the PDP to send IP TE policy
   provisioning data to the IP TE client-type. DEC messages are sent in
   response to a REQ message received from the PEP, or they can be
   unsolicited, e.g. subsequent DEC messages can be sent at any time
   after, to supply the PEP with additional or updated IP TE policy
   configuration information without the solicited message flag set in
   the COPS message header, since such messages correspond to
   unsolicited decisions.

   DEC messages typically consist of "install" and/or "remove"
   decisions, and, when there is no Decision Flags set, the DEC message
   includes the Named Decision Data (Provisioning) object.

   Apart from the aforementioned identification information, and
   according to the kind of (PRID, EPD) bindings that MAY be processed
   by the PEP (see section 6.2.1. of the draft), DEC messages MAY refer
   to the following decision examples:

   - Assign new link/traffic engineering metric values each time a new
     interface is installed/created on the router. These new values
     will obviously yield the generation of LSA messages in the case of
     the activation of the OSPF protocol, and/or the generation of BGP4
     UPDATE messages (e.g. in the case of a new instantiation of the
     MULTI_EXIT_DISC (MED) attribute). This will in turn yield the
     computation of (new) IP routes that MAY be installed in the
     router's FIB,

   - Modify previously assigned metric values, thanks to a
     remove/install decision procedure (this may yield a modification
     of the router's FIB as well, obviously),

   - Remove assigned metric values, e.g. the corresponding interfaces
     may not be taken into consideration by the routing algorithms
     anymore (or during a specific period of time, e.g. for maintenance
     purposes).

6.2.3. Report messages (RPT)

   The Report message allows the PEP to notify the PDP with a particular
   set of IP routing/TE policy provisioning instances that have been
   successfully or unsuccessfully installed/removed.

Jacquenet           Experimental - Expires July 2003            [Page 8]


Internet Draft   COPS Usage for IP Traffic Engineering     January 2003



   When the PEP receives a DEC message from the PDP, it MUST send back a
   RPT message towards the PDP. The RPT message will contain one of the
   following Report-Types:

   "Failure":    Notification of errors that occurred during the
                 processing of the (PRID, EPD) bindings contained in
                 the DEC message. Such a notification procedure can
                 include a failure report in assigning an updated value
                 of a given metric for example,

   "Success":    Notification of successful assignment of metric
                 values, and/or successful installation of IP routes in
                 the router's FIB. From this perspective, there MAY be
                 routes that will be installed in the router's FIB
                 without any explicit decision sent by the PDP to the
                 PEP w.r.t. the calculation/installation of the
                 aforementioned route. This typically reflects a normal
                 dynamic routing procedure, whenever route
                 advertisement messages are received by the router,
                 including messages related to a topology change. In
                 any case (i.e. whatever the effect that yielded the
                 installation of a route in the router's FIB), a RPT
                 message MUST be sent by the PEP towards the PDP to
                 notify such an event, so that the IP TE PIB will be
                 updated by the PDP accordingly.

   "Accounting": The accounting RPT message will carry statistical
                 information related to the traffic that will transit
                 through the router. This statistical information MAY
                 be used by the PDP to possibly modify the metric
                 values that have been assigned when thresholds have
                 been crossed: for example, if the RPT message reports
                 that x % of the available rate associated to a given
                 interface have been reached, then the PDP MAY send an
                 unsolicited DEC message in return, so that potential
                 bottlenecks be avoided.

6.3. Backward Compatibility Issues

   In the case where the IP network is composed of COPS-aware routers
   (which embed a PEP capability that supports the IP TE client-type),
   as well as COPS-unaware routers, the activation of a link state
   routing protocol (like OSPF) together with the reporting mechanism
   that has been described in section 6.2. of this draft addresses the
   backward compatibility issue.

   Indeed, the flooding mechanism that is used by the OSPF protocol for
   the propagation of the LSA messages assumes that, in particular, the
   COPS-aware routers will receive these update messages. Upon receipt
   of such messages, the PEP will have the ability to notify the PDP
   with the corresponding changes (e.g. by using a "Success" report-type

Jacquenet           Experimental - Expires July 2003            [Page 9]


Internet Draft   COPS Usage for IP Traffic Engineering     January 2003


   that will reflect the installation of new routes in the router's
   FIB), so that the IP TE PIB can be updated accordingly.

   The same observation can be made within the context of the activation
   of the BGP4 protocol, because of the iBGP full-mesh topology that is
   required to allow the routers of a given domain to get a homogeneous
   view of the "outside" world.

7. COPS-PR Usage of the IP TE Client-Type

   After having opened a COPS connection with the PDP, the PEP sends a
   REQ message towards the PDP that will contain a Client Handle. The
   Client Handle is used to identify a specific request state associated
   to the IP TE client-type supported by the PEP. The REQ message will
   contain a "Configuration Request" context object.

   This REQ message will also carry the named client specific
   information (including the (default) configuration information), as
   described in section 6.2.1.of the draft. Default configuration
   information includes the information available during the bootstrap
   procedures of the routers.

   The routes that have been installed in the router's FIB MAY be
   conveyed in specific (PRID, EPD) bindings in the REQ message as well.

   Upon receipt of the REQ message, the PDP will send back a DEC message
   towards the PEP. This DEC message will carry IP TE Named Decision
   Data object that will convey all the appropriate installation/removal
   of (PRID, EPD), as described in section 6.2.2 of this draft. One of
   the basic goals of this named Decision objects consists in making the
   routers enforce a given IP routing/TE policy.

   Upon receipt of a DEC message, the IP TE-capable PEP will (try to)
   apply the corresponding decisions, by making the network device (and
   its associated implementation-specific Command Line Interface, if
   necessary) install the named IP TE policy data (e.g. assign a metric
   value to a recently-installed interface).

   Then, the PEP will notify the PDP about the actual enforcement of the
   named IP TE policy decision data, by sending the appropriate RPT
   message back to the PDP. Depending on the report-type that will be
   carried in the RPT message, the contents of the message MAY include:

   - Successfully/unsuccessfully assigned new/updated metric values,

   - Successfully installed routes from the router's FIB. Note that the
     notion of "unsuccessfully installed routes" is meaningless,

   - Successfully/unsuccessfully withdrawn routes from the router's
     FIB. Route withdrawal is not only subject to the normal IGP and
     BGP4 procedures (thus yielding the generation of the corresponding
     advertisement messages), but also subject to named IP TE policy

Jacquenet           Experimental - Expires July 2003           [Page 10]


Internet Draft   COPS Usage for IP Traffic Engineering     January 2003


     decision data (carried in a specific DEC message), like those data
     related to the lifetime of a service.

   The RPT message MAY also carry the "Accounting" report-type, as
   described in section 6.2.3.of this draft.

8. IANA Considerations

   Section 6.1 of this draft has identified the need for the assignment
   of a specific number that will uniquely identify the IP TE client-
   type in every COPS message to be exchanged between a PEP and a PDP.

   This value SHOULD be chosen in the range of 0x8000 - 0xFFFF,according
   to a First Come First Served policy, as mentioned in both [2] and
   [16].

9. Security Considerations

   This draft specifies a new client-type that will make use of the COPS
   protocol for the provisioning and the enforcement of IP routing/TE
   policies. As such, it introduces no new security issues over the COPS
   protocol itself, or its usage for policy provisioning.

   Nevertheless, it is recommended that the IP-TE client-type
   systematically uses the Message Integrity Object (Integrity) for the
   authentication and the validation of every COPS message it may
   exchange with the PDP with whom it has established a COPS
   communication. The Message Integrity Object also prevents from replay
   attacks.

   In addition, the IP Security ([17]) protocol suite may be activated,
   and the IPSec Authentication Header (AH) should be used for the
   validation of the COPS connection, while the Encapsulated Security
   Payload (ESP) may be used to provide both validation and secrecy, as
   stated in [2].

10. References

   [1]  Bradner, S.,"The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.
   [2]  Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja R., Sastry
      A., "The COPS (Common Open Policy Service) Protocol", RFC 2748,
      Proposed Standard, January 2000.
   [3]  Ho Chan, K., Durham, D., Gai, S., Herzog, S., McLoghrie, K.,
      Reichmeyer, F., Seligson, J., Smith, A., Yavatkar, R., "COPS Usage
      for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.
   [4]  Moy, J.,"OSPF Version 2", RFC 2328, April 1998.
   [5]  Rekhter, Y., Li T., "A Border Gateway Protocol 4 (BGP-4)", RFC
      1771, March 1995.




Jacquenet           Experimental - Expires July 2003           [Page 11]


Internet Draft   COPS Usage for IP Traffic Engineering     January 2003



   [6]  Jacquenet, C., Proust, C., "An Introduction to IP Multicast
      Traffic Engineering", Proceedings of the ECUMN 2002 conference.
      See http://iutsun1.colmar.uha.fr/ECUMN02.html for further details.
   [7]  Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
      Extensions to OSPF", draft-katz-yeung-ospf-traffic-09.txt, Work in
      Progress, October 2002.
   [8]  Smit, H., Li T., "IS-IS Extensions for Traffic Engineering",
      draft-ietf-isis-traffic-04.txt, Work in Progress, December 2002.
   [9]  ISO/IEC 10589, "Intermediate System to Intermediate System,
      Intra-Domain Routing Exchange Protocol for use in Conjunction with
      the Protocol for Providing the Connectionless-mode Network Service
      (ISO 8473)", June 1992.
   [10] Jacquenet, C., "Providing Quality of Service Indication by the
      BGP-4 Protocol: the QOS_NLRI Attribute", draft-jacquenet-qos-nrli-
      04.txt, Work in Progress, March 2002.
   [11] Yavatkar, R., Pendarakis, D., Guerin, R., "A Framework for
      Policy-Based Admission Control", RFC 2753, January 2000.
   [12] Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.
   [13] Nichols K., Blake S., Baker F., Black D., "Definition of the
      Differentiated Services Field (DS Field) in the IPv4 and IPv6
      Headers", RFC 2474, December 1998.
   [14] Apostopoulos G., Guerin R., Kamat S., Tripathi S. K., "Server
      Based QOS Routing", Proceedings of the 1999 GLOBCOMM Conference.
   [15] Boucadair, M., Jacquenet, C., "An IP Forwarding Policy
      Information Base", draft-jacquenet-ip-fwd-pib-00.txt, Work in
      Progress, January 2003.
   [16] Alvestrand H., Narten T., "Guidelines for Writing an IANA
      Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
   [17] Atkinson R., "Security Architecture for the Internet Protocol",
      RFC 2401, August 1998.

11. Acknowledgments

   Part of this work is funded by the European Commission, within the
   context of the MESCAL (Management of End-to-End Quality of Service
   Across the Internet At Large, http://www.mescal.org) project, which
   is itself part of the IST (Information Society Technologies) research
   program.

   The author would also like to thank all the partners of the MESCAL
   project for the fruitful discussions that have been conducted so far
   within the context of the traffic engineering specification effort of
   the project, as well as MM. Boucadair and Brunner for their valuable
   input.


12. Author's Address

   Christian Jacquenet
   France Telecom Long Distance

Jacquenet           Experimental - Expires July 2003           [Page 12]


Internet Draft   COPS Usage for IP Traffic Engineering     January 2003


   3, avenue François Château
   CS 36901
   35069 Rennes CEDEX
   France
   Phone: +33 2 99 87 63 31
   Email: christian.jacquenet@francetelecom.com

13. Full Copyright Statement

   Copyright(C) The Internet Society (2003). 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 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.



















Jacquenet           Experimental - Expires July 2003           [Page 13]