NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
Avri Doria <avri@nortelnetworks.com>
Kenneth Sundell <ksundell@nortelnetworks.com>
Fred Baker <chair@ietf.org>
Fred Baker <chair@ietf.org>
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
Note: this WG is one of a set of WGs that comprise the 'sub-IP' pseudo-area that the IESG recently created. All of the sub-IP WGs are temporarily being housed in the General Area until the IESG decides on a final management structure for managing these groups. The Area Directors for the following areas acting as a group will be the Area Advisors: INT, OPS, RTG and TSV. The name(s) listed above under "Technical Advisor(s)" are the the responsible Area Directors for the 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.
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 |
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. |
Apr 01 |
|
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 |
· General Switch Management Protocol V3
· Definitions of Managed Objects for the General Switch Management Protocol (GSMP)
GSMP WG Meeting 50th IETF, Minneapolis, MN
There were two GSMP WG sessions this time; one for GSMP issues and one joint GSMP/ForCES meeting.
Session I: GSMP WG Session I at IETF 50 Notes
Monday March 19 0900-1130
The GSMP working group held a meeting at IETF50. The meeting was chaired by Kenneth Sundell and Avri Doria, and notes were taken by Hans Sjöstrand.
1. Agenda Review
The agenda was presented, bullet about words from the ADs where added, There where no proposed changes from the floor on the agenda. The next session will be together with ForCES on Thursday.
1½. Words from the ADs
Scott Bradner and Bert Wijnen presented themselves. GSMP is pushed into the new temporary sub-IP area, Scott and Bert are area directors in addition to their other commitments. They will maintain Allison Mankin as day to day director and technical advisor for GSMP. The sub-IP area will maybe last for a year or two, hopefully closer to one than two years.
The area is doing work for sub-IP technologies, or also referred to as the underside of IP, and will be some sanity check for that.
2. Charter Update
The goals and milestones from the charter page were presented by Avri.
The ones listed from 99 are still being worked on. These documents are in the process of going through last calls and IESG reviews.
The purpose of the Thursday meeting is to make sure the point "Apr 01 Analyse role of GSMP for control element separation and make recommendation as to a separate WG for extending GSMP for this"
This meeting will decide whether the partitioning draft presented here will be the basis for the point " May 01 Document requirements for control of switches supporting optical, TDM and other CCAMP features".
Regarding the point " 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", we want to discuss if those goes into the current spec or in an extension spec.
The stuff on switch partitioning mib isn't a charter item yet. The most important thing is the requirement process. If it shows up to be the right thing, we will ask for a charter extension to cover also switch partitioning.
There where no comments from the floor on the charter.
Allison made a clarification, she noted noticed for the meeting on Thursday that it's not meant to work on the ForCES charter, but how GSMP WG can help the ForCES WG. Avri pointed out that she didn't know about any decision that ForCES is a WG. Allison agreed that it was not the case.
3. Document Status & Review of IESG comments
- GSMP V3 and GSMP Packet Encap.
Kenneth Sundell presented that the specs went through the WG last call last year and there were many comments. It is now in IESG last call with comments from the RFC editor and IANA so far, mostly about references. The IANA consideration page is totally changed. We are still waiting on IESG comment on the spec as a hole. Some editorial changes received by implementers are made in the meantime.
Avri noted that we must think if these changes require a second last call, if the changes are more than editorial. Allison commented that the changes are most probably to be only editorial.
- GSMP MIB
Hans Sjöstrand presented the updates on the mib. There has been an IESG review and there are quite a few updates. Except for lots of editorial updates there are a list of minor changes presented
- Section added on concepts of GSMP and GSMP config.
- IF-MIB 2233 replaced, now RFC 2863
- Notification OIDs updated with less overhead
- Removed trap from Notification names
- Handling of rows created outside SNMP clarified.
- Clarified when objects can be changed in active state
- gsmpSessionStatUptime changed to TimeStamp and renamed to gsmpSessionStartUptime
- gsmpEventLabel now of GsmpLabelType (new TC based on octet string).
- Added SYNTAX clauses to inet-address objects compliance.
- GsmpVersion TC changed from enumerated to Unsigned32
There where also a few major changes that needs WG approval
- Adopt to the recommended scheme to infer the {gsmpSessionThisSideId, gsmpSessionFarSideId} from the oids, thereby removing the gsmpSessionThisSideId, gsmpSessionFarSideId helperobjects agreed to in Pittsburgh.
- The addition of storagetype.
There where no objections against those proposed changes.
Then there are a few issues that needs WG input
- Any new GSMP encapsulation types in near future and should we make headroom already now for that in the mib...
There where a comment from the floor that the mere uncertainty about if there could be another encap could be enough. Also, SCTP has been mentioned as possible candidate. Avri noted that there where two voices for an extendible approach. Hans frowned.
There is also an issue if we should have the NotificationMap or just rely on the std SNMP filter application (RFC2573)? If none object or speaks up the notification map will stay.
There has also been a question about if scoped Ipv6 addresses makes sense in a GSMP. Allison noted that it's probably a requirement from IESG that we have support for scoped Ipv6 addresses.
Avri asked if these changes needed another last call round, Allison responded that she has seen changes of this kind without a new round of WG last call. Anyway, Hans will make the updates that's agreed, put a new revision 05 out soon after the meeting and the WG could give it's input on the changes. Then there will be a IESG re-review and then to the RFC editor for publishing.
4. Requirements for optical switching
draft-doria-gsmp-req-olsr-01.txt
Stephen Shew presented the draft. The motivation is a result of the interest in IP and optical worlds converging. Either way you approach it there is a need for separation of control functions and data switching.
Unlike the original L2 switch fabrics, optical XCs have some unique properties, even though those come in several varieties.
The requirements are Label Types, Port and Label Management, Configuration Service Model, Encapsulation and the Transaction Model.
Regarding the transaction model, TL-1 interfaces are liked and used in the optical world, these people are used to TL-1. It has command response and the processing environment is often serial. GSMP must convey this to avoid e.g. to flood with add branch, Also, add a bulk message.
Known issues today are Support for SONET/SDH concatenated payloads (virtual or continuous) and Support for bundles
Stephen asked if the draft is adopted as a WG document. Avri asked if there are any objections.
One question was made from the floor that are you tracking what happens in CCAMP. Avri responded Yes, definitely, that's e.g. the primary label target, and that's why its not discussed so much in this presentation.
Another remark was made, even thought it was no real objection, that there are overlaps with ODSI. Avri responded that ODSI primarily defines a client to network interface, this is a controller to fabric. It was argued that we should look on them instead of do everything from scratch.
Dimitri said that he would first like to have his presentation and then the question could be asked again.
Allison wanted to stress a very close cooperation with ccamp, the draft could look very very different next time and people shouldn't be surprised by that.
5. Further Requirements for GSMP - Dimitri Papadimitriou
Dimitri made a presentation on further requirements for GSMP. Performance monitoring is important. Also, there should be logical grouping of interfaces, in order to have more interfaces. Like the bundling in CCAMP. Even it was a rough idea that was proposed, there could be more consistency between the GSMP and GMPLS.
There could be new encapsulation, the question was if it was needed.
It's also done ITU.
The presentation also contained some very technical part, that Dimitri wanted to do it in Forces. Avri clarified that it was better to take it here, because there are no time allocated in the ForCES/GSMP meeting.
Avri clarified that the encap GSMP has nothing to do with encap of IP in optical. Dimitri said that that at least if we wanted to do it, we should be aligned.
It was asked from the floor if it is expected that a single controller controls several switches. Avri responded, yes, it's already in the GSMP framework. But how does the controller know who to talk to. Avri answered that it's an adjacency established.
The requirements document is the base document to build on. We should work together with Dimitri and whoever wants to be involved.
Avri asked if there where any objection to make it a WG doc, there where no objections.
6. Label extensions for Optical, Sonet/SDH, TDM and spatial switching
draft-sadler-gsmp-tdm-labels-00.txt
Jonathan Sadler presented the TDM labels draft. It's based on GMPLS draft in CCAMP. The original reason with TDM in GSMP was to handle ATM CES, but a more contemporary need on GMPLS control / element separation. This offers a mechanism to offload the already deployed switches from GMPLS control plane.
We need primitives to create TDM cross connects, multiplexing and to express directionality. We are dealing with G.707 multiplexing structures and the other plesiochronous services PDH. This introduces 9 new labels, port/lambda label, Sonet/SDH, ANSI PDH, ETSI PDH and the Inverse multiplex concatenated label. We are using label stacks as TDM Hierarchy.
Next steps are; to adopt the draft as working group document; Reconcile ETSI labels and to complete the definition of traffic parameters.
Question from the floor; What's are you referring to with ETSI labels.
Answer; The label format is following the ones in CCAMP, but CCAMP doesn't go as low as we need with E1 in E3 etc.
Yes, PDH labels is a good idea, could be an extension of GMPLS, but why have label stack? You don't need to?
Jonathan acknowledged that in the simple case you don't need to, but e.g. when you operating on a Sonet port, you may have an E3 phy in one side and E1 in others, there could be a benefit to reuse what's already bee negotiated on the other side. Also, DSOs within the DS3s, the sonet world doesn't have that granularity.
Avri asked if there are any issues or objections to make it a WG doc, there where no objections.
7. Requirements for Dynamic Partitioning
draft-anderson-req-dyn-part-00.txt
Todd Anderson presented the draft. In static partitioning the manager is using a mib to define the partitions, and than don't change these configurations. If you want to re-partition you need to down the device and restart. Dynamic partitioning removes that downtime. This is the set of requirements on dynamic partitioning, based on discussion some time ago on the list on the requirements.
The involved are partition manager, the controller and a network element. The network element is always a slave to the controller, it never acts or asks from the controller to release resources. The partitioning manager may release resources in the NE, NE are then allowed to inform the controller that the resources have been changed from the partition manager.
Avri commented that in this draft we have discussed more issues than what has been reflected in requirements. So, it's not by far finished. E.g. the discussion of a frozen partition.
Stephen Shew commented that in the diagram you could have multiple controllers. The partition manager has the trust, the burden to coordinate controllers lands on the partition manager. Notice that the partition manager is operated by the owner of network, the set of controller may be operated by other owners. How do you handle the level of trust, pre-emption etc?
A comment from the floor that there are now connection with the partitioning, and the GSMP. But that is not necessary. E.g. the ForCES discussion, if you partition these resources as well. Answer that, no it's not meant to be specific, should be more general. E.g. a partition could be a native controller for the SDH switch.
Avri pointer out that there are always an invitation to people to contribute to the document.
Avri asked if the draft should be made a WG doc, there where no objection.
8. Paritioning MIB
draft-anderson-gsmp-swpart-mib-00.txt
Avri started by pointing out that we can't make this a WG doc, because it's not within our charter. It's still a pending issue if we should go forward with it. We have the charter to investigate and look on the requirements.
Allison Mankin stated that we should really stay out of the solutions phase. Really not reference it from the requirements doc. We should just do the requirement list. She also stresses the fact that we don't want to have very specific regulatory requirements, that we should be focused on technical requirements.
Todd Anderson presented the mib. The mib started in mib format in MSF, was then made into pib format and presented in Pittsburgh IETF. Now it's back in mib format.
The mib satisfies the requirements so far in the requirement draft. Creating virtual network elements. It maps physical ports to Virtual Network Elements. You could have several VNE assigned the same physical port. It also configures how control protocols will talk to VNE and defines how physical switch resources (bandwidth, buffers, label/forwarding table space) are allocated to VNEs
What's new since Pittsburgh, some tables are added for the partition manager to create synthetic ports to relay packets between the VNEs not having to waste a real link. Also allow partition manager to locate connected controllers.
The mib doesn't cover optical, and may possibly cover the ForCES case with IP. We are not sure where to go with this. We have been issuing the mib. There are a lot of open issues. It was posted to the mailing list, some comments came in.
Hans Sjöstrand asked what MSF has said about the mib since it's been a work item there for a long time. Todd responded that there have been comments from MSF to make it more general. There has been work in MSF that optical should be added, and also to add the TDM partitioning.
Meeting adjourned by Avri Doria.
===========================================================================
Session II: GSMP/ForCES Joint Session at IETF 50 Notes
Thursday March 22 1300-1500
Co-chairs: Avri Doria, David Putzolu
Note takers: Alan Crouch, Craig Rodine, Kenneth Sundell
[Comments attributed where possible]
------------------------
1. Agenda
- Agenda Bashing - David Putzolu, Avri Doria
- Setting the Stage/Meeting Goals
- ForCES Overview and Requirements Update
- ForCES Work
- ForCES Work Structuring Proposal - Tom Worster
- ForCES Work Defiition - David Putzolu
- ForCES Relationships to GSMP
- Discussion and Wrap-Up
2. Setting the Stage
David Putzolu went over the Forces & GSMP recent events to bring everyone in the room up to speed. The Forces BOF was held in San Diego with large attendance and ended with a split vote of 150 for WG creation and 100 against. Questions were raised in the BOF about the relationship of Forces to GSMP and about the structuring of the Forces work. Discussions since then on the mailing list around the relationship to the GSMP wg and protocol were summarized as well as discussions about a potential Forces charter.
3. ForCES Overview and Requirements Update - Todd Anderson
Draft = draft-anderson-forces-req-01.txt
Todd Anderson presented the revised version of his Forces requirements document. Notable changes include support for a variety of connection types, auto-membership and topology discovery, and a change to the failure model. Also identified was a requirement for a functional model of a forwarding element, perhaps via a FE capability advertisement system.
Discussion followed the presentation of the requirements document. The idea of sharing an FE between CEs was discussed and described as a variation of FE parititioning, which would be a separate protocol. A hot topic that was identified is determining what FE functionality is and the ordering in which it is applied to packets. Some audience members questioned the interest of box vendors in the Forces approach and were answered by several attendees who indicated interest on the part of their companies. Avri Doria closed the discussion with a comment indicating that gauging vendor interest was not a goal of the current meeting and would be more appropriately expressed to the IESG.
4. The ForCES context - Tom Worster
Tom Worster presented a structuring of the Forces work that partitions it into manageable chunks. Tom related that he was initially skeptical about the likelihood of success for Forces but after further reflection believed it was an important, feasible effort. For specific information about the proposed structure see Tom's slides. Mark Handley indicated that he was largely in agreement with Tom's analysis. He suggessted starting out with a model that provides strong expressive power, then limit the model for practical purposes - i.e. don't do premature optimization. Ravi Medikonda indicated the importance of socializing these ideas with service providers and system vendors, which was answered by Avri Doria indicating that many service providers are active. Jong Jiant indicated strong service provider interest on his part as this would allow for rapid innovation in services. Russell Dietz indicate that the Forces model made significant sense in the use case where one has a smart backend device and a dumb CPE device, where the CPE device is a forwarding element for the backend device, where all of the intelligence is concentrated. Eric Gray raised a concern about the term "equitable" treatment of FEs in Tom's presentation. This was elaborated on by Tom to indicate the need for technical balance, where the standard did not favor a particular implementation. Jamal Hadi Salim closed the comments by urging that the functionality and expressive power not be limited to basic forwarding and QoS.
5. ForCES Work Definition - David Putzolu
David Putzolu presented the current work definition for Forces based on the discussions on the mailing list since the BOF. The most notable change was the introduction of a formal FE model as an intermediate stage between requirements and protocol selection/specification.
Nabil Seddigh indicated that QoS work should be done in parallel with other work, and that the Diffserv models followed a similar progression. Jon Crowcroft added that security should be addressed from the very beginning rather than as an afterthought.
6. ForCES Relationship to GSMP
David Putzolu and Avri Doria kicked off this discussion by summarizing previous questions around the Forces/GSMP relationship. These questions had previously been discussed on both the Forces and GSMP mailing lists. Avri Doriad described how GSMP will be developed as a result of its rechartering. Her intuition was that GSMP will be applicable she believes that it is not apparent that its generalization would cover the scope of what's being considered here.
Jamal Hadi Salim commented that he was in mild agreement but thinks focus of ForCES is narrow with no real overlap with GSMP. Tom Worster added that perhaps re-use will happen at the protocol level, but it can also happen at the "design experience" level, referring to Fred Baker's point from the previous night's plenary about "twice is enough." Other audience comments focused around the scalability that Forces enables as well as a caution to not turn Forces into a Christmas tree protocol
Allison Mankin (Transport AD) stood up to mention concern about the reaciton to the BOF at the last IETF meeting (San Diego). She indicated that this was not a discussion topic for today, requesting that people please email any opinions, especially negative ones, of ForCES work items/plan directly to the Routing and Transport ADs. Allison Mankin then asked for a sense of the room on a potential recommentation that ForCES be closely co-ordinated with the GSMP WG. The general room response was that ForCES should first develop requirements and functional model and that it was too early to be leaning towards any particular protocol (solution). Once technical requirements and model are defined then Forces would compare them against GSMP and make decisions.
Meeting was adjourned by Avri.
Agenda
Requirements for adding Optical Switch Support to GSMP
TDM Labels for GSMP
Definitions of Managed Objects for GSMP
GSMP/ Forces Joint Session
The Forces Context
Setting the Stage
Forces Relationship to GSMP
Forwarding and Control Element Separation (ForCES) Work Definition
Forwarding and Control Element Separation (ForCES) Overview & Requirements Update