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 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|
Current Meeting Report
Minutes GSMP WG 52nd IETF, Salt Lake City December 2001
Chairs: Avri Doria <firstname.lastname@example.org>
Kenneth Sundell <email@example.com>
Note taker: Kenneth
The meeting was chaired by Avri. The meeting was divided into three parts; Status report of the documents in IESG review/IETF last call; Status report from the design teams and update of the milestone dates.
Documents in IETF Last call or under IESG review
The meeting started with a status report of the documents on the IESG's desk.
draft-ietf-gsmp-10 got one issue
draft-ietf-gsmp-encaps-04 (three issues)
draft-ietf-gsmp-applicability-03 (no issue)
Kenneth went through the gsmp spec issue and how it was resolved. There were no comments on the proposed change that was editorial. The Area Director present also thought that the solution was reasonable.
Avri presented the three issues with the encaps draft and proposed changes at the same time. One of the issue raised by the IESG was about the 2-byte type field indicating the type code for GSMP messages. The question was if there will be any other type in the future. The answer was no, since this field is used for demarkation of individual messages in TCP stream , it is not expected to be any other. It was ok'ed by the Area Dirctor.
The second and the third issue concerned how security was addressed in the encaps draft. Issue #2 pointed at chapter 4.2, where the security recommendations were regarded as weak. The spec has been updated with MUST AH and MUST ESP. There was a comment at the end of the meeting that MUST AH might be a problem, since it might not be used in most cases. The AD agreed to this so the AH recommendation was removed. The AD present also suggested that the word secrecy should be replaced with "integrity and confidentiality". That change was made online. The text was changed to the following:
"When GSMPv3 is implemented for use in IP networks, provisions for security between the controller and client MUST be available and MUST be provided by IP Security [IPSEC]. In this case,the IPSEC Encapsulation Security Payload (ESP) MUST be used to provide both integrity and confidentiality"
And the third issue about security for ATM and Ethernet was resolved by the following text (chapter 5):
"The security of GSMP's TCP/IP control channel has been addressed in Section 4.2. For all uses of GSMP over an IP network it is REQUIRED that GSMP be run over TCP/IP using the security considerations discussed in Section 4.2. Security using ATM and Ethernet encapsulations MAY be provided at the link layer. Discussion of these methods is beyond the scope of this specification. For secure operation over any media, the IP encapsulation with IPsec SHOULD be used."
The AD advised the chairs to advertise the text change simultaneous with getting the next draft out. During this time, comments could be invited from the list. If no substantive comments on sections 4.2 and 5 were received during a two week period then the document could go back to the IESG for approval without need for another last call.
The GSMP MIB is in IETF last call which expires December 24th. The IESG has reviewed the MIB and there have also been SNMP specialists involved, so it is expected that the MIB is in a good shape.
Status Report From the Design teams
There are three GSMP design teams working on tasks beyond the base documents. The Optical Requirement design team has not progressed much. The idea is to reconstitute the design team. They should take on the draft-ietf-gsmp-reqs-00 document and enhance it with new thoughts. Volunteers to join the team are welcome, please send an email to either of the co-chairs. The work should be done by the Minneapolis meeting in march 02.
Jonathan Sadler presented the optical requirement design team efforts so far.
Possible GSMP enhancements:
1. Better Slot/Port definition (Bay/Shelf also needed)
2. Better Bidirectional support
Use in Move branch, Delete branch -- need atomic behavior
3. Better Port Capability identification (needed to find stack of supported TTP/CTPs)
Should be consistent with Neighbor Capability Exchange approaches (i.e. LMP)
Should be consistent with Link attributes used in Routing
4. Need to identify how to number points in the potential sub-multiplex tree
Use convention in iftable?
Or should points be refered to via root-ifindex:label, and partitioning instantiates new root-ifindexes?
5. Better Node Capability identification
Support for LCAS?
6. Need to allow minimal Port configuration in addition to Matrix Connection configuration
7. How should blocking switch fabrics be handled?
8. Better Path Switching support
Need to allow preconfiguration of selector allowing actions independant of controller
9. Rectify how B and R flags interact, since Bidirectional links are a fundamental unit in TDM nets
10.Remove "Layer specific" messages, i.e. ATM VPC Add/Move*/Delete Branch
11.Partitioning at "any layer" (not just port specific partitioning)
12.Generalize Statistics Messages (ie ATM vs Frame)
13.Clarify use of Port/Line Status so it corresponds w/ TDM
- Administrative/Operational state
- Clarify interaction with Port Up/Down Events
14.Support for transport over OSI TP1 or TP3, and SCTP
15.Need to correlate Events and only send root cause Event messages
The Dynamic Partition team is almost there. Avri presented some proposed updates to the requirements document. The first issue was about terminology, she proposed a change from Network Element (NE) to Physical Device (PD) in order to avoid confusion with the terminology at the forces wg. The change was accepted. The other proposal was to change the one-to-one cardinality to one-to-many in order to allow for multiple controllers per partition. There was a comment from the author that this was done for simplicity and that the scheme was describing logical relationships. Avri and the author agreed that this could be interpreted in two different ways, so the agreed that a clarification was needed. The next steps for this documents is to proceed to working group last call since the document is done. And if accepted, submit to the IESG with a charter request.
Milestone Discussion and Update
The last part of the meeting was to discuss the milestones in the charter. Proposed new dates were:
- Document requirements for control of switches supporting optical, TDM and other CCAMP features:
May 01 -> March 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:
Aug 01->Sept 02
- Document requirements for switch partitioning and determine whether to recharter to extend GSMP capabilities to meet these:
Sept 01-> Done?
- If requirements process has convinced ADs/IESG, produce GSMP extensions and MIBs to support dynamic switch partitioning:
Dec 01->March/June 02
- Submit GSMPv3, its extensions and MIBs for Draft Standard:
June 02->Dec 02
The meeting was adjourned by Avri
Issues with Partition Requirements