RFC Number : 3292
Title : General Switch Management Protocol (GSMP) V3.
Network Working Group A. Doria
Request for Comments: 3292 Lulea University of Technology
Category: Standards Track F. Hellstrand
K. Sundell
Nortel Networks
T. Worster
June 2002
General Switch Management Protocol (GSMP) V3
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the 'Internet
Official Protocol Standards' (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document describes the General Switch Management Protocol
Version 3 (GSMPv3). The GSMPv3 is an asymmetric protocol that allows
one or more external switch controllers to establish and maintain the
state of a label switch such as, an ATM, frame relay or MPLS switch.
The GSMPv3 allows control of both unicast and multicast switch
connection state as well as control of switch system resources and
QoS features.
Acknowledgement
GSMP was created by P. Newman, W. Edwards, R. Hinden, E. Hoffman, F.
Ching Liaw, T. Lyon, and G. Minshall (see [6] and [7]). This version
of GSMP is based on their work.
Contributors
In addition to the authors/editors listed in the heading, many
members of the GSMP group have made significant contributions to this
specification. Among the contributors who have contributed
materially are: Constantin Adam, Clint Bishard, Joachim Buerkle,
Torbjorn Hedqvist, Georg Kullgren, Aurel A. Lazar, Mahesan
Nandikesan, Matt Peters, Hans Sjostrand, Balaji Srinivasan, Jaroslaw
Sydir, Chao-Chun Wang.
Doria, et. al. Standards Track [Page 1]
RFC 3292 General Switch Management Protocol V3 June 2002
Specification of Requirements
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in [RFC2119].
Table of Contents
1. Introduction ................................................... 4
2. GSMP Packet Encapsulation ...................................... 6
3. Common Definitions and Procedures .............................. 6
3.1 GSMP Packet Format ........................................... 7
3.1.1 Basic GSMP Message format ................................ 7
3.1.2 Fields commonly found in GSMP messages .................. 11
3.1.3 Labels .................................................. 12
3.1.4 Failure Response Messages ............................... 17
4. Connection Management Messages ................................ 18
4.1 General Message Definitions ................................. 18
4.2 Add Branch Message .......................................... 25
4.2.1 ATM specific procedures: ................................ 29
4.3 Delete Tree Message ......................................... 30
4.4 Verify Tree Message ......................................... 30
4.5 Delete All Input Port Message ............................... 30
4.6 Delete All Output Port Message .............................. 31
4.7 Delete Branches Message ..................................... 32
4.8 Move Output Branch Message .................................. 35
4.8.1 ATM Specific Procedures: ................................ 37
4.9 Move Input Branch Message ................................... 38
4.9.1 ATM Specific Procedures: ................................ 41
5. Reservation Management Messages ............................... 42
5.1 Reservation Request Message ................................. 43
5.2 Delete Reservation Message .................................. 46
5.3 Delete All Reservations Message.............................. 47
6. Management Messages ........................................... 47
6.1 Port Management Message ..................................... 47
6.2 Label Range Message ......................................... 53
6.2.1 Labels .................................................. 56
7. State and Statistics Messages ................................. 60
7.1 Connection Activity Message ................................. 61
7.2 Statistics Messages ......................................... 64
7.2.1 Port Statistics Message ................................. 67
7.2.2 Connection Statistics Message ........................... 67
7.2.3 QoS Class Statistics Message ............................ 68
7.3 Report Connection State Message ............................. 68
8. Configuration Messages ........................................ 73
8.1 Switch Configuration Message ................................ 73
8.1.1 Configuration Message Processing ........................ 75
8.2 Port Configuration Message .................................. 75
Doria, et. al. Standards Track [Page 2]
RFC 3292 General Switch Management Protocol V3 June 2002
8.2.1 PortType Specific Data .................................. 79
8.3 All Ports Configuration Message ............................. 87
8.4 Service Configuration Message ............................... 89
9. Event Messages ................................................ 93
9.1 Port Up Message ............................................ 95
9.2 Port Down Message .......................................... 95
9.3 Invalid Label Message ...................................... 95
9.4 New Port Message ........................................... 96
9.5 Dead Port Message .......................................... 96
9.6 Adjacency Update Message ................................... 96
10. Service Model Definition .................................... 96
10.1 Overview .................................................. 96
10.2 Service Model Definitions ................................. 97
10.2.1 Original Specifications ............................... 97
10.2.2 Service Definitions ................................... 98
10.2.3 Capability Sets ....................................... 99
10.3 Service Model Procedures .................................. 99
10.4 Service Definitions ....................................... 100
10.4.1 ATM Forum Service Categories .......................... 101
10.4.2 Integrated Services ................................... 104
10.4.3 MPLS CR-LDP ........................................... 105
10.4.4 Frame Relay ........................................... 105
10.4.5 DiffServ .............................................. 106
10.5 Format and Encoding of the Traffic Parameters ............. 106
10.5.1 Traffic Parameters for ATM Forum Services ............. 106
10.5.2 Traffic Parameters for Int-Serv Controlled Load Service 107
10.5.3 Traffic Parameters for CRLDP Service .................. 108
10.5.4 Traffic Parameters for Frame Relay Service ............ 109
10.6 Traffic Controls (TC) Flags ............................... 110
11. Adjacency Protocol .......................................... 111
11.1 Packet Format ............................................. 112
11.2 Procedure ................................................. 115
11.2.1 State Tables .......................................... 117
11.3 Partition Information State ............................... 118
11.4 Loss of Synchronisation.................................... 119
11.5 Multiple Controllers Per Switch Partition ................. 119
11.5.1 Multiple Controller Adjacency Process ................. 120
12. Failure Response Codes ...................................... 121
12.1 Description of Failure and Warning Response Messages ...... 121
12.2 Summary of Failure Response Codes and Warnings ............ 127
13. Security Considerations ..................................... 128
Appendix A Summary of Messages ................................. 129
Appendix B IANA Considerations ................................. 130
References ...................................................... 134
Authors' Addresses .............................................. 136
Full Copyright Statement ........................................ 137
Doria, et. al. Standards Track [Page 3]
RFC 3292 General Switch Management Protocol V3 June 2002
1. Introduction
The General Switch Management Protocol (GSMP) is a general purpose
protocol to control a label 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, request and delete reservation of switch
resources, and request statistics. It also allows the switch to
inform the controller of asynchronous events such as a link going
down. 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. Also a switch may be
controlled by more than one controller by using the technique of
partitioning.
A 'physical' switch can be partitioned into several virtual switches
that are referred to as partitions. In this version of GSMP, switch
partitioning is static and occurs prior to running GSMP. The
partitions of a physical switch are isolated from each other by the
implementation and the controller assumes that the resources
allocated to a partition are at all times available to that
partition. A partition appears to its controller as a label switch.
Throughout the rest of this document, the term switch (or
equivalently, label switch) is used to refer to either a physical,
non-partitioned switch or to a partition. The resources allocated to
a partition appear to the controller as if they were the actual
physical resources of the partition. For example if the bandwidth of
a port were divided among several partitions, each partition would
appear to the controller to have its own independent port.
GSMP controls a partitioned switch through the use of a partition
identifier that is carried in every GSMP message. Each partition has
a one-to-one control relationship with its own logical controller
entity (which in the remainder of the document is referred to simply
as a controller) and GSMP independently maintains adjacency between
each controller-partition pair.
Kinds of label switches include frame or cell switches that support
connection oriented switching, using the exact match-forwarding
algorithm based on labels attached to incoming cells or frames. 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. Cells or labelled
frames arrive at the switch from an external communication link on
Doria, et. al. Standards Track [Page 4]
RFC 3292 General Switch Management Protocol V3 June 2002
incoming labelled channels at an input port. Cells or labelled
frames depart from the switch to an external communication link on
labelled channels from an output port.
A switch may support multiple label types, however, each switch port
can support only one label type. The label type supported by a given
port is indicated by the switch to the controller in a port
configuration message. Connections may be established between ports,
supporting different label types. Label types include ATM, Frame
Relay, MPLS Generic and FEC Labels.
A connection across a switch is formed by connecting an incoming
labelled channel to one or more outgoing labelled channels.
Connections are referenced by the input port on which they originate
and the Label values of their incoming labelled channel.
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 connection is established with a certain quality of
service (QoS). This version of GSMP includes a default QoS
Configuration and additionally allows the negotiation of alternative,
optional QoS configurations. The default QoS Configuration includes
three QoS Models: a Service Model, a Simple Abstract Model (strict
priorities) and a QoS Profile Model.
The Service Model is based on service definitions found external to
GSMP such as in Integrated Services or ATM Service Categories. Each
connection is assigned a specific service that defines the handling
of the connection by the switch. Additionally, traffic parameters
and traffic controls may be assigned to the connection depending on
the assigned service.
In the Simple Abstract Model, a connection is assigned a priority
when it is established. It may be assumed that for connections that
share the same output port, a cell or frame on a connection with a
higher priority is much more likely to exit the switch before a cell
or frame 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.
Doria, et. al. Standards Track [Page 5]
RFC 3292 General Switch Management Protocol V3 June 2002
The QoS Profile Model provides a simple mechanism that allows
connection to be assigned QoS semantics defined externally to GSMP.
The QoS Profile Model can be used to indicate pre-defined
Differentiated Service Per Hop Behaviours (PHBs). Definition of QoS
profiles is outside of the scope of this specification.
All GSMP switches MUST support the default QoS Configuration. A GSMP
switch may additionally support one or more alternative QoS
Configurations. The QoS models of alternative QoS configurations are
defined outside the GSMP specification. GSMP includes a negotiation
mechanism that allows a controller to select from the QoS
configurations that a switch supports.
GSMP contains an adjacency protocol. The adjacency protocol is used
to synchronise states 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
GSMP packets may be transported via any suitable medium. GSMP packet
encapsulations for ATM, Ethernet and TCP are specified in [15].
Additional encapsulations for GSMP packets may be defined in separate
documents.
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
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 six classes of GSMP
request-response message: Connection Management, Reservation
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. The
controller can be required to acknowledge event messages, but by
default does not do so. There is also an adjacency protocol message
used to establish synchronisation 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.
Doria, et. al. Standards Track [Page 6]
RFC 3292 General Switch Management Protocol V3 June 2002
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 opaque sub-fields 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 states synchronised.
Except for the adjacency protocol message, no GSMP messages may be
sent across the link until the adjacency protocol has achieved
synchronisation, and all GSMP messages received on a link that do not
currently have state synchronisation MUST be discarded.
3.1 GSMP Packet Format
3.1.1 Basic GSMP Message format
All GSMP messages, except the adjacency protocol message, have the
following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Message Body ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Doria, et. al. Standards Track [Page 7]
RFC 3292 General Switch Management Protocol V3 June 2002
(The convention in the documentation of Internet Protocols [5] is to
express numbers in decimal. Numbers in hexadecimal format are
specified by prefacing them with the characters '0x'. Numbers in
binary format are specified by prefacing them with the characters
'0b'. Data is pictured in 'big-endian' order. That is, fields are
described left to right, with the most significant byte on the left
and the least significant byte on the right. Whenever a diagram
shows a group of bytes, the order of transmission of those bytes is
the normal order in which they are read in English. Whenever a byte
represents a numeric quantity, the left most bit in the diagram is
the high order or most significant bit. That is, the bit labelled 0
is the most significant bit. Similarly, whenever a multi-byte field
represents a numeric quantity, the left most bit of the whole field
is the most significant bit. When a multi-byte quantity is
transmitted, the most significant byte is transmitted first. This is
the same coding convention as is used in the ATM layer [1] and AAL-5
[2][3].)
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 the following
classes: Connection Management, Reservation Management, Port
Management, State and Statistics, Configuration, Quality of
Service, Events and messages belonging to an Abstract or
Resource Model (ARM) extension. 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 that 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 State 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 was set to 'AckAll'. (This facility
was added to reduce the control traffic in the case where the
Doria, et. al. Standards Track [Page 8]
RFC 3292 General Switch Management Protocol V3 June 2002
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'.)
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. 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.
'More' in the result indicates that the message, either request
or 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.
ReturnReceipt is a result field used in Events to indicate that
an acknowledgement is required for the message. The default
for Events Messages is that the controller will not acknowledge
Events. In the case where a switch requires acknowledgement,
it will set the Result Field to ReturnReceipt in the header of
the Event Message.
The encoding of the result field is:
NoSuccessAck: Result = 1
AckAll: Result = 2
Success: Result = 3
Failure: Result = 4
More: Result = 5
ReturnReceipt Result = 6
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.
Doria, et. al. Standards Track [Page 9]
RFC 3292 General Switch Management Protocol V3 June 2002
Partition ID
Field used to associate the command with a specific switch
partition. The format of the Partition ID is not defined in
GSMP. If desired, the Partition ID can be divided into
multiple sub-identifiers within a single partition. For
example: the Partition ID could be subdivided into a 6-bit
partition number and a 2-bit sub-identifier which would allow a
switch to support 64 partitions with 4 available IDs per
partition.
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.
I flag
If I is set then the SubMessage Number field indicates the
total number of SubMessage segments that compose the entire
message. If it is not set then the SubMessage Number field
indicates the sequence number of this SubMessage segment within
the whole message.
SubMessage Number
When a message is segmented because it exceeds the MTU of the
link layer, each segment will include a submessage number to
indicate its position. Alternatively, if it is the first
submessage in a sequence of submessages, the I flag will be set
and this field will contain the total count of submessage
segments.
Length
Length of the GSMP message including its header fields and
defined GSMP message body. The length of additional data
appended to the end of the standard message SHOULD be included
in the Length field.
Doria, et. al. Standards Track [Page 10]
RFC 3292 General Switch Management Protocol V3 June 2002
3.1.2 Fields commonly found in GSMP messages
The following fields are frequently found in GSMP messages. They are
defined here to avoid repetition.
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, '5: 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.
3.1.2.1 Additional General Message Information
1. 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.
2. Flags that are undefined will be designated as: x: reserved
3. It is not an error for a GSMP message to contain additional data
after the end of the Message Body. This is allowed to support
proprietary and experimental purposes. However, the maximum
transmission unit of the GSMP message, as defined by the data link
layer encapsulation, MUST NOT be exceeded. The length of
additional data appended to the end of the standard message SHOULD
be included in the message length field.
4. A success response message MUST NOT be sent until the requested
operation has been successfully completed.
Doria, et. al. Standards Track [Page 11]
RFC 3292 General Switch Management Protocol V3 June 2002
3.1.3 Labels
All labels in GSMP have a common structure composed of tuples,
consisting of a Type, a Length, and a Value. Such tuples are
commonly known as TLV's, and are a good way of encoding information
in a flexible and extensible format. A label TLV is encoded as a 2
octet field that uses 12 bits to specify a Type and four bits to
specify certain behaviour specified below, followed by a 2 octet
Length field, followed by a variable length Value field.
Additionally, a label field can be composed of many stacked labels
that together constitute the label.
A summary of TLV labels supported in this version of the protocol is
listed below:
TLV Label Type Section Title
--------- ---- -------------
ATM Label 0x100 ATM TLV Labels
FR Label 0x101 Frame Relay TLV Labels
MPLS Gen Label 0x102 MPLS Generic TLV Labels
FEC Label 0x103 FEC TLV Labels
All Labels will be designated as follow:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| Label Type | Label Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Label Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
x: Reserved Flags.
These are generally used by specific messages and will be
defined in those messages.
S: Stacked Label Indicator
Label Stacking is discussed below in section 3.1.3.5
Label Type
A 12-bit field indicating the type of label.
Label Length
A 16-bit field indicating the length of the Label Value field
in bytes.
Doria, et. al. Standards Track [Page 12]
RFC 3292 General Switch Management Protocol V3 June 2002
Label Value
A variable length field that is an integer number of 32 bit
words long. The Label Value field is interpreted according to
the Label Type as described in the following sections.
3.1.3.1 ATM Labels
If the Label Type = ATM Label, the labels MUST be interpreted as an
ATM labels as shown:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| ATM Label (0x100) | Label Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x| VPI | VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 VCI field is not
used.
ATM distinguishes between virtual path connections and virtual
channel connections. 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).
Doria, et. al. Standards Track [Page 13]
RFC 3292 General Switch Management Protocol V3 June 2002
3.1.3.2 Frame Relay Labels
If the TLV Type = FR Label, the labels MUST be interpreted as a Frame
Relay labels as shown:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| FR Label (0x101) | Label Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x| Res |Len| DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Res
The Res field is reserved in [21], i.e., it is not explicitly
reserved by GSMP.
Len
The Len field specifies the number of bits of the DLCI. The
following values are supported:
Len DLCI bits
0 10
2 23
DLCI
DLCI is the binary value of the Frame Relay Label. The
significant number of bits (10 or 23) of the label value is to
be encoded into the Data Link Connection Identifier (DLCI)
field when part of the Frame Relay data link header [13].
3.1.3.3 MPLS Generic Labels
If a port's attribute PortType=MPLS, then that port's labels are for
use on links for which label values are independent of the underlying
link technology. Examples of such links are PPP and Ethernet. On
such links the labels are carried in MPLS label stacks [14]. If the
Label Type = MPLS Generic Label, the labels MUST be interpreted as
Generic MPLS labels as shown:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| MPLS Gen Label (0x102)| Label Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x x x x x| MPLS Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Doria, et. al. Standards Track [Page 14]
RFC 3292 General Switch Management Protocol V3 June 2002
MPLS Label
This is a 20-bit label value as specified in [14], represented
as a 20-bit number in a 4-byte field.
3.1.3.4 FEC Labels
Labels may be bound to Forwarding Equivalence Classes (FECs) as
defined in [18]. A FEC is a list of one or more FEC elements. The
FEC TLV encodes FEC items. In this version of the protocol only,
Prefix FECs are supported. If the Label Type = FEC Label, the labels
MUST be interpreted as Forwarding Equivalence Class Labels as shown:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| FEC Label (0x103) | Label Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ FEC Element 1 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ FEC Element n ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FEC Element
The FEC element encoding depends on the type of FEC element.
In this version of GSMP only, Prefix FECs are supported.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Element Type | Address Family | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Prefix ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Element Type
In this version of GSMP the only supported Element Type is
Prefix FEC Elements. The Prefix FEC Element is a one-octet
value, encoded as 0x02.
Address Family
Two-byte quantity containing a value from ADDRESS FAMILY
NUMBERS in [5], that encodes the address family for the address
prefix in the Prefix field.
Doria, et. al. Standards Track [Page 15]
RFC 3292 General Switch Management Protocol V3 June 2002
Prefix Length
One byte containing the length in bits of the address prefix
that follows. A length of zero indicates a prefix that matches
all addresses (the default destination); in this case the
Prefix itself is zero bytes.
Prefix
An address prefix encoded according to the Address Family
field, whose length, in bits, was specified in the Prefix
Length field.
3.1.3.5 Label Stacking
Label stacking is a technique used in MPLS [14] that allows
hierarchical labelling. MPLS label stacking is similar to, but
subtly different from, the VPI/VCI hierarchy of labels in ATM. There
is no set limit to the depth of label stacks that can be used in
GSMP.
When the Stacked Label Indicator S is set to 1 it indicates that an
additional label field will be appended to the adjacent label field.
For example, a stacked Input Short Label could be designated as
follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ Input Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
** |x|S|x|x| |
+-+-+-+-+ Stacked Input Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
** Note: There can be zero or more Stacked Labels fields (like
those marked **) following an Input or Output Label field. A
Stacked Label follows the previous label field if and only if
the S Flag in the previous label is set.
When a label is extended by stacking, it is treated by the protocol
as a single extended label, and all operations on that label are
atomic. For example, in an add branch message, the entire input
label is switched for the entire output label. Likewise, in Move
Input Branch and Move Output Branch messages, the entire label is
swapped. For that reason, in all messages that designate a label
field, it will be depicted as a single 64-bit field, though it might
be instantiated by many 64-bit fields in practice.
Doria, et. al. Standards Track [Page 16]
RFC 3292 General Switch Management Protocol V3 June 2002
3.1.4 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 failure response message will specify which requests were
successful and which failed. The successful requests may result in
changed state.)
A warning response message is a success response (Result = 3) with
the Code field specifying the warning code. The warning code
specifies a warning that was generated during the successful
operation.
If the switch issues a failure response it MUST choose the most
specific failure code according to the following precedence:
- Invalid Message
- General Message Failure
- Specific Message Failure
A failure response specified in the text defining the message
type.
- Connection Failures
- Virtual Path Connection Failures
- Multicast Failures
- QoS Failures
- General Failures
- Warnings
If multiple failures match in any of the categories, the one that is
listed first should be returned. Descriptions of the Failure
response messages can be found in section 12.
Doria, et. al. Standards Track [Page 17]
RFC 3292 General Switch Management Protocol V3 June 2002
4. Connection Management Messages
4.1 General Message Definitions
Connection management messages are used by the controller to
establish, delete, modify and verify 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reservation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Service Selector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Service Selector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IQS|OQS|P|x|N|O| Adaptation Method |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ Input Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ Output Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Doria, et. al. Standards Track [Page 18]
RFC 3292 General Switch Management Protocol V3 June 2002
When required, the Add Branch, Move Input Branch and Move Output
Branch messages have an additional, variable length data block
appended to the above message. This will be required when
indicated by the IQS and OQS flags (if the value of either is set
to 0b10) and the service selector. The additional data block has
the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input TC Flags|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Traffic Parameters Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Output TC Flags|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Traffic Parameters Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: Fields and Parameters that have been explained in the
description of the general messages will not be explained in
this section. Please refer to section 3.1 for details.
Reservation ID
Identifies the reservation that MUST be deployed for the branch
being added. Reservations are established using reservation
management messages (see Chapter 5). A value of zero indicates
that no Reservation is being deployed for the branch. If a
reservation with a corresponding Reservation ID exists, then
the reserved resources MUST be applied to the branch. If the
numerical value of Reservation ID is greater than the value of
Max Reservations (from the Switch Configuration message), a
failure response is returned indicating '20: Reservation ID out
of Range'. If the value of Input Port differs from the input
port specified in the reservation, or if the value of Output
Port differs from the output port specified in the reservation,
a failure response MUST be returned indicating '21: Mismatched
reservation ports'. If no reservation corresponding to
Reservation ID exists, a failure response MUST be returned
indicating '23: Non-existent reservation ID'.
Doria, et. al. Standards Track [Page 19]
RFC 3292 General Switch Management Protocol V3 June 2002
If a valid Reservation ID is specified and the Service Model is
used (i.e., IQS or OQS=0b10) then the Traffic Parameters Block
may be omitted from the Add Branch message indicating that the
Traffic Parameters specified in the corresponding Reservation
Request message are to be used.
Input Port
Identifies a switch input port.
Input Label
Identifies an incoming labelled channel arriving at the switch
input port indicated by the Input Port field. The value in the
Input Label field MUST be interpreted according to the Label
Type attribute of the switch input port indicated by the Input
Port field.
Input Service Selector
Identifies details of the service specification being used for
the connection. The interpretation depends upon the Input QoS
Model Selector (IQS).
IQS = 00: In this case, the Input Service Selector indicates a
simple priority.
IQS = 01: In this case, the Input Service Selector is an opaque
service profile identifier. The definition of these
service profiles is outside the scope of this
specification. Service Profiles can be used to
indicate pre-defined Differentiated Service Per Hop
Behaviours.
IQS = 10: In this case, the Input Service Selector corresponds
to a Service Spec as defined in Chapter 8.2. When
the value of either IQS or OQS is set to 0b10, then a
Traffic Parameters Block is appended to the message.
IQS = 11: In this case the Input Service Selector corresponds
to an ARM service specification. Definition of ARM
service specifications is outside the scope of this
specification and is determined by the MType as
defined in Chapter 8.1.
Output Port
Identifies a switch output port.
Doria, et. al. Standards Track [Page 20]
RFC 3292 General Switch Management Protocol V3 June 2002
Output Label
Identifies an outgoing labelled channel departing at the switch
output port indicated by the Output Port field. The value in
the Output Label field MUST be interpreted according to the
Label Type attribute of the switch input port indicated by the
Output Port field
Output Service Selector
Identifies details of the service model being used. The
interpretation depends upon the Output QoS Model selector
(OQS).
OQS = 00: In this case the Output Service Selector indicates a
simple priority.
OQS = 01: In this case the Output Service Selector is an opaque
service profile identifier. The definition of these
service profiles is outside the scope of this
specification. Service Profiles can be used to
indicate pre-defined Differentiated Service Per Hop
Behaviours.
OQS = 10: In this case the Output Service Selector corresponds
to a Service Spec as defined in Chapter 8.2. When
the value of either IQS or OQS is set to 0b10 then a
Traffic Parameters Block is appended to the message.
OQS = 11: In this case the Output Service Selector corresponds
to an ARM service specification. Definition of ARM
service specifications is outside the scope of this
specification and is determined by the MType as
defined in Chapter 8.1.
IQS, OQS
Input and Output QoS Model Selector:
The QoS Model Selector is used to specify a QoS Model for the
connection. The values of IQS and OQS determine respectively
the interpretation of the Input Service Selector and the Output
Service Selector, and SHOULD be interpreted as a priority, a
QoS profile, a service specification, or an ARM specification
as shown:
IQS/OQS QoS Model Service Selector
------- --------- ----------------
00 Simple Abstract Model Priority
01 QoS Profile Model QoS Profile
10 Default Service Model Service Specification
11 Optional ARM ARM Specification
Doria, et. al. Standards Track [Page 21]
RFC 3292 General Switch Management Protocol V3 June 2002
P Flag
If the Parameter flag is set it indicates that a single
instance of the Traffic Parameter block is provided. This
occurs in cases where the Input Traffic Parameters are
identical to Output Traffic Parameters.
N Flag
The Null flag is used to indicate a null adaptation method.
This occurs when the branch is connecting two ports of the same
type.
O Flag
The Opaque flag indicates whether the adaptation fields are
opaque, or whether they are defined by the protocol. See the
definition of Adaptation Method below for further information.
Adaptation Method
The adaptation method is used to define the adaptation framing
that may be in use when moving traffic from one port type to
another port type; e.g., from a frame relay port to an ATM
port. The content of this field is defined by the Opaque flag.
If the Opaque flag is set, then this field is defined by the
switch manufacturer and is not defined in this protocol. If
the opaque flag is not set, the field is divided into two 12-
bit fields as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IQS|OQS|P|x|N|O| Input Adaptation | Output Adaptation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Input Adaptation
Adaptation framing method used on incoming connections.
Output Adaptation
Adaptation framing method used on outgoing connections.
Adaptation Types:
0x100 PPP
0x200 FRF.5
0x201 FRF.8
Input and Output TC Flags
TC (Traffic Control) Flags are used in Add Branch, Move Input
Branch and Move Output Branch messages for connections using
the Service Model (i.e., when IQS or OQS=0b10). The TC Flags
field is defined in Section 10.6.
Doria, et. al. Standards Track [Page 22]
RFC 3292 General Switch Management Protocol V3 June 2002
Input and Output Traffic Parameters Block
This variable length field is used in Add Branch, Move Input
Branch and Move Output Branch messages for connections using
the Service Model (i.e., when IQS or OQS=0b10). Traffic
Parameters Block is defined in Section 10.5. The Traffic
Parameters Block may be omitted if a valid, non-zero
Reservation ID is specified, in which case the Traffic
Parameters of the corresponding Reservation Request message are
used. If the P flag is set, then the appended message block
will only include a single traffic parameter block which will
be used for both input and output traffic.
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. 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.
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 and Input Label will establish a
point-to-point connection. The second Add Branch message with the
same Input Port and Input Label fields will convert the connection to
a point-to-multipoint connection with two branches. 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 and Input Label 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 labelled
channel to one or more output labelled channels.
In GSMP 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 label.)
Doria, et. al. Standards Track [Page 23]
RFC 3292 General Switch Management Protocol V3 June 2002
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 states 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.
Doria, et. al. Standards Track [Page 24]
RFC 3292 General Switch Management Protocol V3 June 2002
4.2 Add Branch Message
The Add Branch message is a connection management message used to
establish a connection or to add an additional branch to an existing
connection. It may also be used to check the connection state stored
in the switch. The connection is specified by the Input Port and
Input Label fields. The output branch is specified by the Output
Port and Output Label fields. The quality of service requirements of
the connection are specified by the QoS Model Selector and Service
Selector fields. To request a connection the Add Branch message is:
Message Type = 16
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reservation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Service Selector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Service Selector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IQS|OQS|P|x|N|O| Adaptation Method |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|M|B| |
+-+-+-+-+ Input Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|M|R| |
+-+-+-+-+ Output Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Doria, et. al. Standards Track [Page 25]
RFC 3292 General Switch Management Protocol V3 June 2002
When the value of either IQS or OQS is set to 0b10 then the following
Traffic Parameters Block is appended to the above message:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Input TC Flags |x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Input Traffic Parameters Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Output TC Flags|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Output Traffic Parameters Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: Fields and Parameters that have been explained in the
description of the general connection message will not be
explained in this section. Please refer to section 4.1 for
details.
M: Multicast
Multicast flags are used as a hint for point-to-multipoint or
multipoint-to-point connections in the Add Branch message.
They are not used in any other connection management messages
and in these messages they SHOULD be set to zero. There are
two instances of the M-bit in the Add Branch message; one for
input branch specified by the Input Port and Input Label fields
and one for the output branch specified by the Output Port and
Output Label fields. If set for the input branch (in front of
Input Label field), it indicates that the 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. If set for the output
branch (in front of the Output Label field), it indicates that
the connection is very likely to be a multipoint-to-point
connection. If zero, it indicates that this connection is very
likely to be a point-to-point connection or is unknown.
If M flags are set for input as well as output branches, it
indicates that the connection is very likely to be a
multipoint-to-multipoint connection.
The Multicast flags are 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 or a multipoint-to-point connection and
Doria, et. al. Standards Track [Page 26]
RFC 3292 General Switch Management Protocol V3 June 2002
on such connections it SHOULD be ignored by the receiver.
(Except in cases where the connection replace bit is enabled
and set, the receipt of the second and subsequent Add Branch
messages from the receiver indicates a point-to-multipoint or a
multipoint-to-point connection.) If it is known that this is
the first branch of a point-to-multipoint or a multipoint-to-
point 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 the multicast flag is not
mandatory and may be ignored by the switch. If unused, the
flags SHOULD be set to zero. Some switches use a different
data structure for multicast connections rather than for
point-to-point connections. These flags prevent the switch
from setting up a point-to-point structure for the first branch
of a multicast connection that MUST immediately be deleted and
reconfigured as point-to-multipoint or multipoint-to-point when
the second branch is established.
B: Bi-directional
The Bi-directional 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 Bi-directional flag in an Add Branch message, if set,
requests that two unidirectional connections 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
Label, Output Port and Output Label as specified in the Add
Branch message. The reverse direction is derived by exchanging
the values specified in the Input Port and Input Label fields,
with those of the Output Port and Output Label fields
respectively. Thus, a connection in the reverse direction
originates at the input port specified by the Output Port
field, on the label specified by the Output Label field. It
departs from the output port specified by the Input Port field,
on the label specified by the Input Label field.
The Bi-directional flag is simply a convenience to establish
two unidirectional connections in opposite directions between
the same two ports, with identical Labels, using a single Add
Branch message. In all future messages the two unidirectional
connections MUST be handled separately. There is no bi-
directional 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.
Doria, et. al. Standards Track [Page 27]
RFC 3292 General Switch Management Protocol V3 June 2002
R: Connection Replace
The Connection Replace flag applies only to the Add Branch
message and is not used in any other Connection Management
messages. The R flag is used in cases when creation of
multipoint-to-point connections is undesirable (e.g., POTS
applications where fan-in is meaningless). If the R flag is
set, the new connection replaces any existing connection if the
label is already in use at the same Output Port.
The Connection Replace mechanism allows a single Add Connection
command to function as either a Move Branch message or a
combination of Delete Branch/Add Branch messages. This
mechanism is provided to support existing 64k call handling
applications, such as emulating 64k voice switches.
The use of R flag is optional and MUST be pre-configured in the
Port Management message [see section 6.1] to activate its use.
The R flag MUST NOT be set if it is not pre-configured with the
Port Management message. The switch MUST then return a Failure
Response message: '36: Replace of connection is not activated
on switch'. Information about whether the function is active
or not, can be obtained by using the Port Configuration message
[see section 8.2].
The R flag MUST NOT be set if either the M flag or the B flag
is set. If a switch receives an Add connection request that
has the R flag set with either the B or the M flag set, it MUST
return a failure response message of: '37: Connection
replacement mode cannot be combined with Bi-directional or
Multicast mode'
If the connection specified by the Input Port and Input Label fields
does not already exist, it MUST be established with the single output
branch specified in the request message. If the Bi-directional 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.
If the connection specified by the Input Port and Input Label fields
already exists and the R flag is not set, 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 connection specified by the Input Port and Input Label 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
Doria, et. al. Standards Track [Page 28]
RFC 3292 General Switch Management Protocol V3 June 2002
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. This may be used to reduce the traffic on the
control link for messages that are reasserting a previously
established state. For messages that are reasserting a 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 or frames).
If the connection specified by the Input Port and Input Label fields
already exists, and the Bi-directional Flag in the Flags field is
set, a failure response MUST be returned indicating: '15: Point-to-
point bi-directional connection already exists'.
It should be noted that different switches support multicast in
different ways. There may be a limit to the total number of point-
to-multipoint or multipoint-to-point connections certain switches can
support, and possibly a limit on the maximum number of branches that
a point-to-multipoint or multipoint-to-point connection may specify.
Some switches also impose a limit on the number of different Label
values that may be assigned e.g., 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.1 ATM specific procedures:
To request an ATM virtual path connection the ATM Virtual Path
Connection (VPC) Add Branch message is:
Message Type = 26
An ATM virtual path connection can only be established between ATM
ports, i.e., ports with the 'ATM' Label Type attribute. If an ATM
VPC Add Branch message is received and either the switch input port
specified by the Input Port field or the switch output port specified
by the Output Port field is not an ATM port, a failure response
message MUST be returned indicating, '28: ATM Virtual path switching
is not supported on non-ATM ports'.
If an ATM 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,
'24: ATM virtual path switching is not supported on this input port'.
Doria, et. al. Standards Track [Page 29]
RFC 3292 General Switch Management Protocol V3 June 2002
If an ATM 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 '27: Attempt to add an ATM
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, '26: Attempt to
add an ATM virtual path connection branch to an existing virtual
channel connection'.
4.3 Delete Tree Message
The Delete Tree message is a Connection Management message used to
delete an entire connection. All remaining branches of the
connection are deleted. A connection is defined by the Input Port
and the Input Label fields. The Output Port and Output Label fields
are not used in this message. The Delete Tree message is:
Message Type = 18
If the Result field of the request message is 'AckAll' a success
response message MUST be sent 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.
4.4 Verify Tree Message
The Verify Tree message has been removed from this version of GSMP.
Message Type = 19
If a request message is received with Message Type = 19, a failure
response MUST be returned with the Code field indicating:
'3: The specified request is not implemented on this switch.'.
4.5 Delete All Input Port Message
The Delete All Input Port message is a connection management message
used to delete all connections on a switch input port. All
connections that originate at the specified input port MUST be
deleted. On completion of the operation all dynamically assigned
Label values for the specified port MUST be unassigned, i.e., there
MUST be no connections established in the Label space that GSMP
controls on this port. The Service Selectors, Output Port, Input
Doria, et. al. Standards Track [Page 30]
RFC 3292 General Switch Management Protocol V3 June 2002
Label and Output Label fields are not used in this message. The
Delete All Input Port 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
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 Input Port request.
3: The specified request is not implemented on this switch.
4: One or more of the specified ports does not exist.
5: Invalid Port Session Number.
If any field in a Delete All Input Port message not covered by the
above failure codes is invalid, a failure response MUST be returned
indicating: '2: Invalid request message'. Else, the Delete All Input
Port operation MUST be completed successfully and a success message
returned. No other failure messages are permitted.
4.6 Delete All Output Port Message
The Delete All message is a connection management message used to
delete all connections on a switch output port. All connections that
have the specified output port MUST be deleted. On completion of the
operation all dynamically assigned Label values for the specified
port MUST be unassigned, i.e., there MUST be no connections
established in the Label space that GSMP controls on this port. The
Service Selectors, Input Port, Input Label and Output Label fields
are not used in this message. The Delete All Output Port message is:
Message Type = 21
If the Result field of the request message is 'AckAll', a success
response message MUST be sent upon completion of the operation. 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 Output Port request.
Doria, et. al. Standards Track [Page 31]
RFC 3292 General Switch Management Protocol V3 June 2002
3: The specified request is not implemented on this switch.
4: One or more of the specified ports does not exist.
5: Invalid Port Session Number.
If any field in a Delete All Output Port message not covered by the
above failure codes is invalid, a failure response MUST be returned
indicating: '2: Invalid request message'. Else, the delete all
operation MUST be completed successfully and a success message
returned. No other failure messages are permitted.
4.7 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 channel, 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x| Number of Elements |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Delete Branch Elements ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: Fields and Parameters that have been explained in the
description of the general connection message will not be
explained in this section. Please refer to section 4.1 for
details.
Doria, et. al. Standards Track [Page 32]
RFC 3292 General Switch Management Protocol V3 June 2002
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 a branch to be deleted and has
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error |x|x|x|x|x|x|x|x|x|x|x|x| Element Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ Input Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ Output Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: Fields and Parameters that have been explained in the
description of the general connection message will not be
explained in this section. Please refer to section 4.1 for
details.
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 12, 'Failure
Response Codes'.
All other fields of the Delete Branch Element have the same
definition as specified for the other connection management
messages.
Doria, et. al. Standards Track [Page 33]
RFC 3292 General Switch Management Protocol V3 June 2002
In each Delete Branch Element, a connection is specified by the Input
Port and Input Label fields. The specific branch to be deleted is
indicated by the Output Port and Output Label fields.
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 '10: General Message
Failure' 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.
Doria, et. al. Standards Track [Page 34]
RFC 3292 General Switch Management Protocol V3 June 2002
4.8 Move Output Branch Message
The Move Output Branch message is used to move a branch of an
existing connection from its current output port label to a new
output port label in a single atomic transaction. The Move Output
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Service Selector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Service Selector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IQS|OQS|P|x|N|O| Adaptation Method |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ Input Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ Old Output Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ New Output Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Doria, et. al. Standards Track [Page 35]
RFC 3292 General Switch Management Protocol V3 June 2002
When the value of either IQS or OQS is set to 0b10 then the following
Traffic Parameters Block is appended to the above message:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Input TC Flags |x x x x x x x x x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Input Traffic Parameters Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Output TC Flags|x x x x x x x x x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Output Traffic Parameters Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: Fields and Parameters that have been explained in the
description of the general connection message will not be
explained in this section. Please refer to section 4.1 for
details.
The Move Output Branch message is a connection management message
used to move a single output branch of connection from its current
output port and Output Label, to a new output port and Output Label
on the same connection. None of the connection's other output
branches are modified. When the operation is complete the original
Output Label on the original output port will be deleted from the
connection.
The Move Output Branch message is:
Message Type = 22
For the Move Output Branch message, if the connection specified by
the Input Port and Input Label fields already exists, and the output
branch specified by the Old Output Port and Old Output Label fields
exists as a branch on that connection, the output branch specified by
the New Output Port and New Output Label fields is added to the
connection and the branch specified by the Old Output Port and Old
Output Label 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 Move Output Branch message, if the connection specified by
the Input Port and Input Label fields already exists, but the output
branch specified by the Old Output Port and Old Output Label fields
Doria, et. al. Standards Track [Page 36]
RFC 3292 General Switch Management Protocol V3 June 2002
does not exist as a branch on that connection, a failure response
MUST be returned with the Code field indicating, '12: The specified
branch does not exist'.
4.8.1 ATM Specific Procedures:
The ATM VPC Move Output 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 Output 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 Output 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,
'12: The specified branch does not exist'.
If the virtual channel connection specified by the Input Port and
Input Label 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, '11: 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 and Input
Doria, et. al. Standards Track [Page 37]
RFC 3292 General Switch Management Protocol V3 June 2002
Label 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.
4.9 Move Input Branch Message
The Move Input Branch message is used to move a branch of an existing
connection from its current input port label to a new input port
label in a single atomic transaction. The Move Input Branch
connection management message has the following format for both
request and response messages:
Doria, et. al. Standards Track [Page 38]
RFC 3292 General Switch Management Protocol V3 June 2002
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Service Selector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Service Selector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IQS|OQS|P|x|N|O| Adaptation Method |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ Output Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ Old Input Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ New Input Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Doria, et. al. Standards Track [Page 39]
RFC 3292 General Switch Management Protocol V3 June 2002
When the value of either IQS or OQS is set to 0b10, then the
following Traffic Parameters Block is appended to the above message:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Input TC Flags |x x x x x x x x x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Input Traffic Parameters Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Output TC Flags|x x x x x x x x x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Output Traffic Parameters Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: Fields and Parameters that have been explained in the
description of the general connection message will not be
explained in this section. Please refer to section 4.1 for
details.
The Move Input Branch message is a connection management message used
to move a single input branch of connection from its current input
port and Input Label, to a new input port and Input Label on the same
connection. None of the connection's other input branches are
modified. When the operation is complete, the original Input Label
on the original input port will be deleted from the connection.
The Move Input Branch message is:
Message Type = 23
Doria, et. al. Standards Track [Page 40]
RFC 3292 General Switch Management Protocol V3 June 2002
For the Move Input Branch message, if the connection specified by the
Output Port and Output Label fields already exists, and the input
branch specified by the Old Input Port and Old Input Label fields
exists as a branch on that connection, the input branch specified by
the New Input Port and New Input Label fields is added to the
connection and the branch specified by the Old Input Port and Old
Input Label 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 Input Branch operation has been
completed.
For the Move Input Branch message, if the connection specified by the
Output Port and Output Label fields already exists, but the input
branch specified by the Old Input Port and Old Input Label fields
does not exist as a branch on that connection, a failure response
MUST be returned with the Code field indicating, '12: The specified
branch does not exist'.
4.9.1 ATM Specific Procedures:
The ATM VPC Move Input Branch message is a connection management
message used to move a single input branch of a virtual path
connection from its current input port and input VPI, to a new input
port and input VPI on the same virtual channel connection. None of
the other input branches are modified. When the operation is
complete, the original input VPI on the original input port will be
deleted from the connection.
The VPC Move Input Branch message is:
Message Type = 28
For the VPC Move Input Branch message, if the virtual path connection
specified by the Output Port and Output VPI fields already exists,
and the input branch specified by the Old Input Port and Old Input
VPI fields exists as a branch on that connection, the input branch
specified by the New Input Port and New Input VPI fields is added to
the connection and the branch specified by the Old Input Port and Old
Input 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 Input Branch operation has been
completed.
For the VPC Move Input Branch message, if the virtual path connection
specified by the Output Port and Output VPI fields already exists,
but the input branch specified by the Old Input Port and Old Input
Doria, et. al. Standards Track [Page 41]
RFC 3292 General Switch Management Protocol V3 June 2002
VPI fields does not exist as a branch on that connection, a failure
response MUST be returned with the Code field indicating, '12: The
specified branch does not exist'.
If the virtual channel connection specified by the Output Port and
Output Label fields, or if the virtual path connection specified by
the Output Port and Output VPI fields does not exist, a failure
response MUST be returned with the Code field indicating, '11: The
specified connection does not exist'.
If the input branch specified by the New Input Port, New Input VPI,
and New Input VCI fields for a virtual channel connection, or the
input branch specified by the New Input Port and New Input VPI fields
for a virtual path connection, is already in use by any connection
other than that specified by the Output Port and Output Label fields,
then the resulting input branch will have multiple output branches.
If multiple point-to-point connections share the same input branch,
the result will be a point-to-multipoint connection. If multiple
multipoint-to-point trees share the same input branches, the result
will be a multipoint-to-multipoint connection.
5. Reservation Management Messages
GSMP allows switch resources (e.g., bandwidth, buffers, queues,
labels, etc.) to be reserved for connections before the connections
themselves are established. This is achieved through the
manipulation of Reservations in the switch.
Reservations are hard state objects in the switch that can be created
by the controller by sending a Reservation Request message. Each
Reservation is uniquely identified by an identifying number called a
Reservation ID. Reservation objects can be deleted with the Delete
Reservation message or the Delete All Reservations message. A
reservation object is also deleted when the Reservation is deployed
by specifying a Reservation ID in a valid Add Branch message.
The reserved resources MUST remain reserved until either the
reservation is deployed, in which case the resources are applied to a
branch, or the reservation is explicitly deleted (with a Delete
Reservation message or a Delete All Reservations message), in which
case the resources are freed. Reservations and reserved resources
are deleted if the switch is reset.
A Reservation object includes its Reservation ID plus all the
connection state associated with a branch with the exception that the
branch's input label and/or output label may be unspecified. The
Request Reservation message is therefore almost identical to the Add
Branch message.
Doria, et. al. Standards Track [Page 42]
RFC 3292 General Switch Management Protocol V3 June 2002
The switch establishes the maximum number of reservations it can
store by setting the value of Max Reservations in the Switch
Configuration response message. The switch indicates that it does
not support reservations by setting Max Reservations to 0. The valid
range of Reservation IDs is 1 to Max Reservations).
5.1 Reservation Request Message
The Reservation Request message creates a Reservation in the switch
and reserves switch resources for a connection that may later be
established using an Add Branch message. The Reservation Request
Message is:
Message Type = 70
Doria, et. al. Standards Track [Page 43]
RFC 3292 General Switch Management Protocol V3 June 2002
The Reservation Request message has the following format for the
request message:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reservation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Service Selector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Service Selector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IQS|OQS|P|x|N|O| Adaptation Method |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|M|B| |
+-+-+-+-+ Input Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|M|x| |
+-+-+-+-+ Output Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Doria, et. al. Standards Track [Page 44]
RFC 3292 General Switch Management Protocol V3 June 2002
When the value of either IQS or OQS is set to 0b10 then the following
Traffic Parameters Block is appended to the above message:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Input TC Flags |x x x x x x x x x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Input Traffic Parameters Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Output TC Flags|x x x x x x x x x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Output Traffic Parameters Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: Fields and Parameters that have been explained in the
description of the general connection message will not be
explained in this section. Please refer to section 4.1 for
details.
All the fields of the Reservation Request message have the same
meanings as they do in the Add Branch message with the following
exceptions:
Reservation ID
Specifies the Reservation ID of the Reservation. If the
numerical value of the Reservation ID is greater than the value
of the Max Reservations (from the Switch Configuration
message), a failure response is returned indicating '20: the
Reservation ID out of Range'. If the value of Reservation ID
matches that of an extant Reservation, a failure response is
returned indicating '22: Reservation ID in use'.
Input Label
If a specific input label is specified, then that label is
reserved along with the required resources. If the Input Label
is 0 then the switch reserves the resources, but will not bind
them to a label until the add branch command is given, which
references the Reservation Id. If the input label is 0, then
all stacked labels MUST also be zeroed.
Doria, et. al. Standards Track [Page 45]
RFC 3292 General Switch Management Protocol V3 June 2002
Output Label
If a specific Output Label is specified then that label is
reserved along with the required resources. If the Output
Label is 0 then the switch reserves the resources, but will not
bind them to a label until the add branch command is given
which references the Reservation Id. If the Output Label is 0,
then all stacked labels MUST also be zeroed
When the switch receives a valid Reservation Request it reserves all
the appropriate switch resources needed to establish a branch with
corresponding attributes. If sufficient resources are not available,
a failure response is returned indicating '18: Insufficient
resources'. Other failure responses are as defined for the Add
Branch message.
5.2 Delete Reservation Message
The Delete Reservation message deletes a Reservation object in the
switch and frees the reserved switch resources associated with that
reservation object. The Reservation Request Message is:
Message Type = 71
The Delete Reservation 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reservation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the Reservation ID matches that of an extant Reservation then the
reservation is deleted and corresponding switch resources are freed.
If the numerical value of the Reservation ID is greater than the
value of the Max Reservations (from the Switch Configuration
message), a failure response is returned indicating '20: Reservation
ID out of Range'. If the value of Reservation ID does not match that
of any extant Reservation, a failure response is returned indicating
'23: Non-existent reservation ID'.
Doria, et. al. Standards Track [Page 46]
RFC 3292 General Switch Management Protocol V3 June 2002
5.3 Delete All Reservations Message
The Delete All Reservation message deletes all extant Reservation
objects in the switch and frees the reserved switch resources of
these reservations. The Reservation Request Message is:
Message Type = 72
The Delete All Reservation 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6. Management Messages
6.1 Port Management Message
The Port Management message allows a port to be brought into service,
to be taken out of service, to be set to loop back, reset, or to
change the transmit data rate. 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. The Port Management message MAY also be
used for enabling the replace connection mechanism. The Port
Management message is also used as part of the Event Message flow
control mecha |
