As per Relevance of the word response, we have this rfc below:
Network Working Group P. Newman,
Request for Comments: 1987 W. Edwards,
Category: Informational R. Hinden,
E. Hoffman,
F. Ching Liaw,
T. Lyon,
G. Minshall,
August 1996
Ipsilon's General Switch Management Protocol
Version 1.1
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
The General Switch Management Protocol (GSMP), is a general
protocol to control an ATM switch. GSMP allows a controller
establish and release connections across the switch; add and
leaves on a point-to-multipoint connection; manage switch ports
request configuration information; and request statistics
Newman, et. al. Informational [Page 1]
RFC 1987 GSMP Protocol Specification August 1996
Table of
1. Introduction....................................................3
2. GSMP Packet Format..............................................4
3. Connection Management Messages..................................7
3.1 Add Branch Message.........................................11
3.2 Delete Branch Message......................................12
3.3 Delete Tree Message........................................13
3.4 Verify Tree Message........................................13
3.5 Delete All Message.........................................14
3.6 Move Branch Message........................................14
4. Port Management Message........................................16
5. Statistics Messages............................................20
5.1 VC Activity Message........................................20
5.2 Port and VC Statistics Messages............................23
5.2.1 Port Statistics Message..............................26
5.2.2 VC Statistics Message................................26
6. Configuration..................................................26
6.1 Switch Configuration Message...............................27
6.2 Port Configuration Message.................................28
6.3 All Ports Configuration Message............................32
7. Event Messages.................................................33
7.1 Port Up Message............................................35
7.2 Port Down Message..........................................35
7.3 Invalid VPI/VCI Message....................................35
7.4 New Port Message...........................................35
7.5 Dead Port Message..........................................36
8. Adjacency Protocol.............................................36
8.1 Packet Format..............................................36
8.2 Procedure..................................................39
9. Failure Response Messages......................................41
References........................................................43
Security Considerations...........................................43
Authors' Addresses................................................43
Newman, et. al. Informational [Page 2]
RFC 1987 GSMP Protocol Specification August 1996
1.
The General Switch Management Protocol (GSMP), is a general
protocol to control an ATM switch. GSMP allows a controller
establish and release connections across the switch; add and
leaves on a point-to-multipoint connection; manage switch ports
request configuration information; and request statistics. It
allows the switch to inform the controller of asynchronous
such as a link going down. GSMP runs across an ATM link
the controller to the switch, on a control connection (
channel) established at initialization. The GSMP protocol
asymmetric, the controller being the master and the switch being
slave. Multiple switches may be controlled by a single
using multiple instantiations of the protocol over separate
connections
A switch is assumed to contain multiple "ports". Each port is
combination of one "input port" and one "output port". Some
requests refer to the port as a whole whereas other requests
specific to the input port or the output port. ATM cells arrive
the switch from an external communication link on incoming
channels at an input port. ATM cells depart from the switch to
external communication link on outgoing virtual channels from
output port. Virtual channels on a port or link are referenced
their virtual path and virtual channel identifiers (VPI/VCI).
virtual channel connection across a switch is formed by connecting
incoming virtual channel to one or more outgoing virtual channels
Virtual channel connections are referenced by the input port on
they arrive and the virtual path and virtual channel
(VPI/VCI) of their incoming virtual channel
In general a virtual channel is established with a certain quality
service (QOS). Unfortunately this is an ill defined and
concept as new ideas make their way into hardware. For this
of the GSMP protocol it is assumed that each virtual
connection may be assigned a priority when it is established. It
be assumed that for virtual channel connections that share the
output port, an ATM cell on a connection with a higher priority
much more likely to exit the switch before an ATM cell on
connection with a lower priority if they are both in the switch
the same time. The number of priorities that each port of the
supports may be obtained from the port configuration message
Switch ports are described by a 32 bit port number. The
assigns port numbers and it may typically choose to structure the 32
bits into sub-fields that have meaning to the physical structure
the switch (e.g. shelf, slot, port). In general, a port in the
physical location on the switch will always have the same
Newman, et. al. Informational [Page 3]
RFC 1987 GSMP Protocol Specification August 1996
number, even across power cycles. The internal structure of the
number is opaque to the GSMP protocol. However, by looking up
product identity in a database, network management tools may
the partitioning of the port number and the physical meaning of
sub-fields
Each switch port also maintains a port session number assigned by
switch. A connection management message or a port management
with an incorrect port session number must be rejected. This
the controller to detect a link failure and to keep
synchronized. The port session number of a port remains
while the port is continuously in the available state and the
status is continuously up. When a port returns to the available
after it has been unavailable or in any of the loopback states,
when the line status returns to the up state after it has been
or in test, or after a power cycle, its port session number will
changed. Port session numbers should be assigned using some form
random number
GSMP also contains an adjacency protocol. The adjacency protocol
used to synchronize state across the link, to discover the
of the entity at the other end of a link, and to detect when
changes
2. GSMP Packet
GSMP packets are variable length and are encapsulated directly in
AAL-5 CPCS-PDU [I.363] with an LLC/SNAP header 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LLC (0xAA-AA-03) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| SNAP (0x00-00-00-88-0C) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ GSMP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pad (0 - 47 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ AAL-5 CPCS-PDU Trailer (8 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Newman, et. al. Informational [Page 4]
RFC 1987 GSMP Protocol Specification August 1996
(The convention in the documentation of Internet Protocols [rfc1700]
is to express numbers in decimal and to picture data in "big-endian
order. That is, fields are described left to right, with the
significant octet on the left and the least significant octet on
right. Whenever a diagram shows a group of octets, the order
transmission of those octets is the normal order in which they
read in English. Whenever an octet represents a numeric quantity
left most bit in the diagram is the high order or most
bit. That is, the bit labeled 0 is the most significant bit
Similarly, whenever a multi-octet field represents a numeric
the left most bit of the whole field is the most significant bit
When a multi-octet quantity is transmitted, the most
octet is transmitted first. This is the same coding convention as
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
The maximum transmission unit (MTU) of the GSMP message is 1500
octets
The default virtual channel for LLC/SNAP encapsulated messages is
VPI = 0
VCI = 15.
GSMP is a master-slave protocol. The controller issues
messages to the switch. Each request message indicates whether
response is required from the switch and contains a
identifier to enable the response to be associated with the request
The switch replies with a response message indicating either
successful result or a failure. There are four classes of
request-response message: Connection Management, Port Management
Statistics, and Configuration. The switch may also
asynchronous Event messages to inform the controller of
events. Event messages are not acknowledged by the controller.
is also an adjacency protocol message used to
synchronization across the link and maintain a handshake
For the request-response messages each message type has a format
the request message and a format for the success response.
otherwise specified a failure response message is identical to
request message that caused the failure, with the Code
indicating the nature of the failure. Event messages have only
single format defined as they are not acknowledged by the controller
Except for the adjacency protocol message, no GSMP messages may
sent across the link until the adjacency protocol has
Newman, et. al. Informational [Page 5]
RFC 1987 GSMP Protocol Specification August 1996
synchronization, and all GSMP messages received on a link that
not currently have state synchronization must be discarded
All GSMP messages, except the adjacency protocol message, have
following format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Message Body ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The GSMP protocol version number, currently Version = 1.
should be set by the sender of the message to the
protocol version that the sender is currently running
Message
The GSMP message type. GSMP messages fall into
classes: Connection Management, Port Management
Statistics, Configuration, and Events. Each class,
for port management, has a number of different
types. In addition, one Message Type is allocated to
adjacency protocol
Field in a connection management request message or a
management request message, is used to indicate whether
response is required to the request message if the
is successful. A value of "NoSuccessAck" indicates that
request message does not expect a response if the
is successful, and a value of "AckAll" indicates that
response is expected if the outcome is successful. In
cases a failure response will be generated if the
fails. This facility reduces the traffic in the case
the controller is simply checking that the state in
switch is correct. For all other request messages a
of "NoSuccessAck" in the request message is ignored and
request message is handled as if the field were set
"AckAll". In a response message the result field can
two values: "Success" and "Failure".
Newman, et. al. Informational [Page 6]
RFC 1987 GSMP Protocol Specification August 1996
The encoding of the result field is
NoSuccessAck: Result = 1
AckAll: Result = 2
Success: Result = 3
Failure: Result = 4.
The Result field is not used in an adjacency
message and should be set to zero by the sender and
by the receiver
Field gives further information concerning the result in
response message. It is mostly used to pass an error
in a failure response but can also be used to give
information in a success response message or an
message. In a request message the code field is not
and is set to zero. In an adjacency protocol message
Code field is used to determine the function of
message
Transaction
Used to associate a request message with its
message. For request messages the controller may select
transaction identifier. For response messages
transaction identifier is set to the value of
transaction identifier from the message to which it is
response. For event messages the transaction
should be set to zero. In the adjacency protocol
Transaction Identifier is not used. This field is
present in the adjacency protocol message
3. Connection Management
Connection management messages are used by the controller
establish, delete, modify and verify connections across the switch
The Add Branch, Delete Branch, Delete Tree, Verify Tree, and
All connection management messages have the following format for
request and response messages
Newman, et. al. Informational [Page 7]
RFC 1987 GSMP Protocol Specification August 1996
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | Input VPI | Input VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | Output VPI | Output VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Branches | Reserved | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Port Session
Field gives the session number of the input port.
switch port maintains a Port Session Number assigned by
switch. The port session number of a port remains
while the port is continuously in the Available state
the link status is continuously Up. When a port returns
the Available state after it has been Unavailable or in
of the Loopback states, or when the line status returns
the Up state after it has been Down or in Test, or after
power cycle, a new Port Session Number must be generated
Port session numbers should be assigned using some form
random number. The switch must reject any
management request message that has an invalid Port
Number for the port specified in the Input Port field
returning a failure response message with the Code
indicating, "Invalid port session number." The current
session number may be obtained using a
message
Input
Indicates a switch input port. Switch ports are
by a 32 bit value assigned by the switch
Input
Identifies an ATM virtual path arriving at the switch
port indicated by the Input Port field
Newman, et. al. Informational [Page 8]
RFC 1987 GSMP Protocol Specification August 1996
Input
Identifies an ATM virtual channel arriving on the
path indicated by the Input VPI field at the switch
port indicated by the Input Port field
Output
Indicates a switch output port. Switch ports
referenced by a 32 bit value assigned by the switch
Output
Identifies an outgoing virtual path departing from
switch output port indicated in the Output Port field
Output
Identifies an outgoing virtual channel departing on
virtual path indicated by the Output VPI field from
switch output port indicated in the Output Port field
Number of
Gives the number of output branches on a virtual
connection. (A unicast connection will have one branch,
multicast connection will have two or more branches.)
field is only used in the Verify Tree message. In
other connection management messages this field should
set to zero by the sender and ignored by the receiver
This field is not used. It is set to zero by the sender
ignored by the receiver
Gives the priority of the connection. The highest
is numbered zero and the lowest priority is numbered "Q-1"
where "Q" is the number of priorities that the output
can support. The ability to offer different qualities
service to different connections based upon their
is assumed to be a property of the output port of
switch. It is assumed that for virtual channel
that share the same output port, an ATM cell on
connection with a higher priority is much more likely
exit the switch before an ATM cell on a connection with
lower priority if they are both in the switch at the
time. The number of priorities that each output port
support is given in the Port Configuration message. If
connection request is received with a value in the
field that the switch cannot support, the switch
assign the closest priority that it is capable
supporting. This field is only used in the Add Branch
Newman, et. al. Informational [Page 9]
RFC 1987 GSMP Protocol Specification August 1996
Move Branch messages. In all other connection
messages this field should be set to zero by the sender
ignored by the receiver
If the result field of the request message is "AckAll" the
must reply to all connection management request messages with
success response message or a failure response message. If
result field of the request message is "NoSuccessAck" the switch
only reply in the case of a failure
A success response message must not be sent until the operation
been successfully completed. For connection management messages
success response message is a copy of the request message
with a Result field indicating success. The Code field is not used
a connection management success response message and should be set
zero. The failure response message is a copy of the request
returned with a Result field indicating failure. The Code field
used to pass the Failure Code in a connection management
response message. If the switch issues a failure response
connection state within the switch must not be modified by
request message that resulted in the failure
No distinction is made between unicast connections and
connections. The first Add Branch message for a particular
Port, Input VPI, and Input VCI will establish a unicast connection
The second Add Branch message with the same Input Port, Input VPI
and Input VCI fields will convert the connection to a
connection with two branches. Subsequent Add Branch messages with
same Input Port, Input VPI, and Input VCI fields will add
branches to the multicast connection. Use of the Delete
message on a multicast connection with two branches will result in
unicast connection. Use of the Delete Branch message on a
connection will delete the unicast connection. There is no concept
a connection with zero output branches. All connections
unidirectional, one input virtual channel to one or more
virtual channels
The connection management messages may be issued regardless of
Port Status of the switch port. Connections may be established
deleted when a switch port is in the Available, Unavailable, or
of the Loopback states. However, all connection state on an
port will be deleted when the port returns to the Available
from any other state, i.e. when a Port Management message is
for that port with the Function field indicating either Bring Up,
Reset Input Port
Newman, et. al. Informational [Page 10]
RFC 1987 GSMP Protocol Specification August 1996
3.1 Add Branch
The Add Branch message is a connection management message used
establish a virtual channel connection or to add an additional
to an existing virtual channel connection. It may also be used
check the connection state stored in the switch. The connection
specified by the Input Port, Input VPI, and Input VCI fields.
output branch is specified by the Output Port, Output VPI, and
VCI fields. The priority of the connection is specified by
Priority field. The Add Branch message is
Message Type = 16
If the virtual channel connection specified by the Input Port,
VPI, and Input VCI fields does not already exist, it must
established with the single output branch specified in the
message. The output branch should have the priority specified by
Priority field. If the Result field of the request message
"AckAll" a success response message must be sent upon
establishment of the specified branch. The success response
must not be sent until the Add Branch operation has been completed
If the virtual channel connection specified by the Input Port,
VPI, and Input VCI fields already exists, but the specified
branch does not, the new output branch must be added. The new
branch should have the priority specified by the Priority field.
the Result field of the request message is "AckAll" a
response message must be sent upon successful establishment of
specified branch. The success response message must not be sent
the Add Branch operation has been completed
If the virtual channel connection specified by the Input Port,
VPI, and Input VCI fields already exists and the specified
branch also already exists, the priority of the connection,
different from the request message, should be changed to that in
request message. A success response message must be sent if
Result field of the request message is "AckAll". This allows
controller to periodically reassert the state of a connection or
change its priority. If the result field of the request message
"NoSuccessAck" a success response message should not be returned
This may be used to reduce the traffic on the control link
messages that are reasserting previously established state.
messages that are reasserting previously established state,
switch must always check that this state is correctly established
the switch hardware (i.e. the actual connection tables used
forward cells).
Newman, et. al. Informational [Page 11]
RFC 1987 GSMP Protocol Specification August 1996
The behavior is undefined if the output virtual channel specified
the Output Port, Output VPI, and Output VCI fields is already in
by any connection other than that specified by the Input Port,
VPI, and Input VCI fields
A failure response must be returned if the switch is unable
establish the specified branch or if there is an error in any of
fields of the request message. If a failure message is returned
state of the switch must not have been modified by the
message
It should be noted that different switches support multicast
different ways. There will be a limit to the total number
multicast connections any switch can support, and possibly a limit
the maximum number of branches that a multicast connection
specify. Some switches also impose a limit on the number
different VPI/VCI values that may be assigned to the output
of a multicast connection. Many switches are incapable of
more than a single branch of any particular multicast connection
the same output port. Specific failure codes are defined for some
these conditions. If a switch sends a failure response to an
Branch message it must choose the most specific failure code
3.2 Delete Branch
The Delete Branch message is a connection management message used
delete a single branch of a virtual channel connection, or in
case of the last branch, to delete the connection. The
channel connection is specified by the Input Port, Input VPI,
Input VCI fields. The specific branch is indicated by the
Port, Output VPI, and Output VCI fields. The Delete Branch
is
Message Type = 17
If the Result field of the request message is "AckAll" a
response message must be sent upon successful deletion of
specified branch. The success response message must not be sent
the delete branch operation has been completed and if possible,
until all data on that branch, queued for transmission, has
transmitted. A failure message indicating, "The specified
does not exist," must be sent if the connection specified by
Input Port, Input VPI, and Input VCI fields does not exist. A
message indicating, "The specified branch does not exist," must
sent if the connection specified by the Input Port, Input VPI,
Input VCI fields exists but the branch specified by the Output Port
Output VPI, and Output VCI fields does not exist
Newman, et. al. Informational [Page 12]
RFC 1987 GSMP Protocol Specification August 1996
3.3 Delete Tree
The Delete Tree message is a connection management message used
delete an entire virtual channel connection. All remaining
of the connection are deleted. The virtual channel connection
specified by the Input Port, Input VPI, and Input VCI fields.
Output Port, Output VPI, and Output VCI fields are not used in
message and their contents should be set to zero by the sender
ignored by the receiver. The Delete Tree message is
Message Type = 18
If the Result field of the request message is "AckAll" a
response message must be sent upon successful deletion of
specified connection. The success message must not be sent until
delete operation has been completed and if possible, not until
data on the connection, queued for transmission, has
transmitted. A failure message indicating, "The specified
does not exist," must be sent if the connection specified by
Input Port, Input VPI, and Input VCI fields does not exist
3.4 Verify Tree
The Verify Tree message is a connection management message used
verify the number of branches on a virtual channel connection.
virtual channel connection is specified by the Input Port, Input VPI
and Input VCI fields. The Output Port, Output VPI, and Output
fields are not used in this message and their contents should be
to zero by the sender and ignored by the receiver. The number
branches that the sender believes that this virtual
connection should contain is given by the Number of Branches field
The Verify Tree message is
Message Type = 19
If the Result field of the request message is "AckAll" a
response message must be sent if the receiver agrees that the
number of branches of the specified virtual channel
matches the number contained in the Number of Branches field of
request message. The failure response message, with the code
set to "Failure specific to the particular message type," must
sent if the actual number of branches of the specified
channel connection does not match the number contained in the
of Branches field of the request message. In this failure
message the Number of Branches field must be changed to contain
actual number of branches of the specified virtual
connection. A failure response message with the code field set to
different value must be used to indicate some other failure such as
Newman, et. al. Informational [Page 13]
RFC 1987 GSMP Protocol Specification August 1996
"The specified connection does not exist." In this case the Number
Branches field will be the same as that of the request message
The Verify Tree message can only be guaranteed to yield a
response when there are no other connection request messages or
response messages pending for the specified connection. If this
not the case the result of the Verify Tree message is undefined
3.5 Delete All
The Delete All message is a connection management message used
delete all connections on a switch input port. All connections
arrive at the specified input port must be deleted. On completion
the operation all dynamically assigned VPI/VCI values for
specified port must be unassigned, i.e. there must be no
connections established in the VPI/VCI space that GSMP controls
this port. The Input VPI, Input VCI, Output Port, Output VPI,
Output VCI fields are not used in this message and their contents
ignored and unspecified. The Delete All message is
Message Type = 20
If the Result field of the request message is "AckAll" a
response message must be sent upon completion of the operation.
success response message must not be sent until the operation
been completed
3.6 Move Branch
The Move Branch connection management message has the
format for both request and response messages
Newman, et. al. Informational [Page 14]
RFC 1987 GSMP Protocol Specification August 1996
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | Input VPI | Input VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | Old Output VPI | Old Output VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | New Output VPI | New Output VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Move Branch message is a connection management message used
move a single output branch of a virtual channel connection from
current output port, output VPI, and output VCI, to a new
port, output VPI, and output VCI on the same virtual
connection. None of the other output branches are modified. When
operation is complete the original output VPI/VCI on the
output port will be deleted from the connection. The Move
message is
Message Type = 22
If the virtual channel connection specified by the Input Port,
VPI, and Input VCI fields already exists, and the output
specified by the Old Output Port, Old Output VPI, and Old Output
fields exists as a branch on that connection, the output
specified by the New Output Port, New Output VPI, and New Output
fields is added to the connection and the branch specified by the
Output Port, Old Output VPI, and Old Output VCI fields is deleted.
the Result field of the request message is "AckAll" a
response message must be sent upon successful completion of
operation. The success response message must not be sent until
Move Branch operation has been completed
Newman, et. al. Informational [Page 15]
RFC 1987 GSMP Protocol Specification August 1996
If the virtual channel connection specified by the Input Port,
VPI, and Input VCI fields already exists, but the output
specified by the Old Output Port, Old Output VPI, and Old Output
fields does not exist as a branch on that connection, a
response must be returned with the Code field indicating, "
specified branch does not exist." The connection state of the
must not be modified in this case
If the virtual channel connection specified by the Input Port,
VPI, and Input VCI fields does not exist, a failure response must
returned with the Code field indicating, "The specified
does not exist." The connection state of the switch must not
modified in this case
The behavior is undefined if the output virtual channel specified
the New Output Port, New Output VPI, and New Output VCI fields
already in use by any connection
A failure response will be returned if the switch is unable
establish the specified branch or if there is an error in any of
fields of the request message. If a failure message is returned
state of the switch must not have been modified by the
message
4. Port Management
The Port Management message allows a port to be brought into service
taken out of service, looped back, or reset. Only the Bring Up
the Reset Input Port functions change the connection
(established connections) on the input port. Only the Bring
function changes the value of the Port Session Number. If the
field of the request message is "AckAll" a success response
must be sent upon successful completion of the operation. The
response message must not be sent until the operation has
completed. The Port Management Message is
Message Type = 32
The Port Management message has the following format for the
and success response messages
Newman, et. al. Informational [Page 16]
RFC 1987 GSMP Protocol Specification August 1996
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Gives the port number of the port to which the
applies
Port Session
Gives the current port session number for the port. If
Port Session Number in the request message does not
the current port session number of the port indicated
the Port field of the request message, a failure
must be returned with, "Invalid port session number,"
indicated in the Code field. If the specified
requires a new Port Session Number to be generated the
Port Session Number must be given in the success
message. The Port Session Number must be generated
some form of random number
Event Sequence
In the success response message gives the current value
the Event Sequence Number of the switch port indicated
the Port field. The Event Sequence Number is set to
when the port is initialized and is incremented by one
time an asynchronous event is detected on that port
the switch would normally report via an Event message.
the Event Sequence Number in the success response
from the Event Sequence Number of the most recent
message received for that port, events have occurred
were not reported via an Event message. This is most
to be due to the flow control that restricts the rate
which a switch can send Event messages for each port.
the request message this field is not used and should
set to zero by the sender and ignored by the receiver
Newman, et. al. Informational [Page 17]
RFC 1987 GSMP Protocol Specification August 1996
Event
Field in the request message is used to reset the
Flags in the switch port indicated by the Port field.
Event Flag in a switch port corresponds to a type of
message. When a switch port sends an Event message it
the corresponding Event Flag on that port. The port is
permitted to send another Event message of the same
until the Event Flag has been reset. If the Function
in the request message is set to "Reset Event Flags,"
each bit that is set in the Event Flags field,
corresponding Event Flag in the switch port is reset
The Event Flags field is only used in a request
with the Function field set to "Reset Event Flags." For
other values of the Function field, the Event Flags
should be set to zero in the request message and must
ignored by the receiver. In the success response
the Event Flags field must be set to the current value
the Event Flags for the port, after the completion of
operation specified by the request message, for all
of the Function field. Setting the Event Flags field to
zeros in a "Reset Event Flags" request message allows
controller to obtain the current state of the Event
and the current Event Sequence Number of the port
changing the state of the Event Flags
The correspondence between the types of Event message
the bits of the Event Flags field is as follows
Port Up: Bit 0, (most significant bit
Port Down: Bit 1,
Invalid VPI/VCI: Bit 2,
New Port: Bit 3,
Dead Port: Bit 4.
Is the length of time, in seconds, that any of the
states remain in operation. When the duration has
the port will automatically be returned to service.
another Port Management message is received for the
port before the duration has expired, the loopback
continue to remain in operation for the length of
specified by the Duration field in the new message.
Duration field is only used in request messages with
Function field set to Internal Loopback, External Loopback
or Bothway Loopback. In all other request messages
should be set to zero by the sender and ignored by
receiver
Newman, et. al. Informational [Page 18]
RFC 1987 GSMP Protocol Specification August 1996
Specifies the action to be taken. The specified action
be taken regardless of the current status of the
(Available, Unavailable, or any Loopback state).
defined values of the Function field are
Bring Up
Function = 1. Bring the port into service.
connections that arrive at the specified input
must be deleted and a new Port Session Number must
selected using some form of random number.
completion of the operation all dynamically
VPI/VCI values for the specified input port must
unassigned, i.e. no virtual connections will
established in the VPI/VCI space that GSMP controls
this input port. The Port Status of the
afterwards will be Available
Take Down
Function = 2. Take the port out of service. Any
received at this port will be discarded. No cells
be transmitted from this port. The Port Status of
port afterwards will be Unavailable. The behavior
undefined if the port over which the GSMP protocol
running is taken down
Internal Loopback
Function = 3. Cells arriving at the output port
the switch fabric are looped through to the input
to return to the switch fabric. All of the
functions of the input port above the PHY layer, e.g
header translation, are performed upon the looped
cells. The Port Status of the port afterwards will
Internal Loopback
External Loopback
Function = 4. Cells arriving at the input port
the external communications link are
looped back to the communications link at the
layer without entering the input port. None of the
functions of the input port above the PHY layer
performed upon the looped back cells. The Port
of the port afterwards will be External Loopback
Bothway Loopback
Function = 5. Both internal and external loopback
performed. The Port Status of the port afterwards
be Bothway Loopback
Newman, et. al. Informational [Page 19]
RFC 1987 GSMP Protocol Specification August 1996
Reset Input Port
Function = 6. All connections that arrive at
specified input port must be deleted and the input
output port hardware re-initialized. On completion
the operation all dynamically assigned VPI/VCI
for the specified input port must be unassigned, i.e
no virtual connections will be established in
VPI/VCI space that GSMP controls on this input port
The Port Session Number is not changed by the
Input Port function. The Port Status of the
afterwards will be Unavailable
Reset Event Flags
Function = 7. For each bit that is set in the
Flags field, the corresponding Event Flag in
switch port must be reset. The Port Status of the
is not changed by this function
5. Statistics
The statistics messages permit the controller to request the
of various hardware counters associated with the switch input
output ports, and virtual channels. Two classes of statistics
are defined: the VC Activity Message, and the Port and VC
Messages. The VC Activity message is used to determine whether one
more specific VCs have recently been carrying traffic. The Port
VC Statistics message is used to query the various port and
specific traffic and error counters
5.1 VC Activity
The VC Activity message is used to determine whether one or
specific VCs have recently been carrying traffic. The VC
message contains one or more VC Activity records. Each VC
record is used to request and return activity information
a single virtual connection. Each VC is specified by its input port
input VPI, and input VCI. These are specified in the Input Port
Input VPI, and Input VCI fields of each VC Activity record.
forms of activity detection are supported. If the switch supports
VC traffic accounting the current value of the traffic counter
each specified VC must be returned. The units of traffic counted
not specified but will typically be either cells or frames.
controller must compare the traffic counts returned in the
with previous values for each of the specified VCs to
whether each VC has been active in the intervening period. If
switch does not support per VC traffic accounting, but is capable
detecting per-VC activity by some other unspecified means, the
Newman, et. al. Informational [Page 20]
RFC 1987 GSMP Protocol Specification August 1996
may be indicated for each VC using the Flags field. The VC
message is
Message Type = 48
The VC Activity request and success response messages have
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ VC Activity Records ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Number of
Field specifies the number of VC Activity records
follow. The maximum number of VC Activity records
in a single VC Activity message is 120.
Field is not used. It is set to zero by the sender
ignored by the receiver
Each VC Activity Record has the following format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Input VPI | Input VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ VC Traffic Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Input
Identifies the port number of the input port on which
VC of interest arrives in order to identify the
(regardless of whether the traffic count for the VC
maintained on the input port or the output port).
Newman, et. al. Informational [Page 21]
RFC 1987 GSMP Protocol Specification August 1996
Input
Input
Fields identify the specific virtual channel for
statistics are being requested
In the request message this field is unused, it should
set to zero by the sender and ignored by the receiver.
the success response message bit 0 (msb) of the Flags
is used to indicate an invalid VC Activity record. This
must be zero if any of the fields in this VC
record are invalid, if the input port specified by
Input Port field does not exist, or if the
connection does not exist. If this bit is zero in a
response message bits 1 and 2 of the Flags field and the
Traffic Count field are undefined. If bit 0 of the
field is set, the VC Activity record is valid, and bits 1
and 2 of the Flags field in the VC Activity record are
as follows
Bit 1 of the Flags field: if set, indicates that
value in bit 2 of the Flags field is valid; if zero
indicates that the value in the VC Traffic Count
is valid
If bit 1 of the Flags field is set, bit 2 of the
field, if set, indicates that there has been
activity on this virtual channel since the last
Activity message for this virtual channel
If bit 1 of the Flags field is set, bit 2 of the
field, if zero, indicates that there has been
activity on this virtual channel since the last
Activity message for this virtual channel
Bit 3 of the Flags field is not used, it should be
to zero by the sender and ignored by the receiver
VC Traffic
Field is unused in the request message, it should be set
zero by the sender and ignored by the receiver. In
success response message, if the switch supports per-
traffic counting, the VC Traffic Count field must be set
the value of a free running, VC specific, 64 bit
counter counting traffic flowing across the
virtual channel. The value of the traffic counter is
modified by reading it. If per-VC traffic counting
supported, the switch must report the VC Activity
Newman, et. al. Informational [Page 22]
RFC 1987 GSMP Protocol Specification August 1996
using the traffic count rather than using bit 2 of
Flags field
The format of the failure response is the same as the request
with the Number of Records field set to zero and no VC
records returned in the message. If the switch is incapable
detecting per-VC activity, a failure response must be
indicating, "The specified request is not implemented on
switch."
5.2 Port and VC Statistics
The Port and VC Statistics messages are used to query the
port and VC specific traffic and error counters
The Port and VC Statistics request messages have the
format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | VPI | VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Identifies the port number of the port for which
are being requested
Fields identify the specific virtual channel for
statistics are being requested. For requests that do
require a virtual channel to be specified these
should be set to zero in the request and ignored by
receiver
The success response messages for the port and VC statistics
have the following format
Newman, et. al. Informational [Page 23]
RFC 1987 GSMP Protocol Specification August 1996
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | VPI | VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Input Cell Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Input Frame Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Input Cell Discard Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Input Frame Discard Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Input HEC Error Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Input Invalid VPI/VCI Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Output Cell Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Output Frame Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Output Cell Discard Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
Newman, et. al. Informational [Page 24]
RFC 1987 GSMP Protocol Specification August 1996
+ Output Frame Discard Count +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VPI/
Fields are the same as those of the request message
Input Cell
Output Cell
Each gives the value of a free running 64 bit
counting cells arriving at the input or departing from
output respectively. In response to a Port
message the count will be on a per port basis and
response to a VC Statistics message the count will be on
per VC basis
Input Frame
Output Frame
Each gives the value of a free running 64 bit
counting frames (packets) arriving at the input
departing from the output respectively. In response to
Port Statistics message the count will be on a per
basis and in response to a VC Statistics message the
will be on a per VC basis
Input Cell Discard
Output Cell Discard
Each gives the value of a free running 64 bit
counting cells discarded due to queue overflow on an
port or on an output port respectively. In response to
Port Statistics message the count will be on a per
basis and in response to a VC Statistics message the
will be on a per VC basis
Input Frame Discard
Output Frame Discard
Each gives the value of a free running 64 bit
counting frames discarded due to queue overflow on an
port or on an output port respectively. In response to
Port Statistics message the count will be on a per
basis and in response to a VC Statistics message the
will be on a per VC basis
HEC Error
Gives the value of a free running 64 bit counter
cells discarded due to header checksum errors on arrival
an input port
Newman, et. al. Informational [Page 25]
RFC 1987 GSMP Protocol Specification August 1996
Invalid VPI/VCI
Gives the value of a free running 64 bit counter
cells discarded because their VPI/VCI is invalid on
at an input port. An incoming VPI/VCI is invalid if
connection is currently established having that value
VPI/VCI
5.2.1 Port Statistics
The Port Statistics message requests the statistics for the
port specified in the Port field. The contents of the VPI/VCI
in the Port Statistics request message are ignored. All of the
fields in the success response message refer to per-port
regardless of the virtual channels to which the cells belong. Any
the count fields in the success response message not supported by
port will be set to zero. The Port Statistics message is
Message Type = 49
5.2.2 VC Statistics
The VC Statistics message requests the statistics for the
channel specified in the VPI/VCI field that arrives on the
input port specified in the Port field. All of the count fields
the success response message refer only to the specified
channel. The HEC Error Count and Invalid VPI/VCI Count fields are
VC specific and are set to zero. Any of the other count fields
supported on a per virtual channel basis will be set to zero in
success response message. The VC Statistics message is
Message Type = 50
6.
The configuration messages permit the controller to discover
capabilities of the switch. Three configuration request messages
been defined: Switch, Port, and All Ports
Newman, et. al. Informational [Page 26]
RFC 1987 GSMP Protocol Specification August 1996
All configuration request messages have the following format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Identifies the port number for which
information is being requested. If the Port field is
required by the message it is set to zero by the sender
ignored by the receiver
6.1 Switch Configuration
The Switch Configuration message requests the global (non port
specific) configuration for the switch. The Switch
message is
Message Type = 64
The Port field is not used in the request message and is set to zero
The Switch Configuration success response message has the
format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Firmware Version Number | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switch Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Switch Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Firmware Version
The version number of the switch control
installed
Newman, et. al. Informational [Page 27]
RFC 1987 GSMP Protocol Specification August 1996
Field is not used. It is set to zero by the sender
ignored by the receiver
Switch
A 16 bit field allocated by the manufacturer of the switch
(For these purposes the manufacturer of the switch
assumed to be the organization identified by the OUI in
Switch Name field.) The Switch Type identifies the product
When the Switch Type is combined with the OUI from
Switch Name the product is uniquely identified.
Management may use this identification to obtain
related information from a database
Switch
A 48 bit quantity that is unique within the
context of the device. A 48 bit IEEE 802 MAC address,
available, may be used as the Switch Name. The
significant 24 bits of the Switch Name must be
Organizationally Unique Identifier (OUI) that
the manufacturer of the switch
6.2 Port Configuration
The Port Configuration message requests the switch for
configuration information of a single switch port. The Port field
the request message specifies the port for which the configuration
requested. The Port Configuration message is
Message Type = 65.
The Port Configuration success response message has the
format
Newman, et. al. Informational [Page 28]
RFC 1987 GSMP Protocol Specification August 1996
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | Min VPI | zero | Max VPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min VCI | Max VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cell Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Status | Port Type | Line Status | Priorities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The switch port to which the configuration
refers. Configuration information relating to both
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
fields that have meaning to the physical structure of
switch 