Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3292

General Switch Management Protocol (GSMP) V3

Pages: 137
Proposed Standard
Part 1 of 5 – Pages 1 to 17
None   None   Next

Top   ToC   RFC3292 - Page 1
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.
Top   ToC   RFC3292 - Page 2
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
Top   ToC   RFC3292 - Page 3
      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
Top   ToC   RFC3292 - Page 4

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
Top   ToC   RFC3292 - Page 5
   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.
Top   ToC   RFC3292 - Page 6
   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.
Top   ToC   RFC3292 - Page 7
   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 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Top   ToC   RFC3292 - Page 8
   (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
Top   ToC   RFC3292 - Page 9
         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.
Top   ToC   RFC3292 - Page 10
      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.
Top   ToC   RFC3292 - Page 11

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.
Top   ToC   RFC3292 - Page 12

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.
Top   ToC   RFC3292 - Page 13
      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).
Top   ToC   RFC3292 - Page 14
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Top   ToC   RFC3292 - Page 15
      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.
Top   ToC   RFC3292 - Page 16
      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.
Top   ToC   RFC3292 - Page 17

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)

Next Section