2.4.1 General Switch Management Protocol (gsmp)

NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00


Avri Doria <avri@nortelnetworks.com>
Kenneth Sundell <ksundell@nortelnetworks.com>

Routing Area Director(s):

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

Routing Area Advisor:

Rob Coltun <rcoltun@redback.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

The GSMP working group held a meeting at IETF48. The meeting was chaired by Kenneth Sundell, and notes were taken by Hans Sjostrand and by Avri Doria.

There were 2 main areas of discussion and 2 technical I-Ds presented.

Last call was initiated on 21 July and is scheduled to terminate on 18 August. The reason the last call was made longer then the required 2 weeks was to accomodate folks attending the IETF who did not have time to review the material. Additionally the MSF is doing its 'WG last call' equivalent on the same documents at the moment. Their review is also slated to end on 18 August. After that the documents will be recycled to handle all the editorial issues, and if there are no new substantive issues, will be passed along to the IESG for the continuing process. If there are technical issues, the affected docs will go through another WG last call. All 4 documents will be passed on as a set.

Avri Doria did a review of:


There were two substantive changes made between -05 and -6. The first was the additon of the replace flag in the add branch command. This flag was added to accomodate some traditional telephony switching systems. The second change was the removal of Diff Serv support from the service model chapter. This was removed becasue there were no suggestion on how this would be used. Support for Diff Serv service model can be added to GSMP at a latter time in a separate document.


Changes between -01 and -02 were all editorial in nature.


Changes between -00 and -01 were all editorial in nature.

Hans Sjostrand did a review of draft-ietf-gsmp-mib-02.txt

Quite a few changes were made between -01 and 02. These consisted primarily of: a new structure where VSCE, VSE and session data was separated, encap got theis own MIB groups and 10 notifications were added. The new object structure was presented to the WG.

There is a problem with notification object as described in the draft. The proposed solution is to add extra notification objects.

No comments from the floor on this issue.

There where some last call comments, from people that had experience with getting mibs through IESG. Ipv4 specific stuff has to be generalized to support Ipv6 and storage type has to be clarified.

The mib will be updated with the last call comments in a -03 version which will be out in a few weeks time.

During the discussion, Hans noted that the GSMP archive is not fully working, i.e. it's not possible to retrieve the August file. Avri promised to check up on that.

Avri presented a proposal, which has been sent out to the list.

With the submission of the current WG docs to the IESG the WG milestones will be met. There are two alternatives:

The discuyssion for the re-charter included:

This was discussed in the group and there is very strong interest in seeing it done. The primary argument for doing the work concerned the fact that some optical switch vendors are putting so much focus into the optical layer that they don't really have the resources necessary to add the IP superstructure into their products. It may also not be apprpriate to do so in all cases. Using GSMP to do this seems reasonable. Avri mentioned that she had spoken to Jim Luciani (one of the co-chairs of the proposed IPO group) about this and indicated that he is agreement with the GSMP WG taking on this work.

Statement from the floor; GSMP is today only of interest for the vendors who doing both HW and SW, the small optical startups have no clue of SW, so it should be boosted by them. Avri responded that the carriers are also picking up some interest and that GSMP is used within MSF which architecture corresponds to GSMPs. But that she agreed that this should be of interst to Optical vendors.

There has been a call from some service providers and vendors for GSMP to support switch partitioning. This could be done either within the GSMP protocol or a-priori by a MIB or PIB. In either case to make switch partitioning dynamic would require GSMP support. It was mentioned that if this task is approved as a GSMP work item it will require cooperation with the VPN BoF/WG to understand the requirements.

Question from the floor: There was a proposal to use PIBS which are carried by COPS for partioning. It was therefore unclear which protocol the group wanted to use? David Putxolu responded that the authors wanted to raise the interest for the area, we made a pib. This could be adjusted.

Hans commented that the switch partition work item has the character of bottom-up work, and that the GSMP wg should focus on the GSMP and related issues, and avoid become an architectural group to deal with all issues of switch - controller separation. Avri responded that this was true and that the architectural issues would need to be resolved with the cooperation of other groups working on issues of VPN control. Avri also mentioned that the MSF was interested in the problem of switch partitioning and could be counted on to request changes to GSMP to support switch partitioning.

There is a proposal to add suppurt for IP forwarding devices. MSF is adding IP support in their next version, and HW implementations are going to become available. In his presentation David Putzolu argued that this work is best suited for IETF Routing area and that the specific expertise needed currently existed in the GSMP WG.

In additon to the items mentioned above that were part of the formal proposal, several items were suggested by wg members. These consisted of suggestions for other switch support, e.g. SDH/Sonet. These will be added to the re-charter application since there was concensus on doing this. Some discussion will occur on the list to develop the list of device types that should be supported.

There was one comment from the floor that the group should focus on support for Optical Switching alone since this was the biggest opportunity for deployment of GSMP. This was generally not supported, especially by those who suggested that GSMP be extended to support other switch types.

Avri presented some proposed milestones,

Avri asked if there was consensus in the group with proceeding on all the proposed areas. Handraising and humming indicated approval for proceeding on all, with no opposition indicated.

A new charter will be created and posted to the list. First draft on requirement will be introduced into next IETF. The group agreed on that six month for requirements and a year for the extensions were reasonable targets. Operational implementation is coming in due time.

Avri also asked for information about the different implementations. If this information was not confidential it should be posted to the list, otherwise, if it was confidential it could be privately posted to the chairs. This would then be relayed to the IESG, which could be expected to maintain the confidentiality.

Two PIBS were presented; one on switch partitioning and one on IP forwarding. There was some discussion on accepting them as WG work items, but this was put off pending the approval of a new charter.

IP Forwarding PIB < draft-khosravi-ip-fwd-pib-00.txt> - Hormuzd Khosravi

The purpose of the presentation was not to go into the discussion of mibs and pibs, but to guage the interest in GSMP WG. The motivation is offloading the routing protocol computation e.g. on a network processor. Also, MSF will require support for IP. COPS may be useful. The pibs fits well with the gsmp framework.

The actual model is based on the IP forwarding table rfc2096. But stripped to only contain the parts necessary to configure the device to do the forwarding decision. Open issues are IPv6, Multicast and multipath forwarding. Proposal to accept this as a WG item.

Avri responded that even if the group is supportive to the idea, it can't be made a WG item before the recharter.

Multiple Virtual Router Partitioning Policy Information Base <draft-anderson-mvr-pib-00.txt> - Todd Andersen

The work is derived and is largely based on a MSF mib written by the co-authors. The motivation is that MSF is adopting GSMP as reference point, but standard mechanisms to define virtual switches do not exist but are required. NBVPN uses MVR. It was reiterated that the transport mechanism is not important, it's the data model itself that was the focus of the work.

Partitioned resources is bandwidth, buffer space, label space, routing table space, IP addresses. Open issues are: Virtual ports between the VRs. It's also an open issue whether this work should be done in GSMP WG or the potential NBVPN WG.

Avri responded that it is most likely well suited as joint work.

There being no more comments or issues, the meeting adjourned by Kenneth.


Charter Update
IP Forwarding PIB
Definitions of Managed Objects for the GSMP