Applicability of GSMP as an IETF Protocol

Versions: 00                                                            
Internet Engineering Task Force                        Avri Doria
Internet Draft                                        Tom Worster
                                                 General DataComm
Expires April  1999                               Kenneth Sundell

                                                     October 1998

             Applicability of GSMP as an IETF Protocol


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

   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 (Africa), (Northern Europe), (Southern
   Europe), (Pacific Rim),  (US East
   Coast), or (US West Coast).

   Distribution of this memo is unlimited.


   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.

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

   -      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

Doria, et. al.         Expires: April 1999              [Page 4]

INTERNET-DRAFT          GSMP Applicability            October 1998

   One specific area in which GSMP is immediately useful is

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

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.

   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

   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

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

6.3    Refinement and Interoperability experience with GSMP V2 QoS

   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

   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

   [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),

   [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

   [8]    Home page for the IEEE P1520 proposed standard,

Authors' Contact

   Avri Doria          +1 508 624 6723
   General DataComm

   Tom Worster         +1 508 624 6723
   General DataComm

   Kenneth Sundell     +46 8719 9880

Doria, et. al.         Expires: April 1999              [Page 9]