General Switch Management Protocol (GSMP) V3
Extracted elements (31)
GSMP is deliberately asymmetric (controller as master, switch as slave) to allow a single controller to manage multiple switches via separate control connections and to allow a switch to be controlled by multiple controllers via static switch partitioning, cleanly separating control-plane intelligence from forwarding hardware.
Label stacking is supported with no set depth limit to accommodate MPLS hierarchical labelling; a stacked label is treated as a single atomic extended label for all switch operations so that add, move, and delete apply to the full stack simultaneously.
Switch partitioning is static and occurs prior to running GSMP; each partition appears to its controller as an independent label switch with its own ports and resources, so the controller can treat partition resources as if they were the actual physical resources.
The Bi-directional B flag is described as a pure convenience: it is equivalent to two Add Branch messages in opposite directions and is provided only to reduce control traffic. All subsequent operations on the two resulting unidirectional connections MUST be performed separately, and there is no bi-directional delete command.
The Multicast M flag in Add Branch is an optional hint rather than a binding directive; its purpose is to allow switches that use different data structures for unicast vs. multicast connections to pre-allocate the correct structure on the first branch, avoiding the cost of deleting a point-to-point structure and rebuilding it as multicast when the second branch arrives.
A switch may support multiple label types but each port supports exactly one; connections may be established between ports of different label types using the Adaptation Method field (N flag for null/same-type adaptation, O flag for opaque/vendor-defined adaptation, or explicit Input/Output Adaptation codes such as 0x100=PPP, 0x200=FRF.5, 0x201=FRF.8).
GSMP packet encapsulations for ATM, Ethernet, and TCP are specified in a separate document ([15], RFC 3293); additional encapsulations may be defined in further documents. RFC 3292 itself does not specify any encapsulation.
All GSMP switches MUST support the default QoS Configuration, which includes the Service Model, the Simple Abstract Model (strict priorities), and the QoS Profile Model. Additional optional QoS Configurations may also be supported.
Any field in a GSMP message that is unused or defined as 'reserved' MUST be set to zero by the sender and ignored by the receiver. A success response message MUST NOT be sent until the requested operation has been successfully completed.
For ATM VPC Add Branch (Message Type=26), if either specified port is not an ATM port a failure MUST be returned ('28: ATM Virtual path switching is not supported on non-ATM ports'); if a virtual channel connection already exists on any channel within the virtual path a failure MUST be returned ('26: Attempt to add an ATM virtual path connection branch to an existing virtual channel connection').
For the Verify Tree message (Message Type=19), which has been removed from GSMPv3, a switch receiving a request with Message Type=19 MUST return a failure response with Code '3: The specified request is not implemented on this switch'.
If the Port Session Number in a request message does not match the current Port Session Number for the specified port, a failure response message MUST be returned with Code '5: Invalid port session number'. A new Port Session Number MUST be generated when a port returns to Available from Unavailable/Loopback or when line status returns to Up.
No GSMP messages (other than adjacency protocol messages) may be sent across the link until the adjacency protocol has achieved synchronisation; all GSMP messages received on a link that does not currently have state synchronisation MUST be discarded.
On completion of a Delete All Input Port or Delete All Output Port operation, all connections on the port MUST be deleted and all dynamically assigned Label values MUST be unassigned; there MUST be no connections established in the Label space GSMP controls on that port.
The Connection Replace R flag MUST be pre-configured via the Port Management message before use; if the R flag is set without pre-configuration the switch MUST return failure '36: Replace of connection is not activated on switch'. The R flag MUST NOT be set together with either the M or B flags.
When issuing a failure response the switch MUST choose the most specific applicable failure code according to the precedence: Invalid Message > General Message Failure > Specific Message Failure > Connection Failures > VP Connection Failures > Multicast Failures > QoS Failures > General Failures > Warnings.
The Add Branch message (Message Type=16) establishes a new connection or adds an output branch to an existing connection identified by Input Port and Input Label, with an optional Traffic Parameters Block appended when IQS or OQS=0b10 (Service Model). Flags include M (Multicast hint), B (Bi-directional), and R (Connection Replace).
The Adjacency Protocol (section 11) uses a dedicated message type to synchronise state across the controller-switch link, negotiate the GSMP protocol version, discover the peer identity, and detect peer changes. The Code field in the adjacency message determines the message function; the Transaction Identifier field is absent.
The Delete Branches message (Message Type=17) batches one or more Delete Branch Elements in a single request; each element specifies Input Port, Input Label, Output Port, and Output Label. The response carries a per-element Error field, and a failure in any element MUST NOT prevent processing of others.
The Move Input Branch message (Message Type defined in section 4.9) moves a connection from one input port/label to another in a single atomic transaction, preserving all existing output branches.
The Move Output Branch message (Message Type=22) atomically moves a single output branch from an old Output Port/Label to a new Output Port/Label without modifying any other branches of the connection.
The Reservation Management messages (Reservation Request, Delete Reservation, Delete All Reservations) allow the controller to pre-reserve switch resources identified by a Reservation ID; a valid non-zero Reservation ID in an Add Branch message causes the reserved traffic parameters to be applied and allows the Traffic Parameters Block to be omitted.
Appendix B defines IANA Considerations establishing registries for GSMPv3 message types (covering Connection Management, Reservation Management, Port Management, State and Statistics, Configuration, QoS, Events, and ARM extension message classes), label types (ATM 0x100, FR 0x101, MPLS Generic 0x102, FEC 0x103), and failure/warning response codes.
Section 13 addresses security for GSMPv3. Because the protocol is an asymmetric control-plane interface that grants a controller complete authority over connection state, port configuration, QoS assignments, and resource reservations on a switch, the control channel MUST be protected against unauthorized access, spoofing, and replay; authentication and integrity protection are required at the transport or encapsulation layer.
The Adjacency Protocol defines state tables (section 11.2.1) for the adjacency state machine, including states for partition information (section 11.3) and loss-of-synchronisation (section 11.4). Multiple controllers per partition are handled by a dedicated Multiple Controller Adjacency Process (section 11.5.1).
All GSMP messages except the adjacency protocol message share a common 12-byte fixed header: Version (8 bits), Message Type (8 bits), Result (8 bits), Code (8 bits), Partition ID (8 bits), Transaction Identifier (24 bits), I flag (1 bit), SubMessage Number (15 bits), and Length (16 bits), followed by a variable-length Message Body. Fields are big-endian.
ATM Labels (Type=0x100) encode a 12-bit VPI and 16-bit VCI in a 32-bit value. For virtual path connections the VCI field is not used and SHOULD be set to zero by the sender and ignored by the receiver.
FEC Labels (Type=0x103) encode a list of FEC Elements; in GSMPv3 only Prefix FEC Elements (Element Type=0x02) are supported, each containing a 1-octet Element Type, 2-octet Address Family, 1-octet Prefix Length, and variable-length Prefix.
Frame Relay Labels (Type=0x101) contain a 2-bit Len field (0=10-bit DLCI, 2=23-bit DLCI) and a DLCI value, supporting both 10-bit and 23-bit addressing formats per [21].
Labels use TLV encoding: a 2-octet field containing 4 flag bits (including the S stacked-label indicator) and a 12-bit Label Type, followed by a 16-bit Label Length, followed by a variable-length Label Value that is an integer number of 32-bit words.
MPLS Generic Labels (Type=0x102) encode a 20-bit label value (as specified in RFC 3032) in a 32-bit field with 12 reserved leading bits, used for technology-independent links such as PPP and Ethernet.