tech-invite   World Map     

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

RFC 3292

 
 
 

General Switch Management Protocol (GSMP) V3

Part 5 of 5, p. 100 to 137
Prev RFC Part

 


prevText      Top      Up      ToC       Page 100 
10.4  Service Definitions

   This section sets forth the definition of Services.  The following
   Service Identifiers are defined:

         ID          Service Type

         1           CBR= 1
         2           rt-VBR.1
         3           rt-VBR.2
         4           rt-VBR.3
         5           nrt-VBR.1
         6           nrt-VBR.2
         7           nrt-VBR.3
         8           UBR.1
         9           UBR.2
         10-11       Reserved
         12          GFR.1
         13          GFR.2
         14-19       Reserved
         20          Int-Serv Controlled Load

Top      Up      ToC       Page 101 
         21-24       Reserved
         25          MPLS CR-LDP QoS
         26-29       Reserved
         30          Frame Relay Service
         31-49       Reserved
         50-69       Reserved GMPLS
         70-65535    Reserved

   Each Service will be defined in its own subsection.  Each Service
   definition includes the following definitions:

      Service Identifier
         The reference number used to identify the Service in GSMP
         messages.

      Service Characteristics
         A definition of the Service.

      Traffic Parameters
         A definition of the Traffic Parameters used in connection
         management messages.

      QoS Parameters
         A definition of the QoS Parameters that are included in the
         Capability Set for instances of the Service.

      Traffic Controls
         A definition of the Traffic Controls that may be supported by
         an instance of the Service.

   Descriptive text is avoided wherever possible in order to minimise
   any possibility of semantic conflict with the Original
   Specifications.

10.4.1  ATM Forum Service Categories

10.4.1.1  CBR

   Service Identifier:
      CBR.1 - Service ID = 1

   Service Characteristics:
      Equivalent to ATM Forum CBR.1 Service, see [8].

   Traffic Parameters:
      -  Peak Cell Rate
      -  Cell Delay Variation Tolerance

Top      Up      ToC       Page 102 
   QoS Parameters:
      -  Cell Loss Ratio
      -  Maximum Cell Transfer Delay
      -  Peak-to-peak Cell Delay Variation

   Traffic Controls:
      -  (U) Usage Parameter Control
      -  (I) Ingress Traffic Shaping to the Peak Cell Rate
      -  (E) Egress Traffic Shaping to the Peak Cell Rate and Cell Delay
             Variation Tolerance
      -  (D) Packet Discard

10.4.1.2  rt-VBR

   Service Identifier:
      rt-VBR.1 - Service ID = 2
      rt-VBR.2 - Service ID = 3
      rt-VBR.3 - Service ID = 4

   Service Characteristics:
      Equivalent to ATM Forum rt-VBR Service, see [8].

   Traffic Parameters:
      -  Peak Cell Rate
      -  Cell Delay Variation Tolerance
      -  Sustainable Cell Rate
      -  Maximum Burst Size

   QoS Parameters:
      -  Cell Loss Ratio
      -  Maximum Cell Transfer Delay
      -  Peak-to-peak Cell Delay Variation

   Traffic Controls:
      -  (U) Usage Parameter Control
      -  (I) Ingress Traffic Shaping to the Peak Cell Rate
      -  (E) Egress Traffic Shaping to the Peak Cell Rate and Cell Delay
             Variation Tolerance
      -  (S) Egress Traffic Shaping to the Sustainable Cell Rate and
             Maximum Burst Size
      -  (P) Packet Discard
      -  (V) VC Merge

Top      Up      ToC       Page 103 
10.4.1.3  nrt-VBR

   Service Identifier:
      nrt-VBR.1 - Service ID = 5
      nrt-VBR.2 - Service ID = 6
      nrt-VBR.3 - Service ID = 7

   Service Characteristics:
      Equivalent to ATM Forum nrt-VBR Service, see [8].

   Traffic Parameters:
      -  Peak Cell Rate
      -  Cell Delay Variation Tolerance
      -  Sustainable Cell Rate
      -  Maximum Burst Size

   QoS Parameter:
      -  Cell Loss Ratio

   Traffic Controls:
      -  (U) Usage Parameter Control
      -  (I) Ingress Traffic Shaping to the Peak Cell Rate
      -  (E) Egress Traffic Shaping to the Peak Cell Rate and Cell Delay
             Variation Tolerance
      -  (S) Egress Traffic Shaping to the Sustainable Cell Rate and
             Maximum Burst Size
      -  (P) Packet Discard
      -  (V) VC Merge

10.4.1.4  UBR

   Service Identifier:
      UBR.1 - Service ID = 8
      UBR.2 - Service ID = 9

   Service Characteristics:
      Equivalent to ATM Forum UBR Service, see [8].

   Traffic Parameters:
      -  Peak Cell Rate
      -  Cell Delay Variation Tolerance

   QoS Parameter:
      None

   Traffic Controls:
      -  (U) Usage Parameter Control
      -  (I) Ingress Traffic Shaping to the Peak Cell Rate

Top      Up      ToC       Page 104 
      -  (E) Egress Traffic Shaping to the Peak Cell Rate and Cell Delay
             Variation Tolerance
      -  (P) Packet Discard
      -  (V) VC Merge

10.4.1.5  ABR

   ABR is not supported in this version of GSMP.

10.4.1.6  GFR

   Service Identifier:
      GFR.1 - Service ID = 12
      GFR.2 - Service ID = 13

   Service Characteristics:
      Equivalent to ATM Forum GFR Service, see [8].

   Traffic Parameters:
      -  Peak Cell Rate
      -  Cell Delay Variation Tolerance
      -  Minimum Cell Rate
      -  Maximum Burst Size
      -  Maximum Frame Size

   QoS Parameter:
      -  Cell Loss Ratio

   Traffic Controls:
      -  (U) Usage Parameter Control
      -  (I) Ingress Traffic Shaping to the Peak Cell Rate
      -  (E) Egress Traffic Shaping to the Peak Cell Rate and Cell Delay
             Variation Tolerance
      -  (V) VC Merge

10.4.2  Integrated Services

10.4.2.1  Controlled Load

   Service Identifier:
      Int-Serv Controlled Load - Service ID = 20

   Service Characteristics:
      See [9].

Top      Up      ToC       Page 105 
   Traffic Parameters:
      -  Token bucket rate (r)
      -  Token bucket depth (b)
      -  Peak rate (p)
      -  Minimum policed unit (m)
      -  Maximum packet size (M)

   QoS Parameter:
      None.

   Traffic Controls:
      None.

