Internet Draft Stefano Salsano Expiration: August 2000 CoRiTeL File: draft-salsano-issll-cops-odra-00.txt COPS Usage for Outsourcing Diffserv Resource Allocation February 22, 2000 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or 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. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document introduces a new client type for the COPS protocol to support dynamic DiffServ admission control. The Policy Decision Point (PDP) acts as a "Bandwidth Broker" for the Policy Enforcement Point (PEP) which is requesting resources. The use of the defined mechanism is suited for (but it is not limited to) the Integrated Services operation over Diffserv networks. Salsano Expires August 2000 1 COPS Usage for Outsourcing Diffserv Resource Allocation Feb-00 Table of Contents Abstract........................................................2 Glossary........................................................2 1. Introduction ................................................3 2. Interaction between the COPS-ODRA PEP and PDP/BB ............4 3. Message Content .............................................6 4. COPS-ODRA Protocol Objects ..................................9 5. COPS-ODRA Client-Specific data format .......................12 6. Security Considerations .....................................14 7. Illustrative examples for COPS-ODRA client ..................14 8. References ..................................................15 9. Author Information and Acknoledgements ......................15 Glossary BB Bandwidth Broker ER Edge Router COPS Common Open Policy Service. See [COPS] PDP Policy Decision Point. See [RAP] PEP Policy Enforcement Point. See [RAP] Salsano Expires August 2000 2 COPS Usage for Outsourcing Diffserv Resource Allocation Feb-00 1. Introduction The COPS (Common Open Policy Service) protocol [COPS] is a simple query and response protocol that allows policy servers (PDPs) to communicate policy decisions to network devices (PEP). In order to be flexible, the COPS protocol has been designed to support multiple types of policy clients. Each client-type can be described in a different usage draft. The purpose of this draft is to describe the use of COPS for outsourcing the allocation of resources in a Diffserv network. The new client-type is called "COPS-ODRA" (COPS- Outsourcing Diffserv Resource Allocation). The use of a server to control the admission of traffic within a Diffserv domain has been considered since the very beginning of the discussion about the Diffserv architecture [2BIT]. The admission control server is typically referred to as Bandwidth Broker (BB). The communality between the BB and the PDP are described in [BBREQ]. In this draft the use of COPS for the communication between the Edge Device and the Bandwidth Broker is proposed. Therefore the Bandwidth Broker will be denoted PDP/BB. An intra-domain scenario is assumed, where the PDP/BB is in charge of controlling resource for a network in a single administrative domain. Two main models are supported by the COPS protocol: Outsourcing and Provisioning. The COPS-ODRA client relies on the Outsourcing model. The PEP explicitly asks the PDP/BB for a given amount of resources, from an ingress point to an egress point. Note that per-flow state is not stored in the PDP/BB. Instead, resource allocation requests are properly aggregated and only aggregate state information is kept in the PDP/BB, allowing for higher scalability. In this context, resource allocation is strictly related to admission control: the server controls the allocation of resources by admitting or rejecting the requests coming from its clients. An example application scenario for the COPS-ODRA is the Intserv operation over Diffserv networks, as described in [INTDIF]. In this scenario, the Edge Router includes the PEP and interacts with the PDB/BB using COPS-ODRA according to the reservation requests coming from RSVP messages. An architectural definition and scalability analysis of this scenario can be found in [ICC99] The examples used in this document are biased towards this type of RSVP/Diffserv interworking. However, the COPS-ODRA client type can be used for supporting centralized Resource Allocation control arising from different types of scenario. The use of COPS for resource admission control in a Diffserv network is assumed in some studies and prototypes (see for example [BBop], [UCLA- BB]). Anyway, no formal description of the protocol has been proposed so far. Salsano Expires August 2000 3 COPS Usage for Outsourcing Diffserv Resource Allocation Feb-00 1.1 Discussion on the Outsourcing model The Outsourcing model is used when there are "Trigger events" in the PEP that require a policy decision (e.g. a dynamic request to admit a new flow). The PEP delegates this decision to an external policy server (PDP). It sends a query message to the PDP, typically waiting for the response decision before admitting the new flow. See Figure 1 below. Edge Device Policy Server +-----------------------------+ +--------------+ | | | | | +--------+ | COPS | | | |Trigger | +-----+ | REQ() | +--------+ | | | events |----->| |----|----------|->| | | | +--------+ | PEP | | | | PDP/BB | | | | |<---|----------|--| | | | +-----+ | COPS | +--------+ | | | DEC() | | +-----------------------------+ +--------------+ Figure 1: COPS-ODRA Outsourcing Model On the other hand, the Provisioning model [COPS-PR] foresees that the PDP proactively configures the PEP so that it knows how to run its QoS mechanisms. The mechanisms to exchange the configuration information and to store this information is based on the definition of a "Policy Information Base", see [PIB]. In the Provisioning model, either there are no "Trigger events" at the PEP (i.e. only packet classification, marking, scheduling, etc. is performed at the PEP) or these events must be handled using local information (i.e. mapped in the available resources provisioned by the PDP). The Provisioning model is very well suited when there are no such dynamic requests coming to the PEP. In other scenarios, like for example the RSVP/Diffserv interworking the dynamic requests are a fundamental feature in the PEP/Edge Router. In this case a possible solution is to fully rely on the Outsourcing model, so that a very simple PEP can be defined. The drawback is the need of relatively frequent communication with the PDP, but there are scenarios where this solution can be cost- effective. Note that the Outsourcing model lends itself to more sophisticated solutions if scalability concerns arise. In fact the Outsourcing model can be dynamically paced by the PEP in real-time. A straightforward option is to pre-reserve some amount of bandwidth to limit the pace of Resource Admission Requests. The definition of these mechanisms is out of the scope of this document, which focuses on the protocol specification for the COPS-ODRA client. In general, a combination of Outsourcing and Provisioning model could be used to provide a flexible and general solution for QoS in IP networks, but this is outside the scope of this document. Salsano Expires August 2000 4 COPS Usage for Outsourcing Diffserv Resource Allocation Feb-00 2. Interaction between the COPS-ODRA PEP and PDP/BB This section describes the interaction between a PDP and Diffserv Resource Admission Control COPS client. 2.1. Start of operations In order to start operations, the PEP must open the dialogue connection with its PDP/BB. First, a TCP connection is established between the client and server and the PEP sends a Client-Open message with the Client-Type = COPS-ODRA. If the PDP supports this client type, it responds with a Client-Accept (CAT) message. If the client type is not supported, a Client-Close (CC) message is returned by the PDP to the PEP. After receiving the CAT message, the PEP can send requests to the server. 2.2. Common operations Following the terminology in [BBREQ], the PEP will send "Resource Allocation Requests" (RAR) to the PDP/BB once the connection is established. A Resource Allocation Request will contain: - the topological information (e.g. ingress point and egress point in the Diffserv domain) which allows the PDP/BB to aggregate different Resource Requests - the type of the requested resource (e.g. the Diffserv Per Hop Behavior or Behavior Aggregates) - the amount of the requested resource (e.g. the specification of the bandwidth) The resource allocation request is used by the PDP to perform the Admission Control procedure. According to the requirements of the requested service, the PDP/BB will properly map the requested edge-to- edge resources into network resources and will assure that such resources are available throughout the Diffserv cloud. The discussion of the Admission Control algorithms in the PDP/BB and of the mechanisms used by the PDP/BB to get topological/routing information from the Diffserv domain are outside the scope of this document. Related work can be found in [IWQOS99], where the use of OSPF and SNMP for the communication between the BB and the Diffserv routers is proposed. In response to the Resource Allocation request, the PDP sends a reply where it accepts or rejects the RAR. On receiving the answer, the PEP activates its local QoS mechanisms as needed. 2.3 State information in PEP and PDP/BB The COPS protocol is stateful in the sense that Request/Decision state is shared between PEP and PDP. Depending on the COPS client type, one or multiple states can be installed in the context of a single PEP/PDP relationship. The "handle" object uniquely identifies a single installed state at the PEP and at the PDP side. In case of RSVP client type [COPS- Salsano Expires August 2000 5 COPS Usage for Outsourcing Diffserv Resource Allocation Feb-00 RSVP], a different state is installed for each RSVP flow (actually one PATH state and one RESV state). This implies that a lot of state information is duplicated in the PEP and in the server. In COPS-ODRA the state information is aggregated: the state represents the set of resources allocated by the PDP/BB to a PEP. Therefore a unique value for the handle object is used in the context of a single PEP/PDP relationship. The handle is inserted by the PEP in the first request and then it is used in every message by the PEP and by the PDP/BB. The state information in the PDP/BB is represented by the set of the triples (resource type, ingress point, egress point) and the corresponding amount of allocated resources. The PDP/BB keeps this state information separately for each different COPS-ODRA client (i.e. for each connected PEP). The requests for the same resource type, ingress point, egress point coming from the same PEP are properly composed by the PDP/BB so that only the aggregate information is stored. This aggregate state information stored in PDP/BB is logically shared by the PEP in the sense that it is the result of the sequence of Request messages sent and of the Decision messages received. There is no need in the PEP to evaluate and store the aggregate state information: in the simplest case, the client side (PEP) stores a set of "per flow" reservation information. In more advanced scenarios, the PEP client can evaluate and store aggregate information. Temporary state information per each request must be stored in the PEP and in the PDP/BB in order to correlate requests with decisions. To this purpose the notion of request ID is needed and a corresponding client specific protocol object is defined (see section 3). This temporary information is deleted in the PDP/BB when the Decision message is sent and in the PEP when this message is received. 2.4 Synchronization Synchronization procedures are foreseen in COPS specification to cover failure situations. The basic idea is that the PDP/BB can "reset" the state and ask the PEP to rebuild it by sending proper resource allocation Request messages. If the PEP has only stored "per-flow" state, it will send one Request message for each active reservation. If the PEP has stored aggregate states, it can send "aggregate" Resource Allocation requests. Selective re-submissions (i.e. for resource type, ingress or egress point) can be supported. 3. Message Content The COPS protocol provides for different COPS clients to define their own "named", i.e. client-specific, information for various messages. This section describes the messages exchanged between a COPS server (PDP) and COPS ODRA clients (PEP) that carry client-specific data objects. Salsano Expires August 2000 6 COPS Usage for Outsourcing Diffserv Resource Allocation Feb-00 3.1. Request (REQ) PEP -> PDP The REQ message is sent by COPS-ODRA clients to issue a 'Resource Allocation Request' to the PDP. The Resource Allocation Request REQ is used to request new resources, to modify a previous reservation, to release a reservation. The Client Handle associated with the REQ message originated by the DRA client must be unique for that client but otherwise has no protocol significance at this time. The context object specifies the types of request (Add, Release, Modify, see the description of Context object). The Client Specific info object is used to specify the requested resources and the request identifier. Each REQ message contains a single request. The PDP responds to the resource allocation request with a DEC message containing the answer to the query. The REQ message has the following format: ::= [] [] Note that the COPS objects IN-Int, OUT-Int and LDPDecisions are not included in a COPS-ODRA REQ message. Note that resource allocation request messages can be generated and sent to the PDP in response to the receipt of a Synchronize State Request (SSQ) message. 3.2. Decision (DEC) PDP -> PEP The DEC message is sent from the PDP to a COPS-ODRA client in response to the REQ message received from the PEP. Unsolicited DEC messages cannot be sent for this client type (therefore the solicited decision flag is always set). The Client Handle must be the same Handle that was received in the REQ message (it is identical for all requests). The Decision object will contain in the Client Specific info the Request ID, which is needed by the PEP to correlate the reply with the query. Each DEC message contains a single decision. The DEC message for the COPS-ODRA client type has the following format: ::= Salsano Expires August 2000 7 COPS Usage for Outsourcing Diffserv Resource Allocation Feb-00 | [] The decision object in turn has the following format: ::= The context object will be the same as contained in the REQ message. The Decision: Flags object will contain the answer in the Command-code field according to the COPS specifications. In particular the Command- code will be "Install" to mean a positive answer and "Remove" to mean a negative answer. The following text clarifies how Install and Remove Decisions map into the different request types. REQ (Context = Add) DEC (Dec Flag = Install) -> The requested resources are successfully allocated DEC (Dec Flag = Remove) -> The requested resources are not allocated REQ (Context = Release) DEC (Dec flag = Install) -> The resources are released DEC (Dec Flag = Remove) -> The resources are still allocated. (This is syntactically correct, but it make no sense) REQ (Context = Modify) DEC (Dec flag = Install) -> The modification is accepted. The newly requested resources are allocated, while the previous ones have been released DEC (Dec Flag = Remove) -> The modification is not accepted. The previous allocation is still active. (This also makes sense only if the modification increases the allocated resource) The Error object is used to communicate COPS protocol error to the PEP, according to the definition in [COPS]. No client specific error sub- codes are used by COPS-ODRA. Salsano Expires August 2000 8 COPS Usage for Outsourcing Diffserv Resource Allocation Feb-00 No report is sent by the PEP to confirm the reception of a Decision message. Only in case of specific errors, the PEP will send back a Report State message to the PDP/BB. 3.3. Report State (RPT) PEP -> PDP For COPS-ODRA client type, the Report State message is sent by the PEP to the PDP in case of problems with a received Decision message. More specifically it is used to communicate that the Decision contains a Request identifier which cannot be correlated to a previous request. This event is the manifestation of abnormal behavior. On reception of a Report State message the PDP could start a Synchronization procedure. The RPT message for the COPS-ODRA client type has the following format: ::= [] 3.4. Synchronize State Request (SSQ) PDP -> PEP The Synchronize State Request message is sent by the PDP to the PEP to "reset" the state information. It requests the PEP to send the set of resource allocation REQ messages needed to rebuild the state. The SSQ can apply to the whole set of PEP active reservations PEP, or to a specific resource type and ingress-egress couple, depending on the information contained in the Client SI object. < Synchronize State> ::= ] [] Note that the COPS specification in [COPS] does not foresee a ClientSI object in the SSQ message. 3.5. Synchronize State Complete (SSC) PEP -> PDP The Synchronize State Complete message is sent by the PEP to the PDP to inform that all the REQ messages needed to rebuild the state have been sent. The Client SI object is the same received in the SSQ message and specifies the scope of the synchronization procedure which has been completed. < Synchronize State Complete> ::= ] [] Salsano Expires August 2000 9 COPS Usage for Outsourcing Diffserv Resource Allocation Feb-00 Note that the COPS specification in [COPS] does not foresee a ClientSI object in the SSC message. 4. COPS-ODRA Protocol Objects A new COPS client type for the policy provisioning client is defined: Client Type = 5; Outsourcing Diffserv Resource Allocation Client (ODRA Client) COPS messages sent between an ODRA client and a COPS server contain a COPS Common Header with this ODRA Client type specified: 0 1 2 3 +---------------+---------------+---------------+---------------+ | Version| Flag | Op Code | Client Type = 0x05 | +---------------+---------------+---------------+---------------+ | Message Length | +---------------+---------------+---------------+---------------+ The COPS-ODRA uses new COPS protocol objects that carry client-specific information. This section defines those new objects. The format for these new objects is as follows: S-Num and S-Type are similar to the C-Num and C-Type used in the base COPS objects. The difference is that S-Num and S-Type are used only for ClientSI specific objects. Length is a two-octet value that describes the number of octets (including the header) that compose the object. If the length in octets does not fall on a 32-bit word boundary, padding must be added to the end of the object so that it is aligned to the next 32-bit boundary before the object can be sent on the wire. On the receiving side, a subsequent object boundary can be found by simply rounding up the previous stated object length to the next 32-bit boundary. 4.1. Request ID Object (ReqID) The Request ID object is used to correlate the Requests sent by the COPS-ODRA client with the responses coming from the PDP/BB. The ReqID object is chosen by the PEP and it is opaque to the PDP/BB. A different ReQID object is chosen by the PEP for each Request. The ReqID object is carried in the Client Specific Information Object for Request message (PEP -> PDP) and in the Decision ClientSI Data Object (PDP -> PEP). If the PEP receives a Decision with an unrecognized ReqID object, it will send a Report State Message to the PDP to communicate the error. Salsano Expires August 2000 10 COPS Usage for Outsourcing Diffserv Resource Allocation Feb-00 S-Num = 1, S-Type = 1 0 1 2 3 +---------------+---------------+---------------+---------------+ | Length | S-Num = 1 | S-Type = 1 | +---------------+---------------+---------------+---------------+ | Request ID | +---------------+---------------+---------------+---------------+ 4.2. Ingress Point Address (IPA) This object specifies the address of the Ingress Point into the Diffserv domain. The IPA object is carried in the Client Specific Information Object. In the RSVP Diffserv interaction scenario the Ingress point coincides with the requesting PEP itself. S-Num = 2 S-Type = 1, Ipv4 Address. 0 1 2 3 +---------------+---------------+---------------+---------------+ | Length | S-Num = 2 | S-Type = 1 | +---------------+---------------+---------------+---------------+ | IPv4 Address format | +---------------+---------------+---------------+---------------+ S-Type = 2, Ipv6 Address. 0 1 2 3 +---------------+---------------+---------------+---------------+ | Length | S-Num = 2 | S-Type = 2 | +---------------+---------------+---------------+---------------+ | | + + | Ipv6 Address format | + + | | +---------------+---------------+---------------+---------------+ 4.3. Egress Point Address Object (EPA) This object specifies the address of the Egress Point from the Diffserv domain. The EPA object is carried in the Client Specific Information Object. S-Num = 3 S-Type = 1, Ipv4 Address. S-Type = 2, Ipv6 Address. Salsano Expires August 2000 11 COPS Usage for Outsourcing Diffserv Resource Allocation Feb-00 See Ingress Point Address for object coding. 4.4. Resource Type Object (RType) This object specifies the type of the requested resources. In a Diffserv scenario, the simplest option is to specify a DS codepoint. The Rtype object is carried in the Client Specific Information Object. S-Num = 4 S-Type = 1 Diffserv Codepoint (DSCP) 0 1 2 3 +---------------+---------------+---------------+---------------+ | Length | S-Num = 4 | S-Type = 1 | +---------------+---------------+---------------+---------------+ | ////////////////////////// | // | DSCP | +---------------+---------------+---------------+---------------+ More complex Diffserv edge-to-edge services can be listed defining different "S-Type". 4.5. Traffic Descriptor Object (TD) This object specifies the amount of the requested resources. The TD object is carried in the Client Specific Information Object. S-Num = 5 S-Type = 1 (Bandwidth) 0 1 2 3 +---------------+---------------+---------------+---------------+ | Length | S-Num = 5 | S-Type = 1 | +---------------+---------------+---------------+---------------+ | Bandwidth (bytes/s) | +---------------+---------------+---------------+---------------+ This description can be used if there is not a more accurate indication on the policing at the ingress interface. S-Type = 2 (Token Size and Measurement Interval) 0 1 2 3 +---------------+---------------+---------------+---------------+ | Length | S-Num = 5 | S-Type = 2 | +---------------+---------------+---------------+---------------+ | Token Size (bytes) | +---------------+---------------+---------------+---------------+ | Measurement Interval (msec) | +---------------+---------------+---------------+---------------+ Salsano Expires August 2000 12 COPS Usage for Outsourcing Diffserv Resource Allocation Feb-00 This description can be used if there is an indication on the policing at the ingress interface. This information could be used by the PDP/BB in the admission control algorithm. 4.6. Reject Reason Object (RejRea) The RejRea object is used to provide the reason for a negative Decision. It is carried in the Decision Client SI Data object. S-Num = 6, S-Type = 1 0 1 2 3 +---------------+---------------+---------------+---------------+ | Length | S-Num = 6 | S-Type = 1 | +---------------+---------------+---------------+---------------+ | ////////////////////////// | Reason code | +---------------+---------------+---------------+---------------+ Reason codes are: Reason code = 1 : Resource unavailable Reason code = 2 : Unsupported resource type Reason code = 3 : Unacceptable Ingress Point Reason code = 4 : Unacceptable Egress Point 4.7. Synchronize State scope (SSscope) The SSQscope object is used to specify the scope of a Synchronize State operation. The SSQscope object is carried in the Client Specific Information Object for the SSQ and SSC messages. S-Num = 7, S-Type = 1 0 1 2 3 +---------------+---------------+---------------+---------------+ | Length | S-Num = 7 | S-Type = 1 | +---------------+---------------+---------------+---------------+ | ////////////////////////// | Scope | +---------------+---------------+---------------+---------------+ Allowed value for Scope field are: 0 : Generic scope 1 : Specific scope If the Scope is Generic, the Synchronize State operation refers to the whole set of resource types and ingress-egress pairs. If scope is Specific, the Synchronize State Request refers to the specific resource type and ingress-egress pair contained in the rest of the ClientSI Object for SSQ and SSR messages (see section 5). Salsano Expires August 2000 13 COPS Usage for Outsourcing Diffserv Resource Allocation Feb-00 5. COPS-ODRA Client-Specific data format 5.1. Context object The context object specifies the type of request that triggered the query. It is included in the REQ and in the DEC message. For COPS-ODRA client the Request Type flag is always set to 0x02 (Resource-Allocation request). The Message Type flag is used by the COPS-ODRA client to distinguish between add, release and modify requests. Depending on the M-Type, a different content of the ClientSI object for REQ message is used. C-num = 2, C-Type = 1 R-Type = 0x02 M-Type = 1 : Add M-Type = 2 : Release M-Type = 3 : Modify 5.2. Client Specific Information Object for REQ message. The Client Specific Information Object carried in the REQ messages for COPS-ODRA client contains the description of the resources and has a different format depending on weather the type of the request is Add/Release or Modify, as specified by the context object. If the Context object specifies an Add or Release request, the ClientSI object has the following format: ::= If the Context object specifies a Modify request, the previous values for Resource Type and Traffic Description are appended at the end of ClientSI object: ::= (new value) (new value) (old value) (old value) Salsano Expires August 2000 14 COPS Usage for Outsourcing Diffserv Resource Allocation Feb-00 5.3. Decision Client Specific Info Data object. The Decision ClientSI data object carries the information needed to correlate the decision with the answer and some optional information to explain negative Decisions. It has the following format: ::= 5.4. Client Specific Information Object for SSQ and SSC messages. The Client Specific Information Object carried in the SSQ messages for COPS-ODRA client describes the scope of the requested (SSQ message) and performed (SSC message) synchronize operation. This object has the following format: ::= [] [] [] If the "Specific scope" value is expressed in the SS scope object, then the Resource Type, Ingress Point Address and Egress Point Address object must be included. 5.5 Report Type Object The Report Type is contained in the Report State message. Only failures are communicated. C-num = 12, C-Type = 1 Report-Type = 2 : Failure 5.6. Client Specific Information Object for Report State message. The Client SI object for Report State message is used to communicate to the PDP that a Request ID was not recognized. ::= 6. Security Considerations This document relies on COPS for its signaling and its security. Please refer to section "Security Considerations" in [COPS]. 7. Illustrative examples for COPS-ODRA client Salsano Expires August 2000 15 COPS Usage for Outsourcing Diffserv Resource Allocation Feb-00 This section details two examples related to a successful and to an unsuccessful reservation respectively. In the following example the PEP requests the reservation of 1 Mb/s of EF traffic between ingress point 192.168.1.1 and the egress point 192.168.129.1. PEP --> PDP REQ := The PDP accepts the reservation. PDP --> PEP DEC := In the following example the PEP requests the reservation of 2 Mb/s of EF traffic between ingress point 192.168.1.1 and the egress point 192.168.129.1. Note that the same Handle is used, while the Request ID is different. PEP --> PDP REQ := The PDP rejects the reservation. PDP --> PEP DEC := Salsano Expires August 2000 16 COPS Usage for Outsourcing Diffserv Resource Allocation Feb-00 8. References [2BIT] [2BIT] K. Nichols, V. Jacobson, L. Zhang " A Two-bit Differentiated Services Architecture for the Internet "RFC 2638, July 1999 [BBop] First Internet2 bandwidth broker operability event http://www.merit.edu/internet/working.groups/i2-qbone- bb/inter-op/index.htm [BBREQ] R. Neilson, J. Wheeler, F. Reichmeyer, S. Hares (Editors), "A Discussion of Bandwidth Broker Requirements for Internet2 Qbone Deployment" Version 0.7 [COPS] D. Durham, Ed., J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry "The COPS (Common Open Policy Service) Protocol", IETF RFC 2748, January 2000 [COPS-RSVP] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, A. Sastry, "COPS usage for RSVP ", IETF RFC 2749, January 2000 [COPS-PR]F. Reichmeyer, et al. "COPS Usage for Policy Provisioning", draft-ietf-rap-pr-01.txt, October, 1999, Work in Progress. [ICC99] A. Detti, M.Listanti, S.Salsano, L.Veltri, "Supporting RSVP in a Differentiated Service Domain: an Architectural Framework and a Scalability Analysis", ICC '99, June 1999, Vancouver, Canada. [INTDIF] Bernet, Y., Yavatkar R., Ford, P., Baker, F., Zhang, L., Speer, M.,Braden, R., Wrocklaski, J., Felstaine, E., "A Framework for Integrated Services Operation Over Diffserv Networks", IETF , September 1999, Work in Progress. [IWQOS99]O. Schelen, A. Nilsson, J. Norrgard,S. Pink: Performance of QoS Agents for Provisioning Network Resources. In Proceedings of IFIP Seventh International Workshop on Quality of Service (IWQoS'99), London, UK, June 1999. [PIB] M. Fine, K. McCloghrie, S. Hahn, K. Chan, A. Smith, "An Initial Quality of Service Policy Information Base for COPS-PR Clients and Servers", draft-mfine-cops-pib-02.txt, October 1999. [RAP] R. Yavatkar, D.Pendarakis, R.Guerin, "A Framework for Policy Based Admission Control", IETF RFC 2753, January 2000. [UCLA-BB]A. Terzis, J.Ogawa, S.Tsui, L.Wang, L.Zhang "A prototype Implementation of the Two-Tier Architecture for Differentiated Services" IEEE Workshop on QoS Support for Real-Time Internet Applications, June 2-4, 1999 Vancouver, Canada 9. Author Information and Acknoledgements Special thanks to Roberto Mameli, Andrea Ferraresi and Eleonora Manconi for their comments and suggestions and their work on the prototype implementation. Stefano Salsano Salsano Expires August 2000 17 COPS Usage for Outsourcing Diffserv Resource Allocation Feb-00 CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni Via di Tor Vergata, 135 00133 Roma - ITALY email: salsano@coritel.it Salsano Expires August 2000 18