VSI Messages

The information flow between VSI master and VSI slave has two directions. The VSI master sends connection requests to the VSI slave(s), and the VSI slave(s) update the VSI master with switch information.

Figure 2-8 shows the format of the VSI message. It allows the future definition of new parameter group formats without having to redefine the message format.

Figure 2-8. General VSI Message Format

Every VSI message has a version-id field in the header. The VSI master and VSI slave are expected to support multiple old versions to allow upgrades and backward compatibility. The VSI master is required to select the VSI protocol version used by the slaves. The master chooses the highest version that is common to both the VSI slave and VSI master, performing VSI version negotiation. Also, in multiservice switching networks, a slave is expected to be able to handle different versions, because different VSI masters can select different versions for the same VSI slave.

NOTE

VSI version negotiation happens at the VSI session level. In other words, a VSI master can use VSI version X with some slaves and VSI version Y with other slaves. Moreover, a VSI slave can use VSI version A with one master and VSI version B with a second master.

The parameter-group format is shown in Figure 2-9.

Figure 2-9. Parameter-Group Format

In a VSI message, a given function code can have more than one valid message-format-id. A parameter-group structure can be used in different message formats (and function codes). A given parameter group type can have more than one valid parameter-group format.

VSI messages can be divided into the following main groups:

• Connection messages There are two subtypes of connection messages:

  - Connection requests The controller requests connection-related commands (setup reserve, setup commit, teardown, modification, or get information).
  
  

  - Connection request responses The VSI slave acknowledges the connection requests. The slave is required to reply with either ACK or NACK, and the master is required to get an explicit reply for every connection request.
  
  

• Interface information The controller gets interface information from the switch using these messages. The VSI slave(s) can also send notification of changes asynchronously with VSI traps. VSI is designed such that it eliminates the need for the controller to know the details of the interface.

• Switch information The controller gets switch-related information with these messages. The switch can also send updates asynchronously (such as changes in synchronization state [session-id] and changes to logical interfaces). These messages are also often used as keepalive messages between the master and all the slaves.

• Miscellaneous information These messages include the generic error response message, the generic debug command and response, and passthrough (up and down, command and response).

• Bulk statistics Messages (commands, responses, and traps) related to bulk statistics.

It's worth mentioning that in a distributed model, the slaves have specific functions apart from the VSI slave functions, such as performing resource management operations and call acceptance, responding to connection requests, notifying the controller of changes in the interfaces, and interfacing with the hardware drivers. These functions are to set up VSI communication channels with other VSI slaves in the controlled switch, communicate with other slaves for connection setup, maintain individual session-ids per slave, and maintain an interfaces-to-slave mapping. The switch is also responsible for setting up a full mesh of VSI interslave communication channels, transparently to the VSI master.

NOTE

Each VSI master maintains individual and independent sessions with each slave (each session has its own flow-control configuration). The VSI slaves, therefore, are also called sessions.

The VSI protocol specifies that the slave modules communicate with each other in setting up connections that span multiple slaves, as shown in Figure 2-10.

Figure 2-10. Cross-Connects: VSI Slave Distributed Model

In Figure 2-10, the networking module (connection routing and signaling) decides to set up (reserve) a cross-connect between interfaces A and B in the controlled switch. Two different VSI slaves manage the two interfaces' resources:

Step 1.	The VSI master sends a connection request command to the VSI slave that manages interface A's resources.
Step 2.	After passing the CAC (Connection Admission Control), VSI slave A allocates resources locally and sends the connection request to VSI slave B for setting up the second leg of the cross-connect.
Step 3.	VSI slave B checks the CAC, allocates resources, and acknowledges the request with a connection request response to VSI slave A.
Step 4.	When the two legs or endpoints of the cross-connect are set up (reserved), VSI slave A sends the connection request response to the VSI master. The response also includes updated loading information for the interfaces. This approach also eliminates any central bottleneck and allows performance scalability using distributed processing.

Note that this example only requests that a connection segment be set upthat is, reserved. The activation of the segment is performed with a connection commit.