idnits 2.17.1 draft-arumaithurai-nsis-pcn-00.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 702. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 709. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 715. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 18 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (September 4, 2007) is 6078 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) == Unused Reference: 'I-D.lefaucheur-rsvp-ecn' is defined on line 648, but no explicit reference was found in the text == Unused Reference: 'RFC2212' is defined on line 666, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'I-D.briscoe-tsvwg-cl-phb' == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-14 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. 'I-D.ietf-nsis-ntlp') == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-15 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-qos-nslp (ref. 'I-D.ietf-nsis-qos-nslp') == Outdated reference: A later version (-24) exists of draft-ietf-nsis-qspec-17 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-qspec (ref. 'I-D.ietf-nsis-qspec') == Outdated reference: A later version (-11) exists of draft-ietf-pcn-architecture-00 ** Downref: Normative reference to an Informational draft: draft-ietf-pcn-architecture (ref. 'I-D.ietf-pcn-architecture') -- Possible downref: Normative reference to a draft: ref. 'I-D.lefaucheur-rsvp-ecn' Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Next Steps in Signaling (nsis) M. Arumaithurai 3 Internet-Draft University of Goettingen 4 Intended status: Standards Track September 4, 2007 5 Expires: March 7, 2008 7 NSIS PCN-QoSM: A Quality of Service Model for Pre-Congestion 8 Notification (PCN) 9 draft-arumaithurai-nsis-pcn-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 7, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes a Quality of Service model (QOSM), for 43 networks that support the use of the Controlled load service over a 44 Diffserv cloud using pre-congestion notification. Ths is a technique 45 to perform admission control in a Diffserv network by measuring the 46 congestion level in a domain. New flows are admitted only if the 47 current congestion level is below the allowed threshold. When the 48 controlled load in a domain exceeds a certain threshold, the egress 49 prompts the ingress to pre-empt certain flows. This proposal is 50 based on the proposal made by B.Briscoe et al., for the extension of 51 RSVP to support the Controlled load service over a Diffserv cloud 52 using pre-congestion notification. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 58 3. Overview of the Extensions and Operations . . . . . . . . . . 5 59 3.1. Overall QoS Architecture . . . . . . . . . . . . . . . . . 5 60 3.2. Overview of Procedures for Admission Control of New 61 Reservations . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.2.1. PCN-QOSM/QoS-NSLP Upstream Signaling . . . . . . . . . 6 63 3.2.2. PCN-QOSM/QoS-NSLP Downstream Signaling . . . . . . . . 8 64 3.2.3. REFRESH Messages . . . . . . . . . . . . . . . . . . . 10 65 3.2.4. ERROR Messages . . . . . . . . . . . . . . . . . . . . 10 66 3.2.5. NOTIFY Messages . . . . . . . . . . . . . . . . . . . 11 67 3.3. Removal of E2E Reservations . . . . . . . . . . . . . . . 11 68 3.4. Overview of Procedures for Preemption of Existing 69 Reservations . . . . . . . . . . . . . . . . . . . . . . . 11 70 3.4.1. Receiver Initiated QoS Reservation . . . . . . . . . . 12 71 4. PCN-CL-QSPEC Parameter . . . . . . . . . . . . . . . . . . . . 13 72 5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 5.1. CL-PCN-Probes-Required-Error-Code . . . . . . . . . . . . 15 74 5.2. CL-PCN-Inconsistent-Admission-Control-Behaviour-Error-Code 15 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 80 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 Intellectual Property and Copyright Statements . . . . . . . . . . 18 84 1. Introduction 86 GIST [I-D.ietf-nsis-ntlp] is a signalling protocol that can be used 87 by applications to set up state in routers in a given network. GIST, 88 a successor to RSVP [RFC2205] can be used to signal NAT / FW etc in 89 addition to QoS signalling. The Quality of Service NSIS Signalling 90 Layer Protocol (QoS-NSLP), as defined in [I-D.ietf-nsis-qos-nslp], is 91 a generic QoS signalling protocol for carrying Quality of Service 92 (QoS) information between arbitrary nodes in the network and runs on 93 top of the GIST layer. It could be used in various QoS models such 94 as Intserv, Diffserv, RMD etc. 96 This document describes a 'Next Steps in Signalling (NSIS) QoS model' 97 henceforth known as NSIS-PCN-QoSM for networks. These networks use a 98 controlled load service over a Diffserv cloud using pre-congestion 99 notification as described in CL-PCN [I-D.ietf-pcn-architecture]. It 100 also elaborates on the corresponding QSPEC [I-D.ietf-nsis-qspec] 101 parameters and error codes for expressing reservations in a suitable 102 form that can be easily interpreted and processed by the relevant 103 nodes. 105 CL-PCN [I-D.ietf-pcn-architecture] outlines a deployment mode to 106 achieve a Controlled Load (CL) service [RFC2211] by using distributed 107 measurement based admission control edge to edge, which is within a 108 particular region of the Internet. The measurement is made via CL 109 packets that have their Congestion Experienced (CE) codepoint set as 110 they travel across the edge-to-edge region. Setting the CE 111 codepoint, which is under the control of a new pre-congestion marking 112 behaviour, provides an "early warning" of potential congestion. This 113 information is passed on to the ingress node by the egress, thereby 114 instructing the former to decide whether to admit a new CL microflow. 115 CL-PCN [I-D.ietf-pcn-architecture] also describes how the framework 116 uses rate-based pre-emption to maintain the CL service to as many 117 admitted microflows as possible even after localised failure and 118 routing changes in the interior of the edge-to-edge region. 120 The edge-to-edge architecture of CL-PCN [I-D.ietf-pcn-architecture] 121 is a building block in delivering an end-to-end CL service. This 122 approach is similar to implementing an Intserv operation over 123 Diffserv networks, wherein a CL region is viewed as a single hop in 124 acheiving an end-to-end reservation. Interior nodes in a CL region 125 do not hold states or process signalling flows. 127 2. Terminology and Abbreviations 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 For readability, a number of definitions from CL-PCN 134 [I-D.ietf-pcn-architecture], and NSIS terminology as defined in QoS- 135 NSLP [I-D.ietf-nsis-qos-nslp], NSIS-QSPEC [I-D.ietf-nsis-qspec] are 136 repeated here for easy readability: 138 Ingress Edge (or Ingress Gateway, or Ingress Node): 140 A router at an ingress to the CL-region. A CL-region may have 141 several ingress gateways. 143 Egress Edge (or Egress Gateway, or Egress Node): 145 A router at an egress from the CL-region. A CL-region may have 146 several egress gateways. 148 Interior router: 150 A router that is part of the CL-region, but is not an ingress or 151 egress gateway. 153 CL-region: 155 A region of the Internet in which all traffic enters/leaves 156 through an ingress/egress gateway and all routers run Pre- 157 Congestion Notification marking. A CL-region is a DiffServ region 158 (a DiffServ region is either a single DiffServ domain or set of 159 contiguous DiffServ domains), but note that the CL-region does not 160 use the traffic conditioning agreements (TCAs) of the 161 (informational) DiffServ architecture. 163 CL-region-aggregate: 165 All the microflows between a specific pair of ingress and egress 166 gateways. Note there is no field in the flow packet headers that 167 uniquely identifies the aggregate. 169 Congestion-Level-Estimate: 171 The number of bits in CL packets that are admission marked (or 172 pre-emption marked), divided by the number of bits in all CL 173 packets. It is calculated as an exponentially weighted moving 174 average. It is calculated by an egress gateway for the CL packets 175 from a particular ingress gateway, i.e., there is a Congestion- 176 Level-Estimate for each CL- region-aggregate. 178 Sustainable-Aggregate-Rate: 180 The rate of traffic that the network can actually support for a 181 specific CL-region-aggregate. So it is measured by an egress 182 gateway for the CL packets from a particular ingress gateway. 184 QNE: 186 An NSIS Entity (NE), which supports the QoS NSLP. 188 QNI: 190 The first node in the sequence of QNEs that issues a reservation 191 request for a session. 193 QNR: 195 The last node in the sequence of QNEs that receives a reservation 196 request for a session. 198 3. Overview of the Extensions and Operations 200 3.1. Overall QoS Architecture 202 The overall QoS architecture is described in CL-PCN 203 [I-D.ietf-pcn-architecture] and is reproduced below in Figure 1 for 204 readability and modified to incorporate NSIS terminology. 206 ----- ----- ----------------------------------------- ----- ----- 207 | | | | |Ingress Egress| | | | | 208 | | | | |gateway Interior gateway| | | | | 209 | | | | | (QNE) routers (QNE) | | | | | 210 | | | | |-------+ +-------+ +-------+ +------| | | | | 211 | | | | | PCN- | | PCN- | | PCN- | | | | | | | 212 | |..| |...|marking|..|marking|..|marking|..| Meter|..| |...| | 213 | | | | |-------+ +-------+ +-------+ +------| | | | | 214 | | | | | \ / | | | | | 215 | | | | | \ / | | | | | 216 | | | | | \ Congestion-Level-Estimate / | | | | | 217 | | | | | \ (for admission control) / | | | | | 218 | | | | | --<-----<----<----<-----<-- | | | | | 219 | | | | | Sustainable-Aggregate-Rate | | | | | 220 | | | | | (for flow pre-emption) | | | | | 221 | | | | | | | | | | 222 ---- ----- ----------------------------------------- ----- ----- 223 Sx Access CL-region Access Rx 224 End Network Network End 225 Host (QNI) (QNR) Host 227 <------ edge-to-edge signalling -----> 228 (for admission control & flow pre-emption) 230 <---------- end-to-end QoS signalling protocol --------> 232 Figure 1: Overall QoS Architecture 234 3.2. Overview of Procedures for Admission Control of New Reservations 236 As mentioned earlier, CL-PCN [I-D.ietf-pcn-architecture] describes a 237 framework to achieve a Controlled Load (CL) service by using 238 distributed measurement-based admission control edge-to-edge, i.e., 239 within a particular region of the Internet. This section keys out 240 NSIS operations to support such an admission control scheme relying 241 on Pre-Congestion Notification in the edge-to-edge region. 243 3.2.1. PCN-QOSM/QoS-NSLP Upstream Signaling 245 The basic PCN-QOSM/QoS-NSLP signaling is shown in Figure 2. When a 246 new request for QoS arrives at the QNI from an End-Host, the QNI 247 perdorms regular QoS-NSLP processing by establishing a hop by hop 248 connection with other QoS-NSLP aware nodes along the path to the 249 destination. It creates a RESERVE message with an initiator QSPEC 250 parameter describing the reservation and then forwards it. 252 When this end-to-end RESERVE message reaches an Ingress node, it 253 performs the following operation: 255 o The ingress node continues the hop-by-hop QoS-RESERVE message by 256 sending it to the next QoS-NSLP aware node. The PCN-capable 257 Interior nodes in the CL region are not QoS-NSLP-capable (or have 258 Qos/NSLP processing disabled) and thus simply ignore the RESERVE 259 message. Therefore, the Egress Edge becomes the next hop of the 260 Ingress node. 262 The Egress node on receiving the RESERVE message does the 263 following(not necessarily in the order mentioned below): 265 o If the Egress node does not have a valid value for Congestion- 266 Level-Estimate for the aggregate flow of traffic for this Ingress- 267 Egress pair, it sends an asynchronous NOTIFY message back to the 268 Ingress with a INFO-SPEC (as described in Section 5.2.3 of QSPEC 269 [I-D.ietf-nsis-qspec]), which has the "CL-PCN-Probes-Required- 270 error-code" error code. The error code mentioned is defined this 271 document in Section 5.1. Note that the probe packets that are 272 sent by the Ingress SHOULD be in accordance with the CL-PCN 273 [I-D.ietf-pcn-architecture] requirements. 275 o The Egress node sends the original RESERVE message with the End- 276 to-End(E2E) QSPEC to the next hop in the upstream direction, i.e., 277 towards the destination. 279 |<--CL-PCN-Domain-->| 280 | | 281 QNE QNE 282 QNE INGRESS EGRESS QNE 283 | | | | 284 | | | | 285 | | | | 286 |RESERVE (E2E-QSPEC) | | | 287 +---------------------->| | | 288 | | | | 289 | |RESERVE (E2E-QSPEC)| | 290 | +------------------>| | 291 | | |RESERVE (E2E-QSPEC) | 292 | | +-------------------->| 293 | | | | 294 | | NOTIFY(INFO-SPEC= | | 295 | CL-PCN-PROBES-Req-Err-Code)| | 296 | |<------------------+ | 297 | | | | 298 | |...probe packets..>| | 299 | | | | 300 | | | | 301 | |...probe packets..>| | 302 | | | | 303 . 304 . 305 . 306 . 307 < Waits for the RESPONSE message to come in the downstream direction > 308 . 309 . 311 Figure 2: PCN-QOSM Upstream Signalling 313 3.2.2. PCN-QOSM/QoS-NSLP Downstream Signaling 315 Figure 3 shows the RESPONSE message received in the Downstream 316 direction. When the RESPONSE message is received by the Egress Edge 317 (from the downstream side), the latter performs regular QoS-NSLP 318 processing (including performing admission control for the segment 319 downstream of the Egress Edge) augmented with the procedures 320 described in this section: 322 o If the Egress node has a valid Congestion-Level-Estimate value, it 323 forwards the RESPONSE message to the ingress node with the PCN-CL- 324 QSPEC parameter (as described in Section 4) having the Congestion- 325 Level-Estimate value and the E2E-QSPEC parameter already present 326 in the received RESPONSE message. Details for computing the 327 Congestion-Level-estimate can be found in CL-PCN 328 [I-D.ietf-pcn-architecture] and PCN-MARKING 329 [I-D.briscoe-tsvwg-cl-phb]. 331 o If the Egress node does not have a current Congestion-Level- 332 Estimate value(because there was no traffic received by the Egress 333 Edge from that Ingress Edge), it does the following: 335 * Triggers a timer(Tx) and puts the RESPONSE message on hold. 337 * If it is still receiving probe packets from ingress, it does 338 the Congestion-Level-Estimate after receiving the probe 339 packets. 341 * If it isn't receiving probe packets(Due to some error 342 situation), it sends a NOTIFY message with the INFO-SPEC set to 343 the new Error Code of "CL-PCN-Probes-Required" specified in 344 this document in Section 5.1. 346 * When the timer Tx expires, if it has a valid Congestion-Level- 347 Estimate, it sends the RESPONSE message with the PCN-CL-QSPEC 348 and the E2E-QSPEC. If the Congestion-Level-estimate value is 349 still not available, it may loop a few times through the 350 previous steps, and if the situation continues it must send a 351 RESPONSE with an error code. 353 The Ingress node on receiving a NOTIFY message processes it as per 354 regular QoS-NSLP signalling with the following exceptions: 356 o If it received an INFO-SPEC parameter with the Error Code of "CL- 357 PCN-Probes-Required-error-code" specified in this document, it 358 starts sending probe packets to the Egress node. 360 The Ingress node on receiving a RESPONSE message processes it as per 361 regular QoS-NSLP signalling with the following exceptions: 363 o If it received the PCN-CL-QSPEC parameter with a valid Congestion- 364 Level-Estimate, it performs admission control and sends a RESPONSE 365 message upstream indicating the success or failure of the 366 reservation attempt. It must carry out the admission control 367 decision (for admission of the reservation over the path from 368 Ingress Edge to Egress Edge through the PCN cloud) taking into 369 account the congestion information provided in the PCN-CL-QSPEC 370 parameter of the RESPONSE message in accordance with the 371 procedures of PCN-CL-QSPEC and PCN-MARKING 372 [I-D.briscoe-tsvwg-cl-phb]. For example, if the Congestion level 373 Estimate conveyed in the PCN-CL-QSPEC parameter exceeds a 374 configured threshold, the Ingress Edge may decide to reject this 375 new reservation. Once the admission control decision is taken by 376 the Ingress Edge, regular NSIS procedures are followed to either 377 proceed with the reservation (and forward the RESPONSE towards the 378 sender) or tear down the reservation (and, in particular, send a 379 error RESPONSE with the appropriate error code. 381 o In case the Ingress Edge forwards the RESPONSE message upstream, 382 the Ingress Edge MUST remove the PCN-CL-QSPEC parameter. 384 . 385 . 386 < Once the RESERVE reaches the QNR, the 387 RESPONSE begins in the downstream direction> 388 . 389 . 390 . 391 (QNE) (QNE-Ingress) (QNE-Egress) (QNE) 392 | | | | 393 | | | RESPONSE(E2E-QSPEC)| 394 | | |<---------------------| 395 | |RESPONSE(E2E-QSPEC,| | 396 | |(PCN-CL-QSPEC) | | 397 | |<------------------| | 398 | RESPONSE(E2E-QSPEC)| | | 399 |<----------------------| | | 400 | | | | 402 Figure 3: PCN-QoSM Downstream signalling 404 3.2.3. REFRESH Messages 406 Since the set up states in the routers are in soft state, refreshing 407 is done by sending RESERVE messages in the REFRESH mode. The Egress 408 can respond to this RESERVE by sending a NOTIFY message with a new 409 value of Congestion-level-estimate to keep the ingress informed. 411 3.2.4. ERROR Messages 413 On receiving a NOTIFY message with the INFO-SPEC having the "CL-PCN- 414 Probes-Required-error-code" error code flag set, the Ingress Edge 415 MUST generate probe packets, as described in CL-PCN 417 [I-D.ietf-pcn-architecture], towards the Egress Edge which sent the 418 NOTIFY Message with the Error Code. The Ingress Node must not send 419 this NOTIFY message further upstream. 421 3.2.5. NOTIFY Messages 423 NOTIFY messages are asynchronous messages specified in QoS-NSLP 424 [I-D.ietf-nsis-qos-nslp]. They can be send upstream and downstream, 425 by the ingress to the Egress and viceverca, with the PCN-CL-QSPEC 426 parameter or the INFO-SPEC Error Codes to notify one another, when 427 required. The NOTIFY message is mainly used by the egress to notify 428 the ingress of pre-emption of flows. A detailed explanation is given 429 in Section 3.4. It is the responsibility of the QoS-NSLP to take 430 care of the sure delivery of the NOTIFY message. 432 3.3. Removal of E2E Reservations 434 E2E reservations are removed in the usual QoS-NSLP way via sending 435 the RESERVE message with the Tear flag set or when a timeout occurs, 436 since fresh REFRESH messages were not sent or as the result of an 437 error condition. This does not directly affect CL-PCN 438 [I-D.ietf-pcn-architecture] operations. 440 3.4. Overview of Procedures for Preemption of Existing Reservations 442 As mentioned earlier, CL-PCN [I-D.ietf-pcn-architecture] describes 443 how rate-based pre-emption can be used to maintain the CL service to 444 as many admitted microflows as possible, even after localised failure 445 and routing changes in the interior of the edge-to-edge region. This 446 requires the egress to check on the CL-region aggregate and alerting 447 the ingress of any abnormality by sending it the measured 448 Sustainable-Aggregate-Rate. Based on this information, the ingress 449 edge node might decide to pre-empt certain admitted flows to maintain 450 the CL of the admitted flows. CL-PCN [I-D.ietf-pcn-architecture] 451 identifies that this information needs to be transferred reliably. 453 This section describes the corresponding NSIS extensions. 455 As shown in Figure 4, let us assume that a number of reservations are 456 established and transit through a given Ingress Edge and a given 457 Egress Edge and that the sustainable-aggregate-level, that is 458 monitored by the Egress Edge exceeds a certain threshold level. 459 Therefore the Egress Edge sends this measured Sustainable-Aggregate- 460 Rate for the CL-region-aggregate from Ingress Edge to Egress Edge. 461 To do this, the Egress Edge sends aa asynchronous NOTIFY message 462 (described in Section 5.4.4 of the QoS-NSLP [I-D.ietf-nsis-qos-nslp]) 463 with the PCN-CL-QSPEC parameter containing the current Sustainable- 464 Aggregate-Rate. 466 To avoid the risk that this NOTIFY message gets lost and in turn that 467 the Ingress Edge is not made aware in a timely manner that preemption 468 may be needed, the NSIS reliable messaging procedures specified for 469 reliable NOTIFY messages mentioned in QoS-NSLP MUST be used. 471 On receipt of the NOTIFY message, Ei on noting the value of 472 Sustainable-Aggregate-Rate will identify that pre-emption of flows 473 should take place and will trigger its pre-emtion trigger. This will 474 assess whether some reservations need to be dropped in accordance 475 with the CL-PCN [I-D.ietf-pcn-architecture] and PCN-MARKING 476 [I-D.briscoe-tsvwg-cl-phb] scheme. In case some do, those will be 477 torn down as per regular NSIS procedures. 479 3.4.1. Receiver Initiated QoS Reservation 481 TODO 483 Editor's node: We will have to consider the case of the Receiver 484 initiated QoS signalling w.r.t the CL-PCN architecture. 486 QNE QNE 487 QNI INGRESS EGRESS 488 | | | 489 | | | 490 | | | 491 | | | 492 . 493 . 494 < After initial signalling message exchange > 495 . 496 . 498 | | | 499 | | 500 | DATA FLOW | \ 501 -----------------------------------------------------------\ 502 ------------------------------------------------------------/ 503 | | | / 504 | | | / 505 | | 507 | | | 508 | NOTIFY(PCN-CL-QSPEC)| 509 | |<------------------| 510 | | | 511 | | 512 | < Ingress will assess the situation | 513 | and pre-empt some data flows and | 514 | initiate NSIS tear process for the | 515 | selected flows for pre-emption > | 516 | | 517 | | | 518 | | 519 | REDUCED DATA FLOW | \ 520 -----------------------------------------------------------\ 521 ------------------------------------------------------------/ 522 | | | / 523 | | | / 524 | | | 526 Figure 4: Admission Control by Pre-emption of FLows 528 4. PCN-CL-QSPEC Parameter 530 This document defines a new QSPEC parameter. 532 The PCN-QOSM uses the QSpec format specified in QSPEC 533 [I-D.ietf-nsis-qspec]. 535 The < I > flag is set to "Local" (i.e., "1"). There is no necessity 536 for a QoS-Desired or a QoS-Reserved object since there is no state 537 being set in the local domain. Moreover there is no need to indicate 538 the message sequence as sender initiated or receiver initiated. 540 0 1 2 3 541 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Congestion-Level-Estimate | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Sustainable-Aggregate-Rate | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 Figure 5: PCN-CL-QSPEC Parameter 550 The PCN-CL-QSPEC parameter can appear in any message that can carry a 551 QSPEC. The fields inside the PCN-CL-QSPEC parameter have the 552 following semantic (Encoding details will be provided in future 553 versions): 555 Congestion-Level-Estimate: 557 This contains the value of the Congestion-Level-Estimate (defined 558 in CL-PCN [I-D.ietf-pcn-architecture] and PCN-MARKING 559 [I-D.briscoe-tsvwg-cl-phb]) computed by Egress edge for the CL- 560 region-aggregate from the ingress edge to the egress edge. 562 Sustainable-Aggregate-Rate: 564 This contains the Sustainable-Aggregate-Rate for the relevant CL- 565 region-aggregate from the Ingress to the Egress defined in CL-PCN 566 [I-D.ietf-pcn-architecture] and PCN-MARKING 567 [I-D.briscoe-tsvwg-cl-phb]) computed by the Egress for this CL- 568 region-aggregate. It has a NULL value when the Egress wants to 569 inform that pre-emption is not required. 571 5. Error Codes 573 This section defines two error codes to be added to the INFO-Spec 574 mentioned in Section 5.2.3 of QSPEC [I-D.ietf-nsis-qspec]. 576 5.1. CL-PCN-Probes-Required-Error-Code 578 This error code is present in a RESPONSE message from a Egress edge 579 to the Ingress edge, informing the ingress that probe packets need to 580 be sent. 582 Error code = [[To be allocated by IANA]] 584 5.2. CL-PCN-Inconsistent-Admission-Control-Behaviour-Error-Code 586 The "CL-PCN-Inconsistent-Admission-Control-Behaviour-Error-code" may 587 appear only in RESERVE messages to indicate error to the receiver or 588 in a RESPONSE message to indicate to the sender that the Egress Edge 589 node is not CL-PCN [I-D.ietf-pcn-architecture] capable. 591 Error code = [[To be allocated by IANA]] 593 Error value = [[To be allocated by IANA]] 595 6. IANA Considerations 597 PCN-QOSM requires a new IANA registry for the CL-PCN QoS Model 598 Identifier. It is a 8-bit value, carried in the field 599 of the QSpec object [I-D.ietf-nsis-qspec]. 601 PCN-QoSM defines a new QSPEC parameter called PCN-CL-QSPEC parameter 602 (as described in Section 4) to the QPSEC draft. 604 PCN-QoSM also defines two new error codes to be added to the QSPEC 605 INFO-SPEC: 607 o "CL-PCN-Probes-Required-Error-Code" error code as described in 608 Section 5. 610 o "CL-PCN-Inconsistent-Admission-Control-Behaviour-Error-code" error 611 code as described in Section 5. 613 7. Security Considerations 615 TO be added 617 8. Acknowledgements 619 To be added 621 9. References 623 9.1. Normative References 625 [I-D.briscoe-tsvwg-cl-phb] 626 Briscoe, B., "Pre-Congestion Notification marking", 627 draft-briscoe-tsvwg-cl-phb-03 (work in progress), 628 October 2006. 630 [I-D.ietf-nsis-ntlp] 631 Schulzrinne, H. and R. Hancock, "GIST: General Internet 632 Signalling Transport", draft-ietf-nsis-ntlp-14 (work in 633 progress), July 2007. 635 [I-D.ietf-nsis-qos-nslp] 636 Manner, J., "NSLP for Quality-of-Service Signaling", 637 draft-ietf-nsis-qos-nslp-15 (work in progress), July 2007. 639 [I-D.ietf-nsis-qspec] 640 Ash, J., "QoS NSLP QSPEC Template", 641 draft-ietf-nsis-qspec-17 (work in progress), July 2007. 643 [I-D.ietf-pcn-architecture] 644 Eardley, P., "Pre-Congestion Notification Architecture", 645 draft-ietf-pcn-architecture-00 (work in progress), 646 August 2007. 648 [I-D.lefaucheur-rsvp-ecn] 649 Faucheur, F., "RSVP Extensions for Admission Control over 650 Diffserv using Pre-congestion Notification (PCN)", 651 draft-lefaucheur-rsvp-ecn-01 (work in progress), 652 June 2006. 654 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 655 Requirement Levels", BCP 14, RFC 2119, March 1997. 657 [RFC2211] Wroclawski, J., "Specification of the Controlled-Load 658 Network Element Service", RFC 2211, September 1997. 660 9.2. Informative References 662 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 663 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 664 Functional Specification", RFC 2205, September 1997. 666 [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 667 of Guaranteed Quality of Service", RFC 2212, 668 September 1997. 670 Author's Address 672 Mayutan Arumaithurai 673 University of Goettingen 675 Email: arumaithurai@informatik.uni-goettingen.de 677 Full Copyright Statement 679 Copyright (C) The IETF Trust (2007). 681 This document is subject to the rights, licenses and restrictions 682 contained in BCP 78, and except as set forth therein, the authors 683 retain all their rights. 685 This document and the information contained herein are provided on an 686 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 687 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 688 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 689 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 690 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 691 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 693 Intellectual Property 695 The IETF takes no position regarding the validity or scope of any 696 Intellectual Property Rights or other rights that might be claimed to 697 pertain to the implementation or use of the technology described in 698 this document or the extent to which any license under such rights 699 might or might not be available; nor does it represent that it has 700 made any independent effort to identify any such rights. Information 701 on the procedures with respect to rights in RFC documents can be 702 found in BCP 78 and BCP 79. 704 Copies of IPR disclosures made to the IETF Secretariat and any 705 assurances of licenses to be made available, or the result of an 706 attempt made to obtain a general license or permission for the use of 707 such proprietary rights by implementers or users of this 708 specification can be obtained from the IETF on-line IPR repository at 709 http://www.ietf.org/ipr. 711 The IETF invites any interested party to bring to its attention any 712 copyrights, patents or patent applications, or other proprietary 713 rights that may cover technology that may be required to implement 714 this standard. Please address the information to the IETF at 715 ietf-ipr@ietf.org. 717 Acknowledgment 719 Funding for the RFC Editor function is provided by the IETF 720 Administrative Support Activity (IASA).