10.4.3  MPLS CR-LDP

   Service Identifier:
      MPLS CR-LDP QoS - Service ID = 25

   Service Characteristics:
      See [10].

   Traffic Parameters:
      -  Peak Data Rate
      -  Peak Burst Size
      -  Committed Data Rate
      -  Committed Burst Size
      -  Excess Burst Size
      -  Weight

   QoS Parameter:
      -  Frequency

   Traffic Controls:
      None currently defined.

10.4.4  Frame Relay

   Service Identifier:
      Frame Relay Service - Service ID = 30

   Service Characteristics:
      Equivalent to Frame Relay Bearer Service, see [11].

   Traffic Parameters:
      -  Committed Information Rate
      -  Committed Burst Rate
      -  Excess Burst Rate

Top      Up      ToC       Page 106 
   QoS Parameters:
      None.

   Traffic Controls:
      -  Usage Parameter Control
      -  Egress Traffic Shaping to the Committed Information Rate and
         Committed Burst Size

10.4.5  DiffServ

   DiffServ is not supported in this version of GSMP.

10.5  Format and encoding of the Traffic Parameters

   Connection management messages that use the GSMP Service Model (i.e.,
   those that have IQS or OQS set to 0b10) include the Traffic
   Parameters Block that specifies the Traffic Parameter values of a
   connection.  The required Traffic Parameters of a given Service are
   given in Section 10.4.  The format and encoding of these parameters
   are given below.

10.5.1  Traffic Parameters for ATM Forum Services

   The Traffic Parameters:

      -  Peak Cell Rate

      -  Cell Delay Variation Tolerance

      -  Sustainable Cell Rate

      -  Maximum Burst Size

      -  Minimum Cell Rate

      -  Maximum Frame Size

   are defined in [8].  These Parameters are encoded as 24-bit unsigned
   integers.  Peak Cell Rate, Sustainable Cell Rate, and Minimum Cell
   Rate are in units of cells per second.  Cell Delay Variation
   Tolerance is in units of microseconds.  Maximum Burst Size and
   Maximum Frame Size are in units of cells.  In GSMP messages, the
   individual Traffic Parameters are encoded as follows:

Top      Up      ToC       Page 107 
    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 x x x x x x x|           24 bit unsigned integer             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The format of the Traffic Parameters Block in connection management
   messages depends on the Service.  It is a sequence of the 32 bit
   words (as shown above) corresponding to the Traffic Parameters as
   specified in the Service Definitions given in Section 10.4.1 in the
   order given there.

10.5.2  Traffic Parameters for Int-Serv Controlled Load Service

   The Traffic Parameters:

      -  Token bucket rate (r)

      -  Token bucket size (b)

      -  Peak rate (p)

   are defined in [9].  They are encoded as 32-bit IEEE single-precision
   floating point numbers.  The Traffic Parameters Token bucket rate (r)
   and Peak rate (p) are in units of bytes per seconds.  The Traffic
   Parameter Token bucket size (b) is in units of bytes.

   The Traffic Parameters:

      -  Minimum policed unit (m)

      -  Maximum packet size (M)

   are defined in [9].  They are encoded as 32 integer in units of
   bytes.

Top      Up      ToC       Page 108 
   The Traffic Parameters Block for the Int-Serv Controlled Load Service
   is as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Token bucket rate (r)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Token bucket size (b)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Peak rate (p)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Minimum policed unit (m)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Maximum packet size (M)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

10.5.3  Traffic Parameters for CRLDP Service

   The Traffic Parameters:

      -  Peak Data Rate

      -  Peak Burst Size

      -  Committed Data Rate

      -  Committed Burst Size

      -  Excess Burst Size

   are defined in [10] to be encoded as a 32-bit IEEE single-precision
   floating point number.  A value of positive infinity is represented
   as an IEEE single-precision floating-point number with an exponent of
   all ones (255) and a sign and mantissa of all zeros.  The values Peak
   Data Rate and Committed Data Rate are in units of bytes per second.
   The values Peak Burst Size, Committed Burst Size and Excess Burst
   Size are in units of bytes.

   The Traffic Parameter

      -  Weight

   is defined in [10] to be an 8-bit unsigned integer indicating the
   weight of the CRLSP.  Valid weight values are from 1 to 255.  The
   value 0 means that weight is not applicable for the CRLSP.

Top      Up      ToC       Page 109 
   The Traffic Parameters Block for the CRLDP Service is as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Peak Data Rate                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Peak Burst Size                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Committed Data Rate                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Committed Burst Size                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Excess Burst Size                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |x x x x x x x x x x x x x x x x x x x x x x x x|    Weight     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

10.5.4  Traffic Parameters for Frame Relay Service

   The Traffic Parameters:

      -  Committed Information Rate

      -  Committed Burst Size

      -  Excess Burst Size

   are defined in [11].  Format and encoding of these parameters for
   frame relay signalling messages are defined in [12].  (Note than in
   [12] the Committed Information Rate is called "Throughput".)  GSMP
   uses the encoding defined in [12] but uses a different format.

   The format of the Traffic Parameters Block for Frame Relay Service is
   as follows:

    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 x x x x x x x x x x x x| Mag |x x x x x|   CIR Multiplier    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |x x x x x x x x x x x x x| Mag |x x|     CBS Multiplier        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |x x x x x x x x x x x x x| Mag |x x|     EBS Multiplier        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 110 
      Mag
         This field is an unsigned integer in the range from 0 to 6.
         The value 7 is not allowed.  Mag is the decimal exponent for
         the adjacent multiplier field (which itself functions as a
         mantissa).

      CIR Multiplier
         This field is an unsigned integer.  It functions as the
         mantissa of the Committed Information Rate Traffic Parameter.

      CBS Multiplier
      EBS Multiplier
         These fields are unsigned integers.  They function as the
         mantissas of the Committed Burst Size and Excess Burst Size
         Traffic Parameters respectively.

   The Traffic Parameter Values are related to their encoding in GSMP
   messages as follows:

      Committed Information Rate = 10^(Mag) * (CIR Multiplier)

      Committed Burst Size = 10^(Mag) * (CBS Multiplier)

      Excess Burst Size = 10^(Mag) * (EBS Multiplier)

10.6  Traffic Controls (TC) Flags

   The TC Flags field in Add Branch messages for connections using the
   Service Model are set by the controller to indicate that specific
   traffic controls are requested for the requested connection.  The TC
   Flags field is shown below:

             0 1 2 3 4 5 6 7
            +-+-+-+-+-+-+-+-+
            |U|D|I|E|S|V|P|x|
            +-+-+-+-+-+-+-+-+

      U: Usage Parameter Control
            When set, this flag indicates that Usage Parameter Control
            is requested.

      D: Packet Discard
            When set, this flag indicates that Packet Discard is
            requested.

