Internet Draft
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 

             <draft-sydir-scireq-explanation-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 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]