Table Of Contents
Virtual Switch Interface
This appendix provides a description of the Virtual Switch Interface (VSI) protocol as it is used to control a BPX node for PNNI routing or Multiprotocol Label Switching (MPLS) in switched software Release 9.2.
The appendix contains the following:
Virtual Switch Interface Protocol
The Virtual Switch Interface (VSI) protocol is used to control a Cisco Wide Area Network switch, such as the BPX 8620, for networking applications, such as MultiProtocol Label Switching (MPLS: sometimes referred to as Tag switching) or PNNI routing. The VSI is a mechanism for networking applications to control the BPX 8600 and use a partition of the switch's resources for its specific application. With VSI, external controllers are used to control the switch for applications not supported by the traditional WAN switch set of routing protocols known as AutoRoute.
The VSI protocol allows a BPX switch to be controlled by multiple controllers, such as a PNNI controller (SES PNNI controller) or an MPLS controller (Tag or Label Switch Controller), along with the traditional AutoRoute controlling software. These additional controllers provide control planes that can be external or internal to the BPX switch.
VSI Master and Slaves
The VSI protocol is a master/slave protocol. The master part of the VSI protocol runs on the SES PNNI controller for PNNI networking, and is referred to in this application as the PNNI controller. (For MPLS, the controller is an external Tag Switch controller.) The slave part of the VSI protocol runs on the BXMs on the BPX 8620. Figure D-1 provides a simple illustration of VSI master and slave relationship.
Figure D-1 VSI, Controller and Slave VSIs
When enabled and configured, the VSI controller automatically establishes a link between the VSI master and every VSI slave on the associated switch, as shown in Figure D-2. When enabled, the VSI slaves in turn establish links between each other.
Figure D-2 VSI Master and VSI Slave Example
The BXM has 32 virtual interfaces that provide a number of resources including Qbin buffering capability. With physical lines and trunks, one virtual interface is assigned to each port. (Figure D-3).
With virtual trunking, a physical trunk can comprise a number of logical trunks called virtual trunks, and each of these virtual trunks is assigned the resources of one of the 32 virtual interfaces on a BXM (Figure D-3).
Each virtual interface has 16 Qbins assigned to it. Qbins 0-9 are used for AutoRoute and 10-15 are available for use by a VSI enabled on the virtual interface. (In release 9.1, only Qbin 10 was used.) The Qbins 10-15 support class of service (CoS) templates on the BPX.
A virtual switch interface may be enabled on a port, trunk, or virtual trunk. The virtual switch interface is assigned the resources of the associated virtual interface,
Figure D-3 BXM Virtual Interfaces and Qbins
With the VSI protocol, the resources on a BXM port or trunk must be partitioned between competing controllers, AutoRoute, MPLS, and PNNI. Once the resources have been partitioned, the controller can use them for its networking application. In other words, AutoRoute uses the resources in its partition to provision permanent virtual circuits, just like a standard BPX switch. And the PNNI controller, will use the resources in its partition to establish ATM switched virtual circuits. The two partitions are completely independent and the connections from one never interfere with the connections in another partition.
Note Resources can only be partitioned on a BXM card in release 9.2.
The resources that need to be configured for a partition are shown in Table D-1 for a partition designated ifci (interface controller 1). The three parameters that need to be distributed are number of logical connections (LCNs), bandwidth (BW), and virtual path identifiers (VPIs).
Table D-1 ifci parameters (virtual switch interface)
ifci parameters Min Max
Partition Criteria shows theVPI ranges available for partitions on a BXM card.
When a trunk is added, the entire bandwidth is allocated to AutoRoute. To change the allocation in order to provide resources for a VSI partition, the cnfrsrc BPX CLI command is used on the BXM.
This section describes how to perform the following tasks for ILMI functionality:
Support Enabling ILMI Functionality for VSI Partitions on Port Interfaces
The ILMI protocol can either run on the BPX or on the BXM card. For ILMI functionality to work for VSI partitions, the ILMI protocol should run on the BXM card.
To enable ILMI functionality for VSI partitions on port interfaces:.
Step 1 Enable ILMI session for the port using the cnfport command.
a. When prompted for protocol type, specify the ILMI protocol by typing an i.
b. When prompted by "Protocol by the Card?" type y.
Step 2 Enable VSI ILMI functionality using the cnfvsipart command, as in the following example for active VSI partition 1 on a port interface 13.1
cnfvsipart 13.1 1 y
Enable ILMI Functionality for VSI Partitions on Physical Trunk Interfaces
This section describes how to enable ILMI functionality for an active VSI partition, using the example of active VSI partition 1 on a physical trunk interface 13.2.
Step 1 Enable ILMI protocol to run on the BXM card by using the cnftrk command.
Step 2 When prompted by "Protocol by the card?" type y.
Note NOTE: Unlike the cnfport command, the cnftrk command does not provide an option to configure the ILMI protocol on the trunk. The cnfvsipart command automatically configures on the trunk.
Enable VSI ILMI Functionality on Virtual Trunk Interfaces
This section describes how to enable ILMI functionality for an active VSI partition on a specified virtual trunk interface, using the example of active VSI partition 1 on a virtual trunk interface 13.3.1.
ILMI sessions on Virtual trunks always run on the BXM card. Hence it is not necessary that you run the cnftrk command when enabling ILMI functionality for a VSI partition on a virtual trunk interface.
Step 1 Enable ILMI functionality for the VSI partition on the virtual trunk interface using the cnfvsipart command.cnfvsipart 13.3.1 1 y
Note ILMI functionality cannot be enabled on Feeder Trunk Interfaces.
By default LMI protocol runs on these interfaces.
Step 2 Check to ensure that ILMI functionality is enabled for a VSI partition on an interface
Note NOTE: Currently all ILMI sessions exchange only the BPX NW IP address with peer ILMI sessions.
The Sys_Id is generated using the NOVRAM contents in the backplane of the BPX shelf. If for some reason, this NOVRAM could not be read, then a default Sys_Id of 1 is downloaded to the BXM card. If this is done, the dspvsipartcnf command will display this information as follows:Sys_Id generation failed!! Using default value = 0.0.0.0.0.1
Use the cnfvsipart command to configure VSI partition characteristics. The cnfvsipart command is currently the only way to enable VSI ILMI sessions.
cnfvsipart <slot.port.[vtrk]> <part_id> <enable_option>
slot, port of the interface.If applicable, enter the virtual port number.
partition identifier associated with the VSI partition.
Activate (y) or deactivate (n) the VWI ILMI session,
cnfrsrc, dspvsipartcnf, cnfport, cnftrk
Use the dspvsipartcnf command to view VSI partition characteristics.
Currently this command only displays information about VSI ILMI sessions. This command displays whether VSI ILMI is enabled for a given partition, the LCN used for the sessions (only for trunk interfaces) and the type of IP address downloaded to the BXM card for topology discovery purposes.
On Trunk Interfaces, ILMI functionality can be enabled on one VSI partition only. Use the dspvsipartcnf command to view ILMI functionality for VSI partitions on trunk interface 13.2,dspvsipartcnf 12.1
If, for example, a VSI ILMI session is enabled on partition 1, it would provide output similar to the following example:Trunk: 13.2 Partn: 1 ILMI: E LCN: 272 Topo: BPX NW IPTrunk: 13.2 Partn: 2 -- VSI partition DISABLEDTrunk: 13.2 Partn: 3 -- VSI partition DISABLEDSys_Id generated = 126.96.36.199.30.35
The above output says that ILMI functionality is enabled on VSI partition 1 on trunk interface 13.2 and it uses LCN 272 and the BPX Network IP is exchanged by the ILMI session with the peer ILMI session.
If no partition is specified, this command displays the above information about all the VSI partitions and also the Sys_Id downloaded to the BXM card for ILMI functionality.
dspvsipartcnf <slot.port.[vtrk]> [partition_id]
Class of Service Templates
Class of Service Templates (COS Templates) provide a means of mapping a set of standard connection protocol parameters to "extended" platform specific parameters. Full QoS implies that each VC is served through one of a number of Class of Service buffers (Qbins) which are differentiated by their QoS characteristics.
Note The terms—"Class of Service Template," and "COS Template"—can be used interchangeably.
When a connection set up request is received from the VSI Master in the PNNI or MPLS controller, the VSI slave (in the BXM) uses the class of service index of the request to retrieve the corresponding set of extended parameters defined in the template for the corresponding index. The BXM VSI slave uses these values to complete the connection setup and program the cross-connect in the card.
The service class template provide a means of mapping a set of extended parameters, which are generally platform specific, based on the set of standard ATM parameters passed to the VSI slave during connection setup.
A set of service templates is stored in each switch (e.g., BPX) and downloaded to the service modules (e.g., BXMs) as needed.
The service templates contains two classes of data.
•One class consists of parameters necessary to establish a connection (for example, per VC) and includes entries such as UPC actions, various bandwidth related items, per VC thresholds, etc.
•The second class of data items includes those necessary to configure the associated class of service buffers (Qbins) that provide QoS support.
The general types of parameters passed from a VSI master to a slave include:
•A service type identifier
•QOS parameters (CLR, CTD, CDV)
•Bandwidth parameters (e.g. PCR, MCR)
•Other ATM Forum Traffic Management 4.0 parameters
Each VC added by a VSI master is assigned to a specific service class by means of a 32-bit service type identifier. Current identifiers are for:
•ATM Forum service types (used for ATM SVCs)
When a connection setup request is received from a VSI master controller, the VSI slave uses the service type identifier to index into a Service Class Template database containing extended parameter settings for connections matching that index. The firmware then programs the hardware with the applicable extended parameter values to complete the connection setup.
One of the parameters specified for each service type is the particular BXM class of service buffer (Qbin) to use. The Qbin buffers provide separation of service type to match the QoS requirements.
Service class templates on the BPX are maintained by the BCC and are downloaded to the BXM cards as part of the card configuration process as a result of card activation, rebuild, or switchover. In release 9.2 the templates are non-configurable.
Nine template types are available (as of 9.2.3x). You can assign any one of the templates to a virtual switch interface (Figure D-4). For more information about these templates, see the BPX documentation associated with Release 9.2.30.
Figure D-4 Service Class Template Overview
Service Class Template Structure
Each template table row includes an entry that defines the Qbin to be used for that class of service (Figure D-5).
This mapping defines a relationship between the template and the interface Qbin's configuration.
A Qbin template defines a default configuration for the set of Qbins for the logical interface. When a template assignment is made to an interface, the corresponding default Qbin configuration becomes the interface's Qbin configuration. Some of the parameters of the interface's Qbin configuration can be changed on a per interface basis. Such changes affect only that interface's Qbin configuration and no others, and do not affect the Qbin templates.
Qbin templates only are used with Qbins that are available to VSI partitions (PNNI or MPLS), namely Qbins 10 through 15. Qbins 10 through 15 are used by the VSI on interfaces configured as trunks or ports. The rest of the Qbins (0-9) are reserved for and configured by AutoRoute.
Figure D-5 Service Class Template and Associated Qbin Selection
Downloading Service Class Templates
Service Class Templates are downloaded to a BXM card under the following conditions:
•when adding a y-redundant card
•during a BCC (control card) switchover
•when a card that has active interfaces is reset (Hardware reset)
•during a BCC (control card) rebuild
Assignment of a Service Class Template to an interface
A default Service Class Template is assigned to a logical interface (VI) when the interface is upped via upport/uptrk.
•uptrk 1.1.1 (virtual trunk)
This default template has the identifier of 1. Users can change the Service Class Template from Service Class Template 1 to another Service Class Template using the cnfvsiif (configure VSI interface) command. The dspvsiif command allows the user to display the template associated with the interface. For example:
•cnfvsiif 1.1 2
•cnfvsiif 1.1.1 2
The cnfvsiif command is used to assign a selected Service Class Template to an interface (VI) by specifying the template number. It has the following syntax:
cnfvsiif <slot.port.vtrk> <tmplt_id>
The dspvsiif command is used to display the type of Service Class Template assigned to an interface (VI). It has the following syntax:
Card Qbin Configuration
When an interface (VI) is activated by uptrk or upport, the default Service Class Template is assigned to the interface (VI). The corresponding Qbin template is then copied into the card's (BXM) data structure of that interface. A user can change some of the Qbin parameters using the cnfqbin command. The Qbin is now "user configured" as opposed to "template configured". This information may be viewed on the dspqbin screen.
The available Qbin parameters are shown in Table D-3. Notice that the Qbins available for VSI are restricted to Qbins 10-15 for that interface. All 32 possible virtual interfaces are provided with 16 Qbins.
Additional Service Class Template commands are:
Extended Services Types Support
The service-type parameter for a connection is specified in the connection bandwidth information parameter group. The service-type and service-category parameters determine the service class to be used from the Service Class Template.
Connection Admission Control (CAC)
For Release 9.2, when a connection request is received by the VSI Slave, it is first subjected to a Connection Admission Control process before being forwarded to the FW layer responsible for actually programming the connection. The granting of the connection is based on the following criteria:
•LCNs available in the VSI partition
When the VSI slave accepts (for example, after CAC) a connection setup command from the VSI master in the PNNI or MPLS Controller, it receives information about the connection including service type, bandwidth parameters, and QoS parameters. This information is used to determine an index into the VI's selected Service Class Template's VC Descriptor table thereby establishing access to the associated extended parameter set stored in the table.
Supported Service Types
The service type identifier is a 32-bit number. Table D-4 lists the supported service types.
A summary of the parameters associated with each of the Service Class Templates is provided in Table D-5 through Table D-8. Table D-9 provides a description of these parameters and also the range of values that may be configured if the template does not assign an arbitrary value.
Table D-5 lists the parameters associated with Default (0x0001) and Signaling (0x0002) Service Class Template categories.
* indicates not applicable
Table D-8 lists the connection parameters and their default values for MPLS (Tag Switching) Service Class Templates.
Table D-9 describes the connection parameters that are listed in the preceding tables and also lists the range of values that may be configured, if not pre-configured.