Internet DRAFT - draft-evans-gsmp-qos-framework
draft-evans-gsmp-qos-framework
Internet Engineering Task Force Parasuram Ranganathan
Internet-Draft Deepak Sreenivasamurthy
Joseph Evans
Expires June 1999 ITTC, University of Kansas
Arvind Kaushal
Sprint Corporation
December 1998
A framework for QoS support for open control
<draft-evans-gsmp-qos-framework-00.txt>
Status of this Memo
This document is an Internet-Draft. 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 draft documents are valid for a maximum of
six months and may be updated, replaced, or obsolete 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."
To view the entire list of current Internet-Drafts, please
check the "1id-abstracts.txt" listing contained in the
Internet-Drafts Shadow Directories on ftp.is.co.za (Africa),
ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern
Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East
Coast), or ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited.
Abstract
This memo specifies a framework for developing a service type
based QoS message class for open control of network elements.
The proposed framework supports the use of alternative control
interfaces for controlling the network elements. The framework is
applied to ATM Forum services, Integrated Services (intserv) and
Differentiated Services (diffserv) to depict the feasibility of
the approach.
Ranganathan, et. al. Expires: June 1999 [Page 1]
INTERNET-DRAFT draft-ietf-gsmp-qos-framework-00.txt December 1998
Table of Contents
Status of this Memo 1
Abstract 1
1. Introduction 2
2. Framework for QoS support 3
2.1 Extension to Connection Management messages 3
2.1.1 Service Type Failure 4
2.2 QoS Configuration Messages 4
2.2.1 QoS Failures 6
3. Interface support for non-standard/experimental services 6
3.1 Specifying a general parameter set 6
3.2 Interface for functional units in a network element 7
4. The Control Information Base (CIB) 9
4.1 Structure of CIB definitions 9
4.2 Sample CIB Definitions 10
4.2.1 intserv Controlled Load Service CIB definition 10
4.2.2 diffserv EF PHB Service CIB definition 11
4.2.3 ATMF rt_VBR Service CIB definition 12
4.2.4 CIB definition for general parameter set 12
4.2.5 CIB definition for functional units 13
5. Conclusion 14
6. Security considerations 14
7. References 14
Appendix A : Framework applied to Integrated Services 15
Appendix B : Framework applied to Differentiated Services 17
Appendix C : Framework Applied to ATM Forum services 19
Authors' Contact 21
1. Introduction
A typical open control API can be conceived as being composed of
the following set of message classes
- Connection Management messages are used to establish, modify
and delete connections across network elements.
- Interface Management messages are used for controlling
state of network element interfaces such as ports and
configuring them.
- Statistics messages are used for obtaining statistics of
interfaces, connections and the network element.
- Synchronization messages are used for achieving
synchronization between the controller and the network element.
- Alarm messages are used for informing controller of
asynchronous traps generated at the network element.
Ranganathan, et. al. Expires: June 1999 [Page 2]
INTERNET-DRAFT draft-ietf-gsmp-qos-framework-00.txt December 1998
- Quality of Service messages are used for supporting varied
service types with specific traffic and QoS requirements.
Currently proposed and available open control APIs are master-slave
protocols with the controller as the master and the network element
being the slave. Open control API are typically employed when
control architectures operate external to the network element and
require a means of controlling the network element hardware.
2. Framework for QoS support
2.1 Extension to Connection Management messages
Connection Management messages are used by the controller to
establish, delete, modify and verify connections across the network
element. The proposed framework appends QoS service type to
Connection Establishment Request messages and also a QoS indicator
flag to indicate that QoS configuration messages will follow the
Connection Establishment message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Connection Establishment Request Message |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q|N| Reserved | Service Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Q flag
Quality of Service indicator bit to indicate that a QoS message
will follow the Connection Establishment Request message if
the Service Type is supported
N flag
Non-usage of proposed QoS framework indicator. Setting this bit
provides flexibility to employ alternate interfaces for
control, with the assumption that the controller and the
network element have support for these interfaces.
Service Type
Services such as ATM Forum Services, MPLS, intserv, diffserv
are assigned numerical values for Service Types.
Ranganathan, et. al. Expires: June 1999 [Page 3]
INTERNET-DRAFT draft-ietf-gsmp-qos-framework-00.txt December 1998
The reserved fields in the Connection Establishment message may be
used to indicate the Service Type and QoS control flags.
2.1.1 Service Type Failure
Failure of the network element to identify a service type needs to
be incorporated as an additional failure code in the Connection
Establishment Response message.
2.2 QoS Configuration Messages
These are a set of Request/Response messages to handle QoS
requirements of various services. The QoS Request/Response message
format is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control API Message Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Class | QoS Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Parameter 1 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Parameter 2 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Parameter n .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Class
The class of service with a defined set of QoS parameters for
the service type specified in the Connection Establishment
message.
Ranganathan, et. al. Expires: June 1999 [Page 4]
INTERNET-DRAFT draft-ietf-gsmp-qos-framework-00.txt December 1998
QoS Flags
+-+-+-+-+-+-+-+-+
|M|T|X|X|X|X|X|X| X - unused
+-+-+-+-+-+-+-+-+
M
More Bit indicating that more QoS parameters for the same
service class are in successive messages when the QoS
configuration messages are limited by the MTU of the
control API.
T
Setting the T bit indicates that the QoS parameters are in
the form of TLVs. If the T bit is 0, a pre-determined QoS
structure is assumed for the service class.
Reserved
Field currently not used
If QoS parameters are being specified as TLVs, the Parameter fields
in the QoS Configuration messages have the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Parameter Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ... |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type
The QoS parameter type as defined in the Control Information
Base(CIB) (Section 4).
Parameter Length
Indicates the length of the Parameter Value in bytes.
Parameter Value
The Actual QoS parameter value.
Ranganathan, et. al. Expires: June 1999 [Page 5]
INTERNET-DRAFT draft-ietf-gsmp-qos-framework-00.txt December 1998
S flag
Indicates that the parameter specified by the parameter type is
structured. The Length field provides the length of the
complete structure and the Value field consist of individual
elements of the structure also in similar format. Multiple
such nesting of TLVs is permitted.
Specifying QoS parameters as TLVs are useful when all parameters are
not provided by the application and default values are assumed by
the control architecture. When the service class QoS definition
involves a large number of parameters and most of them are being set
to default values, employing TLVs to share QoS information between
the controller and the network element can prove to be more
efficient than employing pre-determined structures.
2.2.1 QoS Failures
The following QoS failures need to be incorporated as failure codes
in QoS configuration messages.
- Unknown/Invalid Service Class
- Invalid QoS parameter type
- QoS value is out of range
- Insufficient QoS resources for the specified service
- No predetermined QoS structure defined for specified service
class(When T is not set)
3. Interface support for non-standard/experimental services
3.1 Specifying a general parameter set
In this framework, for services not directly supported by the
network element, we suggest a general set of parameters that are
grouped under a reserved service type 100. In the QoS configuration
message, the service class field is unused and the parameters are
passed as TLVs. The parameter types for these general set of
parameters are also defined in the Control Information Base.
For instance, let us consider an experimental service characterized
by specifying the peak rate . We employ the "peak rate parameter"
specified in the general parameter set for controlling the network
element to support the desired service as shown below.
In the Connection Establishment message of the control API,
Service type = 100
Ranganathan, et. al. Expires: June 1999 [Page 6]
INTERNET-DRAFT draft-ietf-gsmp-qos-framework-00.txt December 1998
The QoS configuration message has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control API Message Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 |0|1|x|x|x|x|x|x| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 0x01 | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| peak rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The parameter type specified in the above message is based on sample
CIB definitions given in Section 4.2.4. The T bit must be set to 1
when the general parameter set is used.
3.2 Interface for functional units in a network element
If the desired service cannot be supported employing the standard
service type/service class template or using the general parameter
set, the following approach of providing a direct control interface
to the functional entities on the network element is suggested.
Such a model-based approach [1] provides an efficient method to map
QoS parameters specified by the control architecture to functional
units on the network element, however with the increased mapping
overhead and possible inaccuracy of the mapping due to limited
knowledge of the hardware. Further, supporting such an interface
seems to be important for the evolution of flexible control.
The use of this approach is indicated in the Connection
Establishment message by setting the service type field to 150.
The service class field in the QoS configuration message is used to
indicate the functional unit being controlled such as a policer,
shaper, scheduler and so on. The parameters affecting the operation
of the functional unit are specified as parameters in the QoS
configuration message. Flags for controlling the functional units
may be grouped into bytes and treated as control parameters. The
structure of these parameters need to be provided by the vendor
along with the IDs in the proprietary CIBs.
For instance, a simple GCRA based policer is chosen as the
functional unit to be controlled in the following example.
In the Connection Establishment message, the service type is set to 150.
Ranganathan, et. al. Expires: June 1999 [Page 7]
INTERNET-DRAFT draft-ietf-gsmp-qos-framework-00.txt December 1998
The QoS configuration message is as shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control API Message Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x05 |0|1|x|x|x|x|x|x| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 0x01 | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Increment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 0x02 | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 0x03 | 0x01 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|flag parameter |
+-+-+-+-+-+-+-+-+
The service class and parameter type fields are given based on the
CIB definition in Section 4.2.5.
The flag parameter structure for the policer may be as follows:
+-+-+-+-+-+-+-+-+
|M|D|X|X|X|X|X|X| X - unused
+-+-+-+-+-+-+-+-+
M flag
Setting this bit informs the policer to mark the non-conforming
packets. If M bit is 0, then the non-conforming packets are
discarded.
D flag
Domain of policing bit. Setting this bit indicates that
policing function is applied to all packets. If the D bit is
0 only unmarked packets are policed.
Ranganathan, et. al. Expires: June 1999 [Page 8]
INTERNET-DRAFT draft-ietf-gsmp-qos-framework-00.txt December 1998
4. The Control Information Base (CIB)
This serves as an information base for
- all QoS parameter types
- service class and service type for standard services
- functional unit types
The CIB definitions are given in ASN.1 notation based on the
hierarchical tree below.
Abstract Service Super Class
|
|
V
Service Type
|
|
V
Service Class
|
|
V
Parameter Type
|
|
V
Parameter Type
(optional - Specified if corresponding superclass is a structure)
The CIB definitions for all known standard services need to be
standardized.
4.1 Structure of CIB definitions
<controlled_element> ELEMENT_TYPE
SYNTAX <syntax>
STATUS <status>
DESCRIPTION <description>
::= { <super_class> <element_identifier> }
Controlled elements can correspond to service type, service class
or parameter type. The <controlled_element> and the <super_class>
fields hold variables reflecting these controlled elements. All
service types are grouped under an abstract superclass named
"service".
Ranganathan, et. al. Expires: June 1999 [Page 9]
INTERNET-DRAFT draft-ietf-gsmp-qos-framework-00.txt December 1998
The <syntax> indicates the nature of the controlled element,
namely, service_type, service_class, structured_parameter,
int_parameter, float_parameter, double_parameter and so on.
The <status> can be mandatory or optional depending on the parameter
type for the corresponding service. The <status> field is defined as
"non_applicable" when the controlled elements are either service
class, service type or functional units.
The <description> provides a brief description of the controlled
element.
The <element_identifier> provides an ID to the controlled element by
which it is specified in messages of the open control interface.
4.2 Sample CIB Definitions
A few sample CIB definitions for ATMF rt_VBR Service, intserv
controlled load service, diffserv EF PHB service, the general
parameter set and functional units are given below.
4.2.1 intserv Controlled Load Service CIB definition
The service type definition is as follows:
intserv ELEMENT_TYPE
SYNTAX service_type
STATUS non_applicable
DESCRIPTION "Integrated Services - intserv"
::= { service 2 }
The Controlled Load service class definition is as follows:
controlled_load ELEMENT_TYPE
SYNTAX service_class
STATUS non_applicable
DESCRIPTION "Controlled Load service"
::= { intserv 5 }
A typical parameter definition may be as follows:
token_bucket_tspec ELEMENT_TYPE
SYNTAX structured_parameter
STATUS mandatory
DESCRIPTION "Token Bucket Parameter for Controlled Load Service"
::= { controlled_load 127 }
The element_identifiers for all parameters defined WITHIN the
token_bucket_tspec are given below
Ranganathan, et. al. Expires: June 1999 [Page 10]
INTERNET-DRAFT draft-ietf-gsmp-qos-framework-00.txt December 1998
Parameter element_identifier
Token Rate [r] 1
Bucket Depth [b] 2
Peak Traffic Rate [p] 3
Minimum Policed Unit [m] 4
Maximum Packet Size [M] 5
It should be noted that the scope of these element_identifiers is
limited to the token_bucket_tspec. For instance, another parameter
with element_identifier equal to 1 may be specified for the same
service.
4.2.2 diffserv EF PHB Service CIB definition
The service type definition is as follows:
diffserv ELEMENT_TYPE
SYNTAX service_type
STATUS non_applicable
DESCRIPTION "Differentiated Services - diffserv"
::= { service 3 }
The EF PHB class definition is as follows:
ef_phb ELEMENT_TYPE
SYNTAX service_class
STATUS non_applicable
DESCRIPTION "Expedited Forwarding Per-Hop Behavior"
::= { diffserv 184 }
Typical parameter definitions may be as follows:
conf_min_rate ELEMENT_TYPE
SYNTAX float_parameter
STATUS mandatory
DESCRIPTION "Configured Minimum Rate for traffic leaving a
diffserv node"
::= { ef_phb 1 }
max_ef_rate ELEMENT_TYPE
SYNTAX float_parameter
STATUS optional
DESCRIPTION "Maximum Rate characterizing a token
bucket rate limiter"
::= { ef_phb 2 }
Ranganathan, et. al. Expires: June 1999 [Page 11]
INTERNET-DRAFT draft-ietf-gsmp-qos-framework-00.txt December 1998
4.2.3 ATMF rt_VBR Service CIB definition
The service type definition is as follows:
atmf ELEMENT_TYPE
SYNTAX service_type
STATUS non_applicable
DESCRIPTION "Services defined by ATM Forum"
::= { service 1 }
The rt_VBR service class definition is as follows:
rt_vbr ELEMENT_TYPE
SYNTAX service_class
STATUS non_applicable
DESCRIPTION "Real Time VBR service"
::= { atmf 2 }
A typical parameter definition may be as follows:
pcr_allcells ELEMENT_TYPE
SYNTAX float_parameter
STATUS mandatory
DESCRIPTION "Peak Cell Rate for all cells, tagged or untagged"
::= { rt_vbr 1 }
The other parameters are defined in a similar manner. The
element_identifiers for all parameters that may be specified in
rt_VBR service are given below
Parameter element_identifier
Peak Cell Rate (CLP=0+1) 1
Peak Cell Rate (CLP=0) 2
Sustainable Cell Rate (CLP=0+1) 3
Sustainable Cell Rate (CLP=0) 4
Maximum Burst Size (CLP=0+1) 5
Maximum Burst Size (CLP=0) 6
4.2.4 CIB definition for general parameter set
These may be proprietary CIBs provided by the vendor of the network
element.
The service type definition is as follows:
general_param ELEMENT_TYPE
SYNTAX service_type
STATUS non_applicable
DESCRIPTION "Indicator for using general parameter set"
::= { service 100 }
Ranganathan, et. al. Expires: June 1999 [Page 12]
INTERNET-DRAFT draft-ietf-gsmp-qos-framework-00.txt December 1998
A typical parameter definition may be as follows:
peak_rate ELEMENT_TYPE
SYNTAX float_parameter
STATUS mandatory
DESCRIPTION "Acceptable Peak Rate of service traffic"
::= { general_param 1 }
4.2.5 CIB definition for functional units
These may be proprietary CIBs provided by the vendor of the network
element.
The service type definition is as follows:
element_model ELEMENT_TYPE
SYNTAX service_type
STATUS non_applicable
DESCRIPTION "Indicator of functional elements"
::= { service 150 }
The policer definition is as follows:
policer ELEMENT_TYPE
SYNTAX service_class
STATUS non_applicable
DESCRIPTION "Simple GCRA traffic policer"
::= { element_model 5 }
A typical parameter definition may be as follows:
increment ELEMENT_TYPE
SYNTAX float_parameter
STATUS mandatory
DESCRIPTION "Increment parameter for the policer"
::= { policer 1 }
The other parameters are defined in a similar manner. The
element_identifiers for all parameters that may be specified for
the simple GCRA policer are given below
Parameter element_identifier
Increment 1
Limit 2
flag parameter 3
Ranganathan, et. al. Expires: June 1999 [Page 13]
INTERNET-DRAFT draft-ietf-gsmp-qos-framework-00.txt December 1998
5. Conclusion
The proposed framework focuses on providing a simple control
interface for open control implementations based on existing
standard architectures supported by the network element.
By defining a general set of parameters, the framework broadens the
flexibility of the control domain with minimum compromise to
simplicity. Further, it advocates a model based approach for direct
manipulation of hardware.
The concept of Control Information Base provides a convenient means
of parsing the control domain. Proprietary CIB definitions permit
vendors to restrict the information about the underlying hardware
and still cater to flexible services by incorporating a
comprehensive general parameter set.
It is important to note that the proposed framework for generic
Quality of Service is applicable to any network element and any
off-board control architecture.
6. Security considerations
As this document does not propose a protocol, there are no
security considerations.
7. References
[1] Newman, P. et al.,"Ipsilon's General Switch Management Protocol
Version 2.0", RFC 2297, March 1998.
[2] Adam, Constantin M., et al.,"QoS Extensions to GSMP",
OPENSIG-DRAFT, COMET Group, Columbia University, April 1997.
[3] The ATM Forum Technical Committee "ATM User-Network Interface
(UNI) Signaling Specification Version 4.0", af-sig-0061.000,
July 1996.
[4] Ranganathan, P., et al.,"QoS extensions and UNI 4.0 support to
GSMP", ITTC-DRAFT, University of Kansas, January 1998.
[5] Shenker, S., et al., "General Characterization Parameters for
Integrated Service Network Elements", RFC 2215, September 1997.
[6] Shenker, S., et al., "Network Element Service Specification
Template", RFC 2216, September 1997.
Ranganathan, et. al. Expires: June 1999 [Page 14]
INTERNET-DRAFT draft-ietf-gsmp-qos-framework-00.txt December 1998
[7] Nichols, K., et al., "Definition of the Differentiated Services
Field (DS Field) in the IPv4 and IPv6 Headers", Internet Draft
<draft-ietf-diffserv-header-04>, October 1998.
[8] Jacobson, V., et al., "An Expedited Forwarding PHB",
Internet Draft <draft-ietf-diffserv-phb-ef-01>, November 1998.
Appendix A : Framework applied to Integrated Services (intserv)
According to RFC 2215 [5], QoS parameters are assigned in the
following format to intserv-based services -
"Parameters are assigned machine-oriented ID's and each
parameter ID is composed from two numerical fields, one
identifying the service associated with the parameter
(the <service_number>), and the other (the <parameter_number>)
identifying the parameter itself.
The <parameter_number> values for the parameters common to
all services are assigned from the "general parameters"
range (1 - 127). The <parameter_numbers> in the range
128 - 254 name parameters with definitions specific to a
particular QoS control service. In contrast to the general
parameters described here, it is necessary to consider both
the <service_number> and <parameter_number> to determine the
meaning of the parameter."
According to RFC 2216 [6], intserv supports various service classes
as follows -
"<Service Name> is an integer in the range 1 to 254. Service
number 1 is used to indicate that the associated parameter
is "generic", and is not associated with a specific service.
The range from 2 to 127 used to name services defined by the
IETF. Service numbers in the region above 127 are reserved
for experimental or private services."
In Connection Establishment message,
Service Type = 2 (indicating intserv services)
Q = 1
N = 0
In QoS Configuration message
Service Class = 5 (for Controlled Load service defined by IETF)
Ranganathan, et. al. Expires: June 1999 [Page 15]
INTERNET-DRAFT draft-ietf-gsmp-qos-framework-00.txt December 1998
If T=0, a predefined structure for the intserv service can be used
for passing QoS control parameters[5].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control API Message Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x05 |0|0|x|x|x|x|x|x| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Rate [r] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bucket Depth [b] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Traffic Rate [p] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit [m] | Maximum Packet Size [M] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The parameters can also be passed as TLV structures by setting T=1.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control API Message Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x05 |0|1|x|x|x|x|x|x| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| 0x7F (127d) | 0x1C (28d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 0x01 | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Rate [r] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 0x02 | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bucket Depth [b] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 0x04 | 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit [m] |0| 0x05 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x02 | Maximum Packet Size [M] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ranganathan, et. al. Expires: June 1999 [Page 16]
INTERNET-DRAFT draft-ietf-gsmp-qos-framework-00.txt December 1998
The default value of positive infinity may be assumed for the
Peak Traffic Rate [p] for the particular service. The service and
parameter types in the above message are based on example CIB
definition provided in Section 4.2.1.
For any standard service supported by the IETF, the entire parameter
set is known and the control API can provide complete support for
such services. Any parameter in the range of 1-127 is also
predefined by intserv, so the control API can handle them too.
The issue arises for service-specific parameters (parameters
128-254) for experimental/private services (services 127-254) which
can vary depending on the service. In such cases, a general
parameter set may be used as explained in Section 3.1 or the
approach of mapping these QoS parameters to functional units on the
network element may be employed as explained in Section 3.2.
Alternately, the N bit can be set to 1 in the Connection
Establishment message and an alternate interface can be used for
communicating the QoS requirements.
Appendix B : Framework applied to Differentiated Services (diffserv)
According to [7],
"Differentiated services are intended to provide a framework
and building blocks to enable deployment of scalable service
discrimination in the Internet.
In the packet forwarding path, differentiated services are
realized by mapping the codepoint contained in a field in the
IP packet header to a particular forwarding treatment, or
per-hop behavior (PHB), at each network node along its path.
The description of a PHB SHOULD be sufficiently detailed to
allow the construction of predictable services."
We consider a particular per hop behavior, the Expedited Forwarding
PHB to which we apply our framework for control.
According to [8],
"The EF PHB can be used to build a low loss, low latency, low
jitter, assured bandwidth, end-to-end service through DS
domains. The EF PHB is defined as a forwarding treatment for
a particular diffserv aggregate where the departure rate of
the aggregate's packets from any diffserv node must equal or
exceed a configurable rate. This configured minimum rate must
be settable.
Ranganathan, et. al. Expires: June 1999 [Page 17]
INTERNET-DRAFT draft-ietf-gsmp-qos-framework-00.txt December 1998
If the EF PHB is implemented by a mechanism that allows
unlimited preemption of other traffic, the implementation
must include some means to limit the damage EF traffic could
inflict on other traffic (e.g., a token bucket rate limiter).
This maximum EF rate must be settable."
The various PHBs are treated as service classes in the framework.
The EF PHB service may be defined using the framework as follows.
In the Connection Establishment message,
Service Type = 3 (indicating Differentiated Services)
Q = 1
N = 0
In QoS Configuration message
Service Class = 184 (for EF PHB)
The service class identifier is derived from the DS byte. Codepoint,
which forms the 6 most significant bits of the DS byte is assigned
101110 as recommended for the EF PHB. The two least significant
bits of the DS byte are set to 0.
The parameters are passed as TLV structures by setting T=1.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control API Message Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xB8(184d) |0|1|x|x|x|x|x|x| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 0x01 | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| configured minimum rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 0x02 | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| maximum EF rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The service and parameter types in the above message are based on
example CIB definition provided in Section 4.2.2.
Ranganathan, et. al. Expires: June 1999 [Page 18]
INTERNET-DRAFT draft-ietf-gsmp-qos-framework-00.txt December 1998
If a standard support for the EF PHB is not provided on the network
element, possible equivalent parameters from the general parameter
set, if available, can be used for the implementation of the
service. Parameters such as minimum departure rates and peak rates
are parameters that intuitively fall in the general set. In such a
case we use the approach described in Section 3.1 setting the
service type to 100.
If the parameters for the service defined by EF PHB is not directly
available via the control interface, then we map these parameters to
functional units in the network element and follow the approach
described in Section 3.2 setting the service type to 150. A logical
map of these parameters would be to appropriately manipulate the
policer and regulator functional units.
Appendix C : Framework Applied to ATM Forum services
In Connection Establishment message of Control API
Service Type = 1 (Indicating ATMF Based services)
Q = 1
N = 0
In QoS Configuration message
Service Class = 2 (for rt_VBR)
If T=0, then a predetermined QoS structure for ATMF service
class[3] is employed for sending QoS information. It is assumed
that the controller and network element have sufficient information
to interpret these parameters and this is outside the scope of the
control API.
Ranganathan, et. al. Expires: June 1999 [Page 19]
INTERNET-DRAFT draft-ietf-gsmp-qos-framework-00.txt December 1998
As an example, the following message format may be used for rt_VBR
Service defined by ATM Forum,
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control API Message Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x02 |0|0|x|x|x|x|x|x| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Cell Rate ( CLP = 0+1 ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Cell Rate ( CLP = 0 ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sustainable Cell Rate ( CLP = 0+1 ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sustainable Cell Rate ( CLP = 0 ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Burst Size ( CLP = 0+1 ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Burst Size ( CLP = 0 ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ranganathan, et. al. Expires: June 1999 [Page 20]
INTERNET-DRAFT draft-ietf-gsmp-qos-framework-00.txt December 1998
If T=1, then the PCR, SCR and MBS values are given as TLV
structures.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control API Message Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x02 |0|1|x|x|x|x|x|x| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 0x01 | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Cell Rate ( CLP = 0 + 1 ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 0x03 | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sustainable Cell Rate ( CLP = 0+1 ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 0x05 | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Burst Size ( CLP = 0+1 ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the above message, only the PCR, SCR and MBS values for
CLP = 0 + 1 cells are specified. The other parameters are assumed
default values or unused by the application, for instance when
selective cell discard is not a component of the requested service.
The service and parameter types in the above message are based on
example CIB definition provided in Section 4.2.3.
Authors' Contact
Parasuram Ranganathan
ITTC, University of Kansas
2291, Irving Hill Road, #344W
Lawrence, KS 66045
Phone: +1 785 864 7844
email: ram@ittc.ukans.edu
Deepak Sreenivasamurthy
ITTC, University of Kansas
2291, Irving Hill Road, #317
Lawrence, KS 66045
Phone: +1 785 864 3041
email: sdeepak@ittc.ukans.edu
Ranganathan, et. al. Expires: June 1999 [Page 21]
INTERNET-DRAFT draft-ietf-gsmp-qos-framework-00.txt December 1998
Joseph Evans
ITTC, University of Kansas
2291, Irving Hill Road, #204
Lawrence, KS 66045
Phone: +1 785 864 4830
email: evans@ittc.ukans.edu
Arvind Kaushal
Sprint Corporation,
9300 Metcalf Avenue,
Overland Park, KS 66212
Mailstop: KSOPKB0301
Phone: +1 913 534 2558
email: kaushal@sprintcorp.com
Ranganathan, et. al. Expires: June 1999 [Page 22]