Top      Up      ToC       Page 111 
      I: Ingress Shaping
            When set, this flag indicates the availability of Ingress
            Traffic Shaping to the Peak Rate and Delay Variation
            Tolerance is requested.

      E: Egress Shaping, Peak Rate
            When set, this flag indicates that Egress Shaping to the
            Peak Rate and Delay Variation Tolerance is requested.

      S: Egress Traffic Shaping, Sustainable Rate
            When set, this flag indicates that Egress Traffic Shaping to
            the Sustainable Rate and Maximum Burst Size is requested.

      V: VC Merge
            When set, this flag indicates that ATM Virtual Channel Merge
            (i.e., multipoint to point ATM switching with a traffic
            control to avoid AAL5 PDU interleaving) is requested.

      P: Port
            When set indicates that traffic block pertains to Ingress
            Port.

      x: Reserved

   The controller may set (to one) the flag corresponding to the
   requested Traffic Control if the corresponding Traffic Control has
   been indicated in the Service Configuration response message (Section
   8.4) as available for application to connections that use the
   requested Capability Set on a per connection basis.  (The requested
   Capability Set is indicated by the Capability Set ID the least
   significant byte of the Service Selector field of the Add Branch
   message.)  If the Traffic Control has been indicated in the Service
   Configuration response message as either not available in the
   Capability Set or applied to all connections that use the Capability
   Set then the controller sets the flag to zero and the switch ignores
   the flag.

11.  Adjacency Protocol

   The adjacency protocol is used to synchronise state across the link,
   to agree on which version of the protocol to use, to discover the
   identity of the entity at the other end of a link, and to detect when
   it changes.  GSMP is a hard state protocol.  It is therefore
   important to detect loss of contact between switch and controller,
   and to detect any change of identity of switch or controller.  No
   GSMP messages other than those of the adjacency protocol may be sent
   across the link until the adjacency protocol has achieved
   synchronisation.

Top      Up      ToC       Page 112 
11.1  Packet Format

   All GSMP messages belonging to the adjacency protocol have the
   following structure:

    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  |     Timer     |M|     Code    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Sender Name                          |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                         Receiver Name                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Sender Port                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Receiver Port                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | PType | PFlag |               Sender Instance                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |              Receiver Instance                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Version
         In the adjacency protocol the Version field is used for version
         negotiation.  The version negotiation is performed before
         synchronisation is achieved.  In a SYN message the Version
         field always contains the highest version understood by the
         sender.  A receiver receiving a SYN message with a version
         higher than understood will ignore that message.  A receiver
         receiving a SYN message with a version lower than its own
         highest version, but a version that it understands, will reply
         with a SYNACK with the version from the received SYN in its
         GSMP Version field.  This defines the version of the GSMP
         protocol to be used while the adjacency protocol remains
         synchronised.  All other messages will use the agreed version
         in the Version field.

         The version number for the version of the GSMP protocol defined
         by this specification is Version = 3.

      Message Type
         The adjacency protocol is:

            Message Type = 10

Top      Up      ToC       Page 113 
      Timer
         The Timer field is used to inform the receiver of the timer
         value used in the adjacency protocol of the sender.  The timer
         specifies the nominal time between periodic adjacency protocol
         messages.  It is a constant for the duration of a GSMP session.
         The timer field is specified in units of 100ms.

      M-Flag
         The M-Flag is used in the SYN message to indicate whether the
         sender is a master or a slave.  If the M-Flag is set in the SYN
         message, the sender is a master.  If zero, the sender is a
         slave.  The GSMP protocol is asymmetric, the controller being
         the master and the switch being the slave.  The M-Flag prevents
         a master from synchronising with another master, or a slave
         with another slave.  If a slave receives a SYN message with a
         zero M-Flag, it MUST ignore that SYN message.  If a master
         receives a SYN message with the M-Flag set, it MUST ignore that
         SYN message.  In all other messages the M-Flag is not used.

      Code
         Field specifies the function of the message.  Four Codes are
         defined for the adjacency protocol:

                  SYN:     Code = 1
                  SYNACK:  Code = 2
                  ACK:     Code = 3
                  RSTACK:  Code = 4.

      Sender Name
         For the SYN, SYNACK, and ACK messages, is the name of the
         entity sending the message.  The Sender Name is a 48-bit
         quantity that is unique within the operational context of the
         device.  A 48-bit IEEE 802 MAC address, if available, may be
         used for the Sender Name.  If the Ethernet encapsulation is
         used the Sender Name MUST be the Source Address from the MAC
         header.  For the RSTACK message, the Sender Name field is set
         to the value of the Receiver Name field from the incoming
         message that caused the RSTACK message to be generated.

      Receiver Name
         For the SYN, SYNACK, and ACK messages, is the name of the
         entity that the sender of the message believes is at the far
         end of the link.  If the sender of the message does not know
         the name of the entity at the far end of the link, this field
         SHOULD be set to zero.  For the RSTACK message, the Receiver
         Name field is set to the value of the Sender Name field from
         the incoming message that caused the RSTACK message to be
         generated.

Top      Up      ToC       Page 114 
      Sender Port
         For the SYN, SYNACK, and ACK messages, is the local port number
         of the link across which the message is being sent.  For the
         RSTACK message, the Sender Port field is set to the value of
         the Receiver Port field from the incoming message that caused
         the RSTACK message to be generated.

      Receiver Port
         For the SYN, SYNACK, and ACK messages, is what the sender
         believes is the local port number for the link, allocated by
         the entity at the far end of the link.  If the sender of the
         message does not know the port number at the far end of the
         link, this field SHOULD be set to zero.  For the RSTACK
         message, the Receiver Port field is set to the value of the
         Sender Port field from the incoming message that caused the
         RSTACK message to be generated.

      PType
         PType is used to specify if partitions are used and how the
         Partition ID is negotiated.

               Type of partition being requested.
               0 No Partition
               1 Fixed Partition Request
               2 Fixed Partition Assigned

      PFlag
         Used to indicate the type of partition request.

               1 - New Adjacency.
                     In the case of a new adjacency, the state of the
                     switch will be reset.

               2 - Recovered Adjacency.
                     In the case of a recovered adjacency, the state of
                     the switch will remain, and the Switch Controller
                     will be responsible for confirming that the state
                     of the switch matches the desired state.

      Sender Instance
         For the SYN, SYNACK, and ACK messages, is the sender's instance
         number for the link.  It is used to detect when the link comes
         back up after going down or when the identity of the entity at
         the other end of the link changes.  The instance number is a
         24-bit number that is guaranteed to be unique within the recent
         past and to change when the link or node comes back up after
         going down.  Zero is not a valid instance number.  For the
         RSTACK message, the Sender Instance field is set to the value

