2.7.2 General Switch Management Protocol (gsmp)

NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01


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

Sub-IP Area Director(s):

Scott Bradner <sob@harvard.edu>
Bert Wijnen <bwijnen@lucent.com>

Sub-IP Area Advisor:

Scott Bradner <sob@harvard.edu>

Technical Advisor(s):

Allison Mankin <mankin@isi.edu>

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 base General Switch Management Protocol (GSMPv3) protocol has been submitted to the IESG with the request that it become a proposed standard. Currently the GSMP protocol provides switch configuration control and reporting, port management, connection control, QoS and traffic engineering control and the reporting of statistics and asynchronous events for MPLS label switch devices, all either from or to a third party controller.

The working group is responsible for completing the standardization of the GSMP protocol by responding to protocol issues that arise during implementation of the current specifications.

Additionally, the working group is responsible for augmenting the protocol as follows:

- Support for Optical and Other Extensions and CCAMP Features

The architecture of some optical, TDM, spatial and other switch types makes the ability to remotely control the connection state of a switch important. GSMP has been designed especially for such remote control operations. GSMP is, however, currently lacking in the specific semantics necessary for switches with some new technologies, especially in the optical space. The WG will collect requirements and define solutions to support optical and other new switching technologies, compatibly with the common control and measurement protocols WG (CCAMP) work. This work will be done in cooperation with the other Sub IP Working groups involved in this area.

The extensions will include definition of new instances of "labels" (for instance lambda identifiers) as needed, to support the usage in the new technologies. They will also include definitions of port types, of service definitions and of traffic parameters.

- Switch Partitioning

The current version of GSMP is designed to work with a static switch partition. Recently, some regulatory environments (on multiple continents) have mandated multi-provider access to the same physical infrastructure. Therefore, this work should allow network operators to dynamically open their forwarders (optical, TDM, and other switch types) to multiple administrative domains of control. As a result, the WG will analyze requirements for dynamic switch partioning with GSMP and determine if GSMP should be extended to support them. This work would be to adapt GSMP to work with multiple partitions in which resource allocation is dynamic and variable between the switch partitions. This would be achieved by using available management tools, e.g. MIBs (possibly PIBs), as well as potential extensions to GSMP.

- Relationship to Forwarding and Control Element Separation

The WG will conduct a brief (one-meeting) analysis of the potential use of GSMP in mechanisms that allow third party network processors in switch architectures. The output will be an agreement of the likely scope for a distinct WG that might be using GSMP for this purpose.

Goals and Milestones:



Define an IP encapsulation for GSMP messages



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



Refine the support for QoS models in GSMP



Define an approved GSMP MIB



Define approved mechanisms for security and authentication in GSMP



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



Analyze role of GSMP for control element separation and make recommendation as to a separate WG for extending GSMP for this

May 01


Document requirements for control of switches supporting optical, TDM and other CCAMP features

Aug 01


Submit GSMPv3 extensions to include control of switches supporting optical, TDM and other CCAMP features and any updates of the base spec for Proposed Standard

Sep 01


Document requirements for switch partitioning and determine whetherto recharter to extend GSMP capabilities to meet these

Dec 01


If requirements process has convinced ADs/IESG, produce GSMP extensions and MIBs to support dynamic switch partitioning

Jun 02


Submit GSMPv3, its extensions and MIBs for Draft Standard

Jun 02


Conclude Working Group

No Request For Comments

Current Meeting Report

CHAIRS: Avri Doria (avri@nortelnetworks.com)
Kenneth Sundell (ksundell@nortelnetworks.com)

Notes: John Noerenberg

1. Agenda bashing
2. Reports on status of drafts submitted to last call
2.1. draft-ietf-gsmp-09 (Kenneth Sundell)
2.2. draft-ietf-gsmp-encaps-03 (Avri Doria)
2.3. draft-ietf-gsmp-mib-05 (Joachim Buerkle)
3. Design Team Overview (Avri)
3.1. Report from Optical requirements design team
- draft-ietf-gsmp-reqs-00 (Avri)
3.2. Report from Specification design team
-no draft (Jonathan Sadler)
3.3. Reports from Dynamic Partitioning design team.
- draft-ietf-gsmp-dyn-part-reqs-00 (Joachim)
4. Change of Message Format
- draft-kullgren-gsmp-message-format-00.txt
(Georg Kullgren)

1. Angenda bashing
- No additions or changes to the Agenda

2. Reports on status of drafts submitted to last call

2.1 draft-ietf-gsmp-09 (kenneth)

The changes were folded into two categories; editorial and more substantive changes. Among the editorial there were contributors added, some cleanups and addition of clarifying text, especially in the adjacency protocol chapter. The clarification consisted of explanation of the rules and also some examples were added. The rules are still unchanged.

