[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04                                                
               Network Working Group                                       C. Jacquenet
               Internet Draft                                        France Telecom R&D
               Document: draft-jacquenet-ip-te-cops-00.txt                November 2000
               Category: Experimental
               Expires: May 2001
               
               
                             A COPS client-type for IP traffic engineering
                                  <draft-jacquenet-ip-te-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 RFC 2026 [11].
               
                  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, [2])client-
                  type designed for the enforcement of IP Traffic Engineering (IP TE)
                  policies within IP networks. The usage of this IP TE COPS client-type
                  is based upon the activation of the COPS protocol for policy
                  provisioning purposes (COPS-PR, [3]).
               
               1. Introduction
               
                  The deployment of value-added IP services (like 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, as far as the appropriate provisioning and
                  usage of the resources of the IP networks is concerned.
               
                  From this standpoint, the COPS protocol and its usage for the support
                  of Policy Provisioning is one of the ongoing specification effort of
                  the Resource Allocation Protocol (rap) Working Group of the IETF that
                  should help service providers in dynamically enforcing an IP Traffic
               
               Jacquenet           Experimental - Expires May 2001            [Page 1]


               Internet Draft   COPS Usage for IP Traffic Engineering        Nov. 2000
               
               
                  Engineering (IP TE) policy which appears to be one the key components
                  for the massive development of the above-mentioned IP services.
               
                  Indeed, an IP traffic engineering policy aims 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 the
                  Quality of Service (QoS) requirements (e.g. bandwidth, delay, jitter,
                  etc.) expressed by the customers who can access such resources within
                  the context of a given service subscription procedure ([4]), among
                  other considerations (like network dimensioning and planning, for
                  example).
               
                  Within the context of this document, the actual enforcement of an IP
                  traffic engineering policy is primarily based upon the activation of
                  both intra- and inter-domain dynamic routing protocols ([5], [6])
                  that will be activated in the network to appropriately select,
                  install, maintain and possibly withdraw routes that will comply with
                  the above-mentioned 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 exactly reflect these QoS
                  requirements, given the dynamic routing protocols support traffic
                  engineering capabilities for the calculation and the selection of
                  such routes. These capabilities are currently being specified in [7]
                  and [8] for the OSPF (Open Shortest Path First, [5]) and the IS-IS
                  (Intermediate System to Intermediate System routing protocol, [9])
                  interior routing protocols respectively, while there is an equivalent
                  and ongoing specification effort for the BGP4 (Border Gateway
                  Protocol, version 4) protocol, as described in [10], for example.
               
                  To provide the route selection processes with the above-mentioned
                  information, one possibility is to use the COPS protocol and its
                  usage for policy provisioning. To do so, a new COPS client-type is
                  specified, 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 3 introduces terminology as well as basic assumptions,
                  - Section 4 introduces the generic architecture,
                  - Section 5 defines the contents of the COPS messages that MUST
                  include the IP TE client-type specific information,
                  - Section 6 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 7 and 8 introduce IANA and some security
                  considerations, respectively.
               
               
               
               Jacquenet           Experimental - Expires May 2001            [Page 2]


               Internet Draft   COPS Usage for IP Traffic Engineering        Nov. 2000
               
               
               2. 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].
               
               3. Terminology considerations
               
                  The enforcement of an IP traffic engineering policy is based upon the
                  processing of the information that reflects the QoS requirements
                  expressed by a customer during a service subscription procedure. Such
                  a procedure can be gracefully based upon a Service Level
                  Specification (SLS) template that will be negotiated between the
                  customer and the provider, as described in [4]. From this standpoint,
                  such QoS requirements can be expressed in terms of bandwidth, delay,
                  jitter, DSCP (Diff-Serv Code Point, [13]) marking, or a combination
                  of these various parameters.
               
                  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 above-mentioned QoS requirements. From this
                  perspective, the algorithms invoked by the routing processes will run
                  the route calculation algorithms that will take into account the cost
                  metrics (whose corresponding values can possibly be influenced by a
                  DSCP value) that have been assigned by the network administrators,
                  and that will somewhat reflect the QoS parameters that have been
                  valued in the above-mentioned SLS template ([7], [10]).
               
                  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 conveyed in SLS (Service Level
                  Specification, [4]) templates,
               
                  - IP TE-related information is provided to routers (as a
                  configuration input), and is exchanged between routers so that they
                  calculate, select, install, maintain and possibly withdraw the routes
                  that will comply with the QoS parameters that have been valued in the
                  QoS-related information.
               
                  From this perspective, QoS-related information provides information
                  on the traffic 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
               
               Jacquenet           Experimental - Expires May 2001            [Page 3]


               Internet Draft   COPS Usage for IP Traffic Engineering        Nov. 2000
               
               
                  to forward the above-mentioned traffic, i.e. identify and use the IP
                  TE routes that will convey such traffic.
               
                  Furthermore, the actual enforcement of a given IP traffic engineering
                  policy implies that the routers MUST be provided with the IP TE-
                  related information to compute the corresponding IP TE routes, so
                  that they can calculate, select, install, maintain and possibly
                  withdraw the routes that will comply with the requirements expressed
                  in the above-mentioned QoS-related information.
               
                  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, [11]) function that allows a router to enforce a collection of
                  policies (including an IP traffic engineering policy within the
                  context of this draft), thanks to a COPS-based communication that has
                  been established between the PEP and the PDP,
               
                  - The actual enforcement of an IP TE policy is based upon the IP TE-
                  related information that will be exchanged between the PEP and the
                  PDP, and that will be used by the router for selecting, installing,
                  maintaining and possibly withdrawing IP TE routes.
               
               4. The generic model of an IP TE policy enforcement scheme
               
                  The use of the COPS protocol for IP TE policy provisioning together
                  with an IP TE client-type that is supported by the PEP embedded in
                  the IP routers which participate in the enforcement of the IP TE
                  policy, yields the generic model depicted in figure 1.
               
                            +----------------+
                            |                |
                            |    IP Router   |
                            |                |
                            |     +-----+    |   COPS-PR     +-----+    +-----------+
                            |     | PEP |<---|-------------->| PDP |<-->| IP TE PIB |
                            |     +-----+    |               +-----+    +-----------+
                            |        |       |
                            |        |       |
                            |     +-----+    |
                            |     | LPDP|    |
                            |     +-----+    |
                            |        |       |
                            |        |       |
                            |    /-------\   |
                            |    |       |   |
                            | +-----+ +-----+|
                            | | RIB |.| RIB ||
                            | +-----+ +-----+|
                            |    |       |   |
                            |    |       |   |
               
               Jacquenet           Experimental - Expires May 2001            [Page 4]


               Internet Draft   COPS Usage for IP Traffic Engineering        Nov. 2000
               
               
                            |    \-------/   |
                            |        |       |
                            |     +-----+    |
                            |     | FIB |    |
                            |     +-----+    |
                            +----------------+
                  _
                        - Fig.1: generic model of an IP TE policy enforcement scheme -
               
                  According to figure 1, the routers embed the following and basic
                  components (among other capabilities which are clearly out of the
                  scope of this draft):
               
                  - A PEP capability, which supports the IP TE client-type. The IP TE
                  client-type is specified by the PEP to the PDP, and is unique for the
                  area covered by the IP 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, [11]), which corresponds to
                  the routing processes that have been activated in the router,
                  typically. Within the context of enforcing an IP traffic engineering
                  policy, the LPDP is expected to calculate and install the IP TE
                  routes that comply with the QoS requirements expressed in the IP TE-
                  related information that has been received by the PEP (see section 5
                  of this draft),
               
                  - Several instances of Routing Information Bases (RIB), according to
                  the different routing processes that have been activated - one can
                  easily assume the activation of at least one IGP (Interior Gateway
                  Protocol, like OSPF) and BGP4. From this standpoint, the above figure
                  does not make any specific assumption about the actual number of RIB
                  instances that can be supported by the router, since this is an
                  implementation specific issue,
               
                  - Conceptually one Forwarding Information Base (FIB), which will
                  store the routes that have been selected by the routing processes.
                  Again, 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 traffic engineering
                  policy is based upon the use of an IP TE policy server (the PDP in
                  the above figure) that sends IP TE-related information to the PEP
                  capability embedded in the IP router.
               
                  The IP TE-related information is stored and maintained in the 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 5 of this draft).
               
               
               
               Jacquenet           Experimental - Expires May 2001            [Page 5]


               Internet Draft   COPS Usage for IP Traffic Engineering        Nov. 2000
               
               
                  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 traffic engineering policy that is therefore
                  described in the PIB as a specific PRovisioning Class (PRC, [3]),
                  namely the IP TE PRC. Furthermore, the IP TE PRC contains attributes
                  that actually describe the IP TE-related information that will be
                  sent by the PDP to the PEP. These attributes consist of the link and
                  traffic engineering metrics that will be manipulated by the routing
                  processes being activated in the routers to calculate the IP TE
                  routes for a given destination, among other characteristics.
               
                  The IP TE PRC is 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 yet-to-be published [15] document 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
                  naturally yields the notion of "DSCP-based" routing. Such a routing
                  scheme aims at reflecting the IP traffic engineering policies that
                  have been defined by a service provider, assuming a restricted number
                  of DSCP-identified classes of service that will service the
                  customer's requirements.
               
                  This approach clearly yields the use of a single IP TE PRC (as part
                  of the generic PIB depicted in figure 1) per administrative domain,
                  i.e. it is assumed that each service provider will have the ability
                  to instantiate its own IP TE PRC, according to the routing policies
                  it has defined for forwarding the traffic within its domain, but also
                  outside of its domain, in terms of IGP metrics' values and BGP4
                  attribute values, among other things.
               
               5. 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
                  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.
               
               
               
               Jacquenet           Experimental - Expires May 2001            [Page 6]


               Internet Draft   COPS Usage for IP Traffic Engineering        Nov. 2000
               
               
                  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 TE routes in the router's
                  FIB is left to the LPDP embedded in the router. 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 machinery, as defined in [2].
               
               5.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 7 of this draft) for
                  the IP TE client-type.
               
               5.2. COPS Message Content
               
               5.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 traffic engineering
                  policy. Such configuration information is encoded according to the
                  ClientSI format that is defined for the Named ClientSI object of the
                  REQ message ([3]).
               
                  The configuration information is encoded as a collection of bindings
                  that associate a PRID object and an Encoded Provisioning Instance
                  Data (EPD, [3]).
               
                  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, [5]) Type 1 messages, which include the RouterID
                  information encoded as an IP address. 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 [5] 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 DSCP value
                  encoded in each IP datagram that this router may have to forward. For
                  example, a service provider may decide to assign higher values of the
                  link metric for the selection of the routes that will convey best
                  effort traffic characterized by the default DSCP value of 0x000000,
               
                  - The traffic engineering metric values that specify the link metric
                  values for traffic engineering purposes, as defined in [7], for
               
               Jacquenet           Experimental - Expires May 2001            [Page 7]


               Internet Draft   COPS Usage for IP Traffic Engineering        Nov. 2000
               
               
                  example. These values MAY be different from the above-mentioned link
                  metric values and they MAY also vary according to DSCP values: this
                  would indicate that the link is a member of one or several DSCP-
                  defined groups,
               
                  - The contents of each RIB maintained by the router, e.g. the LSDB
                  (Link State Data Base, [5]) and the Adj-RIB-Out, as defined in [6],
               
                  - The contents of the FIB maintained by the router.
               
               5.2.2. Decision messages (DEC)
               
                  The DEC messages are used by the PDP to send IP TE policy
                  provisioning information 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
                  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 above-mentioned identification information, and
                  according to the kind of (PRID, EPD) bindings that MAY be processed
                  by the PEP (see section 5.2.1. of the draft), DEC messages MAY refer
                  to the following decision examples:
               
                  - Install (i.e. assign in this case) 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, [6]) attribute). This will
                  in turn yield the calculation of (new) IP TE routes that MAY be
                  installed in the router's FIB,
               
                  - Modify already-assigned metric values, thanks to a remove/install
                  decision procedure (this may yield a modification of the router's FIB
                  as well, obviously). These DEC messages can be motivated by the
                  processing of newly accepted SLS requests among other contexts,
               
                  - Remove assigned metric values, i.e. 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).
               
               5.2.3. Report messages (RPT)
               
               
               
               
               Jacquenet           Experimental - Expires May 2001            [Page 8]


               Internet Draft   COPS Usage for IP Traffic Engineering        Nov. 2000
               
               
                  The Report message allow the PEP to indicate to the PDP that a
                  particular set of IP TE policy provisioning instances have been
                  successfully or unsuccessfully installed/removed.
               
                  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-Type:
               
                  "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 TE routes in the router's FIB.
                  From this standpoint, 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 above-mentioned 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 might be appropriately updated by the
                  PDP.
               
                  "Accounting": the accounting RPT message will carry statistical
                  information related to the traffic that will transit through the
                  router AND that will be forwarded by the router according to one of
                  the entries of the router's FIB. 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 bandwidth 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.
               
               5.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),
                  and of COPS-unaware routers, the activation of a link state routing
                  protocol (like OSPF) together with the reporting mechanism that has
                  been described in section 5.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 will receive these update messages. Upon receipt of such
                  messages, the PEP will have the ability to notify the PDP of the
                  corresponding changes (e.g. by using a "Success" report-type that
               
               
               Jacquenet           Experimental - Expires May 2001            [Page 9]


               Internet Draft   COPS Usage for IP Traffic Engineering        Nov. 2000
               
               
                  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.
               
               6. COPS-PR Usage of the IP TE client-type
               
                  After having opened a COPS connection with the PDP, the PEP sends a
                  REQ message to 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 5.2.1.of the draft. By "default" configuration
                  information, it must be understood the default values that can be
                  assigned to the different metrics considered in this document,
                  according to the bootstrap procedures of the routers, and to the
                  default values that have been instantiated in the IP TE PRC part of
                  the PIB.
               
                  The routes that have been installed in the router's FIB will 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 5.2.2 of this draft. One of
                  the basic goals of this named Decision objects consist in making the
                  routers calculate and install the IP TE routes that will comply with
                  the requirements contained in the SLS templates that have been
                  accepted by the service provider, as well as enforce the IP traffic
                  engineering policy that is depicted by the above-mentioned metric
                  value assignment.
               
                  Upon receipt of a DEC message, the PEP and the IP TE client-type it
                  supports will (try to) enforce the corresponding IP TE decisions, by
                  making the LPDP (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,
               
               
               Jacquenet           Experimental - Expires May 2001           [Page 10]


               Internet Draft   COPS Usage for IP Traffic Engineering        Nov. 2000
               
               
                  - 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, like a BGP4 UPDATE message, for example), but
                  also subject to named IP TE policy decision data (carried in a
                  specific DEC message), like those data related to the lifetime of a
                  service: from this standpoint, an installed route may be valid ONLY
                  during the operating hours of a company, for example.
               
                  The RPT message MAY also carry the "Accounting" report-type, as
                  described in section 5.2.3.of this draft.
               
               7. IANA Considerations
               
                  Section 5.1. of this draft has identified a 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].
               
               8. 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 traffic
                  engineering policies within IP networks. 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].
               
               9. References
               
                  [1]  Bradner, S.,"The Internet Standards Process -- Revision 3", BCP
                       9, RFC 2026, October 1996.
               
               
               
               Jacquenet           Experimental - Expires May 2001           [Page 11]


               Internet Draft   COPS Usage for IP Traffic Engineering        Nov. 2000
               
               
               
                  [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)", draft-ietf-rap-pr-04.txt,
                       Work in Progress, August 2000.
               
                  [4]  Goderis D., T'Joens Y., Jacquenet C., Memenios G., Pavlou G.,
                       Egan R., Griffin D., Georgatsos P., Georgiadis L.,
                       "Specification of a Service Level Specification (SLS) Template",
                       draft-tequila-sls-00.txt, Work in Progress, November 2000. Check
                       http://www.ist-tequila.org for additional information.
               
                  [5]  Moy J.,"OSPF Version 2", RFC 2328, April 1998.
               
                  [6]  Rekhter Y., Li T., "A Border Gateway Protocol 4 (BGP-4)", RFC
                       1771, March 1995.
               
                  [7]  Katz D., Yeung D., "Traffic Engineering Extensions to OSPF",
                       draft-katz-yeung-ospf-traffic-02.txt, Work in Progress, October
                       2000.
               
                  [8]  Smit H., Li T., "IS-IS Extensions for Traffic Engineering",
                       draft-ietf-isis-traffic-02.txt, Work in Progress, September
                       2000.
               
                  [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-00.txt, Work in Progress, July 2000.
               
                  [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.
               
               
               
               Jacquenet           Experimental - Expires May 2001           [Page 12]


               Internet Draft   COPS Usage for IP Traffic Engineering        Nov. 2000
               
               
               
                  [15] Jacquenet C., "An IP Traffic Engineering Policy Information
                       Base", Work in Progress, November 2000.
               
                  [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.
               
               10. Acknowledgments
               
                  Part of this work is funded by the European Commission, within the
                  context of the TEQUILA (Traffic Engineering for Quality of Service in
                  the Internet At Large Scale, [4]) 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 TEQUILA
                  project for the fruitful discussions that have been conducted so far
                  within the context of the traffic engineering specification effort of
                  the project.
               
               
               11. Author's Addresses
               
                  Christian Jacquenet
                  France Telecom R & D
                  DMI/SIR
                  42, rue des Coutures
                  BP 6243
                  14066 CAEN Cedex 04
                  France
                  Phone: +33 2 31 75 94 28
                  Email: christian.jacquenet@francetelecom.fr
               
               12. 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 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.
               
               Jacquenet           Experimental - Expires May 2001           [Page 13]


               Internet Draft   COPS Usage for IP Traffic Engineering        Nov. 2000
               
               
               
                  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 May 2001           [Page 14]