HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 12:13:21 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Fri, 26 Feb 1999 21:14:56 GMT ETag: "2e6b51-a93e-36d70ed0" Accept-Ranges: bytes Content-Length: 43326 Connection: close Content-Type: text/plain Internet Engineering Task Force Tom Worster, GDC Internet Draft Fiffi Hellstrand, Ericsson Expires: August 1999 Avri Doria A QoS Model for GSMP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The General Switch Management Protocol [1], [2] allows low level control of a label switch. A model for the provision of quality of service must be established in order that GSMP can control the capabilities of a label switch to provide connections with specified quality of service. This memo presents some considerations surrounding the provision of QoS in such an open switch control scenario. This discussion leads to a proposal for a service oriented QoS model for GSMP. The memo also presents proposed extensions to GSMP to allow control of a switch using the Service Model. INTERNET-DRAFT A QoS Model for GSMP Feb 1999 Worster, et. al. [Page 2] Table of Contents 1. Discussion of QoS models.......................................... 2 1.1 Location of the resource manager.............................. 3 1.1.1 Resource management in the controller................... 3 1.1.2 Resource management in the switch....................... 4 1.2 Abstract versus service specific QoS models................... 5 1.2.1 Abstract models......................................... 5 1.2.2 Service model........................................... 6 1.3 Proposed QoS model............................................ 7 2. Proposal for QoS features of GSMP................................. 9 3. Service Model.................................................... 10 4. Service definitions.............................................. 13 4.1 ATM Forum Service Categories................................. 14 4.1.1 CBR.................................................... 14 4.1.2 rt-VBR................................................. 14 4.1.3 nrt-VBR................................................ 15 4.1.4 UBR.................................................... 16 4.1.5 ABR.................................................... 17 4.1.6 GFR.................................................... 17 4.2 Integrated Services.......................................... 18 4.2.1 Controlled Load........................................ 18 4.3 MPLS CR-LDP QoS.............................................. 18 4.4 Frame Relay.................................................. 19 4.5 Diff-Serv.................................................... 19 5. Changes to GSMP messages......................................... 19 5.1 Configuration messages....................................... 19 5.2 Connection management messages............................... 20 5.3 Statistics messages.......................................... 20 1. Discussion of QoS models This section presents the considerations surrounding the selection of a QoS model for GSMP. We begin this section with a brief description of GSMP applications in order to outline requirements and terminology. The GSMP allows a "controller" to control a "switch". The system of controller plus switch typically functions as a network node in a TCP/IP, ATM or Frame Relay network. Broadly speaking, the controller runs "control protocols" that provide the required network layer services such as IP routing protocols, LDP, PNNI signalling and routing, etc. The term "control plane" refers to the set of protocols and mechanisms used to support a node of one INTERNET-DRAFT A QoS Model for GSMP Feb 1999 Worster, et. al. [Page 3] network type, e.g. an ATM control plane. A controller may support multiple control planes. If the physical network supports multiple control planes then the term "logical network" is used to refer to a network as seen by one control plane. The switch is a general label switch with ATM ports and/or other label switched ports. The controller is responsible for installing and deleting connection state in the switch. It is within this context that a quality of service (QoS) model is to be established. The system of controller and switch must be able to efficiently support the QoS requirements of the relevant network technology. The functions required to support network level QoS, in particular the resource management and QoS routing, must be divided in some manner between the controller and the switch. An additional question is whether the QoS model should attempt to generalise network layer QoS or explicitly support specific network layer QoS definitions. These issues are addressed in the sections below. 1.1 Location of the resource manager In this section we present the issues surrounding the location of the resource management function with respect to GSMP: on the controller side or on the switch side. 1.1.1 Resource management in the controller. In the first model we consider, resource management is the responsibility of the controller. In GSMP the controller is responsible for management of labels and thus it is not unreasonable that the controller should manage other switch resources, such as bandwidth and buffers. The main advantage of resource management on the controller is that it gives the controller scope for considerable sophistication in the deployment of the network's resources -- particularly in the case of multiple control planes. Firstly, since the controller is fully aware of the resource allocation state of the switch it may easily tie this data into its QoS routing mechanisms. In QoS routing schemes, such as PNNI [1] and the proposed IP QoS routing protocols ([4], [5], [6]), link state advertisements propagate the information needed for selection of routes with resource reservation. With resource management in the controller, the generation of such link state information is relatively easy. Secondly, resource management in the controller facilitates sophisticated methods of resource allocation to specific logical networks. Rigid partitioning of network resources among logical networks is inefficient and difficult to administer in an INTERNET-DRAFT A QoS Model for GSMP Feb 1999 Worster, et. al. [Page 4] operational network. Full sharing of resources between control planes, on the other hand, does not allow service guarantees for individual logical networks. Thus some kind of partial or limited resource sharing is appropriate. Such resource sharing schemes with provisioned service guarantees are readily implemented if resource management is located in the controller while they are much harder to implement with resource management on the switch. The main disadvantage of putting resource management on the controller is that the controller needs to know something of the capabilities of the switch. To achieve this in a completely general fashion is very hard (this question is addressed below) but in many practical cases it is relatively easy. In particular, the class of resource management techniques based on measurements of network load (see for example [12], [13]) are well suited to controller based resource management. 1.1.2 Resource management in the switch In this model, when the controller requests a connection set-up it specifies parameters that describe the connection's QoS requirements with the request. The switch has the responsibility for determining if the connection can be accepted while supporting the QoS commitments of this and other connections and rejecting the request if it cannot. The option of locating resource management in the switch like this has the advantages that it is a familiar approach and may allow reuse of resource management software already implemented on the switch. It is also an obvious approach if one intends to split switch control between a control plane running on the switch and an external GSMP controller. This scenario is, however, not easy to handle properly with GSMP since it is essentially a multi- controller model -- GSMP does not currently make explicit provision for sharing resources with other logical networks. One of the difficulties with this approach is the lack of link state information in the controller. Even in the case of a single logical network, the controller has no a priori knowledge of what the switch is able to accept and when it will run out of resources. This problem gets still harder if the switch includes embedded control, which is accessing link resources independently of a GSMP controller. Without a mechanism for conveying link state information in GSMP to the controller there is very little the controller can do to properly support QoS routing. An additional problem lies in the provisioning of resources among logical networks. In the case that the GSMP controller is in control of all logical networks it can approximately provision resources among its logical networks. But since it does not know the exact behaviour of the switch's resource management it cannot, INTERNET-DRAFT A QoS Model for GSMP Feb 1999 Worster, et. al. [Page 5] without being overly conservative, make definite QoS commitments to any of its logical networks. In the case that the GSMP controller shares link resources with an embedded switch control there is the additional question of the mechanism by which resources are provisioned between logical networks and how, in the case that allocations may be dynamically changed, these changes are accounted for in GSMP. Only in the cases of complete resource sharing, in which QoS guarantees for logical networks cannot be made, and static resource partitioning avoid this difficulty. 1.2 Abstract versus service specific QoS models Somewhat independent of the question of location of resource management is the question of abstraction in the protocol's QoS model. When the controller requests a connection establishment it expresses the QoS requirements in some "language". The question here is whether that language should be general enough to express all possible requirements in a unified manner or whether specific dialects should be used to express the requirements of specific known services. We call the former an abstract model and an latter a service model. 1.2.1 Abstract models There are differences between the abstract model for resource management in the switch and the abstract model for resource management in the controller. (This is perhaps the first disadvantage of abstract models.) If resource management is in the controller then the controller needs to deploy abstract switch resources via GSMP. This QoS model is most in keeping with the original design of GSMP: a low level protocol for management of general switch resources with a very simple switch implementation. It is also the main QoS model used in GSMP Version 2 [2]. In order that the controller is able to deploy the switch's resources it must first be told what these resources are. Thus the first part of this abstract model is a language through which the switch expresses its capabilities. Next the controller may need to configure these resources, for example, to define scheduler weights or set thresholds, so the protocol needs an abstract configuration language. Lastly, when a connection is requested it must be assigned to the appropriate switch resources and possibly given its own parameters to control its use of the resources. The difficulties of this approach come from the complexity incurred in achieving generality. The abstract language must be sufficiently powerful to allow representation of the capabilities of a very INTERNET-DRAFT A QoS Model for GSMP Feb 1999 Worster, et. al. [Page 6] broad selection if switch designs. GSMP V2 has shown that expressive power leads to an undesirable level of complexity in this area of the protocol. In addition, the controller's task becomes difficult when presented with such a protocol. The controller is required to take a general description of a switch and make a reliable judgement as to what services can be supported by that switch. It also needs to determine how to deploy the switch's resources in the most efficient manner under the constraint that the services' QoS requirements are met. These decisions involve significant sophistication on the part of the controller. A further difficulty is that the abstract switch model requires the switch to expose more of its internal design than some switch manufacturers may tolerate. If resource management is located in the switch then abstraction in the QoS model implies generalisation of the service level QoS models and parameters. In this approach similarities between the service definitions of different network level services are exploited in the definition of generic services and parameters. Thus similar services such as ATM's Guaranteed Frame Rate and Diff- Serv's Assured Forwarding, for example, might be able to share a common service definition within GSMP. Alternatively, or in addition to service generalisation, one might attempt to generalise at the parameter level. In this way similarities between the parameters of different network level services are exploited in the definition of generic parameters. For example one could attempt to define a peak rate parameter in GSMP that could be used for MPLS, Diff-Serv, Int-Serv and ATM. It is not clear how much value there in such generalisation of services and parameters. If services can successfully be generalised then there is a potential saving in the complexity of the switch implementation since it will have fewer service definitions to support. On the other hand the danger of generalisation is the potential loss of semantic accuracy. 1.2.2 Service model In a service model a set of services are defined for use in GSMP. With each connection request the controller specifies one of the services from the set and any traffic and/or QoS parameters that may be needed. Services are chosen specifically to support network level services. Possible candidates for inclusion include ATM service categories [7], Int-Serv Controlled Load [8] and MPLS CR-LDP QoS [10]. Explicit support for differentiated services [11] may be required but it is not clear yet how a label switch would support this architecture. INTERNET-DRAFT A QoS Model for GSMP Feb 1999 Worster, et. al. [Page 7] In a service model the GSMP specification includes a list of services in which reference is made to the pertinent specifications or standards. Each service is given an identifying number to be used in GSMP messages. When setting up a connection the controller specifies the service required. Depending on the service, there may be additional Traffic Parameters to be specified along with the identification of the service. For example, if an ATM constant bit rate connection is to be established then the controller would specify the peak cell rate of the connection. It is then the responsibility of the switch to establish the connection with the requested service or reject the connection if resources do not permit. In a pure service model the controller has no insight into how the switch implements the service. In contrast to an abstract model, details such as whether or not a per connection queue is deployed or the mechanisms used for cell or frame discard are completely private to the switch. And in contrast to GSMP V1.1 a switch needs to be designed with regard to the services that it will support. As part of the GSMP port configuration the switch would report the set of services that it supports on each port. It is doubtful that switches will support specification of arbitrary QoS parameters (e.g. delay or loss bounds) in connection management message. Since this sophistication is also not typical at the network layer we propose to include QoS parameters in configuration messages. The semantics of the Traffic Parameters in connection management messages are defined by reference to the services' original specifications or standards. No attempt is made to generalise within the GSMP specification on the semantics of Traffic Parameters for reasons outlined in Section 1.2.1. 1.3 Proposed QoS model Above we have argued the pros and contras of: - Locating resource management in the switch or in the controller and - Managing switch resources (abstract model) versus managing services (service model). These design options are not independent nor are they strictly dependent. We can draw them in two dimensions to aid discussion of the design space (Figure 1). INTERNET-DRAFT A QoS Model for GSMP Feb 1999 Worster, et. al. [Page 8] Location of resource management Switch <---> Controller +-------+-------+ Abstract | | | ^ | A | B | Management | | | | model | +-------+-------+ v | ...../////| Service | E ..D..//C//| oriented | ...../////| +---------------+ Figure 1 ­ QoS model design space The first point is that there is little to be gained by blurring the line between service management and abstract resource management; more complicated than either of these models is one that mixes elements of both. The next point, discussed in Section 1.2.1 above, is that in an abstract model there is a distinct difference between the protocol design with resource management in the switch and one with resource management in the controller. Thus areas A and B in Figure 1 represent distinct approaches to the design of GSMP. We have argued above that any kind of abstract model comes with significant problems that do not have immediately obvious solutions. A service model, on the other hand, appears to be workable. In the pure service model, shown in area E of Figure 1, service implementation is entirely in the switch including all aspects of resource management. A design in the hatched area C is not possible since the switch being responsible for service implementation is a contradiction of the controller explicitly managing all resources. The grey area D between E and C is potentially an interesting compromise. Here the switch is responsible for managing unshared connection resources while the controller is responsible for managing the shared (multiplexed) resources. Unshared resources are entities such as per connection queues, policers and traffic shapers. Shared resources are basically limited to link bandwidth and shared memory buffers. Before going any further we present the rationale behind attempting to delineate area D. The advantages of the service model outlined above were simplicity, tractability in standardisation and compatibility with existing switch designs. The drawbacks of resource management in the switch INTERNET-DRAFT A QoS Model for GSMP Feb 1999 Worster, et. al. [Page 9] were the difficulties incurred in the implementation of QoS routing at the network layer and constrained resource sharing between logical networks. A powerful compromise is therefore a service model in which the controller has management of link bandwidth. (While there is no direct requirement for the controller to manage shared buffers this follows in some cases from the bandwidth management since for some non-real time services the end-to-end service requires a buffer reservation in each switch.) Design spaces D and E are easily combined into one QoS model by allowing the controller to optionally override the switch's bandwidth and shared buffer allocation rules. The switch would still have to reject connections if the unshared resources were exhausted but in many switch designs this would not happen before the label space is exhausted. This mixed approach to resource management is practical for many switches. Any switch with performance for real time service roughly equivalent to an output buffered switch will be manageable for real time services in this model. Non-real time services can also be easily implemented whenever it can be assumed that link bandwidth will be exhausted before the output shared buffer. If this cannot be assumed then an alternative approach involving a simple buffer CAC on the controller may be used instead. 2. Proposal for QoS features of GSMP In this section we present an overview of the combined set of QoS features we propose for GSMP. GSMP should support three QoS models: Service Model Support of the Service Model is mandatory. Support of individual Services is optional. Admission control on the switch can be disabled by the controller. The GSMP specification will define, by reference to other specs, the set of Services, their Traffic Parameters, QoS Parameters and optional Traffic Controls. QoS Profile Model Support of the QoS Profile Model is optional. The definition is taken directly from GSMP V2.0 Abstract Model Support of the Abstract Model is optional. The abstract model includes the definition of priorities from GSMP V1.1. INTERNET-DRAFT A QoS Model for GSMP Feb 1999 Worster, et. al. [Page 10] Cells or frames belonging to connections in either the Abstract Model or the QoS Profile Model are switched (forwarded) with lower priority than cells or frames of connections with any of the Services from the Service Model. The definition of priorities from GSMP V1.1 should be used in this context. The relationship between QoS Profiles and Abstract Model priorities is undefined in GSMP. This relationship is left to the definition of the semantics of the individual QoS Profiles which is outside the scope of GSMP. 3. Service Model In GSMP we propose to define, by reference to other specifications, a set of Services. The Service characteristics are defined by reference to the Service's Original Specification, e.g. [8], [9], [10]. Each Service definition in GSMP includes definition of: Traffic Parameters Traffic Parameter definitions are associated with Services while Traffic Parameter values are associated with connections. Traffic Parameters quantitatively describe a connection's requirements on the Service. For example, Peak Cell Rate is a Traffic Parameter of the Service defined by the ATM Forum Constant Bit Rate Service Category. Some Traffic Parameters are mandatory and some are optional, depending on the Service. Semantics of Traffic Parameters are defined by reference to Original Specifications. QoS Parameters QoS Parameters and their values are associated with Services. QoS Parameters express quantitative characteristics of a switch's support of a Service. They include, for example, quantitative bounds on switch induced loss and delay. Some QoS Parameters will be mandatory and some will be optional. Semantics of QoS Parameters are defined by reference to Original Specifications. INTERNET-DRAFT A QoS Model for GSMP Feb 1999 Worster, et. al. [Page 11] Traffic Controls The implementation of some services may include the use of Traffic Controls. Traffic Controls include for example functions such as policing, input shaping, output shaping, tagging and marking, frame vs. cell merge, frame vs. cell discard. Switches are not required to support Traffic Controls. Any function that is always required in the implementation of a Service is considered part of the Service and is not considered a Traffic Control. If a switch supports a Traffic Control then the control may be applied either to all connections that use a given Capability Set (see below) or to individual connections. The definition of a Traffic Control is associated with a Service. Traffic Controls are defined, as far as possible, by reference to Original Specifications. For each Service that a switch supports the switch must also support at least one Capability Set. A Capability Set establishes characteristics of a switch's implementation of a Service. It may be appropriate for a switch to support more than one Capability Set for a given Service. A Capability Set may contain, depending on the Service definition, QoS Parameter values and indication of availability of Traffic Controls. If a switch reports QoS Parameter values in a Capability Set then these apply to all the connections that use that Capability Set. For each Traffic Control defined for a given Service the switch reports availability of that control as one of the following: Not available in the Capability Set, Applied to all connections that use the Capability Set, or Available for application to connections that use the Capability Set on a per connection basis. In this case a controller may request application of the Traffic Control in connection management messages. A switch's Services and Capability Sets are reported to a controller in new Service configuration messages. A response by a switch to a Service configuration message includes the list of Services defined for GSMP that the switch supports and, for each Service, a specification of the Capability Sets supported for the Service. Services are referred to by numbers standardised in the INTERNET-DRAFT A QoS Model for GSMP Feb 1999 Worster, et. al. [Page 12] GSMP specification (and approved by IANA). Capability Sets are referred to by a numbering system reported by the switch. Each Capability Set within a given Service includes a unique identifying number together with the switch's specification of QoS Parameters and Traffic Controls. A switch need not support all the defined Services and Capability Sets on every port. The supported Services and Capability Sets are reported to the controller on a per port basis in port configuration messages. Port configuration response messages list the supported Services using the standardised identifying numbers and the Capability Sets by using the identifying numbers established in the switch Service configuration messages. We do not provide a negotiation mechanism by which a controller may establish or modify Capability Sets. If such a feature is required then it is provided by protocols other than GSMP. When a controller establishes a connection, the connection management message includes indication of the Service and the Capability Set. Depending on these the connection management message may additionally include Traffic Parameter values and Traffic Control flags. A connection with a given Service can only be established if both the requested Service and the requested Capability Set are available on all of the connection's input and output ports. The Service Model includes an optional two-stage connection set-up procedure in which resource reservation and connection establishment are separated. This procedure applies to add branch and move branch messages. If a two-stage set-up is not required then a controller may use a one-stage request message. The delete branch message is used to delete either an extant branch or reservation. Refresh of an extant connection is permitted but the add branch message requesting the message must not include indication of Service, Capability Sets or Traffic Parameters. An extant connection's Traffic Parameters may be changed without first deleting the connection. The Service and Capability Sets of an extant connection cannot be changed. Either the one stage or two stage connection set-up procedure may be used to change an extant connection's Traffic Parameters. Move branch messages may be refused on the grounds of resource depletion. In the case of a one stage set-up the connection state does not change if a move branch request is thus refused. INTERNET-DRAFT A QoS Model for GSMP Feb 1999 Worster, et. al. [Page 13] A switch may support a bandwidth allocation function. If it does, a controller may choose to use it or not to use it. A controller indicates whether or not switch bandwidth allocation is requested using a bandwidth allocation (BA) flag in connection management messages. A switch indicates that it is honouring the bandwidth allocation request, and thus the QoS commitments indicated in the QoS of its Capability Sets, by responding with the BA flag set. If the switch does not have a bandwidth allocation function then it will always respond with the BA flag zeroed. If the controller ever sends a request with a zeroed BA flag, the switch is not obliged to honour the QoS commitments for the requested connection, other extant connections or future connections. If the switch receives a request with the BA flag set it must not reject the connection based on a lack of bandwidth. If, after the controller has issued a request with the BA flag zeroed, the switch is still able to track whether or not it is honouring the QoS commitments then it may indicate that QoS commitments are honoured using the BA flag in its responses. The controller may poll the switch with connection refresh messages to determine if the switch is still honouring QoS. 4. Service definitions This section includes sets forth the definition of Services. Each Service will be defined in its own subsection. Each Service definition includes the following definitions: Service Identifier The reference number used to identify the Service in GSMP messages. Service Characteristics A definition of the Service. Traffic Parameters A definition of the Traffic Parameters used in connection management messages. QoS Parameters A definition of the QoS Parameters that are included in the Capability Set for instances of the Service. Traffic Controls A definition of the Traffic Controls that may be supported by an instance of the Service. Descriptive text is avoided wherever possible in order to minimise any possibility of semantic conflict with the Original Specifications. INTERNET-DRAFT A QoS Model for GSMP Feb 1999 Worster, et. al. [Page 14] 4.1 ATM Forum Service Categories 4.1.1 CBR Service Identifier: CBR.1 - Service ID = x Service Characteristics: Equivalent to ATM Forum CBR.1 Service, see [8]. Traffic Parameters: - Peak Cell Rate - Cell Delay Variation Tolerance QoS Parameters: - Cell Loss Ratio - Maximum Cell Transfer Delay - Peak-to-peak Cell Delay Variation Traffic Controls: - Usage Parameter Control - Ingress Traffic Shaping to the Peak Cell Rate - Egress Traffic Shaping to the Peak Cell Rate and Cell Delay Variation Tolerance - Packet Discard 4.1.2 rt-VBR Service Identifier: rt-VBR.1 - Service ID = x rt-VBR.2 - Service ID = x rt-VBR.3 - Service ID = x Service Characteristics: Equivalent to ATM Forum rt-VBR Service, see [8]. Traffic Parameters: INTERNET-DRAFT A QoS Model for GSMP Feb 1999 Worster, et. al. [Page 15] - Peak Cell Rate - Cell Delay Variation Tolerance - Sustainable Cell Rate - Maximum Burst Size QoS Parameters: - Cell Loss Ratio - Maximum Cell Transfer Delay - Peak-to-peak Cell Delay Variation Traffic Controls: - Usage Parameter Control - Ingress Traffic Shaping to the Peak Cell Rate - Egress Traffic Shaping to the Peak Cell Rate and Cell Delay Variation Tolerance - Egress Traffic Shaping to the Sustainable Cell Rate and Maximum Burst Size - Packet Discard 4.1.3 nrt-VBR Service Identifier: nrt-VBR.1 - Service ID = x nrt-VBR.2 - Service ID = x nrt-VBR.3 - Service ID = x Service Characteristics: Equivalent to ATM Forum nrt-VBR Service, see [8]. Traffic Parameters: - Peak Cell Rate - Cell Delay Variation Tolerance - Sustainable Cell Rate INTERNET-DRAFT A QoS Model for GSMP Feb 1999 Worster, et. al. [Page 16] - Maximum Burst Size QoS Parameter: - Cell Loss Ratio Traffic Controls: - Usage Parameter Control - Ingress Traffic Shaping to the Peak Cell Rate - Egress Traffic Shaping to the Peak Cell Rate and Cell Delay Variation Tolerance - Egress Traffic Shaping to the Sustainable Cell Rate and Maximum Burst Size - Egress Traffic Shaping to the Sustainable Cell Rate and a small cell delay variation tolerance. - Packet Discard 4.1.4 UBR Service Identifier: UBR.1 - Service ID = x UBR.2 - Service ID = x Service Characteristics: Equivalent to ATM Forum UBR Service, see [8]. Traffic Parameters: - Peak Cell Rate - Cell Delay Variation Tolerance QoS Parameter: None Traffic Controls: - Usage Parameter Control - Ingress Traffic Shaping to the Peak Cell Rate INTERNET-DRAFT A QoS Model for GSMP Feb 1999 Worster, et. al. [Page 17] - Egress Traffic Shaping to the Peak Cell Rate and Cell Delay Variation Tolerance - Selective Cell Discard - Packet Discard 4.1.5 ABR For future study. 4.1.6 GFR Service Identifier: GFR.1 - Service ID = x GFR.2 - Service ID = x Service Characteristics: Equivalent to ATM Forum GFR Service, see [8]. Traffic Parameters: - Peak Cell Rate - Cell Delay Variation Tolerance - Minimum Cell Rate - Maximum Burst Size - Maximum Frame Size QoS Parameter: - Cell Loss Ratio Traffic Controls: - Usage Parameter Control - Ingress Traffic Shaping to the Peak Cell Rate - Egress Traffic Shaping to the Peak Cell Rate and Cell Delay Variation Tolerance INTERNET-DRAFT A QoS Model for GSMP Feb 1999 Worster, et. al. [Page 18] 4.2 Integrated Services 4.2.1 Controlled Load Service Identifier: Int-Serv Controlled Load - Service ID = x Service Characteristics: See [9]. Traffic Parameters: - Token bucket rate (r) - Token bucket depth (b) - Peak rate (p) - Minimum policed unit (m) - Maximum packet size (M) QoS Parameter: None. Traffic Controls: None. 4.3 MPLS CR-LDP QoS Service Identifier: MPLS CR-LDP QoS - Service ID = x Service Characteristics: See [10]. Traffic Parameters: - Peak Data Rate - Peak Burst Size - Committed Data Rate - Committed Burst Size INTERNET-DRAFT A QoS Model for GSMP Feb 1999 Worster, et. al. [Page 19] - Excess Burst Size - Weight QoS Parameter: - Frequency Traffic Controls: None currently defined. 4.4 Frame Relay Service Identifier: Frame Relay Service - Service ID = x Service Characteristics: Equivalent to Frame Relay Bearer Service, see [14]. Traffic Parameters: - Committed Information Rate - Committed Burst Rate - Excess Burst Rate QoS Parameters: None Traffic Controls: - Usage Parameter Control - Egress Traffic Shaping to the Committed Information Rate and Committed Burst Size 4.5 Diff-Serv For future study. 5. Changes to GSMP messages 5.1 Configuration messages We propose definition of a new service configuration message. The controller sends a simple service configuration request. The switch INTERNET-DRAFT A QoS Model for GSMP Feb 1999 Worster, et. al. [Page 20] responds with message, which includes a sequence of zero or more service configuration records. Each service configuration record contains one Service Identifier and a sequence of one or more Capability Set records. Each Capability Set record includes a Capability Set Identifier which uniquely identifies the Capability Set among those belonging to the service followed by a set of QoS Parameters and Traffic Control availability indications. We propose to append a list of supported Service Identifiers and Capability Set Identifiers to port configuration responses. 5.2 Connection management messages We will add flags to add branch and move branch messages to indicate the type of set-up message: One-stage set-up request Two-stage set-up reservation request Two-stage set-up commitment request If Service Model QoS is to be used then the one-stage set-up request and the two-stage set-up reservation request include a Service Identifier, a Capability Set Identifier, Traffic Parameters and Traffic Control flags. (Traffic Parameters and Traffic Control flags are only applicable to Services for which they are defined.) The two-stage set-up commitment request does not include this data. 5.3 Statistics messages We propose to delete the QoS class statistics message. References [1] Newman, P, Edwards, W., Hinden, R., Hoffman, E. Ching Liaw, F., Lyon, T. and Minshall, G., "Ipsilon's General Switch Management Protocol Specification," Version 1.1, RFC 1987, August 1996. [2] Newman, P, Edwards, W., Hinden, R., Hoffman, E., Ching Liaw, F., Lyon, T. and Minshall, G., "Ipsilon's General Switch Management Protocol Specification," Version 2.0, RFC 2397, March 1998. [3] The ATM Forum Technical Committee, "Private Network-Network Interface Specification Version 1.0," af-pnni-0055.000, Mar 1996. [4] G. Apostolopoulos, R. Guerin, S. Kamat, A. Orda, T. Przygienda and D. Williams, "QoS Routing Mechanisms and OSPF INTERNET-DRAFT A QoS Model for GSMP Feb 1999 Worster, et. al. [Page 21] Extensions", Internet-Draft, draft-guerin-qos-routing-ospf- 04, Dec 1998. [5] C. Villamizar, "OSPF Optimized Multipath (OSPF-OMP)", Internet-Draft, draft-ietf-ospf-omp-01, Oct 1998. [6] D. M. Yeung, "OSPF Extensions for Traffic Engineering," Internet Draft, draft-yeung-ospf-traffic-00.txt, Feb 1999. [7] ATM Forum Technical Committee, "Traffic Management Specification Version 4.0," af-tm-0056.000, Apr 1996. [8] ATM Forum Technical Committee, "Traffic Management Specification Version 4.1," af-tm-0121.000, xxx 1999. [9] J. Wroclawski, "Specification of the Controlled-Load Network Element Service," RFC2211, Sep 1997. [10] B. Jamoussi, et. al. "Constraint-Based LSP Setup using LDP," Internet Draft draft-ietf-mpls-cr-ldp-01.txt, Feb 1999. [11] S. Blake, "An Architecture for Differentiated Services," RFC2475, Dec 1998. [12] R. Gibbens, P. Kelley and P. Key, "A decision theoretic approach to call admission control in ATM networks," IEEE JSAC, Vol 13, No 6, Aug 1995. [13] S. Jamin, S. J. Shenker, P. B. Danzig, "Comparison of measurement based admission control algorithms for controlled load service," Proc INFOCOM'97, Apr 1997. [14] ITU-T Recommendation I.233 Frame Mode Bearer Services 1992. INTERNET-DRAFT A QoS Model for GSMP Feb 1999