idnits 2.17.1 draft-salsano-cops-dra-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 24 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The abstract seems to contain references ([COPS], [RAP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 6 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2002) is 8017 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'COPS' on line 1118 looks like a reference -- Missing reference section? 'RAP' on line 1144 looks like a reference -- Missing reference section? 'COPS-ODRA' on line 1121 looks like a reference -- Missing reference section? '2BIT' on line 1110 looks like a reference -- Missing reference section? 'BBREQ' on line 1115 looks like a reference -- Missing reference section? 'BBop' on line 1112 looks like a reference -- Missing reference section? 'UCLA-BB' on line 140 looks like a reference -- Missing reference section? 'COPS-PR' on line 1213 looks like a reference -- Missing reference section? 'SLS-INT' on line 214 looks like a reference -- Missing reference section? 'COPS-RSVP' on line 1124 looks like a reference -- Missing reference section? 'ICC99' on line 1189 looks like a reference -- Missing reference section? 'INTDIF' on line 1185 looks like a reference -- Missing reference section? 'PIB' on line 1217 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Stefano Salsano 3 October 2001 Univ. of Rome "Tor Vergata" 4 Expiration: May 2002 5 File: draft-salsano-cops-dra-00.txt 7 COPS Usage for Diffserv Resource Allocation (COPS-DRA) 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Distribution of this memo is unlimited. 33 Copyright Notice 34 Copyright (C) The Internet Society (2001). All Rights Reserved. 36 Abstract 38 This document introduces a new client type for the COPS protocol to 39 support dynamic DiffServ resource allocation. The client type supports 40 both the Outsourcing and the Provisioning model to achieve a scalable, 41 efficient and flexible handling of network resources. The defined client 42 type can be used: i) on the interface between an Edge Router (Policy 43 Enforcement Point - PEP) and a Diffserv "Bandwidth Broker" (acting as 44 Policy Decision Point -PDP); ii) on the interface between a client of a 45 QoS enabled network (acting as PEP) and the access point of the network 46 provider (e.g. the Edge Router acting as PDP) 48 Salsano Expires Ma 2002 1 49 Table of Contents 51 Abstract........................................................1 52 Glossary........................................................2 53 1. Introduction ................................................3 54 2. COPS-DRA: analysis of requirements ..........................4 55 3. COPS-DRA protocol operations ................................6 56 4. Message Content .............................................8 57 5. COPS-DRA Protocol Objects ...................................12 58 6. COPS-DRA Client-Specific data format ........................18 59 7. Security Considerations .....................................21 60 8. IANA Considerations .........................................21 61 9. Illustrative examples for COPS-DRA client ...................21 62 10.References ..................................................23 63 11.Author Information and Acknoledgements ......................24 64 APPENDIX: Discussion on Provisioning and Outsourcing models 66 Glossary 68 BB Bandwidth Broker 69 ER Edge Router 70 COPS Common Open Policy Service. See [COPS] 71 PDP Policy Decision Point. See [RAP] 72 PEP Policy Enforcement Point. See [RAP] 73 RAR Resource Allocation Request 75 Salsano Expires May 2002 2 76 1. Introduction 78 The COPS (Common Open Policy Service) protocol [COPS] is a simple query 79 and response protocol that allows policy servers (PDPs) to communicate 80 policy decisions to network devices (PEP). In order to be flexible, the 81 COPS protocol has been designed to support multiple types of policy 82 clients. Each client-type can be described in a different usage draft. 83 The purpose of this draft is to describe the use of COPS for dynamic 84 resource allocation in a Diffserv network. The new client-type is called 85 "COPS-DRA" (COPS- Outsourcing Diffserv Resource Allocation). This work 86 extends the previously defined client type which was called "COPS-ODRA" 87 (COPS- Outsourcing Diffserv Resource Allocation) [COPS-ODRA]. While 88 COPS-ODRA was only based on the outsourcing model, COPS-DRA combines the 89 outsourcing and provisioning model, providing a scalable, flexible and 90 efficient handling of network resources. 92 The COPS-DRA signaling mechanisms can be used on two different logical 93 interfaces: 94 i) On the interface between an Edge Router and the Diffserv "Bandwidth 95 Broker" in order to handle the allocation of resources and to 96 request the admission of new flows. In this case the Edge Router 97 acts as PEP and the Bandwidth Broker as PDP. 98 ii)On the interface between a QoS client of a QoS enabled network and 99 the access point of this network in order to signal dynamic request 100 for QoS flows. In this case the QoS client acts as PEP and the 101 network access point (e.g. the provider Edge Router) acts as PDP. 103 The requirements for the signaling mechanisms to be used on these 104 interfaces are different, yet they are related for a large extent. COPS- 105 DRA has been defined taking into account the superset of both types of 106 requirements in order to be used on both types of interfaces. Figure 1 107 below depicts a scenario for COPS-DRA. 109 .--------. 110 | PDP/BB | 111 | | 112 '--------' 113 | 114 | 115 / COPS-DRA 116 / 117 / 118 .------. .------. 119 | QoS | COPS-DRA | Edge | 120 |Client|<-------------->|Router| 121 '------' '------' 123 Figure 1: COPS-DRA to support dynamic Diffserv based IP QoS 125 Salsano Expires May 2002 3 126 2. COPS-DRA: analysis of requirements 128 2.1 Combination of Outsourcing and Provisioning 130 The use of a server to control the admission of traffic within a 131 Diffserv domain has been considered since the very beginning of the 132 discussion about the Diffserv architecture [2BIT]. The admission control 133 server is typically referred to as Bandwidth Broker (BB). 134 The communality between the BB and the PDP are described in [BBREQ] 136 Let us consider first the use of COPS-DRA on the interface between Edge 137 Device and the Bandwidth Broker. The Bandwidth Broker will be denoted by 138 PDP/BB. An intra-domain scenario is assumed, where the PDP/BB is in 139 charge of controlling resource for a network in a single administrative 140 domain. Note that [BBop] and [UCLA-BB] generically discusses the use of 141 COPS for resource admission control in a Diffserv network, but no 142 protocol definition is provided. 144 Two main models are supported by the COPS protocol: Outsourcing and 145 Provisioning. The reader is referred to [COPS-ODRA] sec. 1, for an 146 introduction to the Outsourcing and Provisioning models (for 147 convenience, the related text in [COPS-ODRA] is reported in the Appendix 148 of this document). 150 The COPS-ODRA was only based on the Outsourcing model. The advantage is 151 that a very efficient usage of resources can be achieved. The problem is 152 the scalability. While some mechanisms were introduced to aggregate 153 state information to achieve scalability in state information storage, 154 the scalability in terms of signaling messages was not achieved. In 155 particular a specific message is needed from the PEP to the PDP to 156 handle each single flow. 158 A model based on provisioning is much more scalable with respect to 159 signaling: there is no exchange of signaling messages related to single 160 requests. COPS-PR [COPS-PR] has been proposed to handle resources under 161 the provisioning model: the PDP installs configuration decisions so that 162 the client is able to handle events locally. If a "pure" provisioning 163 methods is used, it can be impossible, or inefficient to handle requests 164 for large amount of resources. If one wants to include outsourcing in 165 COPS-PR, the model is not so flexible: it is difficult to handle 166 modification of configured parameters in response to events like 167 resource requests (each modification is handled as a request for a new 168 configuration). It is even more difficult to handle single "special" 169 incoming request with the help of the PDP/BB. 171 From this analysis we derive the following three requirements for the 172 combined model of COPS-DRA: 173 i) it should offer the capability of provisioning resources to local 174 nodes, in order to avoid high signaling burden; 175 ii)it should be easy for the local node to request the modification 176 (increase, decrease) of the provisioned resource; 177 iii) it should be possible to handle specific requests under the 178 Outsourcing model. 180 Salsano Expires May 2002 4 181 Let us consider now the QoS client to QoS provider interface. On this 182 interface the QoS client sends QoS reservation requests to the provider, 183 who is in charge to accept or reject the request. In a typical scenario, 184 considering that the provider will not distribute resources in advance 185 to its clients, only the outsourcing model is relevant. 187 2.2 Components of the reservation requests. 189 The Resource Allocation Requests on the Edge Router to PDP/BB interface 190 are required to carry at least these two components (as already 191 mentioned, an intra-domain QoS scenario is assumed): 193 i) scope and amount of reservation (i.e. where the reservation applies 194 and which is the required bandwidth) 195 ii)type of requested service (possibly including a set of QoS 196 parameters) 198 On the basis of these two components, the admission control function can 199 be performed. Considering the QoS client to QoS provider interface, the 200 reservation request should contain an additional component: 202 iii) flow identification (i.e. to which IP flow or aggregate of flows 203 the reservation applies) 205 The QoS provider needs this information for operations related to the 206 access interface like classification, policing ecc. 208 More complex scenarios may require the addition of specific parameters 209 to these three components or the definition of further components in the 210 reservation request. As an example the "timing" of reservation 211 (immediate reservation, advance reservations and so on) has not been 212 considered in the three mentioned components. Work is ongoing to propose 213 a commonly agreed definition of the semantic content of reservation 214 requests, but this work is in a very early stage [SLS-INT]. For COPS-DRA 215 we took a pragmatic approach and a simple scenario has been considered 216 in order to derive the requirements: 218 i) the scope of the reservation is identified by an ingress and an 219 egress point in the QoS enabled network and the amount of needed 220 resource is identified by a traffic descriptor (e.g. a bandwidth in 221 bytes/s, a token bucket...); 222 ii)the type of requested service is either a Diffserv code point or an 223 index to a previously agreed list of services. 224 iii) for the flow identification the source and destination IP 225 addresses and TCP/UDP ports can be used; 227 Note that, thanks to its extensibility, further functionality may be 228 added to COPS DRA in a later stage. 230 Salsano Expires May 2002 5 231 3. COPS-DRA protocol operations 233 This section describes the interaction between a PDP and Diffserv 234 Resource Allocation COPS client. 236 3.1. Start of operations 238 In order to start operations, the PEP must open the dialogue with its 239 PDP/BB. First, a TCP connection is established between the client and 240 server and the PEP sends a Client-Open message with the Client-Type = 241 COPS-DRA. If the PDP supports this client type, it responds with a 242 Client-Accept (CAT) message. If the client type is not supported, a 243 Client-Close (CC) message is returned by the PDP to the PEP. After 244 receiving the CAT message, the PEP can send requests to the server. 246 If the PEP will use the combined outsourcing and provisioning model 247 (typical case for the Edge Router to PDP/BB interface), it can send a 248 special "configuration request" to ask the PDB/BB to provide the initial 249 provisioning information. This message is a special case of the Resource 250 Allocation Request message described in the following subsection. 252 3.1 Common operations 254 Following the terminology in [BBREQ], the PEP will send "Resource 255 Allocation Requests" (RAR) to the PDP/BB once the connection is 256 established. 258 There are three types of Resource Allocation Requests: 260 - Outsourced RAR 261 - Aggregated RAR 262 - Configuration RAR 264 A field in the Context object of the COPS-DRA Request message 265 discriminates among the three types. 267 The Outsourced RARs represent the requests for a single specific flow, 268 for which the PEP is outsourcing the admission control decision to the 269 PDP. The Aggregated RAR is a request for an amount of resources (i.e. 270 bandwidth) from an ingress point to an egress point that can be used by 271 the PEP to accommodate a set of flows. The Configuration RAR is sent by 272 the PEP at the beginning of the dialogue with the PDP, in order to 273 request provisioning information. This information is a set of allocated 274 resources (i.e. bandwidth) for ingress/egress points couples. 276 The Outsourced and Aggregated Resource Allocation Requests will always 277 contain: 278 - scope and amount of reservation (e.g. ingress point and egress point 279 in the Diffserv domain, bandwidth): see IPA, EPA and TD objects in 280 section 5 282 Salsano Expires May 2002 6 283 - the type of the requested resource (e.g. the Diffserv code point or 284 an index to a previously agreed list of services): see Rtype objects 285 in section 5 287 When used on the QoS client to QoS provider interface, the Outsourced 288 Resource Allocation Requests may contain: 289 - the flow identification information (e.g. source and destination IP 290 addresses and TCP/UDP ports): see FlowIDI object in section 5 292 Outsourced and Aggregated RARs are used to release and to modify the 293 reservations, as explained in section 4. 295 The Outsourced and Aggregated RARs are used by the PDP to perform the 296 Admission Control procedure. According to the requirements of the 297 requested service, the PDP/BB will properly map the requested edge-to- 298 edge resources into network resources and will assure that such 299 resources are available throughout the Diffserv cloud. The discussion of 300 the Admission Control algorithms in the PDP/BB, of the mechanisms used 301 by the PDP/BB to get topological/routing information from the Diffserv 302 domain and the mechanism that could be used to actively control the 303 Diffserv routers are outside the scope of this document. 305 In response to the Outsourced and Aggregated RARs, the PDP sends a reply 306 where it accepts or rejects the RAR. On receiving the answer, the PEP 307 may activate its local QoS mechanisms as needed. 309 The Configuration RARs can either carry no specific request or a list of 310 Ingress / Egress couples and related requested resources. The PDP will 311 reply with a Decision message containing the set of Ingress / Egress 312 couples and allocated resources. Note that the list contained in the 313 Request message is only additional information that can be used by the 314 PDP. The PEP will simply install the information received by the PDP and 315 there is no acceptance / refusal of a Configuration RAR. 317 3.2 State information in PEP and PDP/BB 319 The COPS protocol is stateful in the sense that Request/Decision state 320 is shared between PEP and PDP. Depending on the COPS client type, one or 321 multiple states can be installed in the context of a single PEP/PDP 322 relationship. The "handle" object uniquely identifies a single installed 323 state at the PEP and at the PDP side. For example in case of RSVP client 324 type [COPS-RSVP], a different state is installed for each RSVP flow 325 (actually one PATH state and one RESV state). This implies that a lot of 326 state information is duplicated in the PEP and in the server. 327 In COPS-DRA the state information is aggregated as much as possible: the 328 state represents the set of resources allocated by the PDP/BB to a PEP. 329 Therefore a unique value for the handle object is used in the context of 330 a single PEP/PDP relationship. The handle is inserted by the PEP in the 331 first request and then it is used in every message by the PEP and by the 332 PDP/BB. 333 The state information in the PDP/BB is represented by the set of the 334 triples (resource type, ingress point, egress point) and the 336 Salsano Expires May 2002 7 337 corresponding amount of allocated resources, per each different resource 338 type. The PDP/BB keeps this state information separately for each 339 different COPS-DRA client (i.e. for each connected PEP). The requests 340 for the same resource type, ingress point, egress point coming from the 341 same PEP are properly composed by the PDP/BB so that the aggregate 342 information is stored. The resources allocated for the outsourced 343 requests could to be recorded separately from those allocated for the 344 aggregated request. 346 This aggregate state information stored in PDP/BB is logically shared by 347 the PEP in the sense that it is the result of the sequence of Request 348 messages sent and of the Decision messages received. There is no need in 349 the PEP to evaluate and store the aggregate state information for 350 outsourced request: the client side (PEP) stores a set of "per flow" 351 outsourced reservation information. Moreover, the state for the 352 aggregated request is recorded separately from the state for outsourced 353 requests. 355 Temporary state information per each request must be stored in the PEP 356 and in the PDP/BB in order to correlate requests with decisions. To this 357 purpose the notion of request ID is needed and a corresponding client 358 specific protocol object is defined (see section 4). This temporary 359 information is deleted in the PDP/BB when the Decision message is sent 360 and in the PEP when this message is received. 362 3.3 Synchronization 364 Synchronization procedures are foreseen in COPS specification to cover 365 failure situations. The basic idea is that the PDP/BB can "reset" the 366 state and ask the PEP to rebuild it by sending proper resource 367 allocation Request messages. As for the "per-flow" state related to 368 outsourced requests, the PEP will send one Request message for each 369 active reservation. As for the aggregate state related to aggregated 370 request, the PEP will send aggregate Resource Allocation requests. 371 Selective re-submissions (i.e. for resource type, ingress or egress 372 point) can be supported. 374 4. Message Content 376 The COPS protocol enables different COPS clients to define their own 377 "named", i.e. client-specific, information for various messages. This 378 section describes the messages exchanged between a COPS server (PDP) and 379 COPS DRA clients (PEP) that carry client-specific data objects. 381 4.1 Request (REQ) PEP -> PDP 383 The REQ message is sent by COPS-DRA clients to issue a Resource 384 Allocation Request (RAR) to the PDP. 386 The Resource Allocation Request REQ is used to request new resources, to 387 modify a previous reservation, to release a reservation. It is used both 389 Salsano Expires May 2002 8 390 for outsourced request related to single flows and for aggregated 391 request whose resources are used for a set of flows. The Resource 392 Allocation Request REQ is also used to issue a configuration request to 393 the PDP. 395 The Client Handle associated with the REQ message originated by the DRA 396 client must be unique for that client but otherwise has no protocol 397 significance at this time. 399 The context object specifies the types of request (Outsourced, 400 Aggregated, Configuration) and the requested operation (Add, Release, 401 Modify). See the description of Context object. 403 The Client Specific info object is used to specify the requested 404 resources and the request identifier. 406 The Outsourcing RAR REQ message contains a resource request for a single 407 flow. The PDP responds to the resource allocation request with a DEC 408 message containing the answer to the query. 410 The Aggregated RAR REQ may contain resource requests for more than an 411 aggregated flow (i.e. more than one record with ingress/egress point, 412 requested bandwidth, type of service). The PDP accepts or rejects the 413 requests as a whole with a DEC message. 415 The Configuration RAR REQ message contains a (possibly empty) set of 416 resource requests for aggregated flows. The PDP responds to the resource 417 allocation request with a DEC message containing the set of allocated 418 resources: the answer does not represent an acceptance / rejection of 419 the request. 421 The REQ message has the following format: 423 ::= 424 425 426 [] 427 [] 429 Note that the COPS objects IN-Int, OUT-Int and LDPDecisions are not 430 included in a COPS-DRA REQ message. 431 Note that resource allocation request messages can be generated and sent 432 to the PDP in response to the receipt of a Synchronize State Request 433 (SSQ) message. 435 4.2 Decision (DEC) PDP -> PEP 437 The DEC message is sent from the PDP to a COPS-DRA client in response to 438 the REQ message received from the PEP. Unsolicited DEC messages cannot 439 be sent for this client type (therefore the solicited decision flag is 440 always set). 442 Salsano Expires May 2002 9 443 The Client Handle must be the same Handle that was received in the REQ 444 message (it is identical for all requests). 446 The Decision object will contain in the Client Specific info the Request 447 ID, which is needed by the PEP to correlate the reply with the query. 449 Each DEC message contains a single decision. 451 The DEC message for the COPS-DRA client type has the following format: 453 ::= 454 455 | 456 [] 458 The decision object in turn has the following format: 460 ::= 461 462 464 The context object will be the same as contained in the REQ message. 465 The Decision: Flags object will contain the answer in the Command-code 466 field according to the COPS specifications. In particular the Command- 467 code will be "Install" to mean a positive answer and "Remove" to mean a 468 negative answer. The following text clarifies how Install and Remove 469 Decisions map into the different request types, for Decisions related to 470 Outsourced and Aggregated RARs. 472 REQ (Context = Outsourced/Aggregated, Add) 474 DEC (Dec Flag = Install) -> The requested resources are 475 successfully allocated 477 DEC (Dec Flag = Remove) -> The requested resources are not 478 allocated 480 REQ (Context = Outsourced/Aggregated, Release) 482 DEC (Dec flag = Install) -> The resources are released 484 DEC (Dec Flag = Remove) -> The resources are still allocated. 485 (This is syntactically correct, but 486 it makes no sense) 488 REQ (Context = Outsourced/Aggregated, Modify) 490 DEC (Dec flag = Install) -> The modification is accepted. The 491 newly requested resources are 492 allocated, while the previous ones 494 Salsano Expires May 2002 10 495 have been released 497 DEC (Dec Flag = Remove) -> The modification is not accepted. The 498 previous allocation is still active. 499 (This also makes sense only if the 500 modification increases the allocated 501 resource) 503 When the Decision message is related to a Configuration RAR, the answer 504 will always be an Install message: 506 REQ (Context = Configuration) 508 DEC (Dec Flag = Install) -> The set of allocated resources is 509 given in the message 511 The Error object is used to communicate COPS protocol error to the PEP, 512 according to the definition in [COPS]. No client specific error sub- 513 codes are used by COPS-DRA. 515 No report is sent by the PEP to confirm the reception of a Decision 516 message related to Outsourced / Aggregated RAR. Only in case of specific 517 errors, the PEP will send back a Report State message to the PDP/BB. 519 When a Decision message related to a Configuration RAR is received by 520 the PEP, the PEP must send a Report State Message notifying the success 521 or failure in accepting the allocated resources. 523 4.3 Report State (RPT) PEP -> PDP 525 For COPS-DRA client type, the Report State message is sent by the PEP to 526 the PDP when receiving a Decision message related to a Configuration RAR 527 or in case of problems with a received Decision message. In particular, 528 it is used to communicate that the Decision contains a Request 529 identifier that cannot be correlated to a previous request. This event 530 is the manifestation of abnormal behavior. On reception of such Report 531 State message the PDP could start a Synchronization procedure. 533 The RPT message for the COPS-DRA client type has the following format: 535 ::= 536 537 538 539 [] 541 4.4 Synchronize State Request (SSQ) PDP -> PEP 543 The Synchronize State Request message is sent by the PDP to the PEP to 544 "reset" the state information. It requests the PEP to send the set of 545 resource allocation REQ messages needed to rebuild the state. The SSQ 547 Salsano Expires May 2002 11 548 can apply to the whole set of PEP active reservations PEP, or to a 549 specific resource type and ingress-egress couple, depending on the 550 information contained in the Client SI object. 552 < Synchronize State> ::= 553 554 ] 555 [] 557 Note that the COPS specification in [COPS] does not foresee a ClientSI 558 object in the SSQ message. 560 4.5 Synchronize State Complete (SSC) PEP -> PDP 562 The Synchronize State Complete message is sent by the PEP to the PDP to 563 inform that all the REQ messages needed to rebuild the state have been 564 sent. The Client SI object is the same received in the SSQ message and 565 specifies the scope of the synchronization procedure which has been 566 completed. 568 < Synchronize State Complete> ::= 569 570 ] 571 [] 573 Note that the COPS specification in [COPS] does not foresee a ClientSI 574 object in the SSC message. 576 5. COPS-DRA Protocol Objects 578 A new COPS client type for the policy provisioning client is defined: 580 Client Type = 0x4002; Diffserv Resource Allocation Client (DRA 581 Client) 583 COPS messages sent between an DRA client and a COPS server contain a 584 COPS Common Header with this DRA Client type specified: 586 0 1 2 3 587 +---------------+---------------+---------------+---------------+ 588 | Version| Flag | Op Code | Client Type = 0x4002 | 589 +---------------+---------------+---------------+---------------+ 590 | Message Length | 591 +---------------+---------------+---------------+---------------+ 593 The COPS-DRA uses new COPS protocol objects that carry client-specific 594 information. This section defines those new objects. 596 The format for these new objects is as follows: 598 Salsano Expires May 2002 12 599 S-Num and S-Type are similar to the C-Num and C-Type used in the base 600 COPS objects. The difference is that S-Num and S-Type are used only for 601 ClientSI specific objects. 603 Length is a two-octet value that describes the number of octets 604 (including the header) that compose the object. If the length in octets 605 does not fall on a 32-bit word boundary, padding must be added to the 606 end of the object so that it is aligned to the next 32-bit boundary 607 before the object can be sent on the wire. On the receiving side, a 608 subsequent object boundary can be found by simply rounding up the 609 previous stated object length to the next 32-bit boundary. 611 5.1 Request ID Object (ReqID) 613 The Request ID object is used to correlate the Requests sent by the 614 COPS-DRA client with the responses coming from the PDP/BB. The ReqID 615 object is chosen by the PEP and it is opaque to the PDP/BB. A different 616 ReqID object is chosen by the PEP for each Request. 617 The ReqID object is carried in the Client Specific Information Object 618 for Request message (PEP -> PDP) and in the Decision ClientSI Data 619 Object (PDP -> PEP). 620 If the PEP receives a Decision with an unrecognized ReqID object, it 621 will send a Report State Message to the PDP to communicate the error. 623 S-Num = 1, S-Type = 1 625 0 1 2 3 626 +---------------+---------------+---------------+---------------+ 627 | Length | S-Num = 1 | S-Type = 1 | 628 +---------------+---------------+---------------+---------------+ 629 | Request ID | 630 +---------------+---------------+---------------+---------------+ 632 5.2 Ingress Point Address (IPA) 634 This object specifies the address of the Ingress Point into the Diffserv 635 domain. 636 The IPA object is carried in the Client Specific Information Object. 637 In a typical scenario the Ingress point coincides with the requesting 638 PEP itself. 640 S-Num = 2 642 S-Type = 1, Ipv4 Address. 644 0 1 2 3 645 +---------------+---------------+---------------+---------------+ 646 | Length | S-Num = 2 | S-Type = 1 | 647 +---------------+---------------+---------------+---------------+ 648 | IPv4 Address format | 649 +---------------+---------------+---------------+---------------+ 651 Salsano Expires May 2002 13 652 S-Type = 2, Ipv6 Address. 654 0 1 2 3 655 +---------------+---------------+---------------+---------------+ 656 | Length | S-Num = 2 | S-Type = 2 | 657 +---------------+---------------+---------------+---------------+ 658 | | 659 + + 660 // Ipv6 Address format // 661 + + 662 | | 663 +---------------+---------------+---------------+---------------+ 665 5.3 Egress Point Address Object (EPA) 667 This object specifies the address of the Egress Point from the Diffserv 668 domain. 669 The EPA object is carried in the Client Specific Information Object. 671 S-Num = 3 673 S-Type = 1, Ipv4 Address. 674 S-Type = 2, Ipv6 Address. 676 See Ingress Point Address for object coding. 678 5.4 Resource Type Object (RType) 680 This object specifies the type of the requested resources. The Rtype 681 object is carried in the Client Specific Information Object. 682 There are different ways to express the type of service. For this 683 purpose different "S-Type" are defined for this purpose. A possibility 684 is to specify an index to a pre-agreed list of services. The mechanisms 685 for the PEP and PDP to agree on this list of services are not covered by 686 this document. Another possibility is to specify a DS code point. When 687 Diffserv edge-to-edge services (Per-domain-behaviors) will be defined, 688 an additional "S-Type" could be defined. 690 S-Num = 4 692 S-Type = 1 Diffserv Codepoint (DSCP) 694 0 1 2 3 695 +---------------+---------------+---------------+---------------+ 696 | Length | S-Num = 4 | S-Type = 1 | 697 +---------------+---------------+---------------+---------------+ 698 | ////////////////////////// | // | DSCP | 699 +---------------+---------------+---------------+---------------+ 701 Salsano Expires May 2002 14 702 S-Type = 2 Index to an agreed list 704 0 1 2 3 705 +---------------+---------------+---------------+---------------+ 706 | Length | S-Num = 4 | S-Type = 2 | 707 +---------------+---------------+---------------+---------------+ 708 | | Index | 709 +---------------+---------------+---------------+---------------+ 711 5.5 Traffic Descriptor Object (TD) 713 This object specifies the amount of the requested resources. 714 The TD object is carried in the Client Specific Information Object. 716 S-Num = 5 718 S-Type = 1 (Bandwidth) 720 0 1 2 3 721 +---------------+---------------+---------------+---------------+ 722 | Length | S-Num = 5 | S-Type = 1 | 723 +---------------+---------------+---------------+---------------+ 724 | Bandwidth (bytes/s) | 725 +---------------+---------------+---------------+---------------+ 727 This description can be used if there is not a more accurate indication 728 on the policing at the ingress interface. 730 S-Type = 2 (Token Size and Measurement Interval) 732 0 1 2 3 733 +---------------+---------------+---------------+---------------+ 734 | Length | S-Num = 5 | S-Type = 2 | 735 +---------------+---------------+---------------+---------------+ 736 | Token Size (bytes) | 737 +---------------+---------------+---------------+---------------+ 738 | Measurement Interval (msec) | 739 +---------------+---------------+---------------+---------------+ 741 This description can be used if there is an indication on the policing 742 at the ingress interface. This information could be used by the PDP/BB 743 in the admission control algorithm. 745 5.6 Reject Reason Object (RejRea) 747 The RejRea object is used to provide the reason for a negative Decision. 748 It is carried in the Decision Client SI Data object. 750 Salsano Expires May 2002 15 751 S-Num = 6, S-Type = 1 753 0 1 2 3 754 +---------------+---------------+---------------+---------------+ 755 | Length | S-Num = 6 | S-Type = 1 | 756 +---------------+---------------+---------------+---------------+ 757 | ////////////////////////// | Reason code | 758 +---------------+---------------+---------------+---------------+ 760 Reason codes are: 762 Reason code = 1 : Resource unavailable 763 Reason code = 2 : Unsupported resource type 764 Reason code = 3 : Unacceptable Ingress Point 765 Reason code = 4 : Unacceptable Egress Point 767 5.7 Synchronize State scope (SSscope) 769 The SSQscope object is used to specify the scope of a Synchronize State 770 operation. The SSQscope object is carried in the Client Specific 771 Information Object for the SSQ and SSC messages. 773 S-Num = 7, S-Type = 1 775 0 1 2 3 776 +---------------+---------------+---------------+---------------+ 777 | Length | S-Num = 7 | S-Type = 1 | 778 +---------------+---------------+---------------+---------------+ 779 | ////////////////////////// | Scope | 780 +---------------+---------------+---------------+---------------+ 782 Allowed value for Scope field are: 784 0 : Generic scope 785 1 : Specific scope 787 If the Scope is Generic, the Synchronize State operation refers to the 788 whole set of resource types and ingress-egress pairs. 789 If scope is Specific, the Synchronize State Request refers to the 790 specific resource type and ingress-egress pair contained in the rest of 791 the ClientSI Object for SSQ and SSR messages (see section 4). 793 5.8 Flow Identification Information (FlowIDI) 795 This object is a container for the flow identification information. It 796 will contain a Flow Reference ID (FRID) which is used to correlate 797 subsequent requests related to this flow and the SIPA, DIPA, SP and DP 798 objects, defined hereafter. 800 Salsano Expires May 2002 16 801 S-Num = 16, S-Type = 1: Basic 4 fields identification 803 0 1 2 3 804 +---------------+---------------+---------------+---------------+ 805 | Length | S-Num = 16 | S-Type = 1 | 806 +---------------+---------------+---------------+---------------+ 807 | | 808 809 | | 810 +---------------+---------------+---------------+---------------+ 812 ::= 813 [] 814 [] 815 [] 816 [] 818 The defined S-Type "Basic 4 fields identification" foresee that IP 819 source and destination addresses, transport protocol and source 820 destination port can be specified. If one of these components is 821 missing, it represents a wild card. For example if only source and 822 destination IP addressed are present, the packets will belong to this 823 flow regardless of the transport protocol type and port number. More 824 complex Flow identification mechanism (i.e. range of transport protocol 825 ports, range of IP addresses) are for further study and can be easily 826 added by defining additional S-Type for this object. 828 5.9 Flow Reference ID (FRID) 830 S-Num = 17, S-Type = 1 832 0 1 2 3 833 +---------------+---------------+---------------+---------------+ 834 | Length | S-Num = 17 | S-Type = 1 | 835 +---------------+---------------+---------------+---------------+ 836 | Flow Reference ID | 837 +---------------+---------------+---------------+---------------+ 839 The Flow Reference ID is uniquely assigned by the PEP to identify the 840 flow in future requests. 842 5.10 Source IP Address (SIPA) 844 S-Num = 18 846 S-Type = 1, Ipv4 Address. 848 S-Type = 2, Ipv6 Address. 850 See Ingress Point Address object for the representation of the object 851 structure. 853 Salsano Expires May 2002 17 854 5.11 Destination IP Address (DIPA) 856 S-Num = 19 858 S-Type = 1, Ipv4 Address. 860 S-Type = 2, Ipv6 Address. 862 See Ingress Point Address object for the representation of the object 863 structure. 865 5.12 Source Port (SP) 867 S-Num = 20, S-Type = 1 869 0 1 2 3 870 +---------------+---------------+---------------+---------------+ 871 | Length | S-Num = 20 | S-Type = 1 | 872 +---------------+---------------+---------------+---------------+ 873 | ///// | Protocol ID | Port Number | 874 +---------------+---------------+---------------+---------------+ 876 This object actually carries also the protocol type information. It can 877 be used to generically indicate a protocol type if the port Number is 878 set to 0x0000. 880 5.13 Destination Port (DP) 882 S-Num = 21, S-Type = 1 884 See Source Port object for the representation of the object structure. 885 This object actually carries also the protocol type information. It can 886 be used to generically indicate a protocol type if the port Number is 887 set to 0x0000. 889 6. COPS-DRA Client-Specific data format 891 6.1 Context object 893 The context object specifies the type of request that triggered the 894 query. It is included in the REQ and in the DEC message. For COPS-DRA 895 client the Request Type flag is always set to 0x02 (Resource-Allocation 896 Request). The Message Type flag is used by the COPS-DRA client to 897 distinguish between Outsourced, Aggregated and Configuration requests. 898 The Message type flag also discriminates add, release and modify 899 requests. Depending on the M-Type, a different content of the ClientSI 900 object for REQ message is used. 902 Salsano Expires May 2002 18 903 C-num = 2, C-Type = 1 905 R-Type = 0x02 907 M-Type = 1 : Outsourced Add 908 M-Type = 2 : Outsourced Release 909 M-Type = 3 : Outsourced Modify 911 M-Type = 9 : Aggregated Add 912 M-Type = 10 : Aggregated Release 913 M-Type = 11 : Aggregated Modify 915 M-Type = 16 : Configuration 917 6.2 Client Specific Information Object for REQ message. 919 The Client Specific Information Object carried in the REQ messages for 920 COPS-DRA client contains the description of the resources and has a 921 different format depending on the type of the request, as specified by 922 the context object. 924 If the Context object specifies an Outsourced Add or Outsourced Release 925 request, the ClientSI object has the following format: 927 ::= 928 929 930 931 932 [] 934 The Flow Identification Information is optional. Typically it is used on 935 the QoS client to QoS provider interface is policing / classification 936 mechanisms need to be installed on the network access node, while it is 937 not needed on the Edge Router to PDP/BB interface. 939 If the Context object specifies an Outsourced Modify request, the 940 previous values for Resource Type and Traffic Description are also 941 reported 943 ::= 944 945 946 (new value) 947 (new value) 948 (old value) 949 (old value) 950 [] 952 If a Flow IDI was present in the Add request, it must be included in 953 successive Modify and Release requests. 955 Salsano Expires May 2002 19 956 In case of Aggregated Add, Release and Modify request, the format of the 957 Client SI RAR data is identical except that the Flow IDI cannot be 958 included. For example for the Aggregated Add and Aggregated Release: 960 ::= 961 962 963 964 966 In case of Configuration Request, the format of the Client SI RAR data 967 is the following: 969 ::= 970 [] 972 where: 974 ::= | 976 ::= 977 978 979 981 6.3 Decision Client Specific Info Data object. 983 In case of an answer to Outsourced and Aggregated Requests, the Decision 984 ClientSI data object carries the information needed to correlate the 985 decision with the request and some optional information to explain 986 negative Decisions. It has the following format: 988 ::= 989 991 In case of an answer to Configuration Requests, the Decision ClientSI 992 data object carries the information needed to correlate the decision 993 with the request and the information related to the resources to be 994 allocated. It has the following format: 996 ::= 997 [] 999 where Allocated resources is: 1001 ::= 1003 Salsano Expires May 2002 20 1004 6.4 Client Specific Information Object for SSQ and SSC messages. 1006 The Client Specific Information Object carried in the SSQ messages for 1007 COPS-DRA client describes the scope of the requested (for SSQ message) 1008 and performed (for SSC message) synchronize operation. This object has 1009 the following format: 1011 ::= 1012 [] 1013 [] 1014 [] 1016 If the "Specific scope" value is expressed in the SSQscope object, then 1017 the Resource Type, Ingress Point Address and Egress Point Address object 1018 must be included. 1020 6.5 Report Type Object 1022 The Report Type is contained in the Report State message. 1024 C-num = 12, C-Type = 1 1026 Report-Type = 1 : Success 1027 Report-Type = 2 : Failure 1029 6.6 Client Specific Information Object for Report State message. 1031 The Client SI object for Report State message is used to communicate to 1032 the PDP that a Request ID was not recognized. 1034 ::= 1036 7. Security Considerations 1038 This document relies on COPS for its signaling and its security. Please 1039 refer to section "Security Considerations" in [COPS]. 1041 8. IANA Considerations 1043 Following the consideration in [COPS], the COPS Diffserv Resource 1044 Allocation has been temporarily assigned a client-type value in the 1045 range for private use. Future versions of the draft could define new 1046 client-type value from the "First Come First Served" range. 1048 9. Illustrative examples for COPS-DRA client 1050 This section details two examples related to a successful and to an 1051 unsuccessful reservation respectively, for the case of Edge Router to 1052 PDB/BB interface and the use of Outsourced requests. 1054 Salsano Expires May 2002 21 1055 In the following example the PEP requests the reservation of 1 Mb/s of 1056 EF traffic between ingress point 192.168.1.1 and the egress point 1057 192.168.129.1. 1059 PEP --> PDP REQ := 1060 1062 1070 The PDP accepts the reservation. 1072 PDP --> PEP DEC := 1073 1075 1076 1080 In the following example the PEP requests the reservation of 2 Mb/s of 1081 EF traffic between ingress point 192.168.1.1 and the egress point 1082 192.168.129.1. Note that the same Handle is used, while the Request ID 1083 is different. 1085 PEP --> PDP REQ := 1086 1088 1096 Salsano Expires May 2002 22 1097 The PDP rejects the reservation. 1099 PDP --> PEP DEC := 1100 1102 1103 1104 1108 10. References 1110 [2BIT] K. Nichols, V. Jacobson, L. Zhang " A Two-bit Differentiated 1111 Services Architecture for the Internet "RFC 2638, July 1999 1112 [BBop] First Internet2 bandwidth broker operability event 1113 http://www.merit.edu/internet/working.groups/i2-qbone- 1114 bb/inter-op/index.htm 1115 [BBREQ] R. Neilson, J. Wheeler, F. Reichmeyer, S. Hares (Editors), "A 1116 Discussion of Bandwidth Broker Requirements for Internet2 1117 Qbone Deployment" Version 0.7 1118 [COPS] D. Durham, Ed., J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. 1119 Sastry "The COPS (Common Open Policy Service) Protocol", IETF 1120 RFC 2748, January 2000 1121 [COPS-ODRA] S. Salsano "COPS usage for Outsourcing Diffserv Resource 1122 Allocation ", , October 2001, 1123 Work in Progress 1124 [COPS-RSVP] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, A. 1125 Sastry, "COPS usage for RSVP ", IETF RFC 2749, January 2000 1126 [COPS-PR]K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie, S. 1127 Herzog, F. Reichmeyer, R. Yavatkar, A. Smith "COPS Usage for 1128 Policy Provisioning (COPS-PR)", IETF RFC 3084, March 2001. 1129 [ICC99] A. Detti, M.Listanti, S.Salsano, L.Veltri, "Supporting RSVP in 1130 a Differentiated Service Domain: an Architectural Framework 1131 and a Scalability Analysis", ICC '99, June 1999, Vancouver, 1132 Canada. 1133 [INTDIF] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, M. Speer, 1134 R. Braden, J. Wrocklaski, E. Felstaine, A Framework for 1135 Integrated Services Operation Over Diffserv Networks, IETF RFC 1136 2998, November 2000 1137 [IWQOS99]O. Schelen, A. Nilsson, J. Norrgard,S. Pink: Performance of 1138 QoS Agents for Provisioning Network Resources. In Proceedings 1139 of IFIP Seventh International Workshop on Quality of Service 1140 (IWQoS'99), London, UK, June 1999. 1141 [PIB] M. Fine, K. McCloghrie, J. Seligson, S. Hahn, K. Chan, A. 1142 Smith, "Framework Policy Information Base", ,November 2000, Work in Progress 1144 [RAP] R. Yavatkar, D.Pendarakis, R.Guerin, "A Framework for Policy 1145 Based Admission Control", IETF RFC 2753, January 2000. 1146 [SLS-INT]Service Level Specification Interest Web Page, http://www.ist- 1147 tequila.org/sls.html 1149 Salsano Expires May 2002 23 1150 [UCLA-BB]A. Terzis, J.Ogawa, S.Tsui, L.Wang, L.Zhang "A prototype 1151 Implementation of the Two-Tier Architecture for Differentiated 1152 Services" IEEE Workshop on QoS Support for Real-Time Internet 1153 Applications, June 2-4, 1999 Vancouver, Canada 1155 11. Author Information and Acknoledgements 1157 Special thanks to Roberto Mameli, Luca Veltri, Vera Bonanni, Andrea 1158 Ferraresi, Fabio Lazzarini, Eleonora Manconi, Donald Papalilo, Enzo 1159 Sangregorio for their comments and suggestions and their work on the 1160 prototype implementation. 1162 Stefano Salsano 1163 DIE - University of Rome "Tor Vergata" 1164 Via di Tor Vergata, 110 1165 00133 Roma - ITALY 1166 CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni 1167 email: salsano@coritel.it 1169 APPENDIX: Discussion on Provisioning and Outsourcing models 1171 [This text is reported from draft-salsano-cops-odra-00.txt] 1173 Two main models are supported by the COPS protocol: Outsourcing and 1174 Provisioning. The COPS-ODRA client relies on the Outsourcing model. The 1175 PEP explicitly asks the PDP/BB for a given amount of resources, from an 1176 ingress point to an egress point. Note that per-flow state is not stored 1177 in the PDP/BB. Instead, resource allocation requests are properly 1178 aggregated and only aggregate state information is kept in the PDP/BB, 1179 allowing for higher scalability. In this context, resource allocation is 1180 strictly related to admission control: the server controls the 1181 allocation of resources by admitting or rejecting the requests coming 1182 from its clients. 1184 An example application scenario for the COPS-ODRA is the Intserv 1185 operation over Diffserv networks, as described in [INTDIF]. In this 1186 scenario, the Edge Router includes the PEP and interacts with the PDB/BB 1187 using COPS-ODRA according to the reservation requests coming from RSVP 1188 messages. An architectural definition and scalability analysis of this 1189 scenario can be found in [ICC99] 1191 [...] 1193 The Outsourcing model is used when there are "Trigger events" in the PEP 1194 that require a policy decision (e.g. a dynamic request to admit a new 1195 flow). The PEP delegates this decision to an external policy server 1196 (PDP). It sends a query message to the PDP, typically waiting for the 1197 response decision before admitting the new flow. See Figure A1 below. 1199 Salsano Expires May 2002 24 1200 Edge Device Policy Server 1201 +-----------------------------+ +--------------+ 1202 | | | | 1203 | +--------+ | COPS | | 1204 | |Trigger | +-----+ | REQ() | +--------+ | 1205 | | events |----->| |----|----------|->| | | 1206 | +--------+ | PEP | | | | PDP/BB | | 1207 | | |<---|----------|--| | | 1208 | +-----+ | COPS | +--------+ | 1209 | | DEC() | | 1210 +-----------------------------+ +--------------+ 1211 Figure A1: COPS-ODRA Outsourcing Model 1213 On the other hand, the Provisioning model [COPS-PR] foresees that the 1214 PDP proactively configures the PEP so that it knows how to run its QoS 1215 mechanisms. The mechanisms to exchange the configuration information and 1216 to store this information is based on the definition of a "Policy 1217 Information Base", see [PIB]. 1218 In the Provisioning model, either there are no "Trigger events" at the 1219 PEP (i.e. only packet classification, marking, scheduling, etc. is 1220 performed at the PEP) or these events must be handled using local 1221 information (i.e. mapped in the available resources provisioned by the 1222 PDP). 1223 The Provisioning model is very well suited when there are no such 1224 dynamic requests coming to the PEP. In other scenarios, like for example 1225 the RSVP/Diffserv interworking the dynamic requests are a fundamental 1226 feature in the PEP/Edge Router. In this case a possible solution is to 1227 fully rely on the Outsourcing model, so that a very simple PEP can be 1228 defined. The drawback is the need of relatively frequent communication 1229 with the PDP, but there are scenarios where this solution can be cost- 1230 effective. 1231 Note that the Outsourcing model lends itself to more sophisticated 1232 solutions if scalability concerns arise. In fact the Outsourcing model 1233 can be dynamically paced by the PEP in real-time. A straightforward 1234 option is to pre-reserve some amount of bandwidth to limit the pace of 1235 Resource Admission Requests. The definition of these mechanisms is out 1236 of the scope of this document, which focuses on the protocol 1237 specification for the COPS-ODRA client. 1238 In general, a combination of Outsourcing and Provisioning model could be 1239 used to provide a flexible and general solution for QoS in IP networks, 1240 [...] 1242 Salsano Expires May 2002 25