More substantative changes included (as shown in the slides):
- Added event sequence number (all port config ch. 8.3) in order to align with chapter 8.2.
- Re-shuffeling some fields in chapter 8.2, 8.3 and 8.4 after request from implementors.

Changes may or may not require new WG Last Call. The AD's replied that the decision is up to the working group. There has not been any responses from the mailing list so far. There was a rough consensus in the room that the changes were accepted (by humming).

The IANA Section is still on the IESG's plate. The Security Considerations need elaboration. The next version should contain an addition stating that TCP is a must if there are more than one hop between the controller and the controlled.

A new version will be added after the London meeting.

2.2 draft-ietf-gsmp-encaps-03 (avri)

There were a minor set of issues that still were needed. The usage of terms defined in rfc2119 (e.g. MUST and MAY)should be added. The usage of FCS, that is a standard ethernet definition remains in the document for historical reasons. The port# assignment origin needs to be clarified in the iana considerations. Also a reference (url) to iana should be updated.

A new version will be submitted after the London meeting.

2.3 draft-ietf-gsmp-mib-05 (joachim)

There were a number of minor editorial changes (the document includes a revision history chapter that will be removed when the spec enters rfc state. New for this version is that the mib now allows for future gsmp encapsulation types. There was also a clarification added to point out that MapNotification should be seen as a complement to rfc2573 (filter application) rather than a duplication. Addressing scope has been made more sensible. The WG attendees agreed that the changes were not substantive.

The AD present commented on iana consideration, it should be added if missing. Also a remark that the rfc-editor wants a final revision instead a list of changes. That was agreed.

3. Chair comments on design teams (avri)

This part of the meeting was a status update from the gsmp design teams. The Optical requirements design team has issued the draft-ietf-reqs-00, needs more contributors. Report from the Specification design team, currently there are two people; optical architect and an implementer. Chair wants 2nd implementer.

3.1. Draft-ietf-gsmp-reqs-00 report (avri)

Previous meeting made draft-doria-gsmp-req-olsr-01.txt to a working group document. Comments from the Last meeting included question if there were any overlaps with ITU work on OXC's, e.g. the ASTN's CCI s/b standardized. ITU Steve Trowbridge ITU SG 15 vice-chair was present in the meeting room. Will discuss with chairs.

The new version adds support for G.709 and PDH labels and also tentative support for link bundles.

It would be useful to direct the use of OXC based Restoration capabilities. This would change the relationship between the master and the slave. Renamed reserved to dedicated.

GSMP AddBranch was extended to specify input/output branch for dedicated protection link.

The following will be considered in the next versions; SONET/SDH payload support to be added and Bundle support to be added.

We need more implementer input.

3.2. Specification design team (jonathan)

Protocol extensions for optical, plus implementation experience (added to -09 draft). Some structures were reordered for simplifying implementation.

Among isssues; Support current optical equipment flexibility, Multiple layers supported where each layer is independent, Gsmp must be able to label control messages. Trail termination types need to be identified. Example of SONET/SDH given. Result will be protocol extensions.

No draft is available yet but will be out before next IETF

3.3. Reports from Dynamic Partitioning design team (joachim)

To answer if charter to be amended to include. Added description at introduction. Clarifications from previous revisions. The scope is more carefully defined now. Specified relationship between Partition manager, Network element (Partitions) and Controller. Partitioning requirements updated. The gsmp working group needs to read and review. The Chairs exhortation for participation.

The Draft is intended to become an Informational RFC.

4. GSMP message update

George is an implementer and had some issues regarding message structure with sizeable fields.

He requested re-ordering Label field to simplify structuring and make the performance/parsing more efficient. The label fields should be placed in the end of the structure. The attendees adopted the request by nodding heads. Please speak up on the mailing list if there are any opinions regarding the change.

A discussion of message length was brought up earlier on the mailing list. The message length field currently includes the gsmp header and the gsmp payload, but doesn't cover vendor specific fields following. The idea is to cover the complete message including vendor specific data. The consensus in the room (nodding heads) was that the suggestion should be progressed. The matter needs to be discussed on the list and implementers need to experiment.

There was a recommendation the the WG hold another last call on these changes since some of them, especially the message length definition could be seen as a substantive technical change. The WG accepted this recommendation.

The kullgren draft changes should be folded into draft-ietf-gsmp-10 together with the length field. There will be a working group last call issued on changes between -09 and -10 version as soon as -10 is available. Kenneth will send out a new revison after the meeting.

There were no other business to be discussed. And the chairs asked the crowd to read and comment the documents.

Session was adjourned.


GSMPv3 Spec Updates
Definitions of Managed Objects for the General Switch Management Protocol (GSMP)
GSMP Message Format
'draft-ietf-gsmp-encaps-03' - Issues
Requirements for adding Optical Switch Support to GSMP