RFC 3292
General Switch Management Protocol (GSMP) V3
Pages: 137
Proposed Standard
Proposed Standard
Part 1 of 5 – Pages 1 to 17
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|S|x|x| Label Type | Label Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Label Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ x: Reserved Flags. These are generally used by specific messages and will be defined in those messages. S: Stacked Label Indicator Label Stacking is discussed below in section 3.1.3.5 Label Type A 12-bit field indicating the type of label. Label Length A 16-bit field indicating the length of the Label Value field in bytes.
Label Value
A variable length field that is an integer number of 32 bit
words long. The Label Value field is interpreted according to
the Label Type as described in the following sections.
3.1.3.1 ATM Labels
If the Label Type = ATM Label, the labels MUST be interpreted as an
ATM labels as shown:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| ATM Label (0x100) | Label Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x| VPI | VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For a virtual path connection (switched as a single virtual path
connection) or a virtual path (switched as one or more virtual
channel connections within the virtual path) the VCI field is not
used.
ATM distinguishes between virtual path connections and virtual
channel connections. The connection management messages apply both
to virtual channel connections and virtual path connections. The Add
Branch and Move Branch connection management messages have two
Message Types. One Message Type indicates that a virtual channel
connection is required, and the other Message Type indicates that a
virtual path connection is required. The Delete Branches, Delete
Tree, and Delete All connection management messages have only a
single Message Type because they do not need to distinguish between
virtual channel connections and virtual path connections. For
virtual path connections, neither Input VCI fields nor Output VCI
fields are required. They SHOULD be set to zero by the sender and
ignored by the receiver. Virtual channel branches may not be added
to an existing virtual path connection. Conversely, virtual path
branches may not be added to an existing virtual channel connection.
In the Port Configuration message each switch input port may declare
whether it is capable of supporting virtual path switching (i.e.,
accepting connection management messages requesting virtual path
connections).
3.1.3.2 Frame Relay Labels
If the TLV Type = FR Label, the labels MUST be interpreted as a Frame Relay labels as shown: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|S|x|x| FR Label (0x101) | Label Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x x x x| Res |Len| DLCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Res The Res field is reserved in [21], i.e., it is not explicitly reserved by GSMP. Len The Len field specifies the number of bits of the DLCI. The following values are supported: Len DLCI bits 0 10 2 23 DLCI DLCI is the binary value of the Frame Relay Label. The significant number of bits (10 or 23) of the label value is to be encoded into the Data Link Connection Identifier (DLCI) field when part of the Frame Relay data link header [13].3.1.3.3 MPLS Generic Labels
If a port's attribute PortType=MPLS, then that port's labels are for use on links for which label values are independent of the underlying link technology. Examples of such links are PPP and Ethernet. On such links the labels are carried in MPLS label stacks [14]. If the Label Type = MPLS Generic Label, the labels MUST be interpreted as Generic MPLS labels as shown: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|S|x|x| MPLS Gen Label (0x102)| Label Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x x x x x x x x x x x x| MPLS Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MPLS Label
This is a 20-bit label value as specified in [14], represented
as a 20-bit number in a 4-byte field.
3.1.3.4 FEC Labels
Labels may be bound to Forwarding Equivalence Classes (FECs) as
defined in [18]. A FEC is a list of one or more FEC elements. The
FEC TLV encodes FEC items. In this version of the protocol only,
Prefix FECs are supported. If the Label Type = FEC Label, the labels
MUST be interpreted as Forwarding Equivalence Class Labels as shown:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| FEC Label (0x103) | Label Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ FEC Element 1 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ FEC Element n ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FEC Element
The FEC element encoding depends on the type of FEC element.
In this version of GSMP only, Prefix FECs are supported.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Element Type | Address Family | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Prefix ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Element Type
In this version of GSMP the only supported Element Type is
Prefix FEC Elements. The Prefix FEC Element is a one-octet
value, encoded as 0x02.
Address Family
Two-byte quantity containing a value from ADDRESS FAMILY
NUMBERS in [5], that encodes the address family for the address
prefix in the Prefix field.
Prefix Length
One byte containing the length in bits of the address prefix
that follows. A length of zero indicates a prefix that matches
all addresses (the default destination); in this case the
Prefix itself is zero bytes.
Prefix
An address prefix encoded according to the Address Family
field, whose length, in bits, was specified in the Prefix
Length field.
3.1.3.5 Label Stacking
Label stacking is a technique used in MPLS [14] that allows
hierarchical labelling. MPLS label stacking is similar to, but
subtly different from, the VPI/VCI hierarchy of labels in ATM. There
is no set limit to the depth of label stacks that can be used in
GSMP.
When the Stacked Label Indicator S is set to 1 it indicates that an
additional label field will be appended to the adjacent label field.
For example, a stacked Input Short Label could be designated as
follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x| |
+-+-+-+-+ Input Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
** |x|S|x|x| |
+-+-+-+-+ Stacked Input Label |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
** Note: There can be zero or more Stacked Labels fields (like
those marked **) following an Input or Output Label field. A
Stacked Label follows the previous label field if and only if
the S Flag in the previous label is set.
When a label is extended by stacking, it is treated by the protocol
as a single extended label, and all operations on that label are
atomic. For example, in an add branch message, the entire input
label is switched for the entire output label. Likewise, in Move
Input Branch and Move Output Branch messages, the entire label is
swapped. For that reason, in all messages that designate a label
field, it will be depicted as a single 64-bit field, though it might
be instantiated by many 64-bit fields in practice.
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.
(next page on part 2)