Internet Draft
Internet Engineering Task Force                  Jim McEachern (liaison)
INTERNET DRAFT                              Switch Control Working Group
<draft-mceachern-gsmp-scireq-00.txt>        Multiservice Switching Forum
Category: Informational                           http://www.msforum.org
Expires: December 21, 1999


                Service Control Interface Requirements
            Multiservice Switching Forum (MSF) Contribution





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 docu-
ments of the Internet Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working docu-
ments 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

To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.



Abstract


This document serves as input into the IETF GSMP and IEEE P1520 require-
ments process. It includes requirements as input by Multiservice Switch-
ing Forum (MSF) members and refined by the MSF Switch Control Working
Group.


Disclaimer:

This is a representation of the preliminary requirements generated by
the Multiservice Switching Forum/Switch Control Working Group. This
document has been approved by the Working Group for liaison distribution
to the IETF and IEEE. However, this document in no way binds any of the
member organizations to the ideas presented. This document contains the
current state of the requirements of the MSF Switch Control Working
Group for a Switch Control Interface (SCI). The MSF will revisit this
work in the future and may add, change or delete its requirements.



McEachern - Multiservice Switching Forum                        [Page 1]





Internet Draft   Switch Control Interface Requirements      21 June 1999


Table of Contents


        1. Introduction
        2. MSF Architecture and Terminology
          2.1 Functions of the VSC
          2.2 Functions of the Switch
          2.3 Switch Resource and Service Abstractions
            2.3.1Switch Resource Abstraction
            2.3.2 Switch Service Abstraction
            2.3.2.1 Minimal capabilities of the SCI
            2.3.2.2 ATM Forum Services
             2.3.2.3 IETF MPLS Services
             2.3.2.4 IEEE PIN Services
        3. SCI Requirements
          3.1 Fundamental Services Requirements
          3.2 Switch Partitioning Requirements
          3.3 Resource and Service Model Requirements
          3.4 Architectural Requirements
          3.5 Fault Tolerance and Synchronization Requirements
          3.6 Security Requirements
          3.7 Functional Requirements
            3.7.1 Virtual Switch Configuration and Management
            3.7.2 Connection Control
          3.8 SCI Protocol Implementation Requirements
        3.9 Management Requirements
            3.9.1 Resource and Service Model Requirements
            3.9.2 Virtual Switch Configuration and Management
            3.9.3 Virtual Port Configuration and Management
            3.9.4 State and Statistics Reporting



1.  Introduction

The Multiservice Switching Forum (http://www.msforum.org) has the fol-
lowing mission:

*    Define an architecture that separates the control and user/data
     plane aspects of an ATM-capable Multiservice Switching System
     (MSS) and establishes a framework which can be easily extended to
     support new adaptation and switching plane and control functions.

*    Define a set of open intra-switch interfaces based upon this archi-
     tecture document and promote Implementation Agreements for these
     interfaces that allow service providers to deploy ATM-capable Mul-
     tiservice Switching Systems  composed of best-of-breed components
     from multiple vendors.

In the MSF architecture multiple services are supported by partitioning
the resources of a switch into multiple Virtual Switches (VSs) and hand-
ing off control to each of the VSs through a Switch Control Interface
(SCI). This allows different Virtual Switch Controllers (VSCs) to imple-
ment different services by exercising control over their assigned VSs.



McEachern - Multiservice Switching Forum                        [Page 2]





Internet Draft   Switch Control Interface Requirements      21 June 1999


The MSF Switch Control Working Group has adopted GSMP as the base SCI
protocol. This document contains the SCI requirements generated by the
MSF membership and refined by the MSF Switch Control group.

This document employs the following terminology and conventions:

*    Must, Shall, or Mandatory:  the item is an absolute requirement.

*    Should: the item is highly desirable.

*    May or Optional: the item is not compulsory.

*    The requirements are identified by numbers, specified in
     parenthesis, which correspond to the numbers in the Multiservice
     Switching Forum (MSF) SCI Requirements document.

*    Some of the requirements are annotated with the following notation:
     [M]. These are management requirements that were identified as part
     of the SCI requirements gathering process. Even though they are
     stated as SCI requirements, they should not be considered as such.
     They are included here because it may be necessary to perform some
     management functions through the SCI. The MSF Switch Control work-
     ing group has not yet agreed upon which of these requirements do
     indeed apply to the SCI and intends to clarify these requirements
     in a future I-D.

In section 2 we present an overview of the relevant parts of the MSF
architecture, while in section 3 we present the various SCI require-
ments.


2.  MSF Architecture and Terminology

This section provides a simplified description of the subset of the MSF
architecture that pertains to switch control. It is presented here as a
reference to the reader. The terminology defined in this section is used
in the requirements that are specified in the remainder of this docu-
ment.

The high level requirements addressed by the MSF architecture are:

*    Support for multiple services (ATM, IP, POTS, frame relay, private
     line, etc.) which can deliver voice, data, and video end-user
     applications

*    Support for multiplicity of VSC types

*    Support for multiple switch types within an MSS network (One area
     of discussion is the support for multiple switch types within an
     MSS or MSN)

*    Scalablity for carrier class networks

*    Carrier class reliability and availability



McEachern - Multiservice Switching Forum                        [Page 3]





Internet Draft   Switch Control Interface Requirements      21 June 1999


*    Flexible quality of service support

*    Support for high connection rates

*    Support for rapid synchronization

*    Resource management and partitioning

*    Efficient collection of performance and billing statistics

*    Graceful software and protocol upgrades


The following definitions specify the relevant components of the archi-
tecture:

Switching Function (SF): Responsible for the switching of information
from one port to another. The switching function may provide packet
switching, frame switching, cell switching etc.

Switching and Bearer Control Function (SBCF): Responsible for issuing
commands to the switching function(s) associated with the reservation,
establishment, modification, and release of information stream associa-
tions between two or more logical ports.

Switch Control Interface (SCI) : The implementation-independent specifi-
cation of the communication that occurs between the Switch and Bearer
Control Function and the Switching Function. The purpose of this commun-
ication is to allow the Switch and Bearer Control Function to control
the actions of the Switching Function (e.g., to set up and tear down
connections). The interface follows a master-slave model in that it
realizes the master-slave relationship between the Switch and Bearer
Control Function and the Switching Function.

SCI Slave: An active set of software/hardware which implements the slave
side of the SCI. The SCI Slave is generally collocated with the Switch-
ing Function.

SCI Master: An active set of software/hardware which implements the mas-
ter side of the SCI. The SCI Master is generally collocated with the
Switch/Bearer Control Function.

Switch Control Protocol (SCP): A protocol that realizes the SCI.

Switch Control API (SCAPI): An application programming interface which
realizes the SCI.

Switch: A piece of equipment comprising hardware and embedded software
which implements the Switching Function. Switches are viewed as collec-
tions of resources that are controlled by the Switch and Bearer Control
Function.

Switch Abstraction: A model that represents the features of the switch
at a specified level of granularity. Two levels of abstraction are



McEachern - Multiservice Switching Forum                        [Page 4]





Internet Draft   Switch Control Interface Requirements      21 June 1999


specified: a resource abstraction and a service abstraction.

*    Resource abstraction: A model of the resources in the switch, e.g.,
     switching table, multiplexers.

*    Service abstraction: The services that can be requested from the
     switch, e.g., virtual circuit, virtual path and multicast connec-
     tions as specified by common or standard QoS characteristics.

Physical Port: A port on a physical interface of a Switch.

Logical Port: An entity on a switch which supports connections and their
traffic. A logical port can map one-to-one with a physical port in the
most common case. It may also be a subset of a physical port as a VPC
tunnel or TDM channel. It may also map to a grouping of physical ports
in the case of an Inverse Multiplexed ATM (IMA) port.

Virtual Switch (VS): An arbitrary subset of switch resources that can be
controlled as a unit through a single SCI slave. The switch resources
that make up a Virtual Switch can come from a single switch, or a group
of physically connected switches.

Virtual Port: An arbitrary subset of the logical port resources which
belong to a VS.

Switch Partitioning Function: A function, which partitions switch
resources into one or more VSs. This entails the following functions:

*    Providing the capabilities required to assign resources to and con-
     figure a VS

*    Assuring that individual VSs cannot exercise control over resources
     that are not assigned to them

The resources placed under the control of the Switch Partitioning Func-
tion can comprise the resources of a switch or set of switches or the
resources of a VS (in the case of recursive partitioning).

Virtual Switch Controller Entity (VSCE): An active software/hardware
entity that implements all or part of an SCI master and exerts control
over a VS by communicating with its SCI Slave.

Virtual Switch Controller (VSC): A set of one or more Controller Enti-
ties which together control the resources of a VS. A VSC implements the
Switching and Bearer Control Function for a given service.

VS State: Information concerning the state of a VS. Examples of VS State
information are:

*    The active connections and their configuration (including QoS
     parameters and other characteristics such as point-to-multipoint)

*    Queued SCI requests




McEachern - Multiservice Switching Forum                        [Page 5]





Internet Draft   Switch Control Interface Requirements      21 June 1999


*    List of switch capabilities

*    Interfaces and their capabilities

VS State Synchronization/Resynchronization: The communications that
occur between an SCI master and an SCI slave in order to make certain
that their understanding of the VS State  is identical.

Hitless Resynchronization: VS State resynchronization which does not
cause existing user-plane connections to be interrupted.

Figure 1 illustrates the relationship between some of these components.


        +-----------------------------------+   +--------------+
        |Virtual Switch Controller(VSC)     |   | VSC          |
        |                                   |   |              |
        | +-----------+       +-----------+ |   | +-----------+|
        | | VSCE      |       | VSCE      | |   | |  VSCE     ||
        | |           |       |           | |   | |           ||
        | |+=========+| o o o |+=========+| |   | |+=========+||
        | ||SCIMaster||       ||SCIMaster|| |   | ||SCIMaster|||
        | +-----------+       +-----------+ |   | +-----------+|
        +---------^------------^------------+   +----^---------+
                  |           /                      |
                  |          /                       |
                  |         /   <-----SCI---->       |
                  |        /                         |
                  |       /                          |
        +---------v------v---+             +---------v---------+
        |    | SCI Slave  |  |             |   | SCI Slave |   |
        |    +============+  |             |   +===========+   |
        |                    |   o o o     |                   |
        | Virtual Switch (VS)|             | VS                |
        +--------------------+             +-------------------+
        +---------------------------------------------------------+
        |     Switch Partitioning Function                        |
        +---------------------------------------------------------+
        +---------------------------------------------------------+
        |     Switching Function                                  |
        +---------------------------------------------------------+

        VSCE = Virtual Switch Controller Entity

                Figure 1: SCI Master/Slave Relationships




2.1.  Functions of the VSC

The VSC will perform the following functions:

a.   Routing and rerouting traffic between multi-service switching



McEachern - Multiservice Switching Forum                        [Page 6]





Internet Draft   Switch Control Interface Requirements      21 June 1999


     systems

     and interfacing with the control planes of other switches

b.   Routing and rerouting traffic between VSs within the multi-service
     switching system

c.   Controlling the establishment of VPI/VCI mappings between port
     interfaces connected via the switching plane

d.   Assigning quality of service (QoS) parameters to each VPI/VCI map-
     ping

e.   Performing generic connection admission control (GCAC) and traffic
     engineering for the network


2.2.  Functions of the Switch

This section enumerates some of the functions of the Switch and the
Switch Partitioning Function.

a.   Providing an ATM-cell-based interface to the adaptation plane

b.   Supporting a multiplicity of adaptation plane elements, include
     remotely located ones

c.   Switching cells or flows based on VPI/VCI fields

d.   Providing QoS management

e.   Replicating cells for point-to-multipoint connections

f.   Merging cells for multipoint-to-point connections

g.   Performing ABR functions such as EFCI marking and Resource Manage-
     ment (RM) cell processing

h.   Providing a common interface to multiple controllers

i.   Partitioning switch resources into VSs:

*    Performing admission control when admitting VSs.

*    Policing the use of each VS in order to ensure that control is
     exercised only over the resources assigned to the VS. Physical
     resources (e.g., ports, labels, bandwidth, and adaptation
     resources) may be allocated exclusively to individual VSs or shared
     among VSs.

*    Providing a separate SCI for the control of each VS.

j.   Allowing support of a multiplicity of switching elements controlled
     by a single controller



McEachern - Multiservice Switching Forum                        [Page 7]





Internet Draft   Switch Control Interface Requirements      21 June 1999


k.   Allowing support of remotely located switching elements with stan-
     dard (e.g., SONET/SDH) and reliable (e.g., APS) interfaces

l.   Performing dynamic connection admission control (CAC)

m.   Managing card/link redundancy within the switch transparent to the
     control plane


2.3.  Switch Resource and Service Abstractions

A switch abstraction models the features of a switch at a specified
level of granularity. Two levels of abstractions are specified: resource
abstraction and service abstraction. In the former, the SCI exposes the
resources and associated capacities of the switch. In the latter, the
SCI exposes the service capabilities of the switch, as an abstraction of
the underlying switch resources.

In the case of resource abstraction, admission control is left to the
virtual switch controller, whereas in the case of service abstraction
general admission control (GCAC) may be performed in the VSC, while
final call admission control (CAC) is the responsibility of the virtual
switch.


2.3.1.  Switch Resource Abstraction

A switch resource abstraction consists of two components: a minimal
resource set and a minimal capability set.


2.3.1.1.  Minimal Resource Set

There is a set of key resources that are required for supporting quality
of service.  This set consists of a non-blocking switch fabric, a
switching table, a set of input and output ports, and a multiplexer at
each output port.


a.   Switching Table: Each switching table entry must contain at
     minimum:

*    Input and ouput port numbers, VPIs and VCIs  (no VCIs for VPs).

*    Output port buffer identifier

Multicast entries consist of a sequence of unicast entries.


b.   Multiplexers: A minimal model of a multiplexer consists of a set of
     buffers, a buffer manager, and a scheduler.






McEachern - Multiservice Switching Forum                        [Page 8]





Internet Draft   Switch Control Interface Requirements      21 June 1999


2.3.1.2.  Minimal capabilities of the SCI to control and manage the
switch resources

a.   Capabilities for exposing the minimal resource set:

*    Reading the configuration of the switch resources:

-    Number of ports and port bandwidths

-    Switching table and name space sizes,

-    Supported scheduling and buffer management policies (each policy is
     given a code)

-    Maximum number of buffers and maximum buffer sizes

b.   Capabilities to control and manage the entries in the switching
     table:

*    Selecting scheduling and buffer management policies for each port,
     based on a capability list (menu) provided by the switch

*    Setting the number and sizes of buffers for each port

*    Reading resource utilization and QOS parameters


2.3.2.  Switch Service Abstraction

The second approach to developing a switch abstraction is to abstract
the resources of a switch with a set of service-oriented abstractions.
The switch service abstraction model provides the VSC with a description
of the services and capabilities of the virtual switch while masking the
complexities of the switch implementation. The VSC may perform generic
call admission control (GCAC) functions to select routes for end-to-end
calls and as a preliminary check of call admittance, but the switch per-
forms the final call admittance control (CAC)

Partitioning within a switch for the service abstraction model consists
of dividing those resources necessary to support the service. Resources
that are divided may or may not be those directly exposed by the switch
to the VSC.

All connections are specified based on source and destination ports, and
source and destination VPI and VCIs (although VPC connections do not
specify the VCI). Additional parameters are specified based on the ser-
vice types below.


2.3.2.1.  Minimal capabilities of the SCI to support switch service
abstractions

The various switch service abstractions focus on QoS/traffic type
abstractions, which abstract buffer, scheduling, and perhaps bandwidth



McEachern - Multiservice Switching Forum                        [Page 9]





Internet Draft   Switch Control Interface Requirements      21 June 1999


resources. Resources such as input and output ports and address space
are generally not abstracted. When using a switch service abstraction
(service-oriented switch abstraction) the SCI needs the following capa-
bilities:

a.   Capabilities to read the configuration of the switch resources:

*    Available service abstraction(s)

*    Number of ports and port bandwidths (bandwidth might be in terms of
     service specific abstraction)

*    Name space sizes and address ranges

*    Switching table sizes (might be in terms of number of connections
     of each service class)

*    Supported service classes and other class-specific
     capabilities/capacities

b.   Capabilities to control and manage:

*    Set up connections of given service class

*    Manipulate service-specific policies


2.3.2.2.  ATM Forum Services

The ATM Forum UNI 4.0 and TM 4.0 specifications define the following
service types for connections:


          CBR.1,      CBR.2       CBR.3
          VBR-rt.1    VBR-rt.2    VBR-rt.3
          VBR-nrt.1   VBR-nrt.2   VBR-nrt.3
          UBR.1       UBR.2
          ABR


Under the service abstraction model, the switch advertises its ability
to support the above services and allows the VSC to make connection
requests by specifying these service types.

The ATM Forum UNI4.0 and TM 4.0 specifications define the following ser-
vice specific signalled parameters:


          PCR       SCR       CDVT      MBS       pp-CDV
          MaxCDT    CLR       MCR       ICR       RIF
          Nrm       RDF       ADTF      Trm       FRTT
          TBE       CDF





McEachern - Multiservice Switching Forum                       [Page 10]





Internet Draft   Switch Control Interface Requirements      21 June 1999


Under the service abstraction model, the VSC makes connection requests
specifying these service specific parameters individually for each con-
nection.

The ATM Forum PNNI 1.0 specification defines that resource availability
for the following service categories are advertised to other PNNI nodes:

*    CBR

*    VBR-rt

*    VBR-nrt

*    UBR

*    ABR

Under the service abstraction model, the switch advertises its ability
to support the above services to the VSC.

The ATM Forum PNNI 1.0 specification defines that the following parame-
ters are advertised to other PNNI nodes for each or all of the services
listed above:

*    Administrative weight

*    Maximum cell rate

*    Available cell rate

*    Cell transfer delay

*    Cell delay variation

*    Cell loss ratio (CLP=0)

*    Cell loss ratio (CLP=0+1)

*    Cell rate margin (optional)

*    Variance factor (optional)

Under the service abstraction model, the switch advertises the above
parameters, on a per service class basis, to the VSC (with the exception
of administrative weight which is administered in the VSC).


2.3.2.3.  IETF MPLS Services

The IETF MPLS working group has defined the architecture and protocols
for label switched routing. Included in this definition are draft propo-
sals for performing MPLS over ATM, MPLS using RSVP, MPLS using Con-
straint Based LDP, and MPLS using classes. However there has not been an
official decision on which way(s) are accepted as the standard(s).



McEachern - Multiservice Switching Forum                       [Page 11]





Internet Draft   Switch Control Interface Requirements      21 June 1999


Since the MSF wants to support what the MPLS working group defines as
the standard way(s) to provide QoS for MPLS services, we will defer
specifying the details of the QoS definition(s) until the MPLS working
group has reached a decision.


2.3.2.4.  IEEE PIN Services

The IEEE PIN services at the level of an ATM switch are virtual circuit
segments, multicast segments, and virtual path segments. The request for
each of these services is given below. The concept of a traffic class
(used for requesting virtual circuits) is described later.


2.3.2.4.1.  ATM Switch Services

a.   Virtual circuit segments

*    Request to create a VC segment: Parameters: input port, input VPI,
     input VCI, output port, output VPI, output VCI, traffic class
     number, bandwidth parameters.

*    Request to release a VC segment: Parameters: input port, input VPI,
     input VCI; output port, output VPI, output VCI.

b.   Multicast segments

*    Request to add segment of a branch.  Parameters: as for request to
     create a VC segment

*    Request to release a segment of a branch.  Parameters: as for
     request to release a VC segment.

*    Request to release an entire multicast tree segment (within the
     switch): Parameters: input port, input VPI, input VCI

c.   Virtual path segments

*    Request to create a VP segment: Parameters: input port, input VPI,
     output port, output VPI, bandwidth.

*    Request to release a VP segment: Parameters: input port, input VPI,
     output port, output VPI.

*    Request to create a VP origination: Parameters: port, VPI,
     bandwidth

*    Request to release a VP origination: Parameters: port, VPI.

*    Request to create a VP termination: Parameters: port, VPI

*    Request to release a VP termination: Parameters: port, VPI





McEachern - Multiservice Switching Forum                       [Page 12]





Internet Draft   Switch Control Interface Requirements      21 June 1999


2.3.2.4.2.  Traffic classes and Quality of Service

A traffic class is a statistical model for an information stream. It is
described by a set of quantitative and qualitative parameters. The
former consists of parameters such as the peak rate, average rate and
maximum burst size of the stream. The latter consists of a descriptor
such as video, voice, audio or data to describe the traffic characteris-
tics qualitatively. A special descriptor called premium is used to
describe traffic that does not fit into any of the other categories.

With each traffic class, a set of quality of service constraints is
associated. With each output port, a finite set of traffic classes is
associated. The number of traffic classes and their descriptions are
selectable.

a.   Traffic Description  Quantitative

*    Peak cell rate

*    Average cell rate

*    Maximum burst size

b.   Traffic Description  Qualitative

*    Premium - Arbitrary statistics

*    Video- Real-time video statistics

*    Voice - Real-time voice statistics

*    Audio - Real-time audio statistics

*    Data - Data statistics


c.   Quality of Service Description

*    Maximum Cell Delay

*    Average Cell Delay

*    Cell Loss Ratio

*    Average Gap Loss: Average number of consecutively lost cells

*    Measurement era: The duration over which averages are computed


3.  SCI Requirements

This section lists the base SCI protocol requirements that were agreed
upon by the MSF membership.




McEachern - Multiservice Switching Forum                       [Page 13]





Internet Draft   Switch Control Interface Requirements      21 June 1999


3.1.  Fundamental Services Requirements

(66-69)
     The SCI shall allow the control of ATM switching and adaptation
     functions for the following services over an ATM capable core:

*    ATM

*    Frame Relay

*    Circuit Emulation Service

*    MPLS

Note:  Voice is a requirement for the MSF architecture, however respon-
sibility for voice adaptation is not within the scope of the SCI.


3.2.  Switch Partitioning Requirements

(4,17,18,19)
     The following requirements pertain to partitioning of switch
     resources into VSs:

*    The SCI shall allow separate VSCs to control the VSs of a parti-
     tioned MSS switch. It shall be possible for VSCs to be provided by
     different vendors that provide the same service or different ser-
     vices. Examples of such services include PNNI, ISUP, B-ISUP, and
     MPLS.

*    The creation and management of virtual switches are outside the
     scope of the SCI.


3.3.  Resource and Service Model Requirements

(73) MSF switches and thus the SCI shall support an ATM Forum Switch
     Service Abstraction.

(74) MSF switches and thus the SCI shall support an MPLS Switch Service
     Abstraction.

(75) MSF switches and thus the SCI shall support the IEEE P1520 (PIN)
     Switch Service Abstraction.

(76) MSF switches and thus the SCI shall support a Switch Resource
     Abstraction.

(78) The SCI shall allow the VSC to discover the switch resource
     abstraction supported by the VS.  (Also a Management Requirement).

(79) The SCI shall be extensible to allow new service and resource
     abstractions.




McEachern - Multiservice Switching Forum                       [Page 14]





Internet Draft   Switch Control Interface Requirements      21 June 1999


(21) The SCI shall not prevent over-subscription of resources, such as
     bandwidth.


3.4.

Architectural Requirements

(80) The SCI shall provide a standard mechanism for inclusion of vendor-
     proprietary extensions.

(1)  A VS shall be controlled by only one VSC at any given time.

(2)  A VSC can be composed of an arbitrary number of VSCEs and a VS can
     be composed of the resources of an arbitrary number of physical
     switches.

(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.

Some examples of a multi-VSCE VSCs are: a set of redundant VSCEs which
form a fault-tolerant VSC; a set of load-sharing VSCEs which form a
high-performance VSC; a set of specialized VSCEs (e.g., connection con-
troller, statistics controller), which split the duties of the VSC along
functional boundaries; and combinations of the above.


(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).

(55) The SCI may support redundant physical connectivity between a VSCE
     and a VS.

(57) The SCI should not be the limiting constraint on the number of con-
     nections concurrently active on a switch.

(58) The SCI should not restrict the number of virtual ports.

(59) The SCI shall not restrict the physical interface types supported
     by the switch.

(60) The SCI shall allow support for at least one terabit/second
     throughput per virtual port. The SCI encoding of bandwidth values
     shall be extensible, and shall include those specified by the ATM
     Forum.

(61) The SCI shall allow a VSC to have multiple outstanding requests
     (e.g., to support high call rates).






McEachern - Multiservice Switching Forum                       [Page 15]





Internet Draft   Switch Control Interface Requirements      21 June 1999


3.5.  Fault Tolerance and Synchronization  Requirements

(8)  The SCI shall not restrict the switch redundancy scheme and must
     allow for m:n hardware level redundancy in the switch (e.g., Card
     level redundancy, other component level switching, APS on inter-
     faces).

(9)  The SCI shall provide a mechanism for detecting loss of synchroni-
     zation of state (consistency of state between VSC and VS). The
     mechanism must be able to detect whether or not the switch has the
     same configuration (including connections, connection configuration
     parameters, switch configuration parameters) that the VSC has sent
     to it.

(10) In order to be scalable, the SCI must provide a recovery mechanism
     that does not disrupt unaffected connections The  recovery mechan-
     ism  must be able to resynchronize  only the part of the state that
     is related to a failure.

(11) The SCI shall support hitless redundant VSCE switchover: A redun-
     dant VSCE should be able to assume control of the VS without dis-
     rupting existing user plane connections.

(12) The SCI should be able to operate properly over an unreliable
     interconnect or network.

(64) The SCI shall support hitless resynchronization between the VSC and
     VS when they are already in sync. Some examples of resynchroniza-
     tion when the VSC and VS are in sync are:

*    Resynchronization after VSC rebuild

*    Resynchronization after VSC upgrades/downgrades

*    Resynchronization after switch component switchover

*    Resynchronization after switch component rebuild

*    Resynchronization after switch component upgrades/downgrades

(65) The VSC shall be allowed to submit new SCI requests which affect
     virtual switch state (e.g., establish new connections, delete
     existing connections) while resynchronization is being performed,
     after re- establishment of the association between the VSC and the
     VS.


3.6.  Security Requirements

(13) The SCI shall allow the VSC and VS to authenticate each other's
     identity using an standards based authentication protocol (e.g.,
     IPSEC, ATM Forum).

(14) The SCI shall allow for secure communication between VSC and VS,



McEachern - Multiservice Switching Forum                       [Page 16]





Internet Draft   Switch Control Interface Requirements      21 June 1999


     using a standards based security protocol.

Note: Though not necessarily required in all VSC/VS connections, it is
possible that on occasion an installation may require that in addition
to authenticating the VSC/VS identities, the communications between a
VSC and the VS be secure.  In the case of a point to point link, one can
assume that physical access between the VSC and the VS is secure. In the
case of a remote link, for example a link over an IP connection, there
is no guarantee of secure communications without protocol provisions for
security.   Thus it is recommended that the protocol contain provisions
for the optional application of security so that remote communications
might be made securely.


3.7.  Functional Requirements

3.7.1.  Virtual Switch Configuration and Management

(20,25)
     The SCI shall allow the VSC to discover the capabilities and
     resources of the VS in a generic way.

The following examples are informative in nature. The capabilities of a
VS fall into several categories:

1.   Quantities of various partitioned resources that belong to this VS.
     Some examples are:

a.   Virtual Ports that make up this Virtual Switch

*    Type of Port (e.g., ATM, TDM, Frame Relay)

*    Incoming and outgoing bandwidth

*    Incoming and outgoing label space

*    Maximum number of connections  this accounts for both routing
     table space and number of connections that can be adapted to ATM
     (in the case of TDM or Frame ports).

b.   Controller Bandwidth  the simultaneous number of SCI messages that
     the VSC can submit, or the maximum number of SCI messages per
     second.

2.   QoS model(s) supported by the switch and associated parameters.
     Some examples are:

*    ATMF TM 4.0 traffic classes

*    MPLS traffic classes

*    Diff Serv traffic classes

*    Low level description of queue scheduling and buffer sizes



McEachern - Multiservice Switching Forum                       [Page 17]





Internet Draft   Switch Control Interface Requirements      21 June 1999


3.   Reliability abstraction

*    Which ports are hosted on redundant hardware

*    Switch redundancy (processor, etc.)

4.   Capabilities of the SCI slave (although some of these will need to
     be communicated outside the SCI so that the SCI master know how to
     set of the initial connection and query the SCI slave). This is
     essentially a listing of the SCI requirements that are met by this
     implementation. Here are some examples:

*    Base/Extended

*    List of supported options

*    Maximum number of Controller Entities simultaneously controlling a
     SCI slave.


3.7.2.  Connection control

(32) The SCI shall allow the VSC to add, delete, and verify connections
     within its VS.

(33) The SCI shall allow the VSC to modify connections within its VS.

(34) The SCI shall support point to point connections.

(35) The SCI shall support point to multipoint connections.

(36) The SCI shall support multipoint to point connections.

(38) The SCI shall support virtual channel and virtual path connections.

(39) The SCI shall support the termination of virtual paths (splitting a
     VP into VCs) as per I.311.

(41) The SCI shall allow the VSC to specify traffic and QoS parameters
     for each connection.


3.7.3.  Exception Notification

(49) The SCI should contain the vocabulary for the switch to notify VSCs
     of asynchronous events occurring in the switch that affect their
     VS. The minimal set of traps is:

*    Interface up or down

*    Change in available  interfaces

*    Interface faults




McEachern - Multiservice Switching Forum                       [Page 18]





Internet Draft   Switch Control Interface Requirements      21 June 1999


*    Switching faults

(50) The SCI shall provide a flow control mechanism for asynchronous
     event notifications.

(51) The SCI shall provide a mechanism for filtering asynchronous event
     notifications.


3.8.  SCI Protocol Implementation Requirements

(52) The SCP shall be capable of operating over ATM.

(54) The SCP shall be capable of operating over IP.

(56) The SCP should work as a remote protocol.


3.9.  Management Requirements

This section contains requirements that were identified as part of the
SCI requirements gathering process. Even though they are stated as SCI
requirements, they should not be considered as such. They are included
here because it may be necessary to perform some management functions
through the SCI. The MSF Switch Control working group has not yet agreed
upon which of these requirements do indeed apply to the SCI and intends
to clarify these requirements in a future I-D.


3.9.1.  Resource and Service Model Requirements

(22)[M]
     The SCI shall allow the VSC to associate subsets of the resources
     assigned its VS to service classes offered by the VS.

(77)[M]
     The management interface for creating VSs shall allow the user to
     choose from a set of offered switch resource abstractions.


3.9.2.  Virtual Switch Configuration and Management

(26)[M]
     The SCI shall allow the VSC to read and write VS configuration
     parameters. Examples include:

1.   Assigning bandwidth to classes of service

2.   Setting flow control parameters for the SCI.


3.9.3.  Virtual Port Configuration and Management

(27)[M]



McEachern - Multiservice Switching Forum                       [Page 19]





Internet Draft   Switch Control Interface Requirements      21 June 1999


     The SCI shall allow a virtual port to be brought in to service or
     taken out of service.

(28)[M]
     The SCI shall allow the VSC to reset a virtual port that belongs to
     its VS.

(29)[M]
     The SCI shall allow the VSC to configure rudimentary test states.

(30)[M]
     The SCI shall allow the VSC to set the bandwidth of a virtual port.

(31)[M]
     The SCI may allow the VSC to establish and manipulate label ranges
     per virtual port.

There are two possible reasons for this requirement.

1.   In one case there are VSs that have a flexible internal representa-
     tion of VPI/VCI space.  That is they offer the VSC the flexibility
     to determine the VPI/VCI matrix.  For example imagine a switch with
     1000 possible VCCs. These might be organized as 1 VPI with 1000
     VCIs or alternately as 10 VPIs with 100 VCIs each.  Alternatively,
     it might be possible to organize such a VS's space as follows VPI1
     with 1000 VCs, VPI2 with 500 VCs, VPI3 with 1500 VCs etc.

2.   The other case involves partitioning with dynamic assignment of
     resources.  It is possible tha a VS might allow for the VSC to
     request the number of VCC and might be flexible enough to allow for
     the range to be apportioned according to the VSC's VPI/VCI label
     range requirements.


3.9.4.  State and Statistics Reporting

(42)[M]
     The SCI shall allow the VSC to read counters associated with VS
     input and output virtual ports.

(43)[M]
     The SCI shall allow the VSC to read counters associated with vir-
     tual path and virtual channel connections.

(44)[M]
     The SCI shall allow the VSC to read individual switched connection
     state. Connection states include following: does-not-exist, exists,
     exists-failed.

(45)[M]
     The SCI shall allow the VSC to perform bulk reads of statistics for
     all connections on a specified virtual path or a specified virtual
     port.




McEachern - Multiservice Switching Forum                       [Page 20]





Internet Draft   Switch Control Interface Requirements      21 June 1999


(46)[M]
     The SCI may allow the VSC to collect data for performance monitor-
     ing, account management , and other statistics on request or at
     preset intervals.

(47)[M]
     The SCI shall allow the VSC to collect statistics for a single con-
     nection or for groups of connections for efficient scaling.

(48)[M]
     The detailed list of required statistics should include the BICI
     statistics for ATM and other statistics types for other services.


4.  Authors' addresses



        Jim McEachern
        Nortel Networks
        P.O. Box 3511 Stn C
        Ottawa, ON, Canada K1Y 4H7
        Tel: (613) 765-2206
        Email: jmceach@nortelnetworks.com

































McEachern - Multiservice Switching Forum                       [Page 21]