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]