RFC 2297
Ipsilon's General Switch Management Protocol Specification Version 2.0
Ipsilon's General Switch Management Protocol Specification Version 2.0 ๐ฆ
okay bestie, this is RFC 2297 and it's giving ATM switch control realness โจ It's an Informational doc, so it's just sharing info, not a formal standard ๐ It came out in March 1998 under the Network Working Group, and it updates [RFC1987], which is the original GSMP spec ๐ธ
The whole crew: P. Newman (Nokia), W. Edwards (Sprint), R. Hinden (Nokia), E. Hoffman (Nokia), F. Ching Liaw, T. Lyon (Nokia), and G. Minshall (Fiberlane) ๐
Status of This Memo ๐ฎ
this memo is giving info for the Internet community ๐ It doesn't specify an Internet standard of any kind, and distribution is unlimited, so share away!
Copyright Notice ยฉ๏ธ
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract ๐
this memo is basically the glow-up for the General Switch Management Protocol (GSMP) [RFC1987] โจ The big new thing is the Quality of Service (QoS) messages ๐ฅ There are also other improvements that came from people actually running this stuff in the real world ๐
quick recap: GSMP is a general purpose protocol for controlling an ATM switch ๐ฆ A controller can set up and tear down connections across the switch, add and delete leaves on a multicast connection, manage switch ports, and ask for configuration info and statistics. Iconic behavior honestly ๐
Table of Contents ๐๏ธ
1. Introduction....................................................3
2. GSMP Packet Encapsulation.......................................4
2.1 ATM Encapsulation...........................................4
2.2 Ethernet Encapsulation......................................6
3. Common Definitions and Procedures...............................7
3.1 GSMP Packet Format..........................................8
3.2 Failure Response Messages..................................11
4. Connection Management Messages.................................16
4.1 Add Branch Message.........................................21
4.2 Delete Tree Message........................................23
4.3 Verify Tree Message........................................24
4.4 Delete All Message.........................................24
4.5 Delete Branches Message....................................25
4.6 Move Branch Message........................................27
5. Port Management Messages.......................................29
5.1 Port Management Message....................................29
5.2 Label Range Message........................................34
6. State and Statistics Messages..................................37
6.1 Connection Activity Message................................38
6.2 Statistics Messages........................................40
6.2.1 Port Statistics Message..............................44
6.2.2 Connection Statistics Message........................44
6.2.3 QoS Class Statistics Message.........................44
6.3 Report Connection State Message............................45
7. Configuration Messages.........................................49
7.1 Switch Configuration Message...............................50
7.2 Port Configuration Message.................................51
7.3 All Ports Configuration Message............................57
8. Event Messages.................................................59
8.1 Port Up Message............................................60
8.2 Port Down Message..........................................60
8.3 Invalid VPI/VCI Message....................................61
8.4 New Port Message...........................................61
8.5 Dead Port Message..........................................61
9. Quality of Service Messages....................................61
9.1 Abstract Switch Model......................................62
9.2 QoS Configuration Message..................................66
9.3 Scheduler Establishment Message............................74
9.4 QoS Class Establishment Message............................78
9.5 QoS Release Message........................................85
9.6 QoS Connection Management Message..........................86
9.7 QoS Failure Response Codes.................................97
10. Adjacency Protocol............................................97
10.1 Packet Format.............................................98
10.2 Procedure.................................................101
10.3 Loss of Synchronization...................................103
11. Summary of Failure Response Codes.............................104
12. Summary of Message Set........................................105
References........................................................107
Security Considerations...........................................107
Authors' Addresses................................................107
Full Copyright Statement..........................................109
1. Introduction โจ
okay so GSMP is a general purpose protocol for controlling an ATM switch ๐ A controller can set up and release connections across the switch, add and delete leaves on a multicast connection, manage switch ports, and request configuration info and statistics. It can also let the switch tell the controller about async events, like a link going down ๐ญ GSMP runs across an ATM link that connects the controller to the switch, on a control connection (virtual channel) that gets set up at initialization. GSMP over an Ethernet link is specified too ๐
The vibe here is asymmetric: the controller is the master and the switch is the slave ๐ซถ You can have several switches run by one controller, using multiple instances of the protocol over separate control connections ๐ง
A switch is assumed to have multiple "ports" ๐ธ Each port is one "input port" plus one "output port". Some GSMP requests are about the port as a whole, and others only care about the input or output side. ATM cells arrive at the switch from an external link on incoming virtual paths or virtual channels at an input port, and leave the switch on outgoing virtual paths or virtual channels from an output port. Virtual paths are referenced by their virtual path identifier (VPI). Virtual channels are referenced by their VPI and virtual channel identifier (VCI), written VPI/VCI ๐
A virtual channel connection across the switch is made by hooking an incoming virtual channel up to one or more outgoing virtual channels. These connections are identified by the input port they arrive on, plus the VPI/VCI of the incoming virtual channel ๐ฆ A virtual path connection works the same way with incoming and outgoing virtual paths, and is identified by its input port and its VPI. For a virtual path connection, the switch doesn't use the VCI value in each cell on that connection, and it stays unchanged by the switch. Main character energy ๐
GSMP supports point-to-point and point-to-multipoint connections โจ A multipoint-to-point connection is set up by making multiple point-to-point connections that all specify the same output branch. A multipoint-to-multipoint connection is set up by making multiple point-to-multipoint trees that all specify the same output branches ๐
In general, a virtual channel is set up with a certain quality of service (QoS). This version introduces a rich set of QoS messages ๐ฅ But GSMP can also be implemented or run without any of the messages in Section 9, "Quality of service messages," and that's allowed ๐ In that case, each virtual channel connection or virtual path connection may be given a priority when it's set up. It may be assumed that for virtual connections sharing the same output port, a cell on a higher priority connection is much more likely to leave the switch before a cell on a lower priority connection, if 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 ๐
GSMP also has an adjacency protocol ๐ซถ It's used to sync state across the link, negotiate which version of GSMP to use, find out who is at the other end of a link, and notice when that changes ๐
2. GSMP Packet Encapsulation ๐
2.1. ATM Encapsulation โจ
okay so GSMP packets are variable length ๐ธ, and on an ATM data link layer they get wrapped directly in an AAL-5 CPCS-PDU [I.363] with an LLC/SNAP header. Here's the picture:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LLC (0xAA-AA-03) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| SNAP (0x00-00-00-88-0C) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ GSMP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pad (0 - 47 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ AAL-5 CPCS-PDU Trailer (8 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Quick number-and-bits lesson, bestie ๐ง: numbers are written in decimal, the way [RFC1700] does it. Hex numbers get the 0x prefix. Everything is big-endian ๐, so fields are read left to right, with the most significant octet on the left and the least significant octet on the right. When a diagram shows a group of octets, they're sent in the normal order you'd read them in English. For a single octet, the leftmost bit in the diagram is the high-order (most significant) bit, which is the bit labeled 0. For a multi-octet field, the leftmost bit of the whole field is the most significant one, and when it's transmitted, the most significant octet goes first. This is the same coding convention used in the ATM layer [I.361] and AAL-5 [I.363] ๐ฆ.
The LLC/SNAP header contains the octets 0xAA 0xAA 0x03 0x00 0x00 0x00 0x88 0x0C. (0x880C is the assigned Ethertype for GSMP ๐.)
The maximum transmission unit (MTU) of the GSMP Message field is 1492 octets ๐.
The virtual channel that a GSMP session gets set up on, between a controller and the switch it's controlling, is called the GSMP control channel ๐. The default VPI and VCI of the GSMP control channel for LLC/SNAP encapsulated GSMP messages on an ATM data link layer are:
VPI = 0
VCI = 15
2.2. Ethernet Encapsulation ๐
GSMP packets may be encapsulated on an Ethernet data link too, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype (0x88-0C) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
~ GSMP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Check Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Here's what each field does, bestie ๐:
Destination Address: For the SYN message of the adjacency protocol, the Destination Address is the broadcast address0xFFFFFFFFFFFF. (Alternatively, it's also valid to configure the node with the unicast 48-bit IEEE MAC address of the destination. In that case, the configured unicast Destination Address is used in the SYN message.) For all other messages, the Destination Address is the unicast 48-bit IEEE MAC address of the destination. You can discover this address from the Source Address field of messages received during synchronization of the adjacency protocol ๐.Source Address: For all messages, this is the 48-bit IEEE MAC address of the sender ๐.Ethertype: The assigned Ethertype for GSMP is0x880C๐.GSMP Message: The maximum transmission unit (MTU) of this field is 1492 octets ๐.Sender Instance: This is the Sender Instance number for the link, obtained from the adjacency protocol. It's already present in the adjacency protocol message. It gets appended to all non-adjacency GSMP messages in the Ethernet encapsulation, to offer extra protection against the introduction of corrupt state ๐ก๏ธ.Receiver Instance: This is the number the sender believes is the current instance number for the link, allocated by the entity at the far end of the link. It's already present in the adjacency protocol message too. It gets appended to all non-adjacency GSMP messages in the Ethernet encapsulation, again to offer extra protection against the introduction of corrupt state ๐ซถ.Pad: The minimum length of the data field of an Ethernet packet is 46 octets. If necessary, padding should be added so the packet meets the minimum Ethernet frame size. This padding should be octets of zero, and it is not considered to be part of the GSMP message ๐งธ.
Once the adjacency protocol has achieved synchronization, the receiver must check the following for every GSMP message received with an Ethernet encapsulation ๐ค: the Source Address from the Ethernet MAC header, the Sender Instance, and the Receiver Instance. The incoming GSMP message must be discarded if the Sender Instance and the Source Address don't match the values of Sender Instance and Sender Name stored by the "Update Peer Verifier" operation of the GSMP adjacency protocol. The incoming GSMP message must also be discarded if it arrives over any port other than the port over which the adjacency protocol achieved synchronization. And the incoming message must also be discarded if the Receiver Instance field doesn't match the current value for the Sender Instance of the GSMP adjacency protocol ๐.
3. Common Definitions and Procedures โจ
okay so GSMP is a master-slave protocol ๐. The controller issues request messages to the switch. Each request message says whether a response is required from the switch, and it contains a transaction identifier so the response can be matched up with the request ๐ง. The switch replies with a response message, which is either a successful result or a failure.
There are five classes of GSMP request-response message ๐:
- Connection Management
- Port Management
- State and Statistics
- Configuration
- Quality of Service
The switch may also generate asynchronous Event messages to tell the controller about asynchronous events. Event messages are not acknowledged by the controller ๐. There's also an adjacency protocol message, which is used to establish synchronization across the link and maintain a handshake ๐ค.
For the request-response messages, each message type has a format for the request message and a format for the success response ๐. Unless otherwise specified, a failure response message is identical to the request message that caused the failure, with the Code field indicating the nature of the failure. Event messages have only a single format defined, since they aren't acknowledged by the controller โจ.
Switch ports are described by a 32-bit port number ๐ข. The switch assigns port numbers, and it may typically choose to structure those 32 bits into subfields that match the physical structure of the switch (for example, slot and port) ๐. In general, a port in the same physical location on the switch will always have the same port number, even across power cycles ๐. The internal structure of the port number is opaque to the GSMP protocol. However, for network management purposes such as logging, port naming, and graphical representation, a switch may declare the physical location (physical slot and port) of each port. Alternatively, this information may be obtained by looking up the product identity in a database ๐๏ธ.
Each switch port also maintains a port session number assigned by the switch ๐ชช. A message with an incorrect port session number must be rejected. This is what lets the controller detect a link failure and keep state synchronized ๐ซถ.
Except for the adjacency protocol message, no GSMP messages may be sent across the link until the adjacency protocol has achieved synchronization. And all GSMP messages received on a link that does not currently have state synchronization must be discarded ๐ .
3.1 GSMP Packet Format โจ
okay bestie, every GSMP message is built the same way (except the adjacency protocol message, which is the odd one out ๐). here's the 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Message Body ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version ๐ The GSMP protocol version used in this session. The sender of the message should set it to the GSMP protocol version that got negotiated during the adjacency protocol. Main character version control ๐
Message Type ๐ฆ The GSMP message type! GSMP messages fall into six classes: Connection Management, Port Management, State and Statistics, Configuration, Quality of Service, and Events. each class has a bunch of different message types. and on top of that, one Message Type is reserved for the adjacency protocol ๐ซถ
Result ๐ฅ This field shows up in a Connection Management request, a Port Management request, or a Quality of Service request. it tells the switch whether a response is needed if things go well. NoSuccessAck means the request doesn't expect a response on success, and AckAll means a response is expected on success. either way, a failure response must be generated if the request fails ๐ญ
For State and Statistics, and Configuration request messages, a NoSuccessAck value in the request is ignored, and the request gets handled as if the field were set to AckAll. (this facility got added to cut down control traffic when the controller periodically checks that the state in the switch is correct. if the controller doesn't use this capability, all request messages should be sent with a value of AckAll.) ngl this is such a smart little trick ๐ง
In a response message, the result field can be Success, More, or Failure. Success and More both mean a success response. More means the success response is bigger than the maximum transmission unit of the data link, so one or more further messages will follow to finish it. all the messages in the same success response carry the same Transaction Identifier. Success means a success response that either fits in one message or is the final message of a success response spanning several messages ๐ธ
The encoding of the result field is:
NoSuccessAck: Result = 1
AckAll: Result = 2
Success: Result = 3
Failure: Result = 4
More: Result = 5
The Result field is not used in an adjacency protocol message. (we're skipping it there, bestie) ๐
Code ๐ This field gives extra info about the result in a response message. it's mostly used to carry an error code in a failure response, but it can also give more detail in a success response or an event message. in a request message, the Code field isn't used and gets set to zero. in an adjacency protocol message, the Code field is what determines the function of the message ๐
Transaction Identifier ๐ This is how a request gets matched up with its response. for request messages, the controller can pick any transaction identifier it wants. for response messages, the transaction identifier gets set to the value from the message it's responding to. for event messages, the transaction identifier should be set to zero. the Transaction Identifier isn't used in the adjacency protocol, and the field isn't even there ๐ฆ
The following fields show up a lot in GSMP messages, so they're defined here so we don't have to keep repeating ourselves โจ
Port ๐ The port number of the switch port the message applies to.
Port Session Number ๐ Each switch port keeps a Port Session Number that the switch assigns. the port session number stays the same while the port is continuously in the Available state and the link status is continuously Up. a new Port Session Number must be generated when any of these happen: the port goes back to Available after being Unavailable or in any of the Loopback states; the line status comes back Up after being Down or in Test; or there's a power cycle. port session numbers should be assigned using some form of random number ๐ซถ
if the Port Session Number in a request doesn't match the port's current Port Session Number, a failure response must be returned, with the Code field indicating "Invalid port session number." (rude, but fair ๐) the current port session number for a port can be grabbed with a Port Configuration or an All Ports Configuration message ๐
Any field in a GSMP message that's unused or defined as "reserved" must be set to zero by the sender and ignored by the receiver. that's the golden rule, babe ๐ธ
It's not an error for a GSMP message to contain extra data after the end of the Message Body. this is there to support development and experimental purposes ๐งช however, the maximum transmission unit of the GSMP message, as defined by the data link layer encapsulation, must not be exceeded. no oversized messages, periodt ๐ซ
a success response message must not be sent until the requested operation has been successfully completed. so don't send the "yay it worked!" before it actually worked ๐ โโ๏ธ
3.2 Failure Response Messages โจ
okay so a failure response is basically the request that caused the drama, sent right back to you with the Result field in the header set to failure (Result = 4) and the Code field telling you why ๐
That code is the switch's reason for not being able to do what you asked.
If the switch sends a failure response, the switch's state should not change because of that message. ๐ The one exception is multi-request messages like Delete Branches. There, the failure response will say which requests worked and which flopped, and the ones that worked can still change state.
If the switch sends a failure, it must pick the most specific failure code, using this precedence order:
- Invalid Message
- Failure specific to the particular message type (failure code
16). The meaning of this one depends on the message type and is spelled out in the text that defines that message. - A failure response specified in the text defining the message type.
- Connection Failures
- Virtual Path Connection Failures
- Multicast Failures
- QoS Failures (QoS failures are specified in Section 9.7.)
- General Failures
If several failures match within one of those categories, the one listed first should be returned. Here are the failure response messages and codes ๐ธ
Invalid Message
3:The specified request is not implemented on this switch. The Message Type field points at a message the switch doesn't implement, or at a value that isn't defined in the version of the protocol running in this GSMP session.5:One or more of the specified ports does not exist. At least one port in the message is invalid. A port is invalid if it doesn't exist or has been removed from the switch.4:Invalid Port Session Number. The value in the Port Session Number field doesn't match the current Port Session Number for that port.
Connection Failures
8:The specified connection does not exist. An operation that expects a connection, either a virtual channel or a virtual path connection, can't find the one you named. A virtual channel connection is identified by the input port, input VPI, and input VCI it arrives on. A virtual path connection is identified by the input port and input VPI it arrives on.9:The specified branch does not exist. An operation that expects a branch of an existing connection, either a virtual channel or a virtual path connection, can't find the branch. A virtual channel branch is identified by the virtual channel connection it belongs to plus the output port, output VPI, and output VCI it departs on. A virtual path branch is identified by the virtual path connection it belongs to plus the output port and output VPI it departs on.18:One or more of the specified input VPIs is invalid.19:One or more of the specified input VCIs is invalid.20:One or more of the specified output VPIs is invalid.21:One or more of the specified output VCIs is invalid.22:Invalid Class of Service field in a Connection Management message. The value in the Class of Service field is invalid.23:Insufficient resources for QoS Profile. The resources requested by the QoS Profile in the Class of Service field aren't available.
Virtual Path Connections
24:Virtual path switching is not supported on this input port.25:Point-to-multipoint virtual path connections are not supported on the requested input port or the requested output port. One or both of those ports can't handle point-to-multipoint VP connections.26:Attempt to add a virtual path connection branch to an existing virtual channel connection. Mixing branches switched as virtual channel connections with branches switched as virtual path connections on the same point-to-multipoint connection is invalid. ๐ซ27:Attempt to add a virtual channel connection branch to an existing virtual path connection. Same deal: mixing VC-switched and VP-switched branches on one point-to-multipoint connection is invalid.
Multicast Failures
10:A branch of the specified point-to-multipoint connection is already established on the specified output port, and the switch can't support more than one branch of any point-to-multipoint connection on the same output port.11:The switch has hit its limit on the maximum number of point-to-multipoint connections it can support.12:The specified point-to-multipoint connection has hit its limit on the maximum number of branches it can support.17:Each output branch of a point-to-multipoint tree can't be labelled with a different label. Some early designs and some low-cost ATM switch designs require every output branch of a multicast connection to use the same VPI/VCI value.28:Only point-to-point bidirectional connections may be established. It's an error to add another output branch to a connection that already has the bidirectional flag set.13:The requested VPI/VCI value can't be assigned to the requested branch on the specified point-to-multipoint connection. The VPI and VCI are valid, but the switch can't support the request with those values for some reason not covered by the failures above. This message implies that a valid VPI or VCI value exists that the switch could support. For example, some switch designs restrict how many distinct VPI/VCI values are available to a point-to-multipoint connection. (Most switch designs won't need this message.)14:A general problem with how the switch supports point-to-multipoint. Use this one if none of the more specific multicast failure messages apply. (Most switch designs won't need this message.)
General Failures
2:Invalid request message. There's an error in one of the fields that isn't 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 an Unavailable port. Connection Activity and Statistics operations are not permitted on an Unavailable port and will generate this failure response. A Port Management message specifying a Take Down function on a port that is already Unavailable will also generate this failure response.15:Out of resources. The switch has run out of a resource that isn't covered by a more specific failure message, such as memory.1:Unspecified reason not covered by the other failure codes. The failure message of last resort. ๐ซถ
The following failure response messages are only used by the Label Range message:
29:Cannot support requested VPI range.30:Cannot support requested VCI range on all requested VPIs.
The following failure response messages are only used by the Set Transmit Cell Rate function of the Port Management message:
31:The transmit cell rate of this output port cannot be changed.32:Requested transmit cell rate is out of range for this output port.
4. Connection Management Messages โจ
Connection management messages are how the controller establishes, deletes, modifies, and verifies virtual channel connections and virtual path connections across the switch. ๐ฆ The Add Branch, Delete Tree, and Delete All connection management messages all use 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|Q|B|C| Input VPI | Input VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x| Output VPI | Output VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Branches | Class of Service |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Input Port
Identifies a switch input port. ๐
Flags
M: Multicast ๐ The Multicast flag is a hint for point-to-multipoint connections in the Add Branch message. It isn't used in any other connection management messages, and in those messages it should be set to zero. If it's set, the virtual channel connection or virtual path connection is very likely a point-to-multipoint connection. If it's zero, the connection is very likely point-to-point or the type is unknown.
Okay so the Multicast flag is only used in the Add Branch message when you're setting up the first branch of a brand new connection ๐ Subsequent branches on a point-to-multipoint connection? The flag is NOT REQUIRED there, and on those connections the receiver SHOULD ignore it ๐ Why? Because the receiver already knows it's point-to-multipoint once the second Add Branch message shows up โจ
If you know it's the first branch of a point-to-multipoint connection, the flag SHOULD be set ๐ If you don't know, or you know it's point-to-point, the flag SHOULD be zero ๐ง Using this flag is totally not mandatory. The switch MAY ignore it ๐ And if it's unused, it SHOULD be set to zero ๐ซถ
Here's the tea ๐ต Some switches store point-to-multipoint connections in a different data structure than point-to-point ones. Without this flag, the switch would build a point-to-point structure for the first branch of a point-to-multipoint connection, then immediately have to delete it and rebuild it as point-to-multipoint once the second branch arrives. The flag saves it from that whole mess ๐ญ
Q: QoS Profile The QoS Profile flag, if set, means the Class of Service field holds a QoS Profile Identifier ๐ If it's zero, the Class of Service field holds either a Priority or a Scheduler Identifier ๐ธ
B: Bidirectional This one only applies to the Add Branch message. It's ignored in every other Connection Management message ๐ โโ๏ธ It MAY only be used when establishing a point-to-point connection โญ
When it's set, the Bidirectional flag asks for two unidirectional virtual channels or virtual paths, 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 VPI, Input VCI, Output Port, Output VPI, and Output VCI values from the Add Branch message, exactly as written ๐ The reverse direction swaps the Input Port, Input VPI, and Input VCI values with the Output Port, Output VPI, and Output VCI values, respectively. So the reverse connection arrives at the input port named by Output Port, on the VPI/VCI named by Output VPI and Output VCI. It leaves from the output port named by Input Port, on the VPI/VCI named by Input VPI and Input VCI ๐
Honestly the Bidirectional flag is just a shortcut ๐โโ๏ธ It sets up two one-way connections going opposite ways between the same two ports, using the same VPI/VCIs, all in one Add Branch message. After that, the two one-way connections MUST be handled separately in every future message โจ There's no bidirectional delete message, but you CAN use a single Delete Branches message with two Delete Branch Elements, one for the forward connection and one for the reverse, if you want ๐
C: Congestion Indication If this flag is set, it asks that cells on this connection get marked when congestion happens ๐ฅ If the connection goes through a queue the switch considers congested, the Congestion Experienced bit gets set in the Payload Type field of the cell header on every cell in the connection ๐ GSMP doesn't define the algorithm or any threshold the switch uses to decide a queue is congested. That's totally the switch's call ๐
Input VPI This identifies an ATM virtual path arriving at the switch input port named in the Input Port field ๐ฆ
Input VCI This identifies an ATM virtual channel arriving on the virtual path named in the Input VPI field, at the switch input port named in the Input Port field ๐ง For virtual path connections, the Input VCI field isn't used โจ
Output Port This identifies a switch output port ๐
x: Unused Unused ๐
Output VPI This identifies an outgoing virtual path leaving the switch output port named in the Output Port field ๐
Output VCI This identifies an outgoing virtual channel leaving on the virtual path named in the Output VPI field, from the switch output port named in the Output Port field ๐ธ For virtual path connections, the Output VCI field isn't used ๐
Number of Branches In a success response message and a failure response message, this gives the number of output branches on a virtual channel connection or a virtual path connection after the requested operation finishes ๐ A point-to-point connection has one branch, and a point-to-multipoint connection has two or more โจ If the switch can't keep track of the number of branches on a virtual path or virtual channel connection, it MUST respond with the value 0xFFFF, which means "number of branches unknown" ๐ญ This field is not used in the request message ๐ซถ
Class of Service This field can hold a QoS Profile Identifier, a Priority, or a Scheduler Identifier ๐ Here's how to tell which one it is:
- If the QoS Profile flag in the
Flagsfield is set, theClass of Servicefield holds a QoS Profile ๐ - If the QoS Profile flag in the
Flagsfield is zero, and theClass of Servicevalue is greater than or equal to0x100, the field holds a Scheduler Identifier ๐ฆ - If the QoS Profile flag in the
Flagsfield is zero, and theClass of Servicevalue is less than0x100, the field holds a Priority ๐ง
Scheduler Identifier values below 0x100 get treated as priorities, so no mixing this up, bestie ๐
The Class of Service field is only used in the Add Branch and Move Branch messages ๐
A QoS Profile Identifier is an opaque 16-bit value ๐ฎ The switch uses it to find a QoS profile that spells out the Quality of Service the connection needs โจ QoS profiles get set up by a mechanism outside GSMP ๐
A Scheduler Identifier is another way to communicate a connection's QoS requirements ๐ It's defined in Section 9, "Quality of Service Messages" ๐
A Priority sets the connection's priority for Add Branch and Move Branch messages that don't use a QoS profile, or that don't use the QoS capabilities defined in Section 9, "Quality of Service Messages" ๐ The highest priority is numbered zero, and the lowest is numbered Q-1, where Q is the number of priorities the output port supports ๐ Giving different connections different quality of service based on priority is assumed to be a property of the switch's output port ๐ธ For virtual path or virtual channel connections sharing the same output port, a cell on a higher-priority connection is much more likely to leave the switch first when both are in the switch at the same time ๐ฆ The number of priorities each output port supports is given in the Port Configuration message ๐
For all connection management messages except the Delete Branches message, the success response is a copy of the request message, with the Result field saying success and the Number of Branches field showing how many branches the connection has after the operation ๐ The Code field isn't used in a connection management success response โจ
The failure response is a copy of the request message, with the Result field saying failure and the Number of Branches field showing how many branches the connection has ๐
Fundamentally, there's no distinction between point-to-point and point-to-multipoint connections ๐
By default, the first Add Branch message for a particular Input Port, Input VPI, and Input VCI sets up a point-to-point virtual connection ๐ง The second Add Branch message with the same Input Port, Input VPI, and Input VCI converts it into a point-to-multipoint virtual connection with two branches ๐ฆ (For virtual path connections, the Input VCI isn't required.) But some switch designs can be inefficient with that, so the Multicast flag exists ๐ If the controller knows a new connection is point-to-multipoint when it sets up the first branch, it MAY say so with the Multicast flag ๐ Later Add Branch messages with the same Input Port, Input VPI, and Input VCI add more branches to that point-to-multipoint connection ๐
Using the Delete Branch message on a point-to-multipoint connection with two branches leaves a point-to-point connection โจ The switch MAY structure that connection as point-to-multipoint with a single output branch if it chooses, since that can be more convenient for some switch designs ๐ Using the Delete Branch message on a point-to-point connection deletes the whole thing ๐ญ There's no such thing as a connection with zero output branches ๐ โโ๏ธ Every connection is unidirectional, going from one input virtual path or virtual channel to one or more output virtual paths or virtual channels ๐ซถ
GSMP supports point-to-point and point-to-multipoint connections ๐ A multipoint-to-point connection is set up by creating several point-to-point connections that each specify the same output branch ๐ธ (An output branch is an output port plus an output VPI for a virtual path connection, or an output port, output VPI, and output VCI for a virtual channel connection ๐) A multipoint-to-multipoint connection is set up by creating several point-to-multipoint trees that each specify the same output branches ๐โจ
The connection management messages work for both virtual channel connections and virtual path connections, bestie ๐ฆ Add Branch and Move Branch each come in two flavours, one Message Type for a virtual channel connection and one for a virtual path connection. Delete Branches, Delete Tree, and Delete All only have one Message Type each because they don't need to care which kind of connection they're dealing with ๐
For virtual path connections, neither Input VCI fields nor Output VCI fields are required. They SHOULD be set to zero by the sender and ignored by the receiver ๐ธ Virtual channel branches MUST NOT be added to an existing virtual path connection, and virtual path branches MUST NOT be added to an existing virtual channel connection. No cap, that's a hard rule ๐ In the Port Configuration message, each switch input port MAY declare whether it can do virtual path switching (aka accepting connection management messages that ask for virtual path connections) ๐
The connection management messages MAY be issued no matter what the Port Status of the switch port is ๐ง Connections MAY be established or deleted while a switch port is in the Available, Unavailable, or any of the Loopback states. Okay, but here's the plot twist: all connection state on an input port gets deleted when the port goes back to the Available state 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.1 Add Branch Message โจ
The Add Branch message is a connection management message used to set up a virtual channel connection or a virtual path connection, or to add another branch to an existing one ๐ It MAY also be used to check the connection state stored in the switch. The connection is identified by the Input Port, Input VPI, and Input VCI fields. The output branch is identified by the Output Port, Output VPI, and Output VCI fields. The quality of service requirements of the connection come from the Class of Service field. To ask for a virtual channel connection, the VCC (Virtual Channel Connection) Add Branch message is:
Message Type = 16
To ask for a virtual path connection, the VPC (Virtual Path Connection) Add Branch message is:
Message Type = 26
If a VPC Add Branch message arrives and the switch input port named in the Input Port field doesn't support virtual path switching, a failure response message MUST be returned saying, "Virtual path switching is not supported on this input port." ๐ โโ๏ธ
If the virtual channel connection defined by the Input Port, Input VPI, and Input VCI fields, or the virtual path connection defined by the Input Port and Input VPI fields, doesn't exist yet, it MUST be set up with the single output branch from the request message. If the Bidirectional Flag in the Flags field is set, the reverse connection MUST also be set up. The output branch SHOULD have the QoS attributes from the Class of Service field ๐
For a VCC Add Branch message, if a 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, "Attempt to add a virtual channel connection branch to an existing virtual path connection." For a 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, "Attempt to add a virtual path connection branch to an existing virtual channel connection." Not me going "no" to both of these ๐
If the connection already exists but the specified output branch doesn't, the new output branch MUST be added. The new output branch SHOULD have the QoS attributes from the Class of Service field ๐
If the connection already exists and the specified output branch also already exists, the QoS attributes of the connection (from the Class of Service field, if they're different from the request) SHOULD be changed to match the request message. A success response message MUST be sent if the Result field of the request message is "AckAll". This lets the controller periodically reassert the state of a connection or change its priority, which is so iconic ๐ If the Result field of the request message is "NoSuccessAck", a success response message SHOULD NOT be returned.
This MAY be used to cut down on traffic on the control link for messages that are just reasserting state that's already been set up. For those messages, the switch MUST always check that this state is correctly set up in the switch hardware (i.e. the actual connection tables used to forward cells). Double-checking is literally the vibe ๐ซถ
If the output branch defined by the Output Port, Output VPI, and Output VCI fields for a virtual channel connection, or by the Output Port and Output VPI fields for a virtual path connection, is already being used by a connection other than the one defined by the Input Port, Input VPI, and Input VCI fields, then that output branch ends up with multiple input branches. If multiple point-to-point connections share the same output branch, the result is a multipoint-to-point connection. If multiple point-to-multipoint trees share the same output branches, the result is a multipoint-to-multipoint connection ๐ฆ
If the virtual channel connection defined by the Input Port, Input VPI, and Input VCI fields, or the virtual path connection defined by the Input Port and Input VPI fields, already exists and the Bidirectional Flag in the Flags field is set, a failure response MUST be returned saying: "Only point-to-point bidirectional connections may be established."
It should be noted that different switches do multicast in different ways. There's a limit to the total number of point-to-multipoint connections any switch can handle, and possibly a limit on how many branches one point-to-multipoint connection can have. Some switches also cap the number of different VPI/VCI values that can be assigned to the output branches of a point-to-multipoint connection. Lots of switches can't handle more than one branch of the same point-to-multipoint connection on the same output port ๐ฅน Specific failure codes are defined for some of these situations.
4.2 Delete Tree Message ๐ท
The Delete Tree message is a connection management message used to delete an entire virtual channel connection or an entire virtual path connection. All the remaining branches of the connection get deleted too. A virtual channel connection is identified by the Input Port, Input VPI, and Input VCI fields. A virtual path connection is identified by the Input Port and Input VPI fields. The Output Port, Output VPI, and Output VCI fields aren't used in this message. The Delete Tree message is:
Message Type = 18
If the Result field of the request message is "AckAll", a success response message MUST be sent once the specified connection has been deleted successfully. That success message MUST NOT be sent until the delete operation has been completed, and if possible, not until all data on the connection that's queued for transmission has been sent ๐ The Number of Branches field isn't used in either the request or response messages of the Delete Tree message.
4.3 Verify Tree Message ๐งโโ๏ธ
The Verify Tree message has been removed from this version of GSMP ๐ Its job is now done by the Number of Branches field in the success response to the Add Branch message, which tells you how many branches a virtual channel connection has after a successful add branch operation.
Message Type = 19 is reserved.
If a request message arrives with Message Type = 19, a failure response MUST be returned with the Code field indicating: "The specified request is not implemented in this version of the protocol."
4.4 Delete All Message ๐งน
The Delete All message is a connection management message used to delete all connections on a switch input port. All connections that arrive at the specified input port MUST be deleted. Once the operation is done, all dynamically assigned VPI/VCI values for that port MUST be unassigned. In other words, there MUST be no virtual connections established in the VPI/VCI space that GSMP controls on this port. The Input VPI, Input VCI, Output Port, Output VPI, and Output VCI fields aren't used in this message. The Delete All message is:
Message Type = 20
If the Result field of the request message is "AckAll", a success response message MUST be sent once the operation is complete. The Number of Branches field isn't used in either the request or response messages of the Delete All message. 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 request:
The specified request is not implemented on this switch.One or more of the specified ports does not exist.Invalid Port Session Number.
If any field in a Delete All message that isn't covered by the failure codes above is invalid, a failure response MUST be returned saying: "Invalid request message." Otherwise, the delete all operation MUST be completed successfully and a success message returned. No other failure messages are permitted ๐ธ
Heads up: the Delete All operation has to be finished before the success message goes out, so don't rush the response ๐
4.5 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 deletes a branch of a virtual channel connection or a virtual path connection. and if it's the last branch of a connection? it deletes the whole connection ๐ the 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Number of Elements |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Delete Branch Elements ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Number of Elements tells you how many Delete Branch Elements are coming after it ๐ซถ the total number of Delete Branch Elements in a Delete Branches message must not make the packet length go over the maximum transmission unit defined by the encapsulation. so don't get greedy, bestie ๐ญ
each Delete Branch Element names one output branch to delete, and it looks like this ๐ธ
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error | Input VPI | Input VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x| Output VPI | Output VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Error is where a failure code goes, telling you why one specific Delete Branch Element failed 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 that the delete operation in this element worked. the other failure codes are listed in Section 3.2, "Failure Response Messages." ๐
every other field in the Delete Branch Element means the same thing it does in the other connection management messages ๐ง
here's the vibe for connections ๐ in each Delete Branch Element, a virtual channel connection is picked out by the Input Port, Input VPI, and Input VCI fields. or it's a virtual path connection, picked out by just the Input Port and Input VPI fields. then the exact branch to kill is chosen by the Output Port, Output VPI, and Output VCI fields for a virtual channel connection, or by the Output Port and Output VPI for a virtual path connection โจ
now the response part, which is lowkey the important bit ๐ if the Result field of the Delete Branches request message is "AckAll", a success response message must be sent once every branch named by every Delete Branch Element has been deleted. the success response must not be sent until all the delete branch operations are finished. it only goes out if every single requested delete worked ๐ and a Delete Branches success response carries no Delete Branch Elements at all, with Number of Elements set to zero ๐ซถ
if even one Delete Branch Element fails, a Delete Branches failure response message has to come back โจ it's a copy of the request, with the Code field of the whole message set to "Failure specific to the particular message type," and the Error field of each element tells you what happened to that particular delete ๐ฅ a failure in one Delete Branch Element must not interfere with the processing of any other Delete Branch Elements. independent little queens, every one of them ๐ธ
4.6 Move Branch Message ๐ฆ
the Move Branch message is how you move a branch of an existing connection from its current output port VPI/VCI to a new output port VPI/VCI, all in one atomic transaction โญ this happens a LOT in IP switching, every time a flow gets switched from hop-by-hop forwarding over to its own dedicated virtual channel ๐ the Move Branch connection management message uses the same format for both the request and the response ๐
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Input VPI | Input VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x| Old Output VPI | Old Output VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x| New Output VPI | New Output VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Branches | Class of Service |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VCC Move Branch ๐
the VCC Move Branch message moves a single output branch of a virtual channel connection from its current output port, output VPI, and output VCI, over to a new output port, output VPI, and output VCI on that same virtual channel connection ๐ฆ none of the other output branches get touched ๐ once it's done, the original output VPI/VCI on the original output port gets deleted from the connection ๐ the VCC Move Branch message is Message Type = 22 โจ
so, if the virtual channel connection named by Input Port, Input VPI, and Input VCI already exists, and the output branch named by Old Output Port, Old Output VPI, and Old Output VCI is already a branch on it, then the branch named by New Output Port, New Output VPI, and New Output VCI gets added and the old branch gets deleted ๐ฅ if the Result field of the request is "AckAll", a success response message must be sent upon successful completion of the operation. the success response must not be sent until the Move Branch operation has been completed ๐ซถ
now the sad path ๐ญ if the virtual channel connection exists, but the Old Output branch isn't actually a branch on it, a failure response must come back with the Code field saying, "The specified branch does not exist." ๐ฅ
VPC Move Branch ๐ธ
the VPC Move Branch message does the same kind of move, but for a virtual path connection ๐ง it moves one output branch from its current output port and output VPI over to a new output port and output VPI, on the same virtual channel connection ๐ none of the other output branches are modified ๐
when it's finished, the original output VPI on the original output port gets deleted from the connection โจ the VPC Move Branch message is Message Type = 27 ๐
if the virtual path connection named by Input Port and Input VPI already exists, and the output branch named by Old Output Port and Old Output VPI is a branch on it, then the branch named by New Output Port and New Output VPI is added and the old one is deleted ๐ฆ if the Result field of the request is "AckAll", a success response message must be sent upon successful completion of the operation. the success response must not be sent until the Move Branch operation has been completed ๐
and if the virtual path connection exists, but the Old Output branch isn't on it, a failure response must come back with the Code field saying, "The specified branch does not exist." ๐ฅ
if the virtual channel connection named by Input Port, Input VPI, and Input VCI, or the virtual path connection named by Input Port and Input VPI, doesn't exist at all, a failure response must come back with the Code field saying, "The specified connection does not exist." ๐
Shared Output Branches ๐
here's a plot twist ๐คฏ if the output branch named by the New Output Port, New Output VPI, and New Output VCI (for a virtual channel connection), or by the New Output Port and New Output VPI (for a virtual path connection), is already in use by some connection other than the one named by the Input fields, then that output branch ends up with multiple input branches ๐ซถ if several point-to-point connections share the same output branch, you get a multipoint-to-point connection ๐ and if several point-to-multipoint trees share the same output branches, you get a multipoint-to-multipoint connection ๐ธ it's giving complicated, but it's also giving very powerful ๐
5. Port Management Messages ๐
5.1 Port Management Message โจ
the Port Management message is the one that lets a port be brought into service, taken out of service, looped back, reset, or have its transmit cell rate changed ๐ฆ only the Bring Up and Reset Input Port functions change the connection state (the established connections) on the input port ๐ only the Bring Up function changes the value of the Port Session Number ๐ง 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 must not be sent until the operation has been completed ๐ the Port Management Message is Message Type = 32 ๐
Okay so the Port Management message has the same shape whether it's a request or a success response, bestie ๐ Here's the picture:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Flags | Duration | Function |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transmit Cell Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Event Sequence Number ๐ฆ
In the success response message, this gives the current value of the Event Sequence Number of the switch port named in the Port field. It gets set to zero when the port is initialized, and it goes up by one every time the port spots an asynchronous event that the switch would normally report with an Event message. If the Event Sequence Number in the success response doesn't match the Event Sequence Number of the most recent Event message received for that port, then events happened that never got reported through an Event message. ngl this is 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 is not used. ๐
Event Flags ๐ฅ
The Event Flags field in the request message is used to reset the Event Flags on the switch port named in the Port field. Each Event Flag on a switch port matches one type of Event message. When a switch port sends an Event message, it sets the matching Event Flag on that port, and the port isn't allowed to send another Event message of that same type until the Event Flag gets reset. If the Function field in the request message is set to "Reset Event Flags," then for each bit that's set in the Event Flags field, the matching Event Flag on the switch port gets reset. โจ
The Event Flags field is only used in a request message whose Function field is set to "Reset Event Flags." For every other value of the Function field, the Event Flags field is not used. In the success response message, the Event Flags field must be set to the current value of the Event Flags for the port, after the operation in the request message finishes, for every value of the Function field. Setting the Event Flags field to all zeros in a "Reset Event Flags" request message lets the controller check the current Event Flags and the current Event Sequence Number of the port without changing the Event Flags. It's giving "look but don't touch" ๐๐ซถ
Here's how the types of Event message line up with the bits of the Event Flags field:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|U|D|I|N|Z|x x x|
+-+-+-+-+-+-+-+-+
U: Port Up Bit 0, (most significant bit)
D: Port Down Bit 1,
I: Invalid VPI/VCI Bit 2,
N: New Port Bit 3,
Z: Dead Port Bit 4,
x: Unused Bits 5--7.
Duration โณ
Duration is the length of time, in seconds, that any of the loopback states stay in operation. When the duration runs out, the port automatically goes back into service. If another Port Management message arrives for the same port before the duration has expired, the loopback keeps going for the length of time given in the Duration field of that new message. The Duration field is only used in request messages whose Function field is set to Internal Loopback, External Loopback, or Bothway Loopback. ๐
Function ๐
Function specifies the action to take. The action gets taken no matter what the port's current status is (Available, Unavailable, or any Loopback state). If the specified function needs a new Port Session Number to be generated, then the new Port Session Number must be returned in the success response message. The defined values of the Function field are:
Bring Up: Function = 1. This brings the port into service. All connections that arrive at the specified input port must be deleted, and a new Port Session Number must be selected using some form of random number. When the operation finishes, all dynamically assigned VPI/VCI values for the specified input port must be unassigned, so no virtual connections get established in the VPI/VCI space that GSMP controls on this input port. The Port Status of the port afterwards will be Available. ๐ธ
Take Down: Function = 2. This takes the port out of service. Any cells received at this port get discarded, and no cells get transmitted from this port. The Port Status of the port afterwards will be Unavailable.
The behavior is undefined if the port being taken down is the one the GSMP session controlling the switch is running over. (In that case, the most probable behavior is that the switch either ignores the message, or it ends the current GSMP session and starts another one, possibly with the backup controller if there is one.) The correct way to reset the link GSMP is running over is to issue an RSTACK message in the adjacency protocol. ๐
Internal Loopback: Function = 3. Cells arriving at the output port from the switch fabric get looped through to the input port so they return to the switch fabric. All the ATM functions of the input port above the physical layer, like header translation, get performed on the looped back cells. The Port Status of the port afterwards will be Internal Loopback. ๐
External Loopback: Function = 4. Cells arriving at the input port from the external communications link get immediately looped back to the communications link at the physical layer, without entering the input port. None of the ATM functions of the input port above the physical layer get performed on the looped back cells. The Port Status of the port afterwards will be External Loopback. ๐ช
Bothway Loopback: Function = 5. Both internal and external loopback get performed. The Port Status of the port afterwards will be Bothway Loopback. ๐
Reset Input Port: Function = 6. All connections that arrive at the specified input port must be deleted, and the input and output port hardware gets re-initialized. When the operation finishes, all dynamically assigned VPI/VCI values for the specified input port must be unassigned, so no virtual connections get established in the VPI/VCI space that GSMP controls on this input port. The range of VPIs and VCIs that GSMP may control on this port gets set to the default values given in the Port Configuration message. The transmit cell rate of the output port must be set to its default value. The Port Session Number doesn't change with the Reset Input Port function. The Port Status of the port afterwards will be Unavailable. ๐งน
Reset Event Flags: Function = 7. For each bit that's set in the Event Flags field, the matching Event Flag in the switch port must be reset. The Port Status of the port doesn't change with this function. โ
Set Transmit Cell Rate: Function = 8. This sets the transmit cell rate of the output port as close as possible to the rate given in the Transmit Cell Rate field. In the success response message, the Transmit Cell Rate must show the actual transmit cell rate of the output port. If the transmit cell rate of the requested output port can't be changed, a failure response must be returned, with the Code field indicating: "The transmit cell rate of this output port cannot be changed." If the transmit cell rate of the requested output port can be changed, but the value in the Transmit Cell Rate field is outside the range of acceptable values, a failure response must be returned, with the Code field indicating: "Requested transmit cell rate out of range for this output port." In the failure response message, the Transmit Cell Rate must contain the same value as the request message that caused the failure. The transmit cell rate of the output port doesn't change with the Bring Up, Take Down, or any of the Loopback functions. The Reset Input Port function sets it back to the default value. ๐ฏ
Transmit Cell Rate ๐
This field is only used in request and success response messages whose Function field is set to "Set Transmit Cell Rate." It sets the output cell rate of the output port, specified in cells/s. If the Transmit Cell Rate field contains the value 0xFFFFFFFF, the transmit cell rate of the output port should be set to the highest valid value. ๐
5.2. Label Range Message ๐
Okay so, the default label range (Min VPI to Max VPI, and Min VCI to Max VCI) gets set for each port by the Port Configuration or All Ports Configuration messages ๐ . When the protocol first starts up, before any Label Range messages go out, every port's label range gets reset to that default. (The default depends on the switch design and configuration, and GSMP doesn't specify it, so don't go looking for it here ๐.) The Label Range message lets the controller change the range of VPIs a port supports, or the range of VCIs a specific VPI supports on that port. Each switch port must declare whether it supports the Label Range message in the Port Configuration or All Ports Configuration messages. The message type is:
Message Type = 33
The request and success response messages both use 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q|V|x x| Min VPI |x x x x| Max VPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min VCI | Max VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remaining VPIs | Remaining VCIs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags
Here's the breakdown of the flags ๐ฆ
Q: Query- If the Query flag is set in a request message, the switch must respond with the current range of valid VPIs, or the current range of valid VCIs on a specified VPI, depending on the VPI/VCI flag. 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.
V: VPI/VCI- If the VPI/VCI flag is set, the message refers only to a range of VPIs, and the Min VCI and Max VCI fields are unused. If the VPI/VCI flag is zero, the message refers to a range of VCIs on either one VPI or a range of VPIs.
x: Unused
Now the fields ๐ธ
Min VPIandMax VPI- These specify a range of VPI values, from Min VPI to Max VPI, inclusive. You can specify a single VPI by giving Min VPI and Max VPI the same value. In a request message, if Max VPI is less than or equal to Min VPI, the requested range is a single VPI equal to the Min VPI field. Zero is a valid value. In a request message with the Query flag set and the VPI/VCI flag zero, the Max VPI field specifies a single VPI and the Min VPI field isn't used. The maximum valid value for these fields, in both request and response messages, is
0xFFF.
- These specify a range of VPI values, from Min VPI to Max VPI, inclusive. You can specify a single VPI by giving Min VPI and Max VPI the same value. In a request message, if Max VPI is less than or equal to Min VPI, the requested range is a single VPI equal to the Min VPI field. Zero is a valid value. In a request message with the Query flag set and the VPI/VCI flag zero, the Max VPI field specifies a single VPI and the Min VPI field isn't used. The maximum valid value for these fields, in both request and response messages, is
Min VCIandMax VCI- These specify a range of VCI values, from Min VCI to Max VCI, inclusive. You can specify a single VCI by giving Min VCI and Max VCI the same value. In a request message, if Max VCI is less than or equal to Min VCI, the requested range is a single VCI equal to the Min VCI field. Zero is a valid value. (However, VPI=0, VCI=0 isn't available as a virtual channel connection, because ATM uses it as a special value to mean an unassigned cell ๐ โโ๏ธ.)
Remaining VPIsandRemaining VCIs- These fields are unused in the request message. In the success response and failure response messages, they give the maximum number of remaining VPIs and VCIs that could be requested for allocation on the specified port. For a success response, that count is after the requested operation has completed. This tells the switch controller roughly how many VPIs and VCIs it could ask for. The number given is the maximum possible under the switch hardware's constraints, but it doesn't mean that many VPIs and VCIs are available to every switch port.
Now the actual behaviour, the fun part ๐
If both the Query flag and the VPI/VCI flag are set in a request message, the switch must reply with a success response message containing the current range of valid VPIs supported by the port. The Min VPI and Max VPI fields aren't used in the request.
If the Query flag is set and the VPI/VCI flag is zero in a request message, the switch must reply with a success response message containing the current range of valid VCIs supported by the VPI specified in the Max VPI field. If the requested VPI is invalid, the switch must return a failure response saying: "One or more of the specified input VPIs is invalid." The Min VPI field isn't used in either the request or the success response messages.
If the Query flag is zero and the VPI/VCI flag is set in a request message, the Min VPI and Max VPI fields specify the new range of VPIs to allocate to the input port named in the Port field. Whatever VPI range was previously allocated to this port should be increased or decreased to the specified value.
If the Query flag and the VPI/VCI flag are both zero in a request message, the Min VCI and Max VCI fields specify the range of VCIs to allocate to each VPI in the VPI range. Whatever VCI range was previously allocated to each VPI in that range on this port should be increased or decreased to the specified value. The allocated VCI range must be the same on every VPI in the specified VPI range.
A success response to a Label Range message that asks for a label range change is a copy of the request message, with the Remaining VPIs and Remaining VCIs fields updated to their new values after the Label Range operation โจ
If the switch can't satisfy a request to change the VPI range, it must return a failure response with the Code field set to "Cannot support requested VPI range." In that failure response, the switch must use the Min VPI and Max VPI fields to suggest a VPI range it could satisfy.
If the switch can't satisfy a request to change the VCI range on all the VPIs in the requested VPI range, it must return a failure response with the Code field set to "Cannot support requested VCI range on all requested VPIs." In that failure response, the switch must use the Min VPI, Max VPI, Min VCI, and Max VCI fields to suggest a VPI and VCI range it could satisfy.
For every other failure response to a label range operation, the switch must return the Min VPI, Max VPI, Min VCI, and Max VCI values from the request message ๐ซถ
Quick reality check on hardware ๐ง: switches can usually handle all 256 or 4096 VPIs, but the VCI range they can support is often way more limited. The Min VCI often has to be 0 or 32, and all the VCIs within one VPI usually have to be contiguous. That's why the hint in the failure response exists. It lets the switch suggest a label range it can actually handle, given its architecture.
The Label Range message is defined to cover both a range of VPIs and a range of VCIs within each VPI, but the most likely use is changing either the VPI range or the VCI range inside one VPI. A VPI can be valid but have no valid VCIs allocated to it. That kind of VPI could be used for a virtual path connection, but to support virtual channel connections it would need a range of VCIs allocated to it ๐
A Label Range request may be sent regardless of the Port Status or the Line Status of the target switch port ๐ . If the Port field of the request names an invalid port (one that doesn't exist, or one that has been removed from the switch), the switch must return a failure response with the Code field set to "One or more of the specified ports does not exist."
6. State and Statistics Messages โจ
The state and statistics messages let the controller ask for the values of various hardware counters tied to the switch input and output ports, virtual path connections, virtual channel connections, and QoS Classes ๐. They also let the controller ask for the connection state of a switch input port. The Connection Activity message tells the controller whether one or more specific virtual channel connections or virtual path connections have been carrying traffic recently ๐. The Statistics message queries the various port, connection, and QoS class traffic and error counters ๐ฅ.
The Report Connection State message asks an input port to report the connection state for a single virtual channel connection, a single virtual path connection, or the entire input port ๐
6.1 Connection Activity Message ๐ฆ
okay so the Connection Activity message is how you check whether one or more virtual channel connections or virtual path connections have been carrying traffic lately ๐ It holds one or more Activity Records, and each record asks about a single connection and sends back info on it โจ A virtual channel connection is identified by its input port, input VPI, and input VCI. A virtual path connection is identified by its input port and input VPI. Those go in the Input Port, Input VPI, and Input VCI fields of each record ๐
There are two forms of activity detection ๐ If the switch supports per connection traffic accounting, the current value of the traffic counter for each specified virtual channel connection or virtual path connection must be returned. The units of traffic aren't specified, but they'll typically be cells or frames ๐ฆ The controller must compare the traffic counts in the message with the previous values for each connection to figure out whether that connection was active during the in-between period ๐ต๏ธโโ๏ธ
If the switch doesn't support 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 type 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Records | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Activity Records ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Number of Records ๐งพ This field specifies the number of Activity Records to follow. The number of Connection Activity records in a single Connection Activity message must not cause the packet length to exceed the maximum transmission unit defined by the encapsulation.
Each Activity Record has this format ๐ซถ
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V|C|A|x| Input VPI | Input VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Traffic Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Input Port ๐ช Identifies the port number of the input port on which the connection of interest arrives, so the connection can be identified. This works whether the traffic count for the connection is kept on the input port or the output port.
Input VPI and Input VCI ๐ These fields identify the specific virtual path connection or virtual channel connection whose statistics are being requested. For a virtual path connection, the Input VCI field is not used.
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 VC 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 VC 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.
- x: Unused ๐ซฅ
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. Reading the traffic counter does not modify its value. 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 failure response has the same format as the request message, but with the Number of Records field set to zero and no VC Activity records returned in the message. If the switch can't detect per connection activity, a failure response must be returned indicating, "The specified request is not implemented on this switch." ๐
that's the whole Connection Activity message, bestie ๐ the traffic count is doing the most and I respect it ๐
6.2. Statistics Messages
okay bestie, the Statistics messages are the nosy little snoops of this protocol ๐ต๏ธโโ๏ธ๐. They're used to query the various port, connection, and QoS class traffic and error counters, so you can see exactly what's happening on the switch โจ
The Statistics request messages have the following 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | VPI | VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QoS Class Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VPI and VCI ๐ These fields identify the specific virtual path connection or virtual channel connection whose stats you want. For a virtual path connection, the Input VCI field is not used ๐. If a request doesn't need a virtual path connection or virtual channel connection to be specified, then the VPI and VCI fields are not used.
QoS Class Identifier ๐ This field identifies the QoS class whose statistics are being requested. It's only used if the QoS Class Establishment message defined in section 9.4 is implemented, so no cap, it's a conditional vibe ๐ .
The success response for the Statistics message has the following 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | VPI | VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QoS Class Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Input Cell Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Input Frame Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Input Cell Discard Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Input Frame Discard Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Input HEC Error Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Input Invalid VPI/VCI Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Output Cell Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Output Frame Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Output Cell Discard Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Output Frame Discard Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Port, VPI/VCI and QoS Class Identifier ๐ These are the same as in the request message, so nothing new to learn here ๐ซถ.
Input Cell Count and Output Cell Count ๐ฅ These give the value of a free running 64-bit counter counting cells arriving at the input or departing from the output, respectively.
Input Frame Count and Output Frame Count ๐ฆ These give the value of a free running 64-bit counter counting frames (packets) arriving at the input or departing from the output, respectively.
Input Cell Discard Count and Output Cell Discard Count ๐ These give the value of a free running 64-bit counter counting cells discarded due to queue overflow on an input port or on an output port, respectively.
Input Frame Discard Count and Output Frame Discard Count ๐ญ These give the value of a free running 64-bit counter counting frames discarded due to congestion on an input port or on an output port, respectively.
HEC Error Count ๐ธ This gives the value of a free running 64-bit counter counting cells discarded due to header checksum errors on arrival at an input port.
Invalid VPI/VCI Count ๐ง This gives the value of a free running 64-bit counter counting cells discarded because their VPI/VCI is invalid on arrival at an input port. For a virtual channel connection, an incoming VPI/VCI is invalid if no connection is currently established having that value of VPI/VCI. For a virtual path connection, an incoming VPI is invalid if no connection is currently established having that value of VPI.
6.2.1. Port Statistics Message
The Port Statistics message requests the statistics for the switch port specified in the Port field ๐. The contents of the VPI/VCI and the QoS Class Identifier fields in the Port Statistics request message are ignored. All of the count fields in the success response message refer to per-port counts, regardless of the connection or QoS class the cells belong to ๐. Any of the count fields in the success response message that the port doesn't support must be set to zero. The Port Statistics message is:
Message Type = 49
6.2.2. Connection Statistics Message
The Connection Statistics message requests the statistics for the virtual channel connection specified in the VPI/VCI field, or the virtual path connection specified in the VPI field, that arrives on the switch input port specified in the Port field, regardless of the QoS class the cells belong to ๐ฆ. All of the count fields in the success response message refer only to the specified connection. The HEC Error Count and Invalid VPI/VCI Count fields are not connection specific and must be set to zero. Any of the other count fields not supported on a per connection basis must be set to zero in the success response message. The Connection Statistics message is:
Message Type = 50
6.2.3. QoS Class Statistics Message
The QoS Class Statistics message requests the statistics for the QoS class specified by the QoS Class Identifier field that arrives on the switch input port specified in the Port field, regardless of the connection the cells belong to โจ. The QoS Statistics message is only used if the QoS Class Establishment message defined in section 9.4 is implemented. The contents of the VPI/VCI fields in the QoS Class Statistics request message are ignored. All of the count fields in the success response message refer only to the specified QoS class. The HEC Error Count and Invalid VPI/VCI Count fields are not specific to a QoS class and must be set to zero. Any of the other count fields not supported on a per QoS class basis must be set to zero in the success response message. The QoS Class Statistics message is:
Message Type = 51
6.3. Report Connection State Message
The Report Connection State message is used to ask an input port to report the connection state for a single virtual channel connection, a single virtual path connection, or the entire input port ๐. The Report Connection State message is:
Message Type = 52
The Report Connection State request message has the following 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|V|x x| Input VPI | Input VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Input Port ๐ This identifies the port number of the input port whose connection state is being requested.
Flags ๐
A: All Connections If the All Connections flag is set, the message requests the connection state for all virtual path connections and virtual channel connections that arrive at the input port specified by the Input Port field. In this case, the Input VPI and Input VCI fields and the VPI/VCI flag are unused ๐.
V: VPI/VCI If the All Connections flag is zero and the VPI/VCI flag is set, the message requests the connection state for the virtual path connection that arrives at the input port specified by the Input Port and Input VPI fields. If the specified Input VPI identifies a virtual path connection (i.e. a single switched virtual path), the state for that connection is requested. If the specified Input VPI identifies a virtual path containing virtual channel connections, the message requests the connection state for all virtual channel connections that belong to the specified virtual path. The Input VCI field is not used.
If the All Connections flag is zero and the VPI/VCI flag is also zero, this message is asking about the single virtual channel connection that arrives at the input port named by the Port, Input VPI and Input VCI fields. Super specific, very intentional ๐ฏ
- x: Unused.
Input VPI / Input VCI: These fields point to the exact virtual path connection, virtual path, or virtual channel connection you want the state for ๐ฆ 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 that path), the Input VCI field is not used. If the request doesn't need a VPC or VCC to be named at all, the Input VPI and Input VCI fields are not used either ๐
The Report Connection State 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Connection Records ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Input Port: Same as the Input Port field in the request message. It tells you which input port's connection state is being reported ๐ธ
Sequence Number: If the connection state doesn't fit in one success response, every follow-up 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 ๐
Connection Records: Each success response MUST contain one or more Connection Records. Each one describes a single point-to-point or point-to-multipoint virtual path connection or virtual channel connection โจ The Connection Records in one success response MUST NOT make the packet longer than the maximum transmission unit the encapsulation defines. If everything doesn't fit, you send multiple success responses, and all of them MUST carry the same Input Port and Transaction Identifier fields as the request. A single Connection Record MUST NOT be split across multiple success responses. The More flag on the last Connection Record in a success response tells you whether the answer is finished or whether more success responses should be expected for that same request ๐ซถ
Each Connection Record looks like this:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|V|P|M| Input VPI | Input VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Output Branch Records ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags
- A: All Connections
- V: VPI/VCI: For the first Connection Record in each success response, the All Connections and VPI/VCI flags MUST be the same as the ones in the request. For the Connection Records after that, these flags aren't used ๐
- P: VPC: If set, this Connection Record is about a virtual path connection. If zero, it's about a virtual channel connection ๐ฆ
- M: More: If set, another Connection Record answering the same request is coming, either in this same success response or in a later one. If zero, this is the last Connection Record in this success response, and no more success responses will go out for the current request. The response is now complete, so you can breathe ๐ญ
Input VPI / Input VCI: The input VPI and VCI of the connection described in this Connection Record. If the VPC flag is set, the Input VCI field is unused ๐
Output Branch Records: Each Connection Record MUST contain one or more Output Branch Records. Each one describes a single output branch of the connection named by the Input VPI and Input VCI fields. A point-to-point connection only needs one Output Branch Record, while a point-to-multipoint connection needs several. The last Output Branch Record in each Connection Record is marked by the Last Branch flag. If a point-to-multipoint connection has too many output branches to fit in one Connection Record inside one success response, it can be reported with multiple Connection Records across multiple success responses ๐
Each Output Branch Record looks like this:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|x x x| Output VPI | Output VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Output Port: The output port of the switch that this output branch is routed to ๐ง
Flags
- L: Last Branch: If set, this is the last Output Branch Record of this Connection Record. If zero, one or more further Output Branch Records are coming. If this is the last Output Branch Record in the message and the Last Branch flag is zero, the remaining output branches of the same connection will show up in another Connection Record. That Connection Record will be the first one in the next success response, and it MUST have the same Input VPI and Input VCI values as the current Connection Record ๐
- x: Unused.
Output VPI / Output VCI: The output VPI and VCI of the output branch described in this Output Branch Record. If this Output Branch Record belongs to a Connection Record for a virtual path connection (the VPC flag is set), the Output VCI field is unused ๐
A Report Connection State request MAY be issued no matter what the Port Status or the Line Status of the target switch port is ๐ธ
If the Input Port in the request is valid and the All Connections flag is set, but no connections are set up on that port, a failure response MUST be returned with the code field set to, "Failure specific to the particular message type." For the Report Connection State message, that failure code means no connections matching the request were found ๐ This failure message SHOULD also be returned if the Input Port in the request is valid, the All Connections flag is zero, and no connections on that port match the specified virtual path connection, virtual path, or virtual channel connection. The vibes are lowkey strict here, bestie, but it keeps everyone honest ๐ซถ
7. Configuration Messages โจ
The configuration messages let the controller find out what the switch is capable of ๐ฅ Three configuration request messages are defined: Switch, Port, and All Ports ๐
All configuration request messages have 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7.1. Switch Configuration Message โจ
okay bestie, the Switch Configuration message is how you ask the switch for its global config, meaning the stuff that isn't tied to one specific port ๐
the message type is:
Message Type = 64
the Port field isn't used in the request ๐
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Firmware Version Number | Window Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switch Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Switch Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Firmware Version Number ๐พ this is the version of the switch control firmware that's installed.
Window Size ๐ช this is the most unacknowledged request messages the controller MAY send without any chance of them getting lost. It's there so requests don't get dropped when the switch's receive buffer overflows. It's only a hint to the controller, though. If it wants, the controller MAY try out higher and lower window sizes to heuristically figure out the best one ๐ง
Switch Type ๐ท๏ธ this is a 16-bit field the manufacturer assigns. (For this purpose, the manufacturer is treated as whoever owns the OUI in the Switch Name field.) It identifies the product. Combine it with that OUI and the product is uniquely identified, and Network Management MAY use that to look up product info in a database ๐
Switch Name ๐ชช this is a 48-bit value that has to be unique within the device's operational context. If it's available, a 48-bit IEEE 802 MAC address MAY be used as the Switch Name. The most significant 24 bits of the Switch Name MUST be an Organizationally Unique Identifier (OUI) that identifies the switch manufacturer ๐
7.2. Port Configuration Message ๐ฆ
the Port Configuration message asks the switch for the config info of a single port. The Port field in the request is where you say which port you mean ๐ฏ
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V|M|L|R| Min VPI |Q|x x x| Max VPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min VCI | Max VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Cell Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transmit Cell Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Status | Port Type | Line Status | Priorities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Physical Slot Number | Physical Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Port ๐ this is the switch port the config info is about. It covers both the input and output sides of that port. Port numbers are 32 bits and the switch allocates them. The switch MAY split those 32 bits into subfields that match the physical layout of its hardware (like physical slot and port). That structure can be shown in the Physical Slot Number and Physical Port Number fields ๐งฉ
Flags ๐ฉ
- V: VP Switching ๐ if this is set, the input port can do virtual path switching. If it's zero, the input port can only do virtual channel switching.
- M: Multicast Labels ๐ท๏ธ if this is set, the output port can give each output branch of a point-to-multipoint tree its own label. If it's zero, it can't do that.
- L: Logical Multicast ๐ฟ if this is set, the output port can handle more than one branch from any point-to-multipoint connection. People often call this logical multicast. If it's zero, the output port only supports a single output branch per point-to-multipoint connection.
- R: Label Range ๐๏ธ if this is set, the switch port can reallocate its VPI label range or its VCI label range, so it accepts the Label Range message. If it's zero, the port doesn't accept Label Range messages.
- Q: QoS โญ if this is set, the switch port can handle the Quality of Service messages defined in section 9 of this specification. If it's zero, the port doesn't accept those messages.
- x: Unused ๐ซฅ
Min VPI ๐ฝ this is the default minimum incoming VPI value the input port's connection table supports, and it's one that MAY be controlled by GSMP. The Label Range message does not change this value ๐ โโ๏ธ
Max VPI ๐ผ this is the default maximum incoming VPI value the input port's connection table supports, and it's one that MAY be controlled by GSMP. The Label Range message does not change this value either ๐ โโ๏ธ
at power-on, after a hardware reset, and after the Reset Input Port function of the Port Management message, the input port MUST handle every VPI value from Min VPI to Max VPI inclusive, and GSMP MUST be able to control every value in that range ๐ช. It SHOULD be noted that the Min VPI to Max VPI range only covers the incoming VPIs the port can support. No restriction is placed on the outgoing VPIs that get written into the cell header ๐จ. If the switch doesn't support virtual paths, it's fine for Min VPI and Max VPI to be the same value, most likely zero 0๏ธโฃ
using the Label Range message lets you change which VPIs 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 has done ๐ซ
Min VCI ๐ฝ this is the default minimum incoming VCI value the input port's connection table can support, and it's one that MAY be controlled by GSMP. The Label Range message does not change this value ๐ โโ๏ธ
Max VCI ๐ผ this is the default maximum incoming VCI value the input port's connection table can support, and it's one that MAY be controlled by GSMP. The Label Range message does not change this value either ๐ โโ๏ธ
at power-on, after a hardware reset, and after the Reset Input Port function of the Port Management message, the input port MUST handle every VCI value from Min VCI to Max VCI inclusive, for each of the virtual paths in the Min VPI to Max VPI range. GSMP MUST be able to control every value in that range too ๐ง. It SHOULD be noted that the Min VCI to Max VCI range only covers the incoming VCIs the port can support on each of those virtual paths. No restriction is placed on the outgoing VCIs written into the cell header ๐ฆ
using the Label Range message lets you change the VCI range 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, no matter what the Label Range message has done ๐
okay this one is a little plot twist ๐: for a port where GSMP is running, the VCI of the GSMP control channel MAY or MAY NOT be reported as lying within Min VCI to Max VCI. A switch SHOULD honor a connection request that specifies the GSMP control channel's VCI value, even if that VCI sits outside the Min VCI to Max VCI range ๐ซถ
Receive Cell Rate ๐ฅ this is the maximum rate of cells that can arrive at the input port, measured in cells/s.
Transmit Cell Rate ๐ค this is the maximum rate of cells that can leave the output port, measured in cells/s. (The Set Transmit Cell Rate function of the Port Management message can change the transmit cell rate of the output port.) ๐ง
Port Status ๐ฆ this gives the administrative state of the port. The defined values of the Port Status field are:
Available: Port Status = 1. The port can both send and receive cells โจ. When a port changes to Available from any other administrative state, all dynamically assigned virtual connections must be cleared and a new Port Session Number must be generated. That's a total reset, bestie ๐
Unavailable: Port Status = 2. The port has been intentionally taken out of service ๐. No cells will be transmitted from this port, and no cells will be received by it.
Internal Loopback: Port Status = 3. The port is out of service and in internal loopback ๐. Cells 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. All of the ATM functions of the input port above the physical layer, e.g. header translation, are performed on those looped back cells ๐ง.
External Loopback: Port Status = 4. The port is out of service and in external loopback ๐ธ. Cells arriving at the input port from the external communications link are immediately looped back to the link at the physical layer, without entering the input port. None of the ATM functions of the input port above the physical layer are performed on those looped back cells. Very clean, very direct ๐ซถ.
Bothway Loopback: Port Status = 5. The port is out of service and in both internal and external loopback at the same time ๐.
The Port Status of the port that the GSMP session controlling the switch runs over must be declared Available. The controller will ignore any other Port Status for this port ๐. The Port Status of switch ports after power-on initialization is not defined by GSMP, so don't go looking for it there ๐.
Port Type
This is the type of physical transmission interface for this port ๐. The values are defined by the atmIfType object in the Ipsilon IP Switch MIB [IpsilonMIB].
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 both send and receive cells. When the Line Status changes to Up from either the Down or Test states, a new Port Session Number must be generated ๐ฆ.
Down: Line Status = 2. The line can't send or receive cells, or it can't do either one ๐.
Test: Line Status = 3. The port or line is in a test mode, for example during power-on test ๐งช.
Priorities
This is how many different priority levels this output port can assign to virtual connections ๐ถ. Zero is invalid in this field. If an output port can support "Q" priorities, the highest priority is numbered zero and the lowest is numbered "Q-1". Offering different qualities of service to different connections based on their priority is assumed to be a property of the switch's output port ๐. It may be assumed that for connections sharing the same output port, a cell on a higher priority connection is much more likely to leave the switch first than a cell on a lower priority connection, if both are in the switch at the same time ๐โโ๏ธ.
Physical Slot Number
This is where the port's slot physically is ๐งฑ. It's an unsigned 16-bit integer that can be any value except 0xFFFF, and 0xFFFF means "unknown" ๐คทโโ๏ธ. GSMP doesn't use the Physical Slot Number at all. It's just there to help network management with logging, port naming, and graphical representation ๐บ๏ธ.
Physical Port Number
This is where the port sits within its slot ๐. It's an unsigned 16-bit integer that can be any value except 0xFFFF, and 0xFFFF again means "unknown" ๐. GSMP doesn't use the Physical Port Number either. It's there for the same network management things: 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 give the same Physical Slot Number and Physical Port Number combination. The same Port Number must give the same Physical Slot Number and Physical Port Number within a single GSMP session ๐. If both the Physical Slot Number and the Physical Port Number say "unknown", the physical location of the switch ports may be found by looking up the product identity in a database, which reveals the physical meaning of the 32-bit Port Number ๐ต๏ธโโ๏ธโจ.
7.3 All Ports Configuration Message
Okay, this one is the "give me everything" request ๐. The All Ports Configuration message asks the switch for the configuration information of all of its ports ๐ . The message looks like this:
Message Type = 66
The 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Records | Port Record Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Port Records ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 make the packet length go over the maximum transmission unit defined by the encapsulation ๐ฆ. If a switch has more ports than fit in one success response, it must send multiple success response messages ๐งฉ. Every success response sent for the same request must have the same Transaction Identifier as the request, and the same value in the Number of Records field ๐. All of those success responses, except the last one, 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 inside a success response must be complete, so a single Port record must not get split across multiple success response messages ๐ โโ๏ธ๐.
Port Record Length
This field gives the length of each port record in bytes. It's currently 32 ๐. The Port Record Length field also leaves room for future fields at the end of the port record, while staying compatible with earlier versions of the protocol ๐ฎ.
Port Records
These follow in the rest of the message ๐งพ. Each port 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V|M|L|R| Min VPI |Q|x x x| Max VPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min VCI | Max VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Cell Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transmit Cell Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Status | Port Type | Line Status | Priorities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Physical Slot Number | Physical Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields in the Port Record are defined exactly the same way as in the Port Configuration message ๐๐.
8. Event Messages โจ
okay so event messages are how the switch taps the controller on the shoulder and says "hey, something just happened!" ๐ The controller never has to reply to them, so they're not acknowledged. The Result field and the Code field in the header aren't used here, so they should be set to zero. And event messages are not sent during initialization, so nothing gets spammed at the controller while everything is still booting ๐ซถ Here's the 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | VPI | VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Event Sequence Number is the current value of the Event Sequence Number for the specified port. It's set to zero when the port is initialized, and it goes up by one every time the port detects an asynchronous event the switch would normally report with an Event message. The Event Sequence Number must be incremented each time an event occurs, even if flow control stops the switch from actually sending that Event message. Main character energy ๐
VPI/VCI is the VPI/VCI that the event message is about. 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 port sends an Event message, it must set the Event Flag on that port that matches the event's type. The port is not permitted to send another Event message of the same type until that 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 trick that stops the switch from flooding the controller with event messages ๐ฆ The Event Sequence Number of the port must go up every time an event is detected on that port, even if flow control is blocking the report. That way the controller can tell it missed some events that happened on the port ๐ต๏ธโโ๏ธ
8.1 Port Up Message
The Port Up message tells the controller that a port's Line Status has changed from either Down or Test to Up. When a port's Line Status changes to Up from Down or Test, a new Port Session Number must be generated, preferably using some form of random number. That new number goes in the Port Session Number field. The VPI/VCI field isn't used here, so it's set to zero. The Port Up message is:
Message Type = 80
8.2 Port Down Message
The Port Down message tells the controller that a port's Line Status has changed from Up to Down. 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 goes in the Port Session Number field. The VPI/VCI field isn't used and is set to zero. The Port Down message is:
Message Type = 81
8.3 Invalid VPI/VCI Message
The Invalid VPI/VCI message is sent to tell the controller that one or more cells arrived at an input port with a VPI/VCI that isn't currently allocated to an assigned connection. The input port goes in the Port field, and the VPI/VCI goes in the VPI/VCI field. The Invalid VPI/VCI message is:
Message Type = 82
8.4 New Port Message
The New Port message tells the controller that a new port has been added to the switch. The new port's number goes in the Port field. A new Port Session Number must be assigned, preferably using some form of random number. That new Port Session Number goes in the Port Session Number field. The state of the new port is undefined, so the VPI/VCI field isn't used and is set to zero. The New Port message is:
Message Type = 83
8.5 Dead Port Message
The Dead Port message tells the controller that a port has been removed from the switch. The port's number goes in the Port field. The Port Session Number that was valid before the port was removed goes in the Port Session Number field. The VPI/VCI fields aren't used and are set to zero. The Dead Port message is:
Message Type = 84
9. Quality of Service Messages ๐
The GSMP Quality of Service (QoS) messages let a controller group virtual path connections and virtual channel connections into QoS classes, then hand out QoS resources to those classes and to individual connections ๐ At initialization, the switch describes its QoS capabilities to the controller using the abstract switch model, through the QoS Configuration message. The controller sends Scheduler Establishment messages to set up the scheduler on each switch output port, and it sends QoS Class Establishment messages to set up QoS classes. Connections can be added to or removed from a QoS class with the QoS Connection Management message. QoS resources can also be given to individual connections with that same QoS Connection Management message. Connections that only need the scheduler can use the simple connection management messages from Section 3, "Connection Management Messages." โจ
9.1 Abstract Switch Model โจ
okay bestie, so the abstract switch model (fig. 1) is how a switch tells its controller what its core QoS powers are ๐ It has four main parts: a policer, a classifier, a regulator, and a scheduler ๐ The classifier groups multiple connections (VPCs or VCCs) into a QoS class so that QoS resources get shared by the class as a whole ๐ซถ Inside one QoS class, members aren't treated differently from each other when it comes to the QoS resources they get ๐ญ BUT the ordering of cells within each constituent VPC or VCC must be preserved on exit from the switch, so nothing gets shuffled ๐ Connections aren't forced to join a QoS class with other connections, either. They can also get their own individual QoS resources ๐ฆ
VPC/VCCs Policer Classifier Regulator Scheduler
+--+ +----+ +--------+
-------->| |---->| | | |
+--+ | | | |
| | | |
+--+ | | +----+ | |
-------->| |---->| | | |--------->| |
+--+ | | | |conforming| |
| |------>| | | |
+--+ | | QoS | | | |
-------->| |---->| | Class | |--------->| |
+--+ | | +----+ excess | |
| | | |
+--+ | | | |
-------->| |---->| | | |
+--+ +----+ | |
| |
| | Output
| | Port
| |---------->
| |
| |
+--+ +----+ | |
-------->| |---->| | | |
+--+ | | | |
| | | |
+--+ | | +----+ | |
-------->| |---->| | | |--------->| |
+--+ | | | |conforming| |
| |------>| | | |
+--+ | | QoS | | | |
-------->| |---->| | Class | |--------->| |
+--+ | | +----+ excess | |
| | | |
+--+ | | | |
-------->| |---->| | | |
+--+ +----+ | |
+--------+
Fig. 1: Abstract Switch Model
The policer is a single input, single output device that can discard or tag cells ๐ง You can apply a policer to each individual connection, or to the total traffic of a whole QoS class. Either way, its job is to enforce an upper bound on the traffic on a connection or on a QoS class ๐
The regulator sits after the policer and classifier, and it can do either a policing function or a shaping function ๐ The policing function checks each cell and labels it as conforming to the rate set by the regulator parameters or as being in excess of that rate. Then one of three actions can be specified for each cell: tagging, discard, or differentiated scheduling โจ Tagging sets the CLP bit of cells that are in excess of the rate defined by the regulator parameters. Discard just throws away the excess cells ๐๏ธ Differentiated scheduling lets conforming cells and excess cells get scheduled for service at different points in the scheduler. So conforming cells could get service with a QoS guarantee, while excess cells get best-effort service ๐ Honestly, this one is a bit tricky, because it has to work without reordering cells within each connection ๐คฏ
The shaping function of the regulator paces cells out, for each QoS class or individual connection, at the rate set by the regulator parameters ๐ฆ No jitter requirement may be specified, and no specific jitter guarantee is given. If traffic shows up on a QoS class or individual connection faster than the output rate, that traffic gets delayed. If the delayed traffic for any QoS class or individual connection goes past a bound, it gets discarded ๐ Differentiated scheduling works with the shaper too, but it's used a little differently than with policing. Conforming traffic is whatever leaves the shaper because of the shaping process, and the conforming pointer says where in the scheduler structure that traffic gets scheduled for output. This is usually the highest priority of the scheduler, but the GSMP specification lets other priorities be specified too ๐ If an excess pointer is also enabled for a QoS class or individual connection, traffic beyond the shaper's rate can still be transmitted. Where the excess pointer sits in the scheduler structure decides how much extra traffic gets supported, which is left undefined. Excess traffic may be tagged if required, as long as tagging is supported. The excess pointer gets the same share of bandwidth that a best-effort class or connection would get at that same spot in the scheduler structure ๐ซถ
Where the classifier and regulator live in the switch matters a lot ๐ If the classifier is on an input port, only virtual connections arriving at that input port can be grouped into a QoS class. If the classifier is centralized, or on an output port, virtual connections arriving at any input port can be grouped into the same QoS class โจ If the regulator is on an output port, every virtual connection in a QoS class going through that regulator has to exit the switch at that output port.
However, if the regulator is centralized or on an input port, virtual connections in the same QoS class can be switched out to different output ports ๐ธ Each switch port must specify where its classifier and regulator functions are.
The scheduler lives on the output port, as you can see in fig. 2 ๐ It splits the bandwidth of the output link between the QoS classes and individual connections. It's a two-level scheduler: a priority scheduler on one level, and a FIFO or a weighted scheduler on the other. Up to 255 strict priority levels may be supported. Traffic at any priority level may only be transmitted if no traffic is queued at any higher priority level ๐ Within each priority level, a weighted scheduler may be defined. Every leaf of the scheduler tree is connected to a waiting room. The waiting room has two jobs. When it gets service from the scheduler, it must select a QoS class or individual connection for transmission. When it's told that traffic has arrived on a QoS class or connection, it must decide whether there's enough room left to accept that traffic. If there isn't, that traffic must be discarded ๐ญ The waiting room has a size parameter that says how much traffic it can accept, and other queueing parameters can be attached to it too. Multiple conforming and excess pointers from the regulators can point at each waiting room. Inside one waiting room, the connections sharing it may support weighted sharing between them ๐ง
From Waiting FIFO/Weighted Priority
Regulator Room Scheduler Scheduler
Net +---+
+------+ Weight | |
---------->| |-%-------->| 0 |------\
+------+ | | \
+---+ \
---------->+------+ |
| |-%--\ +---+ |
---------->+------+ \---->| | |
| 1 |---\ |
+------+ /---->| | \ \
---------->| |-%--/ +---+ \ \ +---+
+------+ \ \-->| |
\----->| |--------->
---------->+------+ /-->| | Output
---------->| |-%-\ / +---+ Port
---------->+------+ \ /
\ +---+ /
+------+ \--->| | /
---------->| |-%-------->| 2 |-----/
+------+ /--->| |
/ +---+
+------+ /
---------->| |-%-/
+------+
Fig. 2: The Scheduler
9.2 QoS Configuration Message ๐
the QoS Configuration message is how the controller finds out the QoS capabilities of each switch port, described in terms of the abstract switch model ๐ฅ Here's its message type:
Message Type = 96
The QoS Configuration request 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The QoS Configuration success response message has the following 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scheduler Flags | Regulator Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Excess Capabilities | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hi Sharing | Lo Sharing | Max Classes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Default Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Default Discard Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Buffer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Shaper Buffer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scaling Factor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Okay bestie, now the good stuff ๐ โจ This part is all about what each little field inside the QoS Configuration Message actually means, so let's go field by field ๐ฆ
Port
Port ๐ธ is the switch port the QoS configuration info is about. It covers both the input side and the output side of that port, so you get the full picture in one go ๐ซถ
Scheduler Flags
Okay so the Scheduler Flags field is giving bit-by-bit vibes ๐ฅ Here's the layout:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|W|Q|S|G|D|F|M|B|I|x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
W: Weighted Connections ๐ Bit 0 is the one. If it's set, a weighted service algorithm (like weighted round-robin) is available for handing out service to individual connections, in at least some waiting rooms. That means a Connection Weight parameter can be attached to a QoS Connection Management message. Not every waiting room at every priority level can do this though, so the way you find out whether a particular waiting room can support it is by issuing a QoS Connection Management message and seeing what happens ๐
Q: Weighted QoS Classes ๐ Bit 1, if set, means a weighted service algorithm (again, like weighted round-robin) is available for giving service to QoS classes, in at least some waiting rooms. So a QoS Class Weight parameter can ride along on a QoS Class Establishment message. Same catch as before: not every waiting room at every priority level can do it, and you'll discover which ones can when you send a QoS Class Establishment message ๐
S: Shared Waiting Room ๐ฆ Bit 2, if set, means multiple QoS classes and multiple connections can be scheduled inside a single waiting room. This is expected to be the normal case, honestly the main character behaviour ๐ If bit 2 is zero, then only one QoS class or one connection can be pointed at any single waiting room.
G: Global Max Classes ๐ Bit 3, if set, tells you the Max Classes field is the maximum number of QoS classes the entire switch can support. If it's zero, then Max Classes is the maximum for just this switch port ๐
D: Packet Discard ๐ Bit 4, if set, means the scheduler on this output port can do packet discard. Packet discard is a discard algorithm that knows where AAL-5 packet boundaries are and tries to throw away whole packets instead of random bits and pieces (rude ๐ญ). It doesn't name one specific algorithm, but Early Packet Discard (EPD) is likely to be the most common one. Other possible options include "push from front" schemes, dynamic threshold, or Random Early Detection (RED). The only parameters the packet discard algorithm can see through GSMP are the Size and Discard Threshold of the waiting room โจ
F: Frame-Based Scheduling ๐ฅ Bit 5, if set, means the scheduler on this output port can do frame-based scheduling. Here's the tea: a connection only gets scheduled for transmission once a complete AAL-5 packet is available. Once it's scheduled, all the cells from one or more complete packets from that connection go out together, without getting interleaved with any other cells on that output port, no matter what priority they have ๐ Frame-based scheduling is a property of the waiting room and gets requested in the Scheduler Establishment message. A QoS class can be routed through a waiting room configured this way, and then each of its component connections gets frame-based scheduling. For bandwidth to be distributed correctly, each QoS class that needs frame-based scheduling should have its own waiting room ๐ซถ
M: VC Merging ๐ง Bit 6, if set, means the scheduler on this output port can do VC merging by some mechanism other than frame-based scheduling. VC merging is when the switch can merge two or more incoming virtual connections, multipoint-to-point, onto one outgoing virtual connection, without interleaving cells from different AAL-5 packets that share the same VPI/VCI. It's different from frame-based scheduling though, because cells with a different VPI/VCI can get interleaved with a VC merging connection's cells. So higher priority cells can cut in while a packet on a lower priority VC merging connection is going out ๐ญ Most switches do VC merging by using frame-based scheduling. VC merging is also a property of the waiting room, requested in the Scheduler Establishment message, and a QoS class can be routed through a waiting room configured with it, in which case each component connection gets VC merging ๐ธ
B: Shared Buffer ๐ซง Bit 7, if set, means at least some of the buffer space given by the Max Buffer field is shared with other ports. If it's zero, then the buffer space from Max Buffer is not shared with other ports ๐
I: Identical Ports ๐ Bit 8, if set, means every port on the switch has identical QoS capabilities. When this bit is set, the controller doesn't have to ask for the QoS configuration of each port one by one, because they're all the same. Lazy but iconic ๐
x: Bits 9--15 of the Scheduler Flags field are not used. ๐ Nothing to see here, babe.
Regulator Flags
Next up is the Regulator Flags field, and it's giving policing and shaping vibes โจ
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|Q|I O|P|S|H|M|x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C: Connection Policing ๐ Bit 0 being set means this input port supports policing of individual incoming connections. The parameters for the policer are specified in the QoS Connection Management message when the connection gets established ๐ฆ
Q: QoS Class Policing ๐ If bit 1 is set, a policer function is available to police each QoS class on the output from the classifier. The parameters for this policer are specified in the QoS Class Establishment message. If bit 1 is zero, there's no policer function available to police a QoS class ๐
IO: QoS Class Location ๐ Bits 2 and 3 together say where the classifier and regulator functions live. If both bits 2 and 3 are zero, no classifier or regulator function is available to this port ๐
- If bit 2 is set and bit 3 is zero, the classifier and regulator functions are on the input port. That means only virtual connections arriving at this input port can get grouped into QoS classes by this classifier. But connections in a QoS class coming out of this regulator can be switched to any output port โจ
- If bit 2 is zero and bit 3 is set, the classifier and regulator functions are on the output port. Virtual connections arriving at any input port can get grouped into QoS classes by this classifier. The catch is that all connections in any QoS class coming out of this regulator can only be switched to this output port ๐
- If both bits 2 and 3 are set, this switch port has access to centralized classifier and regulator functions. Virtual connections arriving at any input port can be grouped into a QoS class by this classifier, and connections in a QoS class coming out of this regulator can be switched to any output port ๐
Regulator Function ๐ง
P: If bit 4 is set, the regulator can support the policing function ๐ธ
S: If bit 5 is set, the regulator can support the shaping function on all priority levels of the scheduler ๐ฅ
H: If bit 5 is zero and bit 6 is set, the regulator can support the shaping function, but only on the highest priority level of the scheduler. All connections and QoS classes using this regulator must be routed to a waiting room at the highest priority level of the scheduler. Bestie, that's a lot of rules in one bit, but it's giving very specific energy ๐ญ๐ซถ
M: QoS Multicast ๐ If bit 7 of the Regulator Flags field is set, any point-to-multipoint connection arriving on this input port must use the same QoS parameters for all output branches. Those parameters come from the GSMP Quality of Service messages. It's giving "everyone at the party gets the same outfit" ๐โจ no mix and match!
x: Bits 8--15 of the Regulator Flags field are not used ๐
Excess Capabilities ๐
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|T|S|A|B|x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Okay so the Excess Capabilities field is split into two halves, the Policer and the Shaper ๐ฆ
Policer:
- D: If bit 0 of the Excess Capabilities field is set, the policer function of the regulator is able to support discard ๐๏ธ
- T: If bit 1 of the Excess Capabilities field is set, the policer function of the regulator is able to support tagging ๐ท๏ธ
- S: If bit 2 of the Excess Capabilities field is set, the policer function of the regulator is able to support differentiated scheduling ๐
Shaper:
- A: If bit 3 of the Excess Capabilities field is set, the shaper function of the regulator is able to support tagging ๐ท๏ธ
- B: If bit 4 of the Excess Capabilities field is set, the shaper function of the regulator is able to support differentiated scheduling ๐
- x: Bits 5--15 of the Excess Capabilities field are not used ๐
Hi Sharing and Lo Sharing ๐ these two together define a range of priority levels that support weighted sharing. Every priority level from Lo Sharing up to Hi Sharing, inclusive, supports it, and that's the iconic part โจ A priority level with weighted sharing runs a weighted sharing algorithm (weighted round-robin is one example) between the waiting rooms at that level. So the output link bandwidth at that level gets split between those waiting rooms according to each one's Net Weight parameter. Bestie, that's fair sharing with receipts ๐ And if both parameters are 0xFF, the output port doesn't support weighted sharing at any priority level ๐
Max Classes ๐ If bit 3 of the Scheduler Flags field is zero, Max Classes is the maximum number of QoS classes this switch port can support. In that case, the number isn't affected by how many QoS classes other switch ports are using. If bit 3 of the Scheduler Flags field is set, Max Classes is the maximum number of QoS classes for the entire switch instead. Then it's assumed the classes can be spread out across the various switch ports ๐ง
Default Size ๐ This is the size of waiting room this output port allocates by default. The Scheduler Establishment message can specify the actual size instead. The size of a waiting room is the maximum number of cells allowed to wait for transmission through that waiting room. Any cells arriving after that number are discarded ๐๏ธ no sneaking in past the bouncer ๐
Default Discard Threshold ๐ธ This is the discard threshold this output port allocates by default. The Scheduler Establishment message can specify the actual value instead. The discard threshold is the number of cells waiting for transmission through a waiting room. Once that number is passed, further arriving cells are subject to a discard mechanism ๐
Max Buffer โจ This is the maximum amount of buffer space, measured in cells, available to this port. If bit 7 of the Scheduler Flags field is zero, this buffer space isn't shared with other ports. If bit 7 of the Scheduler Flags field is set, at least some of this buffer space is shared with other ports ๐ซถ
Max Shaper Buffer ๐ฆ This is the maximum amount of buffer space, measured in cells, available to a QoS connection or a QoS class within the shaper function of the regulator. The shaper buffer space is likely shared among all the QoS classes and QoS connections using the shaper. So there's no guarantee that any particular QoS class or QoS connection will actually get the amount the Max Shaper Buffer field defines ๐ญ
Scaling Factor ๐ง The QoS Class Establishment and QoS Connection Management messages need parameters that describe cell rates, in cells per second, or their reciprocal, cell interarrival periods, in seconds per cell. To fit these into a 32-bit unsigned integer, the switch defines a Scaling Factor for them. Picking the right Scaling Factor lets the switch choose the range and granularity of rate or time that the 32-bit unsigned integer can express ๐ฅ More details are in the discussion of the UPC Parameters field of the QoS Connection Management message ๐
9.3 Scheduler Establishment Message โจ
Okay bestie, this is the message that sets up the scheduler on a specific output port ๐ It configures a waiting room, attaches it to a leaf of the scheduler tree, and hands back a Scheduler Identifier so you can reference that waiting room later ๐ You can also use it to modify the parameters of a waiting room that's already established ๐ฆ
Scheduler Identifiers in the range 0--255 are the defaults ๐ธ They're used for the priority levels that can show up in the Class of Service field of Connection Management messages, so you don't need an explicit Scheduler Establishment message first ๐ซถ Each default is a single waiting room with default parameters, set up as a FIFO queue, on each of the valid scheduler priority levels. This is what lets Connection Management messages keep specifying QoS as a priority without touching any of the QoS messages, which is honestly iconic ๐ The number of priority levels the scheduler has is given in the Priorities field of the Port Configuration and All Ports Configuration messages ๐
The Scheduler Establishment Message is:
Message Type = 97
The Scheduler Establishment request and success response messages have the following 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scheduler Identifier | Net Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |D|F|M|W|x x x x| Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Waiting Room Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discard Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Scheduler Identifier
The controller picks the Scheduler Identifier ๐ฏ It's how you identify the waiting room being established or modified in future messages. It comes from a namespace that's local to the switch port. A Scheduler Identifier in the Scheduler Establishment message must be greater than 0x00FF but less than 0xFFFF. The values 0 -- 0x00FF are reserved for use as default values, and each default value maps directly to one of the scheduler priority levels. The value 0xFFFF is reserved for use in the QoS Connection Management message. Main character energy ๐
Net Weight
Net Weight is the share of the bandwidth available to the priority level (the one given by the Priority field) that this waiting room should get ๐ It's only valid if that priority level supports weighted sharing.
The Net Weight is an unsigned 16-bit field that holds a binary fraction. So the bandwidth share, as a fraction of the bandwidth available to the priority level, is:
Bandwidth share = Net Weight * 2**(-16)
A Net Weight of zero means equal sharing between all waiting rooms sharing this priority level that also request a Net Weight of zero. Even though it's a 16-bit field, the accuracy of the bandwidth sharing depends on the hardware and isn't specified ๐
If weighted sharing isn't required at a particular priority level, a waiting room with a Net Weight value of 0xFFFF must be specified for that priority level. A priority level that doesn't support weighted sharing can only support a single waiting room ๐
Flags
- D: Packet Discard: Bit 0 of the Flags field, if set, indicates that packet discard is required on all connections and QoS classes routed through this waiting room ๐ฅ
- F: Frame-Based Scheduling: Bit 1 of the Flags field, if set, indicates that frame-based scheduling is required on all connections and QoS classes routed through this waiting room. In frame-based scheduling, a connection is only scheduled for transmission when a complete AAL-5 packet is available. When a connection gets scheduled, all cells from one or more complete packets on that connection are transmitted without being interleaved with any other cells on that output port ๐ฆ A QoS class can be routed through a waiting room configured with frame-based scheduling, and then each component connection of the QoS class gets frame-based scheduling. For correct bandwidth distribution, each QoS class that requires frame-based scheduling should have its own waiting room ๐
- M: VC Merging: Bit 2 of the Scheduler Flags field, if set, indicates that VC merging is required on all connections and QoS classes routed through this waiting room. VC merging lets two or more incoming virtual connections merge multipoint-to-point onto a single outgoing virtual connection, without interleaving cells from different AAL-5 packets that bear the same VPI/VCI. VC merging differs from frame-based scheduling because cells with a different VPI/VCI may be interleaved with those of a multipoint-to-point VC merging connection. Most switches do VC merging by using frame-based scheduling, which is so relatable ๐ A QoS class can be routed through a waiting room configured with VC merging, and then each component connection of the QoS class gets VC merging โจ
- W: Weighted Scheduling: Bit 3 of the Flags field, if set, indicates that weighted scheduling is required on all connections and QoS classes routed through this waiting room. Every connection and QoS class routed through this waiting room will require a Connection Weight or a QoS Class Weight, respectively. The Connection Weight is specified in the QoS Connection Management message, and the QoS Class Weight is specified in the QoS Class Establishment message. If weighted scheduling within this waiting room is unavailable, a failure response message must be returned indicating, "Weighted scheduling within this waiting room is unavailable."
Bit 3 of the Flags field, if zero, indicates that this waiting room should be configured as a single FIFO queue. All cells arriving at this waiting room get first-in-first-out service. If Frame-Based Scheduling or VC Merging are also selected, the strict first-in-first-out service discipline gets modified by the requirement to support Frame-Based Scheduling or VC Merging ๐
- x: Bits 4--7 of the Flags field are not used.
Priority
Specifies the priority level in the scheduler to which the waiting room should be attached. Priorities are numbered from zero, and priority level zero is the highest priority ๐
Waiting Room Size
This is the required size of the waiting room. The size of a waiting room is the maximum number of cells allowed to wait for transmission via that waiting room. Any further cells arriving at that waiting room beyond this number will be discarded ๐ If the switch can't grant the size you asked for in the Scheduler Establishment request message, it may reply with the actual size it allocated in the Waiting Room Size field of the success response message. A value of zero for the Waiting Room Size means the default value should be used ๐
Discard Threshold
This is the required value of the discard threshold. The discard threshold is the number of cells waiting for transmission via a waiting room after which further arriving cells become subject to a discard mechanism ๐ธ The value of the Discard Threshold must be less than or equal to the value of the Waiting Room Size parameter for any given waiting room. If the switch can't grant the discard threshold value you requested in the Scheduler Establishment request message, it may reply with the actual value it allocated in the Discard Threshold field of the success response message. A value of zero for the Discard Threshold means the default value should be used ๐ซถ
9.4 QoS Class Establishment Message โจ
The QoS Class Establishment message configures a QoS class on a specified port, or modifies the parameters of a QoS class that's already established ๐ It configures the classifier and the regulator functions for the QoS class. It also configures the QoS class policer, if a policing function is available for QoS classes ๐
There are two styles of QoS class ๐ฆ In the first style, each component connection of the QoS class can be routed independently to an output port and waiting room, which are specified in its connection management message. In this case, the Scheduler Identifier, and the Excess Scheduler Id if it's required, are specified in the QoS Connection Management message that references this style of QoS class. In the other style, all component connections in the QoS class get routed to the same waiting room on the same output port. In this case, the Output Port, the Scheduler Identifier, and the Excess Scheduler Id if it's required, are specified in the QoS Class Establishment message ๐
okay so the classifier and regulator functions MUST be located together ๐ either on an input port, on an output port, or centralized. each port declares where its classifier and regulator live at initialization using the QoS Configuration message ๐. if they're on an input port, only connections that arrive at that input port can join a QoS class established there ๐ฆ. BUT each connection in that QoS class can still get switched out to a different output port โจ. if they're on an output port, connections arriving at ANY input port MAY join a QoS class established there ๐. however, every connection in that QoS class MUST be switched to that output port ๐ฅ. and for a centralized classifier and regulator, there's no restriction at all on which input ports the connections in a QoS class must arrive on, or which output ports they must be switched to ๐. (fun fact for the centralized case: the actual port in the QoS Class Establishment message is only for admin stuff ๐. any valid Port and Port Session Number that points at a centralized classifier and regulator MAY be used ๐ง)
The QoS Class Establishment message is:
Message Type = 98
The QoS Class Establishment 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QoS Class Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Regulator | Excess Action | QoS Class Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scheduler Identifier | Excess Scheduler Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ QoS Class Policer Parameters ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ QoS Class Regulator Parameters ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
QoS Class Identifier
the controller picks the QoS Class Identifier ๐ง . it's how you point at the QoS class you're establishing or modifying in future QoS Connection Management and QoS Class Establishment messages ๐จ. it comes from a namespace that's global across the WHOLE switch, so no two QoS classes can share an ID no matter which ports they're on ๐ โโ๏ธ. in a QoS Class Establishment message, the QoS Class Identifier MUST be greater than 0 and less than 0xFFFFFFFF ๐.
Regulator
the Regulator field says what the regulator is supposed to do ๐ฆ. there are three options rn: none, policing, and shaping ๐.
None: Regulator = 1
Policing: Regulator = 2
Shaping: Regulator = 3
- None: no regulator operations happen on the cells coming out of the classifier ๐ซถ. they go straight to the waiting room named by the Scheduler Identifier.
- Policing: a token bucket policer gets applied to the QoS class ๐ชฃ. it figures out which cells conform to the policer traffic parameters and which don't ๐. conforming cells go straight to the waiting room named by the Scheduler Identifier โ . what happens to the excess traffic is decided by the Excess Action field, and the policer traffic parameters live in the QoS Class Regulator Parameters fields ๐.
- Shaping: traffic shaping gets applied to the QoS class ๐. cells in a QoS class SHOULD leave the regulator evenly spaced apart, at the rate defined by the QoS Class Regulator Parameters fields ๐ถ. they go straight to the waiting room named by the Scheduler Identifier ๐ . the jitter on the conforming cell stream when it exits the shaping function is not specified ๐คทโโ๏ธ.
Excess Action
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|T|D|S|x x x x x|
+-+-+-+-+-+-+-+-+
T: Tagging ๐ท๏ธ if bit 0 of the Excess Action field is set, every cell sent to the waiting room named by the Excess Scheduler Id gets its CLP bit set ๐. if bit 0 is zero, the CLP bit on those cells stays exactly as it was ๐.
D: Discard ๐๏ธ this one only works when policing is the regulator function ๐ . if the Regulator field says Policing and bit 1 of the Excess Action field is set, every cell the policer marks as in excess of the traffic parameters MUST be discarded ๐. in that case the Excess Scheduler Id isn't used, and bit 0 of the Excess Action field SHOULD be ignored ๐ซ .
S: Differentiated Scheduling ๐ this one acts differently depending on whether policing or shaping is the regulator function ๐ง.
- if the Regulator field says Policing, bit 1 of the Excess Action field is zero, AND bit 2 is set, every cell the policer marks as excess MUST be sent to the waiting room named by the Excess Scheduler Id ๐ฆ. the implementation has to be careful here: within each virtual path connection or virtual channel connection, cells MUST still depart in the same order they arrived ๐ซถ.
- if the Regulator field says Policing, bit 1 is zero, AND bit 2 is also zero, every excess cell MUST go to the waiting room named by the Scheduler Identifier ๐ฏ. the Excess Scheduler Id isn't used in this case.
- if the Regulator field says Shaping and bit 2 is zero, cells move from the QoS class to the waiting room named by the Scheduler Identifier at the rate set by the QoS Class Regulator Parameters ๐ท. the Excess Scheduler Id isn't used here either.
- if the Regulator field says Shaping and bit 2 is set, extra cells get scheduled for transmission by the waiting room named by the Excess Scheduler Id โจ. this lets you allocate a minimum cell rate to the QoS class with the QoS Class Regulator Parameters, and ALSO lets the QoS class share extra bandwidth ๐. that extra share is decided by the parameters of the waiting room named by the Excess Scheduler Id. if the Excess Scheduler Id is in the QoS Class Establishment message, the extra bandwidth gets shared by the whole QoS class ๐ฏ. if it's in each individual QoS Connection Management message, the extra bandwidth belongs to that one connection and is NOT shared by the whole class ๐ โโ๏ธ. again, care MUST be taken in the implementation so that within each virtual path connection or virtual channel connection, cells depart in the same order they arrived โ ๏ธ.
x: Bits 3--7 of the Excess Action field are not used ๐ซง.
QoS Class Weight
if bit 1 of the Scheduler Flags field in the QoS Configuration message says weighted service MAY be applied to a QoS class, then the QoS Class Weight is the share of the waiting room's bandwidth that this QoS class should get ๐.
the QoS Class Weight is an unsigned 16-bit field that holds a binary fraction ๐ข. so the bandwidth share, as a fraction of what the waiting room has, is:
Bandwidth share = QoS Class Weight * 2**(-16)
a QoS Class Weight of zero means equal sharing between ALL the QoS classes using this waiting room that also asked for a weight of zero ๐ค. even though it's a 16-bit field, the accuracy of the bandwidth sharing depends on the hardware and is not specified ๐ ๏ธ.
if the Regulator field of the QoS Class Establishment message says None or Policer, the QoS Class Weight SHOULD be applied to the waiting room named by the Scheduler Identifier ๐. if it says Shaper, the QoS Class Weight SHOULD be applied to the waiting room named by the Excess Scheduler Id ๐ซ.
if the waiting room can't offer weighted sharing for a QoS class, a failure response message SHOULD be returned, with the failure code saying: "This waiting room is unable to offer weighted sharing for a QoS class." ๐ญ
Scheduler Identifier Okay so if all the conforming traffic from this QoS class is headed to the same waiting room on the same output port, this field gives the Scheduler Identifier for the whole class ๐. That ID points at the waiting room, on the output port named in the Output Port field, where all conforming traffic should be sent โจ. Not using it? Set it to 0xFFFF. But if each connection in the class picks its own output port and waiting room, the Scheduler Identifier must be specified in the QoS Connection Management message instead, and this field must be set to 0xFFFF ๐.
Excess Scheduler Id Same energy, but for the leftover traffic ๐ฆ. If all conforming traffic from this QoS class goes to one waiting room on one output port, this field gives the Excess Scheduler Id for the entire class. It points at the waiting room, on the output port named in the Output Port field, where all excess traffic should go ๐ธ. Not used? 0xFFFF. If each connection brings its own output port and waiting room, the Excess Scheduler Id must be specified in the QoS Connection Management message and this field must be 0xFFFF ๐
.
The rules here are a whole vibe, so pay attention bestie ๐. If the Scheduler Id is specified in the QoS Class Establishment message, the Excess Scheduler Id must also be specified in the QoS Class Establishment message (or not used). If the Scheduler Id is specified in the QoS Connection Management message, the Excess Scheduler Id must also be specified in the QoS Connection Management message (or not used).
The Excess Scheduler Id must not point to the same waiting room on the same output port as the Scheduler Identifier. Absolutely do not mix those up ๐.
Output Port If the Scheduler Identifier field in the QoS Establishment message is not 0xFFFF, this field tells you the Output Port that traffic from this QoS class should be routed to ๐ง. If the Scheduler Identifier field in the QoS Establishment message is 0xFFFF, this field is not used ๐.
QoS Class Policer Parameters So a policer function can be applied to a QoS class on output from the classifier, and it works independently of the regulator function ๐. The QoS class policer is basically the same as the connection policer from the QoS Connection Management message. The only difference is that it applies to every cell in the QoS class instead of just the cells from one connection ๐.
The QoS Class Policer Parameters 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QoS Class Increment-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QoS Class Limit-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QoS Class Increment-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QoS Class Limit-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |C|A|x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The definition of these fields is in the UPC Parameters section of the QoS Connection Management message ๐.
QoS Class Regulator Parameters The QoS class regulator is the same as the regulator in the QoS Connection Management message, except it works on every cell in the QoS class rather than only the cells from one connection ๐ฆ.
The QoS Class Regulator Parameters 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QoS Class Regulator Increment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QoS Class Regulator Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The definition of these fields is in the Regulator Parameters section of the QoS Connection Management message ๐ซถ.
9.5 QoS Release Message
The QoS Release message is how you delete a Scheduler Identifier or a QoS Class Identifier and free up every resource attached to it ๐งนโจ.
The QoS Release message is:
Message Type = 99
The QoS Release 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Scheduler Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QoS Class Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Port If the QoS Release message has a Scheduler Identifier, the Port field must contain the Port Number of the switch output port that the Scheduler Identifier applies to ๐ฅ. If it has a QoS Class Identifier instead, any valid Port number works, because the QoS Class Identifier has a global namespace ๐.
Port Session Number This is the current Port Session Number for the port named in the Port field ๐ฆ.
Scheduler Identifier If this field holds 0xFFFF, the QoS Class Identifier in the QoS Class Identifier field should be released ๐. Otherwise, if the value is in the range 0x0100 -- 0xFFFE inclusive, the Scheduler Identifier in this field should be released ๐ธ. A Scheduler Identifier below 0x0100 is invalid in a QoS Release message ๐, because that range is a default value and it can't be released.
QoS Class Identifier If the Scheduler Identifier field holds 0xFFFF, this field gives the QoS Class Identifier to be released ๐.
If the QoS Release message asks for a Scheduler Identifier to be released, but that Scheduler Identifier is still being used by one or more established connections, a failure response must be returned. The failure code says: "Scheduler Identifier still in use." If the QoS Release message asks for a QoS Class Identifier to be released, but it's still being used by one or more established connections, a failure response must be returned with the failure code: "QoS Class Identifier still in use." ๐ซ๐
9.6 QoS Connection Management Message
The QoS Connection Management message is what the controller uses to set up and change virtual channel connections and virtual path connections across the switch that need QoS parameters ๐งโจ. It works exactly like the Add Branch connection management message, plus the QoS parameters ๐. There are no special QoS connection release messages. Instead, you release QoS connections with the Delete Tree, Delete All, and Delete Branches messages from Section 4, "Connection Management Messages." When a QoS connection is released, all of its QoS resources get released with it ๐ซถ.
There are three styles of connection with specified QoS parameters, and they each have their own personality ๐:
QoS Connection: This style has its own individual QoS parameters and is routed on its own to the waiting room and output port named in the QoS Connection Management message. It is not a member of a QoS class ๐ฆ. Each output branch of a point-to-multipoint QoS connection may specify its own QoS parameters, which can be different from every other output branch of that same connection, if the switch supports this capability. However, all output branches must specify identical connection policer parameters ๐. A QoS Connection Management message asking for this style is identified by a QoS Class Identifier with the value 0xFFFFFFFF ๐.
QoS Class Connection: This style doesn't specify its own QoS parameters. It's a member of a QoS class, so the QoS class sets its parameters ๐. It still gets routed independently to the waiting room and output port named in the QoS Connection Management message. Each output branch of a point-to-multipoint QoS Class Connection must use the same QoS parameters ๐ธ. A QoS Connection Management message asking for this style will have a valid QoS Class Identifier and a valid Scheduler Identifier โจ.
QoS Class Member: This style also doesn't specify its own QoS parameters. It's a member of a QoS class, and the QoS class sets its parameters. The QoS class also decides the waiting room and output port that all of its members get routed to ๐. This style doesn't support point-to-multipoint connections ๐. A QoS Connection Management message asking for this style will have a valid QoS Class Identifier and a Scheduler Identifier with the value 0xFFFF ๐.
To request a virtual channel connection with specified QoS parameters, use the Virtual Channel Connection (VCC) QoS Connection Management message, which is:
Message Type = 100.
To request a virtual path connection with specified QoS parameters, use the Virtual Path Connection (VPC) QoS Connection Management message, which is:
Message Type = 101.
The QoS Connection Management message uses 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|Q|B|C| Input VPI | Input VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x| Output VPI | Output VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Branches | Scheduler Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QoS Class Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Regulator | Excess Action | Connection Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|A|x x x x x x| Reserved | Excess Scheduler Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ UPC Parameters ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Regulator Parameters ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Okay, now let's unpack the fields! ๐งโจ
Port Session Number, Input Port, Input VPI, Input VCI, Output Port, Output VPI, Output VCI and Number of Branches ๐ are literally the same as the Add Branch message in Section 4.1, "Connection Management Messages." No new rules, just the familiar crew ๐
M B C Flags ๐ฆ Same deal here! The M, B and C flags are exactly the same as in Section 4, "Connection Management Messages." They work on the QoS Connection Management message exactly the way they work on the Add Branch message. Iconic consistency ๐
Q: QoS Profile Flag ๐ The QoS Profile flag is not used in the QoS Connection Management message. Bye, Q ๐
Scheduler Identifier ๐ For QoS Connection and QoS Class Connection styles, this points to the waiting room on the output port (the one named in the Output Port field) where all conforming traffic on the connection should be routed. Values 0 -- 255 are the default scheduler settings, and each default maps straight to one of the scheduler priority levels. You can use a Scheduler Identifier in the range 0 -- 255 without setting it up first with a Scheduler Establishment message. Anything in the range 0x0100 to 0xFFFE, though, must first be established by a Scheduler Establishment message. Be prepared, bestie ๐
A Scheduler Identifier of 0xFFFF means a QoS Class Member connection style is being requested ๐ In this style, the waiting room and output port are found by reference to the QoS class named in the QoS Class Identifier field. So in this case the QoS Class Identifier field must contain a valid QoS Class Identifier. Main character energy for sure โจ
QoS Class Identifier ๐ For QoS Class Connection and QoS Class Member connection styles, this specifies the QoS Class the connection belongs to. It must first be established by a QoS Class Establishment message, and its value must be greater than 0 and less than 0xFFFFFFFF.
A QoS Class Identifier of 0xFFFFFFFF means the connection is of style "QoS Connection." In that style, the connection doesn't belong to a QoS class at all. All QoS parameters are specified by the QoS Connection Management message and only apply to that one specific connection ๐ซถ
Regulator and Excess Action ๐ธ These are only used in connection requests of style "QoS Connection." Their definitions in the QoS Connection Management message are exactly the same as in the QoS Class Establishment message, except they apply to an individual connection instead of an entire QoS class. Small change, big vibes ๐ฅ
Connection Weight โญ This one is only used in connections of style "QoS Connection" and "QoS Class Connection." For QoS Class Member style connections, the QoS Class Weight parameter of the QoS Class Establishment message should be used to give the QoS class a weight instead.
If bit 0 of the Scheduler Flags field of the QoS Configuration message says weighted service may be applied to a connection, then the Connection Weight parameter sets the share of the bandwidth available to the waiting room that this connection should get ๐ง
The Connection Weight is an unsigned 16-bit field that holds a binary fraction. In other words, the bandwidth share (as a fraction of the bandwidth available to the waiting room) works out like this:
Bandwidth share = Connection Weight * 2**(-16)
A Connection Weight of zero means equal sharing between all connections in that waiting room that also request a Connection Weight of zero. The field is 16 bits wide, but the accuracy of the bandwidth sharing is hardware dependent and is not specified here. Hardware is wild, fr fr ๐คทโโ๏ธ
For connections of style "QoS Class Connection": if the Regulator function of the QoS Class is None or Policer, the Connection Weight should be applied to the waiting room pointed to by the Scheduler Identifier field in the QoS Connection Management message. If the Regulator function of the QoS Class is Shaper, the Connection Weight should be applied to the waiting room pointed to by the Excess Scheduler Id field instead ๐ฆ
For connections of style "QoS Connection": if the Regulator field of the QoS Connection Management message says None or Policer, the Connection Weight should be applied to the waiting room pointed to by the Scheduler Identifier field. If the Regulator field says Shaper, the Connection Weight should be applied to the waiting room pointed to by the Excess Scheduler Id field ๐
If the specified waiting room can't offer weighted sharing for a connection, a failure response message should be returned with a failure code indicating: "this waiting room is unable to offer weighted sharing for a connection." Sad but honest ๐ญ
QoS Flags ๐ญ
S: Selective Discard ๐ฅ If the Selective Discard flag is set, only cells with the Cell Loss Priority (CLP) bit set are subject to the discard mechanism once the number of cells in the waiting room goes over the Discard Threshold. If the Selective Discard flag is zero, then all cells (CLP=0 and CLP=1) are subject to the discard mechanism when the waiting room goes over the Discard Threshold. Selective discard can be combined with packet discard too. In that case, only packets where at least one cell has the CLP bit set will be subject to the discard mechanism ๐ง
A: All Branches ๐ท For a QoS Connection Management message that specifies a point-to-multipoint connection: if the All Branches flag is set, all branches of that connection must be set to the QoS parameters in the message. If the All Branches flag is zero, only the single output branch named in the message should be set to those QoS parameters. For a QoS Connection Management message that specifies a point-to-point connection, the All Branches flag isn't used at all ๐ฆ
x: Unused ๐ซง Nothing to see here ๐
Excess Scheduler Id ๐ For connections of style "QoS Connection" and "QoS Class Connection," the Excess Scheduler Id points to the waiting room on the output port (named in the Output Port field) where all excess traffic should be routed. Values 0 -- 255 are the default scheduler settings, and each default maps straight to one of the scheduler priority levels. You can use an Excess Scheduler Id in the range 0 -- 255 without first setting it up with a Scheduler Establishment message. All values of Excess Scheduler Id in the range 0x0100 to 0xFFFE must first be established by a Scheduler Establishment message ๐ง
If this field isn't used, it should be set to 0xFFFF. Also, the Excess Scheduler Id must not point to the same waiting room on the same output port as the Scheduler Identifier. Don't double up, bestie ๐ โโ๏ธ
UPC Parameters ๐ Every connection style may be subject to a Usage Parameter Control (UPC) function, also known as a connection policer. The policing function is applied to each individual connection before the classifier function combines it with other connections into a QoS class. A policing function applied to an entire QoS class is defined in the QoS Class Establishment message instead ๐
The connection policer is defined by reference to the Generic Cell Rate Algorithm (GCRA) defined by the ATM Forum [af-tm-0056], although any equivalent policing algorithm may be used. The GCRA takes two parameters: the increment (I) and the limit (L). The reciprocal of the increment (1/I) specifies the rate being policed, and the limit specifies the burst tolerance. (For comparison with the token bucket policer discussed in [Partridge], the size of the token bucket is given by L/I. Fun little math link ๐งฎ๐)
Okay bestie, so this part is where the policers get their hands dirty ๐ โจ
Two policers in series can be set up to police both the peak rate and the average rate (also called the sustainable rate) ๐ฆ. The first policer has Increment-1 and Limit-1. If you compare this to the ATM Forum spec, those police the Peak Cell Rate (PCR) and the Cell Delay Variation Tolerance (CDVT) ๐. The second policer has Increment-2 and Limit-2, which map to the Sustainable Cell Rate (SCR) and Burst Tolerance ๐ธ. (The Burst Tolerance can be computed from the Maximum Burst Size [af-tm-0056] ๐.)
There are two ways the policers can be wired together, and they're giving very different energy ๐. In the All Cells configuration, every cell gets policed by both policers in series, whether CLP is 0 or 1 ๐. In the CLP Selective configuration, the first policer checks every cell (CLP=0 and CLP=1), but only the CLP=0 cells get checked by the second policer ๐ง. For either config you can pick tagging or discard for each policer ๐.
Now the units. The Increment and Limit values are measured in a time unit that the switch sets in the QoS Configuration Parameters message โญ. That unit comes as a rate called the Scaling Factor, which is the number of cells per second you'd get from an Increment value of one ๐ซถ. So to find the Increment from the policed rate in cells per second, do this:
Increment parameter = (Scaling_Factor)/(policed_rate)
To find the Limit from the CDVT in seconds:
Limit parameter = CDVT * Scaling_Factor
And to find the Limit from the Burst Tolerance (BT) in seconds:
Limit parameter = BT * Scaling_Factor
Both Increment and Limit are 32-bit unsigned integers ๐ฅ. So the Scaling Factor is how the switch chooses the range and granularity of the policer params compared to its line rate, and it's honestly iconic ๐ญ. Example time: a SONET STS-3c (155.52 Mbps) port has a line rate of about 353 kcells/s ๐. With a Scaling Factor of 353,000,000, you can set a policed rate just under the line rate with 0.1% granularity โจ. And for a policed rate of 1 kbps, you can still get a bucket size of 31 cells ๐.
The UPC Parameters have 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Increment-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Limit-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Increment-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Limit-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |C|A|x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Increment-1 ๐: the increment for the first policer, a 32-bit unsigned integer. If Increment-1 is zero, the first policer is turned off, and then every cell counts as conforming to the first policer's traffic params ๐ธ.
Limit-1 ๐: the limit for the first policer, also a 32-bit unsigned integer.
Increment-2 ๐: the increment for the second policer, a 32-bit unsigned integer. A zero here turns the second policer off, and then every cell is considered conforming to its traffic params ๐ง.
Limit-2 ๐: the limit for the second policer, a 32-bit unsigned integer.
Flags ๐
C: Configuration ๐: if this flag is set, the policer should be in the All Cells configuration. If it's zero, the policer should be in the CLP Selective configuration ๐ซถ.
In All Cells, every cell (CLP=0 and CLP=1) gets hit by both policers in series. In CLP Selective, every cell (CLP=0 and CLP=1) is policed by the first policer, but only CLP=0 cells get policed by the second one. Either tagging or discard can be picked for each policer config โญ.
A: Action ๐ฅ: if the Action flag is zero, discard is required as the policing action. If the Action flag is set, tagging is required as the policing action ๐ .
If tagging is picked in All Cells, any CLP=0 cell that either policer decides is over its params gets flipped to CLP=1 ๐ฆ. If discard is picked in All Cells, any cell (CLP=0 or CLP=1) that either policer decides is over its params gets thrown out ๐ญ.
In CLP Selective, the first policer always discards any cell (CLP=0 or CLP=1) it decides is over its params ๐. If tagging is picked in CLP Selective, the second policer sets CLP=1 on any cell it decides is over its params ๐ธ. If discard is picked in CLP Selective, the second policer discards any cell it decides is over its params ๐.
To set up the policer for the conformance definitions from the ATM Forum [af-tm-0056], these configs are suggested ๐:
CBR.1: One policer, All Cells, Discard
VBR.1: Two policers, All Cells, Discard
VBR.2: Two policers, CLP Selective, Discard
VBR.3: Two policers, CLP Selective, Tagging
UBR.1: One policer, All Cells, Discard
UBR.2: One policer, All Cells, Tagging.
x: Unused ๐ง
Regulator Parameters ๐: only connections of style "QoS Connection" need the Regulator Parameters specified in the QoS Connection Management message ๐. For connections of style "QoS Class Connection" and "QoS Class Member", the Regulator Parameters are specified in the QoS Class Establishment message โจ.
The Regulator Parameters look a lot like the UPC parameters ๐ . If the regulator function is Policing, a single GCRA policer is applied to every cell (CLP=0 and CLP=1) on the connection ๐. The policer takes two params: an increment (the Regulator Increment) and a limit (the Regulator Limit) ๐ฆ. The reciprocal of the increment (1/I) gives the rate being policed, and the limit (L) gives the burst tolerance ๐ซถ. (If you're comparing to the token bucket policer from [Partridge], the token bucket size is L/I ๐.)
The Regulator Increment and Regulator Limit are both 32-bit unsigned integers ๐ฅ. Their values come from the Scaling Factor that the switch sets in the QoS Configuration Parameters message ๐ธ. To get the Regulator Increment from the policed rate in cells per second:
Regulator Increment = (Scaling_Factor)/(policed_rate)
For a policed rate (r), the GCRA policer guarantees that over any time period T, the traffic it counts as conforming to the traffic params doesn't go over:
rT + L/I
You can work out the Regulator Limit from that relation ๐.
If the regulator function is Shaping, only the Regulator Increment is used, and the Regulator Limit isn't used at all ๐ง. The Regulator Increment comes from the Scaling Factor in the QoS Configuration Parameters message, same as before ๐. To get it from the desired shaper rate in cells per second, on output from the shaper:
Regulator Increment = (Scaling_Factor)/(shaper_rate)
An Increment of zero disables the policer, and then all cells on that connection count as conforming to the policer traffic params ๐. A shaper given a Regulator Increment of zero won't do any shaping on that connection ๐ญ.
The Regulator Parameters have 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Regulator Increment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Regulator Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9.7 QoS Failure Response Codes ๐
okay so when a switch can't make a QoS request happen, it doesn't just ghost you ๐ it sends back a failure response. That's the request message you sent, returned to you with the Result field in the header set to failure (Result = 4) and the Code field telling you why it couldn't deliver. The failure code is the reason the switch was unable to satisfy the request. The general failure codes are in Section 3.2, Failure Response Messages, and these extra ones are the QoS-specific drama ๐
128: Weighted scheduling within this waiting room is unavailable.
129: This waiting room is unable to offer weighted sharing for a
QoS class.
130: This waiting room is unable to offer weighted sharing for a
connection.
131: Scheduler Identifier still in use.
132: QoS Class Identifier still in use.
133: Invalid QoS parameter.
134: Insufficient QoS resources.
135: Any point-to-multipoint connection arriving on this input
port must use the same QoS parameters for all output
branches.
10. Adjacency Protocol โจ
okay the adjacency protocol is the main character of getting connected ๐ it syncs state across the link, agrees on which version of the protocol to use, figures out who is at the other end, and notices when that identity changes. GSMP is a hard state protocol, so it is super important to catch loss of contact between switch and controller, and to catch any change of identity on either side ๐ซถ No GSMP messages other than the adjacency ones may be sent across the link until the adjacency protocol has achieved synchronization. So the adjacency protocol goes first, bestie, no exceptions ๐
10.1 Packet Format ๐ฆ
all GSMP messages in the adjacency protocol share this structure:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
in the adjacency protocol, the Version field is used for version negotiation ๐ง In a SYN message, the Version field 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 and puts the version from the received SYN in its GSMP Version field. That sets the version of the GSMP protocol to be used while the adjacency protocol remains synchronized. All other messages use the agreed version in the Version field. โจ
the version number for the version of GSMP defined by this specification is Version = 2 ๐
Message Type
the adjacency protocol is:
Message Type = 10
Timer
the Timer field tells the receiver the timer value the sender uses in the adjacency protocol ๐ It specifies the nominal time between periodic adjacency protocol messages. It stays constant for the whole duration of a GSMP session, and the timer field is measured in units of 100ms.
M-Flag
the M-Flag is only used in the SYN message, and it tells everyone whether the sender is a master or a slave ๐ If the M-Flag is set in the SYN message, the sender is a master. If it is zero, the sender is a slave. GSMP is asymmetric: the controller is the master and the switch is the slave. The M-Flag stops a master from syncing with another master, and a slave from syncing with another slave ๐ If a slave receives a SYN message with a zero M-Flag, it must ignore that SYN message. If a master receives a SYN message with the M-Flag set, it must ignore that SYN message. In all other messages, the M-Flag is not used.
Code
the Code field specifies the function of the message ๐ Four Codes are defined for the adjacency protocol:
SYN: Code = 1
SYNACK: Code = 2
ACK: Code = 3
RSTACK: Code = 4
Sender Name
for the SYN, SYNACK, and ACK messages, this is the name of the entity sending the message ๐ซถ The Sender Name is a 48-bit quantity that must be unique within the operational context of the device. A 48-bit IEEE 802 MAC address may be used for the Sender Name, if one is available. If Ethernet encapsulation is used, the Sender Name must be the Source Address from the MAC header. For the RSTACK message, the Sender Name field is set to the value of the Receiver Name field from the incoming message that caused the RSTACK message to be generated.
Receiver Name
for the SYN, SYNACK, and ACK messages, this is the name of the entity that the sender believes is at the far end of the link ๐ If the sender doesn't know the name of the far-end entity, this field should be set to zero. For the RSTACK message, the Receiver Name field is set to the value of the Sender Name field from the incoming message that caused the RSTACK message to be generated.
Sender Port
for the SYN, SYNACK, and ACK messages, this is the local port number of the link the message is being sent across ๐ For the RSTACK message, the Sender Port field is set to the value of the Receiver Port field from the incoming message that caused the RSTACK message to be generated.
Receiver Port
for the SYN, SYNACK, and ACK messages, this is what the sender believes is the local port number for the link, 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 the RSTACK message, the Receiver Port field is set to the value of the Sender Port field from the incoming message that caused the RSTACK message to be generated.
Sender Instance
for the SYN, SYNACK, and ACK messages, this is the sender's instance number for the link ๐ฆ It is used to detect when the link comes back up after going down, or when the identity of the entity at the other end changes. The instance number is a 32-bit number that is guaranteed to be unique within the recent past, and to change when the link or node comes back up after going down. Zero is not a valid instance number, so don't even try it ๐ For the RSTACK message, the Sender Instance field is set to the value of the Receiver Instance field from the incoming message that caused the RSTACK message to be generated.
Receiver Instance
for the SYN, SYNACK, and ACK messages, this is what the sender believes is the current instance number for the link, as allocated by the entity at the far end โจ If the sender doesn't know the current far-end instance number, this field should be set to zero. For the RSTACK message, the Receiver Instance field is set to the value of the Sender Instance field from the incoming message that caused the RSTACK message to be generated.
10.2 Procedure is where the actual rules live, bestie ๐ Let's go.
The adjacency protocol is described by the following rules and state tables. ๐
The rules and state tables use these operations โจ
- The "Update Peer Verifier" operation means storing the values of the Sender Instance, Sender Port, and Sender Name fields from a SYN or SYNACK message received from the entity at the far end of the link.
- The procedure "Reset the link" is defined as:
- 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, and Sender Name 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, and Receiver Name fields in the incoming message match the values of the Sender Instance, Sender Port, and Sender Name 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 value of the timer is announced in the Timer field. The period of the timer is unspecified, but a value of one second is suggested. โฐ
There are two independent events: the timer expires, and a packet arrives. The processing rules for these events are ๐ธ
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.
Note 1 is the one with the two-message limit, so don't skip it ๐
State synchronization across a link is considered achieved once the protocol reaches the ESTAB state. Every GSMP message that arrives before synchronization is achieved gets discarded, except for adjacency protocol messages. That's the rule, no cap ๐ซถ
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 |
+======================================================================+
Note 2 is the ESTAB one, and it's a little bit spicy ๐ถ๏ธ No more than two ACKs should be sent within any time period of length defined by the timer. So one ACK must be sent every time the timer expires. On top of that, one more ACK may be sent between timer expirations, but only if the incoming message is a SYN or SYNACK. That extra ACK helps the adjacency protocol reach synchronization faster โก
Note 3 is the chill one ๐ง No more than one ACK should be sent within any time period of length defined by the timer.
10.3 Loss of Synchronization
If, after synchronization is achieved, no valid GSMP messages are received for any period longer than three times the value of the Timer field announced in the incoming adjacency protocol messages, loss of synchronization may be declared. ๐ญ
The preferred procedure when a switch loses synchronization with its active controller is to try to establish synchronization with (one of) its backup controller(s). In this preferred approach, though, it must not reset its state until it achieves synchronization with a backup controller. So if it regains synchronization with its original controller before reaching a backup, it may continue the original session and stop trying to reach a backup controller. If synchronization with the original session is regained, it's the controller's job to make sure the state between the switch and controller stays consistent ๐ง
The preferred procedure is the main event, but the simplest procedure is also an option. When loss of synchronization with the active controller is declared, the switch can just reset its switch state and start searching for a controller. That simple procedure is legitimate, so no judgment here ๐ซถ
11. Summary of Failure Response Codes โจ
Here's the full list of failure codes defined for failure response messages. Screenshot this one, it's a lot ๐ธ
1: Unspecified reason not covered by other failure codes.
2: Invalid request message.
3: The specified request is not implemented on this switch.
4: Invalid Port Session Number.
5: One or more of the specified ports does not exist.
6: One or more of the specified ports is down.
7: Unused. (This failure code has been replaced by failure codes
18--21.)
8: The specified connection does not exist.
9: The specified branch does not exist.
10: 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.
11: The limit on the maximum number of point-to-multipoint
connections that the switch can support has been reached.
12: The limit on the maximum number of branches that the
specified point-to-multipoint connection can support has
been reached.
13: Unable to assign the requested VPI/VCI value to the requested
branch on the specified point-to-multipoint connection.
14: General problem related to the manner in which point-to-
multipoint is supported by the switch.
15: Out of resources (e.g. memory exhausted, etc.).
16: Failure specific to the particular message type. (The meaning
of this failure code depends upon the Message Type. It is
defined within the description of any message that uses
it.)
17: Cannot label each output branch of a point-to-multipoint tree
with a different label.
18: One or more of the specified input VPIs is invalid.
19: One or more of the specified input VCIs is invalid.
20: One or more of the specified output VPIs is invalid.
21: One or more of the specified output VCIs is invalid.
22: Invalid Class of Service field in a Connection Management
message.
23: Insufficient resources for QoS Profile.
24: Virtual path switching is not supported on this input port.
25: Point-to-multipoint virtual path connections are not
supported on either the requested input port or the
requested output port.
26: Attempt to add a virtual path connection branch to an
existing virtual channel connection.
27: Attempt to add a virtual channel connection branch to an
existing virtual path connection.
28: Only point-to-point bidirectional connections may be
established.
29: Cannot support requested VPI range.
30: Cannot support requested VCI range on all requested VPIs.
31: The transmit cell rate of this output port cannot be changed.
32: Requested transmit cell rate out of range for this output
port.
128: Weighted scheduling within this waiting room is unavailable.
129: This waiting room is unable to offer weighted sharing for a
QoS class.
130: This waiting room is unable to offer weighted sharing for a
connection.
131: Scheduler Identifier still in use.
132: QoS Class Identifier still in use.
133: Invalid QoS parameter.
134: Insufficient QoS resources.
135: Any point-to-multipoint connection arriving on this input
port must use the same QoS parameters for all output
branches.
Codes 1 to 32 cover the general failures, and 128 to 135 are the QoS ones ๐
12. Summary of Message Set ๐โจ
okay bestie, here's the cheat sheet for every message in this version of the spec ๐ The table shows which ones a switch must be supported to be a minimal, conforming implementation. Anything marked "Required" is the non-negotiable stuff, so the switch needs it to count as conforming ๐ซถ The controller should also implement those "Required" ones, but you can't actually test the controller for conformance because of the Master-Slave nature of the protocol ๐
Message Name Message Type Status
Connection Management Messages
Add Branch VCC....................16 Required
VPC....................26
Delete Tree.......................18
Delete All........................20
Delete Branches...................17 Required
Move Branch VCC...................22
VPC...................27
Port Management Messages
Port Management...................32 Required
Label Range.......................33
State and Statistics Messages
Connection Activity...............48
Port Statistics...................49 Required
Connection Statistics.............50
QoS Class Statistics..............51
Report Connection State...........52
Configuration Messages
Switch Configuration..............64 Required
Port Configuration................65 Required
All Ports Configuration...........66 Required
Event Messages
Port Up...........................80
Port Down.........................81
Invalid VPI/VCI...................82
New Port..........................83
Dead Port.........................84
Quality of Service Messages
QoS Configuration.................96
Scheduler Establishment...........97
QoS Class Establishment...........98
QoS Release.......................99
QoS Connection Management VCC....100
VPC....101
Adjacency Protocol....................10 Required
REFERENCES ๐๐ธ
Here are all the sources this spec leans on, bestie. Citations are kept exactly as they were written ๐ค
[af-tm-0056] ATM Forum Traffic Management Specification 4.0, af-tm-
0056.000, April 1996.
[I.361] "B-ISDN ATM Layer Specification," International
Telecommunication Union, ITU-T Recommendation I.361,
Mar. 1993.
[I.363] "B-ISDN ATM Adaptation Layer (AAL) Specification,"
International Telecommunication Union, ITU-T
Recommendation I.363, Mar. 1993.
[IpsilonMIB] Ipsilon IP Switch MIB,
http://www.ipsilon.com/products/ips.mib
[Partridge] C. Partridge, "Gigabit Networking," Addison-Wesley,
1994.
[RFC1700] Reynolds, J., and J. Postel, "Assigned Numbers," STD 2,
RFC 1700, October 1994.
[RFC1987] 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.
Security Considerations ๐
Okay, this part is serious, so listen up ๐ฅบ The spec assumes physical security on the control link that connects the controller to the switch. The document doesn't go into security issues beyond that.
Security isn't covered in this document. Physical protection of that control link is simply assumed, so keep it locked down ๐
Authors' Addresses ๐ฆ
Meet the crew who wrote this thing ๐
Peter Newman Phone: +1 (408) 990 2003
Nokia EMail: pn@ipsilon.com
W. L. Edwards, Chief Scientist Phone: +1 (913) 534 5334
Sprint EMail: texas@sprintcorp.com
Robert M. Hinden Phone: +1 (408) 990 2004
Nokia EMail: hinden@ipsilon.com
Eric Hoffman Phone: +1 (408) 990 2010
Nokia EMail: hoffman@ipsilon.com
Fong Ching Liaw Phone: +1 (408) 873 2688
Coppercom EMail: fong@coppercom.com
Tom Lyon Phone: +1 (408) 990 2001
Nokia EMail: pugs@ipsilon.com
Greg Minshall Phone: +1 (650) 237 3164
Fiberlane Communications EMail: minshall@fiberlane.com
Where to find them, if you're feeling brave ๐ง
Nokia (Sunnyvale) is located at:
232 Java Drive
Sunnyvale, CA 94089
USA
Sprint is located at:
Sprint
Sprint Technology Services - Long Distance Division
9300 Metcalf Avenue
Mailstop KSOPKB0802
Overland Park, KS 66212-6333
USA
Fiberlane Communications is located at:
1399 Charleston Road
Mountain View, CA 94043
USA
Full Copyright Statement โญ
Legal stuff, but it matters, so here it is in full ๐
Copyright (C) The Internet Society (1998). 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.
๐ฆ where this page comes from
- ietf: rfc2297 1998-03
- ๐ girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms