Network Working Group C. Jacquenet
Internet Draft France Telecom R&D
Document: draft-jacquenet-ip-te-cops-02.txt June 2001
Category: Experimental
Expires December 2001
A COPS client-type for IP traffic engineering
<draft-jacquenet-ip-te-cops-02.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, [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 December 2001 [Page 1]
Internet Draft COPS Usage for IP Traffic Engineering June 2001
Engineering (IP TE) policy which is one of 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. rate, one-way delay,
inter-packet delay variation, 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
configuration 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 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.
Jacquenet Experimental - Expires December 2001 [Page 2]
Internet Draft COPS Usage for IP Traffic Engineering June 2001
2. Changes since the last version
The current version of this draft reflects the following changes:
- Updated bibliography,
- Slight re-wording of sections 1, 5 and 6,
- 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 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 rate, one-way
delay, inter-packet delay variation, 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 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 negotiated between customers and
service providers (e.g. by using SLS templates),
Jacquenet Experimental - Expires December 2001 [Page 3]
Internet Draft COPS Usage for IP Traffic Engineering June 2001
- 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 parameters that are depicted
by 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
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.
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]) capability 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 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 configuration 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.
5. The generic model of an IP TE policy enforcement scheme
The use of the COPS protocol for dynamically enforcing an IP TE
policy yields the generic model depicted in figure 1.
+----------------+
| |
| IP Router |
| |
| +-----+ | COPS-PR +-----+ +-----------+
| | PEP |<---|-------------->| PDP |<-->| IP TE PIB |
| +-----+ | +-----+ +-----------+
| | |
| | |
| +-----+ |
| | LPDP| |
| +-----+ |
| | |
| | |
Jacquenet Experimental - Expires December 2001 [Page 4]
Internet Draft COPS Usage for IP Traffic Engineering June 2001
| /-------\ |
| | | |
| +-----+ +-----+|
| | RIB |.| RIB ||
| +-----+ +-----+|
| | | |
| | | |
| \-------/ |
| | |
| +-----+ |
| | 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 can be
assimilated 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 6 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.
Jacquenet Experimental - Expires December 2001 [Page 5]
Internet Draft COPS Usage for IP Traffic Engineering June 2001
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 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 traffic engineering policy that is therefore
described in the PIB as a collection of PRovisioning Classes (PRC,
[3]), namely the classes described in [15]. Furthermore, these
classes contain 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 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 as depicted in [15] 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 customers'
requirements.
This approach clearly assumes that each service provider will have
the ability to instantiate the contents of its own IP TE PIB,
according to the routing policies that have been defined for
forwarding the traffic within its domain, but also outside of its
domain, in terms of IGP metrics' values and BGP4 attribute values,
respectively.
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 December 2001 [Page 6]
Internet Draft COPS Usage for IP Traffic Engineering June 2001
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 TE routes in the router's
FIB is left to the routers, but the route selection process is
influenced by the configuration information sent by the PDP, and
which will be processed by the IP TE client-type supported by the
PEP, so that the LPDP of the router can convert the IP TE-related
information into local configuration information.
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].
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 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,
Jacquenet Experimental - Expires December 2001 [Page 7]
Internet Draft COPS Usage for IP Traffic Engineering June 2001
- 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
example. These values MAY be different from the above-mentioned
link metric values and they MAY also vary according to DSCP
values: e.g., this would indicate that the link is a member of one
or several DSCP-defined groups.
6.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
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 above-mentioned 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:
- 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 sent because of
the processing of recently accepted SLS templates,
Jacquenet Experimental - Expires December 2001 [Page 8]
Internet Draft COPS Usage for IP Traffic Engineering June 2001
- 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).
6.2.3. Report messages (RPT)
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 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 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. 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),
Jacquenet Experimental - Expires December 2001 [Page 9]
Internet Draft COPS Usage for IP Traffic Engineering June 2001
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 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 of
the corresponding changes (e.g. by using a "Success" report-type 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 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 6.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 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 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
Jacquenet Experimental - Expires December 2001 [Page 10]
Internet Draft COPS Usage for IP Traffic Engineering June 2001
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
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 6.2.3.of this draft.
8. IANA Considerations
Section 6.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].
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 traffic
engineering 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
Jacquenet Experimental - Expires December 2001 [Page 11]
Internet Draft COPS Usage for IP Traffic Engineering June 2001
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] 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., Kompella, K., "Traffic Engineering
Extensions to OSPF", draft-katz-yeung-ospf-traffic-04.txt, Work
in Progress, February 2001.
[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-01.txt, Work in Progress, February 2001.
[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] Jacquenet C., "An IP Traffic Engineering Policy Information
Base", draft-jacquenet-ip-te-pib-00.txt, Work in Progress, June
2001.
[16] Alvestrand H., Narten T., "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
Jacquenet Experimental - Expires December 2001 [Page 12]
Internet Draft COPS Usage for IP Traffic Engineering June 2001
[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 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, as well as M. Brunner for his valuable input.
12. 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.com
13. Full Copyright Statement
Copyright(C) The Internet Society (2001). 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
Jacquenet Experimental - Expires December 2001 [Page 13]
Internet Draft COPS Usage for IP Traffic Engineering June 2001
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 December 2001 [Page 14]