Top      Up      ToC       Page 115 
         of the Receiver Instance field from the incoming message that
         caused the RSTACK message to be generated.

      Partition ID
         Field used to associate the message with a specific switch
         partition.

      Receiver Instance
         For the SYN, SYNACK, and ACK messages, is what the sender
         believes is the current instance number for the link, allocated
         by the entity at the far end of the link.  If the sender of the
         message does not know the current instance number at the far
         end of the link, this field SHOULD be set to zero.  For the
         RSTACK message, the Receiver Instance field is set to the value
         of the Sender Instance field from the incoming message that
         caused the RSTACK message to be generated.

11.2  Procedure

   The adjacency protocol is described by the following rules and state
   tables.

   The rules and state tables use the following operations:

   o  The "Update Peer Verifier" operation is defined as storing the
      values of the Sender Instance, Sender Port, Sender Name and
      Partition ID fields from a SYN or SYNACK message received from the
      entity at the far end of the link.

   o  The procedure "Reset the link" is defined as:

      1. Generate a new instance number for the link
      2. Delete the peer verifier (set to zero the values of Sender
         Instance, Sender Port, and Sender Name previously stored by the
         Update Peer Verifier operation)
      3. Send a SYN message
      4. Enter the SYNSENT state.

   o  The state tables use the following Boolean terms and operators:

      A    The Sender Instance in the incoming message matches the value
           stored from a previous message by the "Update Peer Verifier"
           operation.

      B    The Sender Instance, Sender Port, Sender Name and Partition
           ID fields in the incoming message match the values stored
           from a previous message by the "Update Peer Verifier"
           operation.

Top      Up      ToC       Page 116 
      C    The Receiver Instance, Receiver Port, Receiver Name and
           Partition ID fields in the incoming message match the values
           of the Sender Instance, Sender Port, Sender Name and
           Partition ID currently sent in outgoing SYN, SYNACK, and ACK
           messages.

      "&&" Represents the logical AND operation

      "||" Represents the logical OR operation

      "!" Represents the logical negation (NOT) operation.

   o  A timer is required for the periodic generation of SYN, SYNACK,
      and ACK messages.  The value of the timer is announced in the
      Timer field.  The period of the timer is unspecified but a value
      of one second is suggested.

      There are two independent events: the timer expires, and a packet
      arrives.  The processing rules for these events are:

         Timer Expires:   Reset Timer
                          If state = SYNSENT Send SYN
                          If state = SYNRCVD Send SYNACK
                          If state = ESTAB   Send ACK

          Packet Arrives:
              If incoming message is an RSTACK:
                  If (A && C && !SYNSENT) Reset the link
                  Else discard the message.
              If incoming message is a SYN, SYNACK, or ACK:
                  Response defined by the following State Tables.
              If incoming message is any other GSMP message and
                  state != ESTAB:
                  Discard incoming message.
                  If state = SYNSENT Send SYN (Note 1)
                  If state = SYNRCVD Send SYNACK (Note 1)

         Note 1: No more than two SYN or SYNACK messages should be sent
         within any time period of length defined by the timer.

   o  State synchronisation across a link is considered to be achieved
      when the protocol reaches the ESTAB state.  All GSMP messages,
      other than adjacency protocol messages, that are received before
      synchronisation is achieved, will be discarded.

Top      Up      ToC       Page 117 
11.2.1  State Tables

  State: SYNSENT

  +====================================================================+
  |    Condition     |                Action               | New State |
  +==================+=====================================+===========+
  |   SYNACK && C    |  Update Peer Verifier; Send ACK     |   ESTAB   |
  +------------------+-------------------------------------+-----------+
  |   SYNACK && !C   |            Send RSTACK              |  SYNSENT  |
  +------------------+-------------------------------------+-----------+
  |       SYN        |  Update Peer Verifier; Send SYNACK  |  SYNRCVD  |
  +------------------+-------------------------------------+-----------+
  |       ACK        |            Send RSTACK              |  SYNSENT  |
  +====================================================================+

  State: SYNRCVD

  +====================================================================+
  |    Condition     |                Action               | New State |
  +==================+=====================================+===========+
  |   SYNACK && C    |  Update Peer Verifier; Send ACK     |   ESTAB   |
  +------------------+-------------------------------------+-----------+
  |   SYNACK && !C   |            Send RSTACK              |  SYNRCVD  |
  +------------------+-------------------------------------+-----------+
  |       SYN        |  Update Peer Verifier; Send SYNACK  |  SYNRCVD  |
  +------------------+-------------------------------------+-----------+
  |  ACK && B && C   |              Send ACK               |   ESTAB   |
  +------------------+-------------------------------------+-----------+
  | ACK && !(B && C) |            Send RSTACK              |  SYNRCVD  |
  +====================================================================+

  State: ESTAB

  +====================================================================+
  |    Condition     |                Action               | New State |
  +==================+=====================================+===========+
  |  SYN || SYNACK   |           Send ACK (note 2)         |   ESTAB   |
  +------------------+-------------------------------------+-----------+
  |  ACK && B && C   |           Send ACK (note 3)         |   ESTAB   |
  +------------------+-------------------------------------+-----------+
  | ACK && !(B && C) |              Send RSTACK            |   ESTAB   |
  +====================================================================+

Top      Up      ToC       Page 118 
         Note 2: No more than two ACKs should be sent within any time
         period of length defined by the timer.  Thus, one ACK MUST be
         sent every time the timer expires.  In addition, one further
         ACK may be sent between timer expirations if the incoming
         message is a SYN or SYNACK.  This additional ACK allows the
         adjacency protocol to reach synchronisation more quickly.

         Note 3: No more than one ACK should be sent within any time
         period of length defined by the timer.

