doc: Add RFC documents

1 files changed, 6107 insertions, 0 deletions

diff --git a/doc/rfc/rfc2297.txt b/doc/rfc/rfc2297.txt
new file mode 100644
index 0000000..ac0a32e
--- /dev/null
+++ b/doc/rfc/rfc2297.txt
@@ -0,0 +1,6107 @@
+
+
+
+
+
+
+Network Working Group                                    P. Newman, Nokia
+Request for Comments: 2297                             W. Edwards, Sprint
+Updates: 1987                                            R. Hinden, Nokia
+Category: Informational                                 E. Hoffman, Nokia
+                                                            F. Ching Liaw
+                                                           T. Lyon, Nokia
+                                                   G. Minshall, Fiberlane
+                                                               March 1998
+
+
+       Ipsilon's General Switch Management Protocol Specification
+                              Version 2.0
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+
+Abstract
+
+   This memo specifies enhancements to the  General Switch Management
+   Protocol (GSMP) [RFC1987]. The major enhancement is the addition of
+   Quality of Service (QoS) messages. Other improvements have been made
+   to the protocol resulting from operational experience. GSMP is a
+   general purpose protocol to control an ATM switch. It allows a
+   controller to establish and release connections across the switch;
+   add and delete leaves on a multicast connection; manage switch ports;
+   request configuration information; and request statistics.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman, et. al.              Informational                      [Page 1]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+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
+
+
+
+Newman, et. al.              Informational                      [Page 2]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+      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
+
+   The General Switch Management Protocol (GSMP), is a general purpose
+   protocol to control an ATM switch. GSMP allows a controller to
+   establish and release connections across the switch; add and delete
+   leaves on a multicast connection; manage switch ports; request
+   configuration information; and request statistics. It also allows the
+   switch to inform the controller of asynchronous events such as a link
+   going down. GSMP runs across an ATM link connecting the controller to
+   the switch, on a control connection (virtual channel) established at
+   initialization. GSMP operation across an Ethernet link is also
+   specified. The GSMP protocol is asymmetric, the controller being the
+   master and the switch being the slave. Multiple switches may be
+   controlled by a single controller using multiple instantiations of
+   the protocol over separate control connections.
+
+   A switch is assumed to contain multiple "ports". Each port is a
+   combination of one "input port" and one "output port". Some GSMP
+   requests refer to the port as a whole whereas other requests are
+   specific to the input port or the output port.  ATM cells arrive at
+   the switch from an external communication link on incoming virtual
+   paths or virtual channels at an input port. ATM cells depart from the
+   switch to an external communication link on outgoing virtual paths or
+   virtual channels from an output port. Virtual paths on a port or link
+   are referenced by their virtual path identifier (VPI). Virtual
+   channels on a port or link are referenced by their virtual path and
+   virtual channel identifiers (VPI/VCI).
+
+
+
+Newman, et. al.              Informational                      [Page 3]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   A virtual channel connection across a switch is formed by connecting
+   an incoming virtual channel to one or more outgoing virtual channels.
+   Virtual channel connections are referenced by the input port on which
+   they arrive and the virtual path and virtual channel identifiers
+   (VPI/VCI) of their incoming virtual channel. A virtual path
+   connection across a switch is formed by connecting an incoming
+   virtual path to one or more outgoing virtual paths. Virtual path
+   connections are referenced by the input port on which they arrive and
+   their virtual path identifier (VPI).  In a virtual path connection
+   the value of the VCI in each cell on that, connection is not used by
+   the switch and remains unchanged by the switch.
+
+   GSMP supports point-to-point and point-to-multipoint connections. A
+   multipoint-to-point connection is specified by establishing multiple
+   point-to-point connections each of them specifying the same output
+   branch. A multipoint-to-multipoint connection is specified by
+   establishing multiple point-to-multipoint trees each of them
+   specifying the same output branches.
+
+   In general a virtual channel is established with a certain quality of
+   service (QoS). A rich set of QoS messages is introduced in this
+   version of the protocol. However, implementation or operation of GSMP
+   without any of the messages defined in Section 9, "Quality of service
+   messages," is permitted.  In this case each virtual channel
+   connection or virtual path connection may be assigned a priority when
+   it is established. It may be assumed that for virtual 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 port of
+   the switch supports may be obtained from the port configuration
+   message.
+
+   GSMP contains an adjacency protocol. The adjacency protocol is used
+   to synchronize state across the link, to negotiate which version of
+   the GSMP protocol to use, to discover the identity of the entity at
+   the other end of a link, and to detect when it changes.
+
+
+2. GSMP Packet Encapsulation
+
+2.1 ATM Encapsulation
+
+   GSMP packets are variable length and for an ATM data link layer they
+   are encapsulated directly in an AAL-5 CPCS-PDU [I.363] with an
+   LLC/SNAP header as illustrated:
+
+
+
+
+
+Newman, et. al.              Informational                      [Page 4]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+    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)               +
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   (The convention in the documentation of Internet Protocols [RFC1700]
+   is to express numbers in decimal. Numbers in hexadecimal format are
+   specified by prefacing them with the characters "0x".  Data is
+   pictured in "big-endian" order. That is, fields are described 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, the order of transmission of those octets is the normal order
+   in which they are read in English. Whenever an octet represents a
+   numeric quantity the left most bit in the diagram is the high order
+   or most significant bit. That is, the bit labeled 0 is the most
+   significant bit. Similarly, whenever a multi-octet field represents a
+   numeric quantity the left most bit of the whole field is the most
+   significant bit. When a multi-octet quantity is transmitted, the most
+   significant octet is transmitted first. This is the same coding
+   convention as is 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 over which a GSMP session is established between
+   a controller and the switch it is 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 is:
+
+      VPI = 0
+      VCI = 15.
+
+
+
+
+Newman, et. al.              Informational                      [Page 5]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+2.2 Ethernet Encapsulation
+
+   GSMP packets may be encapsulated on an Ethernet data link as
+   illustrated:
+
+    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                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Destination Address
+             For the SYN message of the adjacency protocol the
+             Destination Address is the broadcast address
+             0xFFFFFFFFFFFF. (Alternatively, it is also valid to
+             configure the node with the unicast 48-bit IEEE MAC address
+             of the destination. In this 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. This address may
+             be discovered from the Source Address field of messages
+             received during synchronization of the adjacency protocol.
+
+   Source Address
+             For all messages the Source Address is the 48-bit IEEE MAC
+             address of the sender.
+
+   Ethertype
+             The assigned Ethertype for GSMP is 0x880C.
+
+
+
+
+Newman, et. al.              Informational                      [Page 6]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   GSMP Message
+             The maximum transmission unit (MTU) of the GSMP Message
+             field is 1492 octets.
+
+   Sender Instance
+             The Sender Instance number for the link obtained from the
+             adjacency protocol.  This field is already present in the
+             adjacency protocol message. It is appended to all non-
+             adjacency GSMP messages in the Ethernet encapsulation to
+             offer additional protection against the introduction of
+             corrupt state.
+
+   Receiver Instance
+             The Receiver Instance number is what the sender believes is
+             the current instance number for the link, allocated by the
+             entity at the far end of the link.  This field is already
+             present in the adjacency protocol message. It is appended
+             to all non-adjacency GSMP messages in the Ethernet
+             encapsulation to offer additional 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 such
+             that it 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.
+
+   After the adjacency protocol has achieved synchronization, for every
+   GSMP message received with an Ethernet encapsulation, the receiver
+   must check 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 do not 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 has achieved synchronization.  In addition, the incoming
+   message must also be discarded if the Receiver Instance field does
+   not match the current value for the Sender Instance of the GSMP
+   adjacency protocol.
+
+
+3. Common Definitions and Procedures
+
+   GSMP is a master-slave protocol. The controller issues request
+   messages to the switch. Each request message indicates whether a
+   response is required from the switch and contains a transaction
+
+
+
+Newman, et. al.              Informational                      [Page 7]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   identifier to enable the response to be associated with the request.
+   The switch replies with a response message indicating either a
+   successful result or a failure. There are five classes of GSMP
+   request-response message: Connection Management, Port Management,
+   State and Statistics, Configuration, and Quality of Service.  The
+   switch may also generate asynchronous Event messages to inform the
+   controller of asynchronous events.  Event messages are not
+   acknowledged by the controller. There is also an adjacency protocol
+   message 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 as they are not 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 the 32
+   bits into subfields that have meaning to the physical structure of
+   the switch (e.g. slot, 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 the purposes of network
+   management 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 allows the controller to detect a link failure and to
+   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
+
+   All GSMP messages, except the adjacency protocol message, have the
+   following format:
+
+
+
+
+
+
+
+Newman, et. al.              Informational                      [Page 8]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+    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 version number of the GSMP protocol being used in this
+             session. It should be set by the sender of the message to
+             the GSMP protocol version negotiated by the adjacency
+             protocol.
+
+   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 number of different message types. In
+             addition, one Message Type is allocated to the adjacency
+             protocol.
+
+   Result
+             Field in a Connection Management request message, a Port
+             Management request message, or a Quality of Service request
+             message is used to indicate whether a response is required
+             to the request message if the outcome is successful. A
+             value of "NoSuccessAck" indicates that the request message
+             does not expect a response if the outcome is successful,
+             and a value of "AckAll" indicates that a response is
+             expected if the outcome is successful.  In both cases a
+             failure response must be generated if the request fails.
+             For Sate and Statistics, and Configuration request
+             messages, a value of "NoSuccessAck" in the request message
+             is ignored and the request message is handled as if the
+             field were set to "AckAll". (This facility was added to
+             reduce the control traffic in the case where the controller
+             periodically checks that the state in the switch is
+             correct. If the controller does not use this capability,
+             all request messages should be sent with a value of
+             "AckAll.")
+
+
+
+
+
+
+Newman, et. al.              Informational                      [Page 9]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             In a response message the result field can have three
+             values: "Success," "More," and "Failure". The "Success" and
+             "More" results both indicate a success response. The "More"
+             result indicates that the success response exceeds the
+             maximum transmission unit of the data link and that one or
+             more further messages will be sent to complete the success
+             response. All messages that belong to the same success
+             response will have the same Transaction Identifier. The
+             "Success" result indicates a success response that may be
+             contained in a single message or the final message of a
+             success response spanning multiple 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.
+
+   Code
+             Field gives further information concerning the result in a
+             response message. It is mostly used to pass an error code
+             in a failure response but can also be used to give further
+             information in a success response message or an event
+             message. In a request message the code field is not used
+             and is set to zero. In an adjacency protocol message the
+             Code field is used to determine the function of the
+             message.
+
+   Transaction Identifier
+             Used to associate a request message with its response
+             message. For request messages the controller may select any
+             transaction identifier. For response messages the
+             transaction identifier is set to the value of the
+             transaction identifier from the message to which it is a
+             response.  For event messages the transaction identifier
+             should be set to zero. The Transaction Identifier is not
+             used, and the field is not present, in the adjacency
+             protocol.
+
+   The following fields are frequently found in GSMP messages. They are
+   defined here to avoid repetition.
+
+
+
+
+Newman, et. al.              Informational                     [Page 10]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   Port
+             Gives the port number of the switch port to which the
+             message applies.
+
+   Port Session Number
+             Each switch port maintains a Port Session Number assigned
+             by the switch. The port session number of a port remains
+             unchanged 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.
+
+             If the Port Session Number in a request message does not
+             match the current Port Session Number for the specified
+             port, a failure response message must be returned with the
+             Code field indicating, "Invalid port session number."  The
+             current port session number for a port may be obtained
+             using a Port Configuration or an All Ports Configuration
+             message.
+
+   Any field in a GSMP message that is unused or defined as "reserved"
+   must be set to zero by the sender and ignored by the receiver.
+
+   It is not an error for a GSMP message to contain additional data
+   after the end of the Message Body. This is 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.
+
+   A success response message must not be sent until the requested
+   operation has been successfully completed.
+
+3.2 Failure Response Messages
+
+   A failure response message is formed by returning the request message
+   that caused the failure with the Result field in the header
+   indicating failure (Result = 4) and the Code field giving the failure
+   code. The failure code specifies the reason for the switch being
+   unable to satisfy the request message.
+
+   If the switch issues a failure response in reply to a request
+   message, no change should be made to the state of the switch as a
+   result of the message causing the failure. (For request messages that
+   contain multiple requests, such as the Delete Branches message, the
+
+
+
+Newman, et. al.              Informational                     [Page 11]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   failure response message will specify which requests were successful
+   and which failed. The successful requests may result in changed
+   state.)
+
+   If the switch issues a failure response it must choose the most
+   specific failure code according to the following precedence:
+
+       Invalid Message
+
+       Failure specific to the particular message type (failure code
+           16). (The meaning of this failure is dependent upon the
+           particular message type and is specified in the text defining
+           the message.)
+
+       A failure response specified in the text defining the message
+           type.
+
+       Connection Failures
+
+       Virtual Path Connection Failures
+
+       Multicast Failures
+
+       QoS Failures (QoS failures are specified in Section 9.7.)
+
+       General Failures
+
+   If multiple failures match in any of the following categories, the
+   one that is listed first should be returned. The following failure
+   response messages and failure codes are defined:
+
+   Invalid Message
+
+       3:  The specified request is not implemented on this switch.
+               The Message Type field specifies a message that is not
+               implemented on the switch or contains a value that is not
+               defined in the version of the protocol running in this
+               session of GSMP.
+
+       5:  One or more of the specified ports does not exist.
+               At least one of the ports specified in the message is
+               invalid. A port is invalid if it does not exist or if it
+               has been removed from the switch.
+
+       4:  Invalid Port Session Number.
+               The value given in the Port Session Number field does not
+               match the current Port Session Number for the specified
+               port.
+
+
+
+Newman, et. al.              Informational                     [Page 12]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   Connection Failures
+
+       8:  The specified connection does not exist.
+               An operation that expects a connection to be specified,
+               either a virtual channel or a virtual path connection,
+               cannot locate the specified connection. A virtual channel
+               connection is specified by the input port, input VPI, and
+               input VCI on which it arrives. A virtual path connection
+               is specified by the input port and input VPI on which it
+               arrives.
+
+       9:  The specified branch does not exist.
+               An operation that expects a branch of an existing
+               connection to be specified, either a virtual channel or a
+               virtual path connection, cannot locate the specified
+               branch.  A branch of a virtual channel connection is
+               specified by the virtual channel connection it belongs to
+               and the output port, output VPI, and output VCI on which
+               it departs. A branch of a virtual path connection is
+               specified by the virtual path connection it belongs to
+               and the output port and output VPI on which it departs.
+
+       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 of 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 are not 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 either the requested input port or the
+               requested output port.
+               One or both of the requested input and output ports is
+               unable to support point-to-multipoint virtual path
+               connections.
+
+
+
+Newman, et. al.              Informational                     [Page 13]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+       26: Attempt to add a virtual path connection branch to an
+               existing virtual channel connection.
+               It is invalid to mix branches switched as virtual channel
+               connections with branches switched as virtual path
+               connections on the same point-to-multipoint connection.
+
+       27: Attempt to add a virtual channel connection branch to an
+               existing virtual path connection.
+               It is invalid to mix branches switched as virtual channel
+               connections with branches switched as virtual path
+               connections on the same point-to-multipoint connection.
+
+   Multicast Failures
+
+       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.
+
+       17: Cannot label each output branch of a point-to-multipoint tree
+               with a different label.
+               Some early designs, and some low-cost ATM switch designs,
+               require all output branches of a multicast connection to
+               use the same value of VPI/VCI.
+
+       28: Only point-to-point bidirectional connections may be
+               established.
+               It is an error to attempt to add an additional output
+               branch to an existing connection with the bidirectional
+               flag set.
+
+       13: Unable to assign the requested VPI/VCI value to the requested
+               branch on the specified point-to-multipoint connection.
+               Although the requested VPI and VCI are valid, the switch
+               is unable to support the request using the specified
+               values of VPI and VCI for some reason not covered by the
+               above failure responses. This message implies that a
+               valid value of VPI or VCI exists that the switch could
+
+
+
+
+
+Newman, et. al.              Informational                     [Page 14]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+               support. For example, some switch designs restrict the
+               number of distinct VPI/VCI values available to a point-
+               to-multipoint connection. (Most switch designs will not
+               require this message.)
+
+       14: General problem related to the manner in which point-to-
+               multipoint is supported by the switch.
+               Use this message if none of the more specific multicast
+               failure messages apply.  (Most switch designs will not
+               require this message.)
+
+   General Failures
+
+       2:  Invalid request message.
+               There is an error in one of the fields of the message not
+               covered by a more specific failure message.
+
+       6:  One or more of the specified ports is down.
+               A port is down if its Port Status is Unavailable.
+               Connection Management, Connection State, Port Management,
+               and Configuration operations are permitted on a port that
+               is Unavailable. Connection Activity and Statistics
+               operations are not permitted on a port that is
+               Unavailable and will generate this failure response. A
+               Port Management message specifying a Take Down function
+               on a port already in the Unavailable state will also
+               generate this failure response.
+
+       15: Out of resources.
+               The switch has exhausted a resource not covered by a more
+               specific failure message, for example, running out of
+               memory.
+
+       1:  Unspecified reason not covered by other failure codes.
+               The failure message of last resort.
+
+   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.
+
+
+
+Newman, et. al.              Informational                     [Page 15]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+       32: Requested transmit cell rate out of range for this output
+               port.
+
+
+4. Connection Management Messages
+
+   Connection management messages are used by the controller to
+   establish, delete, modify and verify virtual channel connections and
+   virtual path connections across the switch. The Add Branch, Delete
+   Tree, and Delete All connection management messages have 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 used as a hint for point-to-
+             multipoint connections in the Add Branch message. It is not
+             used in any other connection management messages and in
+             these messages it should be set to zero. If set, it
+             indicates that the virtual channel connection or the
+             virtual path connection is very likely to be a point-to-
+             multipoint connection. If zero, it indicates that this
+             connection is very likely to be a point-to-point connection
+             or is unknown.
+
+
+
+
+Newman, et. al.              Informational                     [Page 16]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             The Multicast flag is only used in the Add Branch message
+             when establishing the first branch of a new connection. It
+             is not required to be set when establishing subsequent
+             branches of a point-to-multipoint connection and on such
+             connections it should be ignored by the receiver. (On
+             receipt of the second and subsequent Add Branch messages
+             the receiver knows that this is a point-to-multipoint
+             connection.) If it is known that this is the first branch
+             of a point-to-multipoint connection this flag should be
+             set. If it is unknown, or if it is known that the
+             connection is point-to-point this flag should be zero. The
+             use of this flag is not mandatory. It may be ignored by the
+             switch.  If unused the flag should be set to zero. Some
+             switches use a different data structure for point-to-
+             multipoint connections than for point-to-point connections.
+             This flag avoids the switch setting up a point-to-point
+             structure for the first branch of a point-to-multipoint
+             connection which must immediately be deleted and
+             reconfigured as point-to-multipoint when the second branch
+             is established.
+
+        Q: QoS Profile
+             The QoS Profile flag, if set, indicates that the Class of
+             Service field contains a QoS Profile Identifier.  If this
+             flag is zero, it indicates that the Class of Service field
+             contains a Priority or a Scheduler Identifier.
+
+        B: Bidirectional
+             The Bidirectional flag applies only to the Add Branch
+             message. In all other Connection Management messages it is
+             not used. It may only be used when establishing a point-
+             to-point connection.  The Bidirectional flag in an Add
+             Branch message, if set, requests that two unidirectional
+             virtual channels or virtual paths be established, one in
+             the forward direction, and one in the reverse direction. It
+             is equivalent to two Add Branch messages, one specifying
+             the forward direction, and one specifying the reverse
+             direction. The forward direction uses the values of Input
+             Port, Input VPI, Input VCI, Output Port, Output VPI, and
+             Output VCI as specified in the Add Branch message. The
+             reverse direction is derived by exchanging the values
+             specified in the Input Port, Input VPI, and Input VCI
+             fields, with those of the Output Port, Output VPI, and
+             Output VCI fields respectively. Thus, a virtual connection
+             in the reverse direction arrives at the input port
+             specified by the Output Port field, on the VPI/VCI
+             specified by the Output VPI and Output VCI fields. It
+             departs from the output port specified by the Input Port
+
+
+
+Newman, et. al.              Informational                     [Page 17]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             field, on the VPI/VCI specified by the Input VPI and Input
+             VCI fields.
+
+             The Bidirectional flag is simply a convenience to establish
+             two unidirectional virtual connections in opposite
+             directions between the same two ports, with identical
+             VPI/VCIs, using a single Add Branch message. In all future
+             messages the two unidirectional virtual connections must be
+             handled separately. There is no bidirectional delete
+             message. However, a single Delete Branches message with two
+             Delete Branch Elements, one for the forward connection and
+             one for the reverse, may be used.
+
+        C: Congestion Indication
+             The Congestion Indication flag, if set, requests that cells
+             on this connection be marked if congestion is experienced.
+             If this connection passes through a queue that the switch
+             considers to be congested, the Congestion Experienced bit
+             will be set in the Payload Type field of the cell header of
+             all cells on the connection. GSMP does not specify the
+             algorithm or any threshold by which the switch decides when
+             a queue is congested.
+
+   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. For virtual path
+             connections the Input VCI field is not used.
+
+   Output Port
+             Identifies a switch output port.
+
+   x: Unused
+
+   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. For
+             virtual path connections the Output VCI field is not used.
+
+
+
+
+Newman, et. al.              Informational                     [Page 18]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   Number of Branches
+             In a success response message and a failure response
+             message, gives the number of output branches on a virtual
+             channel connection or a virtual path connection after
+             completion of the requested operation.  (A point-to-point
+             connection will have one branch, a point-to-multipoint
+             connection will have two or more branches.) If the switch
+             is unable to keep track of the number of branches on a
+             virtual path connection or a virtual channel connection it
+             must respond with the value 0xFFFF meaning: "number of
+             branches unknown".  This field is not used in the request
+             message.
+
+   Class of Service
+             This field can contain either a QoS Profile Identifier, a
+             Priority, or a Scheduler Identifier.  If the QoS Profile
+             flag in the Flags field is set, the Class of Service field
+             contains a QoS Profile.  If the QoS Profile flag in the
+             Flags field is zero, and the value of the Class of Service
+             field is greater than or equal to 0x100, the Class of
+             Service field contains a Scheduler Identifier.  If the QoS
+             Profile flag in the Flags field is zero, and the value of
+             the Class of Service field is less than 0x100, the Class of
+             Service field contains a Priority. (Values of Scheduler
+             Identifier less than 0x100 are interpreted as priorities.)
+             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. It is
+             used to identify a QoS profile in the switch which
+             specifies the Quality of Service required by the
+             connection. QoS profiles are established by a mechanism
+             external to GSMP.
+
+             A Scheduler Identifier is an alternative method of
+             communicating the QoS requirements of a connection. The
+             Scheduler Identifier is defined in Section 9, "Quality of
+             Service Messages."
+
+             A Priority specifies the priority of the connection for Add
+             Branch and Move Branch messages that choose not to use a
+             QoS profile, or the QoS capabilities defined in Section 9,
+             "Quality of Service Messages." 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
+
+
+
+Newman, et. al.              Informational                     [Page 19]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             switch. It is assumed that for virtual path connections or
+             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.
+
+   For all connection management messages, except the Delete Branches
+   message, the success response message is a copy of the request
+   message returned with the Result field indicating success and the
+   Number of Branches field indicating the number of branches on the
+   connection after completion of the operation. The Code field is not
+   used in a connection management success response message.
+
+   The failure response message is a copy of the request message
+   returned with a Result field indicating failure and the Number of
+   Branches field indicating the number of branches on the connection.
+
+   Fundamentally, no distinction is made 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 will
+   establish a point-to-point virtual connection.  The second Add Branch
+   message with the same Input Port, Input VPI, and Input VCI fields
+   will convert the connection to a point-to-multipoint virtual
+   connection with two branches. (For virtual path connections the Input
+   VCI is not required.) However, to avoid possible inefficiency with
+   some switch designs, the Multicast Flag is provided. If the
+   controller knows that a new connection is point-to-multipoint when
+   establishing the first branch, it may indicate this in the Multicast
+   Flag.  Subsequent Add Branch messages with the same Input Port, Input
+   VPI, and Input VCI fields will add further branches to the point-to-
+   multipoint connection. Use of the Delete Branch message on a point-
+   to-multipoint connection with two branches will result in a point-
+   to-point connection. However, the switch may structure this
+   connection as a point-to-multipoint connection with a single output
+   branch if it chooses. (For some switch designs this structure may be
+   more convenient.) Use of the Delete Branch message on a point-to-
+   point connection will delete the point-to-point connection. There is
+   no concept of a connection with zero output branches. All connections
+   are unidirectional, 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 specified by establishing multiple
+   point-to-point connections each of them specifying the same output
+   branch.  (An output branch is specified by an output port and output
+
+
+
+Newman, et. al.              Informational                     [Page 20]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   VPI for a virtual path connection and by an output port, output VPI,
+   and output VCI for a virtual channel connection.) A multipoint-to-
+   multipoint connection is specified by establishing multiple point-
+   to-multipoint trees each of them specifying the same output branches.
+
+   The connection management messages apply both to virtual channel
+   connections and virtual path connections. The Add Branch and Move
+   Branch connection management messages have two Message Types. One
+   Message Type indicates that a virtual channel connection is required,
+   and the other Message Type indicates that a virtual path connection
+   is required. The Delete Branches, Delete Tree, and Delete All
+   connection management messages have only a single Message Type
+   because they do not need to distinguish between virtual channel
+   connections and virtual path connections. 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 may not be added to an existing
+   virtual path connection.  Conversely, virtual path branches may not
+   be added to an existing virtual channel connection.  In the Port
+   Configuration message each switch input port may declare whether it
+   is capable of supporting virtual path switching (i.e. accepting
+   connection management messages requesting virtual path connections).
+
+   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.
+
+4.1 Add Branch Message
+
+   The Add Branch message is a connection management message used to
+   establish a virtual channel connection or a virtual path connection
+   or to add an additional branch to an existing virtual channel
+   connection or virtual path connection. It may also be used to check
+   the connection state stored in the switch. The connection is
+   specified by the Input Port, Input VPI, and Input VCI fields. The
+   output branch is specified by the Output Port, Output VPI, and Output
+   VCI fields. The quality of service requirements of the connection are
+   specified by the Class of Service field. To request a virtual channel
+   connection the Virtual Channel Connection (VCC) Add Branch message
+   is:
+
+      Message Type = 16
+
+
+
+
+Newman, et. al.              Informational                     [Page 21]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   To request a virtual path connection the Virtual Path Connection
+   (VPC) Add Branch message is:
+
+      Message Type = 26
+
+   If a VPC Add Branch message is received and the switch input port
+   specified by the Input Port field does not support virtual path
+   switching, a failure response message must be returned indicating,
+   "Virtual path switching is not supported on this input port."
+
+   If the virtual channel connection specified by the Input Port, Input
+   VPI, and Input VCI fields; or the virtual path connection specified
+   by the Input Port and Input VPI fields; does not already exist, it
+   must be established with the single output branch specified in the
+   request message. If the Bidirectional Flag in the Flags field is set,
+   the reverse connection must also be established.  The output branch
+   should have the QoS attributes specified by the Class of Service
+   field.
+
+   For the VCC Add Branch message, if a virtual path connection already
+   exists on the virtual path specified by the Input Port and Input VPI
+   fields, a failure response message must be returned indicating,
+   "Attempt to add a virtual channel connection branch to an existing
+   virtual path connection." For the VPC Add Branch message, if a
+   virtual channel connection already exists on any of the virtual
+   channels within the virtual path specified by the Input Port and
+   Input VPI fields, a failure response message must be returned
+   indicating, "Attempt to add a virtual path connection branch to an
+   existing virtual channel connection."
+
+   If the virtual channel connection specified by the Input Port, Input
+   VPI, and Input VCI fields; or the virtual path connection specified
+   by the Input Port and Input VPI fields; already exists, but the
+   specified output branch does not, the new output branch must be
+   added.  The new output branch should have the QoS attributes
+   specified by the Class of Service field.
+
+   If the virtual channel connection specified by the Input Port, Input
+   VPI, and Input VCI fields; or the virtual path connection specified
+   by the Input Port and Input VPI fields; already exists and the
+   specified output branch also already exists, the QoS attributes of
+   the connection, specified by the Class of Service field, if different
+   from the request message, should be changed to that in the request
+   message.  A success response message must be sent if the Result field
+   of the request message is "AckAll".  This allows the controller to
+   periodically reassert the state of a connection or to change its
+   priority. If the result field of the request message is
+   "NoSuccessAck" a success response message should not be returned.
+
+
+
+Newman, et. al.              Informational                     [Page 22]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   This may be used to reduce the traffic on the control link for
+   messages that are reasserting previously established state. For
+   messages that are reasserting previously established state, the
+   switch must always check that this state is correctly established in
+   the switch hardware (i.e. the actual connection tables used to
+   forward cells).
+
+   If the output branch specified by the Output Port, Output VPI, and
+   Output VCI fields for a virtual channel connection; or the output
+   branch specified by the Output Port and Output VPI fields for a
+   virtual path connection; is already in use by any connection other
+   than that specified by the Input Port, Input VPI, and Input VCI
+   fields, then the resulting output branch will have multiple input
+   branches. If multiple point-to-point connections share the same
+   output branch the result will be a multipoint-to-point connection. If
+   multiple point-to-multipoint trees share the same output branches the
+   result will be a multipoint-to-multipoint connection.
+
+   If the virtual channel connection specified by the Input Port, Input
+   VPI, and Input VCI fields, or the virtual path connection specified
+   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 indicating: "Only point-to-point bidirectional
+   connections may be established."
+
+   It should be noted that different switches support multicast in
+   different ways. There will be a limit to the total number of point-
+   to-multipoint connections any switch can support, and possibly a
+   limit on the maximum number of branches that a point-to-multipoint
+   connection may specify.  Some switches also impose a limit on the
+   number of different VPI/VCI values that may be assigned to the output
+   branches of a point-to-multipoint connection. Many switches are
+   incapable of supporting more than a single branch of any particular
+   point-to-multipoint connection on the same output port. Specific
+   failure codes are defined for some of these conditions.
+
+4.2 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 remaining branches of the connection are deleted. A
+   virtual channel connection is specified by the Input Port, Input VPI,
+   and Input VCI fields. A virtual path connection is specified by the
+   Input Port and Input VPI fields. The Output Port, Output VPI, and
+   Output VCI fields are not used in this message. The Delete Tree
+   message is:
+
+      Message Type = 18
+
+
+
+Newman, et. al.              Informational                     [Page 23]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   If the Result field of the request message is "AckAll" a success
+   response message must be sent upon successful deletion of the
+   specified connection. The success message must not be sent until the
+   delete operation has been completed and if possible, not until all
+   data on the connection, queued for transmission, has been
+   transmitted. The Number of Branches field is not 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 function has been replaced by the Number of Branches field in the
+   success response to the Add Branch message which contains the number
+   of branches on a virtual channel connection after successful
+   completion of an add branch operation.
+
+      Message Type = 19 is reserved.
+
+   If a request message is received 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. On completion of
+   the operation all dynamically assigned VPI/VCI values for the
+   specified port must be unassigned, i.e. 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 are not 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 upon completion of the operation. The
+   Number of Branches field is not 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.
+
+
+
+
+Newman, et. al.              Informational                     [Page 24]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+         One or more of the specified ports does not exist.
+
+         Invalid Port Session Number.
+
+   If any field in a Delete All message not covered by the above failure
+   codes is invalid, a failure response must be returned indicating:
+   "Invalid request message." Else, the delete all operation must be
+   completed successfully and a success message returned. No other
+   failure messages are permitted.
+
+4.5 Delete Branches Message
+
+   The Delete Branches message is a connection management message used
+   to request one or more delete branch operations. Each delete branch
+   operation deletes a branch of a virtual channel connection or a
+   virtual path connection, or in the case of the last branch of a
+   connection, it deletes the connection. The Delete Branches message
+   is:
+
+      Message Type = 17
+
+   The 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                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Reserved            |      Number of Elements       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   ~                    Delete Branch Elements                     ~
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Number of Elements
+             Specifies the number of Delete Branch Elements to follow in
+             the message. The number of Delete Branch Elements in a
+             Delete Branches message must not cause the packet length to
+             exceed the maximum transmission unit defined by the
+             encapsulation.
+
+   Each Delete Branch Element specifies an output branch to be deleted
+   and has the following structure:
+
+
+
+
+
+Newman, et. al.              Informational                     [Page 25]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Port Session Number                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Input Port                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Error |      Input VPI        |          Input VCI            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Output Port                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |x x x x|      Output VPI       |          Output VCI           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Error
+             Is used to return a failure code indicating the reason for
+             the failure of a specific Delete Branch Element in 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 is used to indicate that the delete operation
+             specified by this Delete Branch Element was successful.
+             Values for the other failure codes are specified in Section
+             3.2, "Failure Response Messages."
+
+             All other fields of the Delete Branch Element have the same
+             definition as specified for the other connection management
+             messages.
+
+   In each Delete Branch Element, either a virtual channel connection is
+   specified by the Input Port, Input VPI, and Input VCI fields; or a
+   virtual path connection is specified by the Input Port and Input VPI
+   fields. The specific branch to be deleted is indicated by the Output
+   Port, Output VPI, and Output VCI fields for virtual channel
+   connections and by the Output Port and Output VPI for virtual path
+   connections.
+
+   If the Result field of the Delete Branches request message is
+   "AckAll" a success response message must be sent upon successful
+   deletion of the branches specified by all of the Delete Branch
+   Elements. The success response message must not be sent until all of
+   the delete branch operations have been completed. The success
+   response message is only sent if all of the requested delete branch
+   operations were successful. No Delete Branch Elements are returned in
+   a Delete Branches success response message and the Number of Elements
+   field must be set to zero.
+
+   If there is a failure in any of the Delete Branch Elements a Delete
+   Branches failure response message must be returned. The Delete
+   Branches failure response message is a copy of the request message
+   with the Code field of the entire message set to, "Failure specific
+
+
+
+Newman, et. al.              Informational                     [Page 26]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   to the particular message type," and the Error field of each Delete
+   Branch Element indicating the result of each requested delete
+   operation. A failure in any of the Delete Branch Elements must not
+   interfere with the processing of any other Delete Branch Elements.
+
+4.6 Move Branch Message
+
+   The Move Branch message is used to move a branch of an existing
+   connection from its current output port VPI/VCI to a new output port
+   VPI/VCI in a single atomic transaction. This operation occurs
+   frequently in IP switching, every time a flow is switched from hop-
+   by-hop forwarding to a dedicated virtual channel.  The Move Branch
+   connection management message has the following format for both
+   request and response messages:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    Version    | Message Type  |    Result     |     Code      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    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        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The VCC Move Branch message is a connection management message used
+   to move a single output branch of a virtual channel connection from
+   its current output port, output VPI, and output VCI, to a new output
+   port, output VPI, and output VCI on the same virtual channel
+   connection. None of the other output branches are modified.  When the
+   operation is complete the original output VPI/VCI on the original
+   output port will be deleted from the connection.  The VCC Move Branch
+   message is:
+
+
+
+
+Newman, et. al.              Informational                     [Page 27]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+      Message Type = 22
+
+   For the VCC Move Branch message, if the virtual channel connection
+   specified by the Input Port, Input VPI, and Input VCI fields already
+   exists, and the output branch specified by the Old Output Port, Old
+   Output VPI, and Old Output VCI fields exists as a branch on that
+   connection, the output branch specified by the New Output Port, New
+   Output VPI, and New Output VCI fields is added to the connection and
+   the branch specified by the Old Output Port, Old Output VPI, and Old
+   Output VCI fields is deleted. If the Result field of the request
+   message is "AckAll" a success response message must be sent upon
+   successful completion of the operation. The success response message
+   must not be sent until the Move Branch operation has been completed.
+
+   For the VCC Move Branch message, if the virtual channel connection
+   specified by the Input Port, Input VPI, and Input VCI fields already
+   exists, but the output branch specified by the Old Output Port, Old
+   Output VPI, and Old Output VCI fields does not exist as a branch on
+   that connection, a failure response must be returned with the Code
+   field indicating, "The specified branch does not exist."
+
+   The VPC Move Branch message is a connection management message used
+   to move a single output branch of a virtual path connection from its
+   current output port and output VPI, to a new output port and output
+   VPI on the same virtual channel connection. None of the other output
+   branches are modified.  When the operation is complete the original
+   output VPI on the original output port will be deleted from the
+   connection.  The VPC Move Branch message is:
+
+      Message Type = 27
+
+   For the VPC Move Branch message, if the virtual path connection
+   specified by the Input Port and Input VPI fields already exists, and
+   the output branch specified by the Old Output Port and Old Output VPI
+   fields exists as a branch on that connection, the output branch
+   specified by the New Output Port and New Output VPI fields is added
+   to the connection and the branch specified by the Old Output Port and
+   Old Output VPI fields is deleted. If the Result field of the request
+   message is "AckAll" a success response message must be sent upon
+   successful completion of the operation. The success response message
+   must not be sent until the Move Branch operation has been completed.
+
+   For the VPC Move Branch message, if the virtual path connection
+   specified by the Input Port and Input VPI fields already exists, but
+   the output branch specified by the Old Output Port and Old Output VPI
+   fields does not exist as a branch on that connection, a failure
+   response must be returned with the Code field indicating, "The
+   specified branch does not exist."
+
+
+
+Newman, et. al.              Informational                     [Page 28]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   If the virtual channel connection specified by the Input Port, Input
+   VPI, and Input VCI fields; or the virtual path connection specified
+   by the Input Port and  Input VPI fields; does not exist, a failure
+   response must be returned with the Code field indicating, "The
+   specified connection does not exist."
+
+   If the output branch specified by the New Output Port, New Output
+   VPI, and New Output VCI fields for a virtual channel connection; or
+   the output branch specified by the New Output Port and New Output VPI
+   fields for a virtual path connection; is already in use by any
+   connection other than that specified by the Input Port, Input VPI,
+   and Input VCI fields then the resulting output branch will have
+   multiple input branches. If multiple point-to-point connections share
+   the same output branch the result will be a multipoint-to-point
+   connection. If multiple point-to-multipoint trees share the same
+   output branches the result will be a multipoint-to-multipoint
+   connection.
+
+
+5. Port Management Messages
+
+5.1 Port Management Message
+
+   The Port Management message allows a port to be brought into service,
+   taken out of service, looped back, reset, or the transmit cell rate
+   changed.  Only the Bring Up and the Reset Input Port functions change
+   the connection state (established connections) on the input port.
+   Only the Bring Up function changes the value of the Port Session
+   Number. If the Result field of the request message is "AckAll" a
+   success response message must be sent upon successful completion of
+   the operation. The success response message must not be sent until
+   the operation has been completed. The Port Management Message is:
+
+      Message Type = 32
+
+   The Port Management message has the following format for the request
+   and success response messages:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman, et. al.              Informational                     [Page 29]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+    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 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. It is incremented by one each
+             time the port detects an asynchronous event that the switch
+             would normally report via an Event message. If the Event
+             Sequence Number in the success response differs from the
+             Event Sequence Number of the most recent Event message
+             received for that port, events have occurred that were not
+             reported via an Event message. This is most likely to be
+             due to the flow control that restricts the rate at which a
+             switch can send Event messages for each port. In the
+             request message this field is not used.
+
+   Event Flags
+             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 is not
+             permitted to send another Event message of the same type
+             until the Event Flag has been reset. If the Function field
+             in the request message is set to "Reset Event Flags," for
+             each bit that is set in the Event Flags field, the
+             corresponding Event Flag in the switch port is 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
+
+
+
+Newman, et. al.              Informational                     [Page 30]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             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 completion of the operation
+             specified by the request message, for all values of the
+             Function field. Setting the Event Flags field to all zeros
+             in a "Reset Event Flags" request message allows the
+             controller to obtain the current state of the Event Flags
+             and the current Event Sequence Number of the port without
+             changing the state of the Event Flags.
+
+             The correspondence between the types of Event message and
+             the bits of the Event Flags field is as follows:
+
+                 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
+             Is the length of time, in seconds, that any of the loopback
+             states remain in operation. When the duration has expired
+             the port will automatically be returned to service.  If
+             another Port Management message is received for the same
+             port before the duration has expired, the loopback will
+             continue to remain in operation for the length of time
+             specified by the Duration field in 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.
+
+   Function
+             Specifies the action to be taken. The specified action will
+             be taken regardless of the current status of the port
+             (Available, Unavailable, or any Loopback state).  If the
+             specified function requires a new Port Session Number to be
+             generated, 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. Bring the port into service. All
+
+
+
+Newman, et. al.              Informational                     [Page 31]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+                  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. On
+                  completion of the operation all dynamically assigned
+                  VPI/VCI values for the specified input port must be
+                  unassigned, i.e. no virtual connections will be
+                  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. Take the port out of service. Any cells
+                  received at this port will be discarded. No cells will
+                  be transmitted from this port. The Port Status of the
+                  port afterwards will be Unavailable.
+
+                  The behavior is undefined if the port is taken down
+                  over which the GSMP session that controls the switch
+                  is running. (In this case the most probable behavior
+                  would be for the switch either to ignore the message
+                  or to terminate the current GSMP session and to
+                  initiate another session, possibly with the backup
+                  controller, if any.) The correct method to reset the
+                  link over which GSMP is running is to issue an RSTACK
+                  message in the adjacency protocol.
+
+             Internal Loopback:
+                  Function = 3. Cells arriving at the output port from
+                  the switch fabric are looped through to the input port
+                  to return to the switch fabric. All of the ATM
+                  functions of the input port above the physical layer,
+                  e.g. header translation, are performed upon 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 are 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
+                  are performed upon the looped back cells. The Port
+                  Status of the port afterwards will be External
+                  Loopback.
+
+             Bothway Loopback:
+                  Function = 5. Both internal and external loopback are
+
+
+
+
+Newman, et. al.              Informational                     [Page 32]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+                  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 re-initialized. On completion of
+                  the operation all dynamically assigned VPI/VCI values
+                  for the specified input port must be unassigned, i.e.
+                  no virtual connections will be established in the
+                  VPI/VCI space that GSMP controls on this input port.
+                  The range of VPIs and VCIs that may be controlled by
+                  GSMP on this port will be set to the default values
+                  specified in the Port Configuration message.  The
+                  transmit cell rate of the output port must be set to
+                  its default value. The Port Session Number is not
+                  changed by the Reset Input Port function.  The Port
+                  Status of the port afterwards 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.
+
+             Set Transmit Cell Rate:
+                  Function = 8. Sets the transmit cell rate of the
+                  output port as close as possible to the rate specified
+                  in the Transmit Cell Rate field. In the success
+                  response message the Transmit Cell Rate must indicate
+                  the actual transmit cell rate of the output port.  If
+                  the transmit cell rate of the requested output port
+                  cannot 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 of the Transmit Cell Rate field
+                  is beyond 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
+                  contained in the request message that caused the
+                  failure. The transmit cell rate of the output port is
+                  not changed by the Bring Up, Take Down, or any of the
+                  Loopback functions. It is returned to the default
+                  value by the Reset Input Port function.
+
+
+
+
+Newman, et. al.              Informational                     [Page 33]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+        Transmit Cell Rate
+             This field is only used in request and success response
+             messages with the Function field set to "Set Transmit Cell
+             Rate." It is used to set the output cell rate of the output
+             port. It is 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
+
+   The default label range, Min VPI to Max VPI and Min VCI to Max VCI,
+   is specified for each port by the Port Configuration or the All Ports
+   Configuration messages.  When the protocol is initialized, before the
+   transmission of any Label Range messages, the label range of each
+   port will be set to the default label range. (The default label range
+   is dependent upon the switch design and configuration and is not
+   specified by the GSMP protocol.) The Label Range message allows the
+   range of VPIs supported by a specified port, or the range of VCIs
+   supported by a specified VPI on a specified port, to be changed.
+   Each switch port must declare whether it supports the Label Range
+   message in the Port Configuration or the All Ports Configuration
+   messages.  The Label Range message is:
+
+      Message Type = 33
+
+   The Label Range message has the following format for the request and
+   success response messages:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    Version    | Message Type  |    Result     |     Code      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    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         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+Newman, et. al.              Informational                     [Page 34]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   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, according
+             to the VPI/VCI flag. The current label range is not changed
+             by a request message with the Query flag set. If the Query
+             flag is zero, the message is requesting a label change
+             operation.
+
+        V: VPI/VCI
+             If the VPI/VCI flag is set, the message refers to a range
+             of VPIs only. 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 on a range of VPIs.
+
+        x: Unused
+
+   Min VPI
+   Max VPI
+             Specify a range of VPI values, Min VPI to Max VPI
+             inclusive.  A single VPI may be specified with a Min VPI
+             and a Max VPI having the same value.  In a request message,
+             if the value of the Max VPI field is less than or equal to
+             the value of the Min VPI field, the requested range is a
+             single VPI with a value equal to the Min VPI field. Zero is
+             a valid value.  In a request message, if the Query flag is
+             set, and the VPI/VCI flag is zero, the Max VPI field
+             specifies a single VPI and the Min VPI field is not used.
+             The maximum valid value of these fields for both request
+             and response messages is 0xFFF.
+
+   Min VCI
+   Max VCI
+             Specify a range of VCI values, Min VCI to Max VCI
+             inclusive.  A single VCI may be specified with a Min VCI
+             and a Max VCI having the same value.  In a request message,
+             if the value of the Max VCI field is less than or equal to
+             the value of the Min VCI field, the requested range is a
+             single VCI with a value equal to the Min VCI field. Zero is
+             a valid value.  (However, VPI=0, VCI=0 is not available as
+             a virtual channel connection as it is used as a special
+             value in ATM to indicate an unassigned cell.)
+
+   Remaining VPIs
+   Remaining VCIs
+             These fields are unused in the request message. In the
+
+
+
+Newman, et. al.              Informational                     [Page 35]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             success response message and in the failure response
+             message these fields give the maximum number of remaining
+             VPIs and VCIs that could be requested for allocation on the
+             specified port (after completion of the requested operation
+             in the case of the success response). It gives the switch
+             controller an idea of how many VPIs and VCIs it could
+             request. The number given is the maximum possible given the
+             constraints of the switch hardware. There is no implication
+             that this number of VPIs and VCIs is available to every
+             switch port.
+
+   If the Query flag and the VPI/VCI flag are set in the request
+   message, the switch must reply with a success response message
+   containing the current range of valid VPIs that are supported by the
+   port.  The Min VPI and Max VPI fields are not used in the request
+   message.
+
+   If the Query flag is set and the VPI/VCI flag is zero in the request
+   message, the switch must reply with a success response message
+   containing the current range of valid VCIs that are supported by the
+   VPI specified by the Max VPI field.  If the requested VPI is invalid,
+   a failure response must be returned indicating: "One or more of the
+   specified input VPIs is invalid." The Min VPI field is not used in
+   either the request or success response messages.
+
+   If the Query flag is zero and the VPI/VCI flag is set in the request
+   message, the Min VPI and Max VPI fields specify the new range of VPIs
+   to be allocated to the input port specified by the Port field.
+   Whatever the range of VPIs previously allocated to this port it
+   should be increased or decreased to the specified value.
+
+   If the Query flag and the VPI/VCI flag are zero in the request
+   message, the Min VCI and Max VCI fields specify the range of VCIs to
+   be allocated to each of the VPIs specified by the VPI range.
+   Whatever the range of VCIs previously allocated to each of the VPIs
+   within the specified VPI range on this port, it should be increased
+   or decreased to the specified value.  The allocated VCI range must be
+   the same on each of the VPIs within the specified VPI range.
+
+   The success response to a Label Range message requesting a change of
+   label range is a copy of the request message with the Remaining VPIs
+   and Remaining VCIs fields updated to the new values after the Label
+   Range operation.
+
+   If the switch is unable to satisfy a request to change the VPI range,
+   it must return a failure response message with the Code field set to
+   "Cannot support requested VPI range." In this failure response
+
+
+
+
+Newman, et. al.              Informational                     [Page 36]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   message the switch must use the Min VPI and Max VPI fields to suggest
+   a VPI range that it would be able to satisfy.
+
+   If the switch is unable to satisfy a request to change the VCI range
+   on all VPIs within the requested VPI range, it must return a failure
+   response message with the Code field set to "Cannot support requested
+   VCI range on all requested VPIs." In this failure response message
+   the switch must use the Min VPI, Max VPI, Min VCI, and Max VCI fields
+   to suggest a VPI and VCI range that it would be able to satisfy.
+
+   In all other failure response messages for the label range operation
+   the switch must return the values of Min VPI, Max VPI, Min VCI, and
+   Max VCI from the request message.
+
+   While switches can typically support all 256 or 4096 VPIs the VCI
+   range that can be supported is often more constrained. Often the Min
+   VCI must be 0 or 32. Typically all VCIs within a particular VPI must
+   be contiguous.  The hint in the failure response message allows the
+   switch to suggest a label range that it could satisfy in view of its
+   particular architecture.
+
+   While the Label Range message is defined to specify both a range of
+   VPIs and a range of VCIs within each VPI, the most likely use is to
+   change either the VPI range or the range of VCIs within a single VPI.
+   It is possible for a VPI to be valid but to be allocated no valid
+   VCIs. Such a VPI could be used for a virtual path connection but to
+   support virtual channel connections it would need to be allocated a
+   range of VCIs.
+
+   A Label Range request message may be issued regardless of the Port
+   Status or the Line Status of the target switch port. If the Port
+   field of the request message contains an invalid port (a port that
+   does not exist or a port that has been removed from the switch) a
+   failure response message must be returned 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 permit the controller to request
+   the values of various hardware counters associated with the switch
+   input and output ports, virtual path connections, virtual channel
+   connections, and QoS Classes.  They also permit the controller to
+   request the connection state of a switch input port.  The Connection
+   Activity message is used to determine whether one or more specific
+   virtual channel connections or virtual path connections have recently
+   been carrying traffic.  The Statistics message is used to query the
+   various port, connection, and QoS class traffic and error counters.
+
+
+
+Newman, et. al.              Informational                     [Page 37]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   The Report Connection State message is used to request an input port
+   to report the connection state for a single virtual channel
+   connection, a single virtual path connection, or for the entire input
+   port.
+
+6.1 Connection Activity Message
+
+   The Connection Activity message is used to determine whether one or
+   more specific virtual channel connections or virtual path connections
+   have recently been carrying traffic. The Connection Activity message
+   contains one or more Activity Records. Each Activity Record is used
+   to request and return activity information concerning a single
+   virtual channel connection or virtual path connection.  Each virtual
+   channel connection is specified by its input port, input VPI, and
+   input VCI. Each virtual path connection is specified by its input
+   port and input VPI. These are specified in the Input Port, Input VPI,
+   and Input VCI fields of each Activity Record.  Two forms of activity
+   detection are supported. 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 counted are not specified but will
+   typically be either cells or frames.  The controller must compare the
+   traffic counts returned in the message with previous values for each
+   of the specified connections to determine whether each connection has
+   been active in the intervening period.  If the switch does not
+   support per connection traffic accounting, but is capable of
+   detecting per connection activity by some other unspecified means,
+   the result may be indicated for each connection using the Flags
+   field. The Connection Activity message is:
+
+      Message Type = 48
+
+   The Connection Activity request and success response messages 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                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       Number of Records       |           Reserved            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   ~                       Activity Records                        ~
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Newman, et. al.              Informational                     [Page 38]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   Number of Records
+             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 the following 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 in order to identify the
+             connection (regardless of whether the traffic count for the
+             connection is maintained on the input port or the output
+             port).
+
+   Input VPI
+   Input VCI
+             Fields identify the specific virtual path connection or
+             virtual channel connection for which 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.
+
+
+
+
+Newman, et. al.              Informational                     [Page 39]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+        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
+             Field is not used in the request message.  In the success
+             response message, if the switch supports per connection
+             traffic counting, the Traffic Count field must be set to
+             the value of a free running, connection specific, 64-bit
+             traffic counter counting traffic flowing across the
+             specified connection.  The value of the traffic counter is
+             not modified by reading it.  If per connection traffic
+             counting is supported, the switch must report the
+             Connection Activity result using the traffic count rather
+             than using the Activity flag.
+
+   The format of the failure response is the same as the request message
+   with the Number of Records field set to zero and no VC Activity
+   records returned in the message. If the switch is incapable of
+   detecting per connection activity, a failure response must be
+   returned indicating, "The specified request is not implemented on
+   this switch."
+
+6.2 Statistics Messages
+
+   The Statistics messages are used to query the various port,
+   connection, and QoS class traffic and error counters.
+
+   The Statistics request messages have the following format:
+
+
+
+
+
+
+
+Newman, et. al.              Informational                     [Page 40]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+    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
+   VCI
+             Fields identify the specific virtual path connection or
+             virtual channel connection for which statistics are being
+             requested.  For a virtual path connection the Input VCI
+             field is not used.  For requests that do not require a
+             virtual path connection or virtual channel connection to be
+             specified, the VPI and VCI fields are not used.
+
+   QoS Class Identifier
+             Field identifies the QoS class for which statistics are
+             being requested. This field is only used if the QoS Class
+             Establishment message defined in section 9.4 is
+             implemented.
+
+   The success response for the Statistics message has the following
+   format:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman, et. al.              Informational                     [Page 41]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+    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                   +
+   |                                                               |
+
+
+
+Newman, et. al.              Informational                     [Page 42]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   +                  Output Frame Discard Count                   +
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Port
+   VPI/VCI
+   QoS Class Identifier
+             Fields are the same as those of the request message.
+
+   Input Cell Count
+   Output Cell Count
+             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
+   Output Frame Count
+             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
+   Output Cell Discard Count
+             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
+   Output Frame Discard Count
+             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
+             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. 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.
+
+
+
+Newman, et. al.              Informational                     [Page 43]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+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 to
+   which the cells belong.  Any of the count fields in the success
+   response message not supported by the port 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 to which the cells belong. 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 to which the cells belong. 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
+
+
+
+
+
+
+Newman, et. al.              Informational                     [Page 44]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+6.3 Report Connection State Message
+
+   The Report Connection State message is used to request an input port
+   to report the connection state for a single virtual channel
+   connection, a single virtual path connection, or for 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
+             Identifies the port number of the input port for which the
+             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.
+
+
+
+Newman, et. al.              Informational                     [Page 45]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             If the All Connections flag is zero and the VPI/VCI flag is
+             also zero, the message requests the connection state for
+             the virtual channel connection that arrives at the input
+             port specified by the Port, Input VPI and Input VCI fields.
+
+             x: Unused.
+
+   Input VPI
+   Input VCI
+             Fields identify the specific virtual path connection, the
+             specific virtual path, or the specific virtual channel
+             connection for which connection state is being requested.
+             For a virtual path connection (switched as a single virtual
+             path connection) or a virtual path (switched as one or more
+             virtual channel connections within the virtual path) the
+             Input VCI field is not used.  For requests that do not
+             require a virtual path connection or virtual channel
+             connection to be specified, the Input VPI and Input VCI
+             fields are not used.
+
+   The Report Connection State 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                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Input Port                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Sequence Number                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   ~                       Connection Records                      ~
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Input Port
+             Is the same as the Input Port field in the request message.
+             It identifies the port number of the input port for which
+             the connection state is being reported.
+
+   Sequence Number
+             In the case that the requested connection state cannot be
+             reported in a single success response message, each
+             successive success response message in reply to the same
+
+
+
+Newman, et. al.              Informational                     [Page 46]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             request message must increment the Sequence Number. The
+             Sequence Number of the first success response message, in
+             response to a new request message, must be zero.
+
+   Connection Records
+             Each success response message must contain one or more
+             Connection Records. Each Connection Record specifies a
+             single point-to-point or point-to-multipoint virtual path
+             connection or virtual channel connection. The number of
+             Connection Records in a single Report Connection State
+             success response must not cause the packet length to exceed
+             the maximum transmission unit defined by the encapsulation.
+             If the requested connection state cannot be reported in a
+             single success response message, multiple success response
+             messages must be sent. All success response messages that
+             are sent in response to the same request message must have
+             the same Input Port and Transaction Identifier fields as
+             the request message. A single Connection Record must not be
+             split across multiple success response messages. The More
+             flag of the last Connection Record in a success response
+             message indicates whether the response to the request has
+             been completed or whether one or more further success
+             response messages should be expected in response to the
+             same request message.
+
+   Each Connection Record has the following format:
+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |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
+             message the All Connections and the VPI/VCI flags must be
+             the same as those of the request message. For successive
+             Connection Records in the same success response message
+             these flags are not used.
+
+        P: VPC
+             The VPC flag, if set, indicates that the Connection Record
+             refers to a virtual path connection.  If zero, it indicates
+
+
+
+Newman, et. al.              Informational                     [Page 47]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             that the Connection Record refers to a virtual channel
+             connection.
+
+        M: More
+             If the More flag is set, it indicates that another
+             Connection Record, in response to the same request message,
+             will follow either in the same success response message or
+             in a successive success response message. If the More flag
+             is zero it indicates that this is the last Connection
+             record in this success response message and that no further
+             success response messages will be sent in response to the
+             current request message. It indicates that the response to
+             the request message is now complete.
+
+   Input VPI
+   Input VCI
+             The input VPI and VCI of the connection specified in this
+             Connection Record. If this Connection Record specifies a
+             virtual path connection (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 Output Branch Record specifies a
+             single output branch belonging to the connection identified
+             by the Input VPI and Input VCI fields of the Connection
+             Record. A point-to-point connection will require only a
+             single Output Branch Record. A point-to-multipoint
+             connection will require multiple Output Branch Records. The
+             last Output Branch Record of each Connection Record is
+             indicated by the Last Branch flag of the Output Branch
+             Record. If a point-to-multipoint connection has more output
+             branches than can fit in a single Connection Record
+             contained within a single success response message, that
+             connection may be reported using multiple Connection
+             Records in multiple success response messages.
+
+   Each Output Branch Record has the following format:
+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Output Port                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |L|x x x|       Output VPI      |          Output VCI           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Output Port
+             The output port of the switch to which this output branch
+             is routed.
+
+
+
+Newman, et. al.              Informational                     [Page 48]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   Flags
+
+        L: Last Branch
+             The Last Branch flag, if set, indicates that this is the
+             last Output Branch Record of this Connection Record. If
+             zero, it indicates that one or more further Output Branch
+             Records are to follow. If this is the last Output Branch
+             Record in the message and the Last Branch flag is zero,
+             further output branches belonging to the same connection
+             will be given in another Connection Record. This Connection
+             Record will be the first Connection Record in the next
+             success response message. This Connection Record 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 specified in
+             this Output Branch Record.  If this Output Branch Record is
+             part of a Connection Record that specifies a virtual path
+             connection (the VPC flag is set) the Output VCI field is
+             unused.
+
+   A Report Connection State request message may be issued regardless of
+   the Port Status or the Line Status of the target switch port.
+
+   If the Input Port of the request message is valid, and the All
+   Connections flag is set, but there are no connections established on
+   that port, a failure response message must be returned with the code
+   field set to, "Failure specific to the particular message type." For
+   the Report Connection State message, this failure code indicates that
+   no connections matching the request message were found.  This failure
+   message should also be returned if the Input Port of the request
+   message is valid, the All Connections flag is zero, and no
+   connections are found on that port matching the specified virtual
+   path connection, virtual path, or virtual channel connection.
+
+
+7. Configuration Messages
+
+   The configuration messages permit the controller to discover the
+   capabilities of the switch. Three configuration request messages have
+   been defined: Switch, Port, and All Ports.
+
+   All configuration request messages have the following format:
+
+
+
+
+Newman, et. al.              Informational                     [Page 49]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+    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
+
+   The Switch Configuration message requests the global (non port-
+   specific) configuration for the switch. The Switch Configuration
+   message is:
+
+      Message Type = 64
+
+   The Port field is not used in the request message.
+
+   The Switch 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                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    Firmware Version Number    |          Window Size          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Switch Type          |                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+   |                          Switch Name                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Firmware Version Number
+             The version number of the switch control firmware
+             installed.
+
+   Window Size
+             The maximum number of unacknowledged request messages that
+             may be transmitted by the controller without the
+             possibility of loss.  This field is used to prevent request
+             messages being lost in the switch because of overflow in
+             the receive buffer. The field is a hint to the controller.
+             If desired, the controller may experiment with higher and
+
+
+
+Newman, et. al.              Informational                     [Page 50]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             lower window sizes to determine heuristically the best
+             window size.
+
+   Switch Type
+             A 16-bit field allocated by the manufacturer of the switch.
+             (For these purposes the manufacturer of the switch is
+             assumed to be the organization identified by the OUI in the
+             Switch Name field.) The Switch Type identifies the product.
+             When the Switch Type is combined with the OUI from the
+             Switch Name the product is uniquely identified. Network
+             Management may use this identification to obtain product
+             related information from a database.
+
+   Switch Name
+             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 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.
+
+7.2 Port Configuration Message
+
+   The Port Configuration message requests the switch for the
+   configuration information of a single switch port. The Port field in
+   the request message specifies the port for which the configuration is
+   requested.  The Port Configuration message is:
+
+      Message Type = 65.
+
+   The Port Configuration success response message has the following
+   format:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman, et. al.              Informational                     [Page 51]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+    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
+             The switch port to which the configuration information
+             refers. Configuration information relating to both the
+             input and the output sides of the switch port is given.
+             Port numbers are 32 bits wide and allocated by the switch.
+             The switch may choose to structure the 32 bits into
+             subfields that have meaning to the physical structure of
+             the switch hardware (e.g.  physical slot and port). This
+             structure may be indicated in the Physical Slot Number and
+             Physical Port Number fields.
+
+   Flags
+
+        V: VP Switching
+             The VP Switching flag, if set, indicates that this input
+             port is capable of supporting virtual path switching. Else,
+             if zero, it indicates that this input port is only capable
+             of virtual channel switching.
+
+        M: Multicast Labels
+             The Multicast Labels flag, if set, indicates that this
+             output port is capable of labelling each output branch of a
+             point-to-multipoint tree with a different label. If zero,
+             it indicates that this output port is not able to label
+
+
+
+Newman, et. al.              Informational                     [Page 52]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             each output branch of a point-to-multipoint tree with a
+             different label.
+
+        L: Logical Multicast
+             The Logical Multicast flag, if set, indicates that this
+             output port is capable of supporting more than a single
+             branch from any point-to-multipoint connection.  This
+             capability is often referred to as logical multicast.  If
+             zero, it indicates that this output port can only support a
+             single output branch from each point-to-multipoint
+             connection.
+
+        R: Label Range
+             The Label Range flag, if set, indicates that this switch
+             port is capable of reallocating its VPI label range or its
+             VCI label range and therefore accepts the Label Range
+             message. Else, if zero, it indicates that this port does
+             not accept Label Range messages.
+
+        Q: QoS
+             The QoS flag, if set, indicates that this switch port is
+             capable of handling the Quality of Service messages defined
+             in section 9 of this specification.  Else, if zero, it
+             indicates that this port does not accept the Quality of
+             Service messages.
+
+        x: Unused
+
+   Min VPI
+             The default minimum value of dynamically assigned incoming
+             VPI that the connection table on the input port supports
+             and that may be controlled by GSMP. This value is not
+             changed as a result of the Label Range message.
+
+   Max VPI
+             The default maximum value of dynamically assigned incoming
+             VPI that the connection table on the input port supports
+             and that may be controlled by GSMP.  This value is not
+             changed as a result of the Label Range message.
+
+             At power-on, after a hardware reset, and after the Reset
+             Input Port function of the Port Management message, the
+             input port must handle all values of VPI within the range
+             Min VPI to Max VPI inclusive and GSMP must be able to
+             control all values within this range.  It should be noted
+             that the range Min VPI to Max VPI refers only to the
+             incoming VPI range that can be supported by the associated
+             port. No restriction is placed on the values of outgoing
+
+
+
+Newman, et. al.              Informational                     [Page 53]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             VPIs that may be written into the cell header. If the
+             switch does not support virtual paths it is acceptable for
+             both Min VPI and Max VPI to specify the same value, most
+             likely zero.
+
+             Use of the Label Range message allows the range of VPIs
+             supported by the port to be changed. However, the Min VPI
+             and Max VPI fields in the Port Configuration and All Ports
+             Configuration messages always report the same default
+             values regardless of the operation of the Label Range
+             message.
+
+   Min VCI
+             The default minimum value of dynamically assigned incoming
+             VCI that the connection table on the input port can support
+             and may be controlled by GSMP. This value is not changed as
+             a result of the Label Range message.
+
+   Max VCI
+             The default maximum value of dynamically assigned incoming
+             VCI that the connection table on the input port can support
+             and may be controlled by GSMP. This value is not changed as
+             a result of the Label Range message.
+
+             At power-on, after a hardware reset, and after the Reset
+             Input Port function of the Port Management message, the
+             input port must handle all values of VCI within the range
+             Min VCI to Max VCI inclusive, for each of the virtual paths
+             in the range Min VPI to Max VPI inclusive, and GSMP must be
+             able to control all values within this range.  It should be
+             noted that the range Min VCI to Max VCI refers only to the
+             incoming VCI range that can be supported by the associated
+             port on each of the virtual paths in the range Min VPI to
+             Max VPI. No restriction is placed on the values of outgoing
+             VCIs that may be written into the cell header.
+
+             Use of the Label Range message allows the range of VCIs to
+             be changed on each VPI supported by the port.  However, the
+             Min VCI and Max VCI fields in the Port Configuration and
+             All Ports Configuration messages always report the same
+             default values regardless of the operation of the Label
+             Range message.
+
+             For a port over which the GSMP protocol is operating, the
+             VCI of the GSMP control channel may or may not be reported
+             as lying within the range Min VCI to Max VCI.  A switch
+             should honor a connection request message that specifies
+
+
+
+
+Newman, et. al.              Informational                     [Page 54]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             the VCI value of the GSMP control channel even if it lies
+             outside the range Min VCI to Max VCI.
+
+   Receive Cell Rate
+             The maximum rate of cells that may arrive at the input port
+             in cells/s.
+
+   Transmit Cell Rate
+             The maximum rate of cells that may depart from the output
+             port in cells/s. (The transmit cell rate of the output port
+             may be changed by the Set Transmit Cell Rate function of
+             the Port Management message.)
+
+   Port Status
+             Gives the administrative state of the port. The defined
+             values of the Port Status field are:
+
+             Available:
+                  Port Status = 1. The port is available to both send
+                  and receive cells. When a port changes to the
+                  Available state 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 intentionally been taken
+                  out of service. No cells will be transmitted from this
+                  port.  No cells will be received by this port.
+
+             Internal Loopback:
+                  Port Status = 3. The port has intentionally been taken
+                  out of service and is in internal loopback: cells
+                  arriving at the output port from the switch fabric are
+                  looped through to the input port to return to the
+                  switch fabric. All of the ATM functions of the input
+                  port above the physical layer, e.g. header
+                  translation, are performed upon the looped back cells.
+
+             External Loopback:
+                  Port Status = 4. The port has intentionally been taken
+                  out of service and is in external loopback: cells
+                  arriving at the input port from the external
+                  communications link are 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 are performed
+                  upon the looped back cells.
+
+
+
+Newman, et. al.              Informational                     [Page 55]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             Bothway Loopback:
+                  Port Status = 5. The port has intentionally been taken
+                  out of service and is in both internal and external
+                  loopback.
+
+             The Port Status of the port over which the GSMP session
+             controlling the switch is running, 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.
+
+   Port Type
+             The type of physical transmission interface for this port.
+             The values for this field are defined by the atmIfType
+             object specified in the Ipsilon IP Switch MIB [IpsilonMIB].
+
+   Line Status
+             The status of the physical transmission medium connected to
+             the port. The defined values of the Line Status field are:
+
+             Up:
+                  Line Status = 1. The line is able to 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 is unable either to send or
+                  receive cells or both.
+
+             Test:
+                  Line Status = 3. The port or line is in a test mode,
+                  for example, power-on test.
+
+   Priorities
+             The number of different priority levels that this output
+             port can assign to virtual connections.  Zero is invalid in
+             this field. If an output port is able to support "Q"
+             priorities, the highest priority is numbered zero and the
+             lowest priority is numbered "Q-1". 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 may be assumed that for
+             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.
+
+
+
+Newman, et. al.              Informational                     [Page 56]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   Physical Slot Number
+             The physical location of the slot in which the port is
+             located. It is an unsigned 16-bit integer that can take any
+             value except 0xFFFF. The value 0xFFFF is used to indicate
+             "unknown." The Physical Slot Number is not used by the GSMP
+             protocol. It is provided to assist network management in
+             functions such as logging, port naming, and graphical
+             representation.
+
+   Physical Port Number
+             The physical location of the port within the slot in which
+             the port is located. It is an unsigned 16-bit integer that
+             can take any value except 0xFFFF. The value 0xFFFF is used
+             to indicate "unknown." The Physical Port Number is not used
+             by the GSMP protocol. It is provided to assist network
+             management in functions such as logging, port naming, and
+             graphical representation.
+
+             There must be a one to one mapping between Port Number and
+             the Physical Slot Number and Physical Port Number
+             combination. Two different Port Numbers must not yield the
+             same Physical Slot Number and Physical Port Number
+             combination. The same Port Number must yield the same
+             Physical Slot Number and Physical Port Number within a
+             single GSMP session.  If both Physical Slot Number and
+             Physical Port Number indicate "unknown" the physical
+             location of switch ports may be discovered by looking up
+             the product identity in a database to reveal the physical
+             interpretation of the 32-bit Port Number.
+
+7.3 All Ports Configuration Message
+
+   The All Ports Configuration message requests the switch for the
+   configuration information of all of its ports. The All Ports
+   Configuration message is:
+
+      Message Type = 66
+
+   The Port field is not used in the request message.
+
+   The All Ports Configuration success response message has the
+   following format:
+
+
+
+
+
+
+
+
+
+Newman, et. al.              Informational                     [Page 57]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+    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
+             Field gives the total number of Port Records to be returned
+             in response to the All Ports Configuration request message.
+             The number of port records in a single All Ports
+             Configuration success response must not cause the packet
+             length to exceed the maximum transmission unit defined by
+             the encapsulation. If a switch has more ports than can be
+             sent in a single success response message it must send
+             multiple success response messages. All success response
+             messages that are sent in response to the same request
+             message must have the same Transaction Identifier as the
+             request message and the same value in the Number of Records
+             field.  All success response messages that are sent in
+             response to the same request message, except for the last
+             message, must have the result field set to "More." The last
+             message, or a single success response message, must have
+             the result field set to "Success." All Port records within
+             a success response message must be complete, i.e. a single
+             Port record must not be split across multiple success
+             response messages.
+
+   Port Record Length
+             Field gives the length of each port record in bytes. This
+             is currently 32 but the Port Record Length field allows for
+             the future definition of further fields at the end of the
+             port record while preserving compatibility with earlier
+             versions of the protocol.
+
+   Port Records
+             Follow in the remainder of the message. Each port record
+             has the following format:
+
+
+
+
+
+
+Newman, et. al.              Informational                     [Page 58]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+    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 definition of the fields in the Port Record is exactly the same
+   as that of the Port Configuration message.
+
+
+8. Event Messages
+
+   Event messages allow the switch to inform the controller of certain
+   asynchronous events. Event messages are not acknowledged. The Result
+   field and the Code field in the message header are not used and
+   should be set to zero. Event messages are not sent during
+   initialization. Event 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                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Event Sequence Number                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | zero  |          VPI          |              VCI              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Newman, et. al.              Informational                     [Page 59]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   Event Sequence Number
+             The current value of the Event Sequence Number for the
+             specified port. The Event Sequence Number is set to zero
+             when the port is initialized. It is incremented by one each
+             time the port detects an asynchronous event that the switch
+             would normally report via an Event message. The Event
+             Sequence Number must be incremented each time an event
+             occurs even if the switch is prevented from sending an
+             Event message due to the action of the flow control.
+
+   VPI/VCI
+             Field gives the VPI/VCI to which the event message refers.
+             If this field is not required by the event message it is
+             set to zero.
+
+   Each switch port must maintain an Event Sequence Number and a set of
+   Event Flags, 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 corresponding to the type of the event. The port is not
+   permitted to send another Event message of the same type until the
+   Event Flag has been reset. Event Flags are reset by the "Reset Event
+   Flags" function of the Port Management message. This is a simple flow
+   control preventing the switch from flooding the controller with event
+   messages. The Event Sequence Number of the port must be incremented
+   every time an event is detected on that port even if the port is
+   prevented from reporting the event due to the action of the flow
+   control. This allows the controller to detect that it has not been
+   informed of some events that have occurred on the port due to the
+   action of the flow control.
+
+8.1 Port Up Message
+
+   The Port Up message informs the controller that the Line Status of a
+   port has changed from either the Down or Test state to the Up state.
+   When the Line Status of a switch port changes to the Up state from
+   either the Down or Test state a new Port Session Number must be
+   generated, preferably using some form of random number. The new Port
+   Session Number is given in the Port Session Number field. The VPI/VCI
+   field is not used and is set to zero.  The Port Up message is:
+
+      Message Type = 80
+
+8.2 Port Down Message
+
+   The Port Down message informs the controller that the Line Status of
+   a port has changed from the Up state to the Down state. This message
+   will be sent to report link failure if the switch is capable of
+   detecting link failure. The port session number that was valid before
+
+
+
+Newman, et. al.              Informational                     [Page 60]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   the port went down is reported in the Port Session Number field. The
+   VPI/VCI field is not 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 inform the controller that one
+   or more cells have arrived at an input port with a VPI/VCI that is
+   currently not allocated to an assigned connection. The input port is
+   indicated in the Port field, and the VPI/VCI in the VPI/VCI field.
+   The Invalid VPI/VCI message is:
+
+      Message Type = 82
+
+8.4 New Port Message
+
+   The New Port message informs the controller that a new port has been
+   added to the switch. The port number of the new port is given in the
+   Port field. A new Port Session Number must be assigned, preferably
+   using some form of random number.  The new Port Session Number is
+   given in the Port Session Number field.  The state of the new port is
+   undefined so the VPI/VCI field is not used and is set to zero.  The
+   New Port message is:
+
+      Message Type = 83
+
+8.5 Dead Port Message
+
+   The Dead Port message informs the controller that a port has been
+   removed from the switch. The port number of the port is given in the
+   Port field. The Port Session Number that was valid before the port
+   was removed is reported in the Port Session Number field.  The
+   VPI/VCI fields are not 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 allow a controller to
+   group virtual path connections and virtual channel connections into
+   QoS classes, and to allocate QoS resources to both QoS classes and to
+   individual connections. At initialization, the switch describes its
+   QoS capabilities to the controller, in terms of the abstract switch
+   model, using the QoS Configuration message. The controller issues
+
+
+
+Newman, et. al.              Informational                     [Page 61]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   Scheduler Establishment messages to configure the scheduler on each
+   switch output port. It also issues QoS Class Establishment messages
+   to configure QoS classes. Connections may be added to, or deleted
+   from, a QoS class using the QoS Connection Management message. QoS
+   resources may also be assigned to individual connections using the
+   QoS Connection Management message. Connections that only require the
+   scheduler may use the simple connection management messages defined
+   in Section 3, "Connection Management Messages."
+
+9.1 Abstract Switch Model
+
+   The abstract switch model, fig. 1, is the means by which a switch can
+   describe its fundamental QoS capabilities to a controller. It
+   consists of four main functions: a policer, a classifier, a
+   regulator, and a scheduler.  The classifier groups multiple
+   connections (VPCs or VCCs) together into a QoS class such that QoS
+   resources may be shared by the QoS class as a whole. Within a QoS
+   class there is no differentiation between members of the class in
+   terms of QoS resources received. However, the ordering of cells
+   within each constituent VPC or VCC must be preserved on exit from the
+   switch. Connections are not required to be aggregated into a QoS
+   class with other connections; they may be allocated individual QoS
+   resources.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman, et. al.              Informational                     [Page 62]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   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.  A policer may be applied to police each individual
+   connection.  A policer may also be applied to police the aggregate
+   traffic of a QoS class.  The policer is  used to enforce an upper
+   bound on the traffic on a connection or on a QoS class.
+
+
+
+
+Newman, et. al.              Informational                     [Page 63]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   The regulator follows the policer and classifier. It offers either a
+   policing function or a shaping function. The policing function
+   evaluates cells as conforming to the rate specified by the regulator
+   parameters or as being in excess of that rate. One of three actions
+   can be specified to be taken for each cell as a result of this
+   evaluation: tagging, discard or differentiated scheduling. Tagging
+   sets the CLP bit of cells deemed to be in excess of the rate defined
+   by the regulator parameters.  The discard function discards excess
+   cells. The differentiated scheduling function allows conforming cells
+   and excess cells to be scheduled for service at different points in
+   the scheduler. This would allow conforming cells, for example, to
+   receive service with a QoS guarantee, whereas excess cells receive
+   best-effort service.  The implementation of differentiated
+   scheduling, however, is complicated by the requirement not to reorder
+   cells within each connection.
+
+   The shaping function of the regulator paces cells out, on each QoS
+   class or individual connection, at the rate specified by the
+   regulator parameters. No jitter requirement may be specified, nor is
+   any specific guarantee of jitter given. If traffic arrives on any QoS
+   class or individual connection at a greater rate than the output rate
+   specified, that traffic will be delayed. If the delayed traffic for
+   any QoS class or individual connection exceeds a bound, discard will
+   occur.  Differentiated scheduling is supported by the shaper but its
+   application to shaping is somewhat different than its application to
+   policing. Conforming traffic is that traffic which leaves the shaper
+   as a result of the shaping process.  The conforming pointer specifies
+   the point in the scheduler structure where such traffic is scheduled
+   for output. (This is typically the highest priority of the scheduler
+   but the GSMP specification permits other priorities to be specified.)
+   If an excess pointer is also enabled for a particular QoS class or
+   individual connection, traffic in excess of the rate specified by the
+   shaper may also be transmitted.  The position of the excess pointer
+   in the scheduler structure determines the undefined amount of
+   additional traffic that will be supported. The excess traffic may be
+   tagged if required, if tagging is supported. The excess pointer will
+   receive the same share of bandwidth that a best-effort class or
+   connection would receive at the same location in the scheduler
+   structure.
+
+   The location of the classifier and regulator functions in the switch
+   is important. If the classifier is located on an input port, only
+   virtual connections that arrive at that input port may be aggregated
+   into a QoS class. If the classifier is centralized, or located on an
+   output port, virtual connections that arrive at any input port may be
+   aggregated into the same QoS class. If the regulator is located on an
+   output port all virtual connections within a QoS class passing
+   through that regulator must exit the switch at that output port.
+
+
+
+Newman, et. al.              Informational                     [Page 64]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   However, if the regulator is centralized, or located on an input
+   port, virtual connections that are part of the same QoS class may be
+   switched to different output ports.  Each switch port must specify
+   the location of its classifier and regulator functions.
+
+   The scheduler is located on the output port, fig. 2. It distributes
+   the bandwidth of the output link between the QoS classes and
+   individual connections.  It is a two-level scheduler: a priority
+   scheduler at one level and a FIFO or a weighted scheduler at the
+   other.  Up to 255 strict priority levels may be supported. Traffic in
+   any specific priority level may only be transmitted if no traffic is
+   queued for transmission in any higher priority level. Within each
+   priority level a weighted scheduler may be defined. Each leaf of the
+   scheduler tree is connected to a waiting room. The waiting room has
+   two functions. When it receives service from the scheduler, it must
+   select a QoS class or individual connection for transmission. When it
+   is notified of traffic arrival on a QoS class or connection, it must
+   decide whether there is enough room left in the waiting room to
+   accept the traffic, else that traffic must be discarded. The waiting
+   room has a size parameter indicating how much traffic may be
+   accepted.  Other queueing parameters may be attached to the waiting
+   room. Multiple conforming and excess pointers from the regulators may
+   point to each waiting room. Within a waiting room, the scheduling of
+   multiple connections sharing that waiting room may support weighted
+   sharing between the connections.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman, et. al.              Informational                     [Page 65]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+        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 permits the controller to discover the
+   QoS capabilities of each switch port in terms of the abstract switch
+   model. The QoS Configuration message is:
+
+      Message Type = 96
+
+
+   The QoS Configuration request message has the following format:
+
+
+
+
+
+
+
+
+
+
+
+Newman, et. al.              Informational                     [Page 66]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+    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                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Port
+             The switch port to which the QoS configuration information
+             refers. QoS configuration information relating to both the
+             input and the output sides of the switch port is given.
+
+
+
+
+
+
+Newman, et. al.              Informational                     [Page 67]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   Scheduler Flags
+
+         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 of the Scheduler Flags field, if set, indicates that
+             a weighted service algorithm (such as weighted round-robin)
+             is available for allocation of service to individual
+             connections within at least some waiting rooms. It means
+             that a Connection Weight parameter can be attached to a QoS
+             Connection Management message. Not all waiting rooms at all
+             priority levels may be able to support this function.
+             Whether a particular waiting room can support this function
+             will be discovered when a QoS Connection Management message
+             is issued.
+
+        Q: Weighted QoS Classes
+             Bit 1 of the Scheduler Flags field, if set, indicates that
+             a weighted service algorithm (such as weighted round-robin)
+             is available for allocation of service to QoS classes
+             within at least some waiting rooms.  It means that a QoS
+             Class Weight parameter can be attached to a QoS Class
+             Establishment message.  Not all waiting rooms at all
+             priority levels may be able to support this function.
+             Whether a particular waiting room can support this function
+             will be discovered when a QoS Class Establishment message
+             is issued.
+
+        S: Shared Waiting Room
+             Bit 2 of the Scheduler Flags field, if set, indicates that
+             multiple QoS classes and multiple connections may be
+             scheduled within a single waiting room. This is expected to
+             be the normal case. If Bit 2 of the Scheduler Flags field
+             is zero, it indicates that only a single QoS class or a
+             single connection may be directed to any single waiting
+             room.
+
+        G: Global Max Classes
+             Bit 3 of the Scheduler Flags field, if set, indicates that
+             the Max Classes field gives the maximum number of QoS
+             classes that may be supported by the entire switch. If
+             zero, it indicates that the Max Classes field gives the
+             maximum number of QoS classes that may be supported by this
+             switch port.
+
+
+
+Newman, et. al.              Informational                     [Page 68]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+        D: Packet Discard
+             Bit 4 of the Scheduler Flags field, if set, indicates that
+             the scheduler on this output port is capable of packet
+             discard. Packet discard indicates a discard algorithm that
+             is aware of AAL-5 packet boundaries and attempts to discard
+             whole packets. No specific algorithm is indicated though
+             Early Packet Discard (EPD) is likely to be the most common.
+             Other algorithms such as "push from front" schemes, dynamic
+             threshold, or Random Early Detection (RED) are also
+             examples of possible packet discard algorithms. The only
+             parameters available to the packet discard algorithm, via
+             GSMP, are the Size and Discard Threshold of the waiting
+             room.
+
+        F: Frame-Based Scheduling
+             Bit 5 of the Scheduler Flags field, if set, indicates that
+             the scheduler on this output port is capable of frame-based
+             scheduling. In frame-based scheduling, a connection is only
+             scheduled for transmission when a complete AAL-5 packet is
+             available.  When a connection is scheduled for
+             transmission, all cells belonging to one or more complete
+             packets from that connection will be transmitted without
+             being interleaved with any other cells on that output port
+             (regardless of their priority).  Frame-based scheduling is
+             a property of the waiting room and is requested in the
+             Scheduler Establishment message.  A QoS class may be routed
+             through a waiting room configured with frame-based
+             scheduling.  In this case each component connection of the
+             QoS class will receive frame based scheduling. For correct
+             distribution of bandwidth, each QoS class that requires
+             frame-based scheduling should have its own waiting room.
+
+        M: VC Merging
+             Bit 6 of the Scheduler Flags field, if set, indicates that
+             the scheduler on this output port is capable of VC merging
+             by a mechanism other than frame-based scheduling. VC
+             merging indicates that the switch is capable of the
+             multipoint-to-point merging of two or more incoming virtual
+             connections 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 in that cells with a different VPI/VCI may
+             be interleaved with those of a multipoint-to-point VC
+             merging connection. Thus, higher priority cells may be
+             interleaved during the transmission of a packet on a lower
+             priority VC merging connection.  Most switches achieve VC
+             merging by using frame-based scheduling.  VC merging is a
+             property of the waiting room and is requested in the
+
+
+
+Newman, et. al.              Informational                     [Page 69]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             Scheduler Establishment message.  A QoS class may be routed
+             through a waiting room configured with VC merging.  In this
+             case each component connection of the QoS class will
+             receive VC merging.
+
+        B: Shared Buffer
+             Bit 7 of the Scheduler Flags field, if set, indicates that
+             at least some of the buffer space specified by the Max
+             Buffer field is shared with other ports.  If zero, it
+             indicates that the buffer space specified by the Max Buffer
+             field is not shared with other ports.
+
+        I: Identical Ports
+             Bit 8 of the Scheduler Flags field, if set, indicates that
+             all ports of the switch have identical QoS capabilities. If
+             this bit is set the controller does not have to request the
+             QoS configuration of each port individually as all ports
+             have the same capability.
+
+        x: Bits 9--15 of the Scheduler Flags field are not used.
+
+   Regulator Flags
+
+         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 of the Regulator Flags field indicates that this
+             input port supports the policing of individual incoming
+             connections. The parameters for the policer are specified
+             in the QoS Connection Management message when the
+             connection is established.
+
+        Q: QoS Class Policing
+             If bit 1 of the Regulator Flags field is set, a policer
+             function is available to police each QoS class on output
+             from the classifier. The parameters for this policer are
+             specified in the QoS Class Establishment message. If this
+             bit is zero, no policer function is available to police a
+             QoS class.
+
+        IO: QoS Class Location
+             Bits 2 and 3 of the Regulator Flags field specify the
+             location of the classifier and regulator functions. If both
+
+
+
+
+Newman, et. al.              Informational                     [Page 70]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             bits 2 and 3 of the Regulator Flags field are zero, no
+             classifier or regulator function is available to this port.
+
+             If bit 2 of the Regulator Flags field is set and bit 3 is
+             zero, the classifier and regulator functions are available
+             on the input port. This implies that only virtual
+             connections arriving at this input port may be grouped into
+             QoS classes by this classifier. However, connections in a
+             QoS class output from this regulator may be switched to any
+             output port.
+
+             If bit 2 of the Regulator Flags field is zero and bit 3 is
+             set, the classifier and regulator functions are available
+             on the output port. This implies that virtual connections
+             arriving at any input port may be grouped into QoS classes
+             by this classifier. However, all connections in any QoS
+             class output from this regulator may only be switched to
+             this output port.
+
+             If both bits 2 and 3 of the Regulator Flags field are set,
+             this switch port has access to centralized classifier and
+             regulator functions. This implies that virtual connections
+             arriving at any input port may be grouped into a QoS class
+             by this classifier. Also, connections in a QoS class output
+             from this regulator may be switched to any output port.
+
+        Regulator Function
+
+        P: If bit 4 of the Regulator Flags field is set, the regulator
+             is able to support the policing function.
+
+        S: If bit 5 of the Regulator Flags field is set, the regulator
+             is able to support the shaping function on all priority
+             levels of the scheduler.
+
+        H: If bit 5 of the Regulator Flags field is zero and bit 6 is
+             set, the regulator is able to 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.
+
+        M: QoS Multicast
+             If bit 7 of the Regulator Flags field is set, any point-
+             to-multipoint connection arriving on this input port, with
+             QoS parameters established by the GSMP Quality of Service
+             messages, must use the same QoS parameters for all output
+             branches.
+
+
+
+Newman, et. al.              Informational                     [Page 71]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+        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|
+        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+        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
+   Lo Sharing
+             Defines a range of priority levels that support weighted
+             sharing. Each priority level in the range Lo Sharing to Hi
+             Sharing inclusive, supports weighted sharing. A priority
+             level that supports weighted sharing offers a weighted
+             sharing algorithm (for example, weighted round-robin)
+             between waiting rooms within that priority level. This
+             permits the output link bandwidth available at that
+             priority level, to be shared between the waiting rooms
+             allocated to that priority level, according to the Net
+             Weight parameter of each waiting room.  The value 0xFF for
+             both parameters indicates that this output port does not
+             support weighted sharing in any priority level.
+
+
+
+
+Newman, et. al.              Informational                     [Page 72]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   Max Classes
+             If bit 3 of the Scheduler Flags field is zero, Max Classes
+             gives the maximum number of QoS classes that may be
+             supported by this switch port. In this case the maximum
+             number of QoS classes that may be supported by this switch
+             port is not affected by the number of QoS classes in use by
+             other switch ports.  If bit 3 of the Scheduler Flags field
+             is set, Max Classes gives the maximum number of QoS classes
+             that may be supported by the entire switch. In this case it
+             is assumed that use of these QoS classes may be distributed
+             among the various switch ports.
+
+   Default Size
+             The size of waiting room that this output port allocates by
+             default. The actual size of waiting room may be specified
+             in the Scheduler Establishment message. The size of a
+             waiting room specifies the maximum number of cells
+             permitted to wait for transmission via that waiting room.
+             Any further cells arriving at that waiting room beyond this
+             number will be discarded.
+
+   Default Discard Threshold
+             The value of discard threshold that this output port
+             allocates by default. The actual value of discard threshold
+             may be specified in the Scheduler Establishment message.
+             The discard threshold specifies the number of cells waiting
+             for transmission via a waiting room after which further
+             arriving cells will be subject to a discard mechanism.
+
+   Max Buffer
+             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 is not 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
+             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. This shaper buffer space
+             is likely to be shared among all QoS classes and QoS
+             connections using the shaper, so there is no guarantee that
+             the amount of buffer space defined by the Max Shaper Buffer
+             field will be available to any particular QoS class or QoS
+             connection.
+
+
+
+
+
+
+Newman, et. al.              Informational                     [Page 73]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   Scaling Factor
+             The QoS Class Establishment and QoS Connection Management
+             messages require parameters that describe cell rates in
+             cells per second or their reciprocal, cell interarrival
+             periods, in seconds per cell. In order that these
+             parameters may be specified with a 32-bit unsigned integer,
+             the switch defines a Scaling Factor to be used in defining
+             such parameters. By appropriate choice of the Scaling
+             Factor the switch can select the range and granularity of
+             rate or time that can be specified with the 32-bit unsigned
+             integer.  Further details are given in the discussion of
+             the UPC Parameters field of the QoS Connection Management
+             message.
+
+9.3 Scheduler Establishment Message
+
+   The Scheduler Establishment message is used to configure the
+   scheduler on a specified output port. It is used to configure a
+   waiting room, attach it to a leaf of the scheduler tree, and return a
+   Scheduler Identifier to reference the waiting room. The Scheduler
+   Establishment message may also be used to modify the parameters of an
+   already established waiting room.
+
+   Scheduler Identifiers in the range 0--255 represent default values.
+   They are used for the priority levels that may be specified in the
+   Class of Service field of Connection Management messages without
+   requiring explicit establishment via a Scheduler Establishment
+   message.  Each of these default values specifies a single waiting
+   room with default parameters, configured as a FIFO queue, on each of
+   the valid scheduler priority levels. (This permits Connection
+   Management messages to continue to specify QoS requirements as a
+   priority without requiring the use of any of the QoS messages.) The
+   number of priority levels available to the scheduler is specified 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:
+
+
+
+
+
+
+
+
+
+Newman, et. al.              Informational                     [Page 74]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+    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 Scheduler Identifier is selected by the controller. It
+             is used to identify the waiting room being established or
+             modified in future messages. The Scheduler Identifier is
+             taken from a namespace that is 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.
+             The default values of the Scheduler Identifier are used to
+             specify the default settings for the scheduler. Each of the
+             default values maps directly to one of the scheduler
+             priority levels.  The value 0xFFFF is reserved for use in
+             the QoS Connection Management message.
+
+   Net Weight
+             The Net Weight specifies the share of the bandwidth
+             available to the priority level, specified by the Priority
+             field, that should be given to this waiting room.  The Net
+             Weight parameter is only valid if the priority level
+             specified by the Priority field supports weighted sharing.
+
+             The Net Weight is an unsigned 16-bit field specifying a
+             binary fraction.  I.e. the bandwidth share, as a fraction
+             of the bandwidth available to the priority level, is given
+             by:
+
+                Bandwidth share = Net Weight * 2**(-16)
+
+
+
+
+Newman, et. al.              Informational                     [Page 75]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             A Net Weight of zero indicates equal sharing between all
+             waiting rooms sharing this priority level that request a
+             Net Weight of zero.  While a 16-bit field is used to
+             specify the Net Weight it is understood that the accuracy
+             of the bandwidth sharing is hardware dependent and is not
+             specified.
+
+             If weighted sharing is not 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 does not 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 is scheduled for transmission, all cells
+             belonging to one or more complete packets from that
+             connection will be transmitted without being interleaved
+             with any other cells on that output port. A QoS class may
+             be routed through a waiting room configured with frame-
+             based scheduling.  In this case each component connection
+             of the QoS class will receive frame based scheduling. For
+             correct distribution of bandwidth, 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 enables the
+             multipoint-to-point merging of two or more incoming virtual
+             connections 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 in that cells with a different VPI/VCI may
+             be interleaved with those of a multipoint-to-point VC
+             merging connection.  Most switches achieve VC merging by
+
+
+
+Newman, et. al.              Informational                     [Page 76]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             using frame-based scheduling.  A QoS class may be routed
+             through a waiting room configured with VC merging.  In this
+             case each component connection of the QoS class will
+             receive 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.  All connections and QoS
+             classes 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. 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 will receive
+             first-in-first-out service. If Frame-Based Scheduling or VC
+             Merging are also selected, the strict first-in-first-out
+             service discipline will be 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, with priority level zero being the highest
+             priority.
+
+   Waiting Room Size
+             The required size of the waiting room.  The size of a
+             waiting room specifies the maximum number of cells
+             permitted 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 is unable to grant
+             the size requested in the Scheduler Establishment request
+             message it may reply with the actual size allocated to the
+             waiting room in the Waiting Room Size field of the success
+             response message.  A value of zero for the Waiting Room
+             Size indicates that the default value should be used.
+
+
+
+
+
+
+Newman, et. al.              Informational                     [Page 77]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   Discard Threshold
+             The required value of the discard threshold.  The discard
+             threshold specifies the number of cells waiting for
+             transmission via a waiting room after which further
+             arriving cells will be 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 is unable to grant the
+             value of discard threshold requested in the Scheduler
+             Establishment request message it may reply with the actual
+             value of discard threshold allocated to the waiting room in
+             the Discard Threshold field of the success response
+             message.  A value of zero for the Discard Threshold
+             indicates that the default value should be used.
+
+
+9.4 QoS Class Establishment Message
+
+   The QoS Class Establishment message is used to configure a QoS class
+   on a specified port or to modify the parameters of an already
+   established QoS class.  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.
+
+   Two styles of QoS class are available. In one style each component
+   connection of the QoS class may be routed independently to an output
+   port and waiting room specified in its connection management message.
+   In this case the Scheduler Identifier, and if required, the Excess
+   Scheduler Id, are specified in the QoS Connection Management message
+   that references this style of QoS class.  In the alternative style of
+   QoS class, all component connections in the QoS class are routed to
+   the same waiting room on the same output port. In this case the
+   Output Port, the Scheduler Identifier, and if required, the Excess
+   Scheduler Id, are specified in the QoS Class Establishment message.
+
+   The classifier and regulator functions must be located together,
+   either on an input port, on an output port, or centralized. Each port
+   declares the location of its classifier and regulator functions at
+   initialization using the QoS Configuration message. If the classifier
+   and regulator functions are located on an input port, only
+   connections that arrive at that input port may join a QoS class
+   established on that port. However, each connection that is part of a
+   QoS class established on that port may be switched to a different
+   output port. If the classifier and regulator functions are located on
+   an output port, connections that arrive at any input port may join a
+   QoS class established on that port. However, all connections within a
+   QoS class established on that port must be switched to that output
+   port. For a centralized classifier and regulator function, there is
+
+
+
+Newman, et. al.              Informational                     [Page 78]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   no restriction on the input ports on which connections in a QoS class
+   must arrive, or on the output ports to which connections in a QoS
+   class must be switched.  (For the case of a centralized classifier
+   and regulator the actual port specified in the QoS Class
+   Establishment message is used only for administrative purposes.  Any
+   valid value of Port and Port Session Number, that specifies a
+   centralized classifier and regulator function, may be used.)
+
+   The QoS Class Establishment message is:
+
+      Message Type = 98
+
+   The QoS Class 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                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      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 QoS Class Identifier is selected by the controller. It
+             is used to identify the QoS class being established or
+             modified, in future QoS Connection Management and QoS Class
+             Establishment messages.  It is taken from a namespace that
+
+
+
+Newman, et. al.              Informational                     [Page 79]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             is global across the entire switch. No two QoS classes may
+             have the same QoS Class Identifier regardless of the switch
+             ports on which they are defined. A QoS Class Identifier in
+             a QoS Class Establishment message must be greater than 0
+             and less than 0xFFFFFFFF.
+
+   Regulator
+             The Regulator field specifies which function is required of
+             the regulator.  Three possible functions are currently
+             defined: none, policing, and shaping.
+
+                None:      Regulator = 1
+                Policing:  Regulator = 2
+                Shaping:   Regulator = 3
+
+             If the Regulator function is specified as none, no
+             operations are performed by the regulator on the cells
+             output from the classifier. Cells output from the
+             classifier are transferred directly to the waiting room
+             specified by the Scheduler Identifier.
+
+             If policing is specified, a token bucket policer will be
+             applied to the QoS class. The policer determines which
+             cells conform to the specified policer traffic parameters
+             and which do not. Conforming cells are transferred directly
+             to the waiting room specified by the Scheduler Identifier.
+             The action to be taken by the policer on the excess traffic
+             is specified by the Excess Action field. The policer
+             traffic parameters are specified in the QoS Class Regulator
+             Parameters fields.
+
+             If shaping is specified, traffic shaping will be applied to
+             the QoS class.  Cells in a QoS class should leave the
+             regulator spaced evenly apart at a rate defined by the QoS
+             Class Regulator Parameters fields.  These cells are
+             transferred directly to the waiting room specified by the
+             Scheduler Identifier.  The jitter on the conforming cell
+             stream on exit from the shaping function of the regulator
+             is not specified.
+
+   Excess Action
+
+         0 1 2 3 4 5 6 7
+        +-+-+-+-+-+-+-+-+
+        |T|D|S|x x x x x|
+        +-+-+-+-+-+-+-+-+
+
+
+
+
+
+Newman, et. al.              Informational                     [Page 80]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+        T: Tagging
+             If bit 0 of the Excess Action field is set, all cells
+             transferred to the waiting room specified by the Excess
+             Scheduler Id will have their CLP bit set. If bit 0 of the
+             Excess Action field is zero, the CLP bit of cells
+             transferred to the waiting room specified by the Excess
+             Scheduler Id will remain unchanged.
+
+        D: Discard
+             This function is only available if policing is selected as
+             the regulator function.  If the Regulator field specifies
+             Policing, and bit 1 of the Excess Action field is set, all
+             cells determined by the policer to be in excess of the
+             traffic parameters must be discarded. In this case the
+             Excess Scheduler Id is not used and bit 0 of the Excess
+             Action field should be ignored.
+
+        S: Differentiated Scheduling
+             This function operates differently according to whether
+             policing or shaping is selected as the regulator function.
+
+             If the Regulator field specifies Policing, and bit 1 of the
+             Excess Action field is zero, and bit 2 of the Excess Action
+             field is set, all cells determined by the policer to be in
+             excess of the traffic parameters must be transferred to the
+             waiting room specified by the Excess Scheduler Id.  In this
+             case care must be taken in the implementation to ensure
+             that within each virtual path connection or virtual channel
+             connection, cells depart in the same order that they
+             arrived.  If the Regulator field specifies Policing, and
+             bit 1 of the Excess Action field is zero, and bit 2 of the
+             Excess Action field is zero, all cells determined by the
+             policer to be in excess of the traffic parameters must be
+             transferred to the waiting room specified by the Scheduler
+             Identifier.  In this case the Excess Scheduler Id is not
+             used.
+
+             If the Regulator field specifies Shaping, and bit 2 of the
+             Excess Action field is zero, cells will be transferred from
+             the QoS class to the waiting room pointed to by the
+             Scheduler Identifier at a rate defined by the QoS Class
+             Regulator Parameters. In this case the Excess Scheduler Id
+             is not used.  If the Regulator field specifies Shaping, and
+             bit 2 of the Excess Action field is set, additional cells
+             will be scheduled for transmission by the waiting room
+             pointed to by the Excess Scheduler Id. This permits a
+             minimum cell rate to be allocated to the QoS class using
+             the QoS Class Regulator Parameters and additional bandwidth
+
+
+
+Newman, et. al.              Informational                     [Page 81]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             to be shared by the QoS class. The additional share of
+             bandwidth is determined according to the parameters of the
+             waiting room pointed to by the Excess Scheduler Id. If the
+             Excess Scheduler Id is specified in the QoS Class
+             Establishment message, the additional bandwidth will be
+             shared by the entire QoS class. If the Excess Scheduler Id
+             is specified in each individual QoS Connection Management
+             message, the additional bandwidth is specific to that
+             connection and not shared by the entire QoS class. Care
+             must be taken in the implementation to ensure that within
+             each virtual path connection or virtual channel connection,
+             cells depart in the same order that 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 of the QoS
+             Configuration message indicates that weighted service may
+             be applied to a QoS class, the QoS Class Weight parameter
+             specifies the share of the bandwidth available to the
+             waiting room that should be given to this QoS class.
+
+             The QoS Class Weight is an unsigned 16-bit field specifying
+             a binary fraction.  I.e. the bandwidth share, as a fraction
+             of the bandwidth available to the waiting room, is given
+             by:
+
+                Bandwidth share = QoS Class Weight * 2**(-16)
+
+             A QoS Class Weight of zero indicates equal sharing between
+             all QoS classes sharing this waiting room that request a
+             QoS Class Weight of zero.  While a 16-bit field is used to
+             specify the QoS Class Weight it is understood that the
+             accuracy of the bandwidth sharing is hardware dependent and
+             is not specified.
+
+             If the Regulator field of the QoS Class Establishment
+             message indicates None, or Policer, the QoS Class Weight
+             should be applied to the waiting room pointed to by the
+             Scheduler Identifier. If the Regulator field of the QoS
+             Class Establishment message indicates Shaper, the QoS Class
+             Weight should be applied to the waiting room pointed to by
+             the Excess Scheduler Id.
+
+             If the specified waiting room is unable to offer weighted
+             sharing for a QoS class, a failure response message should
+             be returned with the failure code indicating: "This waiting
+             room is unable to offer weighted sharing for a QoS class."
+
+
+
+Newman, et. al.              Informational                     [Page 82]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   Scheduler Identifier
+             If all conforming traffic from this QoS class is directed
+             to the same waiting room, on the same output port, this
+             field specifies the Scheduler Identifier for the entire QoS
+             class. The Scheduler Identifier points to the waiting room,
+             on the output port specified by the Output Port field, to
+             which all conforming traffic should be sent.  If this field
+             is not used it should be set to 0xFFFF. If each component
+             connection of the QoS class specifies its own output port
+             and waiting room, the Scheduler Identifier must be
+             specified in the QoS Connection Management message and this
+             field must be set to 0xFFFF.
+
+   Excess Scheduler Id
+             If all conforming traffic from this QoS class is directed
+             to the same waiting room, on the same output port, this
+             field specifies the Excess Scheduler Id for the entire QoS
+             class. The Excess Scheduler Id points to the waiting room,
+             on the output port specified by the Output Port field, to
+             which all excess traffic should be sent.  If this field is
+             not used it should be set to 0xFFFF. If each component
+             connection of the QoS class specifies 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 set to 0xFFFF. 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.
+
+   Output Port
+             If the Scheduler Identifier field in the QoS Establishment
+             message is not 0xFFFF the Output Port field specifies the
+             Output Port to which traffic from this QoS class should be
+             routed. If the Scheduler Identifier field in the QoS
+             Establishment message is 0xFFFF, this field is not used.
+
+   QoS Class Policer Parameters
+             A policer function may be applied to a QoS class on output
+             from the classifier independently of the regulator
+             function.  The QoS class policer function is identical to
+             the connection policer function defined in the QoS
+
+
+
+
+
+Newman, et. al.              Informational                     [Page 83]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             Connection Management message with the exception that it
+             applies to all cells that belong to the QoS class rather
+             than just cells that belong to a single connection.
+
+             The QoS Class Policer Parameters 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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     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 given in the UPC
+             Parameters section of the QoS Connection Management
+             message.
+
+   QoS Class Regulator Parameters
+             The QoS class regulator function is identical to the
+             regulator function defined in the QoS Connection Management
+             message with the exception that it applies to all cells
+             that belong to the QoS class rather than just cells that
+             belong to a single connection.
+
+             The QoS Class Regulator Parameters 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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                QoS Class Regulator Increment                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                  QoS Class Regulator Limit                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+             The definition of these fields is given in the Regulator
+             Parameters section of the QoS Connection Management
+             message.
+
+
+
+
+
+
+Newman, et. al.              Informational                     [Page 84]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+9.5 QoS Release Message
+
+   The QoS Release message is used to delete a Scheduler Identifier or a
+   QoS Class Identifier and to release all resources associated with it.
+
+   The QoS Release message is:
+
+      Message Type = 99
+
+   The QoS Release 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                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Reserved            |     Scheduler Identifier      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      QoS Class Identifier                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Port
+             If the QoS Release message contains a Scheduler Identifier,
+             the Port field must contain the Port Number of the switch
+             output port to which the Scheduler Identifier applies. If
+             the QoS Release message contains a QoS Class Identifier,
+             any valid Port number may be used. (The QoS Class
+             Identifier has a global namespace.)
+
+   Port Session Number
+             The current Port Session Number for the port specified in
+             the Port field.
+
+   Scheduler Identifier
+             If the Scheduler Identifier contains the value 0xFFFF the
+             QoS Class Identifier specified in the QoS Class Identifier
+             field should be released.  Else, if the value of the
+             Scheduler Identifier lies in the range 0x0100 -- 0xFFFE
+             inclusive, the Scheduler Identifier specified by the
+             Scheduler Identifier field should be released.  A Scheduler
+
+
+
+
+Newman, et. al.              Informational                     [Page 85]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             Identifier with a value less than 0x0100 is invalid in a
+             QoS Release message.  (It specifies a default value which
+             may not be released.)
+
+   QoS Class Identifier
+             If the Scheduler Identifier contains the value 0xFFFF the
+             QoS Class Identifier field specifies the QoS Class
+             Identifier to be released.
+
+   If the QoS Release message requests that a Scheduler Identifier be
+   released, and the Scheduler Identifier is still in use by one or more
+   established connections, a failure response must be returned with the
+   failure code indicating: "Scheduler Identifier still in use." If the
+   QoS Release message requests that a QoS Class Identifier be released,
+   and the QoS Class Identifier is still in use by one or more
+   established connections, a failure response must be returned with the
+   failure code indicating: "QoS Class Identifier still in use."
+
+9.6 QoS Connection Management Message
+
+   The QoS Connection Management message is used by the controller to
+   establish and modify virtual channel connections and virtual path
+   connections across the switch which require QoS parameters to be
+   specified. The functionality of the QoS Connection Management message
+   is identical to that of the Add Branch connection management message
+   with the additional specification of QoS parameters.  No specific QoS
+   connection release messages are defined. QoS connections may be
+   released with the Delete Tree, Delete All, and Delete Branches
+   messages defined in Section 4, "Connection Management Messages." When
+   a QoS connection is released, all associated QoS resources are
+   released.
+
+   There are three styles of connection with specified QoS parameters:
+
+   QoS Connection:
+      This connection style specifies its own individual QoS parameters
+      and is routed independently to the waiting room and output port
+      specified 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 may be
+      different from all other output branches of that point-to-
+      multipoint QoS connection, if the switch supports this capability.
+      However, all output branches must specify identical connection
+      policer parameters. A QoS Connection Management message requesting
+      this style of connection is identified by a QoS Class Identifier
+      with the value 0xFFFFFFFF.
+
+
+
+
+
+Newman, et. al.              Informational                     [Page 86]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   QoS Class Connection:
+      This connection style does not specify its own individual QoS
+      parameters. It is a member of a QoS class, and the QoS parameters
+      are specified by the QoS class.  It is, however, routed
+      independently to the waiting room and output port specified 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 requesting this
+      style of connection will have a valid QoS Class Identifier and a
+      valid Scheduler Identifier.
+
+   QoS Class Member:
+      This connection style does not specify its own individual QoS
+      parameters. It is a member of a QoS class, and the QoS parameters
+      are specified by the QoS class.  The QoS class also specifies the
+      waiting room and output port to which all members of the class are
+      routed. This style of connection does not support point-to-
+      multipoint connections. A QoS Connection Management message
+      requesting this style of connection 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, the Virtual Channel Connection (VCC) QoS Connection
+   Management message is:
+
+      Message Type = 100.
+
+   To request a virtual path connection with specified QoS parameters,
+   the Virtual Path Connection (VPC) QoS Connection Management message
+   is:
+
+      Message Type = 101.
+
+   The QoS Connection Management message has the following format for
+   both request and response messages:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman, et. al.              Informational                     [Page 87]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+    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                     ~
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Port Session Number
+   Input Port
+   Input VPI
+   Input VCI
+   Output Port
+   Output VPI
+   Output VCI
+   Number of Branches
+             The definition of these fields is exactly the same as
+             defined for the Add Branch message in Section 4.1,
+             "Connection Management Messages."
+
+
+
+
+
+
+Newman, et. al.              Informational                     [Page 88]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   M B C Flags
+             The definition of the M, B, and C flags is exactly the same
+             as defined in Section 4, "Connection Management Messages."
+             They apply to the QoS Connection Management message exactly
+             as defined for the Add Branch message.
+
+   Q: QoS Profile Flag The QoS Profile flag is not used in the QoS
+             Connection Management message.
+
+   Scheduler Identifier
+             For QoS Connection and QoS Class Connection styles, the
+             Scheduler Identifier points to the waiting room, on the
+             output port specified by the Output Port field, to which
+             all conforming traffic on the connection should be routed.
+             The values 0 -- 255 specify the default settings for the
+             scheduler. Each of the default values maps directly to one
+             of the scheduler priority levels. A Scheduler Identifier in
+             the range 0 -- 255 may be used without first being
+             established by a Scheduler Establishment message. All
+             Scheduler Identifiers in the range 0x0100 to 0xFFFE must
+             first be established by a Scheduler Establishment message.
+
+             A Scheduler Identifier with a value of 0xFFFF indicates
+             that a QoS Class Member connection style is being
+             requested. In this connection style, the waiting room and
+             output port are specified by reference to the QoS class
+             specified by the QoS Class Identifier field. In this case
+             the QoS Class Identifier field must contain a valid QoS
+             Class Identifier.
+
+   QoS Class Identifier
+             For QoS Class Connection and QoS Class Member connection
+             styles, the QoS Class Identifier specifies the QoS Class to
+             which the connection belongs. It must first be established
+             by a QoS Class Establishment message and must have a value
+             greater than 0 and less than 0xFFFFFFFF.
+
+             A QoS Class Identifier with a value of 0xFFFFFFFF indicates
+             that a connection of style "QoS Connection" is being
+             requested. In this connection style, the connection does
+             not belong to a QoS class. All QoS parameters are specified
+             by the QoS Connection Management message and apply only to
+             the specified connection.
+
+   Regulator
+   Excess Action
+             The Regulator and Excess Action parameters are only used in
+             connection requests of style "QoS Connection." The
+
+
+
+Newman, et. al.              Informational                     [Page 89]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             definition of these fields in the QoS Connection Management
+             message is exactly the same as defined for the QoS Class
+             Establishment message with the exception that they apply to
+             an individual connection rather than to an entire QoS
+             class.
+
+   Connection Weight
+             This field 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
+             assign a weight to the QoS Class.
+
+             If bit 0 of the Scheduler Flags field of the QoS
+             Configuration message indicates that weighted service may
+             be applied to a connection, the Connection Weight parameter
+             specifies the share of the bandwidth available to the
+             waiting room that should be given to this connection.
+
+             The Connection Weight is an unsigned 16-bit field
+             specifying a binary fraction.  I.e. the bandwidth share, as
+             a fraction of the bandwidth available to the waiting room,
+             is given by:
+
+                Bandwidth share = Connection Weight * 2**(-16)
+
+             A Connection Weight of zero indicates equal sharing between
+             all connections in this waiting room that request a
+             Connection Weight of zero.  While a 16-bit field is used to
+             specify the Connection Weight it is understood that the
+             accuracy of the bandwidth sharing is hardware dependent and
+             is not specified.
+
+             For connections of style "QoS Class Connection," if the
+             Regulator function of the QoS Class is specified as 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 specified as Shaper, the
+             Connection Weight should be applied to the waiting room
+             pointed to by the Excess Scheduler Id field in the QoS
+             Connection Management message.
+
+             For connections of style "QoS Connection," if the Regulator
+             field of the QoS Connection Management message specifies
+             None, or Policer, the Connection Weight should be applied
+             to the waiting room pointed to by the Scheduler Identifier
+             field. If the Regulator field of the QoS Connection
+
+
+
+Newman, et. al.              Informational                     [Page 90]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             Management message specifies Shaper, the Connection Weight
+             should be applied to the waiting room pointed to by the
+             Excess Scheduler Id field.
+
+             If the specified waiting room is unable to offer weighted
+             sharing for a connection, a failure response message should
+             be returned with the failure code indicating: "this waiting
+             room is unable to offer weighted sharing for a connection."
+
+   QoS Flags
+
+        S: Selective Discard
+             If the Selective Discard flag is set, only cells with the
+             Cell Loss Priority (CLP) bit set will be subject to the
+             discard mechanism when the number of cells in the waiting
+             room exceeds the Discard Threshold.  If the Selective
+             Discard flag is zero, all cells (CLP=0 and CLP=1) will be
+             subject to the discard mechanism when the number of cells
+             in the waiting room exceeds the Discard Threshold.
+             Selective discard can be combined with packet discard. In
+             this case only packets in which 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 the point-to-multipoint connection
+             must be set to the QoS parameters specified in the message.
+             If the All Branches flag is zero, only the single output
+             branch specified in the message should be set to the QoS
+             parameters specified in the message. For a QoS Connection
+             Management message that specifies a point-to-point
+             connection, the All Branches flag is not used.
+
+        x: Unused
+
+   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 specified by the Output Port
+             field, to which all excess traffic should be routed. The
+             values 0 -- 255 specify the default settings for the
+             scheduler. Each of the default values maps directly to one
+             of the scheduler priority levels. An Excess Scheduler Id in
+             the range 0 -- 255 may be used without first being
+             established by a Scheduler Establishment message. All
+
+
+
+
+
+Newman, et. al.              Informational                     [Page 91]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             values of Excess Scheduler Id in the range 0x0100 to 0xFFFE
+             must first be established by a Scheduler Establishment
+             message.
+
+             If this field is not used it should be set to 0xFFFF.  The
+             Excess Scheduler Id must not point to the same waiting room
+             on the same output port as the Scheduler Identifier.
+
+   UPC Parameters
+             All connection styles 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 it is combined with other connections
+             into a QoS class by the classifier function. A policing
+             function applied to an entire QoS class is defined in the
+             QoS Class Establishment message.
+
+             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. 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.)
+
+             Two policers in series may be specified to permit the
+             policing of both peak rate and average rate (also called
+             sustainable rate). The parameters for the first policer are
+             Increment-1 and Limit-1. For comparison with the ATM Forum
+             specification these would be used to police the Peak Cell
+             Rate (PCR) and Cell Delay Variation Tolerance (CDVT)
+             respectively. The parameters for the second policer are
+             Increment-2 and Limit-2. For comparison with the ATM Forum
+             specification these would be used to police the Sustainable
+             Cell Rate (SCR), and Burst Tolerance.  (The Burst Tolerance
+             may be computed from the Maximum Burst Size [af-tm-0056].)
+
+             There are two configurations in which the two policers may
+             be connected in series.  In the All Cells configuration,
+             all cells (cells with the Cell Loss Priority (CLP) bit set
+             to zero and cells with the CLP bit set to one) are subject
+             to the policing action of both policers in series. In the
+             CLP Selective configuration, all cells, both CLP=0 and
+             CLP=1, are policed by the first policer; but only cells
+
+
+
+
+
+Newman, et. al.              Informational                     [Page 92]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             with CLP=0 are subject to policing by the second policer.
+             Either tagging or discard may be specified for each of the
+             policer configurations.
+
+             The values of the parameters Increment and Limit in the UPC
+             Parameters fields are given in terms of a time unit
+             specified by the switch in the QoS Configuration Parameters
+             message. The time unit is specified by the switch as a
+             rate, the Scaling Factor, which gives the rate in cells per
+             second that would result from an Increment parameter value
+             of one. Thus to determine the value of the Increment
+             parameter from the desired policed rate given in cells per
+             second:
+
+                Increment parameter = (Scaling_Factor)/(policed_rate)
+
+             To determine the value of the Limit parameter from the
+             desired Cell Delay Variation Tolerance (CDVT) given in
+             seconds:
+
+                Limit parameter = CDVT * Scaling_Factor
+
+             To determine the value of the Limit parameter from the
+             desired Burst Tolerance (BT) given in seconds:
+
+                Limit parameter = BT * Scaling_Factor
+
+             The Increment and Limit parameters are specified as 32-bit
+             unsigned integers; so the choice of the Scaling Factor
+             allows the switch to select the range and granularity of
+             the policer parameters with respect to the line rate of the
+             switch port.  For example, a SONET STS-3c (155.52 Mbps)
+             switch port has a line rate of approximately 353 kcells/s.
+             With a Scaling Factor value of 353,000,000 we can specify a
+             policed rate slightly less than the line rate with a
+             granularity of 0.1%. For a policed rate of 1 kbps we can
+             still support a bucket size of 31 cells.
+
+             The UPC Parameters have the following format:
+
+
+
+
+
+
+
+
+
+
+
+
+Newman, et. al.              Informational                     [Page 93]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+    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 parameter for the first policer, specified as
+             a 32-bit unsigned integer.  A value of zero for the
+             Increment-1 parameter is used to disable the first policer.
+             In this case all cells will be considered to conform to the
+             traffic parameters of the first policer.
+
+   Limit-1
+             The limit parameter for the first policer, specified as a
+             32-bit unsigned integer.
+
+   Increment-2
+             The increment parameter for the second policer, specified
+             as a 32-bit unsigned integer.  A value of zero for the
+             Increment-2 parameter is used to disable the second
+             policer.  In this case all cells will be considered to
+             conform to the traffic parameters of the second policer.
+
+   Limit-2
+             The limit parameter for the second policer, specified as a
+             32-bit unsigned integer.
+
+   Flags
+
+        C: Configuration
+             If the Configuration flag is set, the policer should be set
+             to the All Cells configuration. If the Configuration flag
+             is zero, the policer should be set to the CLP Selective
+             configuration.
+
+             In the All Cells configuration, all cells (both CLP=0 and
+             CLP=1) are subject to the policing action of both policers
+             in series. In the CLP Selective configuration, all cells,
+             both CLP=0 and CLP=1, are policed by the first policer; but
+
+
+
+Newman, et. al.              Informational                     [Page 94]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             only cells with CLP=0 are subject to policing by the second
+             policer. Either tagging or discard may be specified for
+             each of the policer configurations.
+
+        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 selected in the All Cells configuration, any
+             cell with CLP=0 in either policer, that the policer
+             determines to be in excess of the specified policer
+             parameters, will be changed to CLP=1. If discard is
+             selected in the All Cells configuration, any cell (CLP=0 or
+             CLP=1) in either policer, that the policer determines to be
+             in excess of the specified policer parameters, will be
+             discarded.
+
+             In the CLP Selective configuration, the first policer is
+             always set to discard any cell (CLP=0 or CLP=1) that it
+             determines to be in excess of its specified policer
+             parameters. If tagging is selected in the CLP Selective
+             configuration, the second policer will change the CLP bit
+             to CLP=1 of any cell that it determines to be in excess of
+             its specified parameters. If discard is selected in the CLP
+             Selective configuration, the second policer will discard
+             any cell that it determines to be in excess of its
+             specified parameters.
+
+             To configure the policer for the conformance definitions
+             specified by the ATM Forum [af-tm-0056] the following
+             configurations 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" require the
+             Regulator Parameters to be 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.
+
+
+
+Newman, et. al.              Informational                     [Page 95]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             The Regulator Parameters are specified in a similar manner
+             to the UPC parameters. If the regulator function is
+             specified as Policing, a single GCRA policer is applied to
+             all cells (both CLP=0 and CLP=1) on the connection. The
+             policer takes two parameters: an increment, the Regulator
+             Increment, and a limit, the Regulator Limit. The reciprocal
+             of the increment (1/I) specifies the rate being policed.
+             The limit (L) 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.)
+
+             The Regulator Increment and Regulator Limit parameters are
+             32-bit unsigned integers. Their values are determined in
+             terms of the Scaling Factor specified by the switch in the
+             QoS Configuration Parameters message. To determine the
+             value of the Regulator Increment parameter from the desired
+             policed rate given 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 amount of traffic determined by
+             the policer to be conforming to the traffic parameters does
+             not exceed:
+
+                rT + L/I
+
+             The value of the Regulator Limit may be determined from
+             this relation.
+
+             If the regulator function is specified as Shaping, only the
+             Regulator Increment parameter is used. The Regulator Limit
+             parameter is not used. The value of the Regulator Increment
+             parameter is determined in terms of the Scaling Factor
+             specified by the switch in the QoS Configuration Parameters
+             message. To determine the value of the Regulator Increment
+             parameter from the desired shaper rate, given in cells per
+             second, on output from the shaper:
+
+                Regulator Increment = (Scaling_Factor)/(shaper_rate)
+
+             An Increment value of zero is used to disable the policer.
+             In this case all cells on that connection will be
+             considered to conform to the policer traffic parameters. A
+             shaper given a Regulator Increment parameter of zero will
+             perform no shaping function on that connection.
+
+   The Regulator Parameters have the following format:
+
+
+
+Newman, et. al.              Informational                     [Page 96]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+    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
+
+   A failure response message is formed by returning the request message
+   that caused the failure with the Result field in the header
+   indicating failure (Result = 4) and the Code field giving the failure
+   code. The failure code specifies the reason for the switch being
+   unable to satisfy the request message.  The following additional
+   failure codes are defined for use in response to QoS messages.
+   General failure codes are specified in Section 3.2, Failure Response
+   Messages.
+
+       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
+
+   The adjacency protocol is used to synchronize state across the link,
+   to agree on which version of the protocol to use, to discover the
+   identity of the entity at the other end of a link, and to detect when
+   it changes. GSMP is a hard state protocol.  It is therefore important
+   to detect loss of contact between switch and controller, and to
+   detect any change of identity of switch or controller.  No GSMP
+   messages other than those of the adjacency protocol may be sent
+   across the link until the adjacency protocol has achieved
+   synchronization.
+
+
+
+
+
+
+
+Newman, et. al.              Informational                     [Page 97]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+10.1 Packet Format
+
+   All GSMP messages belonging to the adjacency protocol have the
+   following 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 contains the highest version understood by the
+             sender.  A receiver receiving a SYN message with a version
+             higher than understood will ignore that message.  A
+             receiver receiving a SYN message with a version lower than
+             its own highest version, but a version that it understands,
+             will reply with a SYNACK with the version from the received
+             SYN in its GSMP Version field. This defines the version of
+             the GSMP protocol to be used while the adjacency protocol
+             remains synchronized. All other messages will use the
+             agreed version in the Version field.
+
+             The version number for the version of the GSMP protocol
+             defined by this specification is Version = 2.
+
+   Message Type
+             The adjacency protocol is:
+
+                Message Type = 10
+
+
+
+
+
+Newman, et. al.              Informational                     [Page 98]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   Timer
+             The Timer field is used to inform the receiver of the timer
+             value used in the adjacency protocol of the sender. The
+             timer specifies the nominal time between periodic adjacency
+             protocol messages. It is a constant for the duration of a
+             GSMP session. The timer field is specified in units of
+             100ms.
+
+   M-Flag
+             The M-Flag is used in the SYN message to indicate 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 zero, the
+             sender is a slave. The GSMP protocol is asymmetric, the
+             controller being the master and the switch being the slave.
+             The M-Flag prevents a master from synchronizing with
+             another master, or a slave 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
+             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, 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. If the 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, 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,
+
+
+
+Newman, et. al.              Informational                     [Page 99]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             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, is the local port
+             number of the link across which the message is being sent.
+             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, 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, 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, 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.
+
+
+
+
+
+
+
+Newman, et. al.              Informational                    [Page 100]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+10.2 Procedure
+
+   The adjacency protocol is described by the following rules and state
+   tables.
+
+   The rules and state tables use the following operations:
+
+    o 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.
+
+    o 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.
+
+    o 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.
+
+    o 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.
+
+
+
+
+
+Newman, et. al.              Informational                    [Page 101]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+      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.
+
+    o State synchronization across a link is considered to be achieved
+      when the protocol reaches the ESTAB state. All GSMP messages,
+      other than adjacency protocol messages, that are received before
+      synchronization is achieved will be discarded.
+
+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  |
++======================================================================+
+
+
+
+
+
+
+
+Newman, et. al.              Informational                    [Page 102]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+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: No more than two ACKs should be sent within any time period
+   of length defined by the timer. Thus, one ACK must be sent every time
+   the timer expires. In addition, one further ACK may be sent between
+   timer expirations if the incoming message is a SYN or SYNACK. This
+   additional ACK allows the adjacency protocol to reach synchronization
+   more quickly.
+
+   Note 3: 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 in any period of time in excess of three times the value of
+   the Timer field announced in the incoming adjacency protocol
+   messages, loss of synchronization may be declared.
+
+   The preferred procedure for a switch to use when it looses
+   synchronization with its active controller is to attempt to establish
+
+
+
+Newman, et. al.              Informational                    [Page 103]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   synchronization with (one of) its backup controller(s).  However, in
+   this preferred approach, it must not reset its state until it
+   achieves synchronization with a backup controller.  This means that
+   if, before achieving synchronization with a backup controller, it
+   regains synchronization with its original controller, it may continue
+   the original session (and cease attempting to establish
+   synchronization with a backup controller). If synchronization with
+   the original session is regained it is the responsibility of the
+   controller to ensure consistent state between the switch and
+   controller.
+
+   While the above is the preferred procedure, it is also the case that
+   the simplest procedure when declaring loss of synchronization with
+   the active controller is to reset the switch state, and start
+   searching for a controller.  This simple procedure is legitimate.
+
+11. Summary of Failure Response Codes
+
+   The following list gives a summary of the failure codes defined for
+   failure response messages:
+
+        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
+
+
+
+Newman, et. al.              Informational                    [Page 104]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+             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.
+
+
+12. Summary of Message Set
+
+   The following table gives a summary of the messages defined in this
+   version of the specification. It also indicates which messages must
+   be supported in a minimal implementation of the protocol. Those
+   messages marked as "Required" must be supported by the switch for an
+   implementation to be considered to conform to this specification.
+   (While the controller should also implement those messages marked
+
+
+
+Newman, et. al.              Informational                    [Page 105]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   "Required," conformance cannot be tested for the controller due to
+   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
+
+
+
+
+
+Newman, et. al.              Informational                    [Page 106]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+REFERENCES
+
+   [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
+
+   Physical security on the control link connecting the controller to
+   the switch is assumed. Security issues are not discussed in this
+   document.
+
+
+AUTHORS' ADDRESSES
+
+   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
+
+
+
+Newman, et. al.              Informational                    [Page 107]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+   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
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman, et. al.              Informational                    [Page 108]
+
+RFC 2297          Ipsilon's General Switch Management         March 1998
+
+
+Full Copyright Statement
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman, et. al.              Informational                    [Page 109]
+