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