GSMP Working Group Avri Doria, Nokia Internet-Draft Fiffi Hellstrand, Ericsson Expiration Date: Dec 1999 Constantin Adam, Xbind 25 June, 1999 Support Structure for Optional Abstract or Resource Models Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract A set of modifications to the GSMP protocol is proposed in order to allow the GSMP to support optional abstract resource models for Quality of Service. Changes from draft-doria-gsmp-option-arm-00.txt - Addition of reserved Failure Code range INTERNET-DRAFT...Support structure for QoS Models 25.06.99 Doria Expires Dec 1999 [Page 2] 1. Overview The GSMP V3[3] rework of the GSMP V2[2] specification replaced chapter 9, Quality of Service Message, with a default service model based on draft-worster-gsmp-qos-00[4]. Chapter 9 had contained an experimental abstract resource model for Quality of Service. In addition to supporting a default Service Model, a mechanism is still required to support optional Abstract/Resource Models (ARM). This proposal recommends such a structure. The proposed changes include a change to the Configuration Request messages as well as a redefinition of the QoS Model Selector and the Service Selector fields in connection messages. The proposal also recommends reserving a group of message numbers for use by Abstract/Resource Model definitions and a group of failure codes for use by ARM definitions. This proposal only includes the changes that need to be made to the GSMP specification to support the ARM framework. Optional models would be defined in separate documents. An ARM specification is required to define the messages and the fields necessary for implementing the model. ARM Model Types also need to be allocated and registered. 2. Changes to Configuration Message processing Currently the switch configuration exchange is rather simple. The controller requests the switch configuration, and the switch responds with its firmware version, maximum number of outstanding messages, switch type and switch identification. This proposal recommends adding a QoS model type (MType) exchange to this interchange. After adjacency between a controller and a switch is first established the controller that opts to use a model type other then the default would send the switch configuration request including the requested model type in the request message. It would need to do this before any connection messages were exchanged. If the switch could support the request model type then the switch would respond by sending back the requested model type as an indication that it was able to support the request. If the switch cannot support the requested model type, it would send back the default MType; that is MType=0. Switch configuration response messages from the switch would also include a list of up to 3 available model types that the controller could choose between. The exchange may continue until the controller sends a requested MType which the switch can support. If the exchange stopped without INTERNET-DRAFT Support structure for QoS Models 25.06.99 Doria Expires Dec 1999 [Page 3] confirmation of an alternate switch model, then the default model would be used. Once a model type has been established for the switch, it cannot be changed without full restart; that it the re-establishment of adjacency with the resetting of all connections. Additionally the model can only be set until the first connection message is sent. 2.1 Changes to the system configuration request message (# 64) Currently all configuration request messages have the following form: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Result | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ However, the Switch Configuration request does not use the Port field for obvious reasons. The system configuration request message would be changed to: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Result | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MType | x | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where MType represents a requested model type: 0 ¡ Indicates use of the default GSMP model 1 ¡ Indicates use IEEE qGSMP Model[6] 2 - Indicates use of Sprint Framework[5] 3 - 200 - Reserved 201 - 255 - Experimental INTERNET-DRAFT Support structure for QoS Models 25.06.99 Doria Expires Dec 1999 [Page 4] 2.2 Switch Configuration Response Message (#64) The switch configuration response message currently has the following form: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Result | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Firmware Version Number | Window Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switch Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Switch Name | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ It will be changed 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Result | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Firmware Version Number | Window Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switch Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Switch Name | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MType | MType | MType | MType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MType: represents a ARM type: 0 ¡ Indicates use of the default GSMP model 1 ¡ Indicates use of IEEE qGSMP Model[6] 2 - Indicates use of Sprint Framework[5] 3 - 200 - Reserved 201 - 255 - Experimental INTERNET-DRAFT Support structure for QoS Models 25.06.99 Doria Expires Dec 1999 [Page 5] The first MType in the list of MTypes is either the MType as proposed in the request if accepted by the switch or the default MType(0). The rest of the MTypes in the list are MTypes the switch can offer or 0 pads. 3. Proposed Connection Management message changes The following changes apply to the connection management messages; 16, 22, 26, and 27. 3.1 General Message definitions In order to make the service selector as useful as possible, it will be extended to 4 octets from the current 2 octets. That is, in request messages, the Number of Branches field will be removed and the Service Selector will extend for the entire 32 bits. In response messages, the Service Selector field will be removed, replaced by the Number of Branches field and a reserved field. 3.1.1 Connection Management Request 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Result | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Session Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Input Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|B|T|R| | +-+-+-+-+ Input Label ~ ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |QMS|T|R| | +-+-+-+-+ Output Label ~ ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Selector | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ INTERNET-DRAFT Support structure for QoS Models 25.06.99 Doria Expires Dec 1999 [Page 6] 3.1.2 Connection Management Response 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Result | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Session Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Input Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|B|T|R| | +-+-+-+-+ Input Label ~ ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |QMS|T|R| | +-+-+-+-+ Output Label ~ ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Branches | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2 Changes to Connection Message Fields 3.2.1 QoS Model Selector QoS Model Selector will be modified as follows in connection management message: QMS: QoS Model Selector The QoS Model Selector is used to specify a QoS Model for connection. The value of QMS indicates the value in the Service Selector should be interpreted as a priority, a QoS profile a service specification or as defined by the configured Mtype: QMS QoS Model Service Selector --- --------- ---------------- 00 Simple Abstract Model Priority 01 QoS Profile Model QoS Profile INTERNET-DRAFT Support structure for QoS Models 25.06.99 Doria Expires Dec 1999 [Page 7] 10 Service Model Service Specification 11 Optional ARM ARM Specification 3.2.2 Service Selector Service Selector field description in the connection management messages will be modified as follows: This field can contain either a QoS Profile Identifier, a Priority, a Service Specification or an optional ARM indicator. If the QoS Model Selector is set to 0b00, the Service Selector field contains a Priority. If the QoS Model Selector is set to 0b01, the Service Selector field contains a QoS Profile. If the QoS Model Selector is set to 0b10, the Service Selector field contains a Service Specification. If the QoS Model Selector is set to 0b11, the Service Selector field will contain a service indicator which has its meaning defined by the optional ARM being used as indicated in the MType field of the configuration message. The Service Selector field is only used in the Add Branch and Move Branch messages. When using the default service model, Priority specifies the priority of the connection for Add Branch and Move Branch messages that choose not to use a QoS profile, or a service specification. The highest priority is numbered zero and the lowest priority is numbered "Q-1" where "Q" is the number of priorities that the output port can support. The ability to offer different qualities of service to different connections based upon their priority is assumed to be a property of the output port of the switch. It is assumed that for virtual path connections or virtual channel connections that share the same output port, a cell or frame on a connection with a higher priority is much more likely to exit the switch before a cell or frame on a connection with a lower priority, if they are both in the switch at the same time. The number of priorities that each output port can support is given in the Port Configuration message. In order to maintain backward compatibility with earlier versions of the protocol, the Priority octets will occupy the 2 rightmost octets of the service selector. When using the default service model, a QoS Profile Identifier is an opaque 16-bit value. It is used to identify a QoS profile in the switch which specifies the Quality of Service required by the connection. QoS profiles are established by a mechanism external to GSMP. When using the default service model, a Service Specification is an alternative method of communicating the QoS requirements of a INTERNET-DRAFT Support structure for QoS Models 25.06.99 Doria Expires Dec 1999 [Page 8] connection. The Service Specification is defined in GSMP V3[3] Chapter 9. When using an optional ARM, The meaning of Service selector is dependant on the definitions which are provided in the ARM specification. 4. Message numbers reserved for Abstract Resource Models Message sequence 200-249 is reserved for abstract resource model message definition. These messages will be interpreted according to definitions provided by the model description. It is expected that ARM specifications will include definitions of Model configuration, connection management and status gathering messages in this group. 5. Failure codes reserved for Abstract Resource Models Failure code sequence 128-159 is reserved for abstract resource model failure code definition. These failure codes will be interpreted according to definitions provided by the model description. Authors' Contact Avri Doria Nokia Telecommunications 3 Burlington Woods Drive, Suite 250 Burlington, MA 01803 Phone: +1 781 359 5131 Mobile: +1 617 678 9402 avri.doria@ntc.nokia.com Fiffi Hellstrand Ericsson Telecom S-126 35 Stockholm Phone +46 8 719 4933 Mobile +46 70 519 4933 etxfiff@etxb.ericsson.se Constantin Adam Xbind, Inc. 55 Broad Street, Suite 13C New York, NY 10004 Phone: +1 212 809 3303 Mobile +1 917 335 8161 ctin@xbind.com INTERNET-DRAFT Support structure for QoS Models 25.06.99 Doria Expires Dec 1999 [Page 9] Comments on this document should be sent to the authors or to the working group mailing list at gsmp@psyton.com. References [1] Newman, P, Edwards, W., Hinden, R., Hoffman, E. Ching Liaw, F., Lyon, T. and Minshall, G., "Ipsilon's General Switch Management Protocol Specification," Version 1.1, RFC 1987, August 1996. [2] Newman, P, Edwards, W., Hinden, R., Hoffman, E., Ching Liaw, F., Lyon, T. and Minshall, G., "Ipsilon's General Switch Management Protocol Specification," Version 2.0, RFC 2397, March 1998. [3] GSMP Working Group, Tom Worster Editor, "General Switch Management Protocol V3", draft-ietf-gsmp-00.txt, June, 1999 [4] GSMP Working Group, Worster, T; Hellstrand, F; Doria, A; "A QoS Model for GSMP", draft-worster-gsmp-qos-00.txt, Feb, 1999 [5] GSMP Working Group, Ranganathan, P; Sreenivasamurthy, D; Evans, J; Kaushal, A; "A framework for QoS support for open control", draft-ranganathan-gsmp-qos-framework-00.txt, Dec 1998 [6] IEEE/WG 1520, Adam, C; Lazar, A; Nanadikesan, M; "Proposal for Standaridizing the qGSMP protocol", P1520/TS/ATM-002, http://comet.columbia.edu/pin-atm/docs/P1520-TS-ATM-002R1.pdf, 19 Jan, 1999 This document expires on 25 December 1999. INTERNET-DRAFT Support structure for QoS Models 25.06.99