2.5.1 General Switch Management Protocol (gsmp)

NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 06-Jul-99


Avri Doria <avri@apocalypse.org>

Routing Area Director(s):

David Oran <oran@cisco.com>
Rob Coltun <rcoltun@siara.com>

Routing Area Advisor:

Rob Coltun <rcoltun@siara.com>

Mailing Lists:

General Discussion:gsmp@revnetworks.com
To Subscribe: gsmp-request@revnetworks.com
In Body: subscribe (unsubscribe)
Archive: ftp://www.revnetworks.com/pub/mailing-lists/gsmp-archive

Description of Working Group:

The General Switch Management Protocol(GSMP)has been available to the IETF community for several years as an informational RFC. As several vendors are beginning to deploy GSMP, there is now a need to standardise the protocol.

GSMP provides an interface that allows a router to control a label switch. The GSMP interface provides the commands necessary for: switch configuration control and reporting, port management, connection control, QoS and traffic engineering control and the reporting of statistics and asynchronous events.

The working group is responsible for standardising the GSMP protocol itself, as well as for defining an encapsulation for running GSMP over IP. The current GSMP V2 set of message types will be expanded to include support for various types of label switches including ATM and Frame Relay. The working group will refine the support for QoS and traffic engineering in GSMP based on the diffserv and intserv architectures and will co-ordinate the work with these WGs where appropriate.

Finally, since GSMP can be used as an adjunct to the MPLS protocol, the group will co-ordinate with the MPLS group to make sure that the primitives required by a MPLS controller are available in the protocol.

Goals and Milestones:

Apr 99


Define an IP encapsulation for GSMP messages

Apr 99


Extend GSMP message types to allow support of non-ATM Label Switch devices

Aug 99


Refine the support for QoS models in GSMP

Nov 99


Define an approved GSMP MIB

Nov 99


Define approved mechanisms for security and authentication in GSMP

Dec 99


Produce a version of the GSMP which has the consensus required for entry onto the standards track.


No Request For Comments

Current Meeting Report

IETF 45 - GSMP Working Group

The meeting was chaired by Avri Doria.
The minutes have been provided by Kenneth Sundell and Avri Doria.

The meeting was divided into 2 sessions. The first session was devoted primary to a review of ongoing work, while the second session was dedicated mostly to a review of the requirements for switch control protocol which had been submitted by the Multiservice Switching Forum (MSF).

Session One
Changes to GSMP Specification

During session 1, a major part of the time was devoted to a review of the specification changes which had been made since the last meeting. Tom Worster presented a change by change review of the modifications made to the GSMP V3 specification since the last meeting.

Open issues

Avri Doria and Tom Worster jointly presented the issues that are currently open.

Label ranges:
- It was questioned whether label range manipulation should be used as described in the GSMPv2 specification. The issue was brought up since the GSMP charter allows other switch types than ATM.

Other label types:
- There is a need for volunteers with Frame Relay switch and MPLS experience to enhance the GSMP specification with non-ATM label types. Tom Worster volunteered to put label support for PPP into the specification. But the working group needs help from contributors with experience as well.

Extended label:
- The extended label types are currently 48 bits long. It was questioned if this is good enough for the future. Do we need them at all? It was decided to leave them for the next revision of the specification.

- The GSMP needs to have a mandatory security method. The Routing co-AD said that while security is required the TCP MD5 signature is not good enough. He will check with the IESG if IPSEC is needed in a protocol such as GSMP.

Two-Stage Connection Set-up:
- Tom addressed the issue of the two-stage connection set-up (as in MPLS down stream on demand), where the resource reservation is granted in the label request message and the downstream label is allocated in the label mapping message. He will suggest a resource reservation message in the GSMP protocol.

Registration of well known numbers:
- Registration of well known numbers in the protocol. Avri indicated she would check on the procedures for asking IANA to assign numbers used for service capability sets, optional model types and possibly other numbered entities in the protocol.

