RFC 1987
Ipsilon's General Switch Management Protocol Specification Version 1.1
Status of this Memo ✨
okay so first things first, the legal-ish bit 💅 this memo gives info to the Internet community. It does NOT count as an Internet standard of any kind, and distribution is unlimited 🌸
Abstract 🦋
okay so the General Switch Management Protocol (GSMP) is a general purpose protocol for controlling an ATM switch 🎀 it lets a controller establish and release connections across the switch, add and delete leaves on a point-to-multipoint connection, manage switch ports, request configuration info, and request statistics. iconic, honestly 👑
Table of Contents 📑
1. Introduction....................................................3
2. GSMP Packet Format..............................................4
3. Connection Management Messages..................................7
3.1 Add Branch Message.........................................11
3.2 Delete Branch Message......................................12
3.3 Delete Tree Message........................................13
3.4 Verify Tree Message........................................13
3.5 Delete All Message.........................................14
3.6 Move Branch Message........................................14
4. Port Management Message........................................16
5. Statistics Messages............................................20
5.1 VC Activity Message........................................20
5.2 Port and VC Statistics Messages............................23
5.2.1 Port Statistics Message..............................26
5.2.2 VC Statistics Message................................26
6. Configuration..................................................26
6.1 Switch Configuration Message...............................27
6.2 Port Configuration Message.................................28
6.3 All Ports Configuration Message............................32
7. Event Messages.................................................33
7.1 Port Up Message............................................35
7.2 Port Down Message..........................................35
7.3 Invalid VPI/VCI Message....................................35
7.4 New Port Message...........................................35
7.5 Dead Port Message..........................................36
8. Adjacency Protocol.............................................36
8.1 Packet Format..............................................36
8.2 Procedure..................................................39
9. Failure Response Messages......................................41
References........................................................43
Security Considerations...........................................43
Authors' Addresses................................................431. Introduction 🧚
okay bestie, so GSMP (the General Switch Management Protocol, which is literally a general purpose protocol for controlling an ATM switch) lets a controller establish and release connections across the switch 💖 it can also add and delete leaves on a point-to-multipoint connection, manage switch ports, request config info, and request stats. it's giving control panel energy 🎛️ and the switch can tell the controller about async events too, like a link going down. so the switch isn't just sitting there quietly 😭
GSMP runs over an ATM link that connects the controller to the switch. it uses a control connection (a virtual channel) that gets set up at initialization 🌈 the protocol is asymmetric, meaning the controller is the master and the switch is the slave. the whole controller/switch power dynamic is very clear, ngl 💅 and one controller can manage multiple switches, using a separate instance of the protocol on each separate control connection ✨
now let's talk ports 🦋 a switch is made of multiple "ports," and each port is one "input port" plus one "output port." some GSMP requests are about the port as a whole, while others are specific to the input port or the output port. ATM cells arrive at the switch from an external communication link on incoming virtual channels at an input port, and they leave the switch to an external link on outgoing virtual channels from an output port 🫶 virtual channels on a port or link are referenced by their VPI/VCI (virtual path and virtual channel identifiers). a virtual channel connection across the switch is formed by hooking an incoming virtual channel up to one or more outgoing virtual channels. and those connections are referenced by the input port they arrive on plus the VPI/VCI of their incoming virtual channel. it's like a whole addressing system, and it's kinda iconic 🍓
next, QoS 💜 ngl this is an ill-defined and changing concept, because new ideas keep making their way into hardware. so for this version of GSMP, it's assumed each virtual channel connection may be given a priority when it's established. for connections sharing the same output port, a cell on a higher-priority connection is much more likely to exit 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 found in the port configuration message 🎀
switch ports get a 32 bit port number, and the switch assigns these 🌸 the switch may choose to structure those 32 bits into sub-fields that match its physical layout, like shelf, slot, and port. generally, a port in the same physical spot on the switch will always keep the same port number, even across power cycles 🫶 the internal structure of the port number is opaque to GSMP itself. but network management tools can look up the product identity in a database, and then figure out how the port number is partitioned and what the sub-fields physically mean. big brain stuff 🧠✨
each switch port also keeps a port session number that the switch assigns, and this is where it gets important. a connection management message or a port management message with an incorrect port session number must be rejected 🙈 this lets the controller detect a link failure and keep state in sync. the port session number stays the same while the port is continuously in the available state and the link status is continuously up. but it changes when the port returns to the available state after being unavailable or in any of the loopback states. it also changes when the line status returns to up after being down or in test, or after a power cycle. and the number should be assigned using some form of random number 🎲 main character energy, the port session number is literally the plot twist 😭
last but not least, GSMP has an adjacency protocol 🌈 it's used to synchronize state across the link, to discover the identity of whatever is at the other end of the link, and to detect when that identity changes. the whole vibe is "who's on the other side and did they change?" 👀
2. GSMP Packet Format ✨
okay so GSMP packets are variable length, and they get wrapped directly in an AAL-5 CPCS-PDU [I.363] with an LLC/SNAP header 🎀 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LLC (0xAA-AA-03) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| SNAP (0x00-00-00-88-0C) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ GSMP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pad (0 - 47 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ AAL-5 CPCS-PDU Trailer (8 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+bit order time 🧠💜 The convention in the documentation of Internet Protocols [rfc1700] is to write numbers in decimal and to picture data in "big-endian" order. So fields are read left to right, with the most significant octet on the left and the least significant octet on the right. Whenever a diagram shows a group of octets, they're transmitted in the normal order you'd read them in English. Whenever an octet holds a numeric value, the leftmost bit in the diagram is the high order, or most significant, bit. The bit labeled 0 is the MSB, full stop 🙌 Same deal for multi-octet fields: the leftmost bit of the whole field is the most significant one. When a multi-octet quantity gets transmitted, the most significant octet goes out first. This is the same coding convention used in the ATM layer [I.361] and AAL-5 [I.363], so it's giving consistency ✨
The LLC/SNAP header contains the octets: 0xAA 0xAA 0x03 0x00 0x00 0x00 0x88 0x0C.
The maximum transmission unit (MTU) of the GSMP message is 1500 octets 📏
The default virtual channel for LLC/SNAP encapsulated messages is:
VPI = 0
VCI = 15GSMP is a master-slave protocol 👑 The controller sends request messages to the switch. Each request message says whether a response is required from the switch, and it carries a transaction identifier so the response can be matched back to the right request. The switch replies with a response message that's either a successful result or a failure. There are four classes of GSMP request-response message: Connection Management, Port Management, Statistics, and Configuration. 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 that establishes synchronization across the link and keeps a handshake going 🤝
For the request-response messages, each message type has one format for the request and another format for the success response. Unless otherwise specified, a failure response message is identical to the request message that caused the failure, except the Code field tells you what went wrong 💀 Event messages have only a single format, since the controller never acknowledges them.
Except for the adjacency protocol message, no GSMP messages may be sent across the link until the adjacency protocol has achieved synchronization. Also, all GSMP messages received on a link that doesn't currently have state synchronization MUST be discarded 🚫
All GSMP messages, except the adjacency protocol message, 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Message Body ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Version
This is the GSMP protocol version number, currently Version = 1 🔢 The sender SHOULD set it to the GSMP protocol version the sender is currently running.
Message Type
This is the GSMP message type 🏷️ GSMP messages fall into five classes: Connection Management, Port Management, Statistics, Configuration, and Events. Every class except port management has a bunch of different message types. On top of that, one Message Type is reserved for the adjacency protocol.
Result
The Result field, in a connection management request message or a port management request message, tells you whether a response is required if the outcome is successful 🎯 The value NoSuccessAck means the request does NOT expect a response when it succeeds, and AckAll means a response IS expected on success. In both cases, a failure response gets generated if the request fails. This is super useful when the controller is just double-checking that the switch's state is what it should be, because it cuts down on traffic 🙌 For every other request message, a NoSuccessAck value in the request gets ignored, and the request is handled as if the field were set to AckAll. In a response message, the Result field can only be Success or Failure ✨
The encoding of the Result field is:
NoSuccessAck: Result = 1
AckAll: Result = 2
Success: Result = 3
Failure: Result = 4The Result field is not used in an adjacency protocol message. The sender SHOULD set it to zero, and the receiver SHOULD ignore it 🙈
Code
The Code 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 add detail to a success response or an event message. In a request message, the Code field isn't used and is set to zero. In an adjacency protocol message, the Code field is what determines the function of the message 🧚
Transaction Identifier
This is what links a request message to its response message 🦋 For request messages, the controller MAY pick any transaction identifier it likes. For response messages, the transaction identifier is set to whatever the transaction identifier was in the message they're responding to. For event messages, the transaction identifier SHOULD be set to zero. In the adjacency protocol, the Transaction Identifier isn't used, and this field isn't even present in the adjacency protocol message 💅
3. Connection Management Messages ✨
okay bestie, connection management messages are how the controller 💅 establishes, deletes, modifies and verifies connections across the switch 🦋. The Add Branch, Delete Branch, Delete Tree, Verify Tree, and Delete All messages all use the same layout for both requests and responses, so here it is 🎀:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | Input VPI | Input VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | Output VPI | Output VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Branches | Reserved | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Port Session Number 🧚 gives the session number of the input port. Each switch port keeps a Port Session Number that the switch assigns. The port session number of a port stays the same while the port is continuously in the Available state and the link status is continuously Up. When a port returns to the Available state after it has been Unavailable or in any of the Loopback states, or when the line status returns to the Up state after it has been Down or in Test, or after a power cycle, a new Port Session Number MUST be generated. Port session numbers SHOULD be assigned using some form of random number. The switch MUST reject any connection management request message that has an invalid Port Session Number for the port specified in the Input Port field by returning a failure response message with the Code field indicating, "Invalid port session number." The current port session number MAY be obtained using a configuration message.
Input Port 🌸 indicates a switch input port. Switch ports are referenced by a 32 bit value assigned by the switch.
Input VPI 💖 identifies an ATM virtual path arriving at the switch input port indicated by the Input Port field.
Input VCI 💜 identifies an ATM virtual channel arriving on the virtual path indicated by the Input VPI field at the switch input port indicated by the Input Port field.
Output Port 🍓 indicates a switch output port. Switch ports are referenced by a 32 bit value assigned by the switch.
Output VPI 🦋 identifies an outgoing virtual path departing from the switch output port indicated in the Output Port field.
Output VCI ✨ identifies an outgoing virtual channel departing on the virtual path indicated by the Output VPI field from the switch output port indicated in the Output Port field.
Number of Branches 👑 gives the number of output branches on a virtual channel connection. (A unicast connection will have one branch, a multicast connection will have two or more branches.) This field is only used in the Verify Tree message. In all other connection management messages this field SHOULD be set to zero by the sender and ignored by the receiver.
Reserved 🙈 is not used. It is set to zero by the sender and ignored by the receiver.
Priority 🔥 gives the priority of the connection. The highest priority is numbered zero and the lowest priority is numbered "Q-1" where "Q" is the number of priorities that the output port can support. The ability to offer different qualities of service to different connections based upon their priority is assumed to be a property of the output port of the switch. It is assumed that for virtual channel connections that share the same output port, an ATM cell on a connection with a higher priority is much more likely to exit the switch before an ATM cell on a connection with a lower priority if they are both in the switch at the same time. The number of priorities that each output port can support is given in the Port Configuration message. If a connection request is received with a value in the priority field that the switch cannot support, the switch will assign the closest priority that it is capable of supporting. This field is only used in the Add Branch and Move Branch messages. In all other connection management messages this field SHOULD be set to zero by the sender and ignored by the receiver.
If the result field of the request message is "AckAll" the switch MUST reply to all connection management request messages with a success response message or a failure response message. If the result field of the request message is "NoSuccessAck" the switch MUST only reply in the case of a failure.
A success response message MUST NOT be sent until the operation has been successfully completed. For connection management messages the success response message is a copy of the request message returned with a Result field indicating success. The Code field is not used in a connection management success response message and SHOULD be set to zero. The failure response message is a copy of the request message returned with a Result field indicating failure. The Code field is used to pass the Failure Code in a connection management failure response message. If the switch issues a failure response, the connection state within the switch MUST NOT be modified by the request message that resulted in the failure.
No distinction is made between unicast connections and multicast connections. The first Add Branch message for a particular Input Port, Input VPI, and Input VCI will establish a unicast connection. The second Add Branch message with the same Input Port, Input VPI, and Input VCI fields will convert the connection to a multicast connection with two branches. Subsequent Add Branch messages with the same Input Port, Input VPI, and Input VCI fields will add further branches to the multicast connection. Use of the Delete Branch message on a multicast connection with two branches will result in a unicast connection. Use of the Delete Branch message on a unicast connection will delete the unicast connection. There is no concept of a connection with zero output branches. All connections are unidirectional, one input virtual channel to one or more output virtual channels.
The connection management messages MAY be issued regardless of the Port Status of the switch port. Connections MAY be established or deleted when a switch port is in the Available, Unavailable, or any of the Loopback states. However, all connection state on an input port will be deleted when the port returns to the Available state from any other state, i.e. when a Port Management message is received for that port with the Function field indicating either Bring Up, or Reset Input Port.
3.1. Add Branch Message ✨
okay bestie, the Add Branch message is the one that sets up a virtual channel connection OR tacks an extra branch onto one that already exists 🦋 it can also be used to check the connection state stored in the switch, so it MAY be used for that too 👀 The connection is identified by the Input Port, Input VPI, and Input VCI fields, the output branch is the Output Port, Output VPI, and Output VCI fields, and the Priority field sets the priority. The message type is:
Message Type = 16If the connection (Input Port, Input VPI, Input VCI) doesn't exist yet, it MUST be set up with the single output branch from the request 🌸 The output branch SHOULD get the priority from the Priority field. If Result is "AckAll", a success response MUST be sent once the branch is successfully up, and it MUST NOT be sent until the Add Branch operation is totally complete 💅
If the connection already exists but that output branch doesn't, the new output branch MUST be added. It SHOULD have the priority from the Priority field, and with "AckAll" a success response MUST be sent upon successful establishment. Again, that success response MUST NOT be sent until the Add Branch operation has been completed ✨
If the connection AND the output branch already exist, the priority SHOULD be changed to the one in the request if it's different 🎀 A success response MUST be sent if Result is "AckAll". This lets the controller periodically reassert the state of a connection or change its priority, which is so iconic. If Result is "NoSuccessAck", a success response SHOULD NOT be returned. This is great for cutting down traffic on the control link when messages are just reasserting state they already set up 🫶 For messages reasserting previously established state, the switch MUST always check that the state is actually established in the switch hardware (i.e. the real connection tables used to forward cells). no shortcuts, babe 😭
The behavior is undefined if the output virtual channel specified by the Output Port, Output VPI, and Output VCI fields is already in use by any connection other than the one specified by the Input Port, Input VPI, and Input VCI fields. 🙈
A failure response MUST be returned if the switch can't establish the specified branch or if there's an error in any field of the request message. And if a failure message comes back, the switch state MUST NOT have been modified by the request message 💀
Worth noting: different switches do multicast in different ways 🌈 there's a limit on the total number of multicast connections any switch can support, possibly a limit on how many branches one multicast connection can have, and some switches cap the number of different VPI/VCI values allowed on a multicast connection's output branches. A lot of switches can't handle more than one branch of the same multicast connection on the same output port. Specific failure codes exist for some of these situations, and if a switch sends a failure response to an Add Branch message, it MUST choose the most specific failure code 🧚
3.2. Delete Branch Message 🍓
The Delete Branch message deletes a single branch of a virtual channel connection, or if it's the last branch, deletes the whole connection 🥀 The connection is specified by the Input Port, Input VPI, and Input VCI fields, and the specific branch is picked out by the Output Port, Output VPI, and Output VCI fields. The message type is:
Message Type = 17If Result is "AckAll", a success response MUST be sent upon successful deletion of the specified branch. It MUST NOT be sent until the delete branch operation is completed and, if possible, not until all data queued for transmission on that branch has been sent out 📦
If the connection specified by the Input Port, Input VPI, and Input VCI fields doesn't exist, a failure message indicating "The specified connection does not exist," MUST be sent. And if the connection exists but the branch specified by the Output Port, Output VPI, and Output VCI fields doesn't, a failure message indicating "The specified branch does not exist," MUST be sent 🙅♀️
3.3. Delete Tree Message 🌳
The Delete Tree message is how you delete an entire virtual channel connection in one go, and all remaining branches get deleted with it 💥 The connection is specified by the Input Port, Input VPI, and Input VCI fields. The Output Port, Output VPI, and Output VCI fields aren't used in this message, so their contents SHOULD be set to zero by the sender and ignored by the receiver 🧸 The message type is:
Message Type = 18If Result is "AckAll", a success response MUST be sent upon successful deletion of the specified connection. The success message MUST NOT be sent until the delete operation is completed and, if possible, not until all data on the connection queued for transmission has been sent 🫧
If the connection specified by the Input Port, Input VPI, and Input VCI fields doesn't exist, a failure message indicating "The specified connection does not exist," MUST be sent 🥲
3.4. Verify Tree Message 🔍
The Verify Tree message checks the number of branches on a virtual channel connection, like a vibe check but for branches 💅 The connection is specified by the Input Port, Input VPI, and Input VCI fields. The Output Port, Output VPI, and Output VCI fields aren't used here either, so their contents SHOULD be set to zero by the sender and ignored by the receiver. The sender's guess for how many branches the connection SHOULD contain goes in the Number of Branches field 🎯 The message type is:
Message Type = 19If Result is "AckAll", a success response MUST be sent if the receiver agrees that the actual number of branches on the specified connection matches the number in the Number of Branches field of the request. But if the actual count doesn't match, a failure response with the code field set to "Failure specific to the particular message type," MUST be sent 🙃 In that failure response, the Number of Branches field MUST be changed to hold the actual number of branches on the connection. If something else went wrong, like "The specified connection does not exist," a failure response with a different code value MUST be used instead. In that case the Number of Branches field will match the request message 🫠
The Verify Tree message can only be guaranteed to give a correct response when there are no other connection request messages or their response messages pending for the specified connection. If that's not the case, the result of the Verify Tree message is undefined. 🌀
3.5. Delete All Message 💣
The Delete All message wipes out ALL connections on a switch input port 🧹 Every connection arriving at the specified input port MUST be deleted. When it's done, all dynamically assigned VPI/VCI values for that port MUST be unassigned, which means there MUST be no virtual connections left 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 here, and their contents are ignored and unspecified 🤷♀️ The message type is:
Message Type = 20If Result is "AckAll", a success response MUST be sent upon completion of the operation. And it MUST NOT be sent until the operation has actually been completed 🎉
3.6 Move Branch Message 🦋
okay so the Move Branch message has the same layout for both the request and the response, and it's giving tidy 💅
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | Input VPI | Input VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | Old Output VPI | Old Output VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | New Output VPI | New Output VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+so the Move Branch message is a connection management message that lets you pick up ONE output branch of a virtual channel connection and shift it 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, bestie ✨ and once the move is done, the original output VPI/VCI on the original output port gets deleted from the connection 💀 the message type is:
Message Type = 22okay now the good stuff 👑 if the virtual channel connection given by the Input Port, Input VPI, and Input VCI fields already exists, AND the output branch given by the Old Output Port, Old Output VPI, and Old Output VCI fields is already a branch on that connection, then the new output branch (New Output Port, New Output VPI, New Output VCI) gets added and the old one gets deleted 🌸 if the Result field of the request is AckAll, a success response message must be sent once the operation finishes successfully. the success response message must not be sent until the Move Branch operation has been completed 🫶
now the sad path 😭 if the connection exists but the old output branch isn't on it, a failure response must come back with the Code field indicating, "The specified branch does not exist." and the switch's connection state must not be modified in this case 🙈
if the connection itself doesn't exist, a failure response must come back with the Code field indicating, "The specified connection does not exist." again, the connection state of the switch must not be modified 💜
⚠️ the behavior is undefined if the output virtual channel given by the New Output Port, New Output VPI, and New Output VCI fields is already in use by any connection. so just don't do that, bestie 💀
and lastly, a failure response will be returned if the switch is unable to establish the specified branch, or if there is an error in any of the fields of the request message 🍓 if a failure message gets returned, the state of the switch must not have been modified by the request message, so nothing gets half-moved, periodt ✨
4. Port Management Message ✨
okay bestie, so the Port Management message is the one that lets you bring a port into service, take it out of service, loop it back on itself, or reset it 🔁💅 Only the Bring Up and the Reset Input Port functions change the connection state (established connections) on the input port 🌸 and only Bring Up changes the Port Session Number 🦋 If the Result field of the request message is "AckAll", a success response message MUST be sent once the operation finishes successfully 💖 and it MUST NOT be sent until the operation has actually been completed 😭 The Port Management Message is:
Message Type = 32
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Flags | Duration | Function |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Port 📍 Gives the port number of the port to which the message applies.
Port Session Number 🎀 This gives the current port session number for the port. If the Port Session Number in the request message doesn't match the current port session number of the port indicated by the Port field, a failure response MUST be returned with, "Invalid port session number," indicated in the Code field 🙈 If the specified function needs a new Port Session Number to be generated, the new Port Session Number MUST be given in the success response message. The Port Session Number MUST be generated using some form of random number 🎲
Event Sequence Number 🔢 In the success response message, this gives the current value of the Event Sequence Number of the switch port indicated by the Port field. The Event Sequence Number is set to zero when the port is initialized, and it goes up by one each time an asynchronous event is detected on that port that the switch would normally report via an Event message ✨ If the Event Sequence Number in the success response is different from the Event Sequence Number of the most recent Event message received for that port, then events happened that never got reported via an Event message 😳 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 isn't used, and it SHOULD be set to zero by the sender and ignored by the receiver 💜
Event Flags 🚩 This field in the request message is used to reset the Event Flags in the switch port indicated by the Port field. Each Event Flag in a switch port corresponds to a type of Event message. When a switch port sends an Event message, it sets the corresponding Event Flag on that port. The port isn't allowed to send another Event message of the same type until that Event Flag has been reset 🙅♀️ If the Function field in the request message is set to "Reset Event Flags," then for each bit that is set in the Event Flags field, the corresponding Event Flag in the switch port gets reset 🧹
The Event Flags field is only used in a request message with the Function field set to "Reset Event Flags." For all other values of the Function field, the Event Flags field SHOULD be set to zero in the request message and MUST be ignored by the receiver. 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 is finished, for all values 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 state of the Event Flags and the current Event Sequence Number of the port without changing the Event Flags at all 👀
The correspondence between the types of Event message and the bits of the Event Flags field is:
Port Up: Bit 0, (most significant bit)
Port Down: Bit 1,
Invalid VPI/VCI: Bit 2,
New Port: Bit 3,
Dead Port: Bit 4.Duration ⏳ This 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 comes in for the same port before the duration has expired, the loopback keeps going for the length of time given in the Duration field of the new message 🔄 The Duration field is only used in request messages with the Function field set to Internal Loopback, External Loopback, or Bothway Loopback. In all other request messages it SHOULD be set to zero by the sender and ignored by the receiver 💅
Function 🎬 This specifies the action to be taken. The action happens no matter what the port's current status is (Available, Unavailable, or any Loopback state) 💪 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 it's done, all dynamically assigned VPI/VCI values for the specified input port MUST be unassigned, which means no virtual connections get established in the VPI/VCI space that GSMP controls on this input port 🧼 Afterwards the Port Status of the port 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 🚫 Afterwards the Port Status of the port will be Unavailable. The behavior is undefined if the port that GSMP runs over gets taken down, so yikes 😬 - Internal Loopback:
Function = 3. Cells arriving at the output port from the switch fabric get looped through to the input port so they can go back to the switch fabric 🔁 All of the ATM functions of the input port above the PHY layer (e.g. header translation) are performed on the looped back cells. Afterwards the Port Status of the port will be Internal Loopback 🪞 - External Loopback:
Function = 4. Cells arriving at the input port from the external communications link get immediately looped back out to the communications link at the physical layer, without ever entering the input port ⚡ None of the ATM functions of the input port above the PHY layer are performed on these looped back cells. Afterwards the Port Status of the port will be External Loopback 🌈 - Bothway Loopback:
Function = 5. Both internal and external loopback happen at once 💫 Afterwards the Port Status of the port 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 MUST be re-initialized 🧽 When it's done, 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 Session Number is NOT changed by the Reset Input Port function, because it stays exactly the same 🫧 Afterwards the Port Status of the port will be Unavailable ✨
Hold on, I need to say that again properly, so here it is clean: the Port Session Number is not changed by the Reset Input Port function. Afterwards the Port Status of the port will be Unavailable.
- Reset Event Flags:
Function = 7. For each bit that is set in the Event Flags field, the corresponding Event Flag in the switch port MUST be reset 🧹 The Port Status of the port is not changed by this function 🌸
5. Statistics Messages 📊
okay so the statistics messages let the controller ask for the values of different hardware counters tied to the switch input and output ports, and to virtual channels 🔍 There are two classes of statistics message: the VC Activity Message, and the Port and VC Statistics Messages 💖 The VC Activity message is used to figure out whether one or more specific VCs have been carrying traffic recently 🚦 The Port and VC Statistics message is used to query the different port and VC specific traffic and error counters 🫶
5.1 VC Activity Message
okay so the VC Activity message is how you check whether one or more specific VCs have been carrying traffic lately 👀🦋 It holds one or more VC Activity records, and each record asks about one single virtual connection and sends info back about it. Each VC is identified by its input port, input VPI, and input VCI, which go in the Input Port, Input VPI, and Input VCI fields of each record ✨
there are two ways the activity detection can work, bestie 💅 If the switch does per VC traffic accounting, the current value of the traffic counter for each specified VC must be returned. The units aren't specified, but they'll usually be cells or frames. Then the controller must compare the traffic counts in the message with the previous values for each VC to see if it was active in the meantime 🫶 If the switch can't do per VC accounting but can detect per-VC activity some other unspecified way, the result may be indicated for each VC using the Flags field.
The message type is Message Type = 48, so that's the number you're looking for 🔥
The VC 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ VC Activity Records ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Number of Records tells you how many VC Activity records are coming along. A single VC Activity message can hold a maximum of 120 of them 📦
Reserved is not used 🙃 The sender sets it to zero and the receiver ignores it.
Each VC Activity Record looks like this:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Input VPI | Input VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ VC Traffic Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Input Port is the port number of the input port where the VC of interest arrives. This is how the VC gets identified, no matter whether the traffic count is kept on the input port or the output port 🌸
Input VPI and Input VCI pin down the exact virtual channel you're asking stats about 🎀
Flags works differently depending on the message, so pay attention bestie 👀
- In the request message, this field is unused. It should be set to zero by the sender and ignored by the receiver.
- In the success response message, bit 0 (msb) of the Flags field is used to flag an invalid VC Activity record. This bit must be zero if any of the fields in this VC Activity record are invalid, if the input port named in the Input Port field doesn't exist, or if the specified connection doesn't exist.
- If bit 0 is zero in a success response message, bits 1 and 2 of the Flags field and the VC Traffic Count field are undefined. 💀
- If bit 0 of the Flags field is set, the VC Activity record is valid, and bits 1 and 2 of the Flags field are used like this:
- Bit 1 of the Flags field: if set, it means the value in bit 2 of the Flags field is valid. If it's zero, it means the value in the VC Traffic Count field is valid.
- If bit 1 of the Flags field is set and bit 2 is set, there has been some activity on this virtual channel since the last VC Activity message for this virtual channel 🔥
- If bit 1 of the Flags field is set and bit 2 is zero, there has been no activity on this virtual channel since the last VC Activity message for this virtual channel 😴
- Bit 3 of the Flags field is not used. It should be set to zero by the sender and ignored by the receiver.
VC Traffic Count is unused in the request message, so it should be set to zero by the sender and ignored by the receiver. In the success response message, if the switch supports per-VC traffic counting, the VC Traffic Count field must be set to the value of a free running, VC specific, 64 bit traffic counter. That counter counts the traffic flowing across the specified virtual channel 📈 Reading it doesn't modify the counter, so you can look as much as you want 👑 And if per-VC traffic counting is supported, the switch must report the VC Activity result using the traffic count, not bit 2 of the Flags field.
The failure response has the same format as the request message, except the Number of Records field is set to zero and no VC Activity records come back in the message 😭 If the switch can't detect per-VC activity at all, a failure response must be returned that says, "The specified request is not implemented on this switch." 🙈
5.2 Port and VC Statistics Messages ✨
okay so the Port and VC Statistics messages are how you ask the switch for all its port and VC specific traffic and error counters 📊🦋
The Port and VC Statistics request messages look like this 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | VPI | VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's what the fields do 🎀
Port Identifies the port number of the port for which statistics are being requested.
VPI and VCI These fields identify the specific virtual channel for which statistics are being requested. For requests that do not require a virtual channel to be specified, these fields should be set to zero in the request and ignored by the receiver.
The success response messages for the port and VC statistics group 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | VPI | VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ 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 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+And the fields in the success response work like this 🌈
Port and VPI/VCI These fields are the same as those of the request message.
Input Cell Count and Output Cell Count Each gives the value of a free running 64 bit counter counting cells arriving at the input or departing from the output, respectively. In response to a Port Statistics message, the count will be on a per port basis, and in response to a VC Statistics message, the count will be on a per VC basis.
Input Frame Count and Output Frame Count Each gives the value of a free running 64 bit counter counting frames (packets) arriving at the input or departing from the output, respectively. In response to a Port Statistics message, the count will be on a per port basis, and in response to a VC Statistics message, the count will be on a per VC basis.
Input Cell Discard Count and Output Cell Discard Count Each gives 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. In response to a Port Statistics message, the count will be on a per port basis, and in response to a VC Statistics message, the count will be on a per VC basis.
Input Frame Discard Count and Output Frame Discard Count Each gives the value of a free running 64 bit counter counting frames discarded due to queue overflow on an input port or on an output port, respectively. In response to a Port Statistics message, the count will be on a per port basis, and in response to a VC Statistics message, the count will be on a per VC basis.
HEC Error Count 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 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. An incoming VPI/VCI is invalid if no connection is currently established having that value of VPI/VCI.
5.2.1 Port Statistics Message 🌸
okay the Port Statistics message asks for the statistics of the switch port named in the Port field 🧚 The contents of the VPI/VCI field in the Port Statistics request message are ignored, so don't stress about it 🙈 All of the count fields in the success response message refer to per-port counts, no matter which virtual channels the cells belong to. Any of the count fields in the success response message that aren't supported by the port will be set to zero. The Port Statistics message is:
Message Type = 495.2.2 VC Statistics Message 💜
the VC Statistics message asks for the statistics of the virtual channel named in the VPI/VCI field, the one that arrives on the switch input port named in the Port field 🦋 All of the count fields in the success response message refer only to that specific virtual channel. The HEC Error Count and Invalid VPI/VCI Count fields aren't VC specific, so they get set to zero. Any of the other count fields that aren't supported on a per virtual channel basis also get set to zero in the success response message. The VC Statistics message is:
Message Type = 506. Configuration 🎀
the configuration messages let the controller find out what the switch is capable of 👑 Three configuration request messages have been defined: Switch, Port, and All Ports.
All configuration 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Port Identifies the port number for which configuration information is being requested. If the Port field is not required by the message, it is set to zero by the sender and ignored by the receiver.
6.1 Switch Configuration Message
okay bestie, so the Switch Configuration message is how you ask a switch for its global config (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 and is set to zero 🌸
The Switch Configuration 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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switch Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Switch Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Firmware Version Number 💾 This is the version of the switch control firmware that's installed.
Reserved 🫶 This field isn't used. The sender sets it to zero, and the receiver ignores it.
Switch Type 🏷️ This is a 16 bit field that the manufacturer of the switch allocates. For these purposes, the manufacturer is taken to be the organization identified by the OUI in the Switch Name field. The Switch Type identifies the product. Combine it with the OUI from the Switch Name and the product is uniquely identified 🔥 Network Management can use this to look up product-related info in a database.
Switch Name 🪪 This is a 48 bit value that has to be unique within the operational context of the device. If it's available, a 48 bit IEEE 802 MAC address can be used as the Switch Name. The most significant 24 bits of the Switch Name MUST be an Organizationally Unique Identifier (OUI) that identifies the manufacturer of the switch 👑
6.2 Port Configuration Message
the Port Configuration message asks the switch for the config info of one switch port 🦋 The Port field in the request says which port you want 🎯 The message type is Message Type = 65.
The Port Configuration 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | Min VPI | zero | Max VPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min VCI | Max VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cell Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Status | Port Type | Line Status | Priorities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+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 wide and the switch allocates them. The switch can split the 32 bits into sub-fields that match its physical hardware layout (for example, shelf, slot, interface) 🧩
Port Session Number 🎟️ This is the current Port Session Number for the port you asked about. Every switch port keeps a Port Session Number that the switch assigns. It stays the same while the port is continuously in the Available state. When a port goes back to Available after being Unavailable, or after a power cycle, its Port Session Number MUST be changed, ideally using some kind of random number 🎲
Min VPI 📉 This is the lowest dynamically assigned incoming VPI that the input port's connection table can support, and GSMP may control it.
Max VPI 📈 This is the highest dynamically assigned incoming VPI that the input port's connection table can support, and GSMP may control it. It's assumed the input port can handle every VPI value from Min VPI to Max VPI (inclusive), and that GSMP may control every value in that range. 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 🌱
Min VCI 📉 This is the lowest dynamically assigned incoming VCI that the input port's connection table can support, and GSMP may control it.
Max VCI 📈 This is the highest dynamically assigned incoming VCI that the input port's connection table can support, and GSMP may control it. It's assumed the input port can handle every VCI value from Min VCI to Max VCI (inclusive) for each of the virtual paths from Min VPI to Max VPI (inclusive), and that GSMP may control every value in that range 🧠
Cell Rate ⚡ This measures how much bandwidth the port has. It's the rate of cells arriving at or leaving the port, in cells/s. It's assumed that the input and output ports have the same cell rate 💜
Port Status 🚦 This tells you the administrative state of the port. The defined values are:
- Available:
Port Status = 1. The port can both send and receive cells ✅ When a port switches to Available from any other administrative state, all dynamically assigned virtual connections MUST be cleared and a new Port Session Number MUST be generated 🔄 - Unavailable:
Port Status = 2. The port has been intentionally taken out of service. It won't transmit cells, and it won't receive them either 🚫 - Internal Loopback:
Port Status = 3. The port has been intentionally taken out of service and is in internal loopback. Cells coming from the switch fabric to the output port get looped back to the input port so they return to the switch fabric 🔁 All the ATM functions of the input port above the PHY layer (for example, header translation) get performed on those looped-back cells. - External Loopback:
Port Status = 4. The port has been intentionally taken out of service and is in external loopback. Cells arriving at the input port from the external link get looped straight back out to the link at the physical layer, without entering the input port 🪞 None of the ATM functions of the input port above the PHY layer happen to these looped-back cells. - Bothway Loopback:
Port Status = 5. The port has been intentionally taken out of service and is in both internal and external loopback 🌀
Port Type 🧵 This is the type of physical transmission interface for the port. The values come from the IANAifTYPE object in the MIB defined for the IANAifTYPE-MIB, as specified in RFC 1573 [rfc1573]. Example values are: SONET or SDH (39), DS-3 (30) 📡
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 Line Status changes to Up from either Down or Test, a new Port Session Number MUST be generated 🙌 - Down:
Line Status = 2. The line can't send cells, can't receive them, or can't do either 💀 - Test:
Line Status = 3. The port or line is in a test mode, for example during a power-on test 🧪
Priorities 🥇 This is the number of different priorities this output port can assign to virtual channel 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 connections based on their priority is assumed to be a feature of the switch's output port. It may be assumed that for virtual channel connections sharing the same output port, an ATM cell on a higher-priority connection is much more likely to leave the switch before an ATM cell on a lower-priority connection, if both are in the switch at the same time 🏃♀️💨
6.3. All Ports Configuration Message 🧚
okay so the All Ports Configuration message is how you ask the switch for the config info of every single port it has, all in one go 💅 main character energy fr. Here's the message type:
Message Type = 66
The Port field isn't used in the request, so it just gets set to zero 🙈
The All Ports Configuration 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Records | Port Record Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Port Records ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Number of Recordstells you how many Port Records are coming along in the message. The max is 64 port records per single success response 💖 If a switch has more than 64 ports, it must send them across multiple success response messages. no cap, that's the rule 🫶Port Record Lengthis the length of each port record in bytes. It's currently24, but this field leaves room to tack new fields onto the end of the port record later on while staying compatible with earlier versions of the protocol 🦋
The Port Records fill up the rest of the message, and each one looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | Min VPI | zero | Max VPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min VCI | Max VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cell Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Status | Port Type | Line Status | Priorities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The fields in each port record mean exactly the same thing as they do in the Port Configuration message, so no new definitions to memorise, bestie ✨
7. Event Messages 🔥
Event messages let the switch tell the controller about certain asynchronous events. They are not acknowledged 🙅 The Result and Code fields in the message header aren't used and should be set to zero. Event messages are also not sent during initialization. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Porttells you which switch port the event message is about 📍Port Session Numberis the current Port Session Number for that port 🎀Event Sequence Numberis the current value of the Event Sequence Number for that port. It starts atzerowhen the port is initialized, and goes up by one every time an asynchronous event is detected on that port that 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 sending the Event message. Yes, it still counts 😭VPI/VCItells you which VPI/VCI the event message is about. If the event message doesn't need this field, it's set tozero🌸
Each switch port must keep 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 isn't allowed to send another Event message of the same type until that Event Flag gets reset. Event Flags are reset by the "Reset Event Flags" function of the Port Management message. This is a simple flow control that stops the switch from flooding the controller with event messages 🛑 The port's Event Sequence Number must be incremented every time an event is detected on that port, even if flow control stops it from reporting the event. That's how the controller can tell it missed some events on that port because of flow control 🕵️♀️
7.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 switch port's Line Status changes to Up from either Down or Test, a new Port Session Number must be generated, preferably using some form of random number 🎲 The new Port Session Number goes in the Port Session Number field. The VPI/VCI field isn't used, so it's set to zero. The Port Up message is:
Message Type = 80
7.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
7.3. Invalid VPI/VCI Message 🙈
The Invalid VPI/VCI message is sent to tell the controller that one or more cells have shown up at an input port with a VPI/ VCI that isn't currently allocated to an assigned connection. The input port is shown in the Port field, and the VPI/VCI goes in the VPI/VCI field. The Invalid VPI/VCI message is:
Message Type = 82
7.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. It 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
7.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
8. Adjacency Protocol 🫶
The adjacency protocol is used to synchronize state across the link, to discover the identity of the entity at the other end of the link, and to detect when that identity changes 👀 No GSMP messages other than those of the adjacency protocol may be sent across the link until the adjacency protocol has achieved synchronization. So it's adjacency first, then everything else, periodt 💅
8.1 Packet Format ✨
okay so the adjacency protocol is giving "hi, who are you, are we connected" energy 🫶 its message type is Message Type = 10, and every GSMP message in this protocol has the same 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Name |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Receiver Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Version
The GSMP protocol version number, currently Version = 1. It should be set by the sender of the message to the GSMP protocol version that the sender is currently running. 🎀
Result
The Result field is not used in the adjacency protocol 💅 It should be set to zero by the sender and ignored by the receiver.
Code
The Code field tells you what the message is for. 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 is unique within the operational context of the device. A 48 bit IEEE 802 MAC address, if available, may be used for the Sender Name. 🦋
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 of the message believes is at the far end of the link. If the sender of the message does not know the name of the entity at the far end of the link, 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 across which the message is being sent. Port numbers are locally assigned 32 bit values. ✨
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, allocated by the entity at the far end of the link. If the sender of the message does not know the port number at the far end of the link, 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 of the link 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. 🙈
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, allocated by the entity at the far end of the link. If the sender of the message does not know the current instance number at the far end of the link, 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.
8.2 Procedure 👑
the adjacency protocol is described by the rules and state tables in this section, so this is the part where it all clicks 🫶
The rules and state tables use the following operations:
- The "Update Peer Verifier" operation is defined as storing the values of the Sender Instance, Sender Port, and Sender Name fields from a SYN or SYNACK message received from the entity at the far end of the link.
- The procedure "Reset the link" is defined as:
- Generate a new instance number for the link
- Delete the peer verifier (set to zero the values of Sender Instance, Sender Port, and Sender Name previously stored by the Update Peer Verifier operation)
- Send a SYN message
- Enter the SYNSENT state
The state tables use the following 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 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
Else the following State Tables.State synchronization across a link is considered to be achieved when the protocol reaches the ESTAB state. 🎉
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 1) | ESTAB |
+--------------------+-------------------------------------+-----------+
| ACK && B && C | Send ACK (note 1) | ESTAB |
+--------------------+-------------------------------------+-----------+
| ACK && !(B && C) | Send RSTACK | ESTAB |
+======================================================================+Note 1: No more than one ACK should be sent within any time period of length defined by the timer. 🌈
9. Failure Response Messages ✨
okay so when the switch can't do what you asked, it doesn't just leave you on read 💀 it sends back your request message with the Result field in the header set to indicate failure (Result = 4), and the Code field says exactly why it couldn't deliver. Code 16 is the special one: it's for failures specific to that particular message type, and what it means gets explained in the text describing that message. Here's the full list of failure codes 💅
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: One or more of the specified VPIs or VCIs is out of range on
one or more of the requested ports.
8: The specified connection does not exist.
9: The specified branch does not exist.
10: A branch belonging to the specified multicast connection is
already established on the specified output port and the
switch cannot support more than a single branch of any
multicast connection on the same output port.
11: The limit on the maximum number of multicast connections that
the switch can support has been reached.
12: The limit on the maximum number of branches that the
specified multicast connection can support has been reached.
13: Unable to assign the requested VPI/VCI value to the requested
branch on the specified multicast connection.
14: General problem related to the manner in which multicast is
supported by the switch.
15: Out of resources (e.g. memory exhausted, etc.).
16: Failure specific to the particular message type.REFERENCES 📚
[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.
[rfc1700] "Assigned Numbers," STD 2, RFC 1700, October 1994.
[rfc1573] "Evolution of the Interfaces Group of MIB-II," RFC 1573,
January 1994.SECURITY CONSIDERATIONS 🔒
okay so the tea is that this document doesn't discuss security issues at all 🙈 that's the whole section. Security issues are not discussed in this document.
AUTHORS' ADDRESSES 🎀
Peter Newman Phone: +1 (415) 846-4603
Ipsilon Networks, Inc. Email: pn@ipsilon.com
W. L. Edwards, Chief Scientist Phone: +1 (913) 534 5334
Sprint Email: texas@sprintcorp.com
Robert M. Hinden Phone: +1 (415) 846-4604
Ipsilon Networks, Inc. Email: hinden@ipsilon.com
Eric Hoffman Phone: +1 (415) 846-4610
Ipsilon Networks, Inc. Email: hoffman@ipsilon.com
Fong Ching Liaw Phone: +1 (415) 846-4607
Ipsilon Networks, Inc. Email: fong@ipsilon.com
Tom Lyon Phone: +1 (415) 846-4601
Ipsilon Networks, Inc. Email: pugs@ipsilon.com
Greg Minshall Phone: +1 (415) 846-4605
Ipsilon Networks, Inc. Email: minshall@ipsilon.comIpsilon Networks, Inc. is located at:
2191 East Bayshore Road
Suite 100
Palo Alto, CA 94303
USASprint is located at:
Sprint
Sprint Technology Services - Long Distance Division
9300 Metcalf Avenue
Mailstop KSOPKB0802
Overland Park, KS 66212-6333
USA📦 where this page comes from
- ietf: rfc1987 1996-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms