idnits 2.17.1 draft-worster-gsmp-qos-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: '3' is defined on line 992, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1987 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-05) exists of draft-guerin-qos-routing-ospf-04 ** Downref: Normative reference to an Experimental draft: draft-guerin-qos-routing-ospf (ref. '4') == Outdated reference: A later version (-02) exists of draft-ietf-ospf-omp-01 -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' == Outdated reference: A later version (-06) exists of draft-ietf-mpls-cr-ldp-01 ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '11') -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Tom Worster, GDC 2 Internet Draft Fiffi Hellstrand, Ericsson 3 Expires: August 1999 Avri Doria 5 A QoS Model for GSMP 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 The General Switch Management Protocol [1], [2] allows low level 34 control of a label switch. A model for the provision of quality of 35 service must be established in order that GSMP can control the 36 capabilities of a label switch to provide connections with 37 specified quality of service. This memo presents some 38 considerations surrounding the provision of QoS in such an open 39 switch control scenario. This discussion leads to a proposal for a 40 service oriented QoS model for GSMP. The memo also presents 41 proposed extensions to GSMP to allow control of a switch using the 42 Service Model. 44 Table of Contents 46 1. Discussion of QoS models.......................................... 2 47 1.1 Location of the resource manager.............................. 3 48 1.1.1 Resource management in the controller................... 3 49 1.1.2 Resource management in the switch....................... 4 50 1.2 Abstract versus service specific QoS models................... 5 51 1.2.1 Abstract models......................................... 5 52 1.2.2 Service model........................................... 6 53 1.3 Proposed QoS model............................................ 7 55 2. Proposal for QoS features of GSMP................................. 9 57 3. Service Model.................................................... 10 59 4. Service definitions.............................................. 13 60 4.1 ATM Forum Service Categories................................. 14 61 4.1.1 CBR.................................................... 14 62 4.1.2 rt-VBR................................................. 14 63 4.1.3 nrt-VBR................................................ 15 64 4.1.4 UBR.................................................... 16 65 4.1.5 ABR.................................................... 17 66 4.1.6 GFR.................................................... 17 67 4.2 Integrated Services.......................................... 18 68 4.2.1 Controlled Load........................................ 18 69 4.3 MPLS CR-LDP QoS.............................................. 18 70 4.4 Frame Relay.................................................. 19 71 4.5 Diff-Serv.................................................... 19 73 5. Changes to GSMP messages......................................... 19 74 5.1 Configuration messages....................................... 19 75 5.2 Connection management messages............................... 20 76 5.3 Statistics messages.......................................... 20 78 1. Discussion of QoS models 80 This section presents the considerations surrounding the selection 81 of a QoS model for GSMP. We begin this section with a brief 82 description of GSMP applications in order to outline requirements 83 and terminology. 85 The GSMP allows a "controller" to control a "switch". The system of 86 controller plus switch typically functions as a network node in a 87 TCP/IP, ATM or Frame Relay network. Broadly speaking, the 88 controller runs "control protocols" that provide the required 89 network layer services such as IP routing protocols, LDP, PNNI 90 signalling and routing, etc. The term "control plane" refers to the 91 set of protocols and mechanisms used to support a node of one 92 network type, e.g. an ATM control plane. A controller may support 93 multiple control planes. If the physical network supports multiple 94 control planes then the term "logical network" is used to refer to 95 a network as seen by one control plane. 97 The switch is a general label switch with ATM ports and/or other 98 label switched ports. The controller is responsible for installing 99 and deleting connection state in the switch. 101 It is within this context that a quality of service (QoS) model is 102 to be established. The system of controller and switch must be able 103 to efficiently support the QoS requirements of the relevant network 104 technology. The functions required to support network level QoS, in 105 particular the resource management and QoS routing, must be divided 106 in some manner between the controller and the switch. An additional 107 question is whether the QoS model should attempt to generalise 108 network layer QoS or explicitly support specific network layer QoS 109 definitions. These issues are addressed in the sections below. 111 1.1 Location of the resource manager 113 In this section we present the issues surrounding the location of 114 the resource management function with respect to GSMP: on the 115 controller side or on the switch side. 117 1.1.1 Resource management in the controller. 119 In the first model we consider, resource management is the 120 responsibility of the controller. In GSMP the controller is 121 responsible for management of labels and thus it is not 122 unreasonable that the controller should manage other switch 123 resources, such as bandwidth and buffers. 125 The main advantage of resource management on the controller is that 126 it gives the controller scope for considerable sophistication in 127 the deployment of the network's resources -- particularly in the 128 case of multiple control planes. 130 Firstly, since the controller is fully aware of the resource 131 allocation state of the switch it may easily tie this data into its 132 QoS routing mechanisms. In QoS routing schemes, such as PNNI [1] 133 and the proposed IP QoS routing protocols ([4], [5], [6]), link 134 state advertisements propagate the information needed for selection 135 of routes with resource reservation. With resource management in 136 the controller, the generation of such link state information is 137 relatively easy. 139 Secondly, resource management in the controller facilitates 140 sophisticated methods of resource allocation to specific logical 141 networks. Rigid partitioning of network resources among logical 142 networks is inefficient and difficult to administer in an 143 operational network. Full sharing of resources between control 144 planes, on the other hand, does not allow service guarantees for 145 individual logical networks. Thus some kind of partial or limited 146 resource sharing is appropriate. Such resource sharing schemes with 147 provisioned service guarantees are readily implemented if resource 148 management is located in the controller while they are much harder 149 to implement with resource management on the switch. 151 The main disadvantage of putting resource management on the 152 controller is that the controller needs to know something of the 153 capabilities of the switch. To achieve this in a completely general 154 fashion is very hard (this question is addressed below) but in 155 many practical cases it is relatively easy. In particular, the 156 class of resource management techniques based on measurements of 157 network load (see for example [12], [13]) are well suited to 158 controller based resource management. 160 1.1.2 Resource management in the switch 162 In this model, when the controller requests a connection set-up it 163 specifies parameters that describe the connection's QoS 164 requirements with the request. The switch has the responsibility 165 for determining if the connection can be accepted while supporting 166 the QoS commitments of this and other connections and rejecting the 167 request if it cannot. 169 The option of locating resource management in the switch like this 170 has the advantages that it is a familiar approach and may allow 171 reuse of resource management software already implemented on the 172 switch. It is also an obvious approach if one intends to split 173 switch control between a control plane running on the switch and an 174 external GSMP controller. This scenario is, however, not easy to 175 handle properly with GSMP since it is essentially a multi- 176 controller model -- GSMP does not currently make explicit provision 177 for sharing resources with other logical networks. 179 One of the difficulties with this approach is the lack of link 180 state information in the controller. Even in the case of a single 181 logical network, the controller has no a priori knowledge of what 182 the switch is able to accept and when it will run out of resources. 183 This problem gets still harder if the switch includes embedded 184 control, which is accessing link resources independently of a GSMP 185 controller. Without a mechanism for conveying link state 186 information in GSMP to the controller there is very little the 187 controller can do to properly support QoS routing. 189 An additional problem lies in the provisioning of resources among 190 logical networks. In the case that the GSMP controller is in 191 control of all logical networks it can approximately provision 192 resources among its logical networks. But since it does not know 193 the exact behaviour of the switch's resource management it cannot, 194 without being overly conservative, make definite QoS commitments to 195 any of its logical networks. 197 In the case that the GSMP controller shares link resources with an 198 embedded switch control there is the additional question of the 199 mechanism by which resources are provisioned between logical 200 networks and how, in the case that allocations may be dynamically 201 changed, these changes are accounted for in GSMP. Only in the cases 202 of complete resource sharing, in which QoS guarantees for logical 203 networks cannot be made, and static resource partitioning avoid 204 this difficulty. 206 1.2 Abstract versus service specific QoS models 208 Somewhat independent of the question of location of resource 209 management is the question of abstraction in the protocol's QoS 210 model. When the controller requests a connection establishment it 211 expresses the QoS requirements in some "language". The question 212 here is whether that language should be general enough to express 213 all possible requirements in a unified manner or whether specific 214 dialects should be used to express the requirements of specific 215 known services. We call the former an abstract model and an latter 216 a service model. 218 1.2.1 Abstract models 220 There are differences between the abstract model for resource 221 management in the switch and the abstract model for resource 222 management in the controller. (This is perhaps the first 223 disadvantage of abstract models.) 225 If resource management is in the controller then the controller 226 needs to deploy abstract switch resources via GSMP. This QoS model 227 is most in keeping with the original design of GSMP: a low level 228 protocol for management of general switch resources with a very 229 simple switch implementation. It is also the main QoS model used in 230 GSMP Version 2 [2]. 232 In order that the controller is able to deploy the switch's 233 resources it must first be told what these resources are. Thus the 234 first part of this abstract model is a language through which the 235 switch expresses its capabilities. Next the controller may need to 236 configure these resources, for example, to define scheduler weights 237 or set thresholds, so the protocol needs an abstract configuration 238 language. Lastly, when a connection is requested it must be 239 assigned to the appropriate switch resources and possibly given its 240 own parameters to control its use of the resources. 242 The difficulties of this approach come from the complexity incurred 243 in achieving generality. The abstract language must be sufficiently 244 powerful to allow representation of the capabilities of a very 245 broad selection if switch designs. GSMP V2 has shown that 246 expressive power leads to an undesirable level of complexity in 247 this area of the protocol. In addition, the controller's task 248 becomes difficult when presented with such a protocol. The 249 controller is required to take a general description of a switch 250 and make a reliable judgement as to what services can be supported 251 by that switch. It also needs to determine how to deploy the 252 switch's resources in the most efficient manner under the 253 constraint that the services' QoS requirements are met. These 254 decisions involve significant sophistication on the part of the 255 controller. A further difficulty is that the abstract switch model 256 requires the switch to expose more of its internal design than some 257 switch manufacturers may tolerate. 259 If resource management is located in the switch then abstraction in 260 the QoS model implies generalisation of the service level QoS 261 models and parameters. In this approach similarities between the 262 service definitions of different network level services are 263 exploited in the definition of generic services and parameters. 264 Thus similar services such as ATM's Guaranteed Frame Rate and Diff- 265 Serv's Assured Forwarding, for example, might be able to share a 266 common service definition within GSMP. Alternatively, or in 267 addition to service generalisation, one might attempt to generalise 268 at the parameter level. In this way similarities between the 269 parameters of different network level services are exploited in the 270 definition of generic parameters. For example one could attempt to 271 define a peak rate parameter in GSMP that could be used for MPLS, 272 Diff-Serv, Int-Serv and ATM. 274 It is not clear how much value there in such generalisation of 275 services and parameters. If services can successfully be 276 generalised then there is a potential saving in the complexity of 277 the switch implementation since it will have fewer service 278 definitions to support. On the other hand the danger of 279 generalisation is the potential loss of semantic accuracy. 281 1.2.2 Service model 283 In a service model a set of services are defined for use in GSMP. 284 With each connection request the controller specifies one of the 285 services from the set and any traffic and/or QoS parameters that 286 may be needed. 288 Services are chosen specifically to support network level services. 289 Possible candidates for inclusion include ATM service categories 290 [7], Int-Serv Controlled Load [8] and MPLS CR-LDP QoS [10]. 291 Explicit support for differentiated services [11] may be required 292 but it is not clear yet how a label switch would support this 293 architecture. 295 In a service model the GSMP specification includes a list of 296 services in which reference is made to the pertinent specifications 297 or standards. Each service is given an identifying number to be 298 used in GSMP messages. When setting up a connection the controller 299 specifies the service required. Depending on the service, there may 300 be additional Traffic Parameters to be specified along with the 301 identification of the service. For example, if an ATM constant bit 302 rate connection is to be established then the controller would 303 specify the peak cell rate of the connection. It is then the 304 responsibility of the switch to establish the connection with the 305 requested service or reject the connection if resources do not 306 permit. 308 In a pure service model the controller has no insight into how the 309 switch implements the service. In contrast to an abstract model, 310 details such as whether or not a per connection queue is deployed 311 or the mechanisms used for cell or frame discard are completely 312 private to the switch. And in contrast to GSMP V1.1 a switch needs 313 to be designed with regard to the services that it will support. 315 As part of the GSMP port configuration the switch would report the 316 set of services that it supports on each port. 318 It is doubtful that switches will support specification of 319 arbitrary QoS parameters (e.g. delay or loss bounds) in connection 320 management message. Since this sophistication is also not typical 321 at the network layer we propose to include QoS parameters in 322 configuration messages. 324 The semantics of the Traffic Parameters in connection management 325 messages are defined by reference to the services' original 326 specifications or standards. No attempt is made to generalise 327 within the GSMP specification on the semantics of Traffic 328 Parameters for reasons outlined in Section 1.2.1. 330 1.3 Proposed QoS model 332 Above we have argued the pros and contras of: 334 - Locating resource management in the switch or in the 335 controller and 337 - Managing switch resources (abstract model) versus managing 338 services (service model). 340 These design options are not independent nor are they strictly 341 dependent. We can draw them in two dimensions to aid discussion of 342 the design space (Figure 1). 344 Location of 345 resource management 347 Switch <---> Controller 349 +-------+-------+ 350 Abstract | | | 351 ^ | A | B | 352 Management | | | | 353 model | +-------+-------+ 354 v | ...../////| 355 Service | E ..D..//C//| 356 oriented | ...../////| 357 +---------------+ 359 Figure 1 � QoS model design space 361 The first point is that there is little to be gained by blurring 362 the line between service management and abstract resource 363 management; more complicated than either of these models is one 364 that mixes elements of both. The next point, discussed in Section 365 1.2.1 above, is that in an abstract model there is a distinct 366 difference between the protocol design with resource management in 367 the switch and one with resource management in the controller. Thus 368 areas A and B in Figure 1 represent distinct approaches to the 369 design of GSMP. 371 We have argued above that any kind of abstract model comes with 372 significant problems that do not have immediately obvious 373 solutions. A service model, on the other hand, appears to be 374 workable. In the pure service model, shown in area E of Figure 1, 375 service implementation is entirely in the switch including all 376 aspects of resource management. A design in the hatched area C is 377 not possible since the switch being responsible for service 378 implementation is a contradiction of the controller explicitly 379 managing all resources. 381 The grey area D between E and C is potentially an interesting 382 compromise. Here the switch is responsible for managing unshared 383 connection resources while the controller is responsible for 384 managing the shared (multiplexed) resources. Unshared resources are 385 entities such as per connection queues, policers and traffic 386 shapers. Shared resources are basically limited to link bandwidth 387 and shared memory buffers. Before going any further we present the 388 rationale behind attempting to delineate area D. 390 The advantages of the service model outlined above were simplicity, 391 tractability in standardisation and compatibility with existing 392 switch designs. The drawbacks of resource management in the switch 393 were the difficulties incurred in the implementation of QoS routing 394 at the network layer and constrained resource sharing between 395 logical networks. A powerful compromise is therefore a service 396 model in which the controller has management of link bandwidth. 397 (While there is no direct requirement for the controller to manage 398 shared buffers this follows in some cases from the bandwidth 399 management since for some non-real time services the end-to-end 400 service requires a buffer reservation in each switch.) 402 Design spaces D and E are easily combined into one QoS model by 403 allowing the controller to optionally override the switch's 404 bandwidth and shared buffer allocation rules. The switch would 405 still have to reject connections if the unshared resources were 406 exhausted but in many switch designs this would not happen before 407 the label space is exhausted. 409 This mixed approach to resource management is practical for many 410 switches. Any switch with performance for real time service roughly 411 equivalent to an output buffered switch will be manageable for real 412 time services in this model. Non-real time services can also be 413 easily implemented whenever it can be assumed that link bandwidth 414 will be exhausted before the output shared buffer. If this cannot 415 be assumed then an alternative approach involving a simple buffer 416 CAC on the controller may be used instead. 418 2. Proposal for QoS features of GSMP 420 In this section we present an overview of the combined set of QoS 421 features we propose for GSMP. 423 GSMP should support three QoS models: 425 Service Model 426 Support of the Service Model is mandatory. 427 Support of individual Services is optional. 428 Admission control on the switch can be disabled by the 429 controller. 430 The GSMP specification will define, by reference to other 431 specs, the set of Services, their Traffic Parameters, QoS 432 Parameters and optional Traffic Controls. 434 QoS Profile Model 435 Support of the QoS Profile Model is optional. 436 The definition is taken directly from GSMP V2.0 438 Abstract Model 439 Support of the Abstract Model is optional. 440 The abstract model includes the definition of priorities 441 from GSMP V1.1. 443 Cells or frames belonging to connections in either the Abstract 444 Model or the QoS Profile Model are switched (forwarded) with lower 445 priority than cells or frames of connections with any of the 446 Services from the Service Model. The definition of priorities from 447 GSMP V1.1 should be used in this context. 449 The relationship between QoS Profiles and Abstract Model priorities 450 is undefined in GSMP. This relationship is left to the definition 451 of the semantics of the individual QoS Profiles which is outside 452 the scope of GSMP. 454 3. Service Model 456 In GSMP we propose to define, by reference to other specifications, 457 a set of Services. The Service characteristics are defined by 458 reference to the Service's Original Specification, e.g. [8], [9], 459 [10]. 461 Each Service definition in GSMP includes definition of: 463 Traffic Parameters 464 Traffic Parameter definitions are associated with Services 465 while Traffic Parameter values are associated with 466 connections. 468 Traffic Parameters quantitatively describe a connection's 469 requirements on the Service. For example, Peak Cell Rate is 470 a Traffic Parameter of the Service defined by the ATM Forum 471 Constant Bit Rate Service Category. 473 Some Traffic Parameters are mandatory and some are optional, 474 depending on the Service. 476 Semantics of Traffic Parameters are defined by reference to 477 Original Specifications. 479 QoS Parameters 480 QoS Parameters and their values are associated with 481 Services. 483 QoS Parameters express quantitative characteristics of a 484 switch's support of a Service. They include, for example, 485 quantitative bounds on switch induced loss and delay. 487 Some QoS Parameters will be mandatory and some will be 488 optional. 490 Semantics of QoS Parameters are defined by reference to 491 Original Specifications. 493 Traffic Controls 494 The implementation of some services may include the use of 495 Traffic Controls. Traffic Controls include for example 496 functions such as policing, input shaping, output shaping, 497 tagging and marking, frame vs. cell merge, frame vs. cell 498 discard. 500 Switches are not required to support Traffic Controls. Any 501 function that is always required in the implementation of a 502 Service is considered part of the Service and is not 503 considered a Traffic Control. 505 If a switch supports a Traffic Control then the control may 506 be applied either to all connections that use a given 507 Capability Set (see below) or to individual connections. 509 The definition of a Traffic Control is associated with a 510 Service. Traffic Controls are defined, as far as possible, 511 by reference to Original Specifications. 513 For each Service that a switch supports the switch must also 514 support at least one Capability Set. A Capability Set establishes 515 characteristics of a switch's implementation of a Service. It may 516 be appropriate for a switch to support more than one Capability Set 517 for a given Service. 519 A Capability Set may contain, depending on the Service definition, 520 QoS Parameter values and indication of availability of Traffic 521 Controls. 523 If a switch reports QoS Parameter values in a Capability Set then 524 these apply to all the connections that use that Capability Set. 526 For each Traffic Control defined for a given Service the switch 527 reports availability of that control as one of the following: 529 Not available in the Capability Set, 531 Applied to all connections that use the Capability Set, or 533 Available for application to connections that use the 534 Capability Set on a per connection basis. In this case a 535 controller may request application of the Traffic Control in 536 connection management messages. 538 A switch's Services and Capability Sets are reported to a 539 controller in new Service configuration messages. A response by a 540 switch to a Service configuration message includes the list of 541 Services defined for GSMP that the switch supports and, for each 542 Service, a specification of the Capability Sets supported for the 543 Service. Services are referred to by numbers standardised in the 544 GSMP specification (and approved by IANA). Capability Sets are 545 referred to by a numbering system reported by the switch. Each 546 Capability Set within a given Service includes a unique identifying 547 number together with the switch's specification of QoS Parameters 548 and Traffic Controls. 550 A switch need not support all the defined Services and Capability 551 Sets on every port. The supported Services and Capability Sets are 552 reported to the controller on a per port basis in port 553 configuration messages. Port configuration response messages list 554 the supported Services using the standardised identifying numbers 555 and the Capability Sets by using the identifying numbers 556 established in the switch Service configuration messages. 558 We do not provide a negotiation mechanism by which a controller may 559 establish or modify Capability Sets. If such a feature is required 560 then it is provided by protocols other than GSMP. 562 When a controller establishes a connection, the connection 563 management message includes indication of the Service and the 564 Capability Set. Depending on these the connection management 565 message may additionally include Traffic Parameter values and 566 Traffic Control flags. 568 A connection with a given Service can only be established if both 569 the requested Service and the requested Capability Set are 570 available on all of the connection's input and output ports. 572 The Service Model includes an optional two-stage connection set-up 573 procedure in which resource reservation and connection 574 establishment are separated. This procedure applies to add branch 575 and move branch messages. If a two-stage set-up is not required 576 then a controller may use a one-stage request message. The delete 577 branch message is used to delete either an extant branch or 578 reservation. 580 Refresh of an extant connection is permitted but the add branch 581 message requesting the message must not include indication of 582 Service, Capability Sets or Traffic Parameters. 584 An extant connection's Traffic Parameters may be changed without 585 first deleting the connection. The Service and Capability Sets of 586 an extant connection cannot be changed. Either the one stage or two 587 stage connection set-up procedure may be used to change an extant 588 connection's Traffic Parameters. 590 Move branch messages may be refused on the grounds of resource 591 depletion. In the case of a one stage set-up the connection state 592 does not change if a move branch request is thus refused. 594 A switch may support a bandwidth allocation function. If it does, a 595 controller may choose to use it or not to use it. A controller 596 indicates whether or not switch bandwidth allocation is requested 597 using a bandwidth allocation (BA) flag in connection management 598 messages. A switch indicates that it is honouring the bandwidth 599 allocation request, and thus the QoS commitments indicated in the 600 QoS of its Capability Sets, by responding with the BA flag set. If 601 the switch does not have a bandwidth allocation function then it 602 will always respond with the BA flag zeroed. If the controller ever 603 sends a request with a zeroed BA flag, the switch is not obliged to 604 honour the QoS commitments for the requested connection, other 605 extant connections or future connections. If the switch receives a 606 request with the BA flag set it must not reject the connection 607 based on a lack of bandwidth. If, after the controller has issued a 608 request with the BA flag zeroed, the switch is still able to track 609 whether or not it is honouring the QoS commitments then it may 610 indicate that QoS commitments are honoured using the BA flag in its 611 responses. The controller may poll the switch with connection 612 refresh messages to determine if the switch is still honouring QoS. 614 4. Service definitions 616 This section includes sets forth the definition of Services. Each 617 Service will be defined in its own subsection. Each Service 618 definition includes the following definitions: 620 Service Identifier 621 The reference number used to identify the Service in GSMP 622 messages. 624 Service Characteristics 625 A definition of the Service. 627 Traffic Parameters 628 A definition of the Traffic Parameters used in connection 629 management messages. 631 QoS Parameters 632 A definition of the QoS Parameters that are included in the 633 Capability Set for instances of the Service. 635 Traffic Controls 636 A definition of the Traffic Controls that may be supported 637 by an instance of the Service. 639 Descriptive text is avoided wherever possible in order to minimise 640 any possibility of semantic conflict with the Original 641 Specifications. 643 4.1 ATM Forum Service Categories 645 4.1.1 CBR 647 Service Identifier: 649 CBR.1 - Service ID = x 651 Service Characteristics: 653 Equivalent to ATM Forum CBR.1 Service, see [8]. 655 Traffic Parameters: 657 - Peak Cell Rate 659 - Cell Delay Variation Tolerance 661 QoS Parameters: 663 - Cell Loss Ratio 665 - Maximum Cell Transfer Delay 667 - Peak-to-peak Cell Delay Variation 669 Traffic Controls: 671 - Usage Parameter Control 673 - Ingress Traffic Shaping to the Peak Cell Rate 675 - Egress Traffic Shaping to the Peak Cell Rate and Cell Delay 676 Variation Tolerance 678 - Packet Discard 680 4.1.2 rt-VBR 682 Service Identifier: 684 rt-VBR.1 - Service ID = x 686 rt-VBR.2 - Service ID = x 688 rt-VBR.3 - Service ID = x 690 Service Characteristics: 692 Equivalent to ATM Forum rt-VBR Service, see [8]. 694 Traffic Parameters: 696 - Peak Cell Rate 698 - Cell Delay Variation Tolerance 700 - Sustainable Cell Rate 702 - Maximum Burst Size 704 QoS Parameters: 706 - Cell Loss Ratio 708 - Maximum Cell Transfer Delay 710 - Peak-to-peak Cell Delay Variation 712 Traffic Controls: 714 - Usage Parameter Control 716 - Ingress Traffic Shaping to the Peak Cell Rate 718 - Egress Traffic Shaping to the Peak Cell Rate and Cell Delay 719 Variation Tolerance 721 - Egress Traffic Shaping to the Sustainable Cell Rate and 722 Maximum Burst Size 724 - Packet Discard 726 4.1.3 nrt-VBR 728 Service Identifier: 730 nrt-VBR.1 - Service ID = x 732 nrt-VBR.2 - Service ID = x 734 nrt-VBR.3 - Service ID = x 736 Service Characteristics: 738 Equivalent to ATM Forum nrt-VBR Service, see [8]. 740 Traffic Parameters: 742 - Peak Cell Rate 744 - Cell Delay Variation Tolerance 746 - Sustainable Cell Rate 747 - Maximum Burst Size 749 QoS Parameter: 751 - Cell Loss Ratio 753 Traffic Controls: 755 - Usage Parameter Control 757 - Ingress Traffic Shaping to the Peak Cell Rate 759 - Egress Traffic Shaping to the Peak Cell Rate and Cell Delay 760 Variation Tolerance 762 - Egress Traffic Shaping to the Sustainable Cell Rate and 763 Maximum Burst Size 765 - Egress Traffic Shaping to the Sustainable Cell Rate and a 766 small cell delay variation tolerance. 768 - Packet Discard 770 4.1.4 UBR 772 Service Identifier: 774 UBR.1 - Service ID = x 776 UBR.2 - Service ID = x 778 Service Characteristics: 780 Equivalent to ATM Forum UBR Service, see [8]. 782 Traffic Parameters: 784 - Peak Cell Rate 786 - Cell Delay Variation Tolerance 788 QoS Parameter: 790 None 792 Traffic Controls: 794 - Usage Parameter Control 796 - Ingress Traffic Shaping to the Peak Cell Rate 797 - Egress Traffic Shaping to the Peak Cell Rate and Cell Delay 798 Variation Tolerance 800 - Selective Cell Discard 802 - Packet Discard 804 4.1.5 ABR 806 For future study. 808 4.1.6 GFR 810 Service Identifier: 812 GFR.1 - Service ID = x 814 GFR.2 - Service ID = x 816 Service Characteristics: 818 Equivalent to ATM Forum GFR Service, see [8]. 820 Traffic Parameters: 822 - Peak Cell Rate 824 - Cell Delay Variation Tolerance 826 - Minimum Cell Rate 828 - Maximum Burst Size 830 - Maximum Frame Size 832 QoS Parameter: 834 - Cell Loss Ratio 836 Traffic Controls: 838 - Usage Parameter Control 840 - Ingress Traffic Shaping to the Peak Cell Rate 842 - Egress Traffic Shaping to the Peak Cell Rate and Cell Delay 843 Variation Tolerance 845 4.2 Integrated Services 847 4.2.1 Controlled Load 849 Service Identifier: 851 Int-Serv Controlled Load - Service ID = x 853 Service Characteristics: 855 See [9]. 857 Traffic Parameters: 859 - Token bucket rate (r) 861 - Token bucket depth (b) 863 - Peak rate (p) 865 - Minimum policed unit (m) 867 - Maximum packet size (M) 869 QoS Parameter: 871 None. 873 Traffic Controls: 875 None. 877 4.3 MPLS CR-LDP QoS 879 Service Identifier: 881 MPLS CR-LDP QoS - Service ID = x 883 Service Characteristics: 885 See [10]. 887 Traffic Parameters: 889 - Peak Data Rate 891 - Peak Burst Size 893 - Committed Data Rate 895 - Committed Burst Size 896 - Excess Burst Size 898 - Weight 900 QoS Parameter: 902 - Frequency 904 Traffic Controls: 906 None currently defined. 908 4.4 Frame Relay 910 Service Identifier: 912 Frame Relay Service - Service ID = x 914 Service Characteristics: 916 Equivalent to Frame Relay Bearer Service, see [14]. 918 Traffic Parameters: 920 - Committed Information Rate 922 - Committed Burst Rate 924 - Excess Burst Rate 926 QoS Parameters: 928 None 930 Traffic Controls: 932 - Usage Parameter Control 934 - Egress Traffic Shaping to the Committed Information Rate and 935 Committed Burst Size 937 4.5 Diff-Serv 939 For future study. 941 5. Changes to GSMP messages 943 5.1 Configuration messages 945 We propose definition of a new service configuration message. The 946 controller sends a simple service configuration request. The switch 947 responds with message, which includes a sequence of zero or more 948 service configuration records. Each service configuration record 949 contains one Service Identifier and a sequence of one or more 950 Capability Set records. Each Capability Set record includes a 951 Capability Set Identifier which uniquely identifies the Capability 952 Set among those belonging to the service followed by a set of QoS 953 Parameters and Traffic Control availability indications. 955 We propose to append a list of supported Service Identifiers and 956 Capability Set Identifiers to port configuration responses. 958 5.2 Connection management messages 960 We will add flags to add branch and move branch messages to 961 indicate the type of set-up message: 963 One-stage set-up request 965 Two-stage set-up reservation request 967 Two-stage set-up commitment request 969 If Service Model QoS is to be used then the one-stage set-up 970 request and the two-stage set-up reservation request include a 971 Service Identifier, a Capability Set Identifier, Traffic Parameters 972 and Traffic Control flags. (Traffic Parameters and Traffic Control 973 flags are only applicable to Services for which they are defined.) 974 The two-stage set-up commitment request does not include this data. 976 5.3 Statistics messages 978 We propose to delete the QoS class statistics message. 980 References 982 [1] Newman, P, Edwards, W., Hinden, R., Hoffman, E. Ching Liaw, 983 F., Lyon, T. and Minshall, G., "Ipsilon's General Switch 984 Management Protocol Specification," Version 1.1, RFC 1987, 985 August 1996. 987 [2] Newman, P, Edwards, W., Hinden, R., Hoffman, E., Ching Liaw, 988 F., Lyon, T. and Minshall, G., "Ipsilon's General Switch 989 Management Protocol Specification," Version 2.0, RFC 2397, 990 March 1998. 992 [3] The ATM Forum Technical Committee, "Private Network-Network 993 Interface Specification Version 1.0," af-pnni-0055.000, Mar 994 1996. 996 [4] G. Apostolopoulos, R. Guerin, S. Kamat, A. Orda, T. 997 Przygienda and D. Williams, "QoS Routing Mechanisms and OSPF 998 Extensions", Internet-Draft, draft-guerin-qos-routing-ospf- 999 04, Dec 1998. 1001 [5] C. Villamizar, "OSPF Optimized Multipath (OSPF-OMP)", 1002 Internet-Draft, draft-ietf-ospf-omp-01, Oct 1998. 1004 [6] D. M. Yeung, "OSPF Extensions for Traffic Engineering," 1005 Internet Draft, draft-yeung-ospf-traffic-00.txt, Feb 1999. 1007 [7] ATM Forum Technical Committee, "Traffic Management 1008 Specification Version 4.0," af-tm-0056.000, Apr 1996. 1010 [8] ATM Forum Technical Committee, "Traffic Management 1011 Specification Version 4.1," af-tm-0121.000, xxx 1999. 1013 [9] J. Wroclawski, "Specification of the Controlled-Load Network 1014 Element Service," RFC2211, Sep 1997. 1016 [10] B. Jamoussi, et. al. "Constraint-Based LSP Setup using LDP," 1017 Internet Draft draft-ietf-mpls-cr-ldp-01.txt, Feb 1999. 1019 [11] S. Blake, "An Architecture for Differentiated Services," 1020 RFC2475, Dec 1998. 1022 [12] R. Gibbens, P. Kelley and P. Key, "A decision theoretic 1023 approach to call admission control in ATM networks," IEEE 1024 JSAC, Vol 13, No 6, Aug 1995. 1026 [13] S. Jamin, S. J. Shenker, P. B. Danzig, "Comparison of 1027 measurement based admission control algorithms for controlled 1028 load service," Proc INFOCOM'97, Apr 1997. 1030 [14] ITU-T Recommendation I.233 Frame Mode Bearer Services 1992.