tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3292

Proposed STD
Pages: 137
Top     in Index     Prev     Next
in Group Index     No Prev: Lowest Number in Group     Next in Group     Group: GSMP

General Switch Management Protocol (GSMP) V3

Part 1 of 5, p. 1 to 17
None       Next RFC Part

 


Top       ToC       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.

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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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 RFC Part