Support structure for optional abstract or resource model.

Avri Doria presented the <draft-doria-gsmp-option-arm-01.txt> draft. The intention was to include the optional abstract or resource model into the GSMP specification. Avri presented the changes in the configuration request and response (introducing MTypes) messages. She also described the service selector update. The branch bit will be removed so the service selector field will extend over all 32 bits. There were no opinions about that change, and no objections for including the I-D into the GSMP specification.

QGSMP protocol

Constantin Adams, gave a brief presentation about qGSMP. The qGSMP provides a QoS resource model (in terms of addressing, buffer space and bandwidth) and is build upon the GSMPv2. The work is done within the IEEE PIN1520 and the I-D <draft-adams-gsmp-qgsmp-00.txt> is submitted to the IETF in order to get RFC'ed. The rough consensus during the first session was that the I-D should be best suited as an informational RFC. But during the second working group session, Loa Andersson brought up the question again. He meant that the specification was created by another body and should not be a product of IETF.

The model type proposal calls for the existence of a separate document to document all the protocol details necessary for implementation of the model. There remains uncertainty over whether there is a need for such model specifications to also become part of the standard's process or whether it was sufficient for the definitions to be assigned IANA numbers that reference a specific document, either the standard of another standardization group or perhaps even an informational RFC. Avri undertook the task of learning, either from the ADs or from an existing IETF procedure RFC, the proper procedure.

Milestone walkthrough
- The IP encapsulation is done by the addition of the TCP encapsulation sections.
- The non-ATM label types milestone is unfortunately not completed.
- The refinements of support for QoS models are almost done. The definition for Differentiated Services is still missing.
- Regarding GSMP MIB, nothing is yet started. The "old" Ipsilon MIB will be submitted as a start if nothing else is started within the next couple of months. Volunteers for the MIB work are being sought.
- Three documents are needed before a WG last call can be issued; applicability draft, GSMP draft and the GSMP MIB. Avri has agreed to produce an updated applicability draft by the next IETF.

Second session
Introduction of Topic

Session 2 was primarily dedicated to the review of the I-D contributed by the MultiService Switching Forum that contained their requirements for a switch protocol. The MSF, a body dedicated to arriving at implementation agreements which satisfy the needs of carriers offering multiservice networks, had decided at its last meeting to base its switch control protocol implementation agreement on the work being done at the IETF on GSMPv3.

After a presentation on the goals and requirements of the MSF by Jim McEachern, there was a presentation by Kenneth Sundell comparing the capabilities of GSMP against the MSF requirements. These fell into the following categories:

- requirements believed to be satisfied
- requirements believed to be partially satisfied
- requirements believed not to be satisfied
- requirements that need further explanation

The group then discussed the response which should be made to the MSF Switch Control working group. Basically the group reached consensus on the notion that support of the requirements was definitely within the GSMP WG interest. It was decided that the Kenneth Sundell and Avri Doria would take the presentation mentioned above and create a response to the MSF based on it. It was also agreed that this response would request further explanation on requirements that were not adequately understood and that it would solicit MSF contributions, in the form of either I-Ds or WG mail list discussions, on ways to resolve issues in categories b & c. This response, in the form of an I-D, is to be submitted to the Working Group within the next several weeks, and once the mailing list reaches rough consensus on its contents it will be forwarded to the MSF as a contribution.

It was implicit in the discussion that all work on satisfying MSF requirements needed to be done before the next IETF since after that meeting there is the intention, and hope, of sending the GSMP specification out for working group last call as mandated by the group's current charter. Any items which cannot be resolved in that time frame will be considered as work items in a charter revision which will be discussed at that meeting.


Support Structure for Optional Abstract or Resource Models
Service Control Interface Requirements Multiservice Switching Forum (MSF) Contribution
The qGSMP Protocol
Discussion of MSF SCI Requirements
GSMP Specification