Internet Draft

Internet Engineering Task Force                         Tom Worster, GDC
Internet Draft                                Fiffi Hellstrand, Ericsson
Expires: August 1999                                          Avri Doria


                            A QoS Model for GSMP

                       <draft-worster-gsmp-qos-00.txt>


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