Internet Draft GSMP Working Group Matt Peters Internet-Draft Balaji Srinivasan Jaroslaw Sydir CPlane Inc. Expires April 18, 2000 GSMP Enhancements for Improving Switch Partitioning Support and Simplifying PDU Parsing <draft-sydir-cplane-gsmp-enhancements-00.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This memo suggests a number of enhancements to GSMP, based on our experiences with our version of GSMP v1 and other, proprietary, switch control protocols. The enhancements fall into the broad categories of improving switch partitioning support, simplifying PDU parsing, and improving multicast support. Peters, Srinivasan, Sydir Expires April 18th 2000 [Page 1] Internet Draft CPlane GSMP Enhancements Oct 1999 1. Introduction This memo suggests a number of enhancements to GSMP, based on our experiences with our version of GSMP v1 and other proprietary switch control protocols. Each of the sections in this draft suggests changes to a subset of the GSMP messages as defined in [1]. The majority of the changes are aimed at simplifying and making more efficient the parsing of PDUs. It is our belief that it is more important to structure the PDUs in a way that make the parsing simple and efficient than it is to make the PDUS as compact as possible. Other changes that we suggest aim at improving the support of multiple partitions, specifically the support of partitions, which share the resources of a single port. Finally, we suggest some changes to better support multi-point to point connections. 2. Modifications Pertaining to All Messages 2.1 Message Length Field We propose that all GSMP Pdus should have a length field for the whole PDU. This length field should appear after the type and the transaction ID fields. This will allow the master/slave to read the entire PDU without having to compute its length. Computing of the length is inefficient because the master/slave must figure out if the PDU is a response or a request. Also for variable length PDUs like the port information PDU, the master/slave must peek into the PDU to find out the number of port records and the length of each port record in order to compute the length of the PDU. See section 2.1 for the proposed PDU change. 2.2 Support For Multi-Frame PDUs Currently when a message must be split into multiple PDUs (because they would not fit into a single frame), each of the sub-PDUs have a bit that says whether there are more sub-PDUs to follow for this response. This is error prone because if an intermediate sub-PDU gets lost there is no way of knowing it. Also there are some reassembly problems if the sequence of the PDUs is not guaranteed. Instead if the first sub-PDU of a multiple PDU response contains the number of sub-PDUs that are to follow and each of the sub-PDUs have a sequence number and an identifier saying whether this is the first sub-PDU or a subsequent sub-PDU, then reassembly and decode will be easier and more reliable. Each GSMP PDU (except the Adjacency Protocol PDUs) will have the following format. Peters, Srinivasan, Sydir Expires April 18th 2000 [Page 2] Internet Draft CPlane GSMP Enhancements Oct 1999 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Result | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| PDU Number | Length | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ GSMP Message ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The "I" flag is the start of PDU indicator. If it is set then the "PDU number" field specifies the total number of sub-PDUs in this PDU. If the "I" flag is not set then the "PDU number" field indicates the sequence number of the sub-PDU within the PDU. This sequence number starts from 1 following the first PDU. The "Length" field contains the length of the entire PDU. (See section 2.1 for an explanation of this field). 2.3 Label Length The Connection Management messages allow the controller to specify extended labels by setting the E bit to indicate that extended label data is to follow. This complicates the parsing of PDUs. We propose that a label length field be added to Connection Management messages, so that the controller can indicate the length of the label. See section 2.4 for the PDU layout. 2.4 PDU Byte Allignments Some of the GSMP PDUs (e.g., the Connection Management messages) contain bit fields that are not aligned on 8 bit boundaries. For example, the "Input Label" field in the Connection Management message has a 4 bit flag value that indicates whether the Label is extended or not. This alignment problem will cause inefficiencies in the parsing of PDUs. We propose that atomic quantities should be aligned to 8, 16 or 32 bit boundaries. Padding should be provided for this purpose, and to allow for expansion of the protocol. For example, the bit fields in the Connection Management should be allocated an entire 16-bit field. Peters, Srinivasan, Sydir Expires April 18th 2000 [Page 3] Internet Draft CPlane GSMP Enhancements Oct 1999 The connection management messages described in Section 4 of [1] will have the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Session Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |QMS|M|B|x|x|x|x|x|x|x|x|x|x|x|x| Label Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Input Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Input Label ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Output Label ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Selector | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The QMS/M/B fields retain their meaning. The bits marked x are reserved and can be used for additional flags. The "Label Length" field indicates the length in bytes that the input/output labels occupy. (See section 2.3 for an explanation of this change). The input and output labels are aligned at 4 byte boundaries. The Move Branch PDU described in section 4.7 of [1] becomes: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Session Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |QMS|x|x|x|x|x|x|x|x|x|x|x|x|x|x| Label Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Input Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Input Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Old Output Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Old Output Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New Output Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New Output Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Selector | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Peters, Srinivasan, Sydir Expires April 18th 2000 [Page 4] Internet Draft CPlane GSMP Enhancements Oct 1999 The statistics message in section 6.2 of [1] changes to: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x| Label Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The activity records in the Connection Activity Message and Report Connection State message also require alignment changes. See sections 4.1 and 4.2 of this document for the PDU format. 2.5 Message Acknowledgements The current GSMP specification allows the controller to indicate whether it wishes to receive a response for a request that it submits to the slave. We believe that this feature is not useful enough to warrant that additional complexity that it adds to the slave. The GSMP requests are either requests for information (in which case the controller by definition wants to see the response) or requests to change the state of the switch (in which case it is hard to think of an example where the controller would not care to find out whether the operation succeeded or not). We therefore propose that all requests be acked. This change will not affect any of the PDU layouts. 3. Port Configuration and All Ports Configuration messages 3.1 Support For Multiple VPI/VCI Ranges As currently specified, the Port Configuration messages return only one contiguous range of VPI/VCIs for each partition. This approach may not be adequate for several reasons. First, the label space of a switch may become fragmented as partitions are created and deleted so it may not be possible to provide a contiguous range to all partitions. Second, there exist switches, which require that labels be designated for use with VPCs or VCCs. This problem is addressed in more detail in the following section. We therefore propose that the Port Configuration Message Responses should contain a variable number of potentially non-adjacent ranges. Peters, Srinivasan, Sydir Expires April 18th 2000 [Page 5] Internet Draft CPlane GSMP Enhancements Oct 1999 3.2 Separate Label Ranges for VP and VC Connections There exist ATM switches in which VPIs must, at configuration time, be designated as "for use with VPCs" or "for use with VCCs". The Port Configuration Messages do not adequately support such switches. We propose that the Port Configuration Message Responses should contain a separate set of ranges for use with VPCs and VCCs. If the switch requires that these ranges be predetermined, then the VPI ranges for use with VPCs will not overlap those for use with VCCs. If on the other hand, the switch does not have such restrictions, the VPIs in the VPC range and VCC range can overlap. 3.3 Indicate Labels for Use with Multipoint Connections There exist ATM switches in which the VPIs and VCIs that can be used for multipoint connections are limited to a subset of the label space of the switch. The current Port Configuration Message Responses do not provide this information to the controller. We propose that each of the VPI/VCI ranges returned in the Port Configuration Message Responses should indicate whether the VPI/VCIs in that range can be used for multipoint connections. This can be achieved by adding a flag for each range that indicates whether the range can be used for only point-to-point or point-to-multipoint or multipoint-to-point or all of them. 3.4 Specify Both Incoming and Outgoing Labels The Port Configuration Message Responses currently specify only incoming label ranges. We believe that the GSMP slave must be aware of both the incoming and outgoing labels on each port. When two partitions share the resources of a physical port, their connections are distinguished by the incoming label. It is therefore important for the slave to police the use of outgoing labels to prevent an errant controller from sending cells to a partition on an adjacent switch that is not intended to be part of the same virtual network. Because of this, both the incoming and outgoing label space are a resource of the port (partition) and should be reported to the controller in the Port Configuration Message response. 3.5 Specifying both Event Sequence Number and Event Flags The Port Configuration Message Responses currently only specify the Port Session Number. To allow for controllers to quickly resynchronize with slaves when it regains contact with the slave, we propose that each Port Record of Section 7.3 of [1] should contain the Event Sequence Number and the Event Flags for that port (see Section 8 of [1]). Peters, Srinivasan, Sydir Expires April 18th 2000 [Page 6] Internet Draft CPlane GSMP Enhancements Oct 1999 3.6 PDU Format In this section we describe the Port Configuration Message Response PDU that incorporates all of the changes described above. Each Port Record of section 7.3 of [1] will have the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Session Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Event Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Event Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Port Type Specific Data + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The PortType Specific Data for PortType=ATM will be as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L|R|Q| unused | Number VC Ranges | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ VC Ranges ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number VP Ranges | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | VP Ranges | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Cell Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transmit Cell Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Status | Line Type | Line Status | Priorities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Physical Slot Number | Physical Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Peters, Srinivasan, Sydir Expires April 18th 2000 [Page 7] Internet Draft CPlane GSMP Enhancements Oct 1999 VC Range 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|P| unused | In Min VPI | In Max VPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | In Min VCI | In Max VCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Out Min VPI | Out Max VPI | Out Min VCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Out Max VCI | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ VP Range 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|P| unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | In Min VPI | In Max VPI | Out Min VPI | Out Max VPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The last VP Range will be followed by a 16 bit pad field in the event that there is an even number of VP ranges. It is assumed that all ranges can be used for point-to-point connections. Flags Q and R: same definitions as in [1]. L: same definition as is [1]. Should this be global for the port, or should it apply to individual ranges? V: not necessary because the presence or absence of VP ranges indicates whether the switch supports VP connections of not. M: Multipoint-to-Point Flag indicates that the associated VP or VC label range can be used to support multi-point to point connections. P: Point-to-Multipoint Flag indicates that the associated VP or VC label range can be used to support point to multi-point connections. Peters, Srinivasan, Sydir Expires April 18th 2000 [Page 8] Internet Draft CPlane GSMP Enhancements Oct 1999 Number VC Ranges Indicates the number of VC Range blocks that follow. Number VP Ranges Indicates the number of VP Range blocks that follow. VC Range Specifies one (square) block of VPI/VCIs that can be used for VC connections. If the switch does not require that VPI ranges for VP connections be pre-configured, the VPIs in a range can be specified in a VP Range as well. VP Range Specifies a contiguous range of VPIs that can be used for VP connections. If the switch does not require that VPI ranges for VP connections be pre-configured, the VPIs in a range can be specified in a VC Range as well. In Min VPI Lower bound of the VPI range in the incoming direction, where VPI is defined as in [1]. In Max VPI Upper bound of the VPI range in the incoming direction, where VPI is defined as in [1]. In Min VCI Lower bound of the VCI range in the incoming direction, where VCI is defined as in [1]. In Max VCI Upper bound of the VCI range in the incoming direction, where VCI is defined as in [1]. Out Min VPI, Out Max VPI, Out Min VCI, Out Max VCI Lower and upper bounds on the VPI and VCI for the outgoing direction. 4. Statistics Messages As currently specified, we believe that the Statistics Messages do not adequately support multi-point to point connections. We propose two modifications. Peters, Srinivasan, Sydir Expires April 18th 2000 [Page 9] Internet Draft CPlane GSMP Enhancements Oct 1999 4.1 Connection Activity Message The result of the Connection Activity message should include two counters, one for the input side of the connection and one for the output side. This will allow for the case where, in a multi-point to point connection, the input cell counts and the output cell counts are not the same. In addition, a valid-indicator bit should be added to both numbers. This will enable a switch vendor who only implements input-side counter to alert a controller of this limitation. This requires a modification be made to the Activity Record. The new record is shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V|C|A|I|O| unused | Label Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Input Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Input Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Input Count + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Output Count + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In the packet above, two pad bits have been used for the input and output valid indicators (I and O). If the I flag is set, the "Input Count" field contains the input port count. If the O flag is set, the "Output Count" field contains the output port count. The meaning of V, C, and A remains the same. All other fields maintain their previous meaning. 4.2 Report Connection State Message The format of the response to a Report Connection State request should be changed. Currently the controller specifies an input label on the request and receives one or more output labels in the response. This makes sense for point-to-point and point-to-multi-point connections, but not for multi-point-to-point connections. We propose that when the controller submits a request with the input label from one of the branches of a multi-point-to-point connection, the slave returns the output label and the list of all input labels. In addition the response PDU should include a number of response records, which will allow the controller to allocate memory in advance. Peters, Srinivasan, Sydir Expires April 18th 2000 [Page 10] Internet Draft CPlane GSMP Enhancements Oct 1999 Also note that the sequence number has been removed in favor of the scheme discussed in section 2.2. The request PDU remains the same. The modified response PDU is shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| PDU Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |T| Number of Records | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Root Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | ~ Label ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Connection Records ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In the above PDU, the Input Port field is replaced with a Root Port field, which may or may not be the same as the value in the request message. The field indicates the root of the multicast tree, whose branches are given in the Branch Records. In the record structure, the Output Branch Records become Branch records, as they can be either input or output branches. The "T" flag indicates whether is was a point-to-multipoint or multipoint-to- point connection. Connection Record 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|V|P|M|x|x|x|x| Input VPI | Input VCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Branch Records ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Peters, Srinivasan, Sydir Expires April 18th 2000 [Page 11] Internet Draft CPlane GSMP Enhancements Oct 1999 5. Delete All (Connection Management) Message We propose that the Delete All Connection Management Message have a flag that indicates the direction of the connections to be deleted. The values that this flag might take on are: "connections that originate at this port", "connections that terminate at this port", and "both". 6. PortEvent Alarm Currently all events happening on the port cause the "Port Session Number" to change. The recovery action taken by the controller is likely to be different for changes in line status and changes to port status. We believe that changes in the "Port Session Number" should accompany only drastic changes in the status of the port (ie. port was removed, port went down etc.). We propose that in case of line status changes to the port (ie. carrier/no carrier) the "Port Session Number" should not change. Authors' Contact Information Matt Peters CPlane Inc. 5150 El Camino Real Suite B-31 Los Altos, CA 94022 Phone +1 650 938 8066 ext 106 mpeters@cplane.com Balaji Srinivasan CPlane Inc. 5150 El Camino Real Suite B-31 Los Altos, CA 94022 Phone +1 650 938 8066 ext 103 balaji@cplane.com Jaroslaw Sydir CPlane Inc. 5150 El Camino Real Suite B-31 Los Altos, CA 94022 Phone +1 650 938 8066 ext 102 sydir@cplane.com Comments on this document should be sent to the authors or to the working group mailing list at gsmp@psyton.com. References [1] GSMP Working Group, Tom Worster Editor, "General Switch Management Protocol V3", draft-ietf-gsmp-02.txt, October, 1999 This document expires on April 18, 2000. Peters, Srinivasan, Sydir Expires March 2000 [Page 12]