Internet Draft Stefano Salsano October 2001 Univ. of Rome "Tor Vergata" Expiration: May 2002 File: draft-salsano-cops-dra-00.txt COPS Usage for Diffserv Resource Allocation (COPS-DRA) 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 (2001). All Rights Reserved. Abstract This document introduces a new client type for the COPS protocol to support dynamic DiffServ resource allocation. The client type supports both the Outsourcing and the Provisioning model to achieve a scalable, efficient and flexible handling of network resources. The defined client type can be used: i) on the interface between an Edge Router (Policy Enforcement Point - PEP) and a Diffserv "Bandwidth Broker" (acting as Policy Decision Point -PDP); ii) on the interface between a client of a QoS enabled network (acting as PEP) and the access point of the network provider (e.g. the Edge Router acting as PDP) Salsano Expires Ma 2002 1 COPS Usage for Diffserv Resource Allocation (COPS-DRA) Oct-01 Table of Contents Abstract........................................................1 Glossary........................................................2 1. Introduction ................................................3 2. COPS-DRA: analysis of requirements ..........................4 3. COPS-DRA protocol operations ................................6 4. Message Content .............................................8 5. COPS-DRA Protocol Objects ...................................12 6. COPS-DRA Client-Specific data format ........................18 7. Security Considerations .....................................21 8. IANA Considerations .........................................21 9. Illustrative examples for COPS-DRA client ...................21 10.References ..................................................23 11.Author Information and Acknoledgements ......................24 APPENDIX: Discussion on Provisioning and Outsourcing models 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] RAR Resource Allocation Request Salsano Expires May 2002 2 COPS Usage for Diffserv Resource Allocation (COPS-DRA) Oct-01 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 dynamic resource allocation in a Diffserv network. The new client-type is called "COPS-DRA" (COPS- Outsourcing Diffserv Resource Allocation). This work extends the previously defined client type which was called "COPS-ODRA" (COPS- Outsourcing Diffserv Resource Allocation) [COPS-ODRA]. While COPS-ODRA was only based on the outsourcing model, COPS-DRA combines the outsourcing and provisioning model, providing a scalable, flexible and efficient handling of network resources. The COPS-DRA signaling mechanisms can be used on two different logical interfaces: i) On the interface between an Edge Router and the Diffserv "Bandwidth Broker" in order to handle the allocation of resources and to request the admission of new flows. In this case the Edge Router acts as PEP and the Bandwidth Broker as PDP. ii)On the interface between a QoS client of a QoS enabled network and the access point of this network in order to signal dynamic request for QoS flows. In this case the QoS client acts as PEP and the network access point (e.g. the provider Edge Router) acts as PDP. The requirements for the signaling mechanisms to be used on these interfaces are different, yet they are related for a large extent. COPS- DRA has been defined taking into account the superset of both types of requirements in order to be used on both types of interfaces. Figure 1 below depicts a scenario for COPS-DRA. .--------. | PDP/BB | | | '--------' | | / COPS-DRA / / .------. .------. | QoS | COPS-DRA | Edge | |Client|<-------------->|Router| '------' '------' Figure 1: COPS-DRA to support dynamic Diffserv based IP QoS Salsano Expires May 2002 3 COPS Usage for Diffserv Resource Allocation (COPS-DRA) Oct-01 2. COPS-DRA: analysis of requirements 2.1 Combination of Outsourcing and Provisioning 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] Let us consider first the use of COPS-DRA on the interface between Edge Device and the Bandwidth Broker. The Bandwidth Broker will be denoted by 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. Note that [BBop] and [UCLA-BB] generically discusses the use of COPS for resource admission control in a Diffserv network, but no protocol definition is provided. Two main models are supported by the COPS protocol: Outsourcing and Provisioning. The reader is referred to [COPS-ODRA] sec. 1, for an introduction to the Outsourcing and Provisioning models (for convenience, the related text in [COPS-ODRA] is reported in the Appendix of this document). The COPS-ODRA was only based on the Outsourcing model. The advantage is that a very efficient usage of resources can be achieved. The problem is the scalability. While some mechanisms were introduced to aggregate state information to achieve scalability in state information storage, the scalability in terms of signaling messages was not achieved. In particular a specific message is needed from the PEP to the PDP to handle each single flow. A model based on provisioning is much more scalable with respect to signaling: there is no exchange of signaling messages related to single requests. COPS-PR [COPS-PR] has been proposed to handle resources under the provisioning model: the PDP installs configuration decisions so that the client is able to handle events locally. If a "pure" provisioning methods is used, it can be impossible, or inefficient to handle requests for large amount of resources. If one wants to include outsourcing in COPS-PR, the model is not so flexible: it is difficult to handle modification of configured parameters in response to events like resource requests (each modification is handled as a request for a new configuration). It is even more difficult to handle single "special" incoming request with the help of the PDP/BB. From this analysis we derive the following three requirements for the combined model of COPS-DRA: i) it should offer the capability of provisioning resources to local nodes, in order to avoid high signaling burden; ii)it should be easy for the local node to request the modification (increase, decrease) of the provisioned resource; iii) it should be possible to handle specific requests under the Outsourcing model. Salsano Expires May 2002 4 COPS Usage for Diffserv Resource Allocation (COPS-DRA) Oct-01 Let us consider now the QoS client to QoS provider interface. On this interface the QoS client sends QoS reservation requests to the provider, who is in charge to accept or reject the request. In a typical scenario, considering that the provider will not distribute resources in advance to its clients, only the outsourcing model is relevant. 2.2 Components of the reservation requests. The Resource Allocation Requests on the Edge Router to PDP/BB interface are required to carry at least these two components (as already mentioned, an intra-domain QoS scenario is assumed): i) scope and amount of reservation (i.e. where the reservation applies and which is the required bandwidth) ii)type of requested service (possibly including a set of QoS parameters) On the basis of these two components, the admission control function can be performed. Considering the QoS client to QoS provider interface, the reservation request should contain an additional component: iii) flow identification (i.e. to which IP flow or aggregate of flows the reservation applies) The QoS provider needs this information for operations related to the access interface like classification, policing ecc. More complex scenarios may require the addition of specific parameters to these three components or the definition of further components in the reservation request. As an example the "timing" of reservation (immediate reservation, advance reservations and so on) has not been considered in the three mentioned components. Work is ongoing to propose a commonly agreed definition of the semantic content of reservation requests, but this work is in a very early stage [SLS-INT]. For COPS-DRA we took a pragmatic approach and a simple scenario has been considered in order to derive the requirements: i) the scope of the reservation is identified by an ingress and an egress point in the QoS enabled network and the amount of needed resource is identified by a traffic descriptor (e.g. a bandwidth in bytes/s, a token bucket...); ii)the type of requested service is either a Diffserv code point or an index to a previously agreed list of services. iii) for the flow identification the source and destination IP addresses and TCP/UDP ports can be used; Note that, thanks to its extensibility, further functionality may be added to COPS DRA in a later stage. Salsano Expires May 2002 5 COPS Usage for Diffserv Resource Allocation (COPS-DRA) Oct-01 3. COPS-DRA protocol operations This section describes the interaction between a PDP and Diffserv Resource Allocation COPS client. 3.1. Start of operations In order to start operations, the PEP must open the dialogue 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-DRA. 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. If the PEP will use the combined outsourcing and provisioning model (typical case for the Edge Router to PDP/BB interface), it can send a special "configuration request" to ask the PDB/BB to provide the initial provisioning information. This message is a special case of the Resource Allocation Request message described in the following subsection. 3.1 Common operations Following the terminology in [BBREQ], the PEP will send "Resource Allocation Requests" (RAR) to the PDP/BB once the connection is established. There are three types of Resource Allocation Requests: - Outsourced RAR - Aggregated RAR - Configuration RAR A field in the Context object of the COPS-DRA Request message discriminates among the three types. The Outsourced RARs represent the requests for a single specific flow, for which the PEP is outsourcing the admission control decision to the PDP. The Aggregated RAR is a request for an amount of resources (i.e. bandwidth) from an ingress point to an egress point that can be used by the PEP to accommodate a set of flows. The Configuration RAR is sent by the PEP at the beginning of the dialogue with the PDP, in order to request provisioning information. This information is a set of allocated resources (i.e. bandwidth) for ingress/egress points couples. The Outsourced and Aggregated Resource Allocation Requests will always contain: - scope and amount of reservation (e.g. ingress point and egress point in the Diffserv domain, bandwidth): see IPA, EPA and TD objects in section 5 Salsano Expires May 2002 6 COPS Usage for Diffserv Resource Allocation (COPS-DRA) Oct-01 - the type of the requested resource (e.g. the Diffserv code point or an index to a previously agreed list of services): see Rtype objects in section 5 When used on the QoS client to QoS provider interface, the Outsourced Resource Allocation Requests may contain: - the flow identification information (e.g. source and destination IP addresses and TCP/UDP ports): see FlowIDI object in section 5 Outsourced and Aggregated RARs are used to release and to modify the reservations, as explained in section 4. The Outsourced and Aggregated RARs are 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, of the mechanisms used by the PDP/BB to get topological/routing information from the Diffserv domain and the mechanism that could be used to actively control the Diffserv routers are outside the scope of this document. In response to the Outsourced and Aggregated RARs, the PDP sends a reply where it accepts or rejects the RAR. On receiving the answer, the PEP may activate its local QoS mechanisms as needed. The Configuration RARs can either carry no specific request or a list of Ingress / Egress couples and related requested resources. The PDP will reply with a Decision message containing the set of Ingress / Egress couples and allocated resources. Note that the list contained in the Request message is only additional information that can be used by the PDP. The PEP will simply install the information received by the PDP and there is no acceptance / refusal of a Configuration RAR. 3.2 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. For example in case of RSVP client type [COPS-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-DRA the state information is aggregated as much as possible: 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 Salsano Expires May 2002 7 COPS Usage for Diffserv Resource Allocation (COPS-DRA) Oct-01 corresponding amount of allocated resources, per each different resource type. The PDP/BB keeps this state information separately for each different COPS-DRA 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 the aggregate information is stored. The resources allocated for the outsourced requests could to be recorded separately from those allocated for the aggregated request. 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 for outsourced request: the client side (PEP) stores a set of "per flow" outsourced reservation information. Moreover, the state for the aggregated request is recorded separately from the state for outsourced requests. 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 4). This temporary information is deleted in the PDP/BB when the Decision message is sent and in the PEP when this message is received. 3.3 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. As for the "per-flow" state related to outsourced requests, the PEP will send one Request message for each active reservation. As for the aggregate state related to aggregated request, the PEP will send aggregate Resource Allocation requests. Selective re-submissions (i.e. for resource type, ingress or egress point) can be supported. 4. Message Content The COPS protocol enables 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 DRA clients (PEP) that carry client-specific data objects. 4.1 Request (REQ) PEP -> PDP The REQ message is sent by COPS-DRA clients to issue a Resource Allocation Request (RAR) to the PDP. The Resource Allocation Request REQ is used to request new resources, to modify a previous reservation, to release a reservation. It is used both Salsano Expires May 2002 8 COPS Usage for Diffserv Resource Allocation (COPS-DRA) Oct-01 for outsourced request related to single flows and for aggregated request whose resources are used for a set of flows. The Resource Allocation Request REQ is also used to issue a configuration request to the PDP. 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 (Outsourced, Aggregated, Configuration) and the requested operation (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. The Outsourcing RAR REQ message contains a resource request for a single flow. The PDP responds to the resource allocation request with a DEC message containing the answer to the query. The Aggregated RAR REQ may contain resource requests for more than an aggregated flow (i.e. more than one record with ingress/egress point, requested bandwidth, type of service). The PDP accepts or rejects the requests as a whole with a DEC message. The Configuration RAR REQ message contains a (possibly empty) set of resource requests for aggregated flows. The PDP responds to the resource allocation request with a DEC message containing the set of allocated resources: the answer does not represent an acceptance / rejection of the request. The REQ message has the following format: <Request> ::= <Common Header> <Client Handle> <Context = resource allocation> [<ClientSI: RAR data>] [<Integrity>] Note that the COPS objects IN-Int, OUT-Int and LDPDecisions are not included in a COPS-DRA 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. 4.2 Decision (DEC) PDP -> PEP The DEC message is sent from the PDP to a COPS-DRA 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). Salsano Expires May 2002 9 COPS Usage for Diffserv Resource Allocation (COPS-DRA) Oct-01 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-DRA client type has the following format: <Decision Message> ::= <Common Header> <Client Handle> <Decision> | <Error> [<Integrity>] The decision object in turn has the following format: <Decision> ::= <Context> <Decision: Flags> <Decision: Client SI data> 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, for Decisions related to Outsourced and Aggregated RARs. REQ (Context = Outsourced/Aggregated, Add) DEC (Dec Flag = Install) -> The requested resources are successfully allocated DEC (Dec Flag = Remove) -> The requested resources are not allocated REQ (Context = Outsourced/Aggregated, Release) DEC (Dec flag = Install) -> The resources are released DEC (Dec Flag = Remove) -> The resources are still allocated. (This is syntactically correct, but it makes no sense) REQ (Context = Outsourced/Aggregated, Modify) DEC (Dec flag = Install) -> The modification is accepted. The newly requested resources are allocated, while the previous ones Salsano Expires May 2002 10 COPS Usage for Diffserv Resource Allocation (COPS-DRA) Oct-01 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) When the Decision message is related to a Configuration RAR, the answer will always be an Install message: REQ (Context = Configuration) DEC (Dec Flag = Install) -> The set of allocated resources is given in the message 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-DRA. No report is sent by the PEP to confirm the reception of a Decision message related to Outsourced / Aggregated RAR. Only in case of specific errors, the PEP will send back a Report State message to the PDP/BB. When a Decision message related to a Configuration RAR is received by the PEP, the PEP must send a Report State Message notifying the success or failure in accepting the allocated resources. 4.3 Report State (RPT) PEP -> PDP For COPS-DRA client type, the Report State message is sent by the PEP to the PDP when receiving a Decision message related to a Configuration RAR or in case of problems with a received Decision message. In particular, it is used to communicate that the Decision contains a Request identifier that cannot be correlated to a previous request. This event is the manifestation of abnormal behavior. On reception of such Report State message the PDP could start a Synchronization procedure. The RPT message for the COPS-DRA client type has the following format: <Report State Message> ::= <Common Header> <Client Handle> <Report Type> <ClientSI: Req ID> [<Integrity>] 4.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 Salsano Expires May 2002 11 COPS Usage for Diffserv Resource Allocation (COPS-DRA) Oct-01 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> ::= <Common Header> <Client Handle> <ClientSI: SSQ scope>] [<Integrity>] Note that the COPS specification in [COPS] does not foresee a ClientSI object in the SSQ message. 4.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> ::= <Common Header> <Client Handle> <ClientSI: SSQ scope>] [<Integrity>] Note that the COPS specification in [COPS] does not foresee a ClientSI object in the SSC message. 5. COPS-DRA Protocol Objects A new COPS client type for the policy provisioning client is defined: Client Type = 0x4002; Diffserv Resource Allocation Client (DRA Client) COPS messages sent between an DRA client and a COPS server contain a COPS Common Header with this DRA Client type specified: 0 1 2 3 +---------------+---------------+---------------+---------------+ | Version| Flag | Op Code | Client Type = 0x4002 | +---------------+---------------+---------------+---------------+ | Message Length | +---------------+---------------+---------------+---------------+ The COPS-DRA 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: Salsano Expires May 2002 12 COPS Usage for Diffserv Resource Allocation (COPS-DRA) Oct-01 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. 5.1 Request ID Object (ReqID) The Request ID object is used to correlate the Requests sent by the COPS-DRA 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. S-Num = 1, S-Type = 1 0 1 2 3 +---------------+---------------+---------------+---------------+ | Length | S-Num = 1 | S-Type = 1 | +---------------+---------------+---------------+---------------+ | Request ID | +---------------+---------------+---------------+---------------+ 5.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 a typical 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 | +---------------+---------------+---------------+---------------+ Salsano Expires May 2002 13 COPS Usage for Diffserv Resource Allocation (COPS-DRA) Oct-01 S-Type = 2, Ipv6 Address. 0 1 2 3 +---------------+---------------+---------------+---------------+ | Length | S-Num = 2 | S-Type = 2 | +---------------+---------------+---------------+---------------+ | | + + // Ipv6 Address format // + + | | +---------------+---------------+---------------+---------------+ 5.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. See Ingress Point Address for object coding. 5.4 Resource Type Object (RType) This object specifies the type of the requested resources. The Rtype object is carried in the Client Specific Information Object. There are different ways to express the type of service. For this purpose different "S-Type" are defined for this purpose. A possibility is to specify an index to a pre-agreed list of services. The mechanisms for the PEP and PDP to agree on this list of services are not covered by this document. Another possibility is to specify a DS code point. When Diffserv edge-to-edge services (Per-domain-behaviors) will be defined, an additional "S-Type" could be defined. S-Num = 4 S-Type = 1 Diffserv Codepoint (DSCP) 0 1 2 3 +---------------+---------------+---------------+---------------+ | Length | S-Num = 4 | S-Type = 1 | +---------------+---------------+---------------+---------------+ | ////////////////////////// | // | DSCP | +---------------+---------------+---------------+---------------+ Salsano Expires May 2002 14 COPS Usage for Diffserv Resource Allocation (COPS-DRA) Oct-01 S-Type = 2 Index to an agreed list 0 1 2 3 +---------------+---------------+---------------+---------------+ | Length | S-Num = 4 | S-Type = 2 | +---------------+---------------+---------------+---------------+ | | Index | +---------------+---------------+---------------+---------------+ 5.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) | +---------------+---------------+---------------+---------------+ 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. 5.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. Salsano Expires May 2002 15 COPS Usage for Diffserv Resource Allocation (COPS-DRA) Oct-01 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 5.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 4). 5.8 Flow Identification Information (FlowIDI) This object is a container for the flow identification information. It will contain a Flow Reference ID (FRID) which is used to correlate subsequent requests related to this flow and the SIPA, DIPA, SP and DP objects, defined hereafter. Salsano Expires May 2002 16 COPS Usage for Diffserv Resource Allocation (COPS-DRA) Oct-01 S-Num = 16, S-Type = 1: Basic 4 fields identification 0 1 2 3 +---------------+---------------+---------------+---------------+ | Length | S-Num = 16 | S-Type = 1 | +---------------+---------------+---------------+---------------+ | | <FlowIDI S-type 1 Content> | | +---------------+---------------+---------------+---------------+ <FlowIDI S-type 1 Content> ::= <Flow Reference ID> [<Source IP Address>] [<Destination IP Address>] [<Source Port>] [<Destination Port>] The defined S-Type "Basic 4 fields identification" foresee that IP source and destination addresses, transport protocol and source destination port can be specified. If one of these components is missing, it represents a wild card. For example if only source and destination IP addressed are present, the packets will belong to this flow regardless of the transport protocol type and port number. More complex Flow identification mechanism (i.e. range of transport protocol ports, range of IP addresses) are for further study and can be easily added by defining additional S-Type for this object. 5.9 Flow Reference ID (FRID) S-Num = 17, S-Type = 1 0 1 2 3 +---------------+---------------+---------------+---------------+ | Length | S-Num = 17 | S-Type = 1 | +---------------+---------------+---------------+---------------+ | Flow Reference ID | +---------------+---------------+---------------+---------------+ The Flow Reference ID is uniquely assigned by the PEP to identify the flow in future requests. 5.10 Source IP Address (SIPA) S-Num = 18 S-Type = 1, Ipv4 Address. S-Type = 2, Ipv6 Address. See Ingress Point Address object for the representation of the object structure. Salsano Expires May 2002 17 COPS Usage for Diffserv Resource Allocation (COPS-DRA) Oct-01 5.11 Destination IP Address (DIPA) S-Num = 19 S-Type = 1, Ipv4 Address. S-Type = 2, Ipv6 Address. See Ingress Point Address object for the representation of the object structure. 5.12 Source Port (SP) S-Num = 20, S-Type = 1 0 1 2 3 +---------------+---------------+---------------+---------------+ | Length | S-Num = 20 | S-Type = 1 | +---------------+---------------+---------------+---------------+ | ///// | Protocol ID | Port Number | +---------------+---------------+---------------+---------------+ This object actually carries also the protocol type information. It can be used to generically indicate a protocol type if the port Number is set to 0x0000. 5.13 Destination Port (DP) S-Num = 21, S-Type = 1 See Source Port object for the representation of the object structure. This object actually carries also the protocol type information. It can be used to generically indicate a protocol type if the port Number is set to 0x0000. 6. COPS-DRA Client-Specific data format 6.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-DRA client the Request Type flag is always set to 0x02 (Resource-Allocation Request). The Message Type flag is used by the COPS-DRA client to distinguish between Outsourced, Aggregated and Configuration requests. The Message type flag also discriminates add, release and modify requests. Depending on the M-Type, a different content of the ClientSI object for REQ message is used. Salsano Expires May 2002 18 COPS Usage for Diffserv Resource Allocation (COPS-DRA) Oct-01 C-num = 2, C-Type = 1 R-Type = 0x02 M-Type = 1 : Outsourced Add M-Type = 2 : Outsourced Release M-Type = 3 : Outsourced Modify M-Type = 9 : Aggregated Add M-Type = 10 : Aggregated Release M-Type = 11 : Aggregated Modify M-Type = 16 : Configuration 6.2 Client Specific Information Object for REQ message. The Client Specific Information Object carried in the REQ messages for COPS-DRA client contains the description of the resources and has a different format depending on the type of the request, as specified by the context object. If the Context object specifies an Outsourced Add or Outsourced Release request, the ClientSI object has the following format: <Client SI: RAR data> ::= <Request ID> <Ingress Point Address> <Egress Point Address> <Resource Type> <Traffic Description> [<Flow IDI>] The Flow Identification Information is optional. Typically it is used on the QoS client to QoS provider interface is policing / classification mechanisms need to be installed on the network access node, while it is not needed on the Edge Router to PDP/BB interface. If the Context object specifies an Outsourced Modify request, the previous values for Resource Type and Traffic Description are also reported <ClientSI: RAR data> ::= <Request ID> <Ingress Point Address> <Egress Point Address> <Resource Type> (new value) <Traffic Description> (new value) <Resource Type> (old value) <Traffic Description> (old value) [<Flow IDI>] If a Flow IDI was present in the Add request, it must be included in successive Modify and Release requests. Salsano Expires May 2002 19 COPS Usage for Diffserv Resource Allocation (COPS-DRA) Oct-01 In case of Aggregated Add, Release and Modify request, the format of the Client SI RAR data is identical except that the Flow IDI cannot be included. For example for the Aggregated Add and Aggregated Release: <Client SI: RAR data> ::= <Request ID> <Ingress Point Address> <Egress Point Address> <Resource Type> <Traffic Description> In case of Configuration Request, the format of the Client SI RAR data is the following: <Client SI: RAR data> ::= <Request ID> [<Res. Req(s)>] where: <Res. Req(s)> ::= <Res. Req> | <Res. Req(s)> <Res. Req> <Res. Req> ::= <Ingress Point Address> <Egress Point Address> <Resource Type> <Traffic Description> 6.3 Decision Client Specific Info Data object. In case of an answer to Outsourced and Aggregated Requests, the Decision ClientSI data object carries the information needed to correlate the decision with the request and some optional information to explain negative Decisions. It has the following format: <Decision: Client SI data> ::= <Request ID> <Reject Reason> In case of an answer to Configuration Requests, the Decision ClientSI data object carries the information needed to correlate the decision with the request and the information related to the resources to be allocated. It has the following format: <Decision: Client SI data> ::= <Request ID> [<Allocated resources>] where Allocated resources is: <Allocated resources> ::= <Res. Req(s)> Salsano Expires May 2002 20 COPS Usage for Diffserv Resource Allocation (COPS-DRA) Oct-01 6.4 Client Specific Information Object for SSQ and SSC messages. The Client Specific Information Object carried in the SSQ messages for COPS-DRA client describes the scope of the requested (for SSQ message) and performed (for SSC message) synchronize operation. This object has the following format: <ClienSI: SSQ scope> ::= <SSQscope> [<Resource Type>] [<Ingress Point Address>] [<Egress Point Address>] If the "Specific scope" value is expressed in the SSQscope object, then the Resource Type, Ingress Point Address and Egress Point Address object must be included. 6.5 Report Type Object The Report Type is contained in the Report State message. C-num = 12, C-Type = 1 Report-Type = 1 : Success Report-Type = 2 : Failure 6.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. <ClientSI: ReqID> ::= <Request ID> 7. Security Considerations This document relies on COPS for its signaling and its security. Please refer to section "Security Considerations" in [COPS]. 8. IANA Considerations Following the consideration in [COPS], the COPS Diffserv Resource Allocation has been temporarily assigned a client-type value in the range for private use. Future versions of the draft could define new client-type value from the "First Come First Served" range. 9. Illustrative examples for COPS-DRA client This section details two examples related to a successful and to an unsuccessful reservation respectively, for the case of Edge Router to PDB/BB interface and the use of Outsourced requests. Salsano Expires May 2002 21 COPS Usage for Diffserv Resource Allocation (COPS-DRA) Oct-01 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 := <Handle H> <Context: Resource allocation, Outsourced Add> <ClientSI: Request ID: X IPA: 192.168.1.1 EPA: 192.168.129.1 Request type (DSCP): EF TD (Bandwidth): 125kBytes/s > The PDP accepts the reservation. PDP --> PEP DEC := <Handle H> <Context: Resource allocation, Outsourced Add> <Decision: Command = Install> <Decision: Client SI Request ID: X > 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 := <Handle H> <Context: Resource allocation, Outsourced Add> <ClientSI: Request ID: Y IPA: 192.168.1.1 EPA: 192.168.129.1 Request type (DSCP): EF TD (Bandwidth): 250kBytes/s > Salsano Expires May 2002 22 COPS Usage for Diffserv Resource Allocation (COPS-DRA) Oct-01 The PDP rejects the reservation. PDP --> PEP DEC := <Handle H> <Context: Resource allocation, Outsourced Add> <Context: Resource allocation, Add> <Decision: Command = Remove> <Decision: Client SI Request ID: Y > 10. References [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-ODRA] S. Salsano "COPS usage for Outsourcing Diffserv Resource Allocation ", <draft-salsano-cops-odra-00.txt>, October 2001, Work in Progress [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]K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R. Yavatkar, A. Smith "COPS Usage for Policy Provisioning (COPS-PR)", IETF RFC 3084, March 2001. [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] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, M. Speer, R. Braden, J. Wrocklaski, E. Felstaine, A Framework for Integrated Services Operation Over Diffserv Networks, IETF RFC 2998, November 2000 [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, J. Seligson, S. Hahn, K. Chan, A. Smith, "Framework Policy Information Base", <draft-ietf-rap- frameworkpib-03.txt>,November 2000, Work in Progress [RAP] R. Yavatkar, D.Pendarakis, R.Guerin, "A Framework for Policy Based Admission Control", IETF RFC 2753, January 2000. [SLS-INT]Service Level Specification Interest Web Page, http://www.ist- tequila.org/sls.html Salsano Expires May 2002 23 COPS Usage for Diffserv Resource Allocation (COPS-DRA) Oct-01 [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 11. Author Information and Acknoledgements Special thanks to Roberto Mameli, Luca Veltri, Vera Bonanni, Andrea Ferraresi, Fabio Lazzarini, Eleonora Manconi, Donald Papalilo, Enzo Sangregorio for their comments and suggestions and their work on the prototype implementation. Stefano Salsano DIE - University of Rome "Tor Vergata" Via di Tor Vergata, 110 00133 Roma - ITALY CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni email: salsano@coritel.it APPENDIX: Discussion on Provisioning and Outsourcing models [This text is reported from draft-salsano-cops-odra-00.txt] 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 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 A1 below. Salsano Expires May 2002 24 COPS Usage for Diffserv Resource Allocation (COPS-DRA) Oct-01 Edge Device Policy Server +-----------------------------+ +--------------+ | | | | | +--------+ | COPS | | | |Trigger | +-----+ | REQ() | +--------+ | | | events |----->| |----|----------|->| | | | +--------+ | PEP | | | | PDP/BB | | | | |<---|----------|--| | | | +-----+ | COPS | +--------+ | | | DEC() | | +-----------------------------+ +--------------+ Figure A1: 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, [...] Salsano Expires May 2002 25