11.3  Partition Information State

   Each instance of a [switch controller-switch partition] pair will
   need to establish adjacency synchronisation independently.

   Part of the process of establishing synchronisation when using
   partition will be to establish the assignment of partition
   identifiers.  The following scenarios are provided for:

      -  A controller can request a specific partition ID by setting the
         PType to Fixed Partition Request.

      -  A controller can let the switch decide whether it wants to
         assign a fixed partition ID or not, by setting the PType to No
         Partition.

      -  A switch can assign the specific Partition ID to the session by
         setting the PType to Fixed Partition Assigned.  A switch can
         specify that no partitions are handled in the session by
         setting the PType to No Partition.

   The assignment is determined by the following behaviour:

      -  An adjacency message from a controller with PType = 1 and
         Code = SYN SHOULD be treated as a partition request.

      -  An adjacency message from a switch with PType = 2 and
         Code = SYN SHOULD be treated as a partition assignment.

      -  An adjacency message from a controller or a switch with
         PType = 2 and Code = (SYNACK || ACK) SHOULD be treated as a
         success response, the partition is assigned.

      -  An adjacency message from a controller with PType = 0 and
         Code = SYN indicates that the controller has not specified if
         it requests partitions or not.

Top      Up      ToC       Page 119 
      -  An adjacency message from a switch with PType = 0 and
         Code = SYN indicates that the switch does not support
         partitions.

      -  An adjacency message from a controller or a switch with
         PType = 0 and Code = (SYNACK || ACK) indicates that the session
         does not support partitions.

      -  An adjacency message from a controller or a switch with
         PType = (1 || 2) and Code = RSTACK indicates that requested
         Partition ID is unavailable.

      -  An adjacency message from a controller or a switch with
         PType = 0 and Code = RSTACK indicates that an unidentified
         error has occurred.  The session SHOULD be reset.

      All other combinations of PType and Code are undefined in this
      version of GSMP.

11.4  Loss of Synchronisation

   If after synchronisation is achieved, no valid GSMP messages are
   received in any period of time in excess of three times the value of
   the Timer field announced in the incoming adjacency protocol
   messages, loss of synchronisation may be declared.

   While re-establishing synchronisation with a controller, a switch
   SHOULD maintain its connection state, deferring the decision about
   resetting the state until after synchronisation is re-established.

   Once synchronisation is re-established the decision about resetting
   the connection state SHOULD be made on the following basis:

      -  If PFLAG = 1, then a new adjacency has been established and the
         state SHOULD be reset

      -  If PFLAG = 2, then adjacency has been re-established and the
         connection state SHOULD be retained.  Verification that
         controller and connection state are the same is the
         responsibility of the controller.

11.5  Multiple Controllers per switch partition

   Multiple switch controllers may jointly control a single switch
   partition.  The controllers may control a switch partition either in
   a primary/standby fashion or as part of multiple controllers
   providing load-sharing for the same partition.  It is the
   responsibility of the controllers to co-ordinate their interactions

Top      Up      ToC       Page 120 
   with the switch partition.  In order to assist the controllers in
   tracking multiple controller adjacencies to a single switch
   partition, the Adjacency Update message is used to inform a
   controller that there are other controllers interacting with the same
   partition.  It should be noted that the GSMP does not include
   features that allow the switch to co-ordinate cache synchronization
   information among controllers.  The switch partition will service
   each command it receives in turn as if it were interacting with a
   single controller.  Controller implementations without controller
   entity synchronisation SHOULD NOT use multiple controllers with a
   single switch partition.

11.5.1  Multiple Controller Adjacency Process

   The first adjacency for a specific partition is determined by the
   procedures described in section 11.2 and an Adjacency Update message
   will be sent.  The next adjacencies to the partition are identified
   by a new partition request with the same Partition ID as the first
   one but with the different Sender Name.  Upon establishing adjacency
   the Adjacency count will be increased and an Adjacency Update message
   will be sent.

   When adjacency between one partition and a controller is lost, the
   adjacency count will be decremented and an Adjacency Update message
   will be sent.

   Example:

   A switch partition has never been used.  When the first controller
   (A) achieves adjacency, an adjacency count will be initiated and (A)
   will get an Adjacency Update message about itself with Code field =
   1.  Since (A) receives an adjacency count of 1 this indicates that it
   is the only controller for that partition.

   When a second adjacency (B), using the same Partition ID, achieves
   adjacency, the adjacency counter will be increased by 1.  Both (A)
   and (B) will receive an Adjacency Update message indicating an
   adjacency count of 2 in the Code field.  Since the count is greater
   than 1, this will indicate to both (A) and (B) that there is another
   controller interacting with the switch; identification of the other
   controller will not be provided by GSMP, but will be the
   responsibility of the controllers.

   If (A) looses adjacency, the adjacency count will be decreased and an
   Adjacency Update message will be sent to (B) indicating an adjacency
   count of 1 in the Code field.  If (B) leaves as well, the partition
   is regarded as idle and the adjacency count may be reset.

Top      Up      ToC       Page 121 
12.  Failure Response Codes

12.1  Description of Failure and Warning 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.

   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 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 a
   changed state.)

   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 following categories, the
   one that is listed first should be returned.  The following failure
   response messages and failure and warning codes are defined:

Top      Up      ToC       Page 122 
   Invalid Message

      3:  The specified request is not implemented on this switch.
              The Message Type field specifies a message that is not
              implemented on the switch or contains a value that is not
              defined in the version of the protocol running in this
              session of GSMP.

      4:  One or more of the specified ports does not exist.
              At least one of the ports specified in the message is
              invalid.  A port is invalid if it does not exist or if it
              has been removed from the switch.

      5:  Invalid Port Session Number.
              The value given in the Port Session Number field does not
              match the current Port Session Number for the specified
              port.

      7: Invalid Partition ID
              The value given in the Partition ID field is not legal for
              this partition.

   General Message Failure

      10: The meaning of this failure is dependent upon the
              particular message type and is specified in the text
              defining the message.

   Specific Message Failure - A failure response that is only used by a
              specific message type

   -  Failure response messages used by the Label Range message

      40: Cannot support one or more requested label ranges.

      41: Cannot support disjoint label ranges.

      42: Specialised multipoint labels not supported.

   -  Failure response messages used by the Set Transmit Data Rate
              function of the Port Management message

      43: The transmit data rate of this output port cannot be changed.

