idnits 2.17.1 draft-mameli-issll-cops-api-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 11 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([COPS-ODRA], [COPS-ISDS]), 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 8827 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) -- Looks like a reference, but probably isn't: '2' on line 455 -- Looks like a reference, but probably isn't: '0' on line 500 -- Looks like a reference, but probably isn't: '1' on line 501 == Unused Reference: 'RFC2205' is defined on line 540, but no explicit reference was found in the text == Unused Reference: 'IWQOS99' is defined on line 556, but no explicit reference was found in the text == Unused Reference: 'COPS' is defined on line 560, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. 'INTSERV') ** Downref: Normative reference to an Informational RFC: RFC 2638 (ref. '2BIT') ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. 'DSARCH') -- Possible downref: Non-RFC (?) normative reference: ref. 'INTDIF' -- Possible downref: Non-RFC (?) normative reference: ref. 'IWQOS99' -- Possible downref: Non-RFC (?) normative reference: ref. 'COPS-ODRA' -- Possible downref: Non-RFC (?) normative reference: ref. 'COPS-ISDS' Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Roberto Mameli 3 Expiration: August 2000 CoRiTeL 4 File: draft-mameli-issll-cops-api-00.txt 6 The CCAPI (COPS Client Application Programming Interface) 8 February 22, 2000 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Distribution of this memo is unlimited. 34 Copyright Notice 36 Copyright (C) The Internet Society (2000). All Rights Reserved. 38 Abstract 40 This document focuses on the Admission Control functionality performed 41 by the Edge Router in the IntServ/DiffServ interworking scenario 42 described in [COPS-ISDS]. More precisely it describes the interaction 43 between the RSVP and the COPS protocols in the Edge Router and 45 Mameli Expires August 2000 1 46 introduces an API (Application Programming Interface) aimed at allowing 47 the intercommunication between them. Anyway, the API described here is 48 designed as a flexible interface, and should be able to support 49 communication between a generic application and the COPS Client Type 50 described in [COPS-ODRA]. 52 Table of Contents 54 Abstract........................................................1 55 Table of Contents...............................................2 56 Glossary........................................................2 57 1. Introduction ................................................2 58 2. CCAPI generalities ..........................................3 59 3. CCAPI Description ...........................................5 60 4. Upcall mechanism ............................................8 61 5. Definition of CCAPI objects .................................10 62 6. References ..................................................11 63 7. Author Information and Acknowledgements .....................12 65 Glossary 67 API Application Programming Interface 68 BB Bandwidth Broker 69 CCAPI COPS Client Application Programming Interface 70 COPS Common Open Policy Service 71 DSCP Differentiated Services Code Point 72 ER Edge Router 73 IPC Inter Process Communication 74 PDP Policy Decision Point. 75 PEP Policy Enforcement Point. 76 QoS Quality of Service 77 RSVP ReSerVation Protocol 78 SLS Service Level Specification 80 1. Introduction 82 One of the possible scenarios for end-to-end QoS provisioning relies on 83 a proper combination of both the Integrated Services (IntServ) 84 ([INTSERV] and [RFC2210]) and the Differentiated Services (DiffServ) 85 ([2BIT] and [DSARCH]) architectures. The description of such a model is 86 beyond the scope of this document; a detailed explanation can be found 87 in [INTDIF] and in [COPS-ISDS]. However it is worth observing that the 88 router placed at the boundary between the IntServ stub domain and the 90 Mameli Expires August 2000 2 91 DiffServ core, i.e. the Edge Router (ER), provides several interworking 92 functionality (described in details in the references above). 94 One of the most important functionality managed by the ER is related to 95 admission control. The original DiffServ architecture provides a sort of 96 implicit admission control, in the form of SLS negotiated between 97 neighboring domains. The introduction of end-to-end signaling by means 98 of the RSVP protocol allows explicit admission control on micro-flow 99 basis, as explained in details in [INTDIF]. 101 Note, however, that the are at least two ways to perform Admission 102 Control in the Edge Router. In fact, it can be realized either in a 103 distributed way by means of information locally available, or in a 104 centralized way by querying an Admission Control Server. As stated in 105 [COPS-ISDS], the first approach is easier to implement, but it is 106 nevertheless characterized by inaccuracy, since each ER does not have an 107 overall knowledge of the network resource utilization. Moreover, in some 108 situations (failures, etc.), consistency among information stored in 109 different ERs could not be assured. For this reason [COPS-ISDS] focuses 110 on the second solution. However, in such a scenario the communication 111 between the ER and the centralized server must happen according to a 112 proper protocol. COPS represents a possible choice, since it is a simple 113 and extensible protocol; [COPS-ODRA] proposes an extension suited at the 114 purpose. 116 Besides the COPS extension, needed for the communication between the 117 centralized server and the Edge Router, another communication interface 118 should be defined. In fact, the Edge Router supports both the COPS-ODRA 119 PEP and the RSVP daemon. As explained in [COPS-ISDS], the entire 120 mechanism requires proper interaction between them; for example the 121 reception of a RSVP RESV message by the ingress ER should trigger an 122 admission control query towards the server (PDP/BB). This observation 123 leads to the definition of a new interface between the COPS-ODRA client 124 and the RSVP daemon within the Edge Router. 126 This document describes an API that can be used at the purpose. This 127 API, called CCAPI (COPS Client API), is based on a client library 128 statically linked with the RSVP daemon. The latter can trigger queries 129 to the PDP/BB server when needed and can receive responses from it 130 either synchronously or asynchronously, as explained in the following 131 paragraph. Note, however, that the CCAPI is designed in a flexible way, 132 in order to be usable with applications other than RSVP, that could need 133 to interact with the COPS-ODRA PEP for whatever reason. For this reason 134 in the remaining part of the document we will use the term _CCAPI 135 client_ to refer to such an application, thus avoiding to mention 136 explicitly RSVP, even if it obviously represents the natural choice. 138 2. CCAPI generalities 140 Mameli Expires August 2000 3 141 As stated above, the CCAPI is realized by means of a client library 142 statically linked with the CCAPI client. The procedures implemented in 143 the CCAPI library use a proper inter-process communication (IPC) 144 mechanism to interact with the COPS client, which in turn relies on the 145 COPS protocol to communicate with the server. The situation is depicted 146 in the following figure: 148 +---------------------------------------------+ 149 | Edge +----------+ +----------+ | +----------+ 150 | Device | CCAPI | |COPS-ODRA |_______________|COPS-ODRA | 151 | | Client | | Client | | COPS | Server | 152 | +----------+ +----------+ | +----------+ 153 | User Level || || | 154 |=================||=============||===========| 155 | Kernel Level |---------------| IPC | 156 | ----------------- Mechanism | 157 +---------------------------------------------+ 159 Note that there is no need to standardize the inter-process 160 communication mechanism, since it could vary due to several reasons, 161 such as Operating System characteristics. The CCAPI proposed here does 162 not assume anything about it, even if the actual implementation relies 163 on the Linux socket mechanism. The definition of the interface specifies 164 only the visible part of it, i.e. the set of routines made available to 165 the CCAPI client. They are listed and explained in the following. 167 The API can be used to manage events both in a synchronous and in an 168 asynchronous way. In the first case the CCAPI client triggers a query to 169 the PDP/BB and blocks indefinitely waiting for a response. This is the 170 easiest way to use the CCAPI, but it could lead to undesirable behavior 171 in the case of no response from the server. Let us consider as an 172 example the case of an admission control request from RSVP; if the 173 server does not respond for whatever reason, the daemon would wait 174 indefinitely. This is obviously undesirable, since normal processing of 175 other requests should not be blocked by a pending request (e.g. timeout 176 of installed PATH and RESV states would expire, and so on). 178 For this reason the CCAPI has been designed to manage events 179 asynchronously, by means of an _upcall_ or _callback_ mechanism. In this 180 way the CCAPI client triggers the request from the PEP to the PDP/BB 181 without waiting for response. When a response from the PDP/BB is 182 available, the PEP notifies the CCAPI client (e.g. the RSVP daemon) 183 that, in turn, manages it by calling a proper callback routine. 185 A synchronous error in a CCAPI library routine returns an appropriate 186 error code. Asynchronous errors are delivered to the application via the 187 CCAPI upcall routine. Text messages for synchronous and asynchronous 188 error codes can be found in the file cops_err.h. 190 Mameli Expires August 2000 4 191 3. CCAPI Description 193 This paragraph reports a brief description of the sequence of operations 194 needed by the CCAPI client and lists all the CCAPI calls along with 195 their explanation. 197 3.1. CCAPI Outline 199 The CCAPI client must include cops_api.h and cops_err.h and must be 200 linked with cops_api.c. It begins by opening the session to the COPS- 201 ODRA PEP via the cops_api_open_session() call; when it issues this call 202 it can optionally specify a pointer to an appropriate callback routine 203 (if any). The session associates the CCAPI Client with the PEP, meaning 204 that the latter cannot have more sessions opened at the same time. If 205 this is the need, several PEP processes should be instantiated together 206 on the same Edge Router, and each of them should have a single session 207 opened towards the CCAPI client. 209 After the cops_api_open_session() call, the CCAPI client can ask for 210 resource request, release and/or modify by means of the 211 bandwidth_request(), bandwidth_release() and bandwidth_modify() calls, 212 with proper parameters. In order to get a response the 213 cops_api_dispatch() call can be used. In the _blocking_ case, the 214 cops_api_dispatch() can be preceded by a select() system call, in order 215 to wait indefinitely for an event; when such an event occurs, the select 216 is unblocked and the cops_api_dispatch() can be used to obtain the 217 response. No callback routine is needed in this case. In contrast, in 218 the _non blocking_ case, a proper callback routine is specified in the 219 cops_api_open_session(). The cops_api_dispatch() is periodically called 220 inside the CCAPI client main loop, and it polls the PEP to see if a 221 response has arrived; if so, the callback routine is executed. The 222 latter receives also an optional argument that can be specified when 223 opening the session through the cops_api_open_session() call. 225 Whatever the mechanism we choose, _blocking_ or _non blocking_, at the 226 end of all the operations the session can be closed via the 227 cops_api_release_session() call. In the following a brief description of 228 all the CCAPI calls is reported. 230 3.2. CCAPI calls 232 3.2.1. cops_api_open_session() 234 The cops_api_open_session() call is used to open a session with the 235 COPS-ODRA PEP. It returns a cops_api_error (i.e. an unsigned int), which 236 could be any of the following values: 238 COPS_API_OK - session opened without problems 240 Mameli Expires August 2000 5 241 COPS_API_NOCOPS _ COPS-ODRA PEP is not running on the ER 242 COPS_API_OPEN - session already opened 244 The definition of the function is the following: 246 cops_api_error 247 cops_api_open_session ( cops_event_rtn event_rtn, 248 void *event_rtn_arg) 250 The parameters are: 252 event_rtn - is a pointer to the callback function specified 253 by the CCAPI client. It could be NULL if the latter 254 is not interested in managing asynchronous events 255 by the upcall mechanism. 256 event_rtn_arg - is a pointer to an optional parameter that is 257 passed to the callback routine whenever it is 258 called. 260 3.2.2. cops_api_getfd() 262 It may be used by the CCAPI client to retrieve a file descriptor; this, 263 in turn, could be used in a select() call immediately before the 264 dispatch(), so as to realize a blocking mechanism. The function is 265 specified as follows: 267 int 268 cops_api_getfd() 270 It doesn't require parameters and returns the file descriptor, or _1 if 271 the session has not been opened before. 273 3.2.3. cops_api_release_session() 275 The cops_api_release_session() is used to close the session with the 276 COPS-ODRA PEP. It returns a cops_api_error of the following types: 278 COPS_API_OK - session closed without problems 279 COPS_API_CLOSE - session already closed 280 COPS_API_SYSERR _ system error 282 The function prototype is: 284 cops_api_error 285 cops_api_release_session () 287 No parameters are requested. 289 3.2.4. bandwidth_request() 291 Mameli Expires August 2000 6 292 The bandwidth_request() library call is used by the CCAPI client in 293 order to instruct the PEP to query the PDP/BB for bandwidth request; 294 referring to RSVP as an example, this could happen whenever a new flow 295 is admitted at the ingress Edge Router. The function prototype is the 296 following: 298 cops_api_error 299 bandwidth_request ( cops_req *request) 301 It takes in input a pointer to a cops_req structure, that contains 302 information about the request. The definition of the cops_req structure 303 is reported in paragraph 5. Note that it also contains a request 304 identifier, that is used in the _non-blocking_ case to associate 305 requests made by the CCAPI client to responses provided by the PEP. In 306 fact, in such a case, the CCAPI client can issue several requests to the 307 PEP, and a way to relate them to corresponding responses is obviously 308 needed. The library call can return one of the following values: 310 COPS_API_OK - request successfully delivered to the PEP 311 COPS_API_INVREQ _ invalid request; session not in place 312 COPS_API_INVRID _ invalid request identifier (already in use) 313 COPS_API_TOOMF - excessive number of pending requests 314 COPS_API_SYSERR _ system error 316 3.2.5. bandwidth_release() 318 This is the complementary function to the previous one. The CCAPI client 319 uses it in order to instruct the PEP to communicate bandwidth release to 320 the PDP/BB. If the CCAPI client is represented by RSVP, 321 bandwidth_release() is called when a reservation is released, e.g. upon 322 the reception of a RESV TEAR message by the ingress Edge Router. 324 cops_api_error 325 bandwidth_release ( cops_req *request) 327 The parameters and the return values of this function are the same of 328 the bandwidth_request(). 330 3.2.6. bandwidth_modify() 332 The bandwidth_modify() call has been introduced with reference to the 333 situation where the CCAPI client is represented by RSVP. It can be used 334 to change dynamically a reservation without first releasing resources 335 and then allocating them again. In this way there are two advantages: 336 first of all the reservation is changed with a single message. Moreover, 337 in the case of rejection of the new request, the old one remains in 338 place. The function is defined as follows: 340 cops_api_error 341 bandwidth_modify ( cops_req *request) 343 Mameli Expires August 2000 7 344 The parameter is a pointer to a cops_req structure; differently from the 345 case of bandwidth_request() and bandwidth_release() this request now 346 contains a pair of bandwidth values, instead of a single one. The return 347 values are the same of bandwidth_request(). 349 3.2.7. cops_api_dispatch() 351 Applications use the cops_api_dispatch() library call to receive 352 notifications of COPS events, e.g. responses to their queries. The 353 function prototype is the following: 355 cops_api_error 356 cops_api_dispatch ( cops_resp *response) 358 The cops_api_dispatch() polls the PEP for a response and retrieves it 359 for the CCAPI client. The parameter is a pointer to a cops_resp 360 structure; if not NULL, it is eventually filled with the response. If 361 the latter is not available the object referenced by this parameter is 362 left unchanged. Moreover the callback function specified in the 363 cops_api_open_session() (if any) is called. An explanation of the upcall 364 mechanism can be found in paragraph 4. Note however that the 365 cops_api_dispatch() is a non blocking call; if a response is not 366 available, it immediately returns control to the calling function. 367 Possible return values of cops_api_dispatch() are: 369 COPS_API_OK - dispatch successfully executed 370 COPS_API_NOCOPS - COPS-ODRA PEP is not running on the ER 371 COPS_API_INVREQ _ invalid request; session not in place 372 COPS_API_SYSERR _ system error 374 3.2.8. cops_api_version() 376 The cops_api_version() call returns the version number of the CCAPI in 377 the form major*100+minor. Current version is 1.00. 379 4. Upcall mechanism 381 An upcall is invoked by cops_api_dispatch(), which executes the 382 procedure specified by the event_rtn parameter of the 383 cops_api_open_session() call (if specified). 385 The upcall function has the following synopsis: 387 int 388 ccapi_callback ( cops_resp *response, 389 void *arg) 391 Mameli Expires August 2000 8 392 It receives from cops_api_dispatch() the response just arrived and the 393 user specified parameter (represented by the event_rtn_arg parameter in 394 the cops_api_open_session() call). Based on these parameters it executes 395 an application specified routine. There are basically two types of 396 events that can trigger an upcall: 398 - DECISION EVENT: this event notifies the CCAPI client about a 399 response from the PDP/BB, which could be either 400 positive (i.e. request accepted) or negative 401 (i.e. the request was rejected for some reason, 402 e.g. bandwidth unavailability or unsupported 403 service). 404 - ERROR EVENT: it is used to signal error events directly 405 recognized by the PEP, e.g. invalid request or 406 excessive number or pending requests. 408 The type of event is contained in the response that is passed to the 409 ccapi_callback() (see paragraph 5). It also contains a code that 410 specifies the particular reason for that event. Possible codes for both 411 DECISION EVENTS and ERROR EVENTS are contained in tables 1 and 2 below: 413 +-------------+---------------------------------------------+ 414 | Code | Reason that triggered the event | 415 +-------------+---------------------------------------------+ 416 | COPS_OK | Request accepted | 417 | COPS_NOBW | Unavailable resources | 418 | COPS_NODSCP | Unsupported service | 419 | COPS_NOIED | Invalid Ingress Edge Device Address | 420 | COPS_NOEED | Invalid Egress Edge Device Address | 421 +-------------+---------------------------------------------+ 423 Table 1: Codes for DECISION EVENTS (PDP/BB responses) 425 +-----------------+------------------------------------------+ 426 | Code | Reason that triggered the event | 427 +-----------------+------------------------------------------+ 428 | COPS_API_OK | Operation successfully completed | 429 | COPS_API_INVRID | Invalid Request Identifier | 430 | COPS_API_INVREQ | Invalid Request or Session not in place | 431 | COPS_API_NOCOPS | COPS Client (PEP) not running on the ER | 432 | COPS_API_OPEN | Session already opened | 433 | COPS_API_CLOSE | Session already closed | 434 | COPS_API_TOOMF | Excessive number of requests | 435 | COPS_API_SYSERR | System Error | 436 +-----------------+------------------------------------------+ 438 Table 2: Codes for ERROR EVENTS 440 Mameli Expires August 2000 9 441 5. Definition of CCAPI objects 443 This appendix defines the main CCAPI objects, reported below along with 444 a brief explanation. 446 - cops_req object 448 typedef struct Cops_Req 449 { 450 unsigned int request_ID; 451 unsigned int request_type; 452 struct in_addr IED_addr,EED_addr; 453 unsigned int dscp[2]; 454 unsigned int msr_interval[2]; 455 unsigned int token_size[2]; 456 } cops_req; 458 This object is used by the CCAPI Client to specify information 459 that the PEP will insert in the COPS REQ message when querying 460 the PDP/BB. The fields have the following meaning: 462 - request_ID: request identifier. Each pair request/response 463 is characterized by a unique request 464 identifier, which is used to correlate the 465 response with the corresponding request. The 466 same request_ID cannot be contemporarily used 467 for issuing different requests, otherwise 468 COPS_API_INVRID is returned. 469 - request_type: type of request. The following list reports 470 the possible values for this parameter. Each 471 of these values must be used when the 472 corresponding library routine on the right is 473 called: 475 BW_REQUEST _ bandwidth_request() 476 BW_RELEASE _ bandwidth_release() 477 BW_MODIFY _ bandwidth_modify() 478 CCAPI_CLOSE _ cops_api_release_session() 480 - IED_addr: IP address of the ingress Edge Device 481 - EED_addr: IP address of the egress Edge Device 482 - dscp[]: two-element vector. In the case of 483 bandwidth_request() and bandwidth_release() 484 calls, the first element contains the DSCP of 485 the requested service, while the second is 486 unspecified. In the case of bandwidth_modify() 487 the two elements contains respectively the old 488 and the new value for the DSCP. 489 - token_size[], msr_interval[]: a pair of two element vectors. 490 The corresponding bandwidth is given by the 491 ratio: 492 token_size[n]/msr_interval[n] n=0,1 493 In the case of bandwidth_request() and 495 Mameli Expires August 2000 10 496 bandwidth_release() only the first two 497 elements are meaningful; they contains the 498 bandwidth to be requested/released. In the 499 case of bandwidth_modify() the values 500 token_size[0]/msr_interval[0] and 501 token_size[1]/msr_interval[1] contains 502 respectively the old and the new value for the 503 bandwidth. 505 - cops_resp object 507 typedef struct Cops_Resp { 508 unsigned int request_ID; 509 cops_event_type resp_type; 510 cops_error resp_errcode; 511 } cops_resp; 513 This object contains the responses received by the CCAPI Client. 514 The fields have the following meaning: 516 - request_ID: is the same value contained in the request. It 517 is returned by the PEP to the CCAPI Client in 518 order to associate the response to the 519 corresponding request. 520 -resp_type: specifies the type of response. Two types are 521 currently supported: 523 DECISION_EVENT 524 ERROR_EVENT 526 The difference is explained in the previous 527 paragraph. 528 -resp_errcode: depending on resp_type, it gives detailed 529 information about the event that triggered the 530 response. Possible values are reported in table 531 1 and table 2. 533 6. References 535 [INTSERV] R. Braden, D. Clark, S. Shenker, "Integrated Services in 536 the Internet Architecture: an Overview", IETF RFC 1633, 537 June 1994 538 [RFC2210] J. Wroclawski, "The Use of RSVP with Integrated Services", 539 IETF RFC 2210, September 1997 540 [RFC2205] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, 541 "Resource ReSerVation Protocol (RSVP) - Version 1 542 Functional Specification ", IETF RFC 2205, September 1997 544 Mameli Expires August 2000 11 545 [2BIT] K. Nichols, V. Jacobson, L. Zhang "A Two-bit Differentiated 546 Services Architecture for the Internet", IETF RFC 2638, 547 July 1999 548 [DSARCH] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. 549 Weiss, "An Architecture for Differentiated Services", IETF 550 RFC 2475, December 1998 551 [INTDIF] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, M. 552 Speer, R. Braden, J. Wrocklaski, E. Felstaine, "A 553 Framework for Integrated Services Operation Over DiffServ 554 Networks", IETF , 555 September 1999, Work in Progress 556 [IWQOS99] O. Schelen, A. Nilsson, J. Norrgard, S. Pink, "Performance 557 of QoS Agents for Provisioning Network Resources", 558 Proceedings of IFIP Seventh Internation Workshop on QoS 559 (IWQoS'99), London, UK, June 1999 560 [COPS] D. Durham, Ed., J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. 561 Sastry "The COPS (Common Open Policy Service) Protocol", 562 IETF RFC 2748, January 2000 563 [COPS-ODRA] S. Salsano, "COPS Usage for Outsourcing Diffserv Resource 564 Allocation", , 565 February 2000, Work in Progress 566 [COPS-ISDS] S. Salsano, R. Mameli, "Integrated services over DiffServ 567 network using COPS-ODRA", , February 2000, Work in Progress 570 7. Author Information and Acknowledgements 572 The author would like to thank Stefano Salsano, Eleonora Manconi and 573 Luca Dell'Uomo for their support and their contribution in the prototype 574 implementation. 576 Roberto Mameli 577 CoRiTeL consortium 578 Via di Tor Vergata 135 579 00133 _ Roma (Italy) 581 Phone: +39 06 20410038 582 EMail: mameli@coritel.it 584 Mameli Expires August 2000 12