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 definitions

	 ELEMENT_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]