RFC 3292
General Switch Management Protocol (GSMP) V3
RFC 3292: General Switch Management Protocol (GSMP) V3 💖
Okay bestie, this is RFC 3292! 🦋 It's a Standards Track doc from June 2002, so it's an actual Internet standard, not just a suggestion. ✨ The authors are A. Doria, F. Hellstrand, K. Sundell, and T. Worster. Doria and Hellstrand are at Lulea University of Technology 🎀, and Sundell and Worster are at Nortel Networks 💅. The header doesn't list anything it obsoletes or updates, so this one stands on its own. 🌸
Status of This Memo 📜
Okay, so this is an Internet standards track protocol for the Internet community 🌈 It's inviting discussion and suggestions for improvements, so speak up if you have ideas! 💜 To see where this protocol stands in standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 And yes, distribution of this memo is unlimited, so go share it! 🫶
Copyright Notice ©️
Copyright (C) The Internet Society (2002). All Rights Reserved. 💖
Abstract 🦋
Okay, the star of the show is the General Switch Management Protocol Version 3 (GSMPv3) ✨ It's an asymmetric protocol, which means one or more external switch controllers can set up and keep up the state of a label switch 🎀 Think of an ATM, frame relay, or MPLS switch! 💅 GSMPv3 lets controllers handle both unicast and multicast switch connection state, and it also covers switch system resources and QoS features. It's giving full control, honestly! 👑
Acknowledgement 🙏
GSMP was originally created by P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, and G. Minshall (see [6] and [7]) 🌷 This version of GSMP is built on their work, so big thanks to them! 🫶
Contributors 🌟
Besides the authors and editors in the heading, tons of GSMP group members made serious contributions to this spec 🧚 The ones who contributed materially are: Constantin Adam, Clint Bishard, Joachim Buerkle, Torbjorn Hedqvist, Georg Kullgren, Aurel A. Lazar, Mahesan Nandikesan, Matt Peters, Hans Sjostrand, Balaji Srinivasan, Jaroslaw Sydir, and Chao-Chun Wang. Iconic cast, no cap! 💖
Specification of Requirements 📏
Here's the key-word rule. The words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be read the way [RFC2119] describes them 🍓
Keep an eye on these words. Their meaning comes from [RFC2119], not from everyday English, so don't skip over them! 💀
Table of Contents 📑
1. Introduction ................................................... 4
2. GSMP Packet Encapsulation ...................................... 6
3. Common Definitions and Procedures .............................. 6
3.1 GSMP Packet Format ........................................... 7
3.1.1 Basic GSMP Message format ................................ 7
3.1.2 Fields commonly found in GSMP messages .................. 11
3.1.3 Labels .................................................. 12
3.1.4 Failure Response Messages ............................... 17
4. Connection Management Messages ................................ 18
4.1 General Message Definitions ................................. 18
4.2 Add Branch Message .......................................... 25
4.2.1 ATM specific procedures: ................................ 29
4.3 Delete Tree Message ......................................... 30
4.4 Verify Tree Message ......................................... 30
4.5 Delete All Input Port Message ............................... 30
4.6 Delete All Output Port Message .............................. 31
4.7 Delete Branches Message ..................................... 32
4.8 Move Output Branch Message .................................. 35
4.8.1 ATM Specific Procedures: ................................ 37
4.9 Move Input Branch Message ................................... 38
4.9.1 ATM Specific Procedures: ................................ 41
5. Reservation Management Messages ............................... 42
5.1 Reservation Request Message ................................. 43
5.2 Delete Reservation Message .................................. 46
5.3 Delete All Reservations Message.............................. 47
6. Management Messages ........................................... 47
6.1 Port Management Message ..................................... 47
6.2 Label Range Message ......................................... 53
6.2.1 Labels .................................................. 56
7. State and Statistics Messages ................................. 60
7.1 Connection Activity Message ................................. 61
7.2 Statistics Messages ......................................... 64
7.2.1 Port Statistics Message ................................. 67
7.2.2 Connection Statistics Message ........................... 67
7.2.3 QoS Class Statistics Message ............................ 68
7.3 Report Connection State Message ............................. 68
8. Configuration Messages ........................................ 73
8.1 Switch Configuration Message ................................ 73
8.1.1 Configuration Message Processing ........................ 75
8.2 Port Configuration Message .................................. 75
8.2.1 PortType Specific Data .................................. 79
8.3 All Ports Configuration Message ............................. 87
8.4 Service Configuration Message ............................... 89
9. Event Messages ................................................ 93
9.1 Port Up Message ............................................ 95
9.2 Port Down Message .......................................... 95
9.3 Invalid Label Message ...................................... 95
9.4 New Port Message ........................................... 96
9.5 Dead Port Message .......................................... 96
9.6 Adjacency Update Message ................................... 96
10. Service Model Definition .................................... 96
10.1 Overview .................................................. 96
10.2 Service Model Definitions ................................. 97
10.2.1 Original Specifications ............................... 97
10.2.2 Service Definitions ................................... 98
10.2.3 Capability Sets ....................................... 99
10.3 Service Model Procedures .................................. 99
10.4 Service Definitions ....................................... 100
10.4.1 ATM Forum Service Categories .......................... 101
10.4.2 Integrated Services ................................... 104
10.4.3 MPLS CR-LDP ........................................... 105
10.4.4 Frame Relay ........................................... 105
10.4.5 DiffServ .............................................. 106
10.5 Format and Encoding of the Traffic Parameters ............. 106
10.5.1 Traffic Parameters for ATM Forum Services ............. 106
10.5.2 Traffic Parameters for Int-Serv Controlled Load Service 107
10.5.3 Traffic Parameters for CRLDP Service .................. 108
10.5.4 Traffic Parameters for Frame Relay Service ............ 109
10.6 Traffic Controls (TC) Flags ............................... 110
11. Adjacency Protocol .......................................... 111
11.1 Packet Format ............................................. 112
11.2 Procedure ................................................. 115
11.2.1 State Tables .......................................... 117
11.3 Partition Information State ............................... 118
11.4 Loss of Synchronisation.................................... 119
11.5 Multiple Controllers Per Switch Partition ................. 119
11.5.1 Multiple Controller Adjacency Process ................. 120
12. Failure Response Codes ...................................... 121
12.1 Description of Failure and Warning Response Messages ...... 121
12.2 Summary of Failure Response Codes and Warnings ............ 127
13. Security Considerations ..................................... 128
Appendix A Summary of Messages ................................. 129
Appendix B IANA Considerations ................................. 130
References ...................................................... 134
Authors' Addresses .............................................. 136
Full Copyright Statement ........................................ 1371. Introduction ✨
okay so GSMP (the General Switch Management Protocol) is giving general purpose 💅 It's how a controller runs a label switch 🎀 With it, a controller can set up and tear down connections across the switch, add and remove leaves on a multicast connection, manage switch ports, ask for configuration info, request and delete reservations of switch resources, and grab statistics 📊 The switch can also tell the controller about async events, like a link going down 😭
GSMP is asymmetric, so the controller is the master and the switch is the slave 🫶 One controller can run several switches by using separate instances of the protocol over separate control connections. A switch can also have more than one controller, and that's where partitioning comes in 🧚
A "physical" switch can be split into virtual switches called partitions. In this version, partitioning is static and happens before GSMP starts running. The implementation keeps partitions isolated from each other, and the controller assumes the resources given to a partition are always available to it. To its controller, a partition looks like a label switch. For the rest of this doc, "switch" (or label switch) means either a physical non-partitioned switch or a partition. The resources of a partition look like the real physical resources of that partition, so if a port's bandwidth gets divided up, each partition sees its own independent port 🦋
GSMP controls a partitioned switch with a partition identifier that rides along in every GSMP message. Each partition has a one-to-one control relationship with its own logical controller (we just call it a controller from here on), and GSMP keeps adjacency going separately for each controller-partition pair 💜
Label switches include frame or cell switches that do connection-oriented switching. They use exact match-forwarding based on labels attached to incoming cells or frames 🌈 A switch has multiple "ports", and each port is one "input port" plus one "output port". Some requests are about the whole port, while others are specific to the input port or the output port. Cells or labelled frames come in from an external link on incoming labelled channels at an input port, and they leave over labelled channels from an output port 🍓
A switch can support multiple label types, but each port can only handle one label type. The switch tells the controller which label type a port uses in a port configuration message. Connections can go between ports that use different label types. The label types are ATM, Frame Relay, MPLS Generic and FEC Labels ✨
A connection across a switch is made by hooking an incoming labelled channel up to one or more outgoing labelled channels. Connections are identified by the input port they start on and the Label values of their incoming labelled channel 🎀
GSMP supports point-to-point and point-to-multipoint connections. A multipoint-to-point connection is made by setting up several point-to-point connections that all name the same output branch. A multipoint-to-multipoint connection is made by setting up several point-to-multipoint trees that all name the same output branches 🧚
Connections usually get a certain quality of service (QoS). This version includes a default QoS Configuration, and it also lets you negotiate alternative, optional QoS configurations 💅 The default QoS Configuration has three QoS Models: a Service Model, a Simple Abstract Model (strict priorities) and a QoS Profile Model 👑
The Service Model is built on service definitions that live outside GSMP, like Integrated Services or ATM Service Categories. Every connection gets a specific service that decides how the switch handles it. Depending on that service, traffic parameters and traffic controls can also be assigned to the connection 🦋
In the Simple Abstract Model, a connection gets a priority when it's established. For connections sharing the same output port, a cell or frame on a higher-priority connection is much more likely to leave the switch before one on a lower-priority connection, as long as they're both in the switch at the same time. The number of priorities each port supports can be read from the port configuration message 🔥
The QoS Profile Model is a simple mechanism for giving a connection QoS semantics that are defined outside GSMP. It can point at pre-defined Differentiated Service Per Hop Behaviours (PHBs). Defining QoS profiles is out of scope for this spec 🌸
All GSMP switches MUST support the default QoS Configuration. A GSMP switch can also support one or more alternative QoS Configurations, and those models are defined outside the GSMP spec. GSMP has a negotiation mechanism so a controller can pick from the QoS configurations a switch supports 🫶
GSMP also has an adjacency protocol. It's used to sync states across the link, negotiate which version of GSMP to use, figure out who is on the other end of the link, and notice when that changes 🙈
2. GSMP Packet Encapsulation
GSMP packets can travel over any suitable medium 💖 Encapsulations for ATM, Ethernet and TCP are specified in [15]. Extra encapsulations for GSMP packets may be defined in separate documents ✨
3. Common Definitions and Procedures
GSMP is a master-slave protocol, and the controller sends request messages to the switch 👑 Each request says whether the switch needs to respond, and it carries a transaction identifier so the response can be matched back to the request. The switch replies with a response message that's either a success or a failure 💅 There are six classes of GSMP request-response message: Connection Management, Reservation Management, Port Management, State and Statistics, Configuration, and Quality of Service 🎀 The switch can also send asynchronous Event messages to tell the controller about async events. The controller can be required to acknowledge event messages, but by default it doesn't 🙈 There's also an adjacency protocol message that sets up synchronisation across the link and keeps a handshake going 🫶
Each message type has a format for the request and a format for the success response. Unless specified otherwise, a failure response is identical to the request that caused the failure, and its Code field tells you what went wrong 😭
Switch ports are described by a 32-bit port number. The switch assigns the port numbers, and it can split those 32 bits into opaque sub-fields that match its physical layout (like slot and port) 🧚 In general, a port in the same physical spot on the switch always keeps the same port number, even across power cycles 🌈 The internal structure of the port number is opaque to the GSMP protocol. But for network management stuff like logging, port naming and graphical representation, a switch can declare the physical location (physical slot and port) of each port. The location info can also come from looking up the product identity in a database 🍓
Each switch port also keeps a port session number that the switch assigns. A message with an incorrect port session number MUST be rejected. This is how the controller can spot a link failure and keep states synchronised 💜
Except for the adjacency protocol message, no GSMP messages can be sent across the link until the adjacency protocol has achieved synchronisation. All GSMP messages received on a link that do not currently have state synchronisation MUST be discarded. 🔥
3.1. GSMP Packet Format ✨
3.1.1. Basic GSMP Message format ✨
okay so bestie, this part is where GSMP actually gets its shape 🎀 every GSMP message uses this same layout, except the adjacency protocol message, which gets to skip the party 🙈 check out the bit layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Message Body ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Quick numbers and bit-order check, because this is where people get messy 🧚 The doc uses decimal by default, "0x" for hex, and "0b" for binary 🍓 Data is pictured big-endian, so fields read left to right with the most significant byte on the left. Bytes get sent in the order you'd read them in English, and within a byte the leftmost bit is the high-order bit (the one labelled 0). Multi-byte fields follow the same rule, and the most significant byte goes out first. Same coding convention as the ATM layer [1] and AAL-5 [2][3] 💜
Version 🌸 The GSMP protocol version in use for this session. The sender SHOULD set it to the version the adjacency protocol negotiated 🫶
Message Type 🦋 Tells you what kind of message it is. The classes are Connection Management, Reservation Management, Port Management, State and Statistics, Configuration, Quality of Service, Events, and messages belonging to an Abstract or Resource Model (ARM) extension. Each class has a bunch of message types inside it 💅 And one Message Type is reserved for the adjacency protocol, obviously 👑
Result ✨ This one is mostly a vibe-check on whether a reply is needed. It shows up in Connection Management requests, Port Management requests, and Quality of Service requests. The value NoSuccessAck means "don't bother replying if it worked," and AckAll means "yes, reply even if it worked." Either way, a failure response MUST be generated if the request fails 🔥 For State and Statistics requests and Configuration requests, a NoSuccessAck gets ignored and the message gets treated as if it said AckAll 🙈 This exists to cut down on control traffic when the controller periodically checks that the switch state is still correct. If the controller doesn't use that trick, all request messages SHOULD be sent with AckAll 💖
In a response, Result can be Success, More, or Failure. Success and More are both success responses, and every message in the same success response shares the same Transaction Identifier 🎀 Success means the response fits in one message or it's the final piece of a multi-message response. More means the message (request or response) is bigger than the data link's MTU, so more messages are coming to finish the response 🧚
Events are a special case 👀 ReturnReceipt is what a switch puts in an Event message's Result field when it needs an acknowledgement. The default is that the controller does NOT acknowledge Events, so only switches that want a receipt will set it 🦋
The encoding is:
NoSuccessAck: Result = 1
AckAll: Result = 2
Success: Result = 3
Failure: Result = 4
More: Result = 5
ReturnReceipt Result = 6And the Result field is not used at all in an adjacency protocol message 🙅♀️
Code 💀 Gives extra detail about the result in a response. It's mostly how failure responses pass along an error code, but it can also add info to a success response or an event message. In a request, Code is unused and set to zero. In an adjacency protocol message, Code is what tells you the message's function 🌈
Partition ID 🍓 Ties the command to a specific switch partition. GSMP doesn't define the format, so if you want, you can split it into sub-identifiers inside a partition. Example: a 6-bit partition number plus a 2-bit sub-identifier would let a switch support 64 partitions with 4 IDs each 🫶
Transaction Identifier 🌸 This is how a response finds its request 💅 Controllers can pick any transaction identifier for a request. A response copies the identifier from the request it's answering. Event messages SHOULD set it to zero. And it's not used at all in the adjacency protocol, so the field isn't even there 😭
I flag 🔥 If I is set, the SubMessage Number field holds the total count of segments that make up the whole message. If I is not set, SubMessage Number is the sequence number of this particular segment 🧚
SubMessage Number 💜 When a message is too big for the link layer MTU and gets chopped up, each piece carries its position in SubMessage Number. Alternatively, the first submessage in a sequence has the I flag set, and this field holds the total number of segments instead ✨
Length 🎀 The length of the whole GSMP message, headers and body included. If extra data gets tacked onto the end of the standard message, its length SHOULD be counted in Length too 🙌
3.1.2. Fields commonly found in GSMP messages 🌈
these fields show up all over the place, so they're defined once here to save everyone from repeating themselves 💖
Port 🦋 The port number of the switch port the message is about 🌸
Port Session Number 💅 Every switch port keeps a Port Session Number that the switch assigns. It stays the same as long as the port stays continuously in the Available state and the link status stays continuously Up 🫶 But if the port comes back to Available after being Unavailable or in any Loopback state, or the line status comes back Up after being Down or in Test, or the switch gets power cycled, a NEW Port Session Number MUST be generated 😭 New numbers SHOULD come from some kind of random number generator 🎲
If a request's Port Session Number doesn't match the port's current one, a failure response MUST be returned with Code set to "5: Invalid port session number" 🔥 You can grab the current port session number with a Port Configuration message or an All Ports Configuration message 💜
3.1.2.1. Additional General Message Information 👑
- Any field that's unused or marked "reserved" MUST be set to zero by the sender and ignored by the receiver 🙈
- Undefined flags get marked as:
x: reserved🎀 - It's not an error to have additional data after the end of the Message Body. It's allowed so people can do proprietary and experimental stuff 🧚 BUT the maximum transmission unit from the data link layer encapsulation MUST NOT be exceeded 🚫 And the length of any appended data SHOULD be counted in the message length field 💖
- A success response MUST NOT be sent until the requested operation has actually finished successfully 🫶 no premature celebrating, bestie 🥹✨
3.1.3. Labels ✨
okay so every label in GSMP is basically a TLV (Type, Length, Value) 🎀. that's a super cute way to pack info into something flexible and extensible, and honestly it's giving organized. a label TLV is a 2 octet field where 12 bits are the Type and 4 bits are for certain behaviours we'll get into below 💅. then comes a 2 octet Length field, then a variable length Value field. and bestie, a label field can be made of lots of stacked labels that work together as one label 🥞.
here's the lineup of TLV labels this version of the protocol supports 🦋:
TLV Label Type Section Title
--------- ---- -------------
ATM Label 0x100 ATM TLV Labels
FR Label 0x101 Frame Relay TLV Labels
MPLS Gen Label 0x102 MPLS Generic TLV Labels
FEC Label 0x103 FEC TLV Labelsevery label has this layout 🌸:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| Label Type | Label Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Label Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+and here's what each bit of it means:
- x: Reserved Flags 🙈. these are usually used by specific messages, and those messages define them.
- S: Stacked Label Indicator 🥞. label stacking gets its own section, which is 3.1.3.5.
- Label Type: a 12-bit field that says what kind of label this is.
- Label Length: a 16-bit field that gives the length of the Label Value field in bytes.
- Label Value: a variable length field that's always an integer number of 32 bit words long. it gets read according to the Label Type, as the next sections explain 🧚.
3.1.3.1. ATM Labels 🦋
if the Label Type is ATM Label, the labels MUST be read as ATM labels, like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| ATM Label (0x100) | Label Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x| VPI | VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+okay so for a virtual path connection (switched as a single virtual path connection), or a virtual path (switched as one or more virtual channel connections inside the virtual path), the VCI field isn't used 🙅♀️.
ATM tells virtual path connections and virtual channel connections apart, and the connection management messages work with both 💜. the Add Branch and Move Branch messages come with two Message Types: one says "I need a virtual channel connection" and the other says "I need a virtual path connection" 🎀. the Delete Branches, Delete Tree, and Delete All messages only have one Message Type, because they don't need to care which kind it is ✨.
for virtual path connections, neither the Input VCI fields nor the Output VCI fields are needed. they SHOULD be set to zero by the sender and ignored by the receiver 🫶. also, virtual channel branches can't be added to an existing virtual path connection, and virtual path branches can't be added to an existing virtual channel connection. no mixing, bestie 🚫. last thing: in the Port Configuration message, each switch input port can say whether it can handle virtual path switching (in other words, accepting connection management messages that ask for virtual path connections) 👑.
3.1.3.2. Frame Relay Labels 🌈
if the TLV Type is FR Label, the labels MUST be read as Frame Relay labels, like so:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| FR Label (0x101) | Label Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x| Res |Len| DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Res: this field is reserved in [21], which means GSMP doesn't reserve it explicitly 🤷♀️.
- Len: this one tells you how many bits the DLCI has. the supported values are:
Len DLCI bits
0 10
2 23- DLCI: this is the binary value of the Frame Relay Label 💖. the significant bits (10 or 23 of them, depending on the label value) get encoded into the Data Link Connection Identifier (DLCI) field when they're part of the Frame Relay data link header [13] 🍓.
3.1.3.3. MPLS Generic Labels 💜
if a port's attribute PortType is MPLS, then that port's labels are for links where the label values don't depend on the underlying link technology. examples of these links are PPP and Ethernet 🌸. on those links, the labels get carried in MPLS label stacks [14] ✨. if the Label Type is MPLS Generic Label, the labels MUST be read as Generic MPLS labels, like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| MPLS Gen Label (0x102)| Label Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x x x x x| MPLS Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- MPLS Label: this is a 20-bit label value as specified in [14], shown as a 20-bit number inside a 4-byte field 🧁.
3.1.3.4. FEC Labels 🧚
labels can be bound to Forwarding Equivalence Classes (FECs) as defined in [18] 🦋. a FEC is a list of one or more FEC elements, and the FEC TLV is what encodes those FEC items. in this version of the protocol only, Prefix FECs are supported. if the Label Type is FEC Label, the labels MUST be read as Forwarding Equivalence Class Labels, like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| FEC Label (0x103) | Label Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ FEC Element 1 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ FEC Element n ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- FEC Element: how the FEC element is encoded depends on its type. in this version of GSMP, only Prefix FECs are supported 💅. the layout is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Element Type | Address Family | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Prefix ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Element Type: in this version the only supported Element Type is Prefix FEC Elements 🎀. a Prefix FEC Element is a one-octet value, encoded as
0x02. - Address Family: a two-byte quantity holding a value from ADDRESS FAMILY NUMBERS in [5], which encodes the address family for the address prefix in the Prefix field ✨.
- Prefix Length: one byte holding the length in bits of the address prefix that follows. a length of zero means a prefix that matches all addresses (the default destination), and in that case the Prefix itself is zero bytes long 🌈.
- Prefix: an address prefix encoded according to the Address Family field, with its length in bits given by the Prefix Length field 💖.
3.1.3.5. Label Stacking 🥞
label stacking is a technique used in MPLS [14] that allows hierarchical labelling 🪜. MPLS label stacking is similar to the VPI/VCI hierarchy of labels in ATM, but it's subtly different 👀. there's no set limit on how deep label stacks can go in GSMP 🫶.
when the Stacked Label Indicator S is set to 1, it means an additional label field gets appended to the label field next to it. for example, a stacked Input Short Label could look like this:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ Input Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
** |x|S|x|x| |
+-+-+-+-+ Stacked Input Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+** Note: There can be zero or more Stacked Labels fields (like those marked **) following an Input or Output Label field. A Stacked Label follows the previous label field if and only if the S Flag in the previous label is set.
when a label gets extended by stacking, the protocol treats it as one single extended label, and every operation on that label is atomic 💅. so in an add branch message, the entire input label gets switched for the entire output label. likewise, in Move Input Branch and Move Output Branch messages, the entire label gets swapped 🔁. that's why, in every message that has a label field, it's drawn as a single 64-bit field, even though in practice it might be made of lots of 64-bit fields 🧚.
3.1.4. Failure Response Messages ✨
Okay so, when the switch can't do what you asked, it sends back a failure response 💀. You basically take the request that caused the problem, flip the Result field to 4 for failure, and put a reason in the Code field. That code tells the controller exactly why the switch said no 🙈.
If the switch sends a failure response, the state of the switch should not change because of the message that broke things 🛑. (Multi-request messages like Delete Branches are the exception. The failure response will list which requests worked and which didn't, so the ones that worked can change the state. Iconic 💅.)
Warnings are their own vibe. A warning response is a success response (Result = 3), and its Code field tells you which warning popped up during an operation that still went through 🦋.
When the switch sends a failure, it MUST pick the most specific failure code, using this precedence order 👑:
- Invalid Message
- General Message Failure
- Specific Message Failure A failure response specified in the text defining the message type.
- Connection Failures
- Virtual Path Connection Failures
- Multicast Failures
- QoS Failures
- General Failures
- Warnings
If more than one failure fits inside a category, the one listed first should be returned. You can find descriptions of all the failure responses in section 12 📚.
4. Connection Management Messages 🎀
4.1. General Message Definitions 🌸
Connection management messages are how the controller makes, deletes, changes and checks connections across the switch 🧚. The Add Branch, Delete Tree and Delete All messages all look like this, for both requests and responses:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reservation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Service Selector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Service Selector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IQS|OQS|P|x|N|O| Adaptation Method |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ Input Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ Output Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+When needed, the Add Branch, Move Input Branch and Move Output Branch messages get an extra, variable-length data block tacked onto the end 🧩. This happens when the IQS and OQS flags say so (if either one is set to 0b10), along with the service selector. The extra block looks like this:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input TC Flags|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Traffic Parameters Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Output TC Flags|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Traffic Parameters Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Quick note: fields and parameters already explained in the general messages won't be repeated here, so check section 3.1 for those 📝.
Reservation ID 🎟️ This identifies the reservation that MUST be deployed for the branch being added. Reservations are set up with reservation management messages (see Chapter 5). A value of 0 means no reservation is being deployed for the branch. If a reservation with a matching Reservation ID exists, the reserved resources MUST be applied to the branch. If the numerical value of Reservation ID is bigger than the value of Max Reservations (from the Switch Configuration message), a failure response is returned saying 20: Reservation ID out of Range. If the value of Input Port doesn't match the input port in the reservation, or if the value of Output Port doesn't match the output port in the reservation, a failure response MUST be returned saying 21: Mismatched reservation ports. If no reservation matching Reservation ID exists, a failure response MUST be returned saying 23: Non-existent reservation ID 😤.
If you give a valid Reservation ID and the Service Model is used (that's IQS or OQS = 0b10), the Traffic Parameters Block may be left out of the Add Branch message. That tells the switch to use the Traffic Parameters from the matching Reservation Request message 🧠.
Input Port 🚪 This identifies a switch input port.
Input Label 🏷️ This identifies an incoming labelled channel arriving at the switch input port named in the Input Port field. The value in the Input Label field MUST be interpreted according to the Label Type attribute of the switch input port named in the Input Port field 🔍.
Input Service Selector 💖 This identifies the details of the service specification being used for the connection. What it means depends on the Input QoS Model Selector (IQS) 👀.
IQS = 00: Here the Input Service Selector means a simple priority.IQS = 01: Here the Input Service Selector is an opaque service profile identifier. How these service profiles are defined is outside the scope of this specification. Service Profiles can be used to point at pre-defined Differentiated Service Per Hop Behaviours.IQS = 10: Here the Input Service Selector corresponds to a Service Spec as defined in Chapter 8.2. When either IQS or OQS is set to 0b10, a Traffic Parameters Block is added to the message.IQS = 11: Here the Input Service Selector corresponds to an ARM service specification. Defining ARM service specifications is outside the scope of this specification, and the MType decides it as defined in Chapter 8.1.
Output Port 🚀 This identifies a switch output port.
Output Label 🎯 This identifies an outgoing labelled channel leaving at the switch output port named in the Output Port field. The value in the Output Label field MUST be interpreted according to the Label Type attribute of the switch input port indicated by the Output Port field
Output Service Selector 💫 This identifies the details of the service model being used. What it means depends on the Output QoS Model Selector (OQS) 🌈.
OQS = 00: Here the Output Service Selector means a simple priority.OQS = 01: Here the Output Service Selector is an opaque service profile identifier. How these service profiles are defined is outside the scope of this specification. Service Profiles can be used to point at pre-defined Differentiated Service Per Hop Behaviours.OQS = 10: Here the Output Service Selector corresponds to a Service Spec as defined in Chapter 8.2. When either IQS or OQS is set to 0b10 then a Traffic Parameters Block is added to the message.OQS = 11: Here the Output Service Selector corresponds to an ARM service specification. Defining ARM service specifications is outside the scope of this specification, and the MType decides it as defined in Chapter 8.1.
IQS, OQS 🔑 Input and Output QoS Model Selector: the QoS Model Selector is how you pick a QoS Model for the connection. The IQS and OQS values decide how the Input Service Selector and Output Service Selector get read, and they SHOULD be read as a priority, a QoS profile, a service specification, or an ARM specification, like this 💅:
IQS/OQS QoS Model Service Selector
------- --------- ----------------
00 Simple Abstract Model Priority
01 QoS Profile Model QoS Profile
10 Default Service Model Service Specification
11 Optional ARM ARM SpecificationP Flag 🧁 If the Parameter flag is set, it means a single instance of the Traffic Parameter block is included. This happens when the Input Traffic Parameters are the same as the Output Traffic Parameters 🙌.
N Flag 🌙 The Null flag is used to indicate a null adaptation method. This happens when the branch connects two ports of the same type 🫶.
O Flag 🔮 The Opaque flag says whether the adaptation fields are opaque, or whether the protocol defines them. Check the definition of Adaptation Method below for more info 🦋.
Adaptation Method 🦋 okay so this one tells you which adaptation framing to use when traffic hops from one port type to another, like frame relay to ATM. The content is defined by the Opaque flag. If Opaque is set, the switch manufacturer defines the field and this protocol doesn't. If Opaque is not set, the field splits into two 12-bit fields:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IQS|OQS|P|x|N|O| Input Adaptation | Output Adaptation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Input Adaptation 💅 the adaptation framing method used on incoming connections.
Output Adaptation 💅 the adaptation framing method used on outgoing connections.
Adaptation Types 🌸 these are the values:
0x100 PPP
0x200 FRF.5
0x201 FRF.8Input and Output TC Flags 🎀 TC (Traffic Control) Flags show up in Add Branch, Move Input Branch and Move Output Branch messages for connections using the Service Model (so when IQS or OQS=0b10). The TC Flags field is defined in Section 10.6.
Input and Output Traffic Parameters Block ✨ this variable-length field also shows up in Add Branch, Move Input Branch and Move Output Branch messages for Service Model connections (again, when IQS or OQS=0b10). The Traffic Parameters Block is defined in Section 10.5. It may be omitted if a valid, non-zero Reservation ID is specified, in which case the Traffic Parameters of the corresponding Reservation Request message get used instead. If the P flag is set, the appended message block only includes a single traffic parameter block, and that one is used for both input and output traffic. 🧚
For all connection management messages except the Delete Branches message, the success response is a copy of the request with the Result field saying success. The Code field isn't used in a connection management success response. 🫶
The failure response is a copy of the request with a Result field saying failure. 💀
Here's the big tea 🍓: there's no real difference between point-to-point and point-to-multipoint connections. By default, the first Add Branch message for a given Input Port and Input Label makes a point-to-point connection. The second Add Branch message with the same Input Port and Input Label fields converts it into a point-to-multipoint connection with two branches. But to avoid possible inefficiency with some switch designs, there's the Multicast Flag. If the controller already knows a new connection is point-to-multipoint when it sets up the first branch, it can say so in the Multicast Flag. Later Add Branch messages with the same Input Port and Input Label fields add more branches to that point-to-multipoint connection. 👑
Using the Delete Branch message on a point-to-multipoint connection with two branches gives you a point-to-point connection. The switch can still structure it as a point-to-multipoint connection with a single output branch if it wants to, which can be more convenient for some switch designs. Using Delete Branch on a point-to-point connection deletes the whole thing, because there's no concept of a connection with zero output branches. All connections are unidirectional: one input labelled channel to one or more output labelled channels. 🌈
For a multipoint-to-point connection in GSMP, you set up several point-to-point connections that all specify the same output branch. An output branch is an output port plus an output label. ⭐
Connection management messages can go out no matter what the switch port's Port Status is. Connections can be set up or deleted while a switch port is Available, Unavailable, or in any of the Loopback states. But all connection states on an input port get deleted when the port returns to Available from any other state. That happens when a Port Management message arrives for that port with the Function field set to either Bring Up or Reset Input Port. 🔥
4.2 Add Branch Message
The Add Branch message is a connection management message that establishes a connection or adds another branch to an existing one. It can also be used to check the connection state stored in the switch. The connection is specified by the Input Port and Input Label fields. The output branch is specified by the Output Port and Output Label fields. The quality of service requirements are specified by the QoS Model Selector and Service Selector fields. To request a connection, the Add Branch message looks like this: 🎀
Message Type = 16
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reservation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Service Selector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Service Selector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IQS|OQS|P|x|N|O| Adaptation Method |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|M|B| |
+-+-+-+-+ Input Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|M|R| |
+-+-+-+-+ Output Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+When IQS or OQS is set to 0b10, the following Traffic Parameters Block gets appended to the message above: 🧁
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Input TC Flags |x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Input Traffic Parameters Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Output TC Flags|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Output Traffic Parameters Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Note: Fields and Parameters already explained in the description of the general connection message won't be explained again in this section. Please refer to section 4.1 for details. 📚
M: Multicast 💜 the Multicast flags are hints for point-to-multipoint or multipoint-to-point connections in the Add Branch message. They aren't used in any other connection management messages, and in those messages they SHOULD be set to zero. The Add Branch message has two M-bits: one for the input branch (given by the Input Port and Input Label fields) and one for the output branch (given by the Output Port and Output Label fields). If the M bit is set in front of the Input Label field, it means the connection is very likely to be point-to-multipoint. If it's zero, the connection is very likely point-to-point or the situation is unknown. If the M bit is set in front of the Output Label field, it means the connection is very likely multipoint-to-point. If it's zero, the connection is very likely point-to-point or unknown. 🦋
If M is set for both the input and output branches, the connection is very likely multipoint-to-multipoint. 🌸
The Multicast flags only get used in an Add Branch message when setting up the first branch of a new connection. They don't have to be set when establishing later branches of a point-to-multipoint or multipoint-to-point connection, and on those connections the receiver SHOULD ignore them. (The exception is when the connection replace bit is enabled and set. Then the receiver receiving the second and later Add Branch messages means it's a point-to-multipoint or multipoint-to-point connection.) If you know this is the first branch of a point-to-multipoint or multipoint-to-point connection, this flag SHOULD be set. If it's unknown, or you know the connection is point-to-point, this flag SHOULD be zero. Using the multicast flag isn't mandatory, and the switch can ignore it. If it's unused, the flags SHOULD be set to zero. 💅
Some switches use a different data structure for multicast connections than for point-to-point ones. These flags stop the switch from setting up a point-to-point structure for the first branch of a multicast connection, which MUST immediately be deleted and reconfigured as point-to-multipoint or multipoint-to-point when the second branch is established. That's a lot of wasted work avoided, bestie! 🙈✨
The Bi-directional flag is only for Add Branch messages, bestie 🦋 In every other Connection Management message it's not used at all. It can only be used when you're setting up a point-to-point connection 🎀 When it's set in an Add Branch message, it asks for two one-way connections: one going forward and one going in reverse 💅 It's basically the same as sending two Add Branch messages, one for each direction ✨ The forward direction uses the Input Port, Input Label, Output Port and Output Label values from the Add Branch message as they are. The reverse direction is worked out by swapping the Input Port and Input Label values with the Output Port and Output Label values. So the reverse connection starts at the input port named by the Output Port field, on the label named by the Output Label field, and leaves from the output port named by the Input Port field, on the label named by the Input Label field 🌸
The Bi-directional flag is really just a shortcut 🫶 It sets up two one-way connections going opposite ways between the same two ports, using the same Labels, all in one Add Branch message. After that, the two connections MUST be handled separately in all future messages 😭 There's no bi-directional delete message, so you can't do it in one go. You can use a single Delete Branches message with two Delete Branch Elements, one for the forward connection and one for the reverse, though 🧚
R: Connection Replace 🔥 The Connection Replace flag only applies to the Add Branch message and isn't used in any other Connection Management message. It's for situations where making multipoint-to-point connections isn't wanted (for example, POTS applications where fan-in makes no sense) 🙈 If the R flag is set, the new connection replaces any existing connection if the label is already in use at the same Output Port 👑
The Connection Replace mechanism lets one Add Connection command act as either a Move Branch message or a combo of a Delete Branch message and an Add Branch message 💅 It's there to support existing 64k call handling applications, like emulating 64k voice switches ✨
Using the R flag is optional, and it MUST be pre-configured in the Port Management message [see section 6.1] before it can be used 💖 The R flag MUST NOT be set if it isn't pre-configured with the Port Management message. In that case the switch MUST return a Failure Response message: 36: Replace of connection is not activated on switch. You can find out whether the function is active by using the Port Configuration message [see section 8.2] 🦋
The R flag MUST NOT be set if either the M flag or the B flag is set 🙅♀️ If a switch gets an Add connection request with the R flag set along with the B or M flag, it MUST return a failure response message of: 37: Connection replacement mode cannot be combined with Bi-directional or Multicast mode 💀
If the connection named by the Input Port and Input Label fields doesn't already exist, it MUST be set up with the single output branch in the request message. If the Bi-directional Flag in the Flags field is set, the reverse connection MUST also be set up 🌈 The output branch SHOULD have the QoS attributes given in the Class of Service field ⭐
If the connection named by the Input Port and Input Label fields already exists, the R flag is not set, but the specified output branch doesn't exist yet, the new output branch MUST be added. The new output branch SHOULD have the QoS attributes in the Class of Service field 🎀
If the connection named by the Input Port and Input Label fields already exists and the specified output branch also already exists, the connection's QoS attributes (from the Class of Service field) SHOULD be changed to match the request message, if they're different 💜 A success response message MUST be sent if the Result field of the request message is "AckAll" 🫶 This lets the controller periodically reassert a connection's state or change its priority ✨ If the Result field of the request message is "NoSuccessAck", a success response message SHOULD NOT be returned. That's useful for cutting down traffic on the control link when messages are just reasserting a state that's already been set up 🌸 For messages that reassert a previously established state, the switch MUST always check that the state is correctly established in the switch hardware (that is, the actual connection tables used to forward cells or frames) 👑
If the connection named by the Input Port and Input Label fields already exists, and the Bi-directional Flag in the Flags field is set, a failure response MUST be returned saying: 15: Point-to-point bi-directional connection already exists 😭
Different switches support multicast in different ways, so keep that in mind 🧚 Some switches limit the total number of point-to-multipoint or multipoint-to-point connections they can support, and there may also be a limit on how many branches one of those connections can have. Some switches also limit how many different Label values can be assigned to the output branches of a point-to-multipoint connection. Lots of switches can only handle a single branch of any particular point-to-multipoint connection on the same output port 💅 Specific failure codes are defined for some of these conditions ✨
4.2.1 ATM specific procedures 🦋
To request an ATM virtual path connection, the ATM Virtual Path Connection (VPC) Add Branch message is:
Message Type = 26An ATM virtual path connection can only be set up between ATM ports, meaning ports with the "ATM" Label Type attribute 💖 If an ATM VPC Add Branch message is received and either the switch input port named by the Input Port field or the switch output port named by the Output Port field is not an ATM port, a failure response message MUST be returned saying 28: ATM Virtual path switching is not supported on non-ATM ports 🙈
If an ATM VPC Add Branch message is received and the switch input port named by the Input Port field doesn't support virtual path switching, a failure response message MUST be returned saying 24: ATM virtual path switching is not supported on this input port 🌸
If an ATM virtual path connection already exists on the virtual path named by the Input Port and Input VPI fields, a failure response message MUST be returned saying 27: Attempt to add an ATM virtual channel connection branch to an existing virtual path connection 👑 For the VPC Add Branch message, if a virtual channel connection already exists on any of the virtual channels inside the virtual path named by the Input Port and Input VPI fields, a failure response message MUST be returned saying 26: Attempt to add an ATM virtual path connection branch to an existing virtual channel connection 💀
4.3 Delete Tree Message 🎀
The Delete Tree message is a Connection Management message used to delete an entire connection 🫶 All remaining branches of the connection get deleted. A connection is defined by the Input Port and Input Label fields. The Output Port and Output Label fields aren't used in this message. The Delete Tree message is:
Message Type = 18If the Result field of the request message is "AckAll", a success response message MUST be sent once the specified connection has been deleted. The success message MUST NOT be sent until the delete operation is complete and, if possible, not until all data queued for transmission on the connection has been sent 🌈
4.4 Verify Tree Message 🥀
The Verify Tree message has been removed from this version of GSMP 😭
Message Type = 19If a request message arrives with Message Type = 19, a failure response MUST be returned with the Code field indicating: 3: The specified request is not implemented on this switch. 🙈
4.5 Delete All Input Port Message 🧚
The Delete All Input Port message is a Connection Management message used to delete all connections on a switch input port 💅 All connections that start at the specified input port MUST be deleted. When the operation finishes, all dynamically assigned Label values for that port MUST be unassigned. In other words, there MUST be no connections in the Label space that GSMP controls on this port ✨ The Service Selectors, Output Port, Input Label and Output Label fields aren't used in this message. The Delete All Input Port message is:
Message Type = 20If the Result field of the request message is "AckAll", a success response message MUST be sent when the operation completes. The success response message MUST NOT be sent until the operation has actually been completed 🦋
The following failure response messages may be returned to a Delete All Input Port request:
3: The specified request is not implemented on this switch.
4: One or more of the specified ports does not exist.
5: Invalid Port Session Number.If any field in a Delete All Input Port message isn't covered by the failure codes above and is invalid, a failure response MUST be returned saying: 2: Invalid request message. Otherwise, the Delete All Input Port operation MUST be completed successfully and a success message returned. No other failure messages are permitted 💖
4.6 Delete All Output Port Message 🌸
The Delete All message is a Connection Management message used to delete all connections on a switch output port 👑 All connections that have the specified output port MUST be deleted. When the operation finishes, all dynamically assigned Label values for that port MUST be unassigned, meaning there MUST be no connections in the Label space that GSMP controls on this port 🫶 The Service Selectors, Input Port, Input Label and Output Label fields aren't used in this message. The Delete All Output Port message is:
Message Type = 21If the Result field of the request message is "AckAll", a success response message MUST be sent when the operation completes. The success response message MUST NOT be sent until the operation has been completed 💜
The following failure response messages may be returned to a Delete All Output Port request:
3: The specified request is not implemented on this switch.
4: One or more of the specified ports does not exist.
5: Invalid Port Session Number.If any field in a Delete All Output Port message isn't covered by the failure codes above and is invalid, a failure response MUST be returned saying: 2: Invalid request message. Otherwise, the delete all operation MUST be completed successfully and a success message returned. No other failure messages are permitted 🎀
4.7. Delete Branches Message 🫧
okay so the Delete Branches message is the connection management message you send when you want to ask for one or more delete branch operations 💅 each one removes a branch of a channel, and if it's the last branch of a connection, the whole connection goes poof 💀 its message type is:
Message Type = 17
the request message looks like this 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x| Number of Elements |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Delete Branch Elements ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+🫶 Note: Fields and Parameters that have been explained in the description of the general connection message will not be explained in this section. Please refer to section 4.1 for details.
Number of Elements 🔢 this one tells you how many Delete Branch Elements are coming along for the ride. The number of Delete Branch Elements in a Delete Branches message MUST NOT cause the packet length to exceed the maximum transmission unit defined by the encapsulation. no oversized packets, bestie 🙅♀️
each Delete Branch Element describes one branch to delete, and it's shaped like this ✨
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error |x|x|x|x|x|x|x|x|x|x|x|x| Element Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ Input Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ Output Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+🫶 Note: Fields and Parameters that have been explained in the description of the general connection message will not be explained in this section. Please refer to section 4.1 for details.
Error 🚨 this is where the failure code lives, for a specific Delete Branch Element inside a Delete Branches failure response message. The Error field is not used in the request message and MUST be set to zero. a value of zero means the delete operation for that element worked 🎉 values for the other failure codes are specified in Section 12, "Failure Response Codes".
all the other fields of the Delete Branch Element mean the same thing they do in the other connection management messages 💖
so here's the deal 🧠 in each Delete Branch Element, the connection is identified by the Input Port and Input Label fields. the specific branch you want gone is identified by the Output Port and Output Label fields. easy peasy 🍓
if the Result field of the Delete Branches request message is "AckAll", a success response message MUST be sent once all of the branches named by the Delete Branch Elements have been deleted successfully. the success response message MUST NOT be sent until all of the delete branch operations are completed. it only gets sent if every single requested delete operation worked 🥹 no Delete Branch Elements come back in a success response, and the Number of Elements field MUST be set to zero.
if anything fails in any of the Delete Branch Elements, a Delete Branches failure response message MUST be returned 💔 it's basically a copy of the request, except the Code field for the whole message is set to "10: General Message Failure", and each Delete Branch Element's Error field tells you what happened to that particular delete. and the big one: a failure in one element MUST NOT interfere with the processing of any of the other Delete Branch Elements. one bad apple does not spoil the bunch 🍎✨
4.8. Move Output Branch Message 🦋
the Move Output Branch message lets you move a branch of an existing connection from its current output port label to a shiny new output port label, all in one single atomic transaction 💜 no half-done nonsense. the Move Output Branch connection management message uses this exact format for both the request and the response messages:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Service Selector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Service Selector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IQS|OQS|P|x|N|O| Adaptation Method |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ Input Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ Old Output Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ New Output Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+when IQS or OQS is set to 0b10, the following Traffic Parameters Block gets tacked onto the end of the message 🧁
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Input TC Flags |x x x x x x x x x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Input Traffic Parameters Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Output TC Flags|x x x x x x x x x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Output Traffic Parameters Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+🫶 Note: Fields and Parameters that have been explained in the description of the general connection message will not be explained in this section. Please refer to section 4.1 for details.
the Move Output Branch message is a connection management message that moves a single output branch of a connection, from its current output port and Output Label to a new output port and Output Label on that same connection 🌈 none of the connection's other output branches get touched. once the operation is complete, the original Output Label on the original output port gets deleted from the connection 🫧
the message type is:
Message Type = 22
now for the logic 🧠 for the Move Output Branch message, if the connection named by the Input Port and Input Label fields already exists, and the output branch named by the Old Output Port and Old Output Label fields exists as a branch on that connection, then the output branch named by the New Output Port and New Output Label fields gets added to the connection, and the branch named by the Old Output Port and Old Output Label fields gets deleted. if the Result field of the request message is "AckAll", a success response message MUST be sent once the operation completes successfully. the success response message MUST NOT be sent until the Move Branch operation has been completed. 🎀
and the sad path 😭 for the Move Output Branch message, if the connection named by the Input Port and Input Label fields already exists, but the output branch named by the Old Output Port and Old Output Label fields does not exist as a branch on that connection, a failure response MUST be returned with the Code field indicating "12: The specified branch does not exist". 🥀
4.8.1 ATM Specific Procedures: 🦋
okay bestie, so the ATM VPC Move Output Branch message is a connection management message that takes ONE output branch of a virtual path connection and moves it from its current output port and output VPI to a new output port and output VPI on the same virtual channel connection 💖. The other output branches? Totally untouched 🫶. Once everything's done, the original output VPI on the original output port gets deleted from the connection ✨.
The VPC Move Branch message is:
Message Type = 27For the VPC Move Output Branch message, if the virtual path connection specified by the Input Port and Input VPI fields already exists, and the output branch specified by the Old Output Port and Old Output VPI fields exists as a branch on that connection, then the output branch specified by the New Output Port and New Output VPI fields gets added to the connection and the branch specified by the Old Output Port and Old Output VPI fields gets deleted 🔥. If the Result field of the request message is "AckAll", a success response message MUST be sent upon successful completion of the operation. The success response message MUST NOT be sent until the Move Branch operation has been completed 👑.
For the VPC Move Output Branch message, if the virtual path connection specified by the Input Port and Input VPI fields already exists, but the output branch specified by the Old Output Port and Old Output VPI fields does not exist as a branch on that connection, a failure response MUST be returned with the Code field indicating, "12: The specified branch does not exist". 💀
If the virtual channel connection specified by the Input Port and Input Label fields, or the virtual path connection specified by the Input Port and Input VPI fields, does not exist, a failure response MUST be returned with the Code field indicating, "11: The specified connection does not exist". not it being missing 😭
If the output branch specified by the New Output Port, New Output VPI, and New Output VCI fields for a virtual channel connection, or the output branch specified by the New Output Port and New Output VPI fields for a virtual path connection, is already in use by any connection other than the one specified by the Input Port and Input Label fields, then the resulting output branch will have multiple input branches 🦋. If multiple point-to-point connections share the same output branch, the result will be a multipoint-to-point connection. If multiple point-to-multipoint trees share the same output branches, the result will be a multipoint-to-multipoint connection 🌈.
4.9 Move Input Branch Message 🌸
The Move Input Branch message is used to move a branch of an existing connection from its current input port label to a new input port label in a single atomic transaction 🧚. It has the following format for both request and response messages:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Service Selector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Service Selector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IQS|OQS|P|x|N|O| Adaptation Method |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ Output Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ Old Input Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ New Input Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+When the value of either IQS or OQS is set to 0b10, then the following Traffic Parameters Block is appended to the above message:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Input TC Flags |x x x x x x x x x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Input Traffic Parameters Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Output TC Flags|x x x x x x x x x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Output Traffic Parameters Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Note: Fields and Parameters that have been explained in the description of the general connection message will not be explained in this section. Please refer to section 4.1 for details. 📖
The Move Input Branch message is a connection management message used to move a single input branch of a connection from its current input port and Input Label to a new input port and Input Label on the same connection 🎀. None of the connection's other input branches are modified. When the operation is complete, the original Input Label on the original input port will be deleted from the connection 💅.
The Move Input Branch message is:
Message Type = 23For the Move Input Branch message, if the connection specified by the Output Port and Output Label fields already exists, and the input branch specified by the Old Input Port and Old Input Label fields exists as a branch on that connection, then the input branch specified by the New Input Port and New Input Label fields gets added to the connection and the branch specified by the Old Input Port and Old Input Label fields gets deleted ✨. If the Result field of the request message is "AckAll", a success response message MUST be sent upon successful completion of the operation. The success response message MUST NOT be sent until the Move Input Branch operation has been completed 🌸.
For the Move Input Branch message, if the connection specified by the Output Port and Output Label fields already exists, but the input branch specified by the Old Input Port and Old Input Label fields does not exist as a branch on that connection, a failure response MUST be returned with the Code field indicating, "12: The specified branch does not exist". 🙈
4.9.1 ATM Specific Procedures:
The ATM VPC Move Input Branch message is a connection management message used to move a single input branch of a virtual path connection from its current input port and input VPI to a new input port and input VPI on the same virtual channel connection 🦋. None of the other input branches are modified. When the operation is complete, the original input VPI on the original input port will be deleted from the connection 🌈.
The VPC Move Input Branch message is:
Message Type = 28For the VPC Move Input Branch message, if the virtual path connection specified by the Output Port and Output VPI fields already exists, and the input branch specified by the Old Input Port and Old Input VPI fields exists as a branch on that connection, then the input branch specified by the New Input Port and New Input VPI fields gets added to the connection and the branch specified by the Old Input Port and Old Input VPI fields gets deleted 🔥. If the Result field of the request message is "AckAll", a success response message MUST be sent upon successful completion of the operation. The success response message MUST NOT be sent until the Move Input Branch operation has been completed 👑.
For the VPC Move Input Branch message, if the virtual path connection specified by the Output Port and Output VPI fields already exists, but the input branch specified by the Old Input Port and Old Input VPI fields does not exist as a branch on that connection, a failure response MUST be returned with the Code field indicating, "12: The specified branch does not exist". 💀
If the virtual channel connection specified by the Output Port and Output Label fields, or if the virtual path connection specified by the Output Port and Output VPI fields does not exist, a failure response MUST be returned with the Code field indicating, "11: The specified connection does not exist". 😭
If the input branch specified by the New Input Port, New Input VPI, and New Input VCI fields for a virtual channel connection, or the input branch specified by the New Input Port and New Input VPI fields for a virtual path connection, is already in use by any connection other than the one specified by the Output Port and Output Label fields, then the resulting input branch will have multiple output branches 🍓. If multiple point-to-point connections share the same input branch, the result will be a point-to-multipoint connection. If multiple multipoint-to-point trees share the same input branches, the result will be a multipoint-to-multipoint connection 💜.
5. Reservation Management Messages ✨
okay so GSMP lets you save a spot for switch resources (bandwidth, buffers, queues, labels, etc.) before the connection even exists 🦋 That's the whole reservation vibe. You do it by messing with Reservations in the switch, and it's honestly iconic.
Reservations are hard state objects in the switch. The controller makes one by sending a Reservation Request message 💅 Every Reservation gets its own identifying number, called a Reservation ID. You can delete them with the Delete Reservation message or the Delete All Reservations message. A Reservation also disappears on its own once it gets deployed, which happens when you put its Reservation ID in a valid Add Branch message 🎀
The reserved resources MUST remain reserved until either the reservation is deployed (so the resources get applied to a branch) or the reservation is explicitly deleted with a Delete Reservation message or a Delete All Reservations message (so the resources get freed) 🔒 Also, if the switch gets reset, the Reservations and their reserved resources are gone too 💀
A Reservation object holds its Reservation ID plus all the connection state tied to a branch. The one difference is that the branch's input label and/or output label may be unspecified 🧚 So the Request Reservation message is basically a twin of the Add Branch message, which is so fitting ✨
The switch decides how many reservations it can store by setting Max Reservations in the Switch Configuration response message 📦 If it doesn't support reservations at all, it sets Max Reservations to 0. Valid Reservation IDs run from 1 to Max Reservations).
5.1. Reservation Request Message
The Reservation Request message creates a Reservation in the switch and reserves switch resources for a connection that might get set up later with an Add Branch message 🌸 The message type is:
Message Type = 70The request message looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reservation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Service Selector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Service Selector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IQS|OQS|P|x|N|O| Adaptation Method |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|M|B| |
+-+-+-+-+ Input Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|M|x| |
+-+-+-+-+ Output Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+When the value of either IQS or OQS is set to 0b10 then the following Traffic Parameters Block is appended to the above message 🍓
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Input TC Flags |x x x x x x x x x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Input Traffic Parameters Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Output TC Flags|x x x x x x x x x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Output Traffic Parameters Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Note: Fields and Parameters that have been explained in the description of the general connection message will not be explained in this section. Please refer to section 4.1 for details.
All the fields in the Reservation Request message mean the same thing they do in the Add Branch message, with a few exceptions 💖
Reservation ID: this is the Reservation ID of the Reservation. If its numerical value is greater than Max Reservations (from the Switch Configuration message), the switch sends a failure response saying "20: the Reservation ID out of Range". If the Reservation ID matches an extant Reservation, the failure response says "22: Reservation ID in use" 🙈
Input Label: if you give a specific input label, that label gets reserved along with the required resources ✨ If the Input Label is 0, the switch reserves the resources but won't bind them to a label until an add branch command comes in that references the Reservation Id. And if the input label is 0, all stacked labels MUST also be zeroed 🫶
Output Label: same energy as the input label. A specific Output Label gets reserved along with the resources. If the Output Label is 0, the switch reserves the resources but waits to bind them until an add branch command references the Reservation Id. If the Output Label is 0, all stacked labels MUST also be zeroed.
When the switch gets a valid Reservation Request, it reserves all the switch resources it needs to set up a branch with matching attributes 🦋 If there aren't enough resources, the switch sends a failure response saying "18: Insufficient resources". Any other failure responses work the way they do for the Add Branch message 💅
5.2. Delete Reservation Message
The Delete Reservation message deletes a Reservation object in the switch and frees the reserved switch resources tied to that reservation object 🗑️ The message type is listed in the source as:
Message Type = 71The Delete Reservation message has this format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reservation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+If the Reservation ID matches an extant Reservation, that reservation gets deleted and its switch resources are freed 🧹 If the numerical value of the Reservation ID is greater than Max Reservations (from the Switch Configuration message), the switch sends a failure response saying "20: Reservation ID out of Range". If the Reservation ID doesn't match any extant Reservation, the failure response says "23: Non-existent reservation ID" 👀
5.3. Delete All Reservations Message
The Delete All Reservation message deletes every extant Reservation object in the switch and frees the reserved switch resources of all of them 🌈 The message type is listed in the source as:
Message Type = 72The Delete All Reservation message has this format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+6. Management Messages
6.1. Port Management Message
The Port Management message is the multitool of port control 🧰 It lets a port come into service, go out of service, loop back, reset, or change its transmit data rate. Only the Bring Up and the Reset Input Port functions change the connection state (established connections) on the input port 🔄 Only the Bring Up function changes the value of the Port Session Number. The Port Management message MAY also be used for enabling the replace connection mechanism ✨ It also shows up as part of the Event Message flow control mechanism, which is very main character of it 👑
If the Result field of the request message is "AckAll", a success response message MUST be sent once the operation has successfully finished 💌 The success response message MUST NOT be sent until the operation has been completed, so no jumping the gun 🙅♀️ The Port Management Message is:
Message Type = 32The Port Management message has the following format for the request and success response messages:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|x|x|x|x|x|x|x| Duration | Function |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Flags | Flow Control Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transmit Data Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Okay bestie, here's the layout 🦋 The fields and parameters that were already explained in the general messages won't be repeated here, so go back to Section 3.1 if you need them 🫶
Note: Fields and Parameters that have been explained in the description of the general messages will not be explained in this section. Please refer to section 3.1 for details.
Event Sequence Number
Okay this one is lowkey clever 💅 The success response gives you the current Event Sequence Number of the switch port named in the Port field. It starts at zero when the port gets initialised, and it goes up by one every time the port spots an asynchronous event that the switch would normally report with an Event message. So if the Event Sequence Number in the success response doesn't match the one from the most recent Event message for that port, some events happened without ever getting reported via an Event message 😭 That's most likely because of flow control, which limits how fast a switch can send Event messages for each port. In the request message this field isn't used 🌸
R: Connection Replace
The R flag is only checked when Function = 1 (Bring Up) ✨ If the R flag is set in the Port Management request, the switch controller is asking the port to support the Connection Replace mechanism 👑
Connection Replace behaviour is described in chapter 4.2. If a switch doesn't support the Connection Replace mechanism, it MUST reply with the failure response "45: Connection Replace mechanism not supported on switch" and reset the R-flag 💀 If the response is a success, the R flag SHOULD stay set in the response message 🎀
Duration
Duration is how many seconds any of the loopback states stay in operation 🧚 Once the duration runs out, the port automatically goes back into service. If another Port Management message comes in for the same port before the duration has expired, the loopback keeps going for however long the Duration field in the new message says 🍓 The Duration field is only used in request messages where the Function field is set to Internal Loopback, External Loopback, or Bothway Loopback.
Function
Function is the action the switch takes 💖 It happens no matter what state the port is in right now (Available, Unavailable, or any Loopback state). If the function needs a new Port Session Number to be generated, the new Port Session Number MUST be returned in the success response message. Here are the defined values of the Function field 👇
Bring Up (Function = 1) Brings the port into service 🌈 All connections that start at the specified input port MUST be deleted, and a new Port Session Number MUST be selected, preferably using some form of random number. When that's done, all dynamically assigned Label values for the specified input port MUST be unassigned, so no connections can be made in the Label space that GSMP controls on this input port. After that, the Port Status of the port will be Available ✨
Take Down (Function = 2) Takes the port out of service 🥺 Any data received at this port gets thrown away, and no data gets sent out of this port. After that, the Port Status of the port will be Unavailable.
Careful here, this is a spicy one 💀 The behaviour is undefined if the port being taken down is the one the GSMP session that controls the switch is running over. (In that case the most probable behaviour would be for the switch to either ignore the message, or to terminate the current GSMP session and start another one, possibly with the backup controller if there is one.) The correct way to reset the link GSMP is running over is to send an RSTACK message in the adjacency protocol 🙈
Internal Loopback (Function = 3) Data coming into the output port from the switch fabric gets looped back through to the input port, so it returns to the switch fabric 🔁 All of the input port's functions above the physical layer, like header translation, get run on the looped back data. After that, the Port Status of the port will be Internal Loopback.
External Loopback (Function = 4) Data arriving at the input port from the external communications link gets looped straight back out to the communications link at the physical layer, without entering the input port at all 🦋 None of the input port's functions above the physical layer run on the looped back data. After that, the Port Status of the port will be External Loopback.
Bothway Loopback (Function = 5) Both internal and external loopbacks happen at the same time 🌸 After that, the Port Status of the port will be Bothway Loopback.
Reset Input Port (Function = 6) This one is a full reset, bestie 😭 All connections that start at the specified input port MUST be deleted, and the input and output port hardware MUST be re-initialised. Hmm, one correction: the hardware is re-initialised, not "MUST be re-initialised" twice, so once it's done, all dynamically assigned Label values for the specified input port MUST be unassigned, so no connections can be made in the Label space that GSMP controls on this input port. The range of labels GSMP can control on this port goes back to the default values from the Port Configuration message 💅 The transmit data rate of the output port MUST be set to its default value. The Port Session Number does NOT change with Reset Input Port 🙅 After that, the Port Status of the port will be Unavailable.
Correction for accuracy: the input and output port hardware are re-initialised, as stated above, and this is a MUST for the connection deletion, label unassignment, and transmit data rate reset only. The hardware re-initialisation itself is described in the original without a keyword, so it is kept as plain text.
Reset Flags (Function = 7) This one resets the Event Flags and Flow Control Flags 🧹 For each bit set in the Event Flags field, the matching Event Flag in the switch port MUST be reset to 0. For each bit set in the Flow Control Flags field, the matching Flow Control Flag in the switch port MUST be toggled, which means flow control for that event gets turned off if it's on, and turned on if it's off 🔄 The Port Status of the port doesn't change with this function.
Set Transmit Data Rate (Function = 8) Sets the transmit data rate of the output port as close as possible to the rate in the Transmit Data Rate field 🎯 In the success response, the Transmit Data Rate MUST show the actual transmit data rate of the output port. If the transmit data rate of the requested output port can't be changed, a failure response MUST be returned with the Code field showing "43: The transmit data rate of this output port cannot be changed" 😤 If the rate can be changed but the Transmit Data Rate value is outside the acceptable range, a failure response MUST be returned with the Code field showing "44: Requested transmit data rate out of range for this output port" 🚫 In the failure response, the Transmit Data Rate MUST contain the same value as the request that caused the failure. The transmit data rate of the output port doesn't change with Bring Up, Take Down, or any of the Loopback functions, and only Reset Input Port puts it back to the default value ✨
Transmit Data Rate
This field is only used in request and success response messages where the Function field is set to "Set Transmit Data Rate" 🧚 It sets the output data rate of the output port, and it's given in cells/s and bytes/s. If the Transmit Data Rate field holds the value 0xFFFFFFFF, the transmit data rate of the output port SHOULD be set to the highest valid value 🚀
Event Flags
Okay so the Event Flags field is how the controller clears event flags on a port 🍃 Each Event Flag in a switch port matches a type of Event message. When a switch port sends an Event message, it sets the matching Event Flag on that port. Depending on the Flow Control Flag setting, a port is either subject to flow control or it isn't 🎀 If it is subject to flow control, it's not allowed to send another Event message of the same type until the Event Flag has been reset. To reset an event flag, the Function field in the request message gets set to "Reset Flags" 💖 For each bit set in the Event Flags field, the matching Event Flag in the switch port gets reset.
The Event Flags field is only used in a request message where the Function field is set to "Reset Event Flags". For all other Function values, the Event Flags field isn't used. In the success response, the Event Flags field MUST be set to the current value of the Event Flags for the port after the operation in the request is complete, for every Function value 👑 Setting the Event Flags field to all zeros in a "Reset Event Flags" request lets the controller check the current state of the Event Flags and the current Event Sequence Number of the port without changing any Event Flags 🔍
The correspondence between the types of Event messages and the bits of the Event Flags field is as follows:
Flow Control Flags Field 🌸
okay so this field is where you check whether flow control is switched on 🦋. Each flag tells you if the flow control mechanism for that event (from the Events Flag field) is active on that port. If the Flow Control Flag is set, flow control for that event on that port is activated. ✨
to flip them, the request's Function field gets set to "Reset Flags" 💅. when you do a reset, every flag that's set in the Flow Control Flags field means its matching flow control mechanism MUST be toggled. 🔥
the Flow Control Flags use the same event definitions as the Event Flag, so they line up perfectly 🫶
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|D|I|N|Z|A|x|x|x|x|x|x|x|x|x|x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U: Port Up Bit 0, (most significant bit)
D: Port Down Bit 1,
I: Invalid Label Bit 2,
N: New Port Bit 3,
Z: Dead Port Bit 4,
A: Adjacency Event Bit 5,
x: Unused Bits 6-15.6.2. Label Range Message ✨
okay bestie, so each port has a default label range, Min Label to Max Label 🎀. that default gets set by the Port Configuration or All Ports Configuration messages. when the protocol starts up, before any Label Range messages get sent, every port's label range is set to that default 🌈 (fun fact: what the default actually is depends on the switch's design and config, and GSMP doesn't define it 🙈).
the Label Range message is how you change which labels a port supports 💖. every switch port MUST declare whether it supports the Label Range message in its Port Configuration or All Ports Configuration messages 🫶. the message type is:
Message Type = 33
here's the request and success response format 👑
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q|M|D|x| Range Count | Range Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Label Range Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Note: the fields and parameters already covered in the general messages aren't explained again here, so peep section 3.1 for those 🧚
each element of the Label Range Block looks like this 🍓
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|V|C| |
+-+-+-+-+ Min Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x| |
+-+-+-+-+ Max Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remaining Labels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Flags 💅
- Q: Query. If the Query flag is set in a request message, the switch MUST respond with the current range of valid labels. A request with the Query flag set doesn't change the current label range. If the Query flag is zero, the message is asking for a label change operation. 🔍
- M: Multipoint Query. If the Multipoint Query flag is set, the switch MUST respond with the current range of valid specialized multipoint labels. A request with this flag set doesn't change the current label range either. ✨
- D: Non-contiguous Label Range Indicator. This flag gets set in a Query response when the labels available for assignment form a non-contiguous set. 🌸
- V: Label. How the Label flag gets used depends on the port type. 🦋
- C: Multipoint Capable. Shows the label range that can be used for multipoint connections. 🫶
Range Count means the count of Label Range elements inside the Label Range Block 🎀
Range Length is the byte count in the Label Range Block 🌈
Min Label is the minimum label value in the range 💖
Max Label is the maximum label value in the range 👑
Remaining Labels is the maximum number of remaining labels that could still be requested for allocation on the specified port 🔥
the success response to a Label Range message that asks for a label range change is a copy of the request, with the Remaining Labels field updated to the new values after the change 🎉
if the switch can't handle a request to change the label range, it MUST send back a failure response with the Code field set to "40: Cannot support one or more requested label ranges" 💀. in that failure response, the switch MUST use the Min Label and Max Label fields to suggest a label range it can actually support 🧚
a Label Range request may be issued regardless of the Port Status or the Line Status of the target switch port 🌸. if the Port field of the request holds an invalid port (one that doesn't exist, or one that's been removed from the switch), a failure response MUST be returned with the Code field set to "4: One or more of the specified ports does not exist" 😭
if the Query flag is set in the request, the switch MUST reply with a success response containing the current range of valid labels supported by that port 💅. the Min Label and Max Label fields aren't used in the request message in this case ✨
if the Multipoint Query flag is set in the request and the switch doesn't support a range of valid multipoint labels, the switch MUST reply with a failure response with the Code field set to "42: Specialised multipoint labels not supported" 🙈. the Min Label and Max Label fields aren't used in the Multipoint request message either 🍓
last one: if a label range changes and there are still connection states using labels from the previous label range, a success response message MUST be returned with the Code field set to "46: One or more labels are still used in the previous Label Range" ⭐. this basically means the label range did change successfully, but the switch is giving you a warning that connection states for the old range are still hanging around 👀
6.2.1. Labels 🦋
6.2.1.1. ATM Labels
Okay bestie, ATM labels are next and they're giving structure 🦋💅. If the Label Type = ATM Label, the labels range message MUST be interpreted as an ATM Label, and the layout looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|V|C| ATM Label (0x100) | Label Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x| min VPI | min VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x| ATM Label (0x100) | Label Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x| max VPI | max VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remaining VPI's | Remaining VCI's |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+V: Label If the Label flag is set, the message refers to a range of VPI's only. The Min VCI and Max VCI fields are unused then. If the Label flag is zero, the message refers to a range of VCI's on either one VPI or on a range of VPI's.
Min VPI, Max VPI These specify a range of VPI values, Min VPI to Max VPI inclusive, so both ends count ✨. A single VPI can be specified by giving Min VPI and Max VPI the same value. In a request message, if the value of the Max VPI field is less than or equal to the value of the Min VPI field, the requested range is a single VPI with a value equal to the Min VPI field. Zero is a valid value 🧚. In a request message, if the Query flag is set and the Label flag is zero, the Max VPI field specifies a single VPI and the Min VPI field is not used. The maximum valid value of these fields for both request and response messages is 0xFFF.
Min VCI, Max VCI These specify a range of VCI values, Min VCI to Max VCI inclusive 🌸. A single VCI can be specified by giving Min VCI and Max VCI the same value. In a request message, if the value of the Max VCI field is less than or equal to the value of the Min VCI field, the requested range is a single VCI with a value equal to the Min VCI field. Zero is a valid value. (However, VPI=0, VCI=0 is not available as a virtual channel connection, because it's used as a special value in ATM to indicate an unassigned cell 🙈.)
Remaining VPI's, Remaining VCI's These fields are unused in the request message. In the success response message and in the failure response message, these fields give the maximum number of remaining VPI's and VCI's that could be requested for allocation on the specified port (after completion of the requested operation in the case of the success response). It gives the switch controller an idea of how many VPI's and VCI's it could request. The number given is the maximum possible given the constraints of the switch hardware. There is no implication that this number of VPI's and VCI's is available to every switch port 💅.
If the Query flag and the Label flag are set in the request message, the switch MUST reply with a success response message containing the current range of valid VPI's that are supported by the port. The Min VPI and Max VPI fields are not used in the request message.
If the Query flag is set and the Label flag is zero in the request message, the switch MUST reply with a success response message containing the current range of valid VCI's that are supported by the VPI specified by the Max VPI field. If the requested VPI is invalid, a failure response MUST be returned indicating: 13: One or more of the specified Input Labels is invalid. The Min VPI field is not used in either the request or success response messages.
If the Query flag is zero and the Label flag is set in the request message, the Min VPI and Max VPI fields specify the new range of VPI's to be allocated to the input port specified by the Port field. The range of VPI's previously allocated to this port SHOULD be increased or decreased to the specified value.
If the Query flag and the Label flag are zero in the request message, the Min VCI and Max VCI fields specify the range of VCI's to be allocated to each of the VPI's specified by the VPI range. The range of VCI's previously allocated to each of the VPI's within the specified VPI range on this port SHOULD be increased or decreased to the specified value. The allocated VCI range MUST be the same on each of the VPI's within the specified VPI range 🦋.
If the switch is unable to satisfy a request to change the label range, it MUST return a failure response message with the Code field set to: 40: Cannot support one or more requested label ranges. If the switch is unable to satisfy a request to change the VPI, the switch MUST use the Min VPI and Max VPI fields to suggest a VPI range that it would be able to satisfy, and set the VCI fields to zero. Or, if the switch is unable to satisfy a request to change the VCI range on all VPI's within the requested VPI range, the switch MUST use the Min VPI, Max VPI, Min VCI, and Max VCI fields to suggest a VPI and VCI range that it would be able to satisfy.
In all other failure response messages for the label range operation, the switch MUST return the values of Min VPI, Max VPI, Min VCI, and Max VCI from the request message.
While switches can typically support all 256 or 4096 VPI's, the VCI range that can be supported is often more constrained 😭. Often the Min VCI MUST be 0 or 32. Typically, all VCI's within a particular VPI MUST be contiguous. The hint in the failure response message lets the switch suggest a label range that it could satisfy given its particular architecture 🫶.
While the Label Range message is defined to specify both a range of VPI's and a range of VCI's within each VPI, the most likely use is to change either the VPI range or the range of VCI's within a single VPI. It's possible for a VPI to be valid but to be allocated no valid VCI's. Such a VPI could be used for a virtual path connection, but to support virtual channel connections it would need to be allocated a range of VCI's 👑.
6.2.1.2. Frame Relay Labels
Next up are Frame Relay labels, and the vibe is very precise 🍓. If the Label Type = FR Label, the labels range message MUST be interpreted as Frame Relay Labels, and it looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|V|C| FR Label (0x101) | Label Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x| Res |Len| Min DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x| FR Label (0x101) | Label Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x| Res |Len| Max DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remaining DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+V: Label The Label flag is not used 🌈.
Res The Res field is reserved in [21], i.e., it is not explicitly reserved by GSMP.
Len The Len field specifies the number of bits of the DLCI. The following values are supported:
Len DLCI bits
0 10
2 23Min DLCI, Max DLCI These specify a range of DLCI values, Min DLCI to Max DLCI inclusive. The values SHOULD be right justified in the 23-bit fields, and the preceding bits SHOULD be set to zero ✨. A single DLCI can be specified by giving Min DLCI and Max DLCI the same value. In a request message, if the value of the Max DLCI field is less than or equal to the value of the Min DLCI field, the requested range is a single DLCI with a value equal to the Min DLCI field. Zero is a valid value.
Remaining DLCI's This field is unused in the request message. In the success response message and in the failure response message, this field gives the maximum number of remaining DLCI's that could be requested for allocation on the specified port (after completion of the requested operation in the case of the success response). It gives the switch controller an idea of how many DLCI's it could request. The number given is the maximum possible given the constraints of the switch hardware. There is no implication that this number of DLCI's is available to every switch port 💖.
6.2.1.3. MPLS Generic Labels
This section is for PortTypes using MPLS labels 🔥. These labels are for use on links where the label values are independent of the underlying link technology. Examples of such links are PPP and Ethernet. On such links, the labels are carried in MPLS label stacks [14]. If Label Type = MPLS Gen Label, the labels range message MUST be interpreted as MPLS Generic Label, and it looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|V|C| MPLS Gen Label (0x102)| Label Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x|x|x|x|x| Min MPLS Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x| MPLS Gen Label (0x102)| Label Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x|x|x|x|x| Max MPLS Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remaining Labels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+V: Label The Label flag is not used 🧚.
Min MPLS Label, Max MPLS Label These specify a range of MPLS label values, Min MPLS Label to Max MPLS Label inclusive. The Max and Min MPLS label fields are 20 bits each 🦋.
Remaining MPLS Labels This field is unused in the request message. In the success response message and in the failure response message, this field gives the maximum number of remaining MPLS Labels that could be requested for allocation on the specified port (after completion of the requested operation in the case of the success response). It gives the switch controller an idea of how many MPLS Labels it could request. The number given is the maximum possible given the constraints of the switch hardware. There is no implication that this number of Labels is available to every switch port 💅.
6.2.1.4. FEC Labels
The Label Range message is not used for FEC Labels, and that part is for further study 🙈.
7. State and Statistics Messages ✨
okay so this section is where the controller gets to be nosy 👀 It can ask for the values of hardware counters on the switch's input and output ports and connections, and it can check the connection state of a switch input port. Iconic behaviour, honestly 💅
The Connection Activity message tells you whether one or more specific connections have recently been carrying traffic. The Statistics message is for pulling the traffic and error counters for ports and connections. main character energy 🎀
The Report Connection State message asks an input port to report the connection state for a single connection, a single ATM virtual path connection, or the entire input port. so many options, all of them slay 🦋
7.1. Connection Activity Message
bestie, this is the one that answers "has anything been happening on this connection lately?" 🌸 It carries one or more Activity Records, and each record asks about and returns info for a single connection. Each connection gets identified by its input port and Input Label, which live in the Input Port and Input Label fields of each Activity Record 🧚
There are two ways the switch can detect activity 💜 If it supports per connection traffic accounting, the current value of the traffic counter for each specified connection MUST be returned. The units of traffic aren't specified, but they'll typically be either cells or frames 📦 Then the controller MUST compare the traffic counts returned in the message with previous values for each of the specified connections, so it can figure out whether each connection was active in the meantime. Lowkey genius 🧠
If the switch doesn't do per connection traffic accounting but can detect per connection activity some other unspecified way, the result may be indicated for each connection using the Flags field 🌈 The Connection Activity message is:
Message Type = 48
The Connection Activity request and success response messages look like this 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Records |x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Activity Records ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Note: Fields and Parameters that have been explained in the description of the general messages will not be explained in this section. Please refer to section 3.1 for details.
Number of Records 🔢 This field specifies the number of Activity Records to follow. The number of Activity records in a single Connection Activity message MUST NOT cause the packet length to exceed the maximum transmission unit defined by the encapsulation. don't be greedy with the packet size, bestie 🙈
Each Activity Record looks like this 💅
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V|C|A|x| TC Count | TC Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Traffic Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ Input Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Flags 🚩
V: Valid Record ✅ In the success response message, the Valid Record flag is used to indicate an invalid Activity Record. The flag MUST be zero if any of the fields in this Activity Record are invalid, if the input port specified by the Input Port field does not exist, or if the specified connection does not exist. If the Valid Record flag is zero in a success response message, the Counter flag, the Activity flag, and the Traffic Count field are undefined. If the Valid Record flag is set, the Activity Record is valid, and the Counter and Activity flags are valid. The Valid Record flag is not used in the request message.
C: Counter 🔢 In a success response message, if the Valid Record flag is set, the Counter flag, if zero, indicates that the value in the Traffic Count field is valid. If set, it indicates that the value in the Activity flag is valid. The Counter flag is not used in the request message.
A: Activity 🔥 In a success response message, if the Valid Record and Counter flags are set, the Activity flag, if set, indicates that there has been some activity on this connection since the last Connection Activity message for this connection. If zero, it indicates that there has been no activity on this connection since the last Connection Activity message for this connection. The Activity flag is not used in the request message.
TC Count 🧮 In cases where per connection traffic counting is supported, this field contains the count of Traffic Count entries.
TC Block Length 📏 In cases where per connection traffic counting is supported, this field contains the Traffic Count block size in bytes.
Input Port 🚪 Identifies the port number of the input port on which the connection of interest originates, in order to identify the connection (regardless of whether the traffic count for the connection is maintained on the input port or the output port).
Input Label 🏷️ These fields identify the specific connection for which statistics are being requested.
Traffic Count 🚗 This field is not used in the request message. In the success response message, if the switch supports per connection traffic counting, the Traffic Count field MUST be set to the value of a free running, connection specific, 64-bit traffic counter counting traffic flowing across the specified connection. The value of the traffic counter is not modified by reading it. If per connection traffic counting is supported, the switch MUST report the Connection Activity result using the traffic count rather than using the Activity flag. the counter just keeps going and reading it doesn't reset it, which is so considerate 🫶
The format of the failure response is the same as the request message, with the Number of Records field set to zero and no Connection Activity records returned in the message. If the switch is incapable of detecting per connection activity, a failure response MUST be returned indicating, "3: The specified request is not implemented on this switch". no cap, that's a very clear "nope" 💀
7.2. Statistics Messages ✨
okay so the Statistics messages are the ones you use to ask for all the port, connection, and error counters 📊🦋
The Statistics request messages look like this 👇
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Note: the Fields and Parameters that already got explained in the general messages description aren't explained again here, so go back to section 3.1 if you need them 🧚
Label: this is the bit that says which specific connection you're asking about 🎀
The success response for the Statistics message looks like this 👇
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Input Cell Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Input Frame Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Input Cell Discard Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Input Frame Discard Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Header Checksum Error Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Input Invalid Label Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Output Cell Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Output Frame Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Output Cell Discard Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Output Frame Discard Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Note: the Fields and Parameters already explained in the general messages description won't be explained again in this section either, so check section 3.1 for those 💅
Input Cell Count, Output Cell Count 🧮: these are free running 64-bit counters that count cells arriving at the input or leaving the output. They're only relevant when the label type is ATM. For every other label type, the sender SHOULD set these fields to zero and the receiver SHOULD ignore them 🙈
Input Frame Count, Output Frame Count 📦: same vibe, but these are free running 64-bit counters for frames (packets) arriving at the input or leaving the output. They matter for label types FR and MPLS. For every other label type, the sender SHOULD set them to zero and the receiver SHOULD ignore them ✨
Input Cell Discard Count, Output Cell Discard Count 🗑️: free running 64-bit counters for cells thrown away because a queue overflowed, on an input port or an output port. Relevant for label type ATM only. Everything else gets zero from the sender and gets ignored by the receiver, same as before, so the SHOULD still applies 💜
Input Frame Discard Count, Output Frame Discard Count 🌸: free running 64-bit counters for frames discarded due to congestion, on an input port or an output port. These are relevant for label types FR and MPLS. For all other label types, the sender SHOULD set them to zero and the receiver SHOULD ignore them 🫶
Header Checksum Error Count 🔥: a free running 64-bit counter for cells or frames discarded because of header checksum errors when they arrive at an input port. For an ATM switch, this is the HEC count 🧚
Invalid Label Count 🙅♀️: a free running 64-bit counter for cells or frames discarded because their Label was invalid when they arrived at an input port 💀
7.2.1. Port Statistics Message
okay the Port Statistics message asks for the stats of whichever switch port is named in the Port field 🔌✨ The Label field in the Port Statistics request is ignored, so don't stress about it 🙈 All of the count fields in the success response are per-port counts, no matter which connection the cells or frames belonged to 💖
Any count field in the success response that the port doesn't support MUST be set to zero 🍓 The Port Statistics message is:
Message Type = 497.2.2. Connection Statistics Message
the Connection Statistics message asks for stats on the connection named in the Label field, the one that starts on the switch input port named in the Port field 🦋 All of the count fields in the success response only refer to that one connection 🎀
The Header Checksum Error Count and Invalid Label Count fields aren't connection specific, so they MUST be set to zero 🙃 Any other count field that can't be tracked per connection MUST also be set to zero in the success response 💅 The Connection Statistics message is:
Message Type = 507.2.3. QoS Class Statistics Message
the QoS Class Statistics message is not supported in this version of GSMP 😭 It's reserved for later, so the message type is:
Message Type = 51 is reserved.7.3. Report Connection State Message ✨
okay bestie, this one is all about asking an input port to spill the tea on its connections 💅 You can ask about one connection or the whole port at once. The Message Type is 52 🦋
The request message looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|A|V| |
+-+-+-+-+ Input Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Note: fields and parameters that were already explained in the general messages won't be explained again here 🌸 For those, check out section 3.1.
Input Port 🍓 This is the port number of the input port whose connection state you're asking about.
Flags
A: All Connections 👑 If the All Connections flag is set, the message asks for the connection state of every connection that starts at the input port named in the Input Port field. In this case the Input Label field and the Label flag are unused.
V: ATM VPI 🌈 The ATM VPI flag may only be set for ports with PortType=ATM. If the switch gets a Report Connection State message with the ATM VPI flag set, and the input port in the Input Port field does not have PortType=ATM, the switch MUST return a Failure response "28: ATM Virtual Path switching is not supported on non-ATM ports". Yikes 💀
If the All Connections flag is zero and the ATM VPI flag is also zero, the message asks for the connection state of the one connection that starts at the input port named in the Port and Input Label fields. 🦋
ATM specific procedures: ✨ If the All Connections flag is zero and the ATM VPI flag is set, and the input port in the Input Port field has LabelType=ATM, the message asks for the connection state of the virtual path connection that starts at the input port named in the Input Port and Input VPI fields. If the Input VPI identifies an ATM virtual path connection (that is, a single switched virtual path), you get the state for that connection. If the Input VPI identifies a virtual path that contains virtual channel connections, the message asks for the connection state of all the virtual channel connections that belong to that virtual path. 🫶
Input Label 🧚 This field identifies the specific connection whose state is being requested. For requests that don't need a specific connection, the Input Label field isn't used.
The Report Connection State success response looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Connection Records ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Note: fields and parameters that were already explained in the general messages won't be explained again here 🌸 For those, check out section 3.1.
Input Port 💖 This matches the Input Port field in the request. It names the input port whose connection state is being reported.
Sequence Number 🎀 If the requested connection state can't be reported in one success response, every following success response to the same request MUST increment the Sequence Number. The first success response to a new request MUST have a Sequence Number of zero. Counting matters, bestie 🔢
Connection Records 🌸 Each success response MUST contain one or more Connection Records. Each Connection Record describes a single point-to-point or point-to-multipoint connection. The number of Connection Records in one Report Connection State success response MUST NOT make the packet length go over the maximum transmission unit defined by the encapsulation. If the requested connection state can't fit in one success response, multiple success responses MUST be sent. Every success response sent for the same request MUST have the same Input Port and Transaction Identifier fields as the request. A single Connection Record MUST NOT be split across multiple success responses. "More" in the Result field means one or more further success responses should be expected for the same request. "Success" in the Result field means the response to the request has been completed. The Result values are defined in chapter 3.1.1. 💅
Each Connection Record has this format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|V|P| Record Count | Record Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ Input Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Output Branch Records ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Flags
A: All Connections 👑
V: ATM VPI 🦋 For the first Connection Record in each success response, the All Connections and ATM VPI flags MUST match the ones in the request. For later Connection Records in the same success response, these flags aren't used.
P: ATM VPC 🌈 The ATM VPC flag may only be set for ports with PortType=ATM. If the ATM VPC flag is set, and only if it's set, the Connection Record refers to an ATM virtual path connection. ✨
Input Label 🧚 The input label of the connection described in this Connection Record.
Record Count 🍓 The count of Output Branch Records included in a response message.
Record Length 🍓 The length, in bytes, of the Output Branch Records field.
Output Branch Records 💜 Each Connection Record MUST contain one or more Output Branch Records. Each Output Branch Record describes a single output branch of the connection identified by the Input Label field of the Connection Record and the Input Port field of the Report Connection State message. A point-to-point connection only needs one Output Branch Record. A point-to-multipoint connection needs several. If a point-to-multipoint connection has more output branches than fit in one Connection Record inside one success response, that connection may be reported using multiple Connection Records across multiple success responses. 🔥
Each Output Branch Record has this format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ Output Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Output Port 💖 The output port of the switch that this output branch is routed to.
Output Label 🎀 The output label of the output branch described in this Output Branch Record.
ATM specific procedures: ✨ If this Output Branch Record is part of a Connection Record that describes a virtual path connection (the ATM VPC flag is set), the Output VCI field is unused.
A Report Connection State request may be sent no matter what the Port Status or the Line Status of the target switch port is. 🌸
If the Input Port of the request is valid, and the All Connections flag is set, but there are no connections set up on that port, a failure response MUST be returned with the Code field set to "10: General Message Failure". For the Report Connection State message, this failure code means that no connections matching the request were found. 🙈 A failure response SHOULD also be returned if the Input Port of the request is valid, the All Connections flag is zero, and no connections matching the specified connection are found on that port. 💅
8. Configuration Messages ✨
Configuration messages let the controller find out what the switch can do 🧚 There are three configuration request messages: Switch, Port, and All Ports. 👑
8.1 Switch Configuration Message ✨
Okay bestie, the Switch Configuration message is how you ask the switch for its global settings 🧚, meaning the stuff that isn't tied to one specific port. The message type is:
Message Type = 64The Port field does nothing in this message, so it isn't used 🙈
Here's the layout, and it's giving main character energy 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MType | MType | MType | MType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Firmware Version Number | Window Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switch Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Switch Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Reservations |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Note: Anything already explained in the general messages isn't repeated here, so go check section 3.1 for those details 📖
Now the fields, bestie 🌸
MType Represents an alternative QoS Configuration type. In the request, the requested MType goes in the most significant (leftmost) MType byte, and the other three MType bytes are unused. The reply either accepts the request by putting the requested MType in the leftmost MType field, or rejects it by responding with MType=0 (the default MType) in the first MType field. If it rejects, the switch reply can optionally include up to 3 more MType values, each one an available alternative QoS Configuration. A switch that only supports the default QoS Configuration always returns MType=0 in all four MType fields. MType negotiation is discussed in section 8.1.1 💅
0 - Indicates use of the default GSMP model
1-200 - Reserved
201-255 - ExperimentalFirmware Version Number The version number of the switch control firmware that's installed 💾
Window Size This is the maximum number of unacknowledged request messages the controller can send without the possibility of loss. It exists so request messages don't get dropped in the switch because its receive buffer overflowed 🫶 It's just a hint for the controller, though. If it wants, the controller can experiment with higher and lower window sizes to heuristically figure out the best one 🔥
Switch Type A 16-bit field assigned by the switch's manufacturer. (For these purposes, the manufacturer is assumed to be the organisation identified by the OUI in the Switch Name field.) The Switch Type identifies the product, and when it's combined with the OUI from the Switch Name, the product is uniquely identified. Network Management can use this to pull product info from a database 📚
Switch Name A 48-bit quantity that's unique within the operational context of the device. If it's available, a 48-bit IEEE 802 MAC address can be used as the Switch Name. The most significant 24 bits of the Switch Name MUST be an Organisationally Unique Identifier (OUI) that identifies the manufacturer of the switch 🦋
Max Reservations The maximum number of Reservations the switch can support (see Chapter 5). A value of 0 means the switch doesn't support Reservations at all 😭
8.1.1 Configuration Message Processing 🌈
Once adjacency is first established between a controller and a switch, a controller that wants a QoS Configuration model other than the default sends a Switch Configuration request with the requested QoS Configuration's MType value in it. This request MUST be sent before any connection messages are exchanged, so it's a very important first move 👑 If the switch can support the requested QoS Configuration, it puts the requested MType value in the response to say "yes, I accept." If it can't, it swaps the MType value in the request for the default QoS Configuration's value, i.e., MType=0 ✨
The switch configuration response messages can also include the MType values of up to three alternative QoS Configurations the switch supports, and the controller can pick between them 💖
The exchange keeps going until the controller sends a requested MType the switch accepts, or until the controller sends a connection request message instead. If the exchange ends without confirmation of an alternate switch model, the default Mtype=0 is be used 🙈
Once an MType has been established for the switch, it can't be changed without a full restart. That means re-establishing adjacency and resetting all connections 💀
8.2. Port Configuration Message ✨
okay so the Port Configuration message is how you ask the switch for the config info of ONE port 🔌 you put the port you want in the Port field of the request, and the message type is Message Type = 65. 🎀
the success response looks like this 👀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Flags | Port Attribute Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PortType |S|x|x|x|x|x|x|x| Data Fields Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ PortType Specific Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x x x x x x x x x| Number of Service Specs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
~ Service Specs List ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Note: the fields and parameters already explained in the general messages description aren't repeated here, so go check section 3.1 for those 💅
Port 🔢 This is the switch port the config info is about, covering BOTH the input and output sides of that port 🔁 Port numbers are 32 bits wide and the switch picks them. The switch can carve those 32 bits into subfields that match its physical hardware layout (like physical slot and port), and if it does, that can be shown in the Physical Slot Number and Physical Port Number fields. 🧩
Event Sequence Number 🔔 This starts at zero when the port gets initialised, then goes up by one every time the port spots an async event the switch would normally report with an Event message. You can read more about it in section 9. 📈
Event Flags 🚩 Event Flags on a switch port line up with a type of Event message. 💌
Port Attribute Flags 🎛️ These show off the specific behaviour of a switch port. Here's the layout:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R: Connection Replace flag 🔁✨ When this is set, connections made by an Add Branch message with its own R-bit set will replace any earlier connection if the established output branch and the requested output branch end up clashing [see chapter 4.2]. big replace energy 😤
x: Unused. 🫥 these bits are just unused, no drama.
PortType 🧭 Pick your port type:
1: PortType is ATM
2: PortType is FR
3: PortType is MPLSS: Service Model 🧁 When this is set, it means Service Model data comes after the PortType Specific port config data. 🍰
Data Fields Length 📏 This is the total length in bytes of the PortType Specific Data and Service Model Data fields combined. You can figure out each field's length from the other one, so this number is mostly a sanity check and a helper for parsing the All Ports Configuration message success response. 🧮
PortType Specific Data 💎 This holds the config data that's specific to whatever PortType you picked. Both its format and its length depend on that PortType, and it's laid out in the subsection right below 👇
Number of Service Specs 🔢 The total count of Service Specs that come after it, either in the rest of the Port Configuration message response or in the Port Configuration Record. 📚
Service Specs List 📜 These Service Specs line up with the Input and Output Service selectors used in Connection Management and Reservation messages. Specifically, they list out the values you can use when the Service Selector (IQS or OQS) is set to 0b10, which means the default service specification model from Chapter 10 is in play. 🎯
Service Spec 🪪 Here's what each one looks like:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service ID | Capability Set ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Each Service Spec names a Service the switch supports, plus the Capability Set ID that picks out the parameters for that instance of the Service. The Service Specs List can have several entries with the same Service ID, but each Service Spec in the Service Specs List MUST be unique. 🫶
Service ID 🆔 The Service ID of a Service that's supported on the port. You'll find the Service ID values defined as part of the Service definition in Chapter 9.6. 📖
Capability Set ID 🧩 This picks out the Capability Set ID of the Service (the one named by the Service ID) that the port supports. The switch sets these Capability Set ID values in its Service Configuration response message (see Section 8.4). The switch MUST NOT return a {Service ID, Capability Set ID} pair that wasn't reported in a Service Configuration response message. 🚫 no making stuff up, bestie 💀
8.2.1. PortType Specific Data 💖
okay the format and length of the PortType Specific Data field depend on the PortType value of the same message or record. This shows up in the Port Configuration message success response and in the Port Records of the All Port Configuration message success response, and the same rule applies to both. Here's the layout, and the Min and Max Label fields for each defined PortType get covered in the subsections after this one 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P|M|L|R|Q| Label Range Count | Label Range Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Default Label Range Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Data Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transmit Data Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Status | Line Type | Line Status | Priorities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Physical Slot Number | Physical Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Note: same deal as before, anything already explained in the general messages section isn't repeated here. Check section 3.1 for the details 📌
Every Default Label Range Block uses this format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|V|C| |
+-+-+-+-+ Min Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x| |
+-+-+-+-+ Max Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Flags 🚩✨
P: VP Switching 🛤️ The ATM VPC flag can only be set for ports with PortType=ATM. When it's set, it means this input port can handle virtual path switching. When it's zero, this input port can only do virtual channel switching. 🦋
M: Multicast Labels 🌿 When this is set, the output port can label each output branch of a point-to-multipoint tree with its own label. When it's zero, the output port can't give each output branch a different label. 🏷️
L: Logical Multicast 📡 When this is set, the output port can support more than one branch from any point-to-multipoint connection. People often call this logical multicast. When it's zero, the output port can only handle a single output branch from each point-to-multipoint connection. 🌈
R: Label Range 🔄 When this is set, the switch port can reallocate its label range, so it accepts the Label Range message. When it's zero, the port doesn't accept Label Range messages. 🙅♀️
Q: QoS 🎀 When this is set, the switch port can handle the Quality of Service messages defined in section 9 of this specification. When it's zero, the port doesn't accept Quality of Service messages. ⭐
V: Label 🏷️ The Label flag depends on the port type. 🧚
C: Multipoint Capable 🦋 okay so this flag says the label range may be used for multipoint connections. if it's set, multipoint is on the table 💅
Label Range Count 🌸 the total number of Default Label Range elements inside the Default Label Range Block. just a count, bestie 🍓
Label Range Length ✨ byte count in the Default Label Range Block. simple, clean, no notes 💖
Min Label 💜 each PortType gets its own Min Label spec, and those live in the subsections coming up. it's the default minimum value of a dynamically assigned incoming label that the connection table on the input port supports and that GSMP can control. and the Label Range message does not change it, so it's giving stable 👑
Max Label 🌈 same deal as Min Label, but for the top end. the per-PortType spec is in the subsections, it's the default maximum value of a dynamically assigned incoming label the input port's connection table supports and GSMP can control, and the Label Range message doesn't touch it either 🫶
Receive Data Rate 🔥 the maximum rate of data that may arrive at the input port. the units depend on the PortType:
cells/s for PortType = ATM
bytes/s for PortType = FR
bytes/s for PortType = MPLSTransmit Data Rate 🚀 the maximum rate of data that may depart from the output port. same unit situation as above:
cells/s for PortType = ATM
bytes/s for PortType = FR
bytes/s for PortType = MPLS(The transmit data rate of the output port may be changed by the Set Transmit Data Rate function of the Port Management message.) 🎀
Port Status 🚦 this one tells you the administrative state of the port. the defined values are:
- Available:
Port Status = 1. the port can send and receive cells or frames. when a port moves into Available from any other administrative state, all dynamically assigned connections MUST be cleared and a new Port Session Number MUST be generated. 💚 - Unavailable:
Port Status = 2. the port has been intentionally taken out of service. no cells or frames get transmitted from it, and none get received by it. 🙈 - Internal Loopback:
Port Status = 3. the port is out of service and in internal loopback. cells or frames arriving at the output port from the switch fabric get looped back through to the input port so they can return to the switch fabric. every input port function above the physical layer, e.g., header translation, runs on those looped back cells or frames. 🔁 - External Loopback:
Port Status = 4. the port is out of service and in external loopback. cells or frames arriving at the input port from the external link get looped straight back out to the link at the physical layer, without entering the input port. none of the input port functions above the physical layer run on them. 🪞 - Bothway Loopback:
Port Status = 5. the port is out of service and in both internal and external loopback. both at once, iconic 😭
the Port Status of the port the GSMP session controlling the switch is running over MUST be declared Available. the controller will ignore any other Port status for this port. and the Port Status of switch ports after power-on initialisation isn't defined by GSMP at all 🤷♀️
Line Type 🔌 the type of physical transmission interface for this port. the values come from the IANAifTypes defined in [17]. these are the ones for this version of the protocol:
PortType = Unknown: other(1)
PortType = MPLS: ethernetCsmacd(6),
ppp(23)
PortType = ATM: atm(37)
PortType = FR: frameRelayService(44)Line Status 📡 this is the status of the physical transmission medium connected to the port. the defined values are:
- Up:
Line Status = 1. the line can send and receive. when the Line Status changes to Up from either Down or Test, a new Port Session Number MUST be generated. ⬆️ - Down:
Line Status = 2. the line can't send, can't receive, or can't do either. 📉 - Test:
Line Status = 3. the port or line is in a test mode, for example, a power-on test. 🧪
Priorities 🥇 the number of different priority levels this output port can assign to connections. zero is invalid here. if an output port can support "Q" priorities, the highest priority is numbered zero and the lowest is numbered "Q-1". the ability to give different qualities of service to different connections based on priority is assumed to be a property of the output port. it can also be assumed that, for connections sharing the same output port, a cell or frame on a higher priority connection is much more likely to exit the switch first than one on a lower priority connection, if they're both in the switch at the same time. main character energy 👑
Physical Slot Number 🗂️ the physical location of the slot the port sits in. it's an unsigned 16-bit integer that can take any value except 0xFFFF, and 0xFFFF means "unknown". GSMP doesn't use it at all. it's there to help network management with logging, port naming, and graphical representation 📊
Physical Port Number 🔢 the physical location of the port within its slot. it's an unsigned 16-bit integer that can take any value except 0xFFFF, and 0xFFFF means "unknown". GSMP doesn't use this one either. it's also just for network management stuff like logging, port naming, and graphical representation 🌟
There MUST be a one to one mapping between the Port Number and the Physical Slot Number and Physical Port Number combination. two different Port Numbers MUST NOT yield the same Physical Slot Number and Physical Port Number combination. the same Port Number MUST yield the same Physical Slot Number and Physical Port Number within a single GSMP session. and if both Physical Slot Number and Physical Port Number say "unknown", you can figure out where the switch ports physically are by looking up the product identity in a database to see what the 32-bit Port Number means in real life. detective era 🕵️♀️✨
8.2.1.1 PortType Specific data for PortType=ATM 🦋
if PortType=ATM, the Default Label Range Block has this format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|V|x| ATM Label (0x100) | Label Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x| VPI | VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+V: Label 🏷️ if the Label flag is set, the message refers to a range of VPI's only. the Min VCI and Max VCI fields are unused. if the Label flag is zero, the message refers to a range of VCI's on either one VPI or a range of VPI's.
Min VPI 💜 the default minimum value of dynamically assigned incoming VPI that the connection table on the input port supports and that GSMP can control.
Max VPI 💜 the default maximum value of dynamically assigned incoming VPI that the connection table on the input port supports and that GSMP can control.
at power-on, after a hardware reset, and after the Reset Input Port function of the Port Management message, the input port MUST handle all values of VPI within the range Min VPI to Max VPI inclusive, and GSMP MUST be able to control all values within this range. it's worth noting that the range Min VPI to Max VPI only covers the incoming VPI range the associated port can support. there's no restriction on the outgoing VPI values that can be written into the cell header. and if the switch doesn't support virtual paths, it's acceptable for both Min VPI and Max VPI to specify the same value, most likely zero 🌸
using the Label Range message lets you change the range of VPI's the port supports. but the Min VPI and Max VPI fields in the Port Configuration and All Ports Configuration messages always report the same default values, no matter what the Label Range message did 🙃
Min VCI 🌙 the default minimum value of a dynamically assigned incoming VCI that the connection table on the input port can support and that GSMP can control. the Label Range message doesn't change this value.
Max VCI 🌙 the default maximum value of a dynamically assigned incoming VCI that the connection table on the input port can support and that GSMP can control.
at power-on, after a hardware reset, and after the Reset Input Port function of the Port Management message, the input port MUST handle all values of VCI within the range Min VCI to Max VCI inclusive, for each of the virtual paths in the range Min VPI to Max VPI inclusive, and GSMP MUST be able to control all values within this range. the range Min VCI to Max VCI only covers the incoming VCI range the associated port can support on each of the virtual paths in the range Min VPI to Max VPI. there's no restriction on the outgoing VCI values that can be written into the cell header. the Label Range message lets you change the range of VCI's on each VPI the port supports. but the Min VCI and Max VCI fields in the Port Configuration and All Ports Configuration messages always report the same default values, regardless of the Label Range message 🫶
the VCI of the GSMP control channel on a port where GSMP is running may or may not be reported as lying within the range Min VCI to Max VCI. and a switch should honour a connection request message that specifies the GSMP control channel's VCI value, even if that value lies outside the range Min VCI to Max VCI. 🔥
8.2.1.2. PortType Specific data for PortType=FR
okay so if PortType=FR 🎀, the Default Label Range Block looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| FR Label (0x101) | Label Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x|Res|Len| DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Res 🧚 The Res field is reserved in [21], i.e., it is not explicitly reserved by GSMP.
Len 💖 This field specifies the number of bits of the DLCI. The following values are supported:
Len DLCI bits
0 10
2 23Min DLCI, Max DLCI ✨ These specify a range of DLCI values, from Min DLCI to Max DLCI inclusive. The values SHOULD be right justified in the 23-bit fields and the preceding bits SHOULD be set to zero. A single DLCI may be specified with a Min DLCI and a Max DLCI having the same value. In a request message, if the value of the Max DLCI field is less than or equal to the value of the Min DLCI field, the requested range is a single DLCI with a value equal to the Min DLCI field. Zero is a valid value 🫶
8.2.1.3. PortType Specific data for PortType=MPLS
bestie, this is the Default Label Range Block for PortTypes using MPLS labels 🌈 These labels are for use on links where label values are independent of the underlying link technology. Examples of such links are PPP and Ethernet. On those links the labels are carried in MPLS label stacks [14]. Ports of the Type MPLS look like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x| MPLS Gen Label (0x102)| Label Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x|x|x|x|x| MPLS Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Min MPLS Label, Max MPLS Label 🦋 These specify a range of MPLS label values, from Min MPLS Label to Max MPLS Label inclusive. The Max and Min MPLS label fields are 20 bits each.
8.2.1.4. PortType Specific data for PortType=FEC
ngl this one is kinda chill 😌 The Default Label Range Block for PortTypes using FEC labels is not used. The Label Range Count and Label Range Length fields defined in [8.2.1] should be set to 0.
8.3. All Ports Configuration Message
the All Ports Configuration message asks the switch for the configuration info of all of its ports 👑 It is:
Message Type = 66The Port field is not used in the request message 🙈
The All Ports Configuration success response message has this format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x x x x x x x x x| Number of Records |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Port Records ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Note: the fields and parameters already explained in the general messages aren't explained again here, so peep section 3.1 for the details 🔍
Number of Records 💅 This field gives the total number of Port Records to be returned in response to the All Ports Configuration request message. The number of port records in a single All Ports Configuration success response MUST NOT cause the packet length to exceed the maximum transmission unit defined by the encapsulation. If a switch has more ports than can fit in a single success response message, it MUST send multiple success response messages. All success response messages sent in response to the same request message MUST have the same Transaction Identifier as the request message and the same value in the Number of Records field. All success response messages sent in response to the same request message, except for the last message, MUST have the result field set to "More". The last message, or a single success response message, MUST have the result field set to "Success". All Port records within a success response message MUST be complete, i.e., a single Port record MUST NOT be split across multiple success response messages. ✨ no cap, this part is very strict
Port Records 🍓 These follow in the remainder of the message. Each port record has this format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Flags | Port Attribute Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PortType |S|x|x|x|x|x|x|x| Data Fields Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ PortType Specific Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x x x x x x x x x| Number of Service Specs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Service Specs List ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The definition of the fields in the Port Record is exactly the same as that of the Port Configuration message [section 8.2] 🦋💜
8.4. Service Configuration Message ✨
okay so the Service Configuration message is how you ask the switch "hey, what Services can you actually do?" 💅 It's Message Type = 67 🦋
Message Type = 67The success response looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x x x x x x x x x| Number of Service Records |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Service Records ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Quick heads-up 🫶: fields and parameters that were already explained in the general messages are NOT re-explained here, so for those, jump back to section 3.1.
Number of Service Records 🍓 This field tells you the total number of Service Records coming back in the Service Records field.
Service Records 🌸 This is a sequence of zero or more Service Records. The switch returns one Service Record for each Service it supports on any of its ports, and each Service Record holds the configuration data for that specific Service. Each one looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service ID | Number of Cap. Set. Records |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Capability Set Records ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Service ID 🧚 This identifies which Service the port supports. Services are defined with their Service ID values in section 10.2.
Number of Cap. Set. Records 💜 This is the total number of Capability Set Records that get returned in the Service Record field.
Capability Set Records 👑 The switch returns one or more Capability Set Records in each Service Record. A Capability Set is basically a bundle of parameters that describe the QoS parameter values and traffic controls that apply to one instance of the Service. Each Capability Set record looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cap. Set ID | Traffic Controls |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CLR | CTD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frequency | CDV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Capability Set ID 🎀 This value is a Capability Set ID supported by the switch. The switch assigns these values itself, then uses them in Port Configuration messages to point at the Capability Sets each individual port supports. Each Capability Set Record within a Service Record MUST have a unique Capability Set ID. No copy-paste IDs, bestie 🙈
Traffic Controls 🔥 This field tells you which Traffic Controls are available within the Capability Set. Traffic Controls are defined as part of each Service definition, so check Chapter 10 for the details. Some or all of them might be undefined for a given Service, and in that case the controller just ignores the matching Flag. The Traffic Controls field gets split up into Traffic Control Sub-fields like this:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| U | D | I | E | S | V |x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Each Traffic Control Sub-field uses this encoding:
0b00 Traffic Control is not available in the Capability Set.
0b01 Traffic Control is applied to all connections that use the
Capability Set.
0b10 Traffic Control is available to be applied to connections that
use the Capability Set, on a per connection basis.
0b11 ReservedNow the sub-fields themselves 💅:
- U: Usage Parameter Control 🌈 This one tells you whether Usage Parameter Control is available for the specified Service and Capability Set.
- D: Packet Discard 🌸 This one tells you whether Packet Discard is available for the specified Service and Capability Set.
- I: Ingress Shaping 🦋 This one tells you whether Ingress Traffic Shaping to the Peak Cell Rate and Cell Delay Variation Tolerance is available for the specified Service and Capability Set.
- E: Egress Shaping, Peak Rate ✨ This one tells you whether Egress Shaping to the Peak Cell Rate and Cell Delay Variation Tolerance is available for the specified Service and Capability Set.
- S: Egress Traffic Shaping, Sustainable Rate 🍓 If this one is set, it means Egress Traffic Shaping to the Sustainable Cell Rate and Maximum Burst Size is available for the specified Service and Capability Set.
- V: VC Merge 💜 This one tells you whether ATM Virtual Channel Merge is available for the specified Service and Capability Set. That's multipoint to point ATM switching with a traffic control that stops AAL5 PDU interleaving, which is honestly iconic 👑
QoS Parameters 🧚 The remaining four fields in the Capability Set Record hold the values of the QoS Parameters. QoS Parameters are defined as part of each Service definition, so check Chapter 9.6 for those. Some or all of them might be undefined for a given Service, and then the controller ignores the corresponding field.
- CLR: Cell Loss Ratio 🎀 This is the CLR the switch guarantees for the specified Service. The cell loss ratio is written as an order of magnitude n, where the CLR equals ten raised to the power of -n, so log(CLR)=-n. The value n is a binary integer in the range
1 <= n <= 15. And the value0b1111 1111means the switch gives no CLR guarantees at all 🙈 - Frequency 🔥 This is an 8 bit unsigned integer. It applies to the MPLS CR-LDP Service (see Section 10.4.3). The valid values are:
0 - Very frequent
1 - Frequent
2 - Unspecified- CTD: Cell Transfer Delay 🌈 The CTD value is in microseconds and is coded as a 24-bit integer ⭐
- CDV: Peak-to-peak Cell Delay Variation 🦋 The CDV value is also in microseconds and is coded as a 24-bit integer 💖
9. Event Messages ✨
okay so event messages are how the switch lets the controller know about certain asynchronous events 🫶 by default the controller doesn't acknowledge them unless ReturnReceipt is set in the Result field 💅 the Code field only gets used in an Adjacency Update message, otherwise it's not used and SHOULD be set to zero. event messages are not sent during initialisation 🌸 they look like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Note: Fields and Parameters that have been explained in the description of the general messages won't be explained again in this section. Please refer to section 3.1 for details.
Event Sequence Number This is the current value of the Event Sequence Number for the specified port 🔢 it's set to zero when the port is initialised, and it goes up by one each time the port detects an asynchronous event that the switch would normally report via an Event message. The Event Sequence Number MUST be incremented each time an event occurs, even if the switch is stopped from sending an Event message because of flow control 🚫
Label This field gives the Label that the event message refers to 🏷️ if the event message doesn't need this field, it's set to zero.
Each switch port MUST maintain an Event Sequence Number and a set of Event Flags, with one Event Flag for each type of Event message 🧠 when a switch sends an Event message, it MUST set the Event Flag for that port that matches the Event type. If Flow Control is activated for this Event type on this Port, then the switch MUST NOT send another Event message of the same type for that port until the Event Flag has been reset. Event Flags get reset by the "Reset Event Flags" function of the Port Management message 🧹 this is a simple flow control that stops the switch from flooding the controller with event messages 🌊 the Event Sequence Number of the port MUST be incremented every time an event is detected on that port, even if the port is prevented from reporting the event because of flow control. This lets the controller figure out that it missed some events on the port because of flow control 🕵️♀️
9.1 Port Up Message
The Port Up message tells the controller that the Line Status of a port has changed from either the Down or Test state to the Up state 🟢 when the Line Status of a switch port changes to the Up state from either the Down or Test state, a new Port Session Number MUST be generated, preferably using some form of random number. The new Port Session Number goes in the Port Session Number field. The Label field isn't used and is set to zero. The Port Up message is:
Message Type = 80
9.2 Port Down Message
The Port Down message tells the controller that the Line Status of a port has changed from the Up state or Test state to the Down state 📉 this message will be sent to report link failure if the switch is capable of detecting link failure. The port session number that was valid before the port went down is reported in the Port Session Number field. The Label field isn't used and is set to zero. The Port Down message is:
Message Type = 81
9.3 Invalid Label Message
The Invalid Label message is sent to tell the controller that one or more cells or frames have arrived at an input port with a Label that isn't currently allocated to an assigned connection 🚨 the input port is shown in the Port field, and the Label is shown in the Label field. The Invalid Label message is:
Message Type = 82
9.4 New Port Message
The New Port message tells the controller that a new port has been added to the switch 🎉 the port number of the new port goes in the Port field. A new Port Session Number MUST be assigned, preferably using some form of random number. The new Port Session Number goes in the Port Session Number field. The state of the new port is undefined, so the Label field isn't used and is set to zero. The New Port message is:
Message Type = 83
9.5 Dead Port Message
The Dead Port message tells the controller that a port has been removed from the switch 🪦 the port number of that port goes in the Port field. The Port Session Number that was valid before the port was removed is reported in the Port Session Number field. The Label fields aren't used and are set to zero. The Dead Port message is:
Message Type = 84
9.6 Adjacency Update Message
The Adjacency Update message tells the controller when adjacencies, i.e., other controllers controlling a specific partition, are joining or leaving 🤝 when a new adjacency has been established, the switch sends an Adjacency Update message to every controller with an established adjacency to that partition. The Adjacency Update message is also sent when an adjacency is lost between the partition and a controller, as long as there are any remaining adjacencies with that partition. The Code field is used to show the number of adjacencies known by the switch partition. The Label field isn't used and SHOULD be set to zero. The Adjacency Update message is:
Message Type = 85
10. Service Model Definition 💜
10.1 Overview
in the GSMP Service Model, a controller can ask the switch to set up a connection with a given Service 🎀 the requested Service is identified by including a Service ID in the Add Branch message or the Reservation Message. The Service ID points to a Service Definition given in this chapter of the GSMP specification.
A switch that implements one or more of the Services, as defined below, advertises that these Services are available in the Service Configuration message response (see Section 8.4) ✨ details of the switch's implementation of a given Service that matter to the controller (for example, the value of delay or loss bounds, or whether traffic controls such as policers or shapers are available) are reported as a Capability Set in the Service Configuration message response 📊
So a switch's implementation of a Service is defined in two parts 🧩 the Service Definition, which is part of the GSMP specification, and the Capability Set, which describes attributes of the Service that are specific to the switch. A switch can support more than one Capability Set for a given Service. For example, if a switch supports one Service with two different values of a delay bound, it could do this by reporting two Capability Sets for that Service 🙌
The Service Definition is identified in GSMP messages by the Service ID, a sixteen-bit identifier. Assigned numbers for the Service ID are given with the Service Definitions in Section 10.4. The Capability Set is identified in GSMP messages by the Capability Set ID, a sixteen-bit identifier. Numbers for the Capability Set ID are assigned by the switch and are advertised in the Service Configuration message response 🔖
The switch reports all its supported Services and Capability Sets in the Service Configuration message response 📣 the subset of Services and Capability Sets supported on an individual port is reported in the Port Configuration message response or in the All Ports Configuration message response. In these messages, the Services and Capability Sets supported on the specified port are shown as a list of {Service ID, Capability Set ID} number pairs 💖
10.2 Service Model Definitions
Terms and objects defined for the GSMP Service Model are given in this section 📖
10.2.1 Original Specifications
Services in GSMP are mostly defined by reference to Original Specifications, i.e., the standards or implementation agreements published by organisations such as ITU-T, IETF, and ATM Forum that first defined the Service 🏛️ this version of GSMP refers to 4 original specifications: [8], [9], [10] and [11].
10.2.2 Service Definitions
Each Service Definition in GSMP includes a definition of:
- Traffic Parameters Traffic Parameter definitions are associated with Services, while Traffic Parameter values are associated with connections 📏
Traffic Parameters describe quantitatively a connection's requirements on the Service. For example, Peak Cell Rate is a Traffic Parameter of the Service defined by the ATM Forum Constant Bit Rate Service Category.
Some Traffic Parameters are mandatory and some are optional, depending on the Service.
Semantics of Traffic Parameters are defined by reference to Original Specifications.
- QoS Parameters QoS Parameters and their values are associated with Services ⭐
QoS Parameters express quantitative characteristics of a switch's support of a Service. They include, for example, quantitative bounds on switch-induced loss and delay.
Some QoS Parameters will be mandatory and some will be optional.
Semantics of QoS Parameters are defined by reference to Original Specifications.
- Traffic Controls The implementation of some Services may include the use of Traffic Controls 🎛️ Traffic Controls include, for example, functions such as policing, input shaping, output shaping, tagging and marking, frame vs. cell merge, and frame vs. cell discard.
Switches are not required to support Traffic Controls. Any function that is always required in the implementation of a Service is considered part of the Service and is not considered a Traffic Control 💅
If a switch supports a Traffic Control, then the control may be applied either to all connections that use a given Capability Set (see below) or to individual connections.
The definition of a Traffic Control is associated with a Service. Traffic Controls are defined, as far as possible, by reference to Original Specifications. 🫶
10.2.3. Capability Sets ✨
okay bestie, so for every Service a switch supports, the switch MUST also support at least one Capability Set 💅. A Capability Set basically sets the vibe for how the switch implements that Service. It may be appropriate for a switch to support more than one Capability Set for a given Service 🦋.
A Capability Set may contain, depending on the Service definition, QoS Parameter values and an indication of availability of Traffic Controls 🎀.
If a switch reports QoS Parameter values in a Capability Set, then those values apply to all the connections that use that Capability Set 🫶.
For each Traffic Control defined for a given Service, the switch reports availability of that control as one of the following:
- Not available in the Capability Set,
- Applied to all connections that use the Capability Set, or
- Available for application to connections that use the Capability Set on a per connection basis. In this case, a controller may request application of the Traffic Control in connection management messages.
10.3. Service Model Procedures 🌸
okay so a switch's Services and Capability Sets get reported to a controller in a Service Configuration message 📨. A Service Configuration message response includes the list of Services defined for GSMP that the switch supports and, for each Service, a specification of the Capability Sets supported for that Service. Services are referred to by numbers standardised in the GSMP specification. Capability Sets are referred to by a numbering system reported by the switch. Each Capability Set within a given Service includes a unique identifying number, together with the switch's specification of QoS Parameters and Traffic Controls 🧚.
A switch need not support all the defined Services and Capability Sets on every port. The supported Services and Capability Sets are reported to the controller on a per port basis in port configuration messages. Port configuration response messages list the supported Services using the standardised identifying numbers, and the Capability Sets by using the identifying numbers established in the switch Service configuration messages 💜.
GSMP does not provide a negotiation mechanism by which a controller may establish or modify Capability Sets. no negotiating, just vibes 🙅♀️
When a controller establishes a connection, the connection management message includes an indication of the Service and the Capability Set. Depending on these, the connection management message may additionally include Traffic Parameter values and Traffic Control flags 🌈.
A connection with a given Service can only be established if both the requested Service and the requested Capability Set are available on all of the connection's input and output ports. Main character energy means checking every port first 👑
Refresh of an extant connection is permitted, but the add branch message requesting the refresh MUST NOT include indication of Service, Capability Sets or Traffic Parameters 🙈.
An extant connection's Traffic Parameters may be changed without first deleting the connection. The Service and Capability Sets of an extant connection cannot be changed 💖.
Move branch messages may be refused on the grounds of resource depletion 😭.
10.4. Service Definitions 👑
okay this section is where the Services get defined, and it's giving full catalogue 📚. The following Service Identifiers are defined:
ID Service Type
1 CBR= 1
2 rt-VBR.1
3 rt-VBR.2
4 rt-VBR.3
5 nrt-VBR.1
6 nrt-VBR.2
7 nrt-VBR.3
8 UBR.1
9 UBR.2
10-11 Reserved
12 GFR.1
13 GFR.2
14-19 Reserved
20 Int-Serv Controlled Load
21-24 Reserved
25 MPLS CR-LDP QoS
26-29 Reserved
30 Frame Relay Service
31-49 Reserved
50-69 Reserved GMPLS
70-65535 ReservedEach Service will be defined in its own subsection. Each Service definition includes the following definitions:
- Service Identifier: the reference number used to identify the Service in GSMP messages.
- Service Characteristics: a definition of the Service.
- Traffic Parameters: a definition of the Traffic Parameters used in connection management messages.
- QoS Parameters: a definition of the QoS Parameters that are included in the Capability Set for instances of the Service.
- Traffic Controls: a definition of the Traffic Controls that may be supported by an instance of the Service.
Descriptive text is avoided wherever possible, in order to minimise any possibility of semantic conflict with the Original Specifications. we don't want any vibes-based misunderstandings here 🫶
10.4.1. ATM Forum Service Categories 🦋
10.4.1.1. CBR 💅
Service Identifier:
- CBR.1 - Service ID = 1
Service Characteristics:
- Equivalent to ATM Forum CBR.1 Service, see [8].
Traffic Parameters:
- Peak Cell Rate
- Cell Delay Variation Tolerance
QoS Parameters:
- Cell Loss Ratio
- Maximum Cell Transfer Delay
- Peak-to-peak Cell Delay Variation
Traffic Controls:
- (U) Usage Parameter Control
- (I) Ingress Traffic Shaping to the Peak Cell Rate
- (E) Egress Traffic Shaping to the Peak Cell Rate and Cell Delay Variation Tolerance
- (D) Packet Discard
10.4.1.2. rt-VBR 🎀
Service Identifier:
- rt-VBR.1 - Service ID = 2
- rt-VBR.2 - Service ID = 3
- rt-VBR.3 - Service ID = 4
Service Characteristics:
- Equivalent to ATM Forum rt-VBR Service, see [8].
Traffic Parameters:
- Peak Cell Rate
- Cell Delay Variation Tolerance
- Sustainable Cell Rate
- Maximum Burst Size
QoS Parameters:
- Cell Loss Ratio
- Maximum Cell Transfer Delay
- Peak-to-peak Cell Delay Variation
Traffic Controls:
- (U) Usage Parameter Control
- (I) Ingress Traffic Shaping to the Peak Cell Rate
- (E) Egress Traffic Shaping to the Peak Cell Rate and Cell Delay Variation Tolerance
- (S) Egress Traffic Shaping to the Sustainable Cell Rate and Maximum Burst Size
- (P) Packet Discard
- (V) VC Merge
10.4.1.3. nrt-VBR 🧚
Service Identifier:
- nrt-VBR.1 - Service ID = 5
- nrt-VBR.2 - Service ID = 6
- nrt-VBR.3 - Service ID = 7
Service Characteristics:
- Equivalent to ATM Forum nrt-VBR Service, see [8].
Traffic Parameters:
- Peak Cell Rate
- Cell Delay Variation Tolerance
- Sustainable Cell Rate
- Maximum Burst Size
QoS Parameter:
- Cell Loss Ratio
Traffic Controls:
- (U) Usage Parameter Control
- (I) Ingress Traffic Shaping to the Peak Cell Rate
- (E) Egress Traffic Shaping to the Peak Cell Rate and Cell Delay Variation Tolerance
- (S) Egress Traffic Shaping to the Sustainable Cell Rate and Maximum Burst Size
- (P) Packet Discard
- (V) VC Merge
10.4.1.4. UBR 🌸
Service Identifier:
- UBR.1 - Service ID = 8
- UBR.2 - Service ID = 9
Service Characteristics:
- Equivalent to ATM Forum UBR Service, see [8].
Traffic Parameters:
- Peak Cell Rate
- Cell Delay Variation Tolerance
QoS Parameter:
- None
Traffic Controls:
- (U) Usage Parameter Control
- (I) Ingress Traffic Shaping to the Peak Cell Rate
- (E) Egress Traffic Shaping to the Peak Cell Rate and Cell Delay Variation Tolerance
- (P) Packet Discard
- (V) VC Merge
10.4.1.5. ABR 🙅♀️
ABR is not supported in this version of GSMP. sorry ABR, not this time 💔
10.4.1.6. GFR 🌈
Service Identifier:
- GFR.1 - Service ID = 12
- GFR.2 - Service ID = 13
Service Characteristics:
- Equivalent to ATM Forum GFR Service, see [8].
Traffic Parameters:
- Peak Cell Rate
- Cell Delay Variation Tolerance
- Minimum Cell Rate
- Maximum Burst Size
- Maximum Frame Size
QoS Parameter:
- Cell Loss Ratio
Traffic Controls:
- (U) Usage Parameter Control
- (I) Ingress Traffic Shaping to the Peak Cell Rate
- (E) Egress Traffic Shaping to the Peak Cell Rate and Cell Delay Variation Tolerance
- (V) VC Merge
10.4.2. Integrated Services 🫧
10.4.2.1. Controlled Load 💖
Service Identifier:
- Int-Serv Controlled Load - Service ID = 20
Service Characteristics:
- See [9].
Traffic Parameters:
- Token bucket rate (r)
- Token bucket depth (b)
- Peak rate (p)
- Minimum policed unit (m)
- Maximum packet size (M)
QoS Parameter:
- None.
Traffic Controls:
- None.
10.4.3. MPLS CR-LDP ⭐
Service Identifier:
- MPLS CR-LDP QoS - Service ID = 25
Service Characteristics:
- See [10].
Traffic Parameters:
- Peak Data Rate
- Peak Burst Size
- Committed Data Rate
- Committed Burst Size
- Excess Burst Size
- Weight
QoS Parameter:
- Frequency
Traffic Controls:
- None currently defined.
10.4.4. Frame Relay 🍓
Service Identifier:
- Frame Relay Service - Service ID = 30
Service Characteristics:
- Equivalent to Frame Relay Bearer Service, see [11].
Traffic Parameters:
- Committed Information Rate
- Committed Burst Rate
- Excess Burst Rate
QoS Parameters:
- None.
Traffic Controls:
- Usage Parameter Control
- Egress Traffic Shaping to the Committed Information Rate and Committed Burst Size
10.4.5. DiffServ 🔥
DiffServ is not supported in this version of GSMP. not today, DiffServ 😔
10.5. Format and encoding of the Traffic Parameters 🎀
okay so connection management messages that use the GSMP Service Model (i.e., those that have IQS or OQS set to 0b10) include the Traffic Parameters Block that specifies the Traffic Parameter values of a connection 📦. The required Traffic Parameters of a given Service are given in Section 10.4. The format and encoding of these parameters are given below ✨.
10.5.1. Traffic Parameters for ATM Forum Services 💅
The Traffic Parameters:
- Peak Cell Rate
- Cell Delay Variation Tolerance
- Sustainable Cell Rate
- Maximum Burst Size
- Minimum Cell Rate
- Maximum Frame Size
are defined in [8]. These Parameters are encoded as 24-bit unsigned integers. Peak Cell Rate, Sustainable Cell Rate, and Minimum Cell Rate are in units of cells per second. Cell Delay Variation Tolerance is in units of microseconds. Maximum Burst Size and Maximum Frame Size are in units of cells. In GSMP messages, the individual Traffic Parameters are encoded as follows 🧮:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x| 24 bit unsigned integer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The format of the Traffic Parameters Block in connection management messages depends on the Service. It is a sequence of the 32 bit words (as shown above) corresponding to the Traffic Parameters, as specified in the Service Definitions given in Section 10.4.1, in the order given there 🦋
10.5.2. Traffic Parameters for Int-Serv Controlled Load Service 🎀
okay so the Controlled Load traffic params are defined in [9] 💖 and there are three of them:
- Token bucket rate (r)
- Token bucket size (b)
- Peak rate (p)
they get encoded as 32-bit IEEE single-precision floating point numbers ✨. The token bucket rate (r) and peak rate (p) are measured in bytes per second, and the token bucket size (b) is measured in bytes 🦋
then there's a second set, also defined in [9] 🌸:
- Minimum policed unit (m)
- Maximum packet size (M)
these are encoded as 32 integer, measured in bytes 🧚
here's how the whole Traffic Parameters Block for Int-Serv Controlled Load Service lays out 👑
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token bucket rate (r) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token bucket size (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak rate (p) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum policed unit (m) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum packet size (M) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+10.5.3. Traffic Parameters for CRLDP Service 💅
for CRLDP, the traffic params are defined in [10] and encoded as a 32-bit IEEE single-precision floating point number 🔥. there are five of them:
- Peak Data Rate
- Peak Burst Size
- Committed Data Rate
- Committed Burst Size
- Excess Burst Size
the positive infinity value is a special vibe: an exponent of all ones (255), with the sign and mantissa all zeros 🌈. Peak Data Rate and Committed Data Rate are in bytes per second, and Peak Burst Size, Committed Burst Size and Excess Burst Size are in bytes 💜
there's also a Weight parameter, defined in [10] as an 8-bit unsigned integer that tells you the weight of the CRLSP ✨. valid weight values run from 1 to 255, and a value of 0 means weight is not applicable for the CRLSP 🙈
the Traffic Parameters Block for the CRLDP Service looks like this 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Burst Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Data Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Burst Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Excess Burst Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x x x x x x x x x x x x x x x x x| Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+10.5.4. Traffic Parameters for Frame Relay Service 🌸
the Frame Relay params are defined in [11] ✨, and the format and encoding for these params in frame relay signalling messages are defined in [12] 🧚. quick heads-up: in [12], the Committed Information Rate is called "Throughput" 👀. GSMP uses the encoding from [12] but with a different format 💅
the Traffic Parameters Block for Frame Relay Service is laid out like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x x x x x x| Mag |x x x x x| CIR Multiplier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x x x x x x| Mag |x x| CBS Multiplier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x x x x x x| Mag |x x| EBS Multiplier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the fields, bestie 🫶
- Mag: an unsigned integer from 0 to 6. The value 7 is not allowed 🙈 Mag is the decimal exponent for the adjacent multiplier field, which itself works as a mantissa 🔥
- CIR Multiplier: an unsigned integer that works as the mantissa of the Committed Information Rate Traffic Parameter 💖
- CBS Multiplier and EBS Multiplier: both unsigned integers. They work as the mantissas of the Committed Burst Size and Excess Burst Size Traffic Parameters respectively 🌈
and here's how the Traffic Parameter Values relate to their encoding in GSMP messages 🦋
Committed Information Rate = 10^(Mag) * (CIR Multiplier)
Committed Burst Size = 10^(Mag) * (CBS Multiplier)
Excess Burst Size = 10^(Mag) * (EBS Multiplier)10.6. Traffic Controls (TC) Flags 🍓
okay, this one is the main character of the section 👑 The TC Flags field in Add Branch messages, for connections using the Service Model, is set by the controller to say which specific traffic controls are requested for the requested connection 💜 Here's the field:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|U|D|I|E|S|V|P|x|
+-+-+-+-+-+-+-+-+and here's what each flag means ✨
- U: Usage Parameter Control. When set, this flag indicates that Usage Parameter Control is requested.
- D: Packet Discard. When set, this flag indicates that Packet Discard is requested.
- I: Ingress Shaping. When set, this flag indicates the availability of Ingress Traffic Shaping to the Peak Rate and Delay Variation Tolerance is requested.
- E: Egress Shaping, Peak Rate. When set, this flag indicates that Egress Shaping to the Peak Rate and Delay Variation Tolerance is requested.
- S: Egress Traffic Shaping, Sustainable Rate. When set, this flag indicates that Egress Traffic Shaping to the Sustainable Rate and Maximum Burst Size is requested.
- V: VC Merge. When set, this flag indicates that ATM Virtual Channel Merge (i.e., multipoint to point ATM switching with a traffic control to avoid AAL5 PDU interleaving) is requested.
- P: Port. When set, indicates that the traffic block pertains to the Ingress Port 🧚
- x: Reserved 🙈
now the important bit 🔥 The controller may set (to one) the flag for the requested Traffic Control, but only if that Traffic Control has been indicated in the Service Configuration response message (Section 8.4) as available for application to connections that use the requested Capability Set on a per connection basis. (The requested Capability Set is indicated by the Capability Set ID, the least significant byte of the Service Selector field of the Add Branch message 🌸) If the Traffic Control has been indicated in the Service Configuration response message as either not available in the Capability Set, or applied to all connections that use the Capability Set, then the controller sets the flag to zero and the switch ignores the flag 💀
11. Adjacency Protocol 🌈
the adjacency protocol is the behind-the-scenes friend that keeps everything in sync 🫶 It's used to synchronise state across the link, agree on which version of the protocol to use, discover the identity of the entity at the other end of the link, and notice when that identity changes 👑
GSMP is a hard state protocol, which means it's super important to detect loss of contact between switch and controller, and to catch any change of identity of the switch or controller 😭 No GSMP messages other than the ones from the adjacency protocol may be sent across the link until the adjacency protocol has achieved synchronisation ✨
11.1. Packet Format ✨
okay so every single GSMP message in the adjacency protocol comes in this exact shape, no exceptions 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Timer |M| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Name |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Receiver Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PType | PFlag | Sender Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Receiver Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Version
the Version field is the star of version negotiation 🎀 and that all happens before synchronisation is achieved. In a SYN message, Version always holds the highest version the sender understands. If a receiver gets a SYN with a version higher than it understands, it will ignore that message. If a receiver gets a SYN with a version lower than its own highest version (but one it does understand), it replies with a SYNACK that carries the version from the received SYN in its GSMP Version field. That's the version of GSMP the adjacency protocol uses while it stays synchronised. Everything else just uses the agreed version in the Version field, so it's giving consistency 🦋
The version number for the version of GSMP defined in this specification is:
Version = 3Message Type
the adjacency protocol has its own message type, and it's:
Message Type = 10Timer
the Timer field tells the receiver what timer value the sender is using in the adjacency protocol. It's the nominal time between periodic adjacency protocol messages, and it stays constant for the whole GSMP session 🌸 The timer is measured in units of 100ms.
M-Flag
the M-Flag is how a SYN tells you whether the sender is a master or a slave. Set means master, zero means slave. GSMP is asymmetric, with the controller as the master and the switch as the slave, and this flag is what stops a master from syncing with another master (or a slave with another slave) 🙅♀️ So, if a slave gets a SYN with a zero M-Flag, it MUST ignore that SYN message. If a master gets a SYN with the M-Flag set, it MUST ignore that SYN message too. In all other messages the M-Flag isn't used at all.
Code
the Code field says what the message is actually doing. There are four adjacency protocol codes:
SYN: Code = 1
SYNACK: Code = 2
ACK: Code = 3
RSTACK: Code = 4Sender Name
for SYN, SYNACK, and ACK messages, this is the name of the entity sending the message. It's a 48-bit quantity that has to be unique within the device's operational context. a 48-bit IEEE 802 MAC address can be used here if one's available 🧚 If Ethernet encapsulation is in use, the Sender Name MUST be the Source Address from the MAC header. For RSTACK, the Sender Name is copied from the Receiver Name of the incoming message that triggered the RSTACK.
Receiver Name
for SYN, SYNACK, and ACK messages, this is the name the sender thinks is at the far end of the link. If the sender doesn't know that name, this field SHOULD be set to zero. For RSTACK, the Receiver Name is copied from the Sender Name of the incoming message that triggered it. 💜
Sender Port
for SYN, SYNACK, and ACK messages, this is the local port number of the link the message is going out on. For RSTACK, the Sender Port is copied from the Receiver Port of the incoming message that caused the RSTACK.
Receiver Port
for SYN, SYNACK, and ACK messages, this is what the sender believes its local port number is, as allocated by the entity at the far end. If the sender doesn't know the far-end port number, this field SHOULD be set to zero. For RSTACK, the Receiver Port is copied from the Sender Port of the incoming message that caused it.
PType
PType decides whether partitions are used and how the Partition ID gets negotiated. The values are:
0 No Partition
1 Fixed Partition Request
2 Fixed Partition AssignedPFlag
PFlag tells you what kind of partition request this is:
1 - New Adjacency.
In the case of a new adjacency, the state of the
switch will be reset.
2 - Recovered Adjacency.
In the case of a recovered adjacency, the state of
the switch will remain, and the Switch Controller
will be responsible for confirming that the state
of the switch matches the desired state.Sender Instance
for SYN, SYNACK, and ACK messages, this is the sender's instance number for the link. It's how you can tell when a link comes back up after going down, or when the entity on the other end changes 👑 It's a 24-bit number, guaranteed unique within the recent past, and it changes when the link or node comes back after going down. Zero is not a valid instance number. For RSTACK, the Sender Instance is copied from the Receiver Instance of the message that caused it.
Partition ID
this field links the message to a specific switch partition. ✨
Receiver Instance
for SYN, SYNACK, and ACK messages, this is what the sender believes the current instance number for the link is, as allocated by the far end. If the sender doesn't know the far-end instance number, this field SHOULD be set to zero. For RSTACK, the Receiver Instance is copied from the Sender Instance of the message that caused it.
11.2. Procedure 🦋
okay now the rules. the adjacency protocol is described by the following rules and state tables, and they're kind of the whole plot, so pay attention bestie 🫶
the rules and state tables use these operations:
- The "Update Peer Verifier" operation means storing the values of the Sender Instance, Sender Port, Sender Name and Partition ID fields from a SYN or SYNACK message received from the entity at the far end of the link.
- The procedure "Reset the link" goes like this:
- Generate a new instance number for the link
- Delete the peer verifier (set to zero the values of Sender Instance, Sender Port, and Sender Name previously stored by the Update Peer Verifier operation)
- Send a SYN message
- Enter the SYNSENT state.
- The state tables use these Boolean terms and operators:
A: The Sender Instance in the incoming message matches the value stored from a previous message by the "Update Peer Verifier" operation.B: The Sender Instance, Sender Port, Sender Name and Partition ID fields in the incoming message match the values stored from a previous message by the "Update Peer Verifier" operation.C: The Receiver Instance, Receiver Port, Receiver Name and Partition ID fields in the incoming message match the values of the Sender Instance, Sender Port, Sender Name and Partition ID currently sent in outgoing SYN, SYNACK, and ACK messages."&&"represents the logical AND operation."||"represents the logical OR operation."!"represents the logical negation (NOT) operation.
- A timer is required for the periodic generation of SYN, SYNACK, and ACK messages. The timer's value is announced in the Timer field. Its period is unspecified, but a value of one second is suggested.
there are two independent events, the timer expiring and a packet arriving 🔥 here's how each one gets processed:
Timer Expires: Reset Timer
If state = SYNSENT Send SYN
If state = SYNRCVD Send SYNACK
If state = ESTAB Send ACK
Packet Arrives:
If incoming message is an RSTACK:
If (A && C && !SYNSENT) Reset the link
Else discard the message.
If incoming message is a SYN, SYNACK, or ACK:
Response defined by the following State Tables.
If incoming message is any other GSMP message and
state != ESTAB:
Discard incoming message.
If state = SYNSENT Send SYN (Note 1)
If state = SYNRCVD Send SYNACK (Note 1)
Note 1: No more than two SYN or SYNACK messages should be sent
within any time period of length defined by the timer.state synchronisation across a link is considered achieved once the protocol reaches the ESTAB state. Until then, every GSMP message that isn't an adjacency protocol message and arrives before synchronisation gets discarded 🌈
11.2.1. State Tables ✨
State: SYNSENT 💖
+====================================================================+
| Condition | Action | New State |
+==================+=====================================+===========+
| SYNACK && C | Update Peer Verifier; Send ACK | ESTAB |
+------------------+-------------------------------------+-----------+
| SYNACK && !C | Send RSTACK | SYNSENT |
+------------------+-------------------------------------+-----------+
| SYN | Update Peer Verifier; Send SYNACK | SYNRCVD |
+------------------+-------------------------------------+-----------+
| ACK | Send RSTACK | SYNSENT |
+====================================================================+State: SYNRCVD 🦋
+====================================================================+
| Condition | Action | New State |
+==================+=====================================+===========+
| SYNACK && C | Update Peer Verifier; Send ACK | ESTAB |
+------------------+-------------------------------------+-----------+
| SYNACK && !C | Send RSTACK | SYNRCVD |
+------------------+-------------------------------------+-----------+
| SYN | Update Peer Verifier; Send SYNACK | SYNRCVD |
+------------------+-------------------------------------+-----------+
| ACK && B && C | Send ACK | ESTAB |
+------------------+-------------------------------------+-----------+
| ACK && !(B && C) | Send RSTACK | SYNRCVD |
+====================================================================+State: ESTAB 🌸
+====================================================================+
| Condition | Action | New State |
+==================+=====================================+===========+
| SYN || SYNACK | Send ACK (note 2) | ESTAB |
+------------------+-------------------------------------+-----------+
| ACK && B && C | Send ACK (note 3) | ESTAB |
+------------------+-------------------------------------+-----------+
| ACK && !(B && C) | Send RSTACK | ESTAB |
+====================================================================+Okay so, the ESTAB table has two notes that are super important, bestie 🧐
Note 2: okay so no more than two ACKs should be sent in any one timer period. That means one ACK MUST go out every time the timer expires 💅 You're also allowed to send one extra ACK between timer expirations, but only if the incoming message is a SYN or SYNACK. That bonus ACK helps the adjacency protocol hit synchronisation way faster. Iconic 🙌
Note 3: no more than one ACK should be sent in any timer period. Simple, but still very much a rule 🫶
11.3. Partition Information State 🎀
Each instance of a [switch controller-switch partition] pair will need to establish adjacency synchronisation independently. Every pair does its own thing, no shortcuts 🧚
Part of getting synchronised when you're using partitions is figuring out who gets which partition identifier. There are three scenarios covered:
- A controller can request a specific partition ID by setting the PType to Fixed Partition Request.
- A controller can let the switch decide whether it wants to assign a fixed partition ID or not, by setting the PType to No Partition.
- A switch can assign the specific Partition ID to the session by setting the PType to Fixed Partition Assigned. A switch can specify that no partitions are handled in the session by setting the PType to No Partition.
Here's how the assignment actually works 👑
- An adjacency message from a controller with
PType = 1andCode = SYNSHOULD be treated as a partition request. - An adjacency message from a switch with
PType = 2andCode = SYNSHOULD be treated as a partition assignment. - An adjacency message from a controller or a switch with
PType = 2andCode = (SYNACK || ACK)SHOULD be treated as a success response, and the partition is assigned. ✨ - An adjacency message from a controller with
PType = 0andCode = SYNmeans the controller hasn't said whether it wants partitions or not. 🤷♀️ - An adjacency message from a switch with
PType = 0andCode = SYNmeans the switch doesn't support partitions. - An adjacency message from a controller or a switch with
PType = 0andCode = (SYNACK || ACK)means the session doesn't support partitions. - An adjacency message from a controller or a switch with
PType = (1 || 2)andCode = RSTACKmeans the requested Partition ID is unavailable. 😭 - An adjacency message from a controller or a switch with
PType = 0andCode = RSTACKmeans some unidentified error happened. The session SHOULD be reset. 💀
All other combinations of PType and Code are undefined in this version of GSMP. Not your problem, not my problem, just undefined 🙈
11.4. Loss of Synchronisation 💔
So if synchronisation was achieved and then no valid GSMP messages show up for longer than three times the Timer value announced in the incoming adjacency protocol messages, loss of synchronisation may be declared. Oof 😬
While the switch is trying to re-establish synchronisation with a controller, it SHOULD keep its connection state. The decision about resetting that state gets postponed until synchronisation is back 🫂
Once synchronisation is re-established, the decision about the connection state SHOULD be made like this:
- If
PFLAG = 1, then a new adjacency has been established and the state SHOULD be reset. Fresh start, fresh vibes ✨ - If
PFLAG = 2, then adjacency has been re-established and the connection state SHOULD be retained. Verifying that the controller and connection state still match is the controller's job, not the switch's 💅
11.5. Multiple Controllers per switch partition 👯♀️
Multiple switch controllers may jointly control a single switch partition. They can do it primary/standby style, or as a group of controllers load-sharing the same partition. Keeping their interactions with the partition coordinated is the controllers' responsibility, not GSMP's 🫶 To help the controllers track all the adjacencies hitting one partition, the Adjacency Update message tells a controller that other controllers are interacting with the same partition.
It should be noted that GSMP doesn't have features that let the switch coordinate cache synchronization info across controllers. The switch partition services each command it gets in turn, as if it were only talking to one controller 🤖 So, controller implementations that don't do controller entity synchronisation SHOULD NOT use multiple controllers with a single switch partition. Please don't. 🙅♀️
11.5.1. Multiple Controller Adjacency Process 👑
The first adjacency for a specific partition is set up using the procedures in section 11.2, and then an Adjacency Update message gets sent. The next adjacencies to that partition show up as a new partition request with the same Partition ID as the first, but with a different Sender Name. Once adjacency is established, the Adjacency count goes up and another Adjacency Update message gets sent 📈
When adjacency between a partition and a controller is lost, the adjacency count goes down and an Adjacency Update message gets sent 📉
Example:
Picture a switch partition that's never been used 🍓 When the first controller (A) achieves adjacency, the adjacency count starts at 1 and (A) gets an Adjacency Update message about itself with Code field = 1. Since (A) sees an adjacency count of 1, it knows it's the only controller for that partition. Solo queen energy 👸
Now a second adjacency (B), using the same Partition ID, achieves adjacency. The counter goes up by 1. Both (A) and (B) get an Adjacency Update message showing an adjacency count of 2 in the Code field. Since the count is greater than 1, both of them know another controller is interacting with the switch. GSMP won't tell them who that other controller is, that's on the controllers to figure out 🕵️♀️
If (A) loses adjacency, the count goes down and an Adjacency Update message gets sent to (B) showing an adjacency count of 1 in the Code field. If (B) leaves too, the partition is considered idle and the adjacency count may be reset. Bye bye, partition 👋
12. Failure Response Codes 🌈
12.1. Description of Failure and Warning Response Messages ✨
okay so a failure response is basically the switch sending your request message right back 🔁 with the Result field in the header set to Result = 4, and the Code field telling you why it said no 🙅♀️. the code explains what stopped the switch from doing the thing you asked for 💀
a warning response is a success response (Result = 3) with a Code field that holds a warning code ⚠️. so it worked, but something came up while it was happening, and the code spills the tea on what it was 🍵
if the switch sends a failure response to a request, the switch's state should not change because of the message that caused the failure 🫶 (lowercase "should" here, so it's a soft vibe, not a hard rule). and for messages that bundle up multiple requests, like the Delete Branches message, the failure response tells you which requests worked and which didn't 🧾. the ones that worked might have changed the state, so no cap, read that part carefully 👀
now here's the big one 🚨 if the switch issues a failure response, it MUST pick the most specific failure code using this precedence order:
- Invalid Message
- General Message Failure
- Specific Message Failure: a failure response specified in the text defining the message type
- Connection Failures
- Virtual Path Connection Failures
- Multicast Failures
- QoS Failures
- General Failures
- Warnings
if more than one failure fits in any of the categories below, the one listed first should be returned 💅 (again lowercase, soft). here's the full list of failure response messages and failure and warning codes, all served ✨
Invalid Message 🙈
3: The specified request is not implemented on this switch. The Message Type field specifies a message that is not implemented on the switch, or contains a value that is not defined in the version of the protocol running in this session of GSMP.4: One or more of the specified ports does not exist. At least one of the ports in the message is invalid. A port is invalid if it does not exist, or if it has been removed from the switch.5: Invalid Port Session Number. The value in the Port Session Number field does not match the current Port Session Number for the specified port.7: Invalid Partition ID. The value in the Partition ID field is not legal for this partition.
General Message Failure 🌸
10: The meaning of this failure depends on the particular message type, and it's spelled out in the text that defines that message.
Specific Message Failure 🎀
A failure response that is only used by one specific message type.
- Failure response messages used by the Label Range message
40: Cannot support one or more requested label ranges.41: Cannot support disjoint label ranges.42: Specialised multipoint labels not supported.
- Failure response messages used by the Set Transmit Data Rate function of the Port Management message
43: The transmit data rate of this output port cannot be changed.44: Requested transmit data rate out of range for this output port. The transmit data rate of the requested output port can be changed, but the value in the Transmit Data Rate field is beyond the range of acceptable values.
- Failure response message of the Port Management message
45: Connection Replace mechanism not supported on switch. The R-flag SHOULD be reset in the Response Port Management message.
- Failure response message range reserved for the ARM extension
128-159: These failure response codes will be interpreted according to definitions provided by the model description.
Connection Failures 🔗
11: The specified connection does not exist. An operation that expects a connection to be specified cannot locate the specified connection. A connection is specified by the input port and input label on which it originates. An ATM virtual path connection is specified by the input port and input VPI on which it originates.12: The specified branch does not exist. An operation that expects a branch of an existing connection to be specified cannot locate the specified branch. A branch of a connection is specified by the connection it belongs to and the output port and output label on which it departs. A branch of an ATM virtual path connection is specified by the virtual path connection it belongs to and the output port and output VPI on which it departs.13: One or more of the specified Input Labels is invalid.14: One or more of the specified Output Labels is invalid.15: Point-to-point bi-directional connection already exists. The connection specified by the Input Port and Input Label fields already exists, and the bi-directional Flag in the Flags field is set.16: Invalid Service Selector field in a Connection Management message. The value of the Service Selector field is invalid.17: Insufficient resources for QoS Profile. The resources requested by the QoS Profile in the Service Selector field are not available.18: Insufficient Resources. Switch resources needed to establish a branch are not available.20: Reservation ID out of Range. The numerical value of Reservation ID is greater than the value of Max Reservations (from the Switch Configuration message).21: Mismatched reservation ports. The value of Input Port differs from the input port specified in the reservation, or the value of Output Port differs from the output port specified in the reservation.22: Reservation ID in use. The value of Reservation ID matches that of an extant Reservation.23: Non-existent reservation ID. No reservation corresponding to Reservation ID exists.36: Replace of connection is not activated on switch. Only applicable for Add Branch messages. The Replace Connection mechanism has not been activated on the port by the Port Management message.37: Connection replacement mode cannot be combined with Bi-directional or Multicast mode. The R flag MUST NOT be used in conjunction with either the M flag or the B flag.
ATM Virtual Path Connections 🦋
24: ATM virtual path switching is not supported on this input port.25: Point-to-multipoint ATM virtual path connections are not supported on either the requested input port or the requested output port. One or both of the requested input and output ports is unable to support point-to-multipoint ATM virtual path connections.26: Attempt to add an ATM virtual path connection branch to an existing virtual channel connection. It is invalid to mix branches switched as virtual channel connections with branches switched as ATM virtual path connections on the same point-to-multipoint connection.27: Attempt to add an ATM virtual channel connection branch to an existing ATM virtual path connection. It is invalid to mix branches switched as virtual channel connections with branches switched as ATM virtual path connections on the same point-to-multipoint connection.28: ATM Virtual path switching is not supported on non-ATM ports. One or both of the requested input and output ports is not an ATM port. ATM virtual path switching is only supported on ATM ports.
Multicast Failures 📡
29: A branch belonging to the specified point-to-multipoint connection is already established on the specified output port, and the switch cannot support more than a single branch of any point-to-multipoint connection on the same output port.30: The limit on the maximum number of multicast connections that the switch can support has been reached.31: The limit on the maximum number of branches that the specified multicast connection can support has been reached.32: Cannot label each output branch of a point-to-multipoint tree with a different label. Some switch designs require all output branches of a point-to-multipoint connection to use the same value of Label.33: Cannot add multi-point branch to bi-directional connection. It is an error to attempt to add an additional branch to an existing connection with the bi-directional flag set.34: Unable to assign the requested Label value to the requested branch on the specified multicast connection. Although the requested Labels are valid, the switch is unable to support the request using the specified Label values, for some reason not covered by the above failure responses. This message implies that a valid value of Labels exists that the switch could support. For example, some switch designs restrict the number of distinct Label values available to a multicast connection. (Most switch designs will not require this message.)35: General problem related to the manner in which multicast is supported by the switch. Use this message if none of the more specific multicast failure messages apply. (Most switch designs will not require this message.)
QoS Failures 💎
60-79: These failure response codes will be interpreted according to definitions provided by the model description.80: Switch does not support different QoS parameters for different branches within a multipoint connection.
General Failures 🧯
2: Invalid request message. There is an error in one of the fields of the message that is not covered by a more specific failure message.6: One or more of the specified ports is down. A port is down if its Port Status is Unavailable. Connection Management, Connection State, Port Management, and Configuration operations are permitted on a port that is Unavailable. Connection Activity and Statistics operations are not permitted on a port that is Unavailable, and will generate this failure response. A Port Management message specifying a Take Down function on a port already in the Unavailable state will also generate this failure response.19: Out of resources. The switch has exhausted a resource not covered by a more specific failure message, for example, running out of memory.1: Unspecified reason not covered by other failure codes. The failure message of last resort.
Warnings ⭐
46: One or more labels are still used in the previous Label Range.
12.2. Summary of Failure Response Codes and Warnings ✨
Okay bestie, here's the cheat sheet 💅 of every failure code a failure response message can carry. Codes 60-79 and 128-159 are reserved for QoS failures and ARM extensions, and code 10 changes meaning depending on the Message Type it shows up in 🙈
1: Unspecified reason not covered by other failure codes.
2: Invalid request message.
3: The specified request is not implemented on this switch.
4: One or more of the specified ports does not exist.
5: Invalid Port Session Number.
6: One or more of the specified ports is down.
7: Invalid Partition ID.
10: General message failure. (The meaning of this failure code
depends upon the Message Type. It is defined within the
description of any message that uses it.)
11: The specified connection does not exist.
12: The specified branch does not exist.
13: One or more of the specified Input Labels is invalid.
14: One or more of the specified Output Labels is invalid.
15: Point-to-point bi-directional connection already exists.
16: Invalid service selector field in a connection management
message.
17: Insufficient resources for QoS profile.
18: Insufficient resources.
19: Out of resources (e.g., memory exhausted, etc.).
20: Reservation ID out of Range
21: Mismatched reservation ports
22: Reservation ID in use
23: Non-existent reservation ID
24: ATM virtual path switching is not supported on this input
port.
25: Point-to-multipoint ATM virtual path connections are not
supported on either the requested input port or the
requested output port.
26: Attempt to add an ATM virtual path connection branch to an
existing virtual channel connection.
27: Attempt to add an ATM virtual channel connection branch to
an existing virtual path connection.
28: ATM Virtual Path switching is not supported on non-ATM
ports.
29: A branch belonging to the specified point-to-multipoint
connection is already established on the specified
output port and the switch cannot support more than a
single branch of any point-to-multipoint connection on
the same output port.
30: The limit on the maximum number of point-to-multipoint
connections that the switch can support has been
reached.
31: The limit on the maximum number of branches that the
specified point-to-multipoint connection can support has
been reached.
32: Cannot label each output branch of a point-to-multipoint
tree with a different label.
33: Cannot add multi-point branch to bi-directional
connection.
34: Unable to assign the requested Label value to the
requested branch on the specified point-to-multipoint
connection.
35: General problem related to the manner in which point-to-
multipoint is supported by the switch.
36: Replace of connection is not activated on switch.
37: Connection replacement mode cannot be combined with Bi-
directional or Multicast mode.
40: Cannot support one or more requested label ranges.
41: Cannot support disjoint label ranges.
42: Specialised multipoint labels not supported.
43: The transmit data rate of this output port cannot be
changed.
44: Requested transmit data rate out of range for this output
port.
45: Connection Replace mechanism not supported on switch.
46: Labels are still used in the existing Label Range.
60-79: Reserved for QoS failures.
80: Switch does not support different QoS parameters for
different branches within a multipoint connection.
128-159: Reserved for the ARM extensions.13. Security Considerations 🔐
Security is a big deal, so let's be serious for a sec 🫶 The security of GSMP's TCP/IP control channel has been addressed in [15]. For all uses of GSMP over an IP network, it is REQUIRED that GSMP be run over TCP/IP using the security considerations discussed in [15]. So yeah, no shortcuts on this one, periodt 😭
Appendix A. Summary of Messages 📋
Here's the whole message roster in one place, so you can find any message number at a glance 🧚
Message Name Message Number Status
Connection Management Messages
Add Branch .......................16
ATM Specific - VPC.............26
Delete Tree.......................18
Verify Tree.......................19 Obsoleted
Delete All Input..................20
Delete All Output.................21
Delete Branches...................17
Move Output Branch................22
ATM Specific - VPC............27
Move Input Branch.................23
ATM Specifc - VPC............28
Port Management Messages
Port Management...................32
Label Range.......................33
State and Statistics Messages
Connection Activity...............48
Port Statistics...................49
Connection Statistics.............50
QoS Class Statistics..............51 Reserved
Report Connection State...........52
Configuration Messages
Switch Configuration..............64
Port Configuration................65
All Ports Configuration...........66
Service Configuration.............67
Reservation Messages
Reservation Request...............70
Delete Reservation................71
Delete All Reservations...........72
Event Messages
Port Up...........................80
Port Down.........................81
Invalid Label.....................82
New Port..........................83
Dead Port.........................84
Abstract and Resource Model Extension Messages
Reserved..........................200-249
Adjacency Protocol....................10 RequiredAppendix B. IANA Considerations 🦋
Following the policies outlined in "Guidelines for Writing an IANA Considerations Section in RFCs" (RFC 2434 [19]), the following name spaces are defined in GSMPv3:
- Message Type Name Space [Appendix A]
- Label Type Name Space [3.1.3]
- Result Name Space [3.1.1]
- Failure Response Message Name Space [3.1.4],[11]
- Adaptation Type Name Space [4.1]
- Model Type Name Space [8.1]
- Port Type Name Space [8.2]
- Service ID Name Space [10.4]
- Traffic Control Name Space [8.4]
- Event Flag Name Space [6.1]
B.1. Message Type Name Space 🌸
GSMPv3 splits the Message Type name space into four ranges, and here's how each one gets managed 💖
- Message Types
0-99. These are part of the GSMPv3 base protocol, and they get allocated through an IETF consensus action [19]. - Message Types
100-199. These are Specification Required [19]. Anything using this range must be documented in an RFC or other permanent and readily available references. - Message Types
200-249. These are Specification Required [19] and are meant for Abstract and Resource Model Extension Messages. Anything using this range must be documented in an RFC or other permanent and readily available references. - Message Types
250-255. These are reserved for vendor private extensions and are the responsibility of individual vendors. IANA management of this range of the Message Type Name Space is unnecessary.
B.2. Label Type Name Space 🏷️
GSMPv3 splits the Label Type name space into three ranges, and the rules are pretty clear-cut 🌈
- Label Types
0x000-0xAFF. These are part of the GSMPv3 base protocol and get allocated through an IETF consensus action [19]. - Label Types
0xB00-0xEFF. These are Specification Required [19]. Anything using this range must be documented in an RFC or other permanent and readily available reference. - Label Types
0xF00-0xFFF. These are reserved for vendor private extensions and are the responsibility of individual vendors. IANA management of this range of the Label Type Name Space is unnecessary.
B.3. Result Name Space ✅
Here's the guideline for managing the Result Name Space:
- Result values
0-255. Anything in this range needs an expert review, i.e., approval by a Designated Expert is required [19].
B.4. Failure Response Name Space 🙅
GSMPv3 splits the Failure Response name space into two groups of ranges, so pay attention to which one you're in ✨
- Failure Responses
0-59,80-127,160-255. These are part of the GSMPv3 base protocol and get allocated through an IETF consensus action [19]. - Failure Responses
60-79,128-159. These are reserved for vendor private extensions and are the responsibility of individual vendors. IANA management of these ranges of the Failure Response Name Space is unnecessary.
B.5. Adaptation Type Name Space 🔌
GSMPv3 splits the Adaptation Type name space into two ranges:
- Adaptation Types
0x000-0x2FF. These are part of the GSMPv3 base protocol and get allocated through an IETF consensus action [19]. - Adaptation Types
0x300-0xFFF. These are allocated by the first come first served principle [19].
B.6. Model Type Name Space 🧩
GSMPv3 splits the Model Type name space into three ranges, and each one has its own rules 💜
- Model Type
0. This is part of the GSMPv3 base protocol and gets allocated through an IETF consensus action [19]. - Model Types
1-200. These are Specification Required [19]. Anything using this range must be documented in an RFC or other permanent and readily available references. - Model Types
201-255. These are reserved for vendor private extensions and are the responsibility of individual vendors. IANA management of these ranges of the Model Type Name Space is unnecessary.
B.7. Port Type Name Space 🚪
GSMPv3 splits the Port Type name space into two ranges, and that's the whole story 🎀
- Port Types
0-127. These are part of the GSMPv3 base protocol and get allocated through an IETF consensus action [19]. - Port Types
128-255. These are Specification Required [19]. Anything using this range must be documented in an RFC or other permanent and readily available references.
B.8. Service ID Name Space ✨
okay so GSMPv3 splits the Service ID name space into two ranges 💅 here's how each one gets managed:
Service ID 0-1023.Service IDs in this range are part of the GSMPv3 base protocol 🎀. They're allocated through an IETF consensus action [19].Service ID 1024-65535.Service IDs in this range are Specification Required [19] 📜. Service IDs using this range must be documented in an RFC or other permanent and readily available references 🌸.
B.9. Traffic Control Name Space 🦋
the rules for Traffic Control Flags in GSMPv3 are simple, bestie:
- All Traffic Control Flags are allocated through an expert review, i.e., approval by a Designated Expert [19] 💜.
B.10. Event Flag Name Space 🌈
and the same vibe for Event Flags in GSMPv3 🧚:
- All Event Flags are allocated through an expert review, i.e., approval by a Designated Expert [19] ✨.
the TCP port for establishing GSMP connections has been defined as 6068 🍓. iconic.
References 📚
[1] "B-ISDN ATM Layer Specification", International Telecommunication Union, ITU-T Recommendation I.361, Feb. 1999.
[2] "B-ISDN ATM Adaptation Layer (AAL) Specification", International Telecommunication Union, ITU-T Recommendation I.363, Mar. 1993.
[3] "B-ISDN ATM Adaptation Layer specification: Type 5 AAL", International Telecommunication Union, ITU-T, Recommendation I.363.5, Aug. 1996.
[4] Sjostrand, H., Buerkle, J. and B. Srinivasan, "Definitions of Managed Objects for the General Switch Management Protocol (GSMP)", RFC 3295, June 2002.
[5] IANA Assigned Port Numbers, http://www.iana.org
[6] Newman, P, Edwards, W., Hinden, R., Hoffman, E. Ching Liaw, F., Lyon, T. and G. Minshall, "Ipsilon's General Switch Management Protocol Specification Version 1.1", RFC 1987, August 1996.
[7] Newman, P., Edwards, W., Hinden, R., Hoffman, E., Ching Liaw, F., Lyon, T. and G. Minshall, "Ipsilon's General Switch Management Protocol Specification Version 2.0", RFC 2297, March 1998.
[8] ATM Forum Technical Committee, "Traffic Management Specification Version 4.1", af-tm-0121.000, 1999.
[9] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[10] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T. and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
[11] ITU-T Recommendation I.233 Frame Mode Bearer Services, ISDN frame relaying bearer services and ISDN switching bearer service, Nov. 1991.
[12] ITU-T Recommendation Q.933, Integrated Services Digital Network (ISDN) Digital Subscriber Signaling System No. 1 (DSS 1) Signaling Specifications For Frame Mode Switched And Permanent Virtual Connection Control And Status Monitoring, 1995.
[13] ITU-T Recommendation Q.922, Integrated Services Digital Network (ISDN) Data Link Layer Specification For Frame Mode Bearer Services, 1992
[14] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[15] Worster, T., Doria, A. and J. Buerkle, "General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP)", RFC 3293, June 2002.
[16] Doria, A. and K. Sundell, "General Switch Management Protocol Applicability", RFC 3294, June 2002.
[17] IANAifType - MIB DEFINITIONS, http://www.iana.org, January 2001.
[18] Anderson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[19] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[20] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[21] Conta, A., Doolan, P. and A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001.
Authors' Addresses 🧚
Avri Doria
Div. of Computer Communications
Lulea University of Technology
S-971 87 Lulea
Sweden
Phone: +1 401 663 5024
EMail: avri@acm.org
Fiffi Hellstrand
Nortel Networks AB
S:t Eriksgatan 115 A
SE-113 85 Stockholm Sweden
EMail: fiffi@nortelnetworks.com
Kenneth Sundell
Nortel Networks AB
S:t Eriksgatan 115 A
SE-113 85 Stockholm Sweden
EMail: ksundell@nortelnetworks.com
Tom Worster
Phone: +1 617 247 2624
EMail: fsb@thefsb.orgFull Copyright Statement ©
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
legal bits stay word-for-word, no cap 🙈
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. 💖
📦 where this page comes from
- ietf: rfc3292 2002-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms