RFC 2297

Ipsilon's General Switch Management Protocol Specification Version 2.0

๐Ÿ“… published March 1998, from ietf

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 (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 address 0xFFFFFFFFFFFF. (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 is 0x880C ๐ŸŽ€.
  • 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:

  1. Invalid Message
  2. 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.
  3. A failure response specified in the text defining the message type.
  4. Connection Failures
  5. Virtual Path Connection Failures
  6. Multicast Failures
  7. QoS Failures (QoS failures are specified in Section 9.7.)
  8. 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 Flags field is set, the Class of Service field holds a QoS Profile ๐Ÿ‘‘
  • If the QoS Profile flag in the Flags field is zero, and the Class of Service value is greater than or equal to 0x100, the field holds a Scheduler Identifier ๐Ÿฆ‹
  • If the QoS Profile flag in the Flags field is zero, and the Class of Service value is less than 0x100, 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 VPI and Max 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.
  • Min VCI and Max 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 VPIs and Remaining 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:
    1. Generate a new instance number for the link
    2. 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)
    3. Send a SYN message
    4. 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

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