As per Relevance of the word response, we have this rfc below:
Network Working Group A.
Request for Comments: 3292 Lulea University of
Category: Standards Track F.
K.
Nortel
T.
June 2002
General Switch Management Protocol (GSMP) V
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document describes the General Switch Management
Version 3 (GSMPv3). The GSMPv3 is an asymmetric protocol that
one or more external switch controllers to establish and maintain
state of a label switch such as, an ATM, frame relay or MPLS switch
The GSMPv3 allows control of both unicast and multicast
connection state as well as control of switch system resources
QoS features
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
of GSMP is based on their work
In addition to the authors/editors listed in the heading,
members of the GSMP group have made significant contributions to
specification. Among the contributors who have
materially are: Constantin Adam, Clint Bishard, Joachim Buerkle
Torbjorn Hedqvist, Georg Kullgren, Aurel A. Lazar,
Nandikesan, Matt Peters, Hans Sjostrand, Balaji Srinivasan,
Sydir, Chao-Chun Wang
Doria, et. al. Standards Track [Page 1]
RFC 3292 General Switch Management Protocol V3 June 2002
Specification of
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [RFC2119].
Table of
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.
The General Switch Management Protocol (GSMP) is a general
protocol to control a label switch. GSMP allows a controller
establish and release connections across the switch, add and
leaves on a multicast connection, manage switch ports,
configuration information, request and delete reservation of
resources, and request statistics. It also allows the switch
inform the controller of asynchronous events such as a link
down. The GSMP protocol is asymmetric, the controller being
master and the switch being the slave. Multiple switches may
controlled by a single controller using multiple instantiations
the protocol over separate control connections. Also a switch may
controlled by more than one controller by using the technique
partitioning
A "physical" switch can be partitioned into several virtual
that are referred to as partitions. In this version of GSMP,
partitioning is static and occurs prior to running GSMP.
partitions of a physical switch are isolated from each other by
implementation and the controller assumes that the
allocated to a partition are at all times available to
partition. A partition appears to its controller as a label switch
Throughout the rest of this document, the term switch (
equivalently, label switch) is used to refer to either a physical
non-partitioned switch or to a partition. The resources allocated
a partition appear to the controller as if they were the
physical resources of the partition. For example if the bandwidth
a port were divided among several partitions, each partition
appear to the controller to have its own independent port
GSMP controls a partitioned switch through the use of a
identifier that is carried in every GSMP message. Each partition
a one-to-one control relationship with its own logical
entity (which in the remainder of the document is referred to
as a controller) and GSMP independently maintains adjacency
each controller-partition pair
Kinds of label switches include frame or cell switches that
connection oriented switching, using the exact match-
algorithm based on labels attached to incoming cells or frames.
switch is assumed to contain multiple "ports". Each port is
combination of one "input port" and one "output port". Some
requests refer to the port as a whole, whereas other requests
specific to the input port or the output port. Cells or
frames arrive at the switch from an external communication link
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
frames depart from the switch to an external communication link
labelled channels from an output port
A switch may support multiple label types, however, each switch
can support only one label type. The label type supported by a
port is indicated by the switch to the controller in a
configuration message. Connections may be established between ports
supporting different label types. Label types include ATM,
Relay, MPLS Generic and FEC Labels
A connection across a switch is formed by connecting an
labelled channel to one or more outgoing labelled channels
Connections are referenced by the input port on which they
and the Label values of their incoming labelled channel
GSMP supports point-to-point and point-to-multipoint connections.
multipoint-to-point connection is specified by establishing
point-to-point connections, each of them specifying the same
branch. A multipoint-to-multipoint connection is specified
establishing multiple point-to-multipoint trees each of
specifying the same output branches
In general a connection is established with a certain quality
service (QoS). This version of GSMP includes a default
Configuration and additionally allows the negotiation of alternative
optional QoS configurations. The default QoS Configuration
three QoS Models: a Service Model, a Simple Abstract Model (
priorities) and a QoS Profile Model
The Service Model is based on service definitions found external
GSMP such as in Integrated Services or ATM Service Categories.
connection is assigned a specific service that defines the
of the connection by the switch. Additionally, traffic
and traffic controls may be assigned to the connection depending
the assigned service
In the Simple Abstract Model, a connection is assigned a
when it is established. It may be assumed that for connections
share the same output port, a cell or frame on a connection with
higher priority is much more likely to exit the switch before a
or frame on a connection with a lower priority if they are both
the switch at the same time. The number of priorities that each
of the switch supports may be obtained from the port
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
connection to be assigned QoS semantics defined externally to GSMP
The QoS Profile Model can be used to indicate pre-
Differentiated Service Per Hop Behaviours (PHBs). Definition of
profiles is outside of the scope of this specification
All GSMP switches MUST support the default QoS Configuration. A
switch may additionally support one or more alternative
Configurations. The QoS models of alternative QoS configurations
defined outside the GSMP specification. GSMP includes a
mechanism that allows a controller to select from the
configurations that a switch supports
GSMP contains an adjacency protocol. The adjacency protocol is
to synchronise states across the link, to negotiate which version
the GSMP protocol to use, to discover the identity of the entity
the other end of a link, and to detect when it changes
2. GSMP Packet
GSMP packets may be transported via any suitable medium. GSMP
encapsulations for ATM, Ethernet and TCP are specified in [15].
Additional encapsulations for GSMP packets may be defined in
documents
3. Common Definitions and
GSMP is a master-slave protocol. The controller issues
messages to the switch. Each request message indicates whether
response is required from the switch and contains a
identifier to enable the response to be associated with the request
The switch replies with a response message indicating either
successful result or a failure. There are six classes of
request-response message: Connection Management,
Management, Port Management, State and Statistics, Configuration,
Quality of Service. The switch may also generate asynchronous
messages to inform the controller of asynchronous events.
controller can be required to acknowledge event messages, but
default does not do so. There is also an adjacency protocol
used to establish synchronisation across the link and maintain
handshake
For the request-response messages, each message type has a format
the request message and a format for the success response.
otherwise specified a failure response message is identical to
request message that caused the failure, with the Code
indicating the nature of the failure
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
assigns port numbers and it may typically choose to structure the 32
bits into opaque sub-fields that have meaning to the
structure of the switch (e.g., slot, port). In general, a port
the same physical location on the switch will always have the
port number, even across power cycles. The internal structure of
port number is opaque to the GSMP protocol. However, for
purposes of network management such as logging, port naming,
graphical representation, a switch may declare the physical
(physical slot and port) of each port. Alternatively,
information may be obtained by looking up the product identity in
database
Each switch port also maintains a port session number assigned by
switch. A message, with an incorrect port session number MUST
rejected. This allows the controller to detect a link failure and
keep states synchronised
Except for the adjacency protocol message, no GSMP messages may
sent across the link until the adjacency protocol has
synchronisation, and all GSMP messages received on a link that do
currently have state synchronisation MUST be discarded
3.1 GSMP Packet
3.1.1 Basic GSMP Message
All GSMP messages, except the adjacency protocol message, have
following format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
express numbers in decimal. Numbers in hexadecimal format
specified by prefacing them with the characters "0x". Numbers
binary format are specified by prefacing them with the
"0b". Data is pictured in "big-endian" order. That is, fields
described left to right, with the most significant byte on the
and the least significant byte on the right. Whenever a
shows a group of bytes, the order of transmission of those bytes
the normal order in which they are read in English. Whenever a
represents a numeric quantity, the left most bit in the diagram
the high order or most significant bit. That is, the bit labelled 0
is the most significant bit. Similarly, whenever a multi-byte
represents a numeric quantity, the left most bit of the whole
is the most significant bit. When a multi-byte quantity
transmitted, the most significant byte is transmitted first. This
the same coding convention as is used in the ATM layer [1] and AAL-5
[2][3].)
The version number of the GSMP protocol being used in
session. It SHOULD be set by the sender of the message to
GSMP protocol version negotiated by the adjacency protocol
Message
The GSMP message type. GSMP messages fall into the
classes: Connection Management, Reservation Management,
Management, State and Statistics, Configuration, Quality
Service, Events and messages belonging to an Abstract
Resource Model (ARM) extension. Each class has a number
different message types. In addition, one Message Type
allocated to the adjacency protocol
Field in a Connection Management request message, a
Management request message, or a Quality of Service
message that is used to indicate whether a response is
to the request message if the outcome is successful. A
of "NoSuccessAck" indicates that the request message does
expect a response if the outcome is successful, and a value
"AckAll" indicates that a response is expected if the
is successful. In both cases a failure response MUST
generated if the request fails. For State and Statistics,
Configuration request messages, a value of "NoSuccessAck"
the request message is ignored and the request message
handled as if the field was set to "AckAll". (This
was added to reduce the control traffic in the case where
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
correct. If the controller does not use this capability,
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
belong to the same success response will have the
Transaction Identifier. The "Success" result indicates
success response that may be contained in a single message
the final message of a success response spanning
messages
"More" in the result indicates that the message, either
or response, exceeds the maximum transmission unit of the
link and that one or more further messages will be sent
complete the success response
ReturnReceipt is a result field used in Events to indicate
an acknowledgement is required for the message. The
for Events Messages is that the controller will not
Events. In the case where a switch requires acknowledgement
it will set the Result Field to ReturnReceipt in the header
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
Field gives further information concerning the result in
response message. It is mostly used to pass an error code in
failure response but can also be used to give
information in a success response message or an event message
In a request message, the code field is not used and is set
zero. In an adjacency protocol message, the Code field is
to determine the function of the message
Doria, et. al. Standards Track [Page 9]
RFC 3292 General Switch Management Protocol V3 June 2002
Partition
Field used to associate the command with a specific
partition. The format of the Partition ID is not defined
GSMP. If desired, the Partition ID can be divided
multiple sub-identifiers within a single partition.
example: the Partition ID could be subdivided into a 6-
partition number and a 2-bit sub-identifier which would allow
switch to support 64 partitions with 4 available IDs
partition
Transaction
Used to associate a request message with its response message
For request messages, the controller may select any
identifier. For response messages, the transaction
is set to the value of the transaction identifier from
message to which it is a response. For event messages,
transaction identifier SHOULD be set to zero. The
Identifier is not used, and the field is not present, in
adjacency protocol
I
If I is set then the SubMessage Number field indicates
total number of SubMessage segments that compose the
message. If it is not set then the SubMessage Number
indicates the sequence number of this SubMessage segment
the whole message
SubMessage
When a message is segmented because it exceeds the MTU of
link layer, each segment will include a submessage number
indicate its position. Alternatively, if it is the
submessage in a sequence of submessages, the I flag will be
and this field will contain the total count of
segments
Length of the GSMP message including its header fields
defined GSMP message body. The length of additional
appended to the end of the standard message SHOULD be
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
The following fields are frequently found in GSMP messages. They
defined here to avoid repetition
Gives the port number of the switch port to which the
applies
Port Session
Each switch port maintains a Port Session Number assigned
the switch. The port session number of a port
unchanged while the port is continuously in the Available
and the link status is continuously Up. When a port returns
the Available state after it has been Unavailable or in any
the Loopback states, or when the line status returns to the
state after it has been Down or in Test, or after a
cycle, a new Port Session Number MUST be generated.
session numbers SHOULD be assigned using some form of
number
If the Port Session Number in a request message does not
the current Port Session Number for the specified port,
failure response message MUST be returned with the Code
indicating, "5: Invalid port session number". The current
session number for a port may be obtained using a
Configuration or an All Ports Configuration message
3.1.2.1 Additional General Message
1. Any field in a GSMP message that is unused or defined
"reserved" MUST be set to zero by the sender and ignored by
receiver
2. Flags that are undefined will be designated as: x:
3. It is not an error for a GSMP message to contain additional
after the end of the Message Body. This is allowed to
proprietary and experimental purposes. However, the
transmission unit of the GSMP message, as defined by the data
layer encapsulation, MUST NOT be exceeded. The length
additional data appended to the end of the standard message
be included in the message length field
4. A success response message MUST NOT be sent until the
operation has been successfully completed
Doria, et. al. Standards Track [Page 11]
RFC 3292 General Switch Management Protocol V3 June 2002
3.1.3
All labels in GSMP have a common structure composed of tuples
consisting of a Type, a Length, and a Value. Such tuples
commonly known as TLV's, and are a good way of encoding
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
specify certain behaviour specified below, followed by a 2
Length field, followed by a variable length Value field
Additionally, a label field can be composed of many stacked
that together constitute the label
A summary of TLV labels supported in this version of the protocol
listed below
TLV Label Type Section
--------- ---- -------------
ATM Label 0x100 ATM TLV
FR Label 0x101 Frame Relay TLV
MPLS Gen Label 0x102 MPLS Generic TLV
FEC Label 0x103 FEC TLV
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
defined in those messages
S: Stacked Label
Label Stacking is discussed below in section 3.1.3.5
Label
A 12-bit field indicating the type of label
Label
A 16-bit field indicating the length of the Label Value
in bytes
Doria, et. al. Standards Track [Page 12]
RFC 3292 General Switch Management Protocol V3 June 2002
Label
A variable length field that is an integer number of 32
words long. The Label Value field is interpreted according
the Label Type as described in the following sections
3.1.3.1 ATM
If the Label Type = ATM Label, the labels MUST be interpreted as
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
connection) or a virtual path (switched as one or more
channel connections within the virtual path) the VCI field is
used
ATM distinguishes between virtual path connections and
channel connections. The connection management messages apply
to virtual channel connections and virtual path connections. The
Branch and Move Branch connection management messages have
Message Types. One Message Type indicates that a virtual
connection is required, and the other Message Type indicates that
virtual path connection is required. The Delete Branches,
Tree, and Delete All connection management messages have only
single Message Type because they do not need to distinguish
virtual channel connections and virtual path connections.
virtual path connections, neither Input VCI fields nor Output
fields are required. They SHOULD be set to zero by the sender
ignored by the receiver. Virtual channel branches may not be
to an existing virtual path connection. Conversely, virtual
branches may not be added to an existing virtual channel connection
In the Port Configuration message each switch input port may
whether it is capable of supporting virtual path switching (i.e.,
accepting connection management messages requesting virtual
connections).
Doria, et. al. Standards Track [Page 13]
RFC 3292 General Switch Management Protocol V3 June 2002
3.1.3.2 Frame Relay
If the TLV Type = FR Label, the labels MUST be interpreted as a
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Res field is reserved in [21], i.e., it is not
reserved by GSMP
The Len field specifies the number of bits of the DLCI.
following values are supported
Len DLCI
0 10
2 23
DLCI is the binary value of the Frame Relay Label.
significant number of bits (10 or 23) of the label value is
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
If a port's attribute PortType=MPLS, then that port's labels are
use on links for which label values are independent of the
link technology. Examples of such links are PPP and Ethernet.
such links the labels are carried in MPLS label stacks [14]. If
Label Type = MPLS Generic Label, the labels MUST be interpreted
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
This is a 20-bit label value as specified in [14],
as a 20-bit number in a 4-byte field
3.1.3.4 FEC
Labels may be bound to Forwarding Equivalence Classes (FECs)
defined in [18]. A FEC is a list of one or more FEC elements.
FEC TLV encodes FEC items. In this version of the protocol only
Prefix FECs are supported. If the Label Type = FEC Label, the
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
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
In this version of GSMP the only supported Element Type
Prefix FEC Elements. The Prefix FEC Element is a one-
value, encoded as 0x02.
Address
Two-byte quantity containing a value from ADDRESS
NUMBERS in [5], that encodes the address family for the
prefix in the Prefix field
Doria, et. al. Standards Track [Page 15]
RFC 3292 General Switch Management Protocol V3 June 2002
Prefix
One byte containing the length in bits of the address
that follows. A length of zero indicates a prefix that
all addresses (the default destination); in this case
Prefix itself is zero bytes
An address prefix encoded according to the Address
field, whose length, in bits, was specified in the
Length field
3.1.3.5 Label
Label stacking is a technique used in MPLS [14] that
hierarchical labelling. MPLS label stacking is similar to,
subtly different from, the VPI/VCI hierarchy of labels in ATM.
is no set limit to the depth of label stacks that can be used
GSMP
When the Stacked Label Indicator S is set to 1 it indicates that
additional label field will be appended to the adjacent label field
For example, a stacked Input Short Label could be designated
follows
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ Input Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
** |x|S|x|x| |
+-+-+-+-+ Stacked Input Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
** Note: There can be zero or more Stacked Labels fields (
those marked **) following an Input or Output Label field.
Stacked Label follows the previous label field if and only
the S Flag in the previous label is set
When a label is extended by stacking, it is treated by the
as a single extended label, and all operations on that label
atomic. For example, in an add branch message, the entire
label is switched for the entire output label. Likewise, in
Input Branch and Move Output Branch messages, the entire label
swapped. For that reason, in all messages that designate a
field, it will be depicted as a single 64-bit field, though it
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
A failure response message is formed by returning the request
that caused the failure with the Result field in the
indicating failure (Result = 4) and the Code field giving the
code. The failure code specifies the reason for the switch
unable to satisfy the request message
If the switch issues a failure response in reply to a
message, no change should be made to the state of the switch as
result of the message causing the failure. (For request
that contain multiple requests, such as the Delete Branches message
the failure response message will specify which requests
successful and which failed. The successful requests may result
changed state.)
A warning response message is a success response (Result = 3)
the Code field specifying the warning code. The warning
specifies a warning that was generated during the
operation
If the switch issues a failure response it MUST choose the
specific failure code according to the following precedence
- Invalid
- General Message
- Specific Message
A failure response specified in the text defining the
type
- Connection
- Virtual Path Connection
- Multicast
- QoS
- General
-
If multiple failures match in any of the categories, the one that
listed first should be returned. Descriptions of the
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
4.1 General Message
Connection management messages are used by the controller
establish, delete, modify and verify connections across the switch
The Add Branch, Delete Tree, and Delete All connection
messages have the following format, for both request and
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
Branch messages have an additional, variable length data
appended to the above message. This will be required
indicated by the IQS and OQS flags (if the value of either is
to 0b10) and the service selector. The additional data block
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
description of the general messages will not be explained
this section. Please refer to section 3.1 for details
Reservation
Identifies the reservation that MUST be deployed for the
being added. Reservations are established using
management messages (see Chapter 5). A value of zero
that no Reservation is being deployed for the branch. If
reservation with a corresponding Reservation ID exists,
the reserved resources MUST be applied to the branch. If
numerical value of Reservation ID is greater than the value
Max Reservations (from the Switch Configuration message),
failure response is returned indicating "20: Reservation ID
of Range". If the value of Input Port differs from the
port specified in the reservation, or if the value of
Port differs from the output port specified in the reservation
a failure response MUST be returned indicating "21:
reservation ports". If no reservation corresponding
Reservation ID exists, a failure response MUST be
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
used (i.e., IQS or OQS=0b10) then the Traffic Parameters
may be omitted from the Add Branch message indicating that
Traffic Parameters specified in the corresponding
Request message are to be used
Input
Identifies a switch input port
Input
Identifies an incoming labelled channel arriving at the
input port indicated by the Input Port field. The value in
Input Label field MUST be interpreted according to the
Type attribute of the switch input port indicated by the
Port field
Input Service
Identifies details of the service specification being used
the connection. The interpretation depends upon the Input
Model Selector (IQS).
IQS = 00: In this case, the Input Service Selector indicates
simple priority
IQS = 01: In this case, the Input Service Selector is an
service profile identifier. The definition of
service profiles is outside the scope of
specification. Service Profiles can be used
indicate pre-defined Differentiated Service Per
Behaviours
IQS = 10: In this case, the Input Service Selector
to a Service Spec as defined in Chapter 8.2.
the value of either IQS or OQS is set to 0b10, then
Traffic Parameters Block is appended to the message
IQS = 11: In this case the Input Service Selector
to an ARM service specification. Definition of
service specifications is outside the scope of
specification and is determined by the MType
defined in Chapter 8.1.
Output
Identifies a switch output port
Doria, et. al. Standards Track [Page 20]
RFC 3292 General Switch Management Protocol V3 June 2002
Output
Identifies an outgoing labelled channel departing at the
output port indicated by the Output Port field. The value
the Output Label field MUST be interpreted according to
Label Type attribute of the switch input port indicated by
Output Port
Output Service
Identifies details of the service model being used.
interpretation depends upon the Output QoS Model
(OQS).
OQS = 00: In this case the Output Service Selector indicates
simple priority
OQS = 01: In this case the Output Service Selector is an
service profile identifier. The definition of
service profiles is outside the scope of
specification. Service Profiles can be used
indicate pre-defined Differentiated Service Per
Behaviours
OQS = 10: In this case the Output Service Selector
to a Service Spec as defined in Chapter 8.2.
the value of either IQS or OQS is set to 0b10 then
Traffic Parameters Block is appended to the message
OQS = 11: In this case the Output Service Selector
to an ARM service specification. Definition of
service specifications is outside the scope of
specification and is determined by the MType
defined in Chapter 8.1.
IQS,
Input and Output QoS Model Selector
The QoS Model Selector is used to specify a QoS Model for
connection. The values of IQS and OQS determine
the interpretation of the Input Service Selector and the
Service Selector, and SHOULD be interpreted as a priority,
QoS profile, a service specification, or an ARM
as shown
IQS/OQS QoS Model Service
------- --------- ----------------
00 Simple Abstract Model
01 QoS Profile Model QoS
10 Default Service Model Service
11 Optional ARM ARM
Doria, et. al. Standards Track [Page 21]
RFC 3292 General Switch Management Protocol V3 June 2002
P
If the Parameter flag is set it indicates that a
instance of the Traffic Parameter block is provided.
occurs in cases where the Input Traffic Parameters
identical to Output Traffic Parameters
N
The Null flag is used to indicate a null adaptation method
This occurs when the branch is connecting two ports of the
type
O
The Opaque flag indicates whether the adaptation fields
opaque, or whether they are defined by the protocol. See
definition of Adaptation Method below for further information
Adaptation
The adaptation method is used to define the adaptation
that may be in use when moving traffic from one port type
another port type; e.g., from a frame relay port to an
port. The content of this field is defined by the Opaque flag
If the Opaque flag is set, then this field is defined by
switch manufacturer and is not defined in this protocol.
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 framing method used on incoming connections
Output
Adaptation framing method used on outgoing connections
Adaptation Types
0x100
0x200 FRF.5
0x201 FRF.8
Input and Output TC
TC (Traffic Control) Flags are used in Add Branch, Move
Branch and Move Output Branch messages for connections
the Service Model (i.e., when IQS or OQS=0b10). The TC
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
This variable length field is used in Add Branch, Move
Branch and Move Output Branch messages for connections
the Service Model (i.e., when IQS or OQS=0b10).
Parameters Block is defined in Section 10.5. The
Parameters Block may be omitted if a valid, non-
Reservation ID is specified, in which case the
Parameters of the corresponding Reservation Request message
used. If the P flag is set, then the appended message
will only include a single traffic parameter block which
be used for both input and output traffic
For all connection management messages, except the Delete
message, the success response message is a copy of the
message returned with the Result field indicating success. The
field is not used in a connection management success
message
The failure response message is a copy of the request
returned with a Result field indicating failure
Fundamentally, no distinction is made between point-to-point
point-to-multipoint connections. By default, the first Add
message for a particular Input Port and Input Label will establish
point-to-point connection. The second Add Branch message with
same Input Port and Input Label fields will convert the connection
a point-to-multipoint connection with two branches. However,
avoid possible inefficiency with some switch designs, the
Flag is provided. If the controller knows that a new connection
point-to-multipoint when establishing the first branch, it
indicate this in the Multicast Flag. Subsequent Add Branch
with the same Input Port and Input Label fields will add
branches to the point-to-multipoint connection. Use of the
Branch message on a point-to-multipoint connection with two
will result in a point-to-point connection. However, the switch
structure this connection as a point-to-multipoint connection with
single output branch if it chooses. (For some switch designs
structure may be more convenient.) Use of the Delete Branch
on a point-to-point connection will delete the point-to-
connection. There is no concept of a connection with zero
branches. All connections are unidirectional, one input
channel to one or more output labelled channels
In GSMP a multipoint-to-point connection is specified by
multiple point-to-point connections, each of them specifying the
output branch. (An output branch is specified by an output port
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
Port Status of the switch port. Connections may be established
deleted when a switch port is in the Available, Unavailable, or
of the Loopback states. However, all connection states on an
port will be deleted when the port returns to the Available
from any other state, i.e., when a Port Management message
received for that port with the Function field indicating
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
The Add Branch message is a connection management message used
establish a connection or to add an additional branch to an
connection. It may also be used to check the connection state
in the switch. The connection is specified by the Input Port
Input Label fields. The output branch is specified by the
Port and Output Label fields. The quality of service requirements
the connection are specified by the QoS Model Selector and
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
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
description of the general connection message will not
explained in this section. Please refer to section 4.1
details
M:
Multicast flags are used as a hint for point-to-multipoint
multipoint-to-point connections in the Add Branch message
They are not used in any other connection management
and in these messages they SHOULD be set to zero. There
two instances of the M-bit in the Add Branch message; one
input branch specified by the Input Port and Input Label
and one for the output branch specified by the Output Port
Output Label fields. If set for the input branch (in front
Input Label field), it indicates that the connection is
likely to be a point-to-multipoint connection. If zero,
indicates that this connection is very likely to be a point
to-point connection or is unknown. If set for the
branch (in front of the Output Label field), it indicates
the connection is very likely to be a multipoint-to-
connection. If zero, it indicates that this connection is
likely to be a point-to-point connection or is unknown
If M flags are set for input as well as output branches,
indicates that the connection is very likely to be
multipoint-to-multipoint connection
The Multicast flags are only used in the Add Branch
when establishing the first branch of a new connection. It
not required to be set when establishing subsequent branches
a point-to-multipoint or a multipoint-to-point connection
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
and set, the receipt of the second and subsequent Add
messages from the receiver indicates a point-to-multipoint or
multipoint-to-point connection.) If it is known that this
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,
flag SHOULD be zero. The use of the multicast flag is
mandatory and may be ignored by the switch. If unused,
flags SHOULD be set to zero. Some switches use a
data structure for multicast connections rather than
point-to-point connections. These flags prevent the
from setting up a point-to-point structure for the first
of a multicast connection that MUST immediately be deleted
reconfigured as point-to-multipoint or multipoint-to-point
the second branch is established
B: Bi-
The Bi-directional flag applies only to the Add Branch message
In all other Connection Management messages it is not used.
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
forward direction, and one specifying the reverse direction
The forward direction uses the values of Input Port,
Label, Output Port and Output Label as specified in the
Branch message. The reverse direction is derived by
the values specified in the Input Port and Input Label fields
with those of the Output Port and Output Label
respectively. Thus, a connection in the reverse
originates at the input port specified by the Output
field, on the label specified by the Output Label field.
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
two unidirectional connections in opposite directions
the same two ports, with identical Labels, using a single
Branch message. In all future messages the two
connections MUST be handled separately. There is no bi
directional delete message. However, a single Delete
message with two Delete Branch Elements, one for the
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
The Connection Replace flag applies only to the Add
message and is not used in any other Connection
messages. The R flag is used in cases when 