idnits 2.17.1 draft-lefaucheur-rsvp-ecn-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 578. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 555. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 562. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 568. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC2119], [CL-DEPLOY]), 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 30 has weird spacing: '... and may be...' == Line 411 has weird spacing: '...te-Rate for t...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 1) The Egress Edge does NOT perform the RSVP-TTL vs IP TTL-check and does NOT update the ADspec Break bit. This is because the whole CL-region is effectively handled by RSVP as a virtual "link" on which Integrated Service is indeed supported (and admission control performed) so that the Break bit MUST not be set. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When receiving a PathErr message with the new Error Code of "CL-PCN Probes Required", the Ingress Edge MUST generate CL-PCN probes as described in [CL-DEPLOY] towards the Egress Edge which sent the PathErr Message, and MUST not propagate the PathErr message further upstream. -- 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 (June 2006) is 6515 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: 'RFC2119' is mentioned on line 54, but not defined == Missing Reference: 'INTSERV-DIFFERV' is mentioned on line 87, but not defined == Unused Reference: 'RFC2998' is defined on line 468, but no explicit reference was found in the text == Unused Reference: 'RFC2475' is defined on line 492, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-briscoe-tsvwg-cl-architecture-03 -- Possible downref: Normative reference to a draft: ref. 'CL-DEPLOY' ** Downref: Normative reference to an Informational RFC: RFC 2998 == Outdated reference: A later version (-03) exists of draft-briscoe-tsvwg-cl-phb-02 -- Possible downref: Normative reference to a draft: ref. 'PCN-MARKING' Summary: 6 errors (**), 0 flaws (~~), 13 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Francois Le Faucheur 2 Anna Charny 3 Cisco Systems, Inc. 5 Bob Briscoe 6 Phil Eardley 7 BT 9 Joe Barbiaz 10 Kwok-Ho Chan 11 Nortel 12 draft-lefaucheur-rsvp-ecn-01.txt 13 Expires: December 2006 June 2006 15 RSVP Extensions for Admission Control 16 over Diffserv using Pre-congestion Notification (PCN) 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that other 27 groups may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 This document specifies the extensions to RSVP for support of the 43 Controlled Load (CL) service over a Diffserv cloud using Pre- 44 Congestion Notification as defined in [CL-DEPLOY]. 46 Copyright Notice 47 Copyright (C) The Internet Society (2006) 49 Specification of Requirements 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in [RFC2119]. 55 1. Introduction 57 [RSVP] defines the Resource reSerVation Protocol which can be used by 58 applications to request resources from the network. The network 59 responds by explicitely admitting or rejecting these RSVP requests. 60 Certain applications that have quantifiable resource requirements 61 express these requirements using Intserv parameters as defined in the 62 appropriate Intserv service specifications ([RFC2212], [RFC2211]). 63 Controlled Load (CL) service is a quality of service (QoS) closely 64 approximating the QoS that the same flow would receive from a lightly 65 loaded network element [RFC2211]. CL is useful for inelastic flows 66 such as those for real-time media. 68 [CL-DEPLOY] describes a deployment model to achieve a Controlled Load 69 (CL) service ([RFC2211]) by using distributed measurement-based 70 admission control edge-to-edge, i.e. within a particular region of 71 the Internet. The measurement made is of CL packets that have their 72 Congestion Experienced (CE) codepoint set as they travel across the 73 edge-to-edge region. Setting the CE codepoint, which is under the 74 control of a new Pre-congestion Marking behaviour, provides an "early 75 warning" of potential congestion. This information is used by the 76 ingress node of the edge-to-edge region to decide whether to admit a 77 new CL microflow. 79 [CL-DEPLOY] also describes how the framework uses rate-based pre- 80 emption to maintain the CL service to as many admitted microflows as 81 possible even after localised failure and routing changes in the 82 interior of the edge-to-edge region. 84 The edge-to-edge architecture of [CL-DEPLOY] is a building block in 85 delivering an end-to-end CL service. The approach is similar to that 86 described in [INTSERV-DIFFERV] for Integrated services operation over 87 Diffserv networks. Like [INTSERV-DIFFERV], an IntServ class (CL in 88 our case) is achieved end-to-end, with a CL-region viewed as a single 89 reservation hop in the total end-to-end path. Interior nodes of the 90 CL-region do not process flow signalling nor do they hold state. 92 [CL-DEPLOY] assumes that the end-to-end signalling mechanism is RSVP. 93 This document specifies the extensions to RSVP for support of the 94 Controlled Load (CL) service over a Diffserv cloud using Pre- 95 Congestion Notification as defined in [CL-DEPLOY]. 97 2. Definitions 99 For readability, a number of definitions from [CL-DEPLOY] are 100 repeated here: 102 o ingress edge (or ingress gateway): router at an ingress to the CL- 103 region. A CL-region may have several ingress gateways. 105 o egress edge (or egress gateway): router at an egress from the CL- 106 region. A CL-region may have several egress gateways. 108 o Interior router: a router which is part of the CL-region, but is 109 not an ingress or egress gateway. 111 o CL-region: A region of the Internet in which all traffic 112 enters/leaves through an ingress/egress gateway and all routers 113 run Pre-Congestion Notification marking. A CL-region is a 114 DiffServ region (a DiffServ region is either a single DiffServ 115 domain or set of contiguous DiffServ domains), but note that the 116 CL-region does not use the traffic conditioning agreements (TCAs) 117 of the (informational) DiffServ architecture. 119 o CL-region-aggregate: all the microflows between a specific pair of 120 ingress and egress gateways. Note there is no field in the flow 121 packet headers that uniquely identifies the aggregate. 123 o Congestion-Level-Estimate: the number of bits in CL packets that 124 are admission marked (or pre-emption marked), divided by the 125 number of bits in all CL packets. It is calculated as an 126 exponentially weighted moving average. It is calculated by an 127 egress gateway for the CL packets from a particular ingress 128 gateway, i.e. there is a Congestion-Level-Estimate for each CL- 129 region-aggregate. 131 o Sustainable-Aggregate-Rate: the rate of traffic that the network 132 can actually support for a specific CL-region-aggregate. So it is 133 measured by an egress gateway for the CL packets from a particular 134 ingress gateway. 136 3. Overview of RSVP extensions and Operations 137 3.1. Overall QoS Architecture 139 The overall QoS architecture is described in [CL-DEPLOY]. For 140 readability, the Figure of [CL-DEPLOY] illustrating this QoS 141 architecture is reproduced below in Figure 1. 143 ---- ----- ----------------------------------------- ----- ----- 144 | | | | | | | | | | 145 | | | | |Ingress Interior Egress| | | | | 146 | | | | |gateway routers gateway| | | | | 147 | | | | |-------+ +-------+ +-------+ +------| | | | | 148 | | | | | PCN- | | PCN- | | PCN- | | | | | | | 149 | |..| |..|marking|..|marking|..|marking|..| Meter|..| |..| | 150 | | | | |-------+ +-------+ +-------+ +------| | | | | 151 | | | | | \ / | | | | | 152 | | | | | \ / | | | | | 153 | | | | | \ Congestion-Level-Estimate / | | | | | 154 | | | | | \ (for admission control) / | | | | | 155 | | | | | --<-----<----<----<-----<-- | | | | | 156 | | | | | Sustainable-Aggregate-Rate | | | | | 157 | | | | | (for flow pre-emption) | | | | | 158 | | | | | | | | | | 159 ---- ----- ----------------------------------------- ----- ----- 160 Sx Access CL-region Access Rx 161 End Network Network End 162 Host 163 Host 164 <------ edge-to-edge signalling -----> 165 (for admission control & flow pre-emption) 167 <-------------------end-to-end QoS signalling protocol--------------> 169 Figure 1: Overall QoS Architecture 171 3.2. Overview of Procedures for Admission Control of New Reservations 173 As mentioned earlier, [CL-DEPLOY] describes a framework to achieve a 174 Controlled Load (CL) service by using distributed measurement-based 175 admission control edge-to-edge, i.e. within a particular region of 176 the Internet. This section describes RSVP operations to support such 177 an admission control scheme relying on Pre-Congestion Notification in 178 the eddge-to-edge region. 180 When a new Path message is received by Ingress Edge, the Ingress Edge 181 does regular RSVP processing (including updating the RSVP PHOP) and 182 forwards the Path towards destination. 184 All the PCN-capable Interior nodes are not RSVP-capable (or have RSVP 185 processing disabled) and thus simply ignore the Path message. 187 When the Path message arrives at the Egress Edge, the Egress Edge 188 processes it as per regular RSVP processing, augmented with the 189 following rules: 191 1) The Egress Edge does NOT perform the RSVP-TTL vs IP TTL-check 192 and does NOT update the ADspec Break bit. This is because the 193 whole CL-region is effectively handled by RSVP as a virtual 194 "link" on which Integrated Service is indeed supported (and 195 admission control performed) so that the Break bit MUST not be 196 set. 198 2) The Egress Edge MAY check, at the time of initial Path 199 processing, whether it has a valid value for the corresponding 200 Congestion-Level-Estimate and if not it MAY send a PathErr 201 message to the Ingress Edge with a new "CL-PCN Probes 202 Required" Error Code. This minimizes call set up time as it 203 allows probes to be generated by the Ingress Edge and measured 204 by the Egress Edge while the Path is traveling towards the 205 receiver and while the Resv travels back from the receiver. 207 Then the Egress Edge forwards the Path message towards the receiver. 209 [Editor Note: discussion on Adspec update to be added] 211 When the Resv message is received by the Egress Edge (from the 212 downstream side), the Egress Edge performs regular RSVP processing 213 (including performing admission control for the segment downstream of 214 the Egress Edge) augmented with the procedures described in this 215 section. 217 The Egress Edge MUST include the new CL-PCN object in the Resv 218 message transmitted to the RSVP PHOP (which is the Ingress Edge). The 219 CL-PCN object MUST convey the current Pre-Congestion Notification 220 Congestion-Level-Estimate as measured by the Egress Edge from the 221 corresponding Ingress Edge to itself. Details for computing the 222 Congestion-Level-estimate can be found in [CL-DEPLOY] and [PCN- 223 MARKING]. 225 If the Egress Edge does not have a current value for the Congestion- 226 Level-estimate for the corresponding Ingress Edge (because there was 227 no traffic received by the Egress Edge from that Ingress Edge) and it 228 has not already requested the Ingress Edge to generate CL-PCN probes, 229 the Egress Edge: 231 1) triggers a timer and puts the Resv message processing on hold 232 2) sends a PathErr message towards the Ingress Edge with the new 233 Error Code of "CL-PCN Probes Required" specified in this 234 document, in order to instruct the Ingress Edge to generate 235 the necessary probe traffic to enable the Egress Edge to 236 compute the Congestion-Level-Estimate from that Ingress Edge 238 3) When timer expires the Resv processing resumes. Assuming the 239 Congestion-Level-Estimate is now available, the Egress Edge 240 can include it in the CL-PCN object and complete Resv 241 processing. If the Congestion-Level-Estimate is still 242 available, the Egress Edge may loop again a few times through 243 step 1) and 2). After a given number of times, the Egress Edge 244 MUST send a ResvErr towards the receiver with existing 245 ErrorCode "Admission Control Failure" 247 [Editor note: approach in previous paragraph may be revisited to try 248 avoid having to "put Resv message processing on hold".] 250 The Egress Edge will then forward the Resv message to the PHOP 251 signaled earlier in the Path message and which identifies the Ingress 252 Edge. Since the Resv message is directly addressed to the Ingress 253 Edge and does not carry the Router Alert option (as per regular RSVP 254 Resv procedures), the Resv message is hidden from the Interior nodes 255 which handle the E2E Resv message as a regular IP packet. 257 When receiving the Resv message, the Ingress Edge processes the Resv 258 message as per regular RSVP with the following exceptions: 260 1) if the CL-PCN object is absent from the Resv message, this 261 means that the RSVP Next Hop is not CL-PCN capable and hence 262 proper admission control can not be achieved for that 263 reservation over the PCN cloud. Thus, the Ingress Edge MUST 264 send a ResvErr message towards the receiver with an new Error 265 Code "Inconsistent Admission Control Behaviour across Ingress 266 and Egress Edge" and an Error Value of "Egress Edge Router not 267 CL-PCN capable". The Ingress Edge MAY also generate an alarm 268 to the network operator. 269 Note that in the case where the RSVP Next Hop is not CL-PCN 270 capable, this RSVP hop would have (most probably) performed 271 the RSVP-TTL vs IP-TTL check when processing the initial Path 272 message and as a result would have set the Break bit in the 273 Adspec (assuming there is at least one Interior node on the 274 path from the Ingress Edge to the RSVP Next Hop). Thus, the 275 sender would already have been notified in the first place 276 that the QoS could not be guaranteed end-to-end. 278 2) The Ingress Edge MUST carry out the admission control decision 279 (for admission of the reservation over the path from Ingress 280 Edge to Egress Edge through the PCN cloud) taking into account 281 the congestion information provided in the CL-PCN object of 282 the Resv message in accordance with the procedures of [CL- 283 DEPLOY] and [PCN-MARKING]. For example, if the Congestion 284 Level Estimate conveyed in the CL-PCN object exceeds a 285 configured threshold, the Ingress Edge may decide to reject 286 this new reservation. Once the admission control decision is 287 taken by the Ingress Edge, regular RSVP procedures are 288 followed to either proceed with the reservation (and forward 289 the Resv towards the sender) or tear down the reservation (and, 290 in particular, send a ResvErr towards the receiver with 291 existing Error Code "Admission Control failure". 293 3) In case the Ingress Edge forwards the Resv message upstream, 294 the Ingress Edge MUST remove the CL-PCN object 296 When generating a refresh for a Resv message towards the Ingress Edge, 297 the Egress Edge SHOULD NOT include the current value of the 298 Congestion-Level-Estimate in the CL-PCN object, but rather SHOULD 299 include the value which was included in the previous refresh. This is 300 for implementation reasons, to facilitate detection by the Ingress 301 Edge that this message is a mere refresh even if the value of the 302 actual Congestion-Level-Estimate has changed since the previous 303 refresh. 305 When receiving a PathErr message with the new Error Code of "CL-PCN 306 Probes Required", the Ingress Edge MUST generate CL-PCN probes as 307 described in [CL-DEPLOY] towards the Egress Edge which sent the 308 PathErr Message, and MUST not propagate the PathErr message further 309 upstream. 311 [Editor Note: discuss RSVP Authentication between ingress and egress 312 edges] 314 3.3. Removal of E2E reservations 316 E2E reservations are removed in the usual RSVP way via PathTear, 317 ResvTear, timeout, or as the result of an error condition. This does 318 not directly affect CL-PCN operations. 320 3.4. Overview of Procedures for Preemption of Existing Reservations 322 As mentioned earlier, [CL-DEPLOY] describes how rate-based pre- 323 emption can be used to maintain the CL service to as many admitted 324 microflows as possible, even after localised failure and routing 325 changes in the interior of the edge-to-edge region. The solution 326 involves the egress edge alerting the ingress edge of the CL-region- 327 aggregate that preemption may be needed and conveying to the ingress 328 edge the measured Sustainable-Aggregate-Rate. [CL-DEPLOY] also 329 identifies that this information needs to be transferred reliably. 330 This section describes the corresponding RSVP extensions. 332 Section 3.2.1 "Alerting the Ingress Edge that pre-emption may be 334 Let us assume that a number of reservations are established and 335 transit through a given Ingress Edge Ei and a given Egress Edge Ee. 336 Let us now assume that Ee is alerted that preemption may be needed 337 and that Ee has measured the Sustainable-Aggregate-Rate for the CL- 338 region-aggregate from Ei to Ee. 340 Then, Ee MUST arbitrarily select one of the reservations whose 341 Previous Hop is Ei and address to Ei a Resv message for that 342 reservation with a CL-PCN object containing the current Sustainable- 343 Aggregate-Rate for the relevant CL-region-aggregate. 345 To avoid the risk that this Resv message gets lost and in turn that 346 the Ingress Edge is not made aware in a timely manner that preemption 347 may be needed, the RSVP reliable messaging procedures specified in 348 [RSVP-REFRESH] SHOULD be used. 350 Note that, even when reliable messaging is used, there is a very 351 small risk that the alert that preemption may be needed does not make 352 it to the Ingress Edge. For example, this could happen because there 353 could be a race condition whereby the corresponding RSVP reservation 354 may get torn down around the same time where the Resv message with 355 the CL-PCN object is transmitted, resulting in the Ingress Edge 356 ignoring the whole Resv message. However, the probability for this to 357 occur is low and could also be mitigated by the Egress Edge sending 358 the alert on more than one reservation. 360 [Editor Note: optional use of a Notify message will be investigated. 361 Can this solve the race condition problem mentioned above?] 363 On receipt of the Resv message Ei will detect that this message is 364 not just a refresh because the content of the CL-PCN object has 365 changed and will immediately trigger its preemption logic. This will 366 assess whether some reservations need to be dropped in accordance 367 with the [CL-DEPLOY] and [PCN-MARKING] scheme. In case some do, those 368 will be torn down as per regular RSVP procedures (in particular a 369 ResvErr message is then sent to the receiver). 371 4. RSVP Object and Error Code Definition 373 This document defines a new object and two new error codes. 375 4.1. CL-PCN Object 377 o Class = To be allocated by IANA 378 C-Type = 1 380 0 7 8 15 16 25 26 31 381 +-------------+-------------+-------------+-------------+ 382 | Congestion-Level-Estimate | 383 +-------------+-------------+-------------+-------------+ 384 | Sustainable-Aggregate-Rate | 385 +-------------+-------------+-------------+-------------+ 387 The CL-PCN Object may only be used in Resv messages. 389 Let us refer: 390 - to the Egress Edge which generated the Resv message containing 391 the CL-PCN object as Ee 392 - to the RSVP Previous HOP (Ingres Edge) for the corresponding 393 reservation as Ei. 395 CL-PCN Congestion-Level-Estimate: 396 This contains the value of the Congestion-Level-Estimate (defined in 397 [CL-DEPLOY] and [PCN-MARKING]) computed by Ee for the CL-region- 398 aggregate from Ei to Ee. When generating a refresh for a Resv message 399 towards the Ingress Edge, the Egress Edge SHOULD NOT include the 400 current value of the Congestion-Level-Estimate in the CL-PCN object, 401 but rather SHOULD include the value which was included in the 402 previous refresh. 403 [Editor Note: Encoding details to be added] 405 Sustainable-Aggregate-Rate: 406 This contains: 407 - When Ee is not alerted that preemption is needed for the CL- 408 region-aggregate from Ei to Ee, this field is set to 0, 409 - When Ee is alerted that preemption is (or may be) needed for 410 the CL-region-aggregate from Ei to Ee, the Sustainable- 411 Aggregate-Rate for the relevant CL-region-aggregate (defined 412 in [CL-DEPLOY] and [PCN-MARKING]) computed by Ee for this CL- 413 region-aggregate. 414 [Editor Note: Encoding details to be added] 416 4.2. "CL-PCN Probes Required" Error Code 418 The "CL-PCN Probes Required" Error Code may appear only in PathErr 419 messages. 421 Error Code = To be allocated by IANA 423 4.3. "Inconsistent Admission Control Behaviour across Ingress and 424 Egress Edge" Error Code 426 The "Inconsistent Admission Control Behaviour across Ingress and 427 Egress Edge" may appear only in ResvErr messages. 428 [Editor note: should we allow it in PathErr messages too so that 429 notification can also be provided to the sender?] 431 Error Code for "Inconsistent Admission Control Behaviour across 432 Ingress and Egress Edge"= To be allocated by IANA 434 Error Value for "Egress Edge Router not CL-PCN capable"= To be 435 allocated by IANA 437 5. Security Considerations 439 To be added 441 6. IANA Considerations 443 This document makes the following requests to the IANA: 444 - allocate a new Object Class (CL-PCN Object) 445 - allocate a new Error Code ("CL-PCN Probes Required") and manage 446 the corresponding Error Value range 447 - allocate a new Error Code ("Inconsistent Admission Control 448 Behaviour across Ingress and Egress Edge"), manage the corresponding 449 Error Value range, and allocate the "Egress Edge Router not CL-PCN 450 capable" under that range. 452 7. Acknowledgments 454 We would like to thank Carol Iturralde for her input into this 455 document. 457 8. Normative References 459 [RSVP] Braden, R., ed., et al., "Resource ReSerVation Protocol 460 (RSVP)- Functional Specification", RFC 2205, September 1997. 462 [CL-DEPLOY] B. Briscoe, P. Eardley, D. Songhurst, F. Le Faucheur, A. 463 Charny, S. Dudley, J. Babiarz, K. Chan, G. Karagiannis, A. Bader., L 464 Westberg. "A Deployment Model for Admission Control over DiffServ 465 using Pre-Congestion Notification, draft-briscoe-tsvwg-cl- 466 architecture-03.txt", (work in progress), June 2006 468 [RFC2998] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., 469 Speer, M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A 470 Framework for Integrated Services Operation Over DiffServ Networks", 471 RFC 2998, November 2000. 473 [PCN-MARKING] B. Briscoe, P. Eardley, D. Songhurst, F. Le Faucheur, A. 474 Charny, S. Dudley, J. Babiarz, K. Chan, G. Karagiannis, A. Bader., L 475 Westberg. "Pre-Congestion Notification marking" 476 draft-briscoe-tsvwg-cl-phb-02.txt (work in progress), June 2006. 478 [RSVP-REFRESH] Burger et al, "RSVP Refresh Overhead Reduction 479 Extensions", RFC2961, April 2001 481 [RFC2211] J. Wroclawski, Specification of the Controlled-Load Network 482 Element Service, September 1997 484 [RFC2212] S. Shenker et al., Specification of Guaranteed Quality of 485 Service, September 1997 487 9. Informative References 489 [RFC2211] J. Wroclawski, Specification of the Controlled-Load Network 490 Element Service, September 1997 492 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and 493 W. Weiss, "A framework for Differentiated Services", RFC 2475, 494 December 1998. 496 10. Authors' Address 498 Francois Le Faucheur 499 Cisco Systems, Inc. 500 Village d'Entreprise Green Side - Batiment T3 501 400, Avenue de Roumanille 502 06410 Biot Sophia-Antipolis 503 France 504 Email: flefauch@cisco.com 506 Anna Charny 507 Cisco Systems 508 300 Apollo Drive 509 Chelmsford, MA 01824 510 USA 511 EMail: acharny@cisco.com 512 Bob Briscoe 513 BT Research 514 B54/77, Sirius House 515 Adastral Park 516 Martlesham Heath 517 Ipswich, Suffolk 518 IP5 3RE 519 United Kingdom 520 Email: bob.briscoe@bt.com 522 Philip Eardley 523 BT Research 524 B54/77, Sirius House 525 Adastral Park 526 Martlesham Heath 527 Ipswich, Suffolk 528 IP5 3RE 529 United Kingdom 530 Email: philip.eardley@bt.com 532 Kwok Ho Chan 533 Nortel Networks 534 600 Technology Park Drive 535 Billerica, MA 01821 536 USA 537 Email: khchan@nortel.com 539 Jozef Z. Babiarz 540 Nortel Networks 541 3500 Carling Avenue 542 Ottawa, Ont K2H 8E9 543 Canada 544 Email: babiarz@nortel.com 546 IPR Statements 548 The IETF takes no position regarding the validity or scope of any 549 Intellectual Property Rights or other rights that might be claimed to 550 pertain to the implementation or use of the technology described in 551 this document or the extent to which any license under such rights 552 might or might not be available; nor does it represent that it has 553 made any independent effort to identify any such rights. Information 554 on the procedures with respect to rights in RFC documents can be 555 found in BCP 78 and BCP 79. 557 Copies of IPR disclosures made to the IETF Secretariat and any 558 assurances of licenses to be made available, or the result of an 559 attempt made to obtain a general license or permission for the use of 560 such proprietary rights by implementers or users of this 561 specification can be obtained from the IETF on-line IPR repository at 562 http://www.ietf.org/ipr. 564 The IETF invites any interested party to bring to its attention any 565 copyrights, patents or patent applications, or other proprietary 566 rights that may cover technology that may be required to implement 567 this standard. 568 Please address the information to the IETF at ietf-ipr@ietf.org. 570 Disclaimer of Validity 572 This document and the information contained herein are provided on an 573 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 574 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 575 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 576 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 577 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 578 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 580 Copyright Notice 582 Copyright (C) The Internet Society (2006). This document is subject 583 to the rights, licenses and restrictions contained in BCP 78, and 584 except as set forth therein, the authors retain all their rights. 586 Appendix A - Example RSVP Signaling Flow for Admission Control 588 To be added. Shows RSVP message flow in case of admission control of 589 new reservations. 591 Appendix B - Example Signaling Flow for Preemption 593 To be added. Shows RSVP message flow in case of preemption of 594 existing reservations.