Introduction to the General Switch Management Protocol (GSMP)

The IP Switch is constructed from two components, an ATM switch and a Switch Controller, fig. 1. The Switch Controller is a high-end Pentium Pro machine running an operating system that continues to bear some resemblance to UNIX. One of the ports on the ATM switch is connected to an ATM interface on the Switch Controller and is used to control the switch. The control protocol used between the switch and the controller is the General Switch Management Protocol, GSMP (RFC1987), which has been designed to give the IP Switch Controller full control of an ATM switch.

The IP switch is implemented in two components to allow a separation between hardware and software. Thus any ATM switch that supports RFC1987 may be used for the switching component. Different ATM switches are designed with different size, cost, and functionality tradeoffs so it makes sense to support a choice. This choice goes both ways. GSMP can also support a standard ATM Forum control protocol stack instead of the IP Switch Controller software. So a choice of network control software is possible for the same hardware.

The design goal for the GSMP interface is to be as close to the actual switch hardware as possible and yet capable of controlling all (reasonable) ATM switch designs. These are conflicting requirements. GSMP is a simple master-slave, request-response protocol. The master (switch controller) sends requests and the switch issues a positive or negative response when the operation is complete. Virtual paths and virtual channels are assumed to be unidirectional. Unreliable message transport is assumed between controller and switch for speed and simplicity. (The link between switch and controller will either be very reliable, or broken, in which case the overhead of adding error detection and retransmission through a protocol like SSCOP is unnecessary. All GSMP messages are acknowledged and the implementation handles its own retransmission.)

GSMP runs on a single, well-known virtual channel (VPI 0, VCI 15). All messages use an AAL-5 LLC/SNAP encapsulation but the most frequent messages (connection management) are designed to be small enough to be single cell AAL-5 packets. The LLC/SNAP encapsulation was chosen to allow other protocols beside GSMP to be multiplexed onto the link by using a different "Ethertype" in the SNAP header. For example, while GSMP offers some simple network management features, the Simple Network Management Protocol (SNMP) will be required between the controller and switch to offer full-service network management. (While SNMP can be used to establish connections in an ATM switch it was considered far too heavyweight a protocol to satisfy the design goals of GSMP.)

An adjacency protocol is used to synchronize state across the control link, to discover the identity of the entity at the far end of the link, and to detect when it changes. No GSMP messages other than the adjacency protocol may be sent across a link until adjacency has been established. Once established, five types of message may be sent: configuration, connection management, port management, statistics, and events.

The configuration messages are used by the controller to discover the capabilities of the ATM switch. Beyond name, rank, and serial number, each ATM switch port can report: the incoming VPI and VCI ranges it can support, its interface type and cell rate, its administrative and line status, and the number of priority levels it supports in its output queue. GSMP (RFC1987) assumes simple strict priority output queues of which any number of priority queues per port may be specified. (Queue structures other than output queueing may be mapped into this model.) The protocol will be extended to support the next generation of ATM queueing and scheduling hardware currently in development. Traffic policing (usage parameter control) is also not supported in RFC 1987.

Once the configuration of the switch has been discovered, the controller can begin issuing connection management messages. These are the most common messages. They enable the controller to establish and remove connections across the switch. No distinction is made between unicast and multicast connections — the "Add Branch" and "Delete Branch" messages are used for both. The first Add Branch message on a new incoming VCI defines a new unicast connection. The second Add Branch message on an existing incoming VCI converts the connection to a point-to-multipoint connection with two branches, etc. This was intentional as no distinction is made in IFMP. However, in hindsight, it would be better to give a hint if a multicast connection is being established as many switches use completely different data structures to implement unicast and multicast connections. A Delete Tree message is available to delete an entire multicast connection. A Move Branch message allows a single output branch of a multicast connection to be moved from one output port and VCI to another. The Move Branch message is used in the cut-through operation where an IP flow is moved from connectionless forwarding to direct switching.

Of the remaining GSMP messages, the Port Management message is used to reset, bring up, take down and loopback switch ports. The statistics message permits various per-VC and per-port performance counts to be requested. The event messages allow a switch to asynchronously alert the controller to significant events such as: loss (or detection) of carrier on a port, loss (or detection) of port interfaces (so that hot-swap hardware may be supported), and arrival of cells with invalid VPI/VCIs. A simple flow control protocol is applied to the event messages to prevent the controller being flooded.

At the time of writing, RFC1987 has been implemented on at least eight different ATM switches. The code size for the GSMP slave is about 2,000 lines. A reference implementation is available and it typically takes one or two weeks to get GSMP up and running on a new switch design. The measured performance of the GSMP slave on Ipsilon’s IP switch is currently just under 1000 connection setups per second. This could be improved considerably if an ATM segmentation and reassembly (SAR) device were added to the switch to offload many of the packet handling and AAL processing functions currently performed in software by the embedded processor on the ATM switch.