Last Modifield: 06/25/2002
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.
|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|
|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)|
General Switch Management Protocol (gsmp) Thursday, November 21 at 1300-1500 ================================== CHAIRS: Avri Doria <email@example.com> Kenneth Sundell <firstname.lastname@example.org> 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