Top      Up      ToC       Page 123 
      44: Requested transmit data rate out of range for this output
              port.
              The transmit data rate of the requested output port can be
              changed, but the value of the Transmit Data Rate field is
              beyond the range of acceptable values.

   -  Failure response message of the Port Management message

      45: Connection Replace mechanism not supported on switch.
              The R-flag SHOULD be reset in the Response Port Management
              message.

   -  Failure response message range reserved for the ARM extension

      128-159: These failure response codes will be interpreted
              according to definitions provided by the model
              description.

   Connection Failures

      11:  The specified connection does not exist.
              An operation that expects a connection to be specified
              cannot locate the specified connection.  A connection is
              specified by the input port and input label on which it
              originates.  An ATM virtual path connection is specified
              by the input port and input VPI on which it originates.

      12:  The specified branch does not exist.
              An operation that expects a branch of an existing
              connection to be specified cannot locate the specified
              branch.  A branch of a connection is specified by the
              connection it belongs to and the output port and output
              label on which it departs.  A branch of an ATM virtual
              path connection is specified by the virtual path
              connection it belongs to and the output port and output
              VPI on which it departs.

      13: One or more of the specified Input Labels is invalid.

      14: One or more of the specified Output Labels is invalid.

      15: Point-to-point bi-directional connection already exists.
              The connection specified by the Input Port and Input Label
              fields already exists, and the bi-directional Flag in the
              Flags field is set.

Top      Up      ToC       Page 124 
      16: Invalid Service Selector field in a Connection Management
              message.  The value of the Service Selector field is
              invalid.

      17: Insufficient resources for QoS Profile.
              The resources requested by the QoS Profile in the Service
              Selector field are not available.

      18: Insufficient Resources.
              Switch resources needed to establish a branch are not
              available.

      20: Reservation ID out of Range
              The numerical value of Reservation ID is greater than the
              value of Max Reservations (from the Switch Configuration
              message).

      21: Mismatched reservation ports
              The value of Input Port differs from the input port
              specified in the reservation or the value of Output Port
              differs from the output port specified in the reservation.

      22: Reservation ID in use
              The value of Reservation ID matches that of an extant
              Reservation.

      23: Non-existent reservation ID
              No reservation corresponding to Reservation ID exists.

      36: Replace of connection is not activated on switch.
              Only applicable for Add Branch messages.  The Replace
              Connection mechanism has not been activated on port by the
              Port Management message.

      37: Connection replacement mode cannot be combined with Bi-
              directional or Multicast mode.  The R flag MUST NOT be
              used in conjunction with either the M flag or the B flag.

   ATM Virtual Path Connections

      24: ATM virtual path switching is not supported on this input
              port.

Top      Up      ToC       Page 125 
      25: Point-to-multipoint ATM virtual path connections are not
              supported on either the requested input port or the
              requested output port.
              One or both of the requested input and output ports is
              unable to support point-to-multipoint ATM virtual path
              connections.

      26: Attempt to add an ATM virtual path connection branch to an
              existing virtual channel connection.
              It is invalid to mix branches switched as virtual channel
              connections with branches switched as ATM virtual path
              connections on the same point-to-multipoint connection.

      27: Attempt to add an ATM virtual channel connection branch to an
              existing ATM virtual path connection.
              It is invalid to mix branches switched as virtual channel
              connections with branches switched as ATM virtual path
              connections on the same point-to-multipoint connection.

      28: ATM Virtual path switching is not supported on non-ATM ports.
              One or both of the requested input and output ports is not
              an ATM port.  ATM virtual path switching is only supported
              on ATM ports.

   Multicast Failures

      29: A branch belonging to the specified point-to-multipoint
              connection is already established on the specified output
              port and the switch cannot support more than a single
              branch of any point-to-multipoint connection on the same
              output port.

      30: The limit on the maximum number of multicast connections that
              the switch can support has been reached.

      31: The limit on the maximum number of branches that the specified
              multicast connection can support has been reached.

      32: Cannot label each output branch of a point-to-multipoint tree
              with a different label.
              Some switch designs, require all output branches of a
              point-to-multipoint connection to use the same value of
              Label.

      33: Cannot add multi-point branch to bi-directional connection.
              It is an error to attempt to add an additional branch to
              an existing connection with the bi-directional flag set.

Top      Up      ToC       Page 126 
      34: Unable to assign the requested Label value to the requested
              branch on the specified multicast connection.
              Although the requested Labels are valid, the switch is
              unable to support the request using the specified Label
              values for some reason not covered by the above failure
              responses.  This message implies that a valid value of
              Labels exists that the switch could support.  For example,
              some switch designs restrict the number of distinct Label
              values available to a multicast connection.  (Most switch
              designs will not require this message.)

      35: General problem related to the manner in which multicast is
              supported by the switch.
              Use this message if none of the more specific multicast
              failure messages apply.  (Most switch designs will not
              require this message.)

   QoS Failures

      60-79: These failure response codes will be interpreted according
              to definitions provided by the model description.

      80: Switch does not support different QoS parameters for different
              branches within a multipoint connection.

   General Failures

      2:  Invalid request message.
              There is an error in one of the fields of the message not
              covered by a more specific failure message.

      6:  One or more of the specified ports is down.
              A port is down if its Port Status is Unavailable.
              Connection Management, Connection State, Port Management,
              and Configuration operations are permitted on a port that
              is Unavailable.  Connection Activity and Statistics
              operations are not permitted on a port that is Unavailable
              and will generate this failure response.  A Port
              Management message specifying a Take Down function on a
              port already in the Unavailable state will also generate
              this failure response.

      19: Out of resources.
              The switch has exhausted a resource not covered by a more
              specific failure message, for example, running out of
              memory.

Top      Up      ToC       Page 127 
      1:  Unspecified reason not covered by other failure codes.
              The failure message of last resort.

   Warnings

      46: One or more labels are still used in the previous Label Range.

12.2  Summary of Failure Response Codes and Warnings

   The following list gives a summary of the failure codes defined for
   failure response messages:

       1: Unspecified reason not covered by other failure codes.
       2: Invalid request message.
       3: The specified request is not implemented on this switch.
       4: One or more of the specified ports does not exist.
       5: Invalid Port Session Number.
       6: One or more of the specified ports is down.
       7: Invalid Partition ID.
      10: General message failure.  (The meaning of this failure code
            depends upon the Message Type.  It is defined within the
            description of any message that uses it.)
      11: The specified connection does not exist.
      12: The specified branch does not exist.
      13: One or more of the specified Input Labels is invalid.
      14: One or more of the specified Output Labels is invalid.
      15: Point-to-point bi-directional connection already exists.
      16: Invalid service selector field in a connection management
            message.
      17: Insufficient resources for QoS profile.
      18: Insufficient resources.
      19: Out of resources (e.g., memory exhausted, etc.).
      20: Reservation ID out of Range
      21: Mismatched reservation ports
      22: Reservation ID in use
      23: Non-existent reservation ID
      24: ATM virtual path switching is not supported on this input
            port.
      25: Point-to-multipoint ATM virtual path connections are not
            supported on either the requested input port or the
            requested output port.
      26: Attempt to add an ATM virtual path connection branch to an
            existing virtual channel connection.
      27: Attempt to add an ATM virtual channel connection branch to
            an existing virtual path connection.
      28: ATM Virtual Path switching is not supported on non-ATM
            ports.

