GSMP Working Group Jaroslaw Sydir (liaison) Internet-Draft Switch Control Working Group Category: Informational Multiservice Switching Forum Expiration Date: April 2000 http://www.msforum.org October 21, 1999 Additional Explanation of Switch Control Interface Requirements 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 document serves as input into the IETF GSMP requirements and protocol definition process. It is submitted in response to draft- ieft-gsmp-msf-response-00.txt. It provides additional explanations to requirements that were not clearly specified in the original liaison (draft-mceachern-scireq-00.txt). It also provides some suggestions for how some of the requirements might be satisfied in the GSMP protocol. MSForum Switch Control WG Expires April 21th 2000 [Page 1] Internet Draft MSF SCI Requirements Explanation Oct 1999 Disclaimer: This document has been approved by the Multiservice Switching Forum/Switch Control Working Group for liaison distribution to the IETF. However, this document in no way binds any of the member organizations to the ideas presented. This document provides additional explanation of some of the Switch Control Interface (SCI) requirements submitted to the IETF in draft-mceachern-scireq-00.txt. It also provides some suggestions for how some of the requirements might be satisfied in the GSMP protocol. The MSF will revisit this work in the future and may add, change or delete its requirements. Requirements: 1. Requirement 66: Support for ATM Service Additional Explanation: The requirement is to support an ATM service over an ATM core. This entails the ability to set up connections that conform to the service classes of the ATM Forum QoS. Since the service is ATM and the core network is ATM, there is no interworking function that must be controlled. 2. Requirement 67: Support for Frame Relay Service Additional Explanation: The requirement is to support a Frame Relay service over an ATM core. In core switches, this entails the ability to set up connections that guarantee a given committed information rate (CIR). In edge switches (switches at the boundary of the Frame and ATM network) this entails the ability to configure the frame relay to ATM interworking function. Contributions to describe the interworking function parameters that need to be set are solicited from MSF Members. 3. Requirement 68: Support for Circuit Emulation Service Additional Explanation: The requirement is to support a Circuit service over an ATM core. In core switches, this entails the ability to set up connections that support circuit emulation (e.g., ATM Forum CBR). In edge switches (switches at the boundary of the TDM and ATM network) this entails the ability to configure the TDM circuit to ATM interworking function. Contributions to describe the interworking function parameters that need to be set are solicited from MSF Members. 4. Requirement 69: Support for MPLS Service Additional Explanation: The requirement is to support a MPLS service over an ATM core. In core switches, this entails ability to set up connections with the QoS required by MPLS. In edge switches (switches at the boundary of the IP and ATM network) this entails the ability to configure the IP to ATM interworking function. Contributions to describe the interworking function parameters that need to be set are solicited from MSF Members. MSForum Switch Control WG Expires April 21th 2000 [Page 2] Internet Draft MSF SCI Requirements Explanation Oct 1999 5. Requirement 18: Support dynamic/statistical partitioning Additional Explanation: This requirement is withdrawn at this time. It was determined by the MSF membership that this requirement should not apply to the Base SCI. This requirement was included in the draft-mceachern-gsmp-scireq-00.txt due to an editorial error. 6. Redundant Controller Requirements: 6.1 Requirement 5: The SCI shall be able to support a VSC that is composed of multiple active VSCEs, all of which can issue SCI requests simultaneously to the same VS. The VS is not responsible for co- ordination of the VSCEs. 6.2 Requirement 6: It shall be possible for the VSCEs that make up a VSC to run on physically separate platforms and to access the VS over separate physical paths(links). 6.3 Requirement 55: The SCI may support redundant physical connectivity between a VSCE and a VS. Contributions to suggest modifications to GSMP are solicited from MSF Members. 7. Requirement 8: The SCI shall not restrict the switch redundancy scheme and must allow for m:n hardware level redundancy in the switch. Additional Explanation: The SCI should not preclude hardware redundancy on the switch. Redundant hardware should not be seen explicitly through the SCI (Port Configuration Responses should return one port description for a pair of redundant ports). 8. Requirement 9: The SCI shall provide a mechanism for detecting loss of synchronization of state (consistency of state between VSC and VS). The mechanism must be able to detect whether or not switch has the same configuration (including connections, connection configuration parameters and switch configuration parameters) that the VSC has sent into it. Contributions to suggest modifications to GSMP are solicited from MSF Members. 9. Requirement 64: The SCI shall support hitless resynchronization between the VSC and the VS when they are already in sync. Additional Explanation: The synchronization of VSC and VS state should not disrupt the connections that exist on the switch. This should be the case when the VSC and VS were already in sync at the start of the operation, or were out of sync at the start of the operation. MSForum Switch Control WG Expires April 21th 2000 [Page 3] Internet Draft MSF SCI Requirements Explanation Oct 1999 10. Requirement 50 - SCI shall provide flow control of event notifications (event messages) The current GSMP utilizes the following event message flow control scheme. When an event occurs, the slave sends an event message to the controller and sets a bit, which indicates that it should not send any more instances of that event message until the controller resets the bit by sending the Reset Event Flags request. The slave does increment the event number with every event, even if it is prevented from sending the event message. This scheme is not sufficient for several reasons. First, since event messages are not acknowledged and are not reliable, a lost event message will cause a deadlock where the controller does not know to check the state of the slave and the slave is not allowed to send another event message of that type. Second, since event messages carry with them information (like the port number) the event number will indicate only the number of occurrences of an event and not the port(s) to which they refer. So we propose the following changes 1. Event messages should be acknowledged. The slave should retransmit an event message some predetermined number of times without getting an ack before giving up. This number can be an implementation detail of the slave. 2. As part of establishing an adjacency, the controller can negotiate the number of event messages (new or retransmitted) that can be sent to it in any 1 second period. The controller requests a number, the slave grants either that number or one that is lower. 3. The event flag and Reset Event Flags message can be eliminated. MSForum Switch Control WG Expires April 21th 2000 [Page 1]