Network Working Group A. Doria Request for Comments: 3294 Lulea University of Technology Category: Informational K. Sundell Nortel Networks June 2002 General Switch Management Protocol (GSMP) Applicability Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved.
AbstractThis memo provides an overview of the GSMP (General Switch Management Protocol) and includes information relating to its deployment in a IP network in an MPLS environment. It does not discuss deployment in an ATM (Asynchronous Transfer Mode) network or in a raw ethernet configuration. RFC 1987 ) and GSMPv2.0 (released in August 1998 as RFC 2297 ) are available. Several vendors have implemented GSMPv1.1. In V1.1 and V2 GSMP was intended only for use with ATM switches. During the course of the last two years, the GSMP working group has decided to expand the purview of GSMP to the point where it can be used to control a number of different kinds of switch and can thus live up to what its name indicates; a general switch management protocol. To do this, commands and arguments needed to be generalised and sections needed to be added, discussing the manner in which the generalised protocol could be applied to specific kinds of switches and port types. In short, the protocol has gone through major changes in the last 24 months.
GSMP provides an interface that can be used to separate the data forwarder from the routing and other control plane protocols such as LDP. As such it allows service providers to move away from monolithic systems that bundle the control plane and the data plane into a single tightly coupled system - usually in a single chassis. Separating the control components from the forwarding components and using GSMP for switch management, enables service providers to create multi-service systems composed of various vendors equipment. It also allows for a more dynamic means of adding services to their networks. The IETF GSMP working group was established in the routing area because GSMP was being seen as an optional part of the MPLS solution. In a MPLS system, it is possible to run the routing protocols and label distribution protocols on one system while passing data across a generic switch, e.g., an ATM switch. GSMP provides the switch resource management mechanism needed in such a scenario. GSMP has also been selected by the Multiservice Switching Forum (MSF) as its protocol of choice for the Switch Control Interface identified in their architecture. The MSF is an industry forum which, among its activities establishes their member's requirements and then works with the appropriate standards bodies to foster their goals. In the case of GSMP, the MSF presented the IETF GSMP Working Group with a set of requirements for GSMP. The working group has made a determined effort to comply with those requirements in its specifications. 5] - GSMP-ENCAPS: General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP)  - GSMP-MIB: Definitions of Managed Objects for the General Switch Management Protocol  5], is a general purpose protocol to control a label switch. GSMP allows a controller to establish and release connections across the switch; add and delete leaves on a multicast connection; reserve resources; manage switch ports; request configuration information; and request statistics. It also allows the switch to inform the
controller of asynchronous events such as a link going down. The GSMPv3 protocol is asymmetric, the controller being the master and the switch being the slave. A physical switch can be partitioned into many virtual switches. GSMPv3 does not provide support for defining switch partitions. GSMPv3 treats a virtual switch as if it were a physical switch. GSMPv3 may be transported in three ways: - GSMPv3 operation across an IP network is specified. - GSMPv3 operation across an ATM virtual channel is specified. - GSMPv3 operation across an Ethernet link is specified. Other encapsulations are possible, but have not been defined. Encapsulations are defined in . A label switch is a frame or cell switch that supports connection oriented switching using the exact match forwarding algorithm based on labels attached to incoming cells or frames. A label switch may support multiple label types. However, each switch port can support only one label type. The label type supported by a given port is indicated in a port configuration message. Connections may be established between ports supporting different label types using the adaptation methods. GSMPv3 supports TLV labels similar to those defined in MPLS. Examples of labels which are defined include ATM, Frame Relay, DS1, DS3, E1, E3, MPLS Generic Labels and MPLS FECs. A connection across a switch is formed by connecting an incoming labelled channel to one or more outgoing labelled channels. Connections are generally referenced by the input port on which they arrive and the label values of their incoming labelled channel. In some messages, connections are referenced by the output port. GSMPv3 supports point-to-point and point-to-multipoint connections. A multipoint-to-point connection is specified by establishing multiple point-to-point connections, each of which specifies the same output label. A multipoint-to-multipoint connection is specified by establishing multiple point-to-multipoint connections each of which specifies a different input label with the same output labels.
In general a connection is established with a certain quality of service (QoS). GSMPv3 includes a default QoS Configuration and additionally allows the negotiation of alternative, optional QoS configurations. The default QoS Configuration includes three QoS Models: a default service model, a simple priority model and a QoS profile model. GSMPv3 also supports the reservation of resources when the labels are not yet known. This ability can be used in support of MPLS. GSMP contains an adjacency protocol. The adjacency protocol is used to synchronise states across the link, to negotiate which version of the GSMP protocol to use, to discover the identity of the entity at the other end of a link, and to detect when it changes.
of the controllers, and will execute all commands as they are received. It is the controller group's responsibility to co-ordinate its use of the switch. This mechanism is most commonly used for controller redundancy and load sharing. Definition of the mechanism by which controllers use to co-ordinate their control is not within GSMPv3's scope.
Abstract and Resource Model Extension Messages Reserved.Message Range.........200-249 Adjacency Protocol.................10 Required 4]. For all uses of GSMP over an IP network, it is REQUIRED that GSMP be run over TCP/IP using the security considerations discussed in .  Sjostrand, H., Buerkle, J. and B. Srinivasan, "Definitions of Managed Objects for the General Switch Management Protocol (GSMP)", RFC 3295, June 2002.  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.  Newman, P., Edwards, W., Hinden, R., Hoffman, E., Ching Liaw, F., Lyon, T. and G. Minshall, "Ipsilon's General Switch Management Protocol Specification Version 2.0", RFC 2297, March 1998.  Worster, T., Doria, A. and J. Buerkle, "General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP)", RFC 3293, June 2002.  Doria, A., Sundell, K., Hellstrand, F. and T. Worster, "General Switch Management Protocol (GSMP) V3", RFC 3292, June 2002.
Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.