Top      Up      ToC       Page 128 
      29: A branch belonging to the specified point-to-multipoint
            connection is already established on the specified
            output port and the switch cannot support more than a
            single branch of any point-to-multipoint connection on
            the same output port.
      30: The limit on the maximum number of point-to-multipoint
            connections that the switch can support has been
            reached.
      31: The limit on the maximum number of branches that the
            specified point-to-multipoint connection can support has
            been reached.
      32: Cannot label each output branch of a point-to-multipoint
            tree with a different label.
      33: Cannot add multi-point branch to bi-directional
            connection.
      34: Unable to assign the requested Label value to the
            requested branch on the specified point-to-multipoint
            connection.
      35: General problem related to the manner in which point-to-
            multipoint is supported by the switch.
      36: Replace of connection is not activated on switch.
      37: Connection replacement mode cannot be combined with Bi-
            directional or Multicast mode.
      40: Cannot support one or more requested label ranges.
      41: Cannot support disjoint label ranges.
      42: Specialised multipoint labels not supported.
      43: The transmit data rate of this output port cannot be
            changed.
      44: Requested transmit data rate out of range for this output
            port.
      45: Connection Replace mechanism not supported on switch.
      46: Labels are still used in the existing Label Range.
      60-79: Reserved for QoS failures.
      80: Switch does not support different QoS parameters for
            different branches within a multipoint connection.
      128-159: Reserved for the ARM extensions.

13.  Security Considerations

   The security of GSMP's TCP/IP control channel has been addressed in
   [15].  For all uses of GSMP over an IP network it is REQUIRED that
   GSMP be run over TCP/IP using the security considerations discussed
   in [15].

Top      Up      ToC       Page 129 
Appendix A  Summary of Messages

   Message Name                      Message Number  Status

   Connection Management Messages
       Add Branch .......................16
          ATM Specific - VPC.............26
       Delete Tree.......................18
       Verify Tree.......................19          Obsoleted
       Delete All Input..................20
       Delete All Output.................21
       Delete Branches...................17
       Move Output Branch................22
           ATM Specific - VPC............27
       Move Input Branch.................23
           ATM Specifc  - VPC............28

   Port Management Messages
       Port Management...................32
       Label Range.......................33

   State and Statistics Messages
       Connection Activity...............48
       Port Statistics...................49
       Connection Statistics.............50
       QoS Class Statistics..............51          Reserved
       Report Connection State...........52

   Configuration Messages
       Switch Configuration..............64
       Port Configuration................65
       All Ports Configuration...........66
       Service Configuration.............67

   Reservation Messages
       Reservation Request...............70
       Delete Reservation................71
       Delete All Reservations...........72

   Event Messages
       Port Up...........................80
       Port Down.........................81
       Invalid Label.....................82
       New Port..........................83
       Dead Port.........................84

Top      Up      ToC       Page 130 
   Abstract and Resource Model Extension Messages
       Reserved..........................200-249

   Adjacency Protocol....................10          Required

Appendix B  IANA Considerations

   Following the policies outlined in "Guidelines for Writing an IANA
   Considerations Section in RFCs" (RFC 2434 [19]), the following name
   spaces are defined in GSMPv3.

      -  Message Type Name Space [Appendix A]

      -  Label Type Name Space [3.1.3]

      -  Result Name Space [3.1.1]

      -  Failure Response Message Name Space [3.1.4],[11]

      -  Adaptation Type Name Space [4.1]

      -  Model Type Name Space [8.1]

      -  Port Type Name Space [8.2]

      -  Service ID Name Space [10.4]

      -  Traffic Control Name Space [8.4]

      -  Event Flag Name Space [6.1]

B.1. Message Type Name Space

   GSMPv3 divides the name space for Message Types into four ranges.
   The following are the guidelines for managing these ranges.

      -  Message Types 0-99.
              Message Types in this range are part of the GSMPv3 base
              protocol.  Message types in this range are allocated
              through an IETF consensus action [19].

      -  Message Types 100-199.
              Message Types in this range are Specification Required
              [19].  Message Types using this range must be documented
              in an RFC or other permanent and readily available
              references.

Top      Up      ToC       Page 131 
      -  Message Types 200-249.
              Message Types in this range are Specification Required
              [19] and are intended for Abstract and Resource Model
              Extension Messages.  Message Types using this range must
              be documented in an RFC or other permanent and readily
              available references.

      -  Message Types 250-255.
              Message Types in this range are reserved for vendor
              private extensions and are the responsibility of
              individual vendors.  IANA management of this range of the
              Message Type Name Space is unnecessary.

B.2. Label Type Name Space

   GSMPv3 divides the name space for Label Types into three ranges.  The
   following are the guidelines for managing these ranges.

      -  Label Types 0x000-0xAFF.
              Label Types in this range are part of the GSMPv3 base
              protocol.  Label Types in this range are allocated through
              an IETF consensus action [19].

      -  Label Types 0xB00-0xEFF.
              Label Types in this range are Specification Required [19].
              Label Types using this range must be documented in an RFC
              or other permanent and readily available reference.

      -  Label Types 0xF00-0xFFF.
              Label Types in this range are reserved for vendor private
              extensions and are the responsibility of individual
              vendors.  IANA management of this range of the Label Type
              Name Space is unnecessary.

B.3. Result Name Space

   The following is the guideline for managing the Result Name Space:

      -  Result values 0-255.
              Result values in this range need an expert review, i.e.,
              approval by a Designated Expert is required [19].

B.4. Failure Response Name Space

   GSMPv3 divides the name space for Failure Responses into three
   ranges.  The following are the guidelines for managing these ranges:

Top      Up      ToC       Page 132 
      -  Failure Responses 0-59, 80-127, 160-255.
              Failure responses in these ranges are part of the GSMPv3
              base protocol.  Failure Responses in these ranges are
              allocated through an IETF consensus action [19].

      -  Failure Responses 60-79, 128-159.
              Failure responses in these ranges are reserved for vendor
              private extensions and are the responsibility of
              individual vendors.  IANA management of these ranges of
              the Failure Response Name Space are unnecessary.

B.5. Adaptation Type Name Space

   GSMPv3 divides the name space for Adaptation Types into two ranges.
   The following are the guidelines for managing these ranges:

      -  Adaptation Type 0x000-0x2FF.
              Adaptation Types in this range are part of the GSMPv3 base
              protocol.  Adaptation Types in this range are allocated
              through an IETF consensus action [19].

      -  Adaptation Type 0x300-0xFFF.
              Adaptation Types in this range are allocated by the first
              come first served principle [19].

B.6. Model Type Name Space

   GSMPv3 divides the name space for Model Types into three ranges.  The
   following are the guidelines for managing these ranges:

      -  Model Type 0.
              Model Types in this range are part of the GSMPv3 base
              protocol.  Model Types in this range are allocated through
              an IETF consensus action [19].

      -  Model Type 1-200.
              Model Types in this range are Specification Required [19].
              Message Types using this range must be documented in an
              RFC or other permanent and readily available references.

      -  Model Type 201-255.
              Model Types in this range are reserved for vendor private
              extensions and are the responsibility of individual
              vendors.  IANA management of these ranges of the Model
              Type Name Space are unnecessary.

Top      Up      ToC       Page 133 
B.7. Port Type Name Space

   GSMPv3 divides the name space for Port Types into two ranges.  The
   following are the guidelines for managing these ranges:

      -  Port Type 0-127.
              Port Types in this range are part of the GSMPv3 base
              protocol.  Port Types in this range are allocated through
              an IETF consensus action [19].

      -  Port Type 128-255.
              Port Types in this range are Specification Required [19].
              Port Types using this range must be documented in an RFC
              or other permanent and readily available references.

B.8. Service ID Name Space

   GSMPv3 divides the name space for Service IDs into two ranges.  The
   following are the guidelines for managing these ranges:

      -  Service ID 0-1023.
              Service ID's in this range are part of the GSMPv3 base
              protocol.  Service ID's in this range are allocated
              through an IETF consensus action [19].

      -  Service ID 1024-65535.
              Service ID's in this range are Specification Required
              [19].  Service ID's using this range must be documented in
              an RFC or other permanent and readily available
              references.

B.9. Traffic Control Name Space

   The following are the guidelines for managing Traffic Control Flags
   in GSMPv3:

      -  All Traffic Control Flags are allocated through an expert
         review, i.e., approval by a Designated Expert [19].

B.10. Event Flag Name Space

   The following are the guidelines for managing Event Flags in GSMPv3:

      -  All Event Flags are allocated through an expert review, i.e.,
         approval by a Designated Expert [19].

   The TCP port for establishing GSMP connections has been defined as
   6068.

Top      Up      ToC       Page 134 
References

   [1]  "B-ISDN ATM Layer Specification", International
        Telecommunication Union, ITU-T Recommendation I.361, Feb.  1999.

   [2]  "B-ISDN ATM Adaptation Layer (AAL) Specification", International
        Telecommunication Union, ITU-T Recommendation I.363, Mar. 1993.

   [3]  "B-ISDN ATM Adaptation Layer specification: Type 5 AAL",
        International Telecommunication Union, ITU-T, Recommendation
        I.363.5, Aug. 1996.

   [4]  Sjostrand, H., Buerkle, J. and B. Srinivasan, "Definitions of
        Managed Objects for the General Switch Management Protocol
        (GSMP)", RFC 3295, June 2002.

   [5]  IANA Assigned Port Numbers, http://www.iana.org

   [6]  Newman, P, Edwards, W., Hinden, R., Hoffman, E. Ching Liaw, F.,
        Lyon, T. and G. Minshall, "Ipsilon's General Switch Management
        Protocol Specification Version 1.1", RFC 1987, August 1996.

   [7]  Newman, P., Edwards, W., Hinden, R., Hoffman, E., Ching Liaw,
        F., Lyon, T. and G. Minshall, "Ipsilon's General Switch
        Management Protocol Specification Version 2.0", RFC 2297, March
        1998.

   [8]  ATM Forum Technical Committee, "Traffic Management Specification
        Version 4.1", af-tm-0121.000, 1999.

   [9] Wroclawski, J., "Specification of the Controlled-Load Network
        Element Service", RFC 2211, September 1997.

   [10] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L.,
        Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M.,
        Gray, E., Heinanen, J., Kilty, T. and A. Malis, "Constraint-
        Based LSP Setup using LDP", RFC 3212, January 2002.

   [11] ITU-T Recommendation I.233 Frame Mode Bearer Services, ISDN
        frame relaying bearer services and ISDN switching bearer
        service, Nov. 1991.

   [12] ITU-T Recommendation Q.933, Integrated Services Digital Network
        (ISDN) Digital Subscriber Signaling System No. 1 (DSS 1)
        Signaling Specifications For Frame Mode Switched And Permanent
        Virtual Connection Control And Status Monitoring, 1995.

Top      Up      ToC       Page 135 
   [13] ITU-T Recommendation Q.922, Integrated Services Digital Network
        (ISDN) Data Link Layer Specification For Frame Mode Bearer
        Services, 1992

   [14] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D.,
        Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032,
        January 2001.

   [15] Worster, T., Doria, A. and J. Buerkle, "General Switch
        Management Protocol (GSMP) Packet Encapsulations for
        Asynchronous Transfer Mode (ATM), Ethernet and Transmission
        Control Protocol (TCP)", RFC 3293, June 2002.

   [16] Doria, A. and K. Sundell, "General Switch Management Protocol
        Applicability", RFC 3294, June 2002.

   [17] IANAifType - MIB DEFINITIONS, http://www.iana.org, January 2001.

   [18] Anderson, L., Doolan, P., Feldman, N., Fredette, A. and B.
        Thomas, "LDP Specification", RFC 3036, January 2001.

   [19] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

   [20] Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [21] Conta, A., Doolan, P. and A. Malis, "Use of Label Switching on
        Frame Relay Networks Specification", RFC 3034, January 2001.

Top      Up      ToC       Page 136 
Authors' Addresses

   Avri Doria
   Div. of Computer Communications
   Lulea University of Technology
   S-971 87 Lulea
   Sweden

   Phone: +1 401 663 5024
   EMail: avri@acm.org


   Fiffi Hellstrand
   Nortel Networks AB
   S:t Eriksgatan 115 A
   SE-113 85 Stockholm Sweden

   EMail: fiffi@nortelnetworks.com


   Kenneth Sundell
   Nortel Networks AB
   S:t Eriksgatan 115 A
   SE-113 85 Stockholm Sweden

   EMail: ksundell@nortelnetworks.com


   Tom Worster

   Phone: +1 617 247 2624
   EMail: fsb@thefsb.org

Top      Up      ToC       Page 137 
Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.