RFC3292 - 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.
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
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
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
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.
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.
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 ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(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
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.
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.
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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
xSxx 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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
xSxx 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).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
xSxx 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
xSxx MPLS Gen Label (0x102) Label Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
x x x x x x x x x x x x MPLS Label
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
xSxx 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.
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:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
xSxx
+-+-+-+-+ Input Label
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
** xSxx
+-+-+-+-+ 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.
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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IQSOQSPxNO Adaptation Method
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
xSxx
+-+-+-+-+ Input Label
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
xSxx
+-+-+-+-+ Output Label
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Flagsxxxxxxxxxxxxxxxxxxxxxxxx
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~ Traffic Parameters Block ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Output TC Flagsxxxxxxxxxxxxxxxxxxxxxxxx
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~ 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".
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.
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
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:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IQSOQSPxNO 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.
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.)
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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IQSOQSPxNO Adaptation Method
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
xSMB
+-+-+-+-+ Input Label
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
xSMR
+-+-+-+-+ Output Label
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 xxxxxxxxxxxxxxxxxxxxxxxx
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~ Input Traffic Parameters Block ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Output TC Flagsxxxxxxxxxxxxxxxxxxxxxxxx
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~ 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
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.
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
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".
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