Current Meeting Report
Slides
Jabber Logs


2.7.2 General Switch Management Protocol (gsmp)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 06/25/2002

Chair(s):
Avri Doria <avri@acm.org>
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):
A. Mankin <mankin@isi.edu>
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 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:
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
MAY 02  Document requirements for control of switches supporting optical, TDM and other CCAMP features
MAY 02  Document requirements for switch partitioning and determine whetherto recharter to extend GSMP capabilities to meet these
SEP 02  If requirements process has convinced ADs/IESG, produce GSMP extensions and MIBs to support dynamic switch partitioning
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
Internet-Drafts:
  • - draft-ietf-gsmp-dyn-part-reqs-02.txt
  • - draft-ietf-gsmp-reqs-02.txt
  • Request For Comments:
    RFCStatusTitle
    RFC3292 PS General Switch Management Potocol(GSMP) V3
    RFC3293 PS GSMP Packet Encapsulations for ATM, Ethernet and TCP
    RFC3294 I General Switch Management Protocol Applicability
    RFC3295 PS Definitions of Managed Objects for the General Switch Management Protocol (GSMP)

    Current Meeting Report

    General Switch Management Protocol (gsmp)
    
    Thursday, November 21 at 1300-1500
    ==================================
    
    CHAIRS: Avri Doria <avri@sm.luth.se>
            Kenneth Sundell 
    <ksundell@nortelnetworks.com>
    
    
    Scribes: Jonathan Sadler and Scott Bradner.
    
    Agenda bashing: nothing changed
    
    WG Status:
    ----------
    Kenneth went through the WG Status. The two requirement drafts have been 
    processed through last call. The RFC3292 has been split into a number of 
    drafts since it turned out to be too complex containing all label and 
    interface types. The division was agreed on at the Yokohama meeting. Two new 
    drafts have been posted to suggest additional Network Management of GSMP. 
    Request has been made by WG to IESG for block on dynamic switch 
    partition extensions to be removed. IESG requested report on 
    implementations.
    Many implementations and some deployments were reported. Scott (AD) will 
    recommend to IESG to remove block in charter.
    
    Requirement Docs
    ----------------
    Avri reported on dyn-part-reqs-03 on behalf of Todd Anderson. Draft was 
    sent in late, missing updated draft submission deadline. Copy has been made 
    available on Avri's web site 
    
    (http://www.cdt.luth.se/babylon/ietf55/d
    raft-ietf-gsmp-dyn-part-reqs-03.txt) 
    All changes requested of past version have been completed. Ready for WG 
    Last Call - call to be made within one week of end of IETF 55 when draft 
    appears at IETF site.
    
    Jonathan reported on gsmp-reqs-04. There has been two updates since 
    Yokohama, integrated optical burst switching requirements, revised sec 7.
    Ready for new WG last call.
    
    MPLS/GMPLS control/management items
    -----------------------------------
    Avri presented two issues with (G)MPLS control/management (also 
    presented to CCAMP WG)
    
    Issue 1: There are too many control paths to control a label switch
    Some of the control paths are MIBS, CLI, GSMP, TL-1, Vendor 
    Proprietary, Service Provider Proprietary etc. No mechanism to 
    coordinate the actions made on the same resource by two (or more) 
    different controllers. Need "feedback" mechanism. 
    Avri proposed that controller needs to keep state and report changes. 
    Support receiving notification from the switch of any changes made.
    Tested sense of the room; half of room said this a good idea, no one 
    opposed.
    
    Issue 2: Are MIBs the best way to control a label switch?
    MIBs for MPLS showing rampant complexity. MIBs starting to challenge the 
    bounds of scalability. GMPLS change may be too dynamic for effective 
    management by SNMP.
    Reconsider use of GSMPv3. Requested CCAMP review optical 
    requirements drafts.
    
    Concerns from the WG:
    Scott B:How do we handle what can and cannot be changed by the other 
    mechanisms?
    Avri: Change can't be prevented, but GSMP better have a way to provide 
    notification of change made.
    Jon S: Dynamic Partitioning draft provides mechanism for controlling which 
    resources GSMP is allowed to change.
    
    
    GSMPv3 Specifications
    ---------------------
    Recommendation at Yokohama was the division of the GSMPv3 spec into parts 
    that dealt with general protocol, and specific applications.
    Avri hopes to get unified look and feel.
    Split of GSMPv3 doc into parts
    - Base
    - Packet Switch
    - L2 Switch
    - Optical
    - TDM
    Merge some of the parts? (Packet + L2) Seems to be support.
    Question: do we need 2 or 4 other docs?
    No comment
    Ken: Makes sense to combine L2 and packet switch capable
    Question: Should we combine optical and TDM?
    Jon: Much in common. Both have to deal with layering - this should be done in 
    a common way. Layering discussion should be in base spec.
    ?******** was this Jon or someone 
    else?****************************
    Jon : Optical and TDM have technology specific parts that can be in 
    separate documents. Prefer to see as separate.
    Question: What about use of GSMP for FORCES now is time to decide if this is a 
    good idea. FORCES has sent out a request for candidate protocols.
    This may also be outside of current GSMP charter.
    No comments - will ask on mailing list, if no worker bees then let slide
    
    Issue 1
    Do tech values belong in base spec? ATM still there or put in 
    technology-specific specs
    Suggestion: Move tech-specific to separate specs, generalize 
    tech-specific left in base specs.
    Examples are TLV label types, ATM specific flags, port types, ATM 
    Specific merge flag, failure response codes. 
    
    Issue 2
    There are also a lot of ATM specifics in the middle of the failure 
    response range. Should they be reorganized with technology 
    independent base and technology specific issues? Do Failure messages need to 
    be localized?
    Scott B: Localization is not an issue for GSMP since protocol is just 
    passing numbers - controller software should handle localization.
    Avri: What about non-english error strings?
    Scott: No need to i18n error strings because people do not see them.
    Ken verified this (just numbers).
    Scott: check to see if ATM is deployed if not then clean them up.
    
    
    GSMP optical spec (Jun-kyun Choi)
    The work was presented.
    Question: Are there any requirements that have been identified for the 
    optical spec that are not in the optical requirements spec? 
    (Autonomous Protection and Restoration, Label formats)
    Jon S: No, these issues are already captured in the optical 
    requirements draft.
    Question: Should there be coordination between GSMP and CCAMP
    Jon S: Some of the things that GSMP will need will be different than what 
    CCAMP needs due to node vs. network scope of operation.
    Scott B: But where they are the same, they should be the same. 
    (Jon S: Agreed)
    Suggestion to start discuss on the ccamp mailing list.
     
    
    Individual Drafts
    -----------------
    
    GSMP management (YoungWook Cha)
    
    GSMP management updated.
    Issue RFC 3295 is for provisioning of GSMP protocol, but not FCAPS
    Can GSMP be used to support Network Management?
    Where is network management function for supporting NM services for NE? 
    Controller or Switch?
    Useful? Should it be a GSMP working group doc?
    Jon S: Concern that this is adding FCAPS to GSMP interface - lots of stuff 
    that doesn't really matter to the controller.
    Avri: However there is a need for management of the 
    controller-side GSMP interface. Consequently, a MIB is needed.
    Dave A: MPLS/GMPLS mibs are "incestuous" with NE and controller items in 
    common places.  Coordination across the GSMP interface is necessary to 
    work.  
    Agent will probably have to be in both places
    Malcom B: Interface should probably be lightweight, and not 
    incorporate FCAPS.
    Dave A: Need to have path up/down indication added to GSMPv3.
    Avri: Is this captured in optical-reqs?
    Jon S: If not, then it will be added.
    
    Will discuss on list.
    
    GSMP service mib (YoungWook Cha)
    Options - new mib for service and events or add to existing mib.
    MIB for GSMP Service needed for Configuration and Partition 
    management.
    Two approaches:
    New GSMP Service MIB + GSMP MIB (RFC 3295)
    Existing GSMP MIB + New GSMP Service MIB w/ Configuration & Partition 
    Management + GSMP MIB (RFC 3295)
    
    
    Report on G.805 (Jon Sadler)
    
    Presentation about G.805. Include model of DS-1 service ITU-T uses 
    different layer concept.  Usage of the model for Optical and TDM specs to be 
    discussed.
    
    End of meeting
    

    Slides

    Agenda
    Network Management for GSMP Interface
    Definitions of Managed Objects for Network Management Services in GSMP Interface
    GSMP V3 Specs
    General Switch Management Protocol (GSMP) v3 for Optical Support
    GSMP Requirements