idnits 2.17.1 draft-salsano-issll-cops-odra-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 17 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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. 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 (February 22, 2000) is 8829 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 801 looks like a reference -- Missing reference section? 'RAP' on line 826 looks like a reference -- Missing reference section? '2BIT' on line 792 looks like a reference -- Missing reference section? 'BBREQ' on line 798 looks like a reference -- Missing reference section? 'INTDIF' on line 812 looks like a reference -- Missing reference section? 'ICC99' on line 808 looks like a reference -- Missing reference section? 'BBop' on line 795 looks like a reference -- Missing reference section? 'UCLA-BB' on line 115 looks like a reference -- Missing reference section? 'COPS-PR' on line 141 looks like a reference -- Missing reference section? 'PIB' on line 822 looks like a reference -- Missing reference section? 'IWQOS99' on line 209 looks like a reference -- Missing reference section? 'COPS-RSVP' on line 804 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Stefano Salsano 2 Expiration: August 2000 CoRiTeL 3 File: draft-salsano-issll-cops-odra-00.txt 5 COPS Usage for Outsourcing Diffserv Resource Allocation 7 February 22, 2000 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 35 Copyright (C) The Internet Society (2000). All Rights Reserved. 37 Abstract 39 This document introduces a new client type for the COPS protocol to 40 support dynamic DiffServ admission control. The Policy Decision Point 41 (PDP) acts as a "Bandwidth Broker" for the Policy Enforcement Point 42 (PEP) which is requesting resources. The use of the defined mechanism is 43 suited for (but it is not limited to) the Integrated Services operation 44 over Diffserv networks. 46 Salsano Expires August 2000 1 47 Table of Contents 49 Abstract........................................................2 50 Glossary........................................................2 51 1. Introduction ................................................3 52 2. Interaction between the COPS-ODRA PEP and PDP/BB ............4 53 3. Message Content .............................................6 54 4. COPS-ODRA Protocol Objects ..................................9 55 5. COPS-ODRA Client-Specific data format .......................12 56 6. Security Considerations .....................................14 57 7. Illustrative examples for COPS-ODRA client ..................14 58 8. References ..................................................15 59 9. Author Information and Acknoledgements ......................15 61 Glossary 63 BB Bandwidth Broker 64 ER Edge Router 65 COPS Common Open Policy Service. See [COPS] 66 PDP Policy Decision Point. See [RAP] 67 PEP Policy Enforcement Point. See [RAP] 69 Salsano Expires August 2000 2 70 1. Introduction 72 The COPS (Common Open Policy Service) protocol [COPS] is a simple query 73 and response protocol that allows policy servers (PDPs) to communicate 74 policy decisions to network devices (PEP). In order to be flexible, the 75 COPS protocol has been designed to support multiple types of policy 76 clients. Each client-type can be described in a different usage draft. 77 The purpose of this draft is to describe the use of COPS for outsourcing 78 the allocation of resources in a Diffserv network. The new client-type 79 is called "COPS-ODRA" (COPS- Outsourcing Diffserv Resource Allocation). 81 The use of a server to control the admission of traffic within a 82 Diffserv domain has been considered since the very beginning of the 83 discussion about the Diffserv architecture [2BIT]. The admission control 84 server is typically referred to as Bandwidth Broker (BB). 85 The communality between the BB and the PDP are described in [BBREQ]. In 86 this draft the use of COPS for the communication between the Edge Device 87 and the Bandwidth Broker is proposed. Therefore the Bandwidth Broker 88 will be denoted PDP/BB. An intra-domain scenario is assumed, where the 89 PDP/BB is in charge of controlling resource for a network in a single 90 administrative domain. 92 Two main models are supported by the COPS protocol: Outsourcing and 93 Provisioning. The COPS-ODRA client relies on the Outsourcing model. The 94 PEP explicitly asks the PDP/BB for a given amount of resources, from an 95 ingress point to an egress point. Note that per-flow state is not stored 96 in the PDP/BB. Instead, resource allocation requests are properly 97 aggregated and only aggregate state information is kept in the PDP/BB, 98 allowing for higher scalability. In this context, resource allocation is 99 strictly related to admission control: the server controls the 100 allocation of resources by admitting or rejecting the requests coming 101 from its clients. 103 An example application scenario for the COPS-ODRA is the Intserv 104 operation over Diffserv networks, as described in [INTDIF]. In this 105 scenario, the Edge Router includes the PEP and interacts with the PDB/BB 106 using COPS-ODRA according to the reservation requests coming from RSVP 107 messages. An architectural definition and scalability analysis of this 108 scenario can be found in [ICC99] 109 The examples used in this document are biased towards this type of 110 RSVP/Diffserv interworking. However, the COPS-ODRA client type can be 111 used for supporting centralized Resource Allocation control arising from 112 different types of scenario. 114 The use of COPS for resource admission control in a Diffserv network is 115 assumed in some studies and prototypes (see for example [BBop], [UCLA- 116 BB]). Anyway, no formal description of the protocol has been proposed so 117 far. 119 Salsano Expires August 2000 3 120 1.1 Discussion on the Outsourcing model 122 The Outsourcing model is used when there are "Trigger events" in the PEP 123 that require a policy decision (e.g. a dynamic request to admit a new 124 flow). The PEP delegates this decision to an external policy server 125 (PDP). It sends a query message to the PDP, typically waiting for the 126 response decision before admitting the new flow. See Figure 1 below. 128 Edge Device Policy Server 129 +-----------------------------+ +--------------+ 130 | | | | 131 | +--------+ | COPS | | 132 | |Trigger | +-----+ | REQ() | +--------+ | 133 | | events |----->| |----|----------|->| | | 134 | +--------+ | PEP | | | | PDP/BB | | 135 | | |<---|----------|--| | | 136 | +-----+ | COPS | +--------+ | 137 | | DEC() | | 138 +-----------------------------+ +--------------+ 139 Figure 1: COPS-ODRA Outsourcing Model 141 On the other hand, the Provisioning model [COPS-PR] foresees that the 142 PDP proactively configures the PEP so that it knows how to run its QoS 143 mechanisms. The mechanisms to exchange the configuration information and 144 to store this information is based on the definition of a "Policy 145 Information Base", see [PIB]. 146 In the Provisioning model, either there are no "Trigger events" at the 147 PEP (i.e. only packet classification, marking, scheduling, etc. is 148 performed at the PEP) or these events must be handled using local 149 information (i.e. mapped in the available resources provisioned by the 150 PDP). 151 The Provisioning model is very well suited when there are no such 152 dynamic requests coming to the PEP. In other scenarios, like for example 153 the RSVP/Diffserv interworking the dynamic requests are a fundamental 154 feature in the PEP/Edge Router. In this case a possible solution is to 155 fully rely on the Outsourcing model, so that a very simple PEP can be 156 defined. The drawback is the need of relatively frequent communication 157 with the PDP, but there are scenarios where this solution can be cost- 158 effective. 159 Note that the Outsourcing model lends itself to more sophisticated 160 solutions if scalability concerns arise. In fact the Outsourcing model 161 can be dynamically paced by the PEP in real-time. A straightforward 162 option is to pre-reserve some amount of bandwidth to limit the pace of 163 Resource Admission Requests. The definition of these mechanisms is out 164 of the scope of this document, which focuses on the protocol 165 specification for the COPS-ODRA client. 166 In general, a combination of Outsourcing and Provisioning model could be 167 used to provide a flexible and general solution for QoS in IP networks, 168 but this is outside the scope of this document. 170 Salsano Expires August 2000 4 171 2. Interaction between the COPS-ODRA PEP and PDP/BB 173 This section describes the interaction between a PDP and Diffserv 174 Resource Admission Control COPS client. 176 2.1. Start of operations 178 In order to start operations, the PEP must open the dialogue connection 179 with its PDP/BB. First, a TCP connection is established between the 180 client and server and the PEP sends a Client-Open message with the 181 Client-Type = COPS-ODRA. If the PDP supports this client type, it 182 responds with a Client-Accept (CAT) message. If the client type is not 183 supported, a Client-Close (CC) message is returned by the PDP to the 184 PEP. After receiving the CAT message, the PEP can send requests to the 185 server. 187 2.2. Common operations 189 Following the terminology in [BBREQ], the PEP will send "Resource 190 Allocation Requests" (RAR) to the PDP/BB once the connection is 191 established. 192 A Resource Allocation Request will contain: 193 - the topological information (e.g. ingress point and egress point in 194 the Diffserv domain) which allows the PDP/BB to aggregate different 195 Resource Requests 196 - the type of the requested resource (e.g. the Diffserv Per Hop 197 Behavior or Behavior Aggregates) 198 - the amount of the requested resource (e.g. the specification of the 199 bandwidth) 201 The resource allocation request is used by the PDP to perform the 202 Admission Control procedure. According to the requirements of the 203 requested service, the PDP/BB will properly map the requested edge-to- 204 edge resources into network resources and will assure that such 205 resources are available throughout the Diffserv cloud. The discussion of 206 the Admission Control algorithms in the PDP/BB and of the mechanisms 207 used by the PDP/BB to get topological/routing information from the 208 Diffserv domain are outside the scope of this document. Related work can 209 be found in [IWQOS99], where the use of OSPF and SNMP for the 210 communication between the BB and the Diffserv routers is proposed. 212 In response to the Resource Allocation request, the PDP sends a reply 213 where it accepts or rejects the RAR. On receiving the answer, the PEP 214 activates its local QoS mechanisms as needed. 216 2.3 State information in PEP and PDP/BB 218 The COPS protocol is stateful in the sense that Request/Decision state 219 is shared between PEP and PDP. Depending on the COPS client type, one or 220 multiple states can be installed in the context of a single PEP/PDP 221 relationship. The "handle" object uniquely identifies a single installed 222 state at the PEP and at the PDP side. In case of RSVP client type [COPS- 224 Salsano Expires August 2000 5 225 RSVP], a different state is installed for each RSVP flow (actually one 226 PATH state and one RESV state). This implies that a lot of state 227 information is duplicated in the PEP and in the server. 228 In COPS-ODRA the state information is aggregated: the state represents 229 the set of resources allocated by the PDP/BB to a PEP. Therefore a 230 unique value for the handle object is used in the context of a single 231 PEP/PDP relationship. The handle is inserted by the PEP in the first 232 request and then it is used in every message by the PEP and by the 233 PDP/BB. 234 The state information in the PDP/BB is represented by the set of the 235 triples (resource type, ingress point, egress point) and the 236 corresponding amount of allocated resources. The PDP/BB keeps this state 237 information separately for each different COPS-ODRA client (i.e. for 238 each connected PEP). The requests for the same resource type, ingress 239 point, egress point coming from the same PEP are properly composed by 240 the PDP/BB so that only the aggregate information is stored. 241 This aggregate state information stored in PDP/BB is logically shared by 242 the PEP in the sense that it is the result of the sequence of Request 243 messages sent and of the Decision messages received. There is no need in 244 the PEP to evaluate and store the aggregate state information: in the 245 simplest case, the client side (PEP) stores a set of "per flow" 246 reservation information. In more advanced scenarios, the PEP client can 247 evaluate and store aggregate information. 248 Temporary state information per each request must be stored in the PEP 249 and in the PDP/BB in order to correlate requests with decisions. To this 250 purpose the notion of request ID is needed and a corresponding client 251 specific protocol object is defined (see section 3). This temporary 252 information is deleted in the PDP/BB when the Decision message is sent 253 and in the PEP when this message is received. 255 2.4 Synchronization 257 Synchronization procedures are foreseen in COPS specification to cover 258 failure situations. The basic idea is that the PDP/BB can "reset" the 259 state and ask the PEP to rebuild it by sending proper resource 260 allocation Request messages. If the PEP has only stored "per-flow" 261 state, it will send one Request message for each active reservation. If 262 the PEP has stored aggregate states, it can send "aggregate" Resource 263 Allocation requests. 264 Selective re-submissions (i.e. for resource type, ingress or egress 265 point) can be supported. 267 3. Message Content 269 The COPS protocol provides for different COPS clients to define their 270 own "named", i.e. client-specific, information for various messages. 271 This section describes the messages exchanged between a COPS server 272 (PDP) and COPS ODRA clients (PEP) that carry client-specific data 273 objects. 275 Salsano Expires August 2000 6 276 3.1. Request (REQ) PEP -> PDP 278 The REQ message is sent by COPS-ODRA clients to issue a 'Resource 279 Allocation Request' to the PDP. 281 The Resource Allocation Request REQ is used to request new resources, to 282 modify a previous reservation, to release a reservation. 284 The Client Handle associated with the REQ message originated by the DRA 285 client must be unique for that client but otherwise has no protocol 286 significance at this time. 288 The context object specifies the types of request (Add, Release, Modify, 289 see the description of Context object). 291 The Client Specific info object is used to specify the requested 292 resources and the request identifier. 294 Each REQ message contains a single request. The PDP responds to the 295 resource allocation request with a DEC message containing the answer to 296 the query. 298 The REQ message has the following format: 300 ::= 301 302 303 [] 304 [] 306 Note that the COPS objects IN-Int, OUT-Int and LDPDecisions are not 307 included in a COPS-ODRA REQ message. 308 Note that resource allocation request messages can be generated and sent 309 to the PDP in response to the receipt of a Synchronize State Request 310 (SSQ) message. 312 3.2. Decision (DEC) PDP -> PEP 314 The DEC message is sent from the PDP to a COPS-ODRA client in response 315 to the REQ message received from the PEP. Unsolicited DEC messages 316 cannot be sent for this client type (therefore the solicited decision 317 flag is always set). 318 The Client Handle must be the same Handle that was received in the REQ 319 message (it is identical for all requests). 321 The Decision object will contain in the Client Specific info the Request 322 ID, which is needed by the PEP to correlate the reply with the query. 324 Each DEC message contains a single decision. 326 The DEC message for the COPS-ODRA client type has the following format: 328 ::= 330 Salsano Expires August 2000 7 331 332 | 333 [] 335 The decision object in turn has the following format: 337 ::= 338 339 341 The context object will be the same as contained in the REQ message. 342 The Decision: Flags object will contain the answer in the Command-code 343 field according to the COPS specifications. In particular the Command- 344 code will be "Install" to mean a positive answer and "Remove" to mean a 345 negative answer. The following text clarifies how Install and Remove 346 Decisions map into the different request types. 348 REQ (Context = Add) 349 DEC (Dec Flag = Install) -> The requested resources are 350 successfully allocated 352 DEC (Dec Flag = Remove) -> The requested resources are not 353 allocated 355 REQ (Context = Release) 357 DEC (Dec flag = Install) -> The resources are released 359 DEC (Dec Flag = Remove) -> The resources are still allocated. 360 (This is syntactically correct, but 361 it make no sense) 363 REQ (Context = Modify) 365 DEC (Dec flag = Install) -> The modification is accepted. The 366 newly requested resources are 367 allocated, while the previous ones 368 have been released 370 DEC (Dec Flag = Remove) -> The modification is not accepted. The 371 previous allocation is still active. 372 (This also makes sense only if the 373 modification increases the allocated 374 resource) 376 The Error object is used to communicate COPS protocol error to the PEP, 377 according to the definition in [COPS]. No client specific error sub- 378 codes are used by COPS-ODRA. 380 Salsano Expires August 2000 8 381 No report is sent by the PEP to confirm the reception of a Decision 382 message. Only in case of specific errors, the PEP will send back a 383 Report State message to the PDP/BB. 385 3.3. Report State (RPT) PEP -> PDP 387 For COPS-ODRA client type, the Report State message is sent by the PEP 388 to the PDP in case of problems with a received Decision message. More 389 specifically it is used to communicate that the Decision contains a 390 Request identifier which cannot be correlated to a previous request. 391 This event is the manifestation of abnormal behavior. On reception of a 392 Report State message the PDP could start a Synchronization procedure. 394 The RPT message for the COPS-ODRA client type has the following format: 396 ::= 397 398 399 400 [] 402 3.4. Synchronize State Request (SSQ) PDP -> PEP 404 The Synchronize State Request message is sent by the PDP to the PEP to 405 "reset" the state information. It requests the PEP to send the set of 406 resource allocation REQ messages needed to rebuild the state. The SSQ 407 can apply to the whole set of PEP active reservations PEP, or to a 408 specific resource type and ingress-egress couple, depending on the 409 information contained in the Client SI object. 411 < Synchronize State> ::= 412 413 ] 414 [] 416 Note that the COPS specification in [COPS] does not foresee a ClientSI 417 object in the SSQ message. 419 3.5. Synchronize State Complete (SSC) PEP -> PDP 421 The Synchronize State Complete message is sent by the PEP to the PDP to 422 inform that all the REQ messages needed to rebuild the state have been 423 sent. The Client SI object is the same received in the SSQ message and 424 specifies the scope of the synchronization procedure which has been 425 completed. 427 < Synchronize State Complete> ::= 428 429 ] 430 [] 432 Salsano Expires August 2000 9 433 Note that the COPS specification in [COPS] does not foresee a ClientSI 434 object in the SSC message. 436 4. COPS-ODRA Protocol Objects 438 A new COPS client type for the policy provisioning client is defined: 440 Client Type = 5; Outsourcing Diffserv Resource Allocation Client 441 (ODRA Client) 443 COPS messages sent between an ODRA client and a COPS server contain a 444 COPS Common Header with this ODRA Client type specified: 446 0 1 2 3 447 +---------------+---------------+---------------+---------------+ 448 | Version| Flag | Op Code | Client Type = 0x05 | 449 +---------------+---------------+---------------+---------------+ 450 | Message Length | 451 +---------------+---------------+---------------+---------------+ 453 The COPS-ODRA uses new COPS protocol objects that carry client-specific 454 information. This section defines those new objects. 456 The format for these new objects is as follows: 458 S-Num and S-Type are similar to the C-Num and C-Type used in the base 459 COPS objects. The difference is that S-Num and S-Type are used only for 460 ClientSI specific objects. 462 Length is a two-octet value that describes the number of octets 463 (including the header) that compose the object. If the length in octets 464 does not fall on a 32-bit word boundary, padding must be added to the 465 end of the object so that it is aligned to the next 32-bit boundary 466 before the object can be sent on the wire. On the receiving side, a 467 subsequent object boundary can be found by simply rounding up the 468 previous stated object length to the next 32-bit boundary. 470 4.1. Request ID Object (ReqID) 472 The Request ID object is used to correlate the Requests sent by the 473 COPS-ODRA client with the responses coming from the PDP/BB. The ReqID 474 object is chosen by the PEP and it is opaque to the PDP/BB. A different 475 ReQID object is chosen by the PEP for each Request. 476 The ReqID object is carried in the Client Specific Information Object 477 for Request message (PEP -> PDP) and in the Decision ClientSI Data 478 Object (PDP -> PEP). 479 If the PEP receives a Decision with an unrecognized ReqID object, it 480 will send a Report State Message to the PDP to communicate the error. 482 Salsano Expires August 2000 10 483 S-Num = 1, S-Type = 1 485 0 1 2 3 486 +---------------+---------------+---------------+---------------+ 487 | Length | S-Num = 1 | S-Type = 1 | 488 +---------------+---------------+---------------+---------------+ 489 | Request ID | 490 +---------------+---------------+---------------+---------------+ 492 4.2. Ingress Point Address (IPA) 494 This object specifies the address of the Ingress Point into the Diffserv 495 domain. 496 The IPA object is carried in the Client Specific Information Object. 497 In the RSVP Diffserv interaction scenario the Ingress point coincides 498 with the requesting PEP itself. 500 S-Num = 2 502 S-Type = 1, Ipv4 Address. 504 0 1 2 3 505 +---------------+---------------+---------------+---------------+ 506 | Length | S-Num = 2 | S-Type = 1 | 507 +---------------+---------------+---------------+---------------+ 508 | IPv4 Address format | 509 +---------------+---------------+---------------+---------------+ 511 S-Type = 2, Ipv6 Address. 513 0 1 2 3 514 +---------------+---------------+---------------+---------------+ 515 | Length | S-Num = 2 | S-Type = 2 | 516 +---------------+---------------+---------------+---------------+ 517 | | 518 + + 519 | Ipv6 Address format | 520 + + 521 | | 522 +---------------+---------------+---------------+---------------+ 524 4.3. Egress Point Address Object (EPA) 526 This object specifies the address of the Egress Point from the Diffserv 527 domain. 528 The EPA object is carried in the Client Specific Information Object. 530 S-Num = 3 532 S-Type = 1, Ipv4 Address. 533 S-Type = 2, Ipv6 Address. 535 Salsano Expires August 2000 11 536 See Ingress Point Address for object coding. 538 4.4. Resource Type Object (RType) 540 This object specifies the type of the requested resources. In a Diffserv 541 scenario, the simplest option is to specify a DS codepoint. The Rtype 542 object is carried in the Client Specific Information Object. 544 S-Num = 4 546 S-Type = 1 Diffserv Codepoint (DSCP) 548 0 1 2 3 549 +---------------+---------------+---------------+---------------+ 550 | Length | S-Num = 4 | S-Type = 1 | 551 +---------------+---------------+---------------+---------------+ 552 | ////////////////////////// | // | DSCP | 553 +---------------+---------------+---------------+---------------+ 555 More complex Diffserv edge-to-edge services can be listed defining 556 different "S-Type". 558 4.5. Traffic Descriptor Object (TD) 560 This object specifies the amount of the requested resources. 561 The TD object is carried in the Client Specific Information Object. 563 S-Num = 5 565 S-Type = 1 (Bandwidth) 567 0 1 2 3 568 +---------------+---------------+---------------+---------------+ 569 | Length | S-Num = 5 | S-Type = 1 | 570 +---------------+---------------+---------------+---------------+ 571 | Bandwidth (bytes/s) | 572 +---------------+---------------+---------------+---------------+ 574 This description can be used if there is not a more accurate indication 575 on the policing at the ingress interface. 577 S-Type = 2 (Token Size and Measurement Interval) 579 0 1 2 3 580 +---------------+---------------+---------------+---------------+ 581 | Length | S-Num = 5 | S-Type = 2 | 582 +---------------+---------------+---------------+---------------+ 583 | Token Size (bytes) | 584 +---------------+---------------+---------------+---------------+ 585 | Measurement Interval (msec) | 586 +---------------+---------------+---------------+---------------+ 588 Salsano Expires August 2000 12 589 This description can be used if there is an indication on the policing 590 at the ingress interface. This information could be used by the PDP/BB 591 in the admission control algorithm. 593 4.6. Reject Reason Object (RejRea) 595 The RejRea object is used to provide the reason for a negative Decision. 596 It is carried in the Decision Client SI Data object. 598 S-Num = 6, S-Type = 1 600 0 1 2 3 601 +---------------+---------------+---------------+---------------+ 602 | Length | S-Num = 6 | S-Type = 1 | 603 +---------------+---------------+---------------+---------------+ 604 | ////////////////////////// | Reason code | 605 +---------------+---------------+---------------+---------------+ 607 Reason codes are: 609 Reason code = 1 : Resource unavailable 610 Reason code = 2 : Unsupported resource type 611 Reason code = 3 : Unacceptable Ingress Point 612 Reason code = 4 : Unacceptable Egress Point 614 4.7. Synchronize State scope (SSscope) 616 The SSQscope object is used to specify the scope of a Synchronize State 617 operation. The SSQscope object is carried in the Client Specific 618 Information Object for the SSQ and SSC messages. 620 S-Num = 7, S-Type = 1 622 0 1 2 3 623 +---------------+---------------+---------------+---------------+ 624 | Length | S-Num = 7 | S-Type = 1 | 625 +---------------+---------------+---------------+---------------+ 626 | ////////////////////////// | Scope | 627 +---------------+---------------+---------------+---------------+ 629 Allowed value for Scope field are: 631 0 : Generic scope 632 1 : Specific scope 634 If the Scope is Generic, the Synchronize State operation refers to the 635 whole set of resource types and ingress-egress pairs. 636 If scope is Specific, the Synchronize State Request refers to the 637 specific resource type and ingress-egress pair contained in the rest of 638 the ClientSI Object for SSQ and SSR messages (see section 5). 640 Salsano Expires August 2000 13 641 5. COPS-ODRA Client-Specific data format 643 5.1. Context object 645 The context object specifies the type of request that triggered the 646 query. It is included in the REQ and in the DEC message. For COPS-ODRA 647 client the Request Type flag is always set to 0x02 (Resource-Allocation 648 request). The Message Type flag is used by the COPS-ODRA client to 649 distinguish between add, release and modify requests. Depending on the 650 M-Type, a different content of the ClientSI object for REQ message is 651 used. 653 C-num = 2, C-Type = 1 655 R-Type = 0x02 657 M-Type = 1 : Add 658 M-Type = 2 : Release 659 M-Type = 3 : Modify 661 5.2. Client Specific Information Object for REQ message. 663 The Client Specific Information Object carried in the REQ messages for 664 COPS-ODRA client contains the description of the resources and has a 665 different format depending on weather the type of the request is 666 Add/Release or Modify, as specified by the context object. 668 If the Context object specifies an Add or Release request, the ClientSI 669 object has the following format: 671 ::= 672 673 674 675 677 If the Context object specifies a Modify request, the previous values 678 for Resource Type and Traffic Description are appended at the end of 679 ClientSI object: 681 ::= 682 683 684 (new value) 685 (new value) 686 (old value) 687 (old value) 689 Salsano Expires August 2000 14 690 5.3. Decision Client Specific Info Data object. 692 The Decision ClientSI data object carries the information needed to 693 correlate the decision with the answer and some optional information to 694 explain negative Decisions. It has the following format: 696 ::= 697 699 5.4. Client Specific Information Object for SSQ and SSC messages. 701 The Client Specific Information Object carried in the SSQ messages for 702 COPS-ODRA client describes the scope of the requested (SSQ message) and 703 performed (SSC message) synchronize operation. This object has the 704 following format: 706 ::= 707 [] 708 [] 709 [] 711 If the "Specific scope" value is expressed in the SS scope object, then 712 the Resource Type, Ingress Point Address and Egress Point Address object 713 must be included. 715 5.5 Report Type Object 717 The Report Type is contained in the Report State message. Only failures 718 are communicated. 720 C-num = 12, C-Type = 1 722 Report-Type = 2 : Failure 724 5.6. Client Specific Information Object for Report State message. 726 The Client SI object for Report State message is used to communicate to 727 the PDP that a Request ID was not recognized. 729 ::= 731 6. Security Considerations 733 This document relies on COPS for its signaling and its security. Please 734 refer to section "Security Considerations" in [COPS]. 736 7. Illustrative examples for COPS-ODRA client 738 Salsano Expires August 2000 15 739 This section details two examples related to a successful and to an 740 unsuccessful reservation respectively. 742 In the following example the PEP requests the reservation of 1 Mb/s of 743 EF traffic between ingress point 192.168.1.1 and the egress point 744 192.168.129.1. 746 PEP --> PDP REQ := 747 748 756 The PDP accepts the reservation. 758 PDP --> PEP DEC := 759 760 761 765 In the following example the PEP requests the reservation of 2 Mb/s of 766 EF traffic between ingress point 192.168.1.1 and the egress point 767 192.168.129.1. Note that the same Handle is used, while the Request ID 768 is different. 770 PEP --> PDP REQ := 771 772 780 The PDP rejects the reservation. 782 PDP --> PEP DEC := 783 784 785 789 Salsano Expires August 2000 16 790 8. References 792 [2BIT] [2BIT] K. Nichols, V. Jacobson, L. Zhang " A Two-bit 793 Differentiated Services Architecture for the Internet "RFC 794 2638, July 1999 795 [BBop] First Internet2 bandwidth broker operability event 796 http://www.merit.edu/internet/working.groups/i2-qbone- 797 bb/inter-op/index.htm 798 [BBREQ] R. Neilson, J. Wheeler, F. Reichmeyer, S. Hares (Editors), "A 799 Discussion of Bandwidth Broker Requirements for Internet2 800 Qbone Deployment" Version 0.7 801 [COPS] D. Durham, Ed., J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. 802 Sastry "The COPS (Common Open Policy Service) Protocol", IETF 803 RFC 2748, January 2000 804 [COPS-RSVP] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, A. 805 Sastry, "COPS usage for RSVP ", IETF RFC 2749, January 2000 806 [COPS-PR]F. Reichmeyer, et al. "COPS Usage for Policy Provisioning", 807 draft-ietf-rap-pr-01.txt, October, 1999, Work in Progress. 808 [ICC99] A. Detti, M.Listanti, S.Salsano, L.Veltri, "Supporting RSVP in 809 a Differentiated Service Domain: an Architectural Framework 810 and a Scalability Analysis", ICC '99, June 1999, Vancouver, 811 Canada. 812 [INTDIF] Bernet, Y., Yavatkar R., Ford, P., Baker, F., Zhang, L., 813 Speer, M.,Braden, R., Wrocklaski, J., Felstaine, E., "A 814 Framework for Integrated Services Operation Over Diffserv 815 Networks", IETF , 816 September 1999, Work in Progress. 817 [IWQOS99]O. Schelen, A. Nilsson, J. Norrgard,S. Pink: Performance of 818 QoS Agents for Provisioning Network Resources. In Proceedings 819 of IFIP Seventh International Workshop on Quality of Service 820 (IWQoS'99), London, UK, June 1999. 822 [PIB] M. Fine, K. McCloghrie, S. Hahn, K. Chan, A. Smith, "An 823 Initial Quality of Service Policy Information Base for COPS-PR 824 Clients and Servers", draft-mfine-cops-pib-02.txt, October 825 1999. 826 [RAP] R. Yavatkar, D.Pendarakis, R.Guerin, "A Framework for Policy 827 Based Admission Control", IETF RFC 2753, January 2000. 828 [UCLA-BB]A. Terzis, J.Ogawa, S.Tsui, L.Wang, L.Zhang "A prototype 829 Implementation of the Two-Tier Architecture for Differentiated 830 Services" IEEE Workshop on QoS Support for Real-Time Internet 831 Applications, June 2-4, 1999 Vancouver, Canada 833 9. Author Information and Acknoledgements 835 Special thanks to Roberto Mameli, Andrea Ferraresi and Eleonora Manconi 836 for their comments and suggestions and their work on the prototype 837 implementation. 839 Stefano Salsano 841 Salsano Expires August 2000 17 842 CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni 843 Via di Tor Vergata, 135 844 00133 Roma - ITALY 845 email: salsano@coritel.it 847 Salsano Expires August 2000 18