Internet Draft Internet Engineering Task Force Avri Doria Internet Draft Tom Worster General DataComm Expires April 1999 Kenneth Sundell Ericsson October 1998 Applicability of GSMP as an IETF Protocol <draft-doria-gsmp-applicability-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 discusses the applicability of the General Switch Management Protocol, GSMP, to network control protocols such as Multiprotocol Label Switching (MPLS). It discusses the need for this protocol to be standardized and discusses areas where development is still necessary. Finally, it recommends that the IETF establish a working group with the objective of furthering the protocol and working toward making it a standard. Doria, et. al. Expires: April 1999 [Page 1] INTERNET-DRAFT GSMP Applicability October 1998 A PDF version of this draft can be found at: http://www. apocalypse.org/~avri/papers/draft-doria-gsmp-applicability-00.pdf Table of Contents Status of this Memo 1 Abstract 1 1. Background 2 2. Brief description of the protocol 3 3. Applicability to the IETF Enterprise 4 4. Related Standards Efforts 5 5. Why Standardize 7 6. GSMP requirements 7 7. Recommendation 8 8. Security considerations 8 9. References 9 Authors' Contact 9 1 Background The General Switch Management Protocol (GSMP) has been available to the IETF community for several years now. Both V1.1 released in March 1996 as RFC1987, and V2.0 released in August 1998 as RFC2297 are available and V1.1 has been implemented by several vendors. Ipsilon, now Nokia, originally created the protocol and produced the first commercial products which utilized the protocol. They also produced a reference port which was openly available and produced a set of GSMP test programs which they also made available. Initially GSMP was released as part of the IP Switch protocols. GSMP provided a means by which the control plane software, Ipsilon Flow Management Protocol [5] and the IETF routing protocols, could be strictly isolated from the data switch and could control the switch. Since its first release, several equipment vendors have either released versions of their switch with support of GSMP controlled switching or have such products in preparation. Several other vendors are currently implementing service platforms which use GSMP, or a similar protocol, to control ATM switching hardware. With the exit of Ipsilon/Nokia from the IP Switching arena, it appeared as if the usefulness of GSMP might be at an end. Several vendors, however, realized the utility of this protocol was independent of IP Switching. To quote from "Switching in IP Networks" by Davie, Doolan and Rekhter: We provide an introduction to the GSMP because it is part of the overall IP Switching architecture. However, it is important to realize that, from a technology perspective, IP Switching is essentially Doria, et. al. Expires: April 1999 [Page 2] INTERNET-DRAFT GSMP Applicability October 1998 independent of GSMP, and vice versa. GSMP is used solely to control an ATM switch and the VC connections made across it. We could make an IP switch without GSMP. Also one can use GSMP to control ATM switches without building an IP switch. For example, one could build a controller that implemented standard ATM signaling (e.g., Q.2931) and controlled a switch using GSMP. The GSMP protocol has begun to achieve that independent usefulness which the quote above alludes to. That is, even though IP Switching, as a protocol is not longer being implemented as originally conceived by the designers at Ipsilon/Nokia, various vendors are producing implementations of GSMP to allow service controllers, in some case IP service controllers, to control ATM switches. GSMP provides an interface which can be used to separate the data forwarder from the routing and other control plane protocols. While many systems achieve some degree of this separation internally, there is a lot of which can be gained from defining a standard way to define that separation. As currently defined GSMP has two encapsulations; ATM and raw Ethernet. This draft discusses some of the tasks GSMP can be used for, and argues that the IETF should create a working group to further develop the GSMP with the objective of standardizing the protocol. 2. Brief description of the protocol The General Switch Management Protocol (GSMP) as currently defined in Informational RFC 2297 [4] is intended to provide a general purpose interface for controlling an ATM switch. It includes commands in the following areas: - Connection Management, that is the establishment and release of unicast and multicast connections. - Port Management. - Definitions of QoS models and parameters to be used in connections. - Switch configuration control and reporting. - Reporting of statistics and asynchronous events. The protocol runs as a controller-controlled (a.k.a. Master- Slave) protocol with the controller running in an control Doria, et. al. Expires: April 1999 [Page 3] INTERNET-DRAFT GSMP Applicability October 1998 component which contains upper layer protocols while the controlled component generally runs in switches. While it is possible for a GSMP control component to control more then one switch, a single switch can only be controlled by one controller. The protocol includes an adjacency protocol which allows for the relationship between the control component and the switch to be monitored for discontinuity, for example restarts, in both the control component and in the switch. The adjacency protocol also allows for the identity of the switch a controller to be maintained. Since the original design of the protocol was intended for direct point to point communications, no authentication other than by simple naming is provided. A full definition of GSMP V2 is available in RFC2297 [4]. GSMP V1.1, which is the protocol currently available in several vendors' equipment, is defined in RFC1987 [3]. The major difference between GSMP V1.1 and GSMP V2 is that GSMP V1.1 does not contain support for anthing more than very simple QoS. 3. Applicability to the IETF Enterprise While there have been arguments about the usefulness of the ATM cell format, there is a fair amount of agreement over the principle that forwarding is a job well left to hardware. It is also being discovered that often the control plane operations (that is routing, label distribution and discovery and signaling whether RSVP or Q.2932) are often ill suited to run on the hardware that is best suited for forwarding. It is therefore, often advantageous to split the functionality between sub systems, each specialized for it own tasks. Sometimes, the split is internal and sometimes it is external. By and large, whether it is internal or external is determined more by the environment where the equipment will be used than by the technical needs of the upper and lower layer protocols. Often, in an open market, the company which produces the best switch for a user's purposes is not the same company that produces the best control components; i.e. routing protocols etc... . In this case, having a protocol which is standard and which can be tested against for interoperability allows the user the greatest latitude in picking vendors to suit his or her needs. As an organization dedicated to the creation of open standards that aid users in establishing end to end communications among the equipment of diverse users, standardizing a protocol like GSMP seems relevant and perhaps even important. Doria, et. al. Expires: April 1999 [Page 4] INTERNET-DRAFT GSMP Applicability October 1998 One specific area in which GSMP is immediately useful is MPLS. 3.1 MPLS MPLS's use of an ATM hardware infrastructure is an excellent candidate for implementation using GSMP. In effect MPLS replaces the ATM forum based control plane with an IP based control plane. It, however, takes advantage of the efficiencies available in use of the ATM hardware. When making use of an ATM switch there are definite advantages in using a protocol which provides a useable abstraction of the switch's capabilities for use by the label distribution control components. The same argument would hold for a Frame Relay switch and for other switch types, There is a very large installed base of ATM switches in the market, just as there is a very large installed base of routers. If users are to acquire Labeled Switch Routers without the forklift approach, it will be necessary for the routers and switches both to accommodate the MPLS functionality without massive rewrites. It is possible to add a full set of routing code and label distribution code to a switch, or to attach a switch by proprietary means to a router. It seems, however, that adding GSMP functionality to both routers and switches would facilitate the use of the new protocols. It would certainly make things cheaper and easier for the users as they would not need to do massive updates. 3.1.1 Sharing bandwidth between MPLS and ATM forum protocols. While MPLS is useful without being paired with ATM Forum signaling protocols, many users will not wish to dedicate the entire bandwidth on a line to MPLS traffic. In order to support a ships in the night implementation it will be necessary for the bandwidth and other resources to be partitioned. While this can be done in a static way on many of today's switches, the partitioning would be aided by peering the IP and ATM Forum protocols on a separate controller and controlling the switch with a protocol such as GSMP. 4. Related Standards Efforts The desire to develop an open interface has been explored in several other standards bodies including the IEEE, ATM Forum and ITU-T. Doria, et. al. Expires: April 1999 [Page 5] INTERNET-DRAFT GSMP Applicability October 1998 4.1 IEEE In the IEEE, a GSMP like interface has been proposed as P1520, a Proposed IEEE Standard for Application Programming Interfaces for Networks. From their charter: The interfaces proposed above permit views of network and switching hardware states to be exposed for independent and flexible signaling service creation. ... we can encapsulate different types of signaling protocols, so that they may be accessed from the same generic interface. This will benefit network service developers and application vendors who can realize communication services not specified in standard signaling protocols, and conduct service quality negotiations with network elements. The exposed interfaces will also benefit switch vendors through enhanced external control and management of switching hardware with minimum software development effort. [6] The work being done in this committee comprises much more then just the physical interface which GSMP provides. In terms of the physical layer they write the following: As the names suggest, the entities at the PE level are physical elements of the network, such as ATM and IP switches, and local exchanges in narrow-band circuit switched telephone networks. The above encompasses hardware such as ATM switches, time division multiplexers (TDMs), VP switches and cross connects; and also the physical elements of a narrow- band CS telephone network. These elements are accessed by means of open protocols such as GSMP [3][4] QGSMP [7] (which are used for ATM switches), and other proprietary means for accessing information at this level. [6] There appears to be an assumption that the P1520 effort as proposed intends to use the GSMP protocol as a reference point. From the proposal: Other standards and implementation agreements that are relevant to this project include ATM Forum UNI, PNNI, MPOA [28-30], and IETF RSVP, Integrated Services, MPLS, GSMP [11, 31-33]. The Proposed Standard defines part of the software environment for programmable networks. As such, existing and evolving standards, for example for ATM signaling or for IP related signaling, can be implemented within the standard framework as special cases. [6] Doria, et. al. Expires: April 1999 [Page 6] INTERNET-DRAFT GSMP Applicability October 1998 The P1520 effort has organized subgroups which are also focusing on developing the QoS capabilities along lines similar to those included in GSMP V2. 4.2 ATM Forum Since the initial, and still current, predominant use for GSMP was to control ATM switches, it is natural to wonder whether there is any interest by the ATM Forum in standardizing GSMP. Reportedly, this has been broached, but the organization is not interested at this time. 5. Why Standardize GSMP is a protocol which allows a clean separation between control protocols and switching hardware. Often the companies that make these products have different capabilities. By opening up this interface and making it a standard which can be tested against, it becomes feasible for customers to pick the switching hardware and the control plane hardware form different vendors, according to their needs. While GSMP may seem a good idea to some, without a standard which offers at least a minimal expectation that diverse vendors equipment will interoperate, it becomes too big a risk for both vendors and customers. While it remains useful as a proprietary solution for those who have implemented it, it cannot achieve it full potential as a protocol. 6. GSMP requirements In this note, we are recommending not only that GSMP be put on the standards track, something that is possible with forming a working group, but are suggesting that a working group be formed to continue development of this protocol. Currently several areas of development are envisioned. There may be others. 6.1 IP encapsulation of GSMP messages As GSMP is currently designed, it can only be used in a point to point connection between the control component and the switch. Since a GSMP control component is capable of controlling several switches, and since it is possible to control a switch remotely, it would be beneficial for GSMP to have an IP encapsulation. Doria, et. al. Expires: April 1999 [Page 7] INTERNET-DRAFT GSMP Applicability October 1998 6.2 Extend GSMP to support non ATM switch types Currently GSMP is ATM centric. In order for GSMP to be used for switch types other then ATM, such as Ether switches, PoS IP switches or Frame Relay switches, the protocol needs to be extended to support these switch types and their primitives. 6.3 Refinement and Interoperability experience with GSMP V2 QoS model GSMP V2, provides both a practical update to GSMP V1.1 and an experimental advance in the protocol. As an update, the authors took what had been learned by Ipsilon/Nokia and their customers and partners and made significant improvement to the protocol. As an experimental advancement, the authors added a QoS support model. This model has not yet been subjected to much implementation. One of the purposes of a working group would be to gain and share knowledge about the implementation of the QoS capabilities. Interoperability between the various GSMP implementations is still haphazard at best. As part of the working group and standardization process, this must be rectified. 6.4 Definition of a GSMP MIB While GSMP can be run independently of any other management protocol, within today's network, a protocol which does not offer SNMP support is wanting. A working group would also be charged with producing a MIB for the protocol. 7. Recommendation For the reasons explored in this note, we recommend and request that a working group be established to further work on GSMP within the IETF community. 8. Security considerations As this document does not propose a protocol, there are no security considerations. As part of the work to be done in a GSMP working group, security considerations, especially those having to do with authentication in the adjacency protocol and in use of the protocol over IP nets will need to be explored. Doria, et. al. Expires: April 1999 [Page 8] INTERNET-DRAFT GSMP Applicability October 1998 9. References [1] R. Callon et al, "A Framework for Multiprotocol Label Switching," Internet Draft <draft-ietf-mpls-framework-02.txt>, Nov 1997. [2] B. Davie, P.Doolan, Y. Rekhter, Switching in IP Networks, Morgan Kaufman Publishers, Inc., 1998 [3] P. Newman, W. Edwards, R. Hinden, E. Hofman, F. Ching Liaw, T. Lyon, G. Minshall, "Ipsilon's General Switch Management Protocol Specification," Version 1.1, RFC 1987, August 1996. [4] P. Newman, W. Edwards, R. Hinden, E. Hofman, F. Ching Liaw, T. Lyon, G. Minshall, "Ipsilon's General Switch Management Protocol Specification," Version 2.0, RFC 2297, March 1998 [5] P.Newman, W.L. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall, "Ipsilon Flow Management Protocol Specification," Version 1.0, RFC 1953, May 1996 [6] Jit Biswas, Jean-Francois Huard, Aurel Lazar, Koonseng Lim, Semir Mahjoub, Louis Francois Paul, Masaaki Suzuki, Soren Torstensson, Wang Weiguo and Steve Weinstein, Application Programming Interfaces for Networks (DRAFT WHITE PAPER), http://www.ieee-pin.org/. [7] C. M. Adam, A. A. Lazar and M. Nandikesan, "QOS Extension to GSMP", OPENSIG Workshop on Open Signaling for ATM, Internet and Mobile Networks, University of Cambridge, Cambridge, UK, April 17- 18, 1997; CTR Technical Report #471-97-05, Center for Telecommunications Research, Columbia University, New York, April 16, 1997, available under URL http://comet.columbia.edu/xbind/qGSMP. [8] Home page for the IEEE P1520 proposed standard, http://www.ieee-pin.org/. Authors' Contact Avri Doria +1 508 624 6723 General DataComm avri@gdc.com Tom Worster +1 508 624 6723 General DataComm worster@gdc.com Kenneth Sundell +46 8719 9880 Ericsson etxkens@etxb.ericsson.com Doria, et. al. Expires: April 1999 [Page 9]