NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 29-Feb-00
Chair(s):
Avri Doria <avri.doria@nokia.com>
Kenneth Sundell <ksundell@nortelnetworks.com>
Routing Area Director(s):
David Oran <oran@cisco.com>
Rob Coltun <rcoltun@siara.com>
Routing Area Advisor:
Rob Coltun <rcoltun@siara.com>
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 General Switch Management Protocol(GSMP)has been available to the IETF community for several years as an informational RFC. As several vendors are beginning to deploy GSMP, there is now a need to standardise the protocol.
GSMP provides an interface that allows a router to control a label switch. The GSMP interface provides the commands necessary for: switch configuration control and reporting, port management, connection control, QoS and traffic engineering control and the reporting of statistics and asynchronous events.
The working group is responsible for standardising the GSMP protocol itself, as well as for defining an encapsulation for running GSMP over IP. The current GSMP V2 set of message types will be expanded to include support for various types of label switches including ATM and Frame Relay. The working group will refine the support for QoS and traffic engineering in GSMP based on the diffserv and intserv architectures and will co-ordinate the work with these WGs where appropriate.
Finally, since GSMP can be used as an adjunct to the MPLS protocol, the group will co-ordinate with the MPLS group to make sure that the primitives required by a MPLS controller are available in the protocol.
Goals and Milestones:
Apr 99 |
|
Define an IP encapsulation for GSMP messages |
Apr 99 |
|
Extend GSMP message types to allow support of non-ATM Label Switch devices |
Aug 99 |
|
Refine the support for QoS models in GSMP |
Nov 99 |
|
Define an approved GSMP MIB |
Nov 99 |
|
Define approved mechanisms for security and authentication in GSMP |
Dec 99 |
|
Produce a version of the GSMP which has the consensus required for entry onto the standards track. |
Internet-Drafts:
· General Switch Management Protocol
· Definitions of Managed Objects for the General Switch Management Protocol (GSMP)
No Request For Comments
Minutes GSMP Working Group, Adelaide 3/30/00
--------------------------------------------
The meeting was co-chaired by Avri Doria and Kenneth Sundell and was divided into two sections; the review of current documentation and the discussion about future work items for the working group. The minutes were taken by Kenneth.
Changes to the three standards track documents currently being worked on were discussed. While there were several editorial and minor technical comments on the drafts, there were no major technical objections. The plan is to update the documents, fixing known problems by the end of April and then to have a WG last call during May.
1. Review of draft-ietf-gsmp-04
Avri presented the changes since revision 02. Revision 03 was issued before the editing session in New Orleans (Feb 3), while revision -04 was released after that session. Since the differences between 02 and 03 has not been
presented at an IETF meeting, though they had been presented on the mailing list, the co-chairs decided to present all changes from 02 to 04 in this session. There will be at least a revision 05 before the document will proceed to working group last call.
The encapsulation section was, as previously agreed, moved to a separate document, draft-ietf-gsmp-encaps-00.txt.
All failure response messages were gathered and moved to appendix A.
The 04 introduced the notion of TLV Labels, i.e. labels that are longer than 28 bits. For clarity, the notion of extended label has changed to stacked label.
The 03 introduced the reservation message which allows for resources to be reserved for a connection before the actual label mapping is known. Revision -03 also included support for redundant adjacencies.
A proposal for adding output/input service selectors in the Add Branch message had been discussed on the list and also proposed at the New Orleans editing session. The capability was added to 04.
Other additions to 04 included: a simple mechanism for turning of the flow control, a way to do multicast queries in order to support those switches that have dedicated ranges of labels for multipoint connections, support for discontinuous label ranges, the addition of event sequence numbers and event flags to the port configuration message.
Additionally, the service model was updated to include support for Circuit Emulation Services (-04).
2. Review of draft-ietf-gsmp-mib-01 (15)
Joachim Buerkle presented the updated GSMP MIB that is co-authored by Hans Sjostrand and Balaji Srinivasan.
The GSMP MIB was totally rewritten. The GSMP MIB is focused on the protocol and not covering partition issues. Joachim pointed at work done in MSF where they are producing a protocol independent partition MIB. He went through the different GSMP MIB objects (slides will be available in the proceedings).
There was a question about whether the structure of multiple controller to a single switch partition should be represented in the MIB. The answer was yes.
The document will be updated during April. Updates in the next version will be mainly changes in wordings, some new tables and maybe addition of statistics into the MIB.
3. Review of draft-ietf-gsmp-applicability-00.txt
Avri presented the applicability draft. There is a minor set of documents that are needed before we can proceed to IESG group last call. Apart from the GSMP specification, GSMP MIB and GSMP Encapsulation documents, an informational RFC for GSMP applicability is needed. The document introduces the reader to concepts and notions that are used within GSMP e.g. switch partitioning, controller/switch interaction and service support.
A question about the MSF's role in relation to GSMP was raised, i.e. where they defining their own version of GSMP. Avri answered that IETF is defining the protocol and MSF will be referencing the RFC in its implementation agreement. Joachim clarified that MSF draft applicability documents are not publicly available until they have been approved for release by the membership.
The minimal set of messages needed to support MPLS was discussed. The applicability document list the messages required for minimal MPLS support.
4. Security issues in draft-ietf-gsmp-encaps-00
The main content of the encapsulation draft was moved from draft-ietf-gsmp-02.txt. A security section has been added to the document. A change that needs to be made to that draft involves requiring the support of IPsec when the IP encapsulation is used.
5. Working Group Last Call
Text revision of the GSMP spec will be due in approximately 3 weeks. The GSMP MIB co-authors will try to make a new revision within the next 3-4 weeks. It is very important that people read the documents and send appropriate comments on the list. Non technical editorial changes should be sent to the authors directly.
A two weeks WG Last Call will be issued in the beginning of May.
6. Implementation Experience
Joachim Buerkle of Marconi communications (wireline access system) presented on their work with GSMP. They have produced I-Ds on resource reservation, move output branch and GSMP MIB. In their implementation they are using the ATM encapsulation and implementing the ATM specific features.
There were questions about interoperability. A lot of people say that they are implementing GSMP, but only a few have done this in public. Service providers are soliciting products.
7. Discussion of charter update
The group then spoke about future activities. Unless the charter is redefined, the working group will go dormant after the last call until implementations and implementation issues crop up. A discussion was held to determine whether there was real interest in adding additional features to GSMP beyond those currently planned. Several different possibilities where discussed.
7.1 Requirements for GSMP support of Optical switching
A presentation was made on using GSMP for controlling Edge nodes, and optical interconnects within an IP over optics environment. This presentation was essentially a repetition of one given earlier in the week at the IPO BOF, though it did focus more on the changes required in GSMP then on the possibilities for optical network control. Basically, a controller/router could control an OXC over GSMP, either through use of an out of bound network or via a dedicated "control" wavelength.
New label TLVs were introduced to handle label types such as fiber bundle, arbitrary number fibers in that bundle, a single fiber, arbitrary lambdas in that fiber, a single lambda etc.
Several questions were raised; whether we need a raw optical encapsulation for GSMP messages or if we should require use of the IP encapsulation, whether we need one single TLV or several for accommodating the different types of optical labels and whether there was an existing service model for optical switches which GSMP could use or would the group need to define one.
7.2 Future Requirements for GSMP
Several other proposals for new work were discussed:
- Add support for SDH port types.
- Investigate a rework of the flow control mechanisms in GSMP.
- Add support for switching IP packets (L3 switching). Part of the support for this already exists in the protocol, but many of the elements which would be required, are still lacking. This effort would probably require a requirements effort first.
- Continue tracking work on QoS service models.
7.3 Conclusion
There was definite interest in continuing the work of the WG. In fact instead of having a passive (i.e. does anyone object to continuing work on these and similar items), we had an active show of hands on whether folks thought these issues were worth pursuing. Of those voting, and approximately 2/3 voted, there was a clear consensus for continuing the group. The intention is the chairs discuss a specific charter amendment on the list before making the formal request to the IESG.
In terms of vendors and service providers interested in seeing the work continuing, there was positive interest from several companies.
Agenda
Applicability
Encapsulation
What comes next?
Requirements for adding Optical Switch Support to GSMP