2.7.2 General Switch Management Protocol (gsmp)

Last Modified: 2003-06-13

Avri Doria <avri@acm.org>
Kenneth Sundell <ksundell@nortelnetworks.com>
Sub-IP Area Director(s):
Bert Wijnen <bwijnen@lucent.com>
Alex Zinin <zinin@psg.com>
Sub-IP Area Advisor:
Bert Wijnen <bwijnen@lucent.com>
Technical Advisor(s):
Allison Mankin <mankin@psg.com>
Mailing Lists:
General Discussion: gsmp@ietf.org
To Subscribe: gsmp-request@ietf.org
In Body: subscribe (unsubscribe)
Archive: ftp://ftp.ietf.org/ietf-mail-archive/gsmp/
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
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. The working group will develop extensions to GSMP to
support dynamic switch portioning. 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 work would allow
network operators to dynamically open their forwarders (optical, TDM,
and other switch types) to multiple administrative domains of control.
The working group will also see what is achieved by using available
management tools, e.g. MIBs to monitor and control dynamic switch

- 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:
Done  Define an IP encapsulation for GSMP messages
Done  Extend GSMP message types to allow support of non-ATM Label Switch devices
Done  Refine the support for QoS models in GSMP
Done  Define an approved GSMP MIB
Done  Define approved mechanisms for security and authentication in GSMP
Done  Produce a version of the GSMP which has the consensus required for entry onto the standards track.
Done  Analyze role of GSMP for control element separation and make recommendation as to a separate WG for extending GSMP for this
Done  Document requirements for control of switches supporting optical, TDM and other CCAMP features
Done  Document requirements for switch partitioning and determine whetherto recharter to extend GSMP capabilities to meet these
Dec 02  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
Jun 03  Submit GSMPv3, its extensions and MIBs for Draft Standard
Jun 03  Conclude Working Group
  • - draft-ietf-gsmp-reqs-06.txt
  • - draft-ietf-gsmp-optical-spec-02.txt
  • - draft-ietf-gsmp-v3-base-spec-02.txt
  • - draft-ietf-gsmp-packet-spec-01.txt
  • Request For Comments:
    General Switch Management Potocol(GSMP) V3 (RFC 3292) (318983 bytes)
    GSMP Packet Encapsulations for ATM, Ethernet and TCP (RFC 3293) (18206 bytes)
    General Switch Management Protocol Applicability (RFC 3294) (18294 bytes)
    Definitions of Managed Objects for the General Switch Management Protocol (GSMP) (RFC 3295) (95516 bytes)
    Requirements for the Dynamic Partitioning of Switching Elements (RFC 3532) (25119 bytes)

    Current Meeting Report

    GSMP Working Group minutes IETF57
    Notes taken by Jonathan Sadler.
    The meeting was chaired by Kenneth Sundell and was scheduled for an hour. 
    Topics covered included:
    - changes to the Base GSMP document including
      o  Triggered add
      o  Block add
      o  removal of technology specific content
    - changes to the Packet spec
      o Label Type ranges updated
      o Stacking Section removed
      o Capability sets added
    - changes to optical spec
      o reservation message for recovery
      o addition of technology specific block for recovery
      o add of new short message for data burst
      o discussion about terminology following what is being done in ccamp for 
    Comment:  There are some difference developing between the docs.  There was 
    an open meeting schedule for later in the IETF week to discuss the docs. 
    Editors requested to attends with other being welcome.  Details of the 
    discussions to be  discussed on the mailing list.  All provisional 
    decisions to be discussed and confirmed on the WG mailing list.
    - Discussion on Capability sets
      o each technology to have it own section and range of values
      o discussion of keeping it a fixed size or making variable.
        - opinions in favor of variable size especially for multi-layer 
        - issue to be resolved on mailing list.
    - Discussion of triggered add message
        o quiet room
        o WG list to be asked again if the message will do
    - Discussion of bulk add message
        o predominant question of whether this form of the message meets the 
    requirements in the requirement document.  List to be inquired.
    - Discussion of protection
        o 1+1 added as argument to Add Branch
        o other modes still need solution.
        o issue to be discussed on the 


    Document Issues
    Multi-layer port support in GSMP