Internet Draft 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-ranganathan-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-ranganathan-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-ranganathan-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-ranganathan-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-ranganathan-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-ranganathan-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-ranganathan-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-ranganathan-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-ranganathan-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 definitionsELEMENT_TYPE SYNTAX STATUS DESCRIPTION ::= { } Controlled elements can correspond to service type, service class or parameter type. The and the 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-ranganathan-gsmp-qos-framework-00.txt December 1998 The indicates the nature of the controlled element, namely, service_type, service_class, structured_parameter, int_parameter, float_parameter, double_parameter and so on. The can be mandatory or optional depending on the parameter type for the corresponding service. The field is defined as "non_applicable" when the controlled elements are either service class, service type or functional units. The provides a brief description of the controlled element. The 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-ranganathan-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-ranganathan-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-ranganathan-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-ranganathan-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-ranganathan-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 , October 1998. [8] Jacobson, V., et al., "An Expedited Forwarding PHB", Internet Draft , 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 ), and the other (the ) identifying the parameter itself. The values for the parameters common to all services are assigned from the "general parameters" range (1 - 127). The 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 and to determine the meaning of the parameter." According to RFC 2216 [6], intserv supports various service classes as follows - " 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-ranganathan-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-ranganathan-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-ranganathan-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-ranganathan-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-ranganathan-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-ranganathan-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-ranganathan-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]