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]