The meeting was chaired by Avri Doria and reported on by Chao-Chun Wang. Avri presented the agenda. The agenda included: ò Review of the proposed baseline GSMP draft ò TCP Encapsulation for GSMP Messages - ò A QoS Model for GSMP ò QoS framework for GSMP - ò Addition of Partition Id to the GSMP header - ò Milestone Review The agenda was accepted without change. 1 Baseline draft review. The changes in GSMP V2 were presented by Tom Worster. These changes included (1) the support of the label stack, (2) the removal of V2 QoS abstract model, (3) the inclusion of QoS model selector, and (4) the generalization to other label switches. Tom started his presentation by pointing out that the word label referred to ATM only in his draft. The support for generic labels, however, was included in the draft. On discussing the change in QoS model, Avri asked the audience if anyone had implemented the QoS resource model defined in Chapter 9. No one indicated that they had. Removal of chapter 9 from the proposed baseline draft was approved. Tom moved on to Chapters 1-3. Tom used a two-layer stack label as an example when discussing the label field in the connection management message. Questions concerning the number of layers the model supported came up. Tom replied that at any one switching point, two labels should be enough. Tom further explained that at the aggregate egress node two layers of labels were required. Some discussion followed and led to the conclusion that the E bit in the message would be used to indicate whether there were more labels in the label field. This allows for a label stack of undetermined size. Questions regarding whether GSMP was for core or edge nodes were brought up. Tom indicated that GSMP could be used for both edge and core nodes in MPLS and ATM. However, in the case of ATM, only core nodes were mentioned in the chapter. The chapter would be updated to include edge nodes. In response to the question whether GSMP should extend the architecture to include higher layer function and adaptation, Tom said no, these functions were outside of GSMP's scope and should be handled by separately When asked whether there was a plan to make the service selector compatible with diff-serv, Tom responded he did not plan to do so. When asked whether the GSMP allows the stacking of ATM labels, Tom indicated that GSMP label could encode more than one type of label and the stacking of ATM labels might be confusing. In response to the question whether E-bit was needed to indicate the presence of shim header, he said that there was no need to do so as it was not in the scope of the GSMP. In response to a question regarding whether there was a need for the architecture and framework documents, Avri answered that the GSMP applicability draft had covered some of the architecture issues of the GSMP and that she would update the applicable draft to reflect the concern. As to the relationship between LDP and GSMP, it was pointed out that they complimented each other in that they functioned at different points in the architecture; one was used to distribute label information while the other was used to instruct a switch to make connections which corresponded to those labels. The baseline draft was accepted by the group as a WG document. 2 TCP encapsulation of GSMP message. Chao-Chun Wang presented a proposal for a TCP encapsulation for GSMP. One of the issues under discussion was that TCP was less prone to denial of service of attacks then was UDP. This was disputed. It was then clarified that this would be true when the security encapsulations were used. There was a question about whether including a TCP encapsulation would preclude the introduction of a UDP encapsulation. While one of the main reasons for using TCP was to gain advantage of security work already done for TCP connections, there was no reason to preclude an UDP encapsulation. A proposal for such an encapsulation was solicited. The proposal included a requirement that the GSMP Instance Identifier be included in the encapsulation header. This was done to keep the encapsulation similar to the existing Ethernet encapsulation. There were recommendations that this should be removed. The discussion was tabled and moved to the list for resolution. The TCP encapsulation was accepted into the baseline draft with the exception of the Ethernet issues and the inclusion of the Instance Identifiers. 3 GSMP QoS Models Two presentations were made proposing QoS service models for GSMP. 3.1 A QoS Model for GSMP Tom Worster presented a discussion of the QoS model design space. This presentation discussed both the location and type of control that is appropriate in controller/switch architectures. The pros and cons of putting resource management in the switch and/or in the controller were presented. The consensus was that the dominant responsibility for resource management should be located in the switch and not in the controller. There was also a discussion of whether the QoS management model should be based on an abstract resource model or an service model. Tom used a chart to show that the service model was more suitable than the resource model from the perspective of the switch design. Tom proposed a service model that included support for multiple service types as well as the priorities from GSMP V1.1 and the opaque profiles from GSMP V2. The proposal includes the use of capability set to help define the service type with a service model. 3.2 a QoS Framework for GSMP Parasuram Ranganathan presented a QoS framework draft, which was similar in concept to Tom's presentation but which provided a different mechanism. Parasuram proposed to map service parameters, such as service class, traffic parameters and etc, to the service model with some pre-defined numbers. It was pointed out that the GSMP server might not know what the numbers were and that this might cause problems. Moreover, it was seen as a problem that it took two messages to complete a connection. 3.3 General QoS discussion Questions such as "Could GSMP emulate PNNI?" and "What was the function of the switch?" brought about intensive discussion. Tom answered that the switch should be responsible for CAC. If the CAC failed then the switch rejected the request. The switch could inform the controller of the failure of request, but not of the reason why it failed. In general, it was hard for the switch to inform the controller of what was available in a general way. In response to the question "Does the GSMP protocol include the message to handle dynamic reuse of switch resources?" Avri answered that because of the complexity of dynamic reuse of switch resources, it was not being included in this draft, but that it could be considered in the future as a new WG work item. It was decided that the authors of the QoS drafts which had been presented to the WG should meet and come up with a single proposal for a QoS model by the next IETF. 4 Proposal to add a Partition Identifier to the GSMP header Avri Doria defined a switch partition as a partitioning of the label space as well as service and port resource. How a switch did the partition or assigned the resources was defined as being outside the GSMP scope. She mentioned that in this version of the protocol commands to dynamically change the nature of the partitions were not being included. These could be discussed as a future WG work item if interest warranted. The addition of the partition identifier was accepted as an addition to the baseline protocol text. 5 Milestone Review The group is on target for its 4/99 milestones of introducing the IP encapsulation and on opening up the draft to new label types. There is a need, however, for contributions on other label types such as Frame Relay.