idnits 2.17.1 draft-mameli-issll-is-ds-cops-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]), 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 == Line 471 has weird spacing: '...all and compl...' -- 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: 'DSARCH' is mentioned on line 78, but not defined == Missing Reference: 'INTDIF' is mentioned on line 243, but not defined == Missing Reference: 'INTDIFF' is mentioned on line 177, but not defined ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. 'INTSERV') ** Downref: Normative reference to an Informational RFC: RFC 2638 (ref. '2BIT') -- Possible downref: Non-RFC (?) normative reference: ref. 'IWQOS99' -- Possible downref: Non-RFC (?) normative reference: ref. 'COPS-ODRA' -- Possible downref: Non-RFC (?) normative reference: ref. 'CCAPI' Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Roberto Mameli 2 Expiration: August 2000 Stefano Salsano 3 File: draft-mameli-issll-is-ds-cops-00.txt CoRiTeL 5 Integrated services over DiffServ network using COPS-ODRA 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 details the IntServ operation over a DiffServ network in 40 the case of dynamic admission control procedure supported by the COPS 41 protocol. An RSVP aware Edge Router uses the COPS protocol in order to 42 query a Bandwidth Broker, which manages the resources within the 43 DiffServ domain. This document relies on the COPS extensions proposed in 44 the companion draft "COPS usage for Outsourcing DiffServ Resource 45 Allocation" [COPS-ODRA]. 47 Mameli Expires August 2000 1 48 Table of Contents 50 Abstract........................................................1 51 Table of Contents...............................................2 52 1 Introduction.................................................2 53 2 IntServ over DiffServ: the role of the Edge Router...........3 54 3 RSVP/COPS interaction........................................5 55 4 Traffic control in the RSVP daemon...........................8 56 5 References...................................................9 57 6 Author Information and acknoledgements.......................10 59 Glossary 61 API Application Programming Interface 62 BB Bandwidth Broker 63 COPS Common Open Policy Service 64 ER Edge Router 65 LPDP Local Policy Decision Point 66 LLDAL Link Layer Dependent Adaptation Layer 67 ODRA Outsourcing Diffserv Resource Allocation 68 PDP Policy Decision Point 69 PEP Policy Enforcement Point 70 QoS Quality of Service 71 RSVP ReSerVation Protocol 72 SLS Service Level Specification 74 1. Introduction 76 The Integrated Service Architecture (IntServ _ see [INTSERV] and 77 [RFC2210]) and the Differentiated Service Architecture (DiffServ _ see 78 [2BIT] and [DSARCH]) have been proposed in the IETF to address the 79 support of QoS in IP networks. A combination of the two approaches is 80 proposed in [INTDIF], which provides a general framework while leaving 81 open several architectural issues. In particular three options for 82 resource management in the DiffServ network are listed: 1) statically 83 provisioned resources, 2) dynamically provisioned resources by means of 84 RSVP, 3) dynamically provisioned resources by other means (e.g., a form 85 of Bandwidth Broker). 87 In this draft we consider the third scenario where the Admission Control 88 in the DiffServ network is based on a Bandwidth Broker. The Edge Router 89 communication with the Bandwidth Broker is realized by means of an 90 extension to the COPS protocol described in the related proposed 91 document [COPS-ODRA]. The COPS is used to exchange resource allocation 92 requests/responses. The Edge Router contains the PEP _ Policy 93 Enforcement Point (client side of the COPS protocol), while the 95 Mameli Expires August 2000 2 96 Bandwidth Broker plays the role of the PDP _ Policy Decision Point 97 (server side of the COPS protocol). 99 The goal of this document is to define the scenario for the interworking 100 of RSVP and COPS protocols and to describe the interaction between them. 101 Note that in the Edge Router, the implementations of the RSVP and of the 102 COPS protocols can be seen as two different entities that need to 103 communicate. The detailed description of the related communication 104 mechanism is outside the scope of this document. A proposal for such 105 communication mechanism, based on an API library is described in a 106 companion draft [CCAPI]. 108 2. IntServ over DiffServ: the role of the Edge Router 110 This section briefly recall the main concepts behind the IntServ over 111 DiffServ operation as described in [INTDIF]; it focuses on the specific 112 scenario of dynamic admission control and analyzes in detail the role of 113 the Edge Router. The reference network configuration is depicted in 114 Figure 1. 116 ________ ________ _______ 117 / \ / \ / \ 118 / \ / \ / \ 119 +---+ | |---| |---| | +---+ 120 |Tx |-| |ER1| |ER2| |-| Rx| 121 +---+ | |-- | |---| | +---+ 122 \ / \ / \ / 123 \________/ \________/ \_______/ 125 IntServ Access Region DiffServ Core IntServ Access Region 127 Figure 1: Reference Network Configuration 129 As explained in [INTDIF], such a solution tries to conjugate benefits of 130 both the IntServ and the DiffServ approaches to QoS provisioning. In 131 fact, it achieves scalability due to the DiffServ aggregation in the 132 core, while keeping the advantages of end-to-end signaling. 134 The Edge Router (ER) plays a key role in this scenario. The ER is the 135 router placed at the boundary between the IntServ access network and the 136 DiffServ core. Differently from core routers, it is RSVP aware and 137 stores per-flow states; nevertheless, it is capable of managing packets 138 both on a micro-flow basis and on an aggregate basis. The choice between 139 the two possibilities depends on the role of the Edge Router. When it 140 acts as ingress ER, i.e. for packets from the originating IntServ 141 network to the DiffServ core it forwards packets in an aggregate fashion 142 on the outgoing interface, while it can handle micro-flows on the 143 incoming interface. Instead, when it behaves as egress ER, i.e. for 144 packets from the DiffServ core to the destination IntServ network, it is 146 Mameli Expires August 2000 3 147 able to distinguish micro-flows on the outgoing interface. Note, 148 however, that the distinction between ingress and egress edge router 149 depends only on the direction of the data stream. This means that the 150 same ER may be ingress ER for a flow and egress ER for another one in 151 the opposite direction. 153 As previously stated, the Edge Router is one of the main actors in the 154 situation depicted in Figure 1. This is especially true for the ingress 155 Edge Router, since it provides some important functionality. Among them 156 we cite: 158 - Classification: it performs per micro-flow classification, i.e. it is 159 able to distinguish the different Intserv flows. 160 - Mapping: it performs mapping of IntServ service classes into DiffServ 161 PHBs; it is also in charge of aggregating IntServ micro-flows 162 into DiffServ aggregates. 163 - Marking: it marks (or remarks) the DS field of incoming packets 164 according to the target PHB, that in turn results from the 165 mapping operation explained above. 166 - ADSPEC update: for GS flows the exported terms in the ADSPEC (i.e. C 167 and D) must be properly updated with a value depending upon the 168 topology and the characteristics of the DiffServ core. 169 - Admission Control: this is one of the main tasks performed by the 170 ingress Edge Router. The Admission Control is applied to the 171 virtual hop represented by the DiffServ core network. The 172 purpose of this procedure is to ensure that Diffserv resources 173 are available in the Diffserv domain to support the requested 174 Intserv flow. In a "pure" DiffServ network per flow Admission 175 Control is not needed, as simpler "aggregate" policing at 176 ingress points based on provisioning can be used. As explained 177 in [INTDIFF], the purpose of per-flow admission control is to 178 increase network utilization and/or to support tighter end-to- 179 end QoS guarantees (at the expense of increased complexity). 181 Let us focus on the Admission Control functionality performed by the 182 Edge Router at the ingress boundary of the DiffServ cloud. There are 183 basically two distinct approaches to this task: 185 - Distributed: in this case Admission Control is based on information 186 locally available in the ingress Edge Router. 187 - Centralized: differently from the previous choice, Admission Control 188 is realized by means of a Bandwidth Broker (BB), i.e. 189 logically centralized entity acting as an Admission Control 190 server. The BB could use global knowledge of both the 191 network topology and the resource allocation (see Figure 2) 192 to take Admission control decisions. The definition of 193 mechanisms and algorithms used for the BB operation is 194 outside the scope of this document and will not be further 195 detailed here. Related work can be found in [IWQOS99]. 197 Mameli Expires August 2000 4 198 +------+ 199 +----| BB |----+ 200 | +------+ | 201 ________ | ________ | ________ 202 / \ | / \ | / \ 203 / \ | / \ | / \ 204 +---+ | |---| |---| | +---+ 205 |Tx |-| |ER1| |ER2| |-| Rx| 206 +---+ | |-- | |---| | +---+ 207 \ / \ / \ / 208 \________/ \________/ \________/ 210 IntServ Access Region DiffServ Core IntServ Access Region 212 Figure 2: Centralized Bandwidth Broker 214 The distributed solution is quite simple to implement, but it is also 215 rather inaccurate, since each ER exploits information with a local 216 scope, without the overall vision of the network status. In contrast, 217 the second approach raises some non-trivial issues in terms of 218 complexity and scalability, but allows better resource utilization 219 within the DiffServ cloud. 221 In this document the centralized solution of Figure 2 is analyzed. A 222 protocol for the communication between the ER and the centralized server 223 is needed. The use of the COPS [COPS] is considered here. The COPS 224 protocol can be extended to support new Client types. The extensions 225 proposed in [COPS-ODRA] are suited to support the Intserv operation on 226 Diffserv network. 228 Note that the scenario depicted in Figure 2 refers to a single DiffServ 229 core domain (intra-domain case). In a multi-domain scenario, one could 230 simply use of RSVP as end-to-end signaling (raising scalability 231 concerns) or more complex communication mechanisms between BBs of 232 different domains could be defined. These inter-domain aspects are 233 outside the scope of this document. 235 3. RSVP/COPS interaction 237 From now on the architecture represented in Figure 2 will be assumed as 238 the reference scenario. As previously explained, the Edge Router 239 comprises most of the functionality needed for interworking, including 240 admission control on a micro-flow basis. Obviously, for proper 241 operation, RSVP and COPS signaling should properly interact. To clarify 242 this mechanism let us consider the sequence of operations involved in an 243 end-to-end reservation, that is described in detail in [INTDIF] and 244 reported here in a simplified form. We are considering unicast 245 reservations: 247 Mameli Expires August 2000 5 248 - The sender application on Tx generates an RSVP PATH message 249 carrying the flow's characteristics (i.e. the Tspec). The message 250 is carried towards the receiver Rx; in the IntServ access regions 251 it is subject to standard RSVP/IntServ processing, while in the 252 DiffServ core it is forwarded transparently. 254 - When the receiving host Rx receives the PATH it generates the 255 corresponding RSVP RESV message, that is carried back towards the 256 sending host. As before, the RESV message undergoes standard 257 RSVP/IntServ processing in the IntServ access regions and is simply 258 ignored in the DiffServ core. During his travel backwards, assuming 259 that it not rejected before for resource unavailability, it reaches 260 the ingress Edge Router ER1. 262 - In ER1, the RESV message triggers a query to the Bandwidth Broker. 263 The latter, based on the information carried in the RESV message 264 and on its view on the utilization of network resources, decides to 265 admit or reject the request. The total amount of available 266 resources is determined by Diffserv provisioning mechanisms. 268 - If ER1 approves the request, the RESV message is admitted and is 269 allowed to continue upstream towards the sender. If it rejects the 270 request, the RESV is not forwarded and the appropriate RSVP error 271 messages are sent. 273 As described in the list above, queries from the ingress ER to the BB 274 are triggered whenever the former receives a RESV message from the 275 downstream DiffServ domain. Note that in this situation RSVP and COPS 276 are synchronized. A possible choice in the implementation of RSVP/COPS 277 interaction would be to keep this synchronization. This would imply a 278 blocking behavior; whenever the RSVP daemon triggers a query it blocks 279 indefinitely waiting for a response. This raises the obvious problem of 280 managing situations in which a response from the PDP/BB is not 281 temporarily available. In fact, in such cases, the blocking behavior 282 should be avoided, in order to be able to manage other events and to 283 avoid soft state expirations. 285 As a consequence the RSVP should be properly adapted in order to manage 286 requests and responses asynchronously. After a query and before getting 287 the response, processing of other events should be possible. A possible 288 way to realize this behavior could be the introduction of pending 289 reservation states in the RSVP daemon. Consider as an example the 290 reception of a RESV message by the ingress Edge Router ER1, that in turn 291 triggers an admission control query towards the PDP/BB. In this case the 292 RSVP daemon could set up a reservation state before retrieving the 293 response, marking it as pending. No further operations related to this 294 state should be performed until it remains pending, i.e. until the 295 response from the PDP/BB is available; this means, for example, that the 296 RESV message should not be forwarded upstream. In the case of positive 297 response (i.e. reservation request accepted), the corresponding 298 reservation should be instantiated on the egress interface of ER1, and 299 the RESV message should be forwarded upstream. In the case of rejection, 301 Mameli Expires August 2000 6 302 e.g. due to unavailability of resources, a blockade state should be set 303 up in ER1 and a RESVERR message should be propagated downstream towards 304 Rx, according to standard RSVP behavior. The introduction of pending 305 reservation states could allow the RSVP daemon to perform normal 306 processing related to states other than the one considered. This 307 obviously includes refresh operations triggered by timeout expirations. 308 Note that a timeout could also be defined for pending states. In this 309 case, when the timeout of a pending reservation state expires, and no 310 response has been received in the meanwhile, the RSVP could either 311 reject the request or revert to local decision based on LPDP 312 functionality in the ER. 314 Figure 4 and Figure 5 show the typical sequence of operations involved 315 in a reservation, both in the case of acceptance and in the case of 316 rejection. As stated above, the interface between the PEP in the ER and 317 the PDP/BB is realized by means of the COPS protocol extension described 318 in [COPS-ODRA], while the interface between the RSVP daemon and the PEP 319 within the ER is described in a companion draft [CCAPI]. 321 +---------+ 322 +----------------| PDP/BB |----------------+ 323 | +---------+ | 324 +---------+ +---------+ 325 | ER1 | | ER2 | 326 +---------+ +---------+ 327 RSVP PEP PDP/BB RSVP 329 | | RSVP RESV MESSAGE | 330 |<-------+---------------+------------------| 331 | | | | 332 |request | | | 333 |message | COPS-ODRA | | 334 + |------->| REQ MESSAGE | | 335 | | |-------------->| | 336 pending | | Add | | 337 reserv. | | | | 338 state | | COPS-ODRA | | 339 | |dispatch| DEC MESSAGE | | 340 + |message |<--------------| | 341 + |<-------| Install | | 342 normal | OK | | | 343 reservation| | | | 344 state | | | | 345 | | | | | 346 ... ... ... ... ... 348 Figure 3: Reservation successfully accepted 350 Mameli Expires August 2000 7 351 +---------+ 352 +----------------| PDP/BB |----------------+ 353 | +---------+ | 354 +---------+ +---------+ 355 | ER1 | | ER2 | 356 +---------+ +---------+ 357 RSVP PEP PDP/BB RSVP 359 | | RSVP RESV MESSAGE | 360 |<-------+---------------+------------------| 361 |request | | | 362 |message | COPS-ODRA | | 363 + |------->| REQ MESSAGE | | 364 | | |-------------->| | 365 pending | | Add | | 366 reserv. | | | | 367 state | | COPS-ODRA | | 368 | |dispatch| DEC MESSAGE | | 369 + |message |<--------------| | 370 + |<-------| Remove | | 371 | | NO | RSVP RESVERR MESSAGE | 372 blockade |--------+---------------+----------------->| 373 state | | | | 374 | ... ... ... ... 376 Figure 4: Reservation rejected 378 Finally, Figure 5 shows the sequence of events involved in the release 379 of resources. When a RESV TEAR is received a COPS-ODRA REQ message is 380 sent to the PDP/BB, in order to let it keep track of resource usage. 381 After the reception of the corresponding DEC message the PEP notifies 382 the RSVP, which in turn releases the reservation and forward upstream 383 the RESV TEAR. Note however that the same sequence of operations happens 384 in the case of PATH TEAR or in the case of timeout expiration. 386 Mameli Expires August 2000 8 387 +---------+ 388 +----------------| PDP/BB |----------------+ 389 | +---------+ | 390 +---------+ +---------+ 391 | ER1 | | ER2 | 392 +---------+ +---------+ 393 RSVP PEP PDP/BB RSVP 395 | | RSVP RESV TEAR MESSAGE | 396 |<-------+---------------+------------------| 397 |request | | | 398 |message | COPS-ODRA | | 399 + |------->| REQ MESSAGE | | 400 | | |-------------->| | 401 | | | Release | | 402 reserv. | | | | 403 state | | COPS-ODRA | | 404 | |dispatch| DEC MESSAGE | | 405 | |message |<--------------| | 406 + |<-------| Install | | 407 <---------| OK | | | 408 RESV TEAR| | | | 409 MESSAGE... ... ... ... 411 Figure 5: Resource release 413 4. Traffic control in the RSVP daemon 415 The previous paragraph explains how RSVP and COPS can interact within 416 the same Edge Router. Obviously the need for interaction between them 417 requires some modifications in the normal operations performed by RSVP. 418 An example of this is represented by the introduction of pending 419 reservation states (see the previous paragraph). Another modification 420 deals with the interface between RSVP and Traffic Control, described in 421 [RFC2205]. As explained there, it may be desirable to organize an RSVP 422 implementation into two parts: a core that performs link-layer 423 independent processing, and a link-layer dependent adaptation layer 424 (LLDAL). A suitable interface between these layers is specified in 425 [RFC2205] (see Figure 6): 427 Mameli Expires August 2000 9 428 +--------------------+ 429 | Link Layer | 430 | Independent | 431 | Core | 432 +--------------------+ RSVP/Traffic Control 433 ------------------------------------- 434 +--------------------+ Interface 435 | Link Layer | 436 | Dependent | 437 | Adaptation Layer | 438 | (LLDAL) | 439 +--------------------+ 441 Figure 6: Organization of an RSVP implementation 443 The realization of the scenarios depicted in Figure 1 and in Figure 2 444 requires some minor changes to this interface. In fact, let us focus on 445 the TC_AddFlowspec() call: 447 Rhandle = TC_AddFlowspec( Interface, TC_Flowspec, TC_Tspec, 448 TC_Adspec, Police_Flags ) 450 In a pure RSVP/IntServ scenario, whenever the upper layer executes a 451 TC_AddFlowspec() call, the LLDAL performs Admission Control and, in case 452 of success, it sets up the reservation (i.e. it adds the proper traffic 453 control objects, such as schedulers and classifiers, on the interface 454 involved in the reservation). This makes sense, since in this case 455 Admission Control is based on the local availability of resources, whose 456 usage is likely to be known at the Link Layer dependent level. 458 The situation is slightly different when dealing with the interoperation 459 between IntServ and DiffServ. In fact, in this case Admission Control 460 requires the knowledge of the resource usage of the whole DiffServ 461 domain, and such an information is obviously outside the local scope of 462 the LLDAL. The entity that is aware of the whole domain is the Bandwidth 463 Broker, and this implies that it must be involved in the decision, i.e. 464 it must be queried by the RSVP. There are obviously two possible choices 465 to perform this operation. The first one is to keep the Admission 466 Control functionality at the LLDAL level, making it responsible of 467 interfacing with the COPS-ODRA PEP; the second one is to move this 468 functionality at the upper layer, thus realizing RSVP/COPS 469 intercommunication in the Link Layer Independent Core. The first choice 470 is preferable, since it leaves unchanged the semantic of the original 471 TC_AddFlowspec() call and complies with the philosophy behind the 472 scenario of Figure 2. In fact, from the RSVP viewpoint the DiffServ core 473 network can be seen as a single virtual trunk, i.e. a sort of virtual 474 link layer. 476 Note however that a new piece of information is required for Admission 477 Control in the situation depicted above. In fact, since the availability 478 of resources concerns a network, and not a single link, it should also 479 take into account some topological information, i.e. typically the IP 481 Mameli Expires August 2000 10 482 addresses of the ingress and egress Edge Routers. The former is known, 483 because it coincides with the IP address of the ingress router involved 484 in the operation. The latter, instead, should be retrieved from the RESV 485 message and passed through the interface of Figure 5 for proper 486 Admission Control. This would imply a change of the TC_AddFlowspec() 487 call, that would become: 489 Rhandle = TC_AddFlowspec( Interface, TC_Flowspec, TC_Tspec, 490 TC_Adspec, Police_Flags, Egress_Point ) 492 where Egress_Point contains the IP address of the egress Edge Router. 494 Figure 7 summarizes the considerations explained in this paragraph. It 495 depicts the situation in the Edge Router ER, where the RSVP daemon and 496 the COPS-ODRA Client run as independent and concurrent processes. As 497 mentioned before the communication between them is realized by an API, 498 described in a companion document [CCAPI], that is used to support 499 communication at the LLDAL level. 501 +-----------------------------------------------------------+ 502 | Edge Router (ER) | 503 | +------------------------------------+ | 504 | | +--------------------+ RSVP | +-----------+ | 505 | | | Link Layer | | | | | 506 | | | Independent | | | | | 507 | | | Core | Modified | | | | 508 | | +--------------------+ RSVP/TC | | COPS-ODRA | | 509 | | ---------------------------------- | | Client | | 510 | | +--------------------+ Interface| | (PEP) | | 511 | | | Link Layer | | | | | 512 | | | Dependent |__________|__| | | 513 | | | Adaptation Layer | CCAPI | | | | 514 | | | (LLDAL) | | | | | 515 | | +--------------------+ | +-----------+ | 516 | +------------------------------------+ | 517 | | 518 +-----------------------------------------------------------+ 520 Figure 7: RSVP/COPS interaction in the Edge Router 522 5. References 524 [INTSERV] R. Braden, D. Clark, S. Shenker, "Integrated Services in 525 the Internet Architecture: an Overview", IETF RFC 1633, June 526 1994 527 [RFC2210] J. Wroclawski, "The Use of RSVP with Integrated 528 Services", IETF RFC 2210, September 1997 530 Mameli Expires August 2000 11 531 [RFC2205] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, 532 "Resource ReSerVation Protocol (RSVP) - Version 1 Functional 533 Specification ", IETF RFC 2205, September 1997 534 [2BIT] K. Nichols, V. Jacobson, L. Zhang "A Two-bit Differentiated 535 Services Architecture for the Internet", IETF RFC 2638, July 536 1999 537 [DSARCH]S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, 538 "An Architecture for Differentiated Services", IETF RFC 2475, 539 December 1998 540 [INTDIF]Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, M. Speer, 541 R. Braden, J. Wrocklaski, E. Felstaine, "A Framework for 542 Integrated Services Operation Over DiffServ Networks", IETF 543 , September 1999, Work 544 in Progress 545 [IWQOS99] O. Schelen, A. Nilsson, J. Norrgard, S. Pink, 546 "Performance of QoS Agents for Provisioning Network Resources", 547 Proceedings of IFIP Seventh Internation Workshop on QoS 548 (IWQoS'99), London, UK, June 1999 549 [COPS] D. Durham, Ed., J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. 550 Sastry "The COPS (Common Open Policy Service) Protocol", IETF 551 RFC 2748, January 2000 552 [COPS-ODRA] S. Salsano, "COPS Usage for Outsourcing Diffserv 553 Resource Allocation", , 554 February 2000, Work in Progress 555 [CCAPI] R. Mameli, "The CCAPI (COPS Client Application Programming 556 Interface", , February 557 2000, Work in Progress 559 6. Author Information and acknoledgements 561 Special thanks to Andrea Ferraresi and Eleonora Manconi for their 562 comments and suggestions and their work on the prototype implementation. 564 Stefano Salsano 565 CoRiTeL consortium 566 Via di Tor Vergata 135 567 00133 _ Roma (Italy) 569 Phone: +39 06 20410029 570 EMail: salsano@coritel.it 572 Roberto Mameli 573 CoRiTeL consortium 574 Via di Tor Vergata 135 575 00133 _ Roma (Italy) 577 Phone: +39 06 20410038 578 EMail: mameli@coritel.it 580 Mameli Expires August 2000 12