idnits 2.17.00 (12 Aug 2021) /tmp/idnits20974/draft-kappler-nsis-qosmodel-controlledload-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 4, 2011) is 3911 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Kappler 3 Internet-Draft ck technology concepts 4 Intended status: Informational X. Fu 5 Expires: March 7, 2012 B. Schloer 6 Univ. Goettingen 7 September 4, 2011 9 A QoS Model for Signaling IntServ Controlled-Load Service with NSIS 10 draft-kappler-nsis-qosmodel-controlledload-14 12 Abstract 14 This document describes a QoS Model to signal IntServ controlled load 15 service with QoS NSLP. QoS NSLP is QoS Model agnostic. All QoS 16 Model specific information is carried in an opaque object, the QSPEC. 17 This document hence specifies the QSPEC for controlled load service, 18 how the QSPEC must be processed in QoS NSLP nodes, and how QoS NSLP 19 messages must be used. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 7, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Signaling with QoS NSLP . . . . . . . . . . . . . . . . . . . 5 70 3.1. QoS NSLP . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.2. QSPEC . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.3. QoS Model . . . . . . . . . . . . . . . . . . . . . . . . 7 73 4. IntServ Controlled Load Service . . . . . . . . . . . . . . . 7 74 5. NSIS QoS Model for IntServ Controlled Load Service . . . . . . 8 75 5.1. Role of QNEs . . . . . . . . . . . . . . . . . . . . . . . 9 76 5.2. QSPEC Definition . . . . . . . . . . . . . . . . . . . . . 9 77 5.2.1. Controlled Load Service Requirements . . . . . . . . . 9 78 5.2.2. QSPEC Objects . . . . . . . . . . . . . . . . . . . . 10 79 5.3. Usage of QoS NSLP Messages -- QSPEC Procedures . . . . . . 11 80 6. Processing Rules in QNEs . . . . . . . . . . . . . . . . . . . 12 81 6.1. Admission Control . . . . . . . . . . . . . . . . . . . . 12 82 6.2. Packet Scheduling and Excess Treatment . . . . . . . . . . 13 83 7. Preemption . . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 8. Interoperation with Controlled Load Service Specified in 85 RFC2211 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 87 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 88 11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 91 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 92 Appendix A. Bit level Examples of QSPEC objects for 93 Controlled Load QOSM . . . . . . . . . . . . . . . . 18 94 A.1. Minimal QSPEC objects for Sender-Initiated Reservation . . 18 95 A.2. Extended QSPEC objects for Sender-Initiated Reservation . 19 96 A.3. Receiver Initiated Reservation (RSVP Style) . . . . . . . 21 97 A.4. Resource Queries . . . . . . . . . . . . . . . . . . . . . 24 98 Appendix B. Change Tracker . . . . . . . . . . . . . . . . . . . 25 99 B.1. Changes since -13 . . . . . . . . . . . . . . . . . . . . 25 100 B.2. Changes since -12 . . . . . . . . . . . . . . . . . . . . 25 101 B.3. Changes since -11 . . . . . . . . . . . . . . . . . . . . 25 102 B.4. Changes since -10 . . . . . . . . . . . . . . . . . . . . 25 103 B.5. Changes since -09 . . . . . . . . . . . . . . . . . . . . 26 104 B.6. Changes since -08 . . . . . . . . . . . . . . . . . . . . 26 105 B.7. Changes since -07 . . . . . . . . . . . . . . . . . . . . 26 106 B.8. Changes since -06 . . . . . . . . . . . . . . . . . . . . 26 107 B.9. Changes since -05 . . . . . . . . . . . . . . . . . . . . 26 108 B.10. Changes since -04 . . . . . . . . . . . . . . . . . . . . 26 109 B.11. Changes since -03 . . . . . . . . . . . . . . . . . . . . 26 110 B.12. Changes since -02 . . . . . . . . . . . . . . . . . . . . 26 111 B.13. Changes since -01 . . . . . . . . . . . . . . . . . . . . 27 112 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 27 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 115 1. Introduction 117 The QoS NSIS Signaling Layer Protocol, QoS NSLP [RFC5974] defines how 118 to signal for QoS reservations in the Internet. The protocol is not 119 bound to a specific mechanism for achieving QoS, such as IntServ or 120 DiffServ. Rather, the actual QoS information is carried opaquely in 121 the protocol in a separate object, the QSPEC [RFC5974]. A method for 122 achieving QoS for a traffic flow is called QoS model. It is expected 123 that a number of QoS models will be developed for QoS NSLP. Examples 124 are [RFC5977] and [RFC5976] and this draft. 126 The purpose of this document is to describe a QoS model for 127 controlled-load service of IntServ [RFC2211]. In [RFC2210] it is 128 specified how to signal for controlled-load service with RSVP. This 129 document describes how to signal for the same service with QoS NSLP. 131 The controlled-load service is rather minimal both in terms of 132 information that is signaled - basically bandwidth in the form of a 133 token bucket - and in terms of prescribed realization of the service 134 in the network. It is therefore suited for a wide range of 135 realizations, such as reserving resources per-flow per-network node 136 [RFC1633], achieving QoS in appropriately engineered DiffServ 137 networks with admission control [RFC2998], or across IP tunnels or 138 MPLS Label Switched Paths (LSPs) with reserved bandwidths and 139 admission control [RFC2746] [RFC3031]. 141 The document is structured as follows: It gives a brief overview of 142 QoS NSLP and the QSPEC, and the content and features of a QoS model 143 as described in [RFC5974] and [RFC5975]. It then gives a brief 144 overview of the controlled-load service of IntServ. Subsequently, 145 the actual QoS model for controlled-load service is described. A 146 section describing the interoperation of QoS NSLP and RSVP, both for 147 signaling controlled-load service, is also provided. 149 2. Terminology 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 The terminology defined in [RFC5974] and [RFC5975] applies to this 156 document. 158 3. Signaling with QoS NSLP 159 3.1. QoS NSLP 161 QoS NSLP [RFC5974] is an NSIS signaling layer protocol for signaling 162 QoS reservations in the Internet. Together with GIST [RFC5971], it 163 provides functionality similar to RSVP and extends it, e.g. by 164 supporting both sender-initiated and receiver-initiated reservations. 165 QoS NSLP however does not support multicast. QoS NSLP establishes 166 and maintains reservation state in QoS NSLP aware nodes, called QNEs, 167 along the path of a data flow. The number or frequency of QNEs is 168 not prescribed. The node initiating a reservation request is called 169 QNI, the node terminating the request is called QNR. QNI and QNR are 170 also QNEs, and are not necessarily the actual sender and receiver of 171 the data flow they are signaling for as they may also be proxying for 172 them. 174 QoS NSLP defines four message types, RESERVE, QUERY, RESPONSE and 175 NOTIFY. The message type identifies whether a message manipulates 176 state (e.g. RESERVE) or not (e.g. QUERY, RESPONSE). The RESERVE 177 message is used to create, refresh, modify or remove reservation 178 state in QNEs. The QUERY message is used to request information 179 about the data path without making a reservation. This functionality 180 may be used to 'probe' the path for certain characteristics. The 181 RESPONSE message is used to provide information about the results of 182 a previous RESERVE or QUERY message, e.g. confirmation of a 183 successful reservation, error, or for transferring results of a QUERY 184 back towards the querying node. A NOTIFY message is sent 185 asynchronously and need not refer to any previously received message. 186 The information conveyed by a NOTIFY message is typically related to 187 error conditions. 189 3.2. QSPEC 191 QoS NSLP carries QoS Model specific information encapsulated in an 192 opaque object, the QSPEC [RFC5975]. The QSPEC thus fulfills a 193 similar purpose as TSpec, RSpec and AdSpec in RSVP [RFC2205]. The 194 QSPEC is not interpreted by the QoS NSLP Processing unit on a QNE, 195 but passed as-is to the Resource Management Function RMF, usually 196 located on the same node, where it is interpreted. 198 The QSPEC is composed of QSPEC objects, namely , , and . A QSPEC typically only 200 contains a subset of these objects. QSPEC objects contain a set of 201 QSPEC parameters that govern the processing of the resource request 202 in the RMF, e.g. information on excess treatment. 203 o contains parameters describing the QoS desired by a 204 QNI. 206 o contains parameters describing the available 207 resources. In the controlled load service QOSM, this QSPEC object 208 is used to collect information on the available bandwidth along a 209 path. 210 o describes the actual QoS reserved. 211 o can be included by a QNI together with QoS Desired 212 to signal a range of QoS (between QoS Desired and Minimum QoS) is 213 acceptable. 215 The QSPEC template [RFC5975] defines a number of QSPEC parameters. 216 provides a description of the traffic for which resources are 217 reserved. This parameter MUST be interpreted by each QNE along the 218 path. All other QSPEC parameters MAY be signaled by the QNI if they 219 are applicable to the underlying QOS desired. The QNI sets the 220 M-Flag if they must be interpreted by downstream QNEs. If the 221 parameter cannot be interpreted by a QNE the reservation fails. A 222 QSPEC parameter without set M-Flag should be interpreted by the QNE 223 but may be ignored if it cannot be interpreted. In a given QoS 224 Model, new optional parameters may be defined. 226 3.3. QoS Model 228 A QoS-enabled domain supports a particular QoS model (QOSM), which is 229 a method to achieve QoS for a traffic flow, such as IntServ 230 Controlled Load or DiffServ [RFC2475]. QoS NSLP is independent of 231 the QOSM, just as RSVP [RFC2205] is independent of IntServ. A QOSM 232 hence incorporates QoS provisioning methods and a QoS architecture. 233 It however also defines how to use QoS NSLP. It therefore defines 234 the behavior of the resource management function (RMF), including 235 inputs and outputs, and how QSPEC information on traffic description, 236 resources required, resources available, and control information 237 required by the RMF is interpreted. A QOSM also specifies the QSPEC 238 parameters that describe the QoS and how resources will be managed by 239 the RMF. 241 4. IntServ Controlled Load Service 243 As specified in [RFC2211], the controlled-load service defined for 244 IntServ supports applications which are highly sensitive to overload 245 conditions, e.g. real-time applications. The controlled-load service 246 provides to an application approximately the end-to-end service of an 247 unloaded best-effort network. "Unloaded" thereby is used in the 248 sense of "not heavily loaded or congested" rather than in the sense 249 of "no other network traffic". 251 The definition of controlled-load service is intentionally imprecise. 252 It implies a very high percentage of transmitted packets will be 253 successfully delivered to the end nodes. Furthermore, the transit 254 delay experienced by a very high percentage of the delivered packets 255 will not greatly exceed the minimum transmit delay experienced by any 256 successfully delivered packet. In other words, a short disruption of 257 the service is viewed as a statistical effect which may occur in 258 normal operation. Events of longer duration are indicative of 259 failure to allocate sufficient resources to the controlled-load flow. 261 In order to ensure that the conditions on controlled-load service are 262 met, clients requesting the service provide network elements on the 263 data path with an estimation of the data traffic they are going to 264 generate. When signaling with RSVP, the object carrying this 265 estimation is called TSpec. In return, the service ensures that in 266 each network element on the data path, resources adequate to process 267 traffic falling within this descriptive envelope will be available to 268 the client. This must be accomplished by admission control. 270 The controlled-load service is implemented per-flow in each network 271 element on the data-path. Thereby, a network element may be an 272 individual node such as a router. However, a network element can 273 also be a subnet, e.g. a DiffServ cloud within a larger IntServ 274 network [RFC2998]. In this case, the per-flow traffic description 275 (e.g. carried in the RSVP TSpec) together with the DiffServ Code 276 Point (carried e.g. in the DCLASS object [RFC2996] of RSVP) is used 277 for admission control into the DiffServ cloud. The DiffServ cloud 278 MUST ensure it provides controlled-load service. It is also possible 279 to operate controlled-load service over logical links such as IP 280 tunnels [RFC2746] or MPLS LSPs [RFC3031]. The per-flow traffic 281 descriptor is in this case used for admission control into the 282 tunnel/LSP. 284 5. NSIS QoS Model for IntServ Controlled Load Service 286 According to [RFC5975], a QOSM MUST include the following 287 information: 288 o role of QNEs, e.g., location, frequency, statefulness, etc. 289 o QSPEC definition including QSPEC parameters 290 o QSPEC procedures applicable to this QOSM 291 o QNE processing rules describing how QSPEC information is treated 292 and interpreted in the RMF, e.g., admission control, scheduling, 293 policy control, QoS parameter accumulation (e.g., delay). 294 o at least one bit-level QSPEC example 295 o QSPEC parameter behavior for new QSPEC parameters the QOSM 296 specification defines 297 o a defininition of what happens in case of preemption if the 298 default QNI behavior (tear down preempted reservation) is not 299 followed 301 A QOSM specification MAY include the following information: 302 o defininitions of additional QOSM-specific error codes 303 o the QoS NSLP options a QOSM wants to use, when several options are 304 available for a QOSM (e.g., Local QSPEC to either a) hide 305 Initiator QSPEC within a local domain message, or b) encapsulate 306 Initiator QSPEC). 308 Subsequent sections treat these points one-by-one. Several example 309 bit-level QSPEC formats are given in Appendix A. 311 5.1. Role of QNEs 313 Controlled-load service network elements can be individual routers or 314 subnets. I.e. it is not necessary for each network node on the data 315 path to interpret the signaling for the service. Rather, dedicated 316 nodes MAY interpret signaling information and take on responsibility 317 that the subnet they represent delivers adequate service. In fact, 318 this setting maps nicely onto QoS NSLP - and the NSIS protocol suite 319 in general. In NSIS, QNEs are just required to be located on the 320 data path. However there are no prescriptions regarding their number 321 or frequency. Hence, in the controlled-load QoS model, there MUST be 322 (at least) one QNE acting on behalf of every network element. For 323 example all ingress routers to a DiffServ cloud could be QNEs, 324 performing admission control. If there is more than one network 325 element per QNE, they MUST be coordinated among to ensure they 326 delivers controlled-load service. Controlled Load QNEs are always 327 stateful. 329 5.2. QSPEC Definition 331 5.2.1. Controlled Load Service Requirements 333 The controlled-load service QOSM uses TMOD1 parameters[RFC5975], 334 which consist of a token bucket specification (i.e. bucket rate r and 335 a bucket depth b) plus a peak rate (p), a minimum policed unit (m) 336 and a maximum packet size (MPS). The minimum policed unit m is an 337 integer measured in bytes. All IP datagrams of size less than m are 338 counted against the token bucket as being of size m. For more 339 details, including value ranges of the parameters see [RFC2210]. 341 The TMOD1 parameter contains a maximum packet size (MPS), as the 342 original token bucket does (MTU). When using RSVP to signal for 343 controlled-load services, the PATH message collects information on 344 MTU and available bandwidth which is used by the receiver to adapt 345 the reservation parameters in the RESV message [RFC2210][RFC2215]. 346 In QoS NSLP the TMOD1 parameter collecting resource information on 347 the path may be included in QUERY, RESERVE or RESPONSE messages. 349 Available bandwidth may be collected if desired and used for 350 controlled load service QOSM. The controlled-load service has no 351 required characterization parameters the QNI needs to be informed 352 about, i.e. current measurement and monitoring information need not 353 be exported by QNEs, although individual implementations may do so if 354 they wish. 356 5.2.2. QSPEC Objects 358 The QSPEC can contain some or all of the following objects: 360 = 362 = 364 = 366 = 368 Among them, , and MUST be 369 supported by all QOSM implementations, as defined in [RFC5975]. 371 is required for receiver-initiated reservations with 372 object combination 1 and 2, and object combination 1 and 2 in sender- 373 initiated reservations. It is used for gathering available bandwidth 374 information along the path. This information can be used by the QNI 375 (or QNR, for receiver-initiated reservations) to make an appropriate 376 reservation thereafter, particularly to re-issue a failed 377 reservation. Since only bandwidth is needed, set the 378 parameters r = peak rate = p, b = large, m = large and for TCP 379 traffic, r = average rate, b = large, p = large. 381 MAY be supported by QNEs and is optional to implement 382 and to use. If supported it always travels together with . It signifies that the QNI can accept a downgrade of 384 resources for particular parameters in the reservation, down to the 385 value of the respective parameter in . For parameters 386 not appearing in , it cannot accept a downgrade. For 387 controlled load service this means if is included, a 388 downgrade of all TMOD1 parameters is possible. 390 Furthermore, the Excess Treatment parameter MAY be included as 391 parameter. Currently supported values are "drop", "shape" or "re- 392 mark". The default value for the Controlled Load QOSM if not 393 included is "shape". This parameter is used for a controlled load 394 service implementation to handle the received data traffic belonging 395 to a controlled load flow which is "non-conformant" to the TMOD1 396 specification reserved. Traffic is considered "non-conformant" when: 398 o over time period T, the amount of data received exceeds rT+b; or 399 o data rate of the traffic exceeds the peak rate p; or 400 o data packet size is larger than M or the QNE's outgoing link MTU 402 In all QSPEC objects additional parameters MAY be included, as 403 described in [RFC5975]. 405 5.3. Usage of QoS NSLP Messages -- QSPEC Procedures 407 QoS NSLP allows a variety of message sequences for reserving 408 resources ("QSPEC Procedures"). Particularly, sender-initiated, 409 receiver-initiated and bi-directional messages are possible. E.g., 410 in sender-initiated reservations, a RESERVE is issued by the QNI. If 411 the reservation is successful, the QNR replies with a RESPONSE. If 412 the reservation fails, the QNE at which it failed sends an INFO_SPEC 413 object indicating this failure towards the QNI. 415 The QSPEC template defines what QSPEC objects are carried in which of 416 these messages, and how they are translated from message-to-message. 417 For each of the message patterns defined in QoS NSLP, a variety of 418 QSPEC object usages, the so-called QSPEC Procedures, are possible. 419 o in the simplest message sequence, sender-initiated reservations, 420 the RESERVE may carry just to indicate the exact QoS 421 it wants, and the corresponding RESPONSE carries solely . This implies either the exact resources described in 423 are reserved, or the reservation fails. 424 o A more advanced QNI would include, in addition to , a 425 QSPEC object, or even a . allows collecting path properties, e.g. currently 427 available TMOD1, and signals that (and how much) 428 less resources than are acceptable. The RESPONSE 429 message carries , and additionally copies the QSPEC Object from RESERVE. This information may be of 431 particular interest if a reservation failed. Note however, that 432 since the QNE failing the reservation sends the RESPONSE, no 433 complete end-to-end information on e.g. bandwidth can be collected 434 and delivered to the QNI. 435 o In an "RSVP-style" receiver-initiated reservation, the sender 436 (QNR) issues a QUERY with specifying the desired 437 resources and collecting information on available 438 TMOD1 parameters. The receiver (QNI) reacts with a RESERVE 439 message containing with a TMOD1. is 440 copied from the QUERY message. The signaling exchange is 441 concluded with a RESPONSE by the QNR including a 442 echoing the TMOD1 that was reserved. 444 Note that the initial message triggering the signaling exchange fully 445 determines the sequencing of subsequent messages, and also determines 446 what QSPEC objects will be carried in them. That is, only the QNI 447 for sender initiated reservation and the QNR for receiver initiated 448 reservation have freedom in choosing a particular QSPEC procedure. 449 Other QNEs can only react to this. 451 The controlled load service parameters can be signaled with any QSPEC 452 procedure. Note, in contrast, in RSVP only one type of message 453 exchange is defined (receiver-initiated reservations, and the 454 equivalent of = 0). However, this is a characteristic 455 of RSVP rather than of the controlled load service. 457 6. Processing Rules in QNEs 459 6.1. Admission Control 461 For controlled-load service, QNEs are required to perform admission 462 control. All resources important to the operation of the network 463 element MUST be considered when admitting a request. Common examples 464 of such resources include link bandwidth, router or switch port 465 buffer space, and computational capacity of the packet forwarding 466 engine. It is not prescribed how a QNE determines adequate resources 467 are available. It is however required that they make bandwidth 468 greater than the token rate available to the flow in certain 469 situations in order to account for fluctuations. E.g. statistical 470 methods may be used to determine how much bandwidth is necessary. 472 During the admission control, the controlled-load service TMOD1 473 parameters MUST be met according to the following rule: a TMOD1 A 474 from the available resources for a flow MUST be "as good or better 475 than" or "greater than or equal to" TMOD1 B (which is carried in the 476 received QoS Description, e.g., , or if 477 available), i.e.,: 478 o the TMOD1 rate r for TMOD1 A is greater than or equal to that of 479 TMOD1 B, and 480 o the TMOD1 depth b for TMOD1 A is greater than or equal to that of 481 TMOD1 B, and 482 o the peak rate p for TMOD1 A is greater than or equal to that of 483 TMOD1 B, and 484 o the minimum policed unit m for TMOD1 A is less than or equal to 485 that of TMOD1 B, and 486 o the maximum packet size MPS of TMOD1 A is greater than or equal to 487 that of TMOD1 B. 489 Remark: these rules come originally from rules for ordering TMOD1s in 490 [RFC2211]. 492 There are no target values for other parameters, e.g. delay or loss, 493 other than providing a service closely equivalent to that provided to 494 best-effort traffic under lightly loaded conditions. 496 Resource requests for new flows are accepted if capacity is 497 available. Reservation modifications are accepted if the new 498 is strictly smaller than the old one. Otherwise they are treated 499 like new reservations from an admission control perspective. 501 6.2. Packet Scheduling and Excess Treatment 503 A QNE MUST ensure the TMOD1 requirements for any individual flow 504 given at setup time are met locally. That is, traffic MUST obey the 505 rule that over all time periods, the amount of data sent does not 506 exceed rT+b. Packets smaller than m are counted as of size m. A 507 basic requirement for packet scheduling is that the QNE MUST ensure 508 the QoS requirements are met for traffic belonging to flows whose 509 traffic are all conformant. 511 In presence of arriving non-conformant traffic, the QNE MUST behave 512 as follows: 513 o the QNE MUST continue to provide the contracted QoS for traffic 514 belonging to flows which are all conformant. 515 o the QNE SHOULD prevent excess control load traffic from unfairly 516 impacting the handling of arriving best-effort traffic. 517 o While fulfilling the above two requirements, the QNE MUST attempt 518 to forward the excess traffic on a best-effort basis if sufficient 519 resources are available, unless indicated differently by . 522 Several basic approaches for excess treatment are suggested in 523 [RFC2211] and reused here, although other alternatives are possible, 524 if available. A simple approach is the priority mechanism, namely, 525 to let the QNE process excess controlled-load traffic at a lower 526 priority than the elastic best-effort traffic, especially when the 527 most controlled-load traffic arises from non-rate-adaptive real-time 528 applications. 530 The second approach is that a QNE can maintain separate flow classes 531 (e.g., one for each non-conformant controlled-load traffic, one for 532 inelastic best-effort flows, and another from elastic best-effort 533 flows), where packet scheduling mechanisms like Fair Queueing or 534 Weight Fair Queueing can be used. One implementation, for instance, 535 could allocate each controlled-load flow a 1/N "fair share" 536 percentage of the available best effort bandwidth for its excess 537 traffic. 539 Finally, Random Early Detection (RED) queueing mechanism may be used. 541 7. Preemption 543 The controlled-load service QOSM makes use of the and parameter to preempt flows. A new 545 flow with higher can preempt an already 546 admitted flow with lower . One single higher 547 priority flow can replace more than one lower priority flow until the 548 requested amount of is met. Once the flow is admitted 549 becomes irrelevant. More details about 550 Preemption and Defending Priority are provided in [RFC3181]. 552 8. Interoperation with Controlled Load Service Specified in RFC2211 554 The controlled-load service QOSM is intended to be consistent with 555 the RSVP/Controlled Load Service specified in [RFC2211], although the 556 signaling protocols used are QoS NSLP and RSVP, respectively. This 557 section discusses how a router implementing both RSVP and QoS NSLP 558 could translate from one to the other. 560 The following is a table that contains a mapping of messages, objects 561 and parameters between QoS NSLP and RSVP for the specific case of 562 controlled-load signaling using the "RSVP-style" receiver-initiated 563 signaling described in Appendix A.3. 565 | Message | Object(s) | Parameter(s) 566 -------------------------------------------------------------------- 567 RSVP | Path | Sender TSpec | token bucket 568 | | ADSpec | avail. bw and MTU 569 QoS NSLP | QUERY | | 570 | | | 571 | | | 572 RSVP | Resv | FlowSpec | token bucket 573 QoS NSLP | RESERVE | | 574 | | | 575 | | | 576 RSVP | ResvConfirm | | 577 QoS NSLP | RESPONSE | | 579 Please note that TMOD1 in specifies bandwidth only. 580 See Section Section 5.2.2 how to set bandwidth in TMOD. 582 A RSVP Path Message includes a SenderTSPEC specifying the traffic an 583 application is going to send. The RSVP AdSpec is optionally 584 included. It probes for the available bandwidth on the data path. 585 This reservation model is referred to as One Pass with Advertising 586 (OPWA). When the AdSpec is omitted, the Receiver cannot determine 587 the available resources for the resulting end-to-end QoS. This 588 reservation model is referred to as One Pass. On arrival at the 589 Receiver the FlowSpec, consisting of the TSpec, is created. The 590 TSpec is usually derived from the SenderTSpec and if available from 591 the AdSpec. It contains the desired QoS. The Resv message is sent 592 upstream to the Sender. At each hop the desired resource reservation 593 is reserved. The last node sends a ResvConf back to the Receiver to 594 indicate that end-to-end reservation has been installed. 596 In QoS NSLP, the sender populates the QoS which it desires by 597 including a and optionally queries the network for the 598 QoS that is available. In this case it carries the 599 parameter which is updated by all QNEs to reflect the QoS that is 600 actually available. With the object, the Receiver 601 (QNI) is informed about the requested resources. See Section 5.3 for 602 a detailed description of QSPEC procedures for controlled-load 603 service. 605 9. Security Considerations 607 This document does not raise additional security issues beyond those 608 described in [RFC5974] and [RFC5975]. 610 10. IANA Considerations 612 A new QOSM ID ("Controlled-Load Service QOSM") needs to be assigned 613 by IANA. 615 11. Conclusions 617 This document describes a QoS Model to signal IntServ controlled load 618 service with QoS NSLP. Up to now, it was only described how to 619 signal for IntServ controlled load service with RSVP. Since no 620 independent document exists that describes IntServ controlled load by 621 its own, i.e. without RSVP, it is sometimes difficult to determine 622 what features are specific to IntServ controlled load, and which 623 features are specific to RSVP. 625 The QoS NSLP QOSM for controlled load service allows a variety of 626 message exchanges all eventually resulting in a reservation, e.g. 627 sender-initiated, receiver-initiated and bidirectional signaling. 628 The controlled load service when signaled with RSVP was bound to 629 receiver-initiated reservations. 631 When signaling with RSVP, it is not possible to define a range of 632 acceptable QoS. Also this seems to be a characteristic of RSVP 633 rather than a feature of the controlled load service. 635 An issue of general interest discovered here concerns feedback of 636 information in sender-initiated scenarios (In receiver-initiated 637 scenarios it does not occur because path information is collected 638 before the RESERVE is issued). A QNI may include in 639 several parameters, e.g. bandwidth, which it would like to measure 640 along the data path. If the reservation fails, e.g. because the 641 desired bandwidth was to large, the QNE failing the reservation 642 returns a RESPONSE, including the QSPEC object with 643 accumulated information up to this point. The QNI can learn from 644 this why the reservation failed at this particular QNE. However it 645 cannot be sure a subsequent downgraded RESERVE will be more 646 successful. This is because there may be even more difficult 647 conditions (e.g. even less bandwidth) down the path. That is, in 648 sender-initiated scenarios it is not straightforward to receive 649 feedback from a failed reservation that allows to make a good guess 650 at what size of reservation would be more successful. Of course it 651 would be possible for the QNI to issue a QUERY first to find out 652 about a suitable value for, e.g. maximum packet size. However this 653 adds another round-trip time to the reservation, thereby obsoleting 654 one of the main benefits of sender-initiated reservations compared to 655 receiver-initiated ones. 657 In this draft, the feedback problem is solved by including a QSPEC object in sender-initiated reservations. This gives some 659 flexibility as it implicitly says the QNI would also accept a 660 downgraded reservation, up to the value specified. 662 12. References 664 12.1. Normative References 666 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 667 Requirement Levels", BCP 14, RFC 2119, March 1997. 669 [RFC2211] Wroclawski, J., "Specification of the Controlled-Load 670 Network Element Service", RFC 2211, September 1997. 672 [RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS 673 Signaling Layer Protocol (NSLP) for Quality-of-Service 674 Signaling", RFC 5974, October 2010. 676 [RFC5975] Ash, G., Bader, A., Kappler, C., and D. Oran, "QSPEC 677 Template for the Quality-of-Service NSIS Signaling Layer 678 Protocol (NSLP)", RFC 5975, October 2010. 680 12.2. Informative References 682 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 683 Services in the Internet Architecture: an Overview", 684 RFC 1633, June 1994. 686 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 687 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 688 Functional Specification", RFC 2205, September 1997. 690 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 691 Services", RFC 2210, September 1997. 693 [RFC2215] Shenker, S. and J. Wroclawski, "General Characterization 694 Parameters for Integrated Service Network Elements", 695 RFC 2215, September 1997. 697 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 698 and W. Weiss, "An Architecture for Differentiated 699 Services", RFC 2475, December 1998. 701 [RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, 702 "RSVP Operation Over IP Tunnels", RFC 2746, January 2000. 704 [RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, 705 November 2000. 707 [RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., 708 Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. 709 Felstaine, "A Framework for Integrated Services Operation 710 over Diffserv Networks", RFC 2998, November 2000. 712 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 713 Label Switching Architecture", RFC 3031, January 2001. 715 [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", 716 RFC 3181, October 2001. 718 [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet 719 Signalling Transport", RFC 5971, October 2010. 721 [RFC5976] Ash, G., Morton, A., Dolly, M., Tarapore, P., Dvorak, C., 722 and Y. El Mghazli, "Y.1541-QOSM: Model for Networks Using 723 Y.1541 Quality-of-Service Classes", RFC 5976, 724 October 2010. 726 [RFC5977] Bader, A., Westberg, L., Karagiannis, G., Kappler, C., and 727 T. Phelan, "RMD-QOSM: The NSIS Quality-of-Service Model 728 for Resource Management in Diffserv", RFC 5977, 729 October 2010. 731 Appendix A. Bit level Examples of QSPEC objects for Controlled Load 732 QOSM 734 A.1. Minimal QSPEC objects for Sender-Initiated Reservation 736 The first example shows a "minimal" QSPEC for Controlled Load 737 containing the least number of objects and parameters. It signals 738 for sender initiated reservations, containing the TMOD1 for and for . The difference between the QSPEC in 740 the RESERVE and the RESPONSE message is only slight. 742 0 1 2 3 743 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 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Vers.|I|QSPECType|r|r|QSPEC Proc.=0/0| Length = 7 | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 |E|r|r|r| Type = 0 (QoS Des.) |r|r|r|r| Length = 6 | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 |1|E|0|r| ID = 1 |r|r|r|r| Length = 5 | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | TMOD Rate-1 (r) (32-bit IEEE floating point number) | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | TMOD Size-1 (b) (32-bit IEEE floating point number) | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | Peak Data Rate-1 (p) (32-bit IEEE floating point number) | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Minimum Policed Unit-1 (m) (32-bit unsigned integer) | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Maximum Packet Size-1 (MPS) (32-bit unsigned integer) | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 Fig. 1 An Example QSPEC for Sender-Initiated Reservation(RESERVE) 763 0 1 2 3 764 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 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Vers.|I|QSPECType|r|r|QSPEC Proc.=0/0| Length = 7 | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 |E|r|r|r| Type = 2 (QoS Res.) |r|r|r|r| Length = 6 | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 |1|E|0|r| ID = 1 |r|r|r|r| Length = 5 | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | TMOD Rate-1 (r) (32-bit IEEE floating point number) | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | TMOD Size-1 (b) (32-bit IEEE floating point number) | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | Peak Data Rate-1 (p) (32-bit IEEE floating point number) | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | Minimum Policed Unit-1 (m) (32-bit unsigned integer) | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | Maximum Packet Size-1 (MPS) (32-bit unsigned integer) | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 Fig.2 An Example QSPEC for Sender-Initiated Reservation(RESPONSE) 785 A.2. Extended QSPEC objects for Sender-Initiated Reservation 787 The following QSPEC offers a range of acceptable bandwidth in case 788 the request of cannot be fulfilled. When becomes lower than the reservation fails. 790 The requesting node gets informed by about the 791 remaining resources. See [RFC5975] for details. The optional 792 parameter defines the behavior of the traffic 793 conditioner how to handle out of profile traffic. 795 0 1 2 3 796 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 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Vers.|I|QSPECType|r|r|QSPEC Proc.=0/2| Length = 23 | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 |E|r|r|r| Type = 0 (QoS Des.) |r|r|r|r| Length = 8 | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 |1|E|0|r| ID = 1 |r|r|r|r| Length = 5 | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | TMOD Rate-1 (r) (32-bit IEEE floating point number) | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | TMOD Size-1 (b) (32-bit IEEE floating point number) | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | Peak Data Rate-1 (p) (32-bit IEEE floating point number) | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | Minimum Policed Unit-1 (m) (32-bit unsigned integer) | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | Maximum Packet Size-1 (MPS) (32-bit unsigned integer) | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 |M|E|N|r| ID = 11 |r|r|r|r| Length = 1 | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | Excess Trtmnt |Re-mark Val| Reserved | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 |E|r|r|r| Type = 1 (QoS Avail.) |r|r|r|r| Length = 6 | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 |1|E|0|r| ID = 1 |r|r|r|r| Length = 5 | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | TMOD Rate-1 (r) (32-bit IEEE floating point number) | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | TMOD Size-1 (b) (32-bit IEEE floating point number) | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | Peak Data Rate-1 (p) (32-bit IEEE floating point number) | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | Minimum Policed Unit-1 (m) (32-bit unsigned integer) | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | Maximum Packet Size-1 (MPS) (32-bit unsigned integer) | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 |E|r|r|r| Type = 3 (Min. QoS) |r|r|r|r| Length = 6 | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 |1|E|0|r| ID = 1 |r|r|r|r| Length = 5 | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | TMOD Rate-1 (r) (32-bit IEEE floating point number) | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | TMOD Size-1 (b) (32-bit IEEE floating point number) | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | Peak Data Rate-1 (p) (32-bit IEEE floating point number) | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | Minimum Policed Unit-1 (m) (32-bit unsigned integer) | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Maximum Packet Size-1 (MPS) (32-bit unsigned integer) | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 Fig.3 Example QSPEC for Sender-Initiated Reservation(RESERVE) 848 0 1 2 3 849 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 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | Vers.|I|QSPECType|r|r|QSPEC Proc.=0/2| Length = 14 | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 |E|r|r|r| Type = 2 (QoS Res.) |r|r|r|r| Length = 6 | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 |1|E|0|r| ID = 1 |r|r|r|r| Length = 5 | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | TMOD Rate-1 (r) (32-bit IEEE floating point number) | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | TMOD Size-1 (b) (32-bit IEEE floating point number) | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Peak Data Rate-1 (p) (32-bit IEEE floating point number) | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | Minimum Policed Unit-1 (m) (32-bit unsigned integer) | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | Maximum Packet Size-1 (MPS) (32-bit unsigned integer) | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 |E|r|r|r| Type = 1 (QoS Avail.) |r|r|r|r| Length = 6 | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 |1|E|0|r| ID = 1 |r|r|r|r| Length = 5 | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | TMOD Rate-1 (r) (32-bit IEEE floating point number) | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | TMOD Size-1 (b) (32-bit IEEE floating point number) | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Peak Data Rate-1 (p) (32-bit IEEE floating point number) | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Minimum Policed Unit-1 (m) (32-bit unsigned integer) | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Maximum Packet Size-1 (MPS) (32-bit unsigned integer) | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 Fig.4 Example QSPEC for Sender-Initiated Reservation(RESPONSE) 884 A.3. Receiver Initiated Reservation (RSVP Style) 886 This is an example for an 'RSVP-style' reservation using a 3-way 887 handshake. The QNR as the sender issues a QUERY and informs the QNI 888 at the receiver about the desired bandwidth. The requested resources 889 are contained in . Resource information about the path 890 is collected in . The receiver copies the content of 891 into . The QNI is updated about 892 available resources before sending the RESERVE. A RESPONSE is sent 893 back to confirm the reservation. 895 0 1 2 3 896 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 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | Vers.|I|QSPECType|r|r|QSPEC Proc.=1/2| Length = 14 | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 |E|r|r|r| Type = 0 (QoS Des.) |r|r|r|r| Length = 6 | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 |1|E|0|r| ID = 1 |r|r|r|r| Length = 5 | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | TMOD Rate-1 (r) (32-bit IEEE floating point number) | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | TMOD Size-1 (b) (32-bit IEEE floating point number) | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | Peak Data Rate-1 (p) (32-bit IEEE floating point number) | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | Minimum Policed Unit-1 (m) (32-bit unsigned integer) | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | Maximum Packet Size-1 (MPS) (32-bit unsigned integer) | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | Minimum Policed Unit-1 [m] (32-bit unsigned integer) | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 |E|r|r|r| Type = 1 (QoS Avail.) |r|r|r|r| Length = 6 | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 |1|E|0|r| ID = 1 |r|r|r|r| Length = 5 | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | TMOD Rate-1 (r) (32-bit IEEE floating point number) | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | TMOD Size-1 (b) (32-bit IEEE floating point number) | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | Peak Data Rate-1 (p) (32-bit IEEE floating point number) | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | Minimum Policed Unit-1 (m) (32-bit unsigned integer) | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | Maximum Packet Size-1 (MPS) (32-bit unsigned integer) | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 Fig.5 Example QSPEC for Receiver-Initiated Reservation(QUERY) 932 0 1 2 3 933 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 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | Vers.|I|QSPECType|r|r|QSPEC Proc.=1/2| Length = 14 | 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 |E|r|r|r| Type = 0 (QoS Des.) |r|r|r|r| Length = 6 | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 |1|E|0|r| ID = 1 |r|r|r|r| Length = 5 | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | TMOD Rate-1 (r) (32-bit IEEE floating point number) | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | TMOD Size-1 (b) (32-bit IEEE floating point number) | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | Peak Data Rate-1 (p) (32-bit IEEE floating point number) | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | Minimum Policed Unit-1 (m) (32-bit unsigned integer) | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | Maximum Packet Size-1 (MPS) (32-bit unsigned integer) | 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 |E|r|r|r| Type = 1 (QoS Avail.) |r|r|r|r| Length = 6 | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 |1|E|0|r| ID = 1 |r|r|r|r| Length = 5 | 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 | TMOD Rate-1 (r) (32-bit IEEE floating point number) | 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | TMOD Size-1 (b) (32-bit IEEE floating point number) | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Peak Data Rate-1 (p) (32-bit IEEE floating point number) | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | Minimum Policed Unit-1 (m) (32-bit unsigned integer) | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | Maximum Packet Size-1 (MPS) (32-bit unsigned integer) | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 Fig.6 Example QSPEC for Receiver-Initiated Reservation(RESERVE) 967 0 1 2 3 968 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 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 | Vers.|I|QSPECType|r|r|QSPEC Proc.=1/2| Length = 7 | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 |E|r|r|r| Type = 2 (QoS Res.) |r|r|r|r| Length = 6 | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 |1|E|0|r| ID = 1 |r|r|r|r| Length = 5 | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | TMOD Rate-1 (r) (32-bit IEEE floating point number) | 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | TMOD Size-1 (b) (32-bit IEEE floating point number) | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | Peak Data Rate-1 (p) (32-bit IEEE floating point number) | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | Minimum Policed Unit-1 (m) (32-bit unsigned integer) | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | Maximum Packet Size-1 (MPS) (32-bit unsigned integer) | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 Fig.7 Example QSPEC for Receiver-Initiated Reservation(RESPONSE) 989 A.4. Resource Queries 991 The QUERY message is used to collect information about available 992 bandwidth along the path. It does not manipulate any state. In 993 response to the a object describing the 994 resources is returned. 996 0 1 2 3 997 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 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | Vers.|I|QSPECType|r|r|QSPEC Proc.=2/0| Length = 7 | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 |E|r|r|r| Type = 1 (QoS Avail.) |r|r|r|r| Length = 6 | 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 |1|E|0|r| ID = 1 |r|r|r|r| Length = 5 | 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 | TMOD Rate-1 (r) (32-bit IEEE floating point number) | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 | TMOD Size-1 (b) (32-bit IEEE floating point number) | 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 | Peak Data Rate-1 (p) (32-bit IEEE floating point number) | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | Minimum Policed Unit-1 (m) (32-bit unsigned integer) | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | Maximum Packet Size-1 (MPS) (32-bit unsigned integer) | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 Fig.8 Example QSPEC for Resource Queries (QUERY and RESPONSE) 1018 Other scenarios can be easily derived by adapting to the QoS NSLP 1019 signaling procedure and used QoS specifications. 1021 Appendix B. Change Tracker 1023 B.1. Changes since -13 1025 1. Editorial changes made 1027 B.2. Changes since -12 1029 1. References updated 1031 B.3. Changes since -11 1033 1. Editorial changes made 1035 B.4. Changes since -10 1037 1. Updated Bit level Examples of QSPEC object to current Object 1038 format 1040 2. Removed discussion about collecting path MTU 1042 B.5. Changes since -09 1044 1. Updated Bit level Examples of QSPEC object to current Object 1045 format 1047 2. Editorial changes made 1049 B.6. Changes since -08 1051 1. Removed discussion about number of hops not implementing the CLS 1052 QoSM in section Conclusions 1054 B.7. Changes since -07 1056 1. Editorial changes made 1058 B.8. Changes since -06 1060 1. Updated requirements for QOSM specification 1062 2. Clarified the use of 1064 3. Added section about preemption 1066 B.9. Changes since -05 1068 1. Included additional bit-level examples. 1070 2. Updated section about interoperation with RSVP-CLS. 1072 B.10. Changes since -04 1074 1. Adapted terminology and content to latest version of QSPEC (v17). 1075 E.g. removed QOSM ID, removed MTU,... 1077 B.11. Changes since -03 1079 1. Adapted terminology and updated references. 1081 B.12. Changes since -02 1083 1. Added "RSVP-style reservation" as running example 1085 2. Updated interoperability section 1087 3. Aligned QSPEC example in Appendix A with update of QSPEC draft 1088 and added more details 1090 B.13. Changes since -01 1092 1. Clarifications about path MTU, scheduling/excess treatment and 1093 QOSM Hops. 1095 2. Added a section "Interoperation with RFC2211" and QSPEC format as 1096 Appendix. 1098 Appendix C. Acknowledgements 1100 The authors would like to thank Andrew McDonald for fruitful 1101 discussions. John Loughney, Bob Braden and Hannes Tschofenig 1102 provided helpful comments. 1104 Authors' Addresses 1106 Cornelia Kappler 1107 ck technology concepts 1108 Berlin 1109 Germany 1111 Email: cornelia.kappler@cktecc.de 1113 Xiaoming Fu 1114 University of Goettingen 1115 Institute of Computer Science 1116 Goldschmidtstr. 7 1117 Goettingen 37077 1118 Germany 1120 Email: fu@cs.uni-goettingen.de 1122 Bernd Schloer 1123 University of Goettingen 1124 Institute of Computer Science 1125 Goldschmidtstr. 7 1126 Goettingen 37077 1127 Germany 1129 Email: bernd.schloer@yahoo.com