[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
   GSMP Working Group
   Internet Draft                                            K. Sundell
   Document: draft-ietf-gsmp-packet-spec-02.txt         Nortel Networks
   Expires: April 2004                                     October 2003


                   GSMPv3 Packet Capable Switch Support


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.


Abstract

   The General Switch Management Protocol version 3 (GSMPv3) has been
   divided into a base specification (describing the semantics of the
   protocol) together with a set of documents describing protocol
   extensions to the base. Such extension could be to support switches
   capable for optical transport. This document adds extensions to the
   base GSMPv3 specification for controlling MPLS, ATM and Frame Relay
   capable switches.


Conventions used in this document

   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 RFC-2119 [2].





Sundell                  Expires - April 2004                 [Page 1]


                 GSMPv3 Packet Capable Switch Support     October 2003


Acknowledgement

   GSMP was created by P. Newman, W. Edwards, R. Hinden, E. Hoffman, F.
   Ching Liaw, T. Lyon, and G. Minshall (see [3] and [4]). All versions
   of GSMP are based on their work.


Table of Contents

   1. Introduction..................................................4
   2. GSMP Packet Encapsulation.....................................4
   3. Labels........................................................4
      3.1 ATM Labels................................................5
      3.2 Frame Relay Labels........................................6
      3.3 MPLS Generic Labels.......................................7
      3.4 FEC Labels................................................8
   4. Connection Management.........................................9
      4.1 Add Branch - ATM Specific procedures......................9
      4.2 Move Output Branch - ATM Specific Procedures.............10
      4.3 Move Input Branch - ATM Specific Procedures..............11
   5. Label Range Message..........................................12
      5.1 ATM Labels...............................................12
      5.2 Frame Relay Labels.......................................14
      5.3 MPLS Generic Labels......................................16
      5.4 FEC Labels...............................................16
   6. Management Messages..........................................17
      6.1 Port Management messages.................................17
   7. State and Statistics messages................................18
      7.1 Statistics Messages......................................18
      7.2 Report Connection State - ATM Specific Procedure.........23
   8. Configuration messages.......................................28
      8.1 Switch Configuration Messages............................28
      8.2 Port Configuration Messages..............................28
      8.3 Port Type Specific data for ATM..........................30
      8.4 Port Type Specific Data for Frame Relay..................31
      8.5 Port Type Specific Data for MPLS.........................32
      8.6 Port Type Specific Data for FEC..........................33
      8.7 Service Configuration....................................33
   9. Service Definitions..........................................36
      9.1 ATM CBR..................................................37
      9.2 ATM rt-VBR...............................................37
      9.3 ATM nrt-VBR..............................................38
      9.4 ATM UBR..................................................39
      9.5 ATM ABR..................................................39
      9.6 ATM GFR..................................................39
      9.7 Frame Relay..............................................40
      9.8 Integrated Services - Controlled Load....................40
      9.9 MPLS CR-LDP..............................................41
   10. Format and encoding of the Traffic Parameters...............41

Sundell                  Expires û April 2004                 [Page 2]


                 GSMPv3 Packet Capable Switch Support     October 2003


      10.1 Traffic Parameters for ATM Forum Services...............41
      10.2 Traffic Parameters for Int-Serv Controlled Load Service.42
      10.3 Traffic Parameters for CRLDP Service....................43
      10.4 Traffic Parameters for Frame Relay Service..............44
   11. Traffic Controls (TC) Flags.................................45
   12. Events......................................................46
   13. Failure Response Codes......................................46
      13.1 Description of Failure and Warning Response Messages....46
      13.2 Connection Failures.....................................47
      13.3 ATM Virtual Path Connections............................47
   Security Considerations.........................................48
   References......................................................49
   Acknowledgments.................................................50
   Author's Addresses..............................................50


   Changes since <draft-ietf-gsmp-packet-spec-01.txt>

   - Fixed typo in message format for Port Type Specific Data for
      MPLS.
   - Added specification of technology specific Port management
      messages.
   - Defined Technology specific Extension Values for Port Management
      Messages.
   - Defined Technology specific Extension Values for Port and
      Connection Statistics Messages.
   - Defined Technology specific Extension Values for Port.
      Configuration Message (PortType Specific Data in particular).
   - Examined if Event messages need Technology specific extensions.

   Changes since <draft-ietf-gsmp-packet-spec-00.txt>

   - Changed Label Type values (ch. 3) according to [7].
   - Removed section about Label Stacking (belongs to [7]).
   - Added Definition of Capability Set Records (ch. 7.6).
   - Resized the Result and Code fields in the general headers
      reflecting the recent change in [7].
   - Adjusted the Service ID ranges according to the ones that are
      being defined in [7].
   - Added text to the Failure Response codes (Ch.13).










Sundell                  Expires û April 2004                 [Page 3]


                 GSMPv3 Packet Capable Switch Support     October 2003




1. Introduction

   The General Switch Management Protocol version 3 (GSMPv3) was
   initially defined in [5] together with an applicability statement
   [6]. Since then the GSMPv3 has been divided into a base
   specification [7] (describing the semantics of the protocol)
   together with a set of documents describing protocol extensions to
   the base protocol. Such extension could be to support switches
   capable for optical transport. This document adds extensions to the
   base GSMPv3 specification for controlling MPLS, ATM and Frame Relay
   capable switches.


2. GSMP Packet Encapsulation

   GSMP packets may be transported via any suitable medium. GSMP packet
   encapsulations for ATM, Ethernet and TCP are specified in [8].
   Additional encapsulations for GSMP packets may be defined in
   separate documents.


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 behavior 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 by the GSMPv3 extensions defined
   in this document, is listed below:


          TLV Label      Type          Section Title
          ---------      ----          -------------
          ATM Label      0x100         ATM TLV Labels
          FR Label       0x101         Frame Relay TLV Labels
          Reserved       0x102-0x1FF   -
          MPLS Gen Label 0x200         MPLS Generic TLV Labels
          FEC Label      0x201         FEC TLV Labels
          Reserved       0x202-0x2FF   -



Sundell                  Expires û April 2004                 [Page 4]


                 GSMPv3 Packet Capable Switch Support     October 2003





   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
            The definition of Label Stacking is discussed in [7].

         Label Type
            A 12-bit field indicating the type of label.

         Label Length
            A 16-bit field indicating the length of the Label Value
            field in bytes.

         Label Value
            A variable length field that is an integer number of 32 bit
            words long. The Label Value field is interpreted according
            to the Label Type as described in the following sections.


3.1 ATM Labels

   Labels for an ATM based label switch MAY consist of an ATM VPI
   and/or VCI field or of an MPLS shim header [11]. Also if there are
   multiple Labels in the stack, these labels MAY be treated as MPLS
   Generic Labels [11] specified in 3.3. This section defines ATM
   labels that utilize the VPI and/or the VCI field as the label.

   If the Label Type = ATM Label, the labels MUST be interpreted as ATM
   labels as shown:





Sundell                  Expires û April 2004                 [Page 5]


                 GSMPv3 Packet Capable Switch Support     October 2003





       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |x|S|x|x|   ATM Label (0x100)   |          Label Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |x x x x|           VPI         |              VCI              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   For a virtual path connection (switched as a single virtual path
   connection) or a virtual path (switched as one or more virtual
   channel connections within the virtual path) the VCI field is not
   used.

   ATM distinguishes between virtual path connections and virtual
   channel connections. The connection management messages apply both
   to virtual channel connections and virtual path connections. The Add
   Branch and Move Branch connection management messages have two
   Message Types. One Message Type indicates that a virtual channel
   connection is required, and the other Message Type indicates that a
   virtual path connection is required. The Delete Branches, Delete
   Tree, and Delete All connection management messages have only a
   single Message Type because they do not need to distinguish between
   virtual channel connections and virtual path connections.
   For virtual path connections, neither Input VCI fields nor Output
   VCI fields are required. They SHOULD be set to zero by the sender
   and ignored by the receiver. Virtual channel branches may not be
   added to an existing virtual path connection. Conversely, virtual
   path branches may not be added to an existing virtual channel
   connection. In the Port Configuration message each switch input port
   may declare whether it is capable of supporting virtual path
   switching (i.e. accepting connection management messages requesting
   virtual path connections).


3.2 Frame Relay Labels

   Frame Relay labels are specified for Frame Relay switches and Label
   switches, utilizing the Frame Relay DLCI as the label as defined in
   [9]. If there is more than one label in the label stack, these are
   treated as MPLS Generic Labels, specified in 3.3.

   If the TLV Type = FR Label, the labels MUST be interpreted as a
   Frame Relay labels as shown:



Sundell                  Expires û April 2004                 [Page 6]


                 GSMPv3 Packet Capable Switch Support     October 2003





       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 [9], i.e. it is not explicitly
         reserved by GSMPv3.

      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 [10].


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
   [11]. This applies also for other switch types, e.g. ATM switches,
   which MAY NOT utilize the available identifiers as labels (rather
   Shim Labels as defined in [11]). 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 (0x200)|          Label Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |x x x x x x x x x x x x|              MPLS Label               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Sundell                  Expires û April 2004                 [Page 7]


                 GSMPv3 Packet Capable Switch Support     October 2003





          MPLS Label
             This is a 20-bit label value as specified in [11]
             represented as a 20-bit number in a 4-byte field.


3.4 FEC Labels

   Labels may be bound to Forwarding Equivalence Classes (FECs) as
   defined in [12]. 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 (0x201)   |          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

Sundell                  Expires û April 2004                 [Page 8]


                 GSMPv3 Packet Capable Switch Support     October 2003


             NUMBERS in [13] that encodes the address family for the
             address prefix in the Prefix field.

          Prefix Length
             One byte containing the length in bits of the address
             prefix that follows. A length of zero indicates a prefix
             that matches all addresses (the default destination); in
             this case the Prefix itself is zero bytes.

          Prefix
             An address prefix encoded according to the Address Family
             field, whose length, in bits, was specified in the Prefix
             Length field.


4. Connection Management

4.1 Add Branch - ATM Specific procedures

   To request an ATM virtual path connection the ATM Virtual Path
   Connection (VPC) Add Branch message is:

                Message Type = 26

   An ATM virtual path connection can only be established between ATM
   ports, i.e. ports with the "ATM" Label Type attribute. If an ATM VPC
   Add Branch message is received and either the switch input port
   specified by the Input Port field or the switch output port
   specified by the Output Port field is not an ATM port, a failure
   response message MUST be returned indicating, "28: ATM Virtual path
   switching is not supported on non-ATM ports".

   If an ATM VPC Add Branch message is received and the switch input
   port specified by the Input Port field does not support virtual path
   switching, a failure response message MUST be returned indicating,
   "24: ATM virtual path switching is not supported on this input
   port".

   If an ATM virtual path connection already exists on the virtual path
   specified by the Input Port and Input VPI fields, a failure response
   message MUST be returned indicating, "27: Attempt to add an ATM
   virtual channel connection branch to an existing virtual path
   connection".

   For the VPC Add Branch message, if a virtual channel connection
   already exists on any of the virtual channels within the virtual
   path specified by the Input Port and Input VPI fields, a failure
   response message MUST be returned indicating, "26: Attempt to add an


Sundell                  Expires û April 2004                 [Page 9]


                 GSMPv3 Packet Capable Switch Support     October 2003


   ATM virtual path connection branch to an existing virtual channel
   connection".


4.2 Move Output Branch - ATM Specific Procedures

   The ATM VPC Move Output Branch message is a connection management
   message used to move a single output branch of a virtual path
   connection from its current output port and output VPI, to a new
   output port and output VPI on the same virtual channel connection.
   None of the other output branches are modified. When the operation
   is complete the original output VPI on the original output port will
   be deleted from the connection.

   The VPC Move Branch message is:

          Message Type = 27

   For the VPC Move Output Branch message, if the virtual path
   connection specified by the Input Port and Input VPI fields already
   exists, and the output branch specified by the Old Output Port and
   Old Output VPI fields exists as a branch on that connection, the
   output branch specified by the New Output Port and New Output VPI
   fields is added to the connection and the branch specified by the
   Old Output Port and Old Output VPI fields is deleted. If the Result
   field of the request message is "AckAll" a success response message
   MUST be sent upon successful completion of the operation. The
   success response message MUST NOT be sent until the Move Branch
   operation has been completed.

   For the VPC Move Output Branch message, if the virtual path
   connection specified by the Input Port and Input VPI fields already
   exists, but the output branch specified by the Old Output Port and
   Old Output VPI fields does not exist as a branch on that connection,
   a failure response MUST be returned with the Code field indicating,
   "12: The specified branch does not exist".

   If the virtual channel connection specified by the Input Port and
   Input Label fields; or the virtual path connection specified by the
   Input Port and Input VPI fields; does not exist, a failure response
   MUST be returned with the Code field indicating, "11: The specified
   connection does not exist".

   If the output branch specified by the New Output Port, New Output
   VPI, and New Output VCI fields for a virtual channel connection; or
   the output branch specified by the New Output Port and New Output
   VPI fields for a virtual path connection; is already in use by any
   connection other than that specified by the Input Port and Input
   Label fields then the resulting output branch will have multiple

Sundell                  Expires û April 2004                [Page 10]


                 GSMPv3 Packet Capable Switch Support     October 2003


   input branches. If multiple point-to-point connections share the
   same output branch the result will be a multipoint-to-point
   connection. If multiple point-to-multipoint trees share the same
   output branches the result will be a multipoint-to-multipoint
   connection.

4.3 Move Input Branch - ATM Specific Procedures

   The ATM VPC Move Input Branch message is a connection management
   message used to move a single input branch of a virtual path
   connection from its current input port and input VPI, to a new input
   port and input VPI on the same virtual channel connection.
   None of the other input branches are modified. When the operation is
   complete the original input VPI on the original input port will be
   deleted from the connection.

   The VPC Move Input Branch message is:

          Message Type = 28

   For the VPC Move Input Branch message, if the virtual path
   connection specified by the Output Port and Output VPI fields
   already exists, and the input branch specified by the Old Input Port
   and Old Input VPI fields exists as a branch on that connection, the
   input branch specified by the New Input Port and New Input VPI
   fields is added to the connection and the branch specified by the
   Old Input Port and Old Input VPI fields is deleted. If the Result
   field of the request message is "AckAll" a success response message
   MUST be sent upon successful completion of the operation. The
   success response message MUST NOT be sent until the Move Input
   Branch operation has been completed.

   For the VPC Move Input Branch message, if the virtual path
   connection specified by the Output Port and Output VPI fields
   already exists, but the input branch specified by the Old Input Port
   and Old Input VPI fields does not exist as a branch on that
   connection, a failure response MUST be returned with the Code field
   indicating, "12: The specified branch does not exist".

   If the virtual channel connection specified by the Output Port and
   Output Label fields; or the virtual path connection specified by the
   Output Port and Output VPI fields; does not exist, a failure
   response MUST be returned with the Code field indicating, "11: The
   specified connection does not exist".

   If the input branch specified by the New Input Port, New Input VPI,
   and New Input VCI fields for a virtual channel connection; or the
   input branch specified by the New Input Port and New Input VPI
   fields for a virtual path connection; is already in use by any

Sundell                  Expires û April 2004                [Page 11]


                 GSMPv3 Packet Capable Switch Support     October 2003


   connection other than that specified by the Output Port and Output
   Label fields then the resulting input branch will have multiple
   output branches. If multiple point-to-point connections share the
   same input branch the result will be a point-to-multipoint
   connection. If multiple multipoint-to-point trees share the same
   input branches the result will be a multipoint-to-multipoint
   connection.

5. Label Range Message

5.1 ATM Labels

   If the Label Type = ATM Label, the labels range message MUST be
   interpreted as an ATM Label 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|x|V|C|   ATM Label (0x100)   |          Label Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |x|x|x|x|        min VPI        |            min VCI            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |x|x|x|x|   ATM Label (0x100)   |          Label Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |x|x|x|x|        max VPI        |            max VCI            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Remaining VPI's         |        Remaining VCI's        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


         V: Label
            If the Label flag is set, the message refers to a range of
            VPI's only. The Min VCI and Max VCI fields are unused. If
            the Label flag is zero the message refers to a range of
            VCI's on either one VPI or on a range of VPI's.

         Min VPI, Max VPI
            Specify a range of VPI values, Min VPI to Max VPI
            inclusive. A single VPI may be specified with a Min VPI and
            a Max VPI having the same value. In a request message, if
            the value of the Max VPI field is less than or equal to the
            value of the Min VPI field, the requested range is a single
            VPI with a value equal to the Min VPI field. Zero is a
            valid value. In a request message, if the Query flag is
            set, and the Label flag is zero, the Max VPI field
            specifies a single VPI and the Min VPI field is not used.
            The maximum valid value of these fields for both request
            and response messages is 0xFFF.

Sundell                  Expires û April 2004                [Page 12]


                 GSMPv3 Packet Capable Switch Support     October 2003



         Min VCI, Max VCI
            Specify a range of VCI values, Min VCI to Max VCI
            inclusive. A single VCI may be specified with a Min VCI and
            a Max VCI having the same value. In a request message, if
            the value of the Max VCI field is less than or equal to the
            value of the Min VCI field, the requested range is a single
            VCI with a value equal to the Min VCI field. Zero is a
            valid value. (However, VPI=0, VCI=0 is not available as a
            virtual channel connection as it is used as a special value
            in ATM to indicate an unassigned cell.)

         Remaining VPI's, Remaining VCI's
            These fields are unused in the request message. In the
            success response message and in the failure response
            message these fields give the maximum number of remaining
            VPI's and VCI's that could be requested for allocation on
            the specified port (after completion of the requested
            operation in the case of the success response). It gives
            the switch controller an idea of how many VPI's and VCI's
            it could request. The number given is the maximum possible
            given the constraints of the switch hardware. There is no
            implication that this number of VPI's and VCI's is
            available to every switch port.

   If the Query flag and the Label flag are set in the request message,
   the switch MUST reply with a success response message containing the
   current range of valid VPI's that are supported by the port. The Min
   VPI and Max VPI fields are not used in the request message.

   If the Query flag is set and the Label flag is zero in the request
   message, the switch MUST reply with a success response message
   containing the current range of valid VCI's that are supported by
   the VPI specified by the Max VPI field. If the requested VPI is
   invalid, a failure response MUST be returned indicating: "13: One or
   more of the specified Input Labels is invalid". The Min VPI field is
   not used in either the request or success response messages.

   If the Query flag is zero and the Label flag is set in the request
   message, the Min VPI and Max VPI fields specify the new range of
   VPI's to be allocated to the input port specified by the Port field.
   Whatever the range of VPI's previously allocated to this port it
   SHOULD be increased or decreased to the specified value.

   If the Query flag and the Label flag are zero in the request
   message, the Min VCI and Max VCI fields specify the range of VCI's
   to be allocated to each of the VPI's specified by the VPI range.
   Whatever the range of VCI's previously allocated to each of the
   VPI's within the specified VPI range on this port, it SHOULD be

Sundell                  Expires û April 2004                [Page 13]


                 GSMPv3 Packet Capable Switch Support     October 2003


   increased or decreased to the specified value. The allocated VCI
   range MUST be the same on each of the VPI's within the specified VPI
   range.

   If the switch is unable to satisfy a request to change the label
   range, it MUST return a failure response message with the Code field
   set to: "40: Cannot support one or more requested label ranges". If
   the switch is unable to satisfy a request to change the VPI the
   switch MUST use the Min VPI and Max VPI fields to suggest a VPI
   range that it would be able to satisfy and set the VCI fields to
   zero or if the switch is unable to satisfy a request to change the
   VCI range on all VPI's within the requested VPI range, the switch
   MUST use the Min VPI, Max VPI, Min VCI, and Max VCI fields to
   suggest a VPI and VCI range that it would be able to satisfy.

   In all other failure response messages for the label range operation
   the switch MUST return the values of Min VPI, Max VPI, Min VCI, and
   Max VCI from the request message.

   While switches can typically support all 256 or 4096 VPI's, the VCI
   range that can be supported is often more constrained. Often the Min
   VCI MUST be 0 or 32. Typically all VCI's within a particular VPI
   MUST be contiguous. The hint in the failure response message allows
   the switch to suggest a label range that it could satisfy in view of
   its particular architecture.

   While the Label Range message is defined to specify both a range of
   VPI's and a range of VCI's within each VPI, the most likely use is
   to change either the VPI range or the range of VCI's within a single
   VPI. It is possible for a VPI to be valid but to be allocated no
   valid VCI's. Such a VPI could be used for a virtual path connection
   but to support virtual channel connections it would need to be
   allocated a range of VCI's.


5.2 Frame Relay Labels

   If the Label Type = FR Label, the labels range message MUST be
   interpreted as 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|x|V|C|    FR Label (0x101)   |          Label Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |x|x|x|x| Res |Len|                Min DLCI                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |x|x|x|x|    FR Label (0x101)   |          Label Length         |

Sundell                  Expires û April 2004                [Page 14]


                 GSMPv3 Packet Capable Switch Support     October 2003


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |x|x|x|x| Res |Len|                Max DLCI                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Remaining DLCI                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


       V: Label
            The Label flag is not used.

       Res
            The Res field is reserved in [9], 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

       Min DLCI, Max DLCI
            Specify a range of DLCI values, Min DLCI to Max DLCI
            inclusive. The values SHOULD be right justified in the
            23-bit fields and the preceding bits SHOULD be set to
            zero. A single DLCI may be specified with a Min DLCI and
            a Max DLCI having the same value. In a request message,
            if the value of the Max DLCI field is less than or equal
            to the value of the Min DLCI field, the requested range
            is a single DLCI with a value equal to the Min DLCI field.
            Zero is a valid value.

       Remaining DLCI's
            This field is unused in the request message. In the success
            response message and in the failure response message this
            field gives the maximum number of remaining DLCI's that
            could be requested for allocation on the specified port
            (after completion of the requested operation in the case of
            the success response). It gives the switch controller an
            idea of how many DLCI's it could request. The number given
            is the maximum possible given the constraints of the switch
            hardware. There is no implication that this number of
            DLCI's is available to every switch port.






Sundell                  Expires û April 2004                [Page 15]


                 GSMPv3 Packet Capable Switch Support     October 2003


5.3 MPLS Generic Labels

   The Label Range Block for PortTypes using MPLS labels. These types
   of 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 [11]. If Label Type = MPLS Gen Label, the labels
   range message MUST be interpreted as MPLS Generic Label 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|x|V|C| MPLS Gen Label (0x200)|          Label Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |x|x|x|x|x|x|x|x|x|x|x|x|          Min MPLS Label               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |x|x|x|x| MPLS Gen Label (0x200)|          Label Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |x|x|x|x|x|x|x|x|x|x|x|x|          Max MPLS Label               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Remaining Labels                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       V: Label
          The Label flag is not used.

       Min MPLS Label, Max MPLS Label
          Specify a range of MPLS label values, Min MPLS Label to Max
          MPLS Label inclusive. The Max and Min MPLS label fields are
          20 bits each.

       Remaining MPLS Labels
          This field is unused in the request message. In the success
          response message and in the failure response message this
          field gives the maximum number of remaining MPLS Labels that
          could be requested for allocation on the specified port
          (after completion of the requested operation in the case of
          the success response). It gives the switch controller an idea
          of how many MPLS Labels it could request. The number given is
          the maximum possible given the constraints of the switch
          hardware. There is no implication that this number of Labels
          is available to every switch port.

5.4 FEC Labels

   The Label Range message is not used for FEC Labels and is for
   further study.



Sundell                  Expires û April 2004                [Page 16]


                 GSMPv3 Packet Capable Switch Support     October 2003


6. Management Messages

6.1 Port Management messages

   The Port Management message allows a port to be brought into
   service, to be taken out of service, to be set to loop back, reset,
   or to change the transmit data rate. This section specifies Port
   Management messages for L2 and Packet Capable Switches.

       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|  Message Type |   Tech Type   | Block Length  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                         Extension Value                       |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Message Type
      The 8-bit Message Type field, defined in [7], corresponds to the
      message type where the TLV is used.

   Tech Type
      The 8-bit Tech Type field, defined in [7], indicates the
      applicable technology type value. The Message Type value plus the
      Tech Value uniquely define a single Extension Type and be treated
      as a single 16 bit extension type.

      In this document the Tech Type will use the following values:

            0x00  Extension Value not in use
            0x01  Extensions for ATM and Frame Relay switch types
            0x02  Extensions for Generic MPLS switch types


   If the Message Type field is = 32 and the Tech Type field is = 0x01
   or 0x02 then the Extension Value field should be interpreted as:


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Transmit Data Rate                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Sundell                  Expires û April 2004                [Page 17]


                 GSMPv3 Packet Capable Switch Support     October 2003


   Transmit Data Rate
       This field is only used in request and success response messages
       with the Function field set to "Set Transmit Data Rate".  It is
       used to set the output data rate of the output port.  It is
       specified in cells/s and bytes/s.  If the Transmit Data Rate
       field contains the value 0xFFFFFFFF the transmit data rate of
       the output port SHOULD be set to the highest valid value.


7. State and Statistics messages

7.1 Statistics Messages

   The Statistics Messages are used to query the various port,
   connection and counters. The request message is used as defined in
   [7] but the response for the Statistics Message is technology
   specific. Please refer to [7] for details about GSMPv3 general
   fields and parameters.

   If the Message Type field is = 49 (Port Statistics Message) and the
   Tech Type field is = 0x01 and the label type is = ATM, then the
   Extension Value field should be interpreted as:


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                       Input Cell Count                        +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                    Input Cell Discard Count                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                  Header Checksum Error Count                  +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                   Input Invalid Label Count                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                       Output Cell Count                       +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                   Output Cell Discard Count                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Sundell                  Expires û April 2004                [Page 18]


                 GSMPv3 Packet Capable Switch Support     October 2003


   Input Cell Count, Output Cell Count
       Give the value of a free running 64-bit counter counting cells
       arriving at the input or departing from the output respectively.
       These fields are relevant for label type = ATM, for all other
       label types these fields SHOULD be set to zero by the sender and
       ignored by the receiver.

   Input Cell Discard Count, Output Cell Discard Count
       Give the value of a free running 64-bit counter counting cells
       discarded due to queue overflow on an input port or on an
       output port respectively.  These fields are relevant for label
       type = ATM, for all other label types these fields SHOULD be
       set to zero by the sender and ignored by the receiver.

   Header Checksum Error Count
       Gives the value of a free running 64-bit counter counting cells
       or frames discarded due to header checksum errors on arrival at
       an input port. For an ATM switch this would be the HEC count.

   Invalid Label Count
       Gives the value of a free running 64-bit counter counting cells
       or frames discarded because their Label is invalid on arrival
       at an input port.

   If the Message Type field is = 49 (Port Statistics Message) and the
   Tech Type field is = 0x01 and the label type is = Frame Relay, then
   the Extension Value field should be interpreted as:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                       Input Frame Count                       +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                   Input Frame Discard Count                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                  Header Checksum Error Count                  +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                   Input Invalid Label Count                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      Output Frame Count                       +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Sundell                  Expires û April 2004                [Page 19]


                 GSMPv3 Packet Capable Switch Support     October 2003


      |                                                               |
      +                  Output Frame Discard Count                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Input Frame Count, Output Frame Count
       Give the value of a free running 64-bit counter counting frames
       (packets) arriving at the input or departing from the output
       respectively.  These fields are relevant for label types = FR
       and MPLS, for all other label types these fields SHOULD be set
       to zero by the sender and ignored by the receiver.

   Input Frame Discard Count, Output Frame Discard Count
       Give the value of a free running 64-bit counter counting frames
       discarded due to congestion on an input port or on an output
       port respectively.  These fields are relevant for label types =
       FR and MPLS, for all other label types these fields SHOULD be
       set to zero by the sender and ignored by the receiver.

   If the Message Type field is = 49 (Port Statistics Message) and the
   Tech Type field is = 0x02 and the label type is = MPLS, then the
   Extension Value field should be interpreted as:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                       Input Frame Count                       +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                   Input Frame Discard Count                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                  Header Checksum Error Count                  +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                   Input Invalid Label Count                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      Output Frame Count                       +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                  Output Frame Discard Count                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Sundell                  Expires û April 2004                [Page 20]


                 GSMPv3 Packet Capable Switch Support     October 2003



   If the Message Type field is = 50 (Connection Statistics Message)
   and the Tech Type field is = 0x01 and the label type is = ATM, then
   the Extension Value field should be interpreted as:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                       Input Cell Count                        +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                    Input Cell Discard Count                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                  Header Checksum Error Count                  +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                   Input Invalid Label Count                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                       Output Cell Count                       +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                   Output Cell Discard Count                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Input Cell Count, Output Cell Count
       Give the value of a free running 64-bit counter counting cells
       arriving at the input or departing from the output
       respectively.  These fields are relevant for label type = ATM,
       for all other label types these fields SHOULD be set to zero by
       the sender and ignored by the receiver.

   Input Cell Discard Count, Output Cell Discard Count
       Give the value of a free running 64-bit counter counting cells
       discarded due to queue overflow on an input port or on an
       output port respectively.  These fields are relevant for label
       type = ATM, for all other label types these fields SHOULD be
       set to zero by the sender and ignored by the receiver.

   Header Checksum Error Count
       Gives the value of a free running 64-bit counter counting cells
       or frames discarded due to header checksum errors on arrival at
       an input port.  For an ATM switch this would be the HEC count.

Sundell                  Expires û April 2004                [Page 21]


                 GSMPv3 Packet Capable Switch Support     October 2003


   Invalid Label Count
       Gives the value of a free running 64-bit counter counting cells
       or frames discarded because their Label is invalid on arrival
       at an input port.

   If the Message Type field is = 50 (Connection Statistics Message)
   and the Tech Type field is = 0x01 and the label type is = Frame
   Relay, then the Extension Value field should be interpreted as:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                       Input Frame Count                       +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                   Input Frame Discard Count                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      Output Frame Count                       +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                  Output Frame Discard Count                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Input Frame Count, Output Frame Count
       Give the value of a free running 64-bit counter counting frames
       (packets) arriving at the input or departing from the output
       respectively.  These fields are relevant for label types = FR
       and MPLS, for all other label types these fields SHOULD be set
       to zero by the sender and ignored by the receiver.

   Input Frame Discard Count, Output Frame Discard Count
       Give the value of a free running 64-bit counter counting frames
       discarded due to congestion on an input port or on an output
       port respectively.  These fields are relevant for label types =
       FR and MPLS, for all other label types these fields SHOULD be
       set to zero by the sender and ignored by the receiver.










Sundell                  Expires û April 2004                [Page 22]


                 GSMPv3 Packet Capable Switch Support     October 2003


   If the Message Type field is = 50 (Connection Statistics Message)
   and the Tech Type field is = 0x02 and the label type is = MPLS, then
   the Extension Value field should be interpreted as:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                       Input Frame Count                       +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                   Input Frame Discard Count                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      Output Frame Count                       +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                  Output Frame Discard Count                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


7.2 Report Connection State - ATM Specific Procedure

   The Report Connection State message is used to request an input port
   to report the connection state for a single connection or for the
   entire input port. The Report Connection State message is:

         Message Type = 52

   The Report Connection State request message has 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Vers  |  Sub  | Message Type  | Result|         Code          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Partition ID  |            Transaction Identifier             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |I|      SubMessage Number      |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Input Port                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |x|S|A|V|                                                       |
      +-+-+-+-+                  Input Label                          |
      ~                                                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Sundell                  Expires û April 2004                [Page 23]


                 GSMPv3 Packet Capable Switch Support     October 2003



       Note: Field and Parameters that have been explained in the
       description of the general GSMPv3 messages will not be explained
       in this section. Please refer to [7] for details.

       Input Port
          Identifies the port number of the input port for which the
          connection state is being requested.

       Flags

          A: All Connections
             If the All Connections flag is set, the message requests
             the connection state for all connections that originate at
             the input port specified by the Input Port field. In this
             case the Input Label field and the Label flag are unused.

          V: ATM VPI
             The ATM VPI flag may only be set for ports with
             PortType=ATM. If the switch receives a Report Connection
             State message in which the ATM VPI flag set and in which
             the input port specified by the Input Port field does not
             have PortType=ATM, the switch MUST return an Failure
             response "28: ATM Virtual Path switching is not supported
             on non-ATM ports".

             If the All Connections flag is zero and the ATM VPI flag
             is also zero, the message requests the connection state
             for the connection that originates at the input port
             specified by the Port and Input Label fields.

             If the All Connections flag is zero and the ATM VPI flag
             is set and the input port specified by the Input Port
             field has LabelType=ATM, the message requests the
             connection state for the virtual path connection that
             originates at the input port specified by the Input Port
             and Input VPI fields. If the specified Input VPI
             identifies an ATM virtual path connection (i.e. a single
             switched virtual path) the state for that connection is
             requested. If the specified Input VPI identifies a virtual
             path containing virtual channel connections, the message
             requests the connection state for all virtual channel
             connections that belong to the specified virtual path.

      Input Label
         Field identifies the specific connection for which connection
         state is being requested. For requests that do not require a
         connection to be specified, the Input Label field is not used.


Sundell                  Expires û April 2004                [Page 24]


                 GSMPv3 Packet Capable Switch Support     October 2003



   The Report Connection State success response message has 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Vers  | Sub   | Message Type  | Result|         Code          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Partition ID  |            Transaction Identifier             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |I|      SubMessage Number      |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Input Port                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Sequence Number                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                       Connection Records                      ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Note: Field and Parameters that have been explained in the
          description of the general messages will not be explained
          in this section. Please refer to section 3.1 of [7] for
          details.

       Input Port
          Is the same as the Input Port field in the request message.
          It identifies the port number of the input port for which
          the connection state is being reported.

       Sequence Number
          In the case that the requested connection state cannot be
          reported in a single success response message, each
          successive success response message in reply to the same
          request message MUST increment the Sequence Number. The
          Sequence Number of the first success response message, in
          response to a new request message, MUST be zero.

       Connection Records
          Each success response message MUST contain one or more
          Connection Records. Each Connection Record specifies a single
          point-to-point or point-to-multipoint connection. The number
          of Connection Records in a single Report Connection State
          success response MUST NOT cause the packet length to exceed
          the maximum transmission unit defined by the encapsulation.
          If the requested connection state cannot be reported in a
          single success response message, multiple success response

Sundell                  Expires û April 2004                [Page 25]


                 GSMPv3 Packet Capable Switch Support     October 2003


          messages MUST be sent. All success response messages that are
          sent in response to the same request message MUST have the
          same Input Port and Transaction Identifier fields as the
          request message. A single Connection Record MUST NOT be split
          across multiple success response messages. Since the usage of
          ôMOREö in the Result field is deprecated in [7], the I flag
          [7] should  be utilized to indicate that one or more
          further success response messages should be expected in
          response to the same request message. "Success" in the Result
          field indicates that the response to the request has been
          completed. The Result values are defined in [7].


   Each Connection Record has the following format:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |A|V|P|     Record Count    |           Record Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |x|S|x|x|                                                       |
      +-+-+-+-+                    Input Label                        |
      ~                                                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                   Output Branch Records                       ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Flags

           A: All Connections


           V: ATM VPI
              For the first Connection Record in each success response
              message the All Connections and the ATM VPI flags MUST be
              the same as those of the request message. For successive
              Connection Records in the same success response message
              these flags are not used.

           P: ATM VPC
              The ATM VPC flag may only be set for ports with
              PortType=ATM. The ATM VPC flag, if set and only if set,
              indicates that the Connection Record refers to an ATM
              virtual path connection.

       Input Label
          The input label of the connection specified in this
          Connection Record.


Sundell                  Expires û April 2004                [Page 26]


                 GSMPv3 Packet Capable Switch Support     October 2003



       Record Count
          Count of Output Branch Records included in a response
          message.

       Record Length
          Length in bytes of Output Branch Records field

       Output Branch Records
          Each Connection Record MUST contain one or more Output Branch
          Records. Each Output Branch Record specifies a single output
          branch belonging to the connection identified by the Input
          Label field of the Connection Record and the Input Port field
          of the Report Connection State message. A point-to-point
          connection will require only a single Output Branch Record. A
          point-to-multipoint connection will require multiple Output
          Branch Records. If a point-to-multipoint connection has more
          output branches than can fit in a single Connection Record
          contained within a single success response message, that
          connection may be reported using multiple Connection Records
          in multiple success response messages.

   Each Output Branch Record has the following format:


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Output Port                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |x|S|x|x|                                                       |
      +-+-+-+-+                    Output Label                       |
      ~                                                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Output Port
            The output port of the switch to which this output branch
            is routed.

         Output Label
            The output label of the output branch specified in this
            Output Branch Record.

   ATM specific procedures:

   If this Output Branch Record is part of a Connection Record that
   specifies a virtual path connection (the ATM VPC flag is set) the
   Output VCI field is unused.

   A Report Connection State request message may be issued regardless
   of the Port Status or the Line Status of the target switch port.

Sundell                  Expires û April 2004                [Page 27]


                 GSMPv3 Packet Capable Switch Support     October 2003



   If the Input Port of the request message is valid, and the All
   Connections flag is set, but there are no connections established on
   that port, a failure response message MUST be returned with the Code
   field set to, "10: General Message Failure" For the Report
   Connection State message, this failure code indicates that no
   connections matching the request message were found. This failure
   message SHOULD also be returned if the Input Port of the request
   message is valid, the All Connections flag is zero, and no
   connections are found on that port matching the specified
   connection.


8. Configuration messages

8.1 Switch Configuration Messages

   There are currently no Technology specifics for L2 and Packet
   capable switches. For Message Type = 64 and Tech Type = 0x01 or
   0x02, the Block Length should be set to 0.

8.2 Port Configuration Messages

   The Port Configuration message (defined in section 8.2 of [7])
   requests the switch for the configuration information of a single
   switch port. The Port field in the request message specifies the
   port for which the configuration is requested. In order to support
   Packet Capable switches, there is a need to define PortTypeÆs for
   these.

     PortType

         1: PortType is ATM
         2: PortType is FR
         3: PortType is MPLS

   There are also a number of flags and fields to be defined for the
   Port Type Specific Data field in the Port Configuration message.

     P: VP Switching
        The ATM VPC flag may only be set for ports withPortType=ATM.
        The VP Switching flag, if set, indicates that this input port
        is capable of supporting virtual path switching. Else, if zero,
        it indicates that this input port is only capable of virtual
        channel switching.

     V: Label
        The Label flag use is port type specific.


Sundell                  Expires û April 2004                [Page 28]


                 GSMPv3 Packet Capable Switch Support     October 2003


   The Extensions Value field for PortTypes = ATM, FR or MPLS will be:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Receive Data Rate                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Transmit Data Rate                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Receive Data Rate
        The maximum rate of data that may arrive at the input port in;
            cells/s  for PortType = ATM
            bytes/s  for PortType = FR
            bytes/s  for PortType = MPLS

     Transmit Data Rate
        The maximum rate of data that may depart from the output port
        in;
            cells/s          for PortType = ATM
            bytes/s          for PortType = FR
            bytes/s          for PortType = MPLS

            (The transmit data rate of the output port may be changed
            by the Set Transmit Data Rate function of the Port
            Management message.)

     Line Type
        The type of physical transmission interface for this port. The*
        values for this field are defined by the IANAifType's specified
        in [18].

        The following values are identified for use in this version of
        the protocol.

            PortType = Unknown: other(1)
            PortType = MPLS:    ethernetCsmacd(6),
                                ppp(23)
            PortType = ATM:     atm(37)
            PortType = FR:      frameRelayService(44)












Sundell                  Expires û April 2004                [Page 29]


                 GSMPv3 Packet Capable Switch Support     October 2003


8.3 Port Type Specific data for ATM

   If PortType=ATM, the Default Label Range Block have 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |x|x|V|x|   ATM Label (0x100)   |          Label Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |x x x x|           VPI         |              VCI              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       V: Label
          If the Label flag is set, the message refers to a range of
          VPI's only. The Min VCI and Max VCI fields are unused. If
          the Label flag is zero the message refers to a range of
          VCI's on either one VPI or on a range of VPI's.

       Min VPI
          The default minimum value of dynamically assigned incoming
          VPI that the connection table on the input port supports
          and that may be controlled by GSMP.

       Max VPI
          The default maximum value of dynamically assigned incoming
          VPI that the connection table on the input port supports
          and that may be controlled by GSMP.

          At power-on, after a hardware reset, and after the Reset
          Input Port function of the Port Management message, the
          input port MUST handle all values of VPI within the range
          Min VPI to Max VPI inclusive and GSMP MUST be able to
          control all values within this range. It should be noted
          that the range Min VPI to Max VPI refers only to the
          incoming VPI range that can be supported by the associated
          port. No restriction is placed on the values of outgoing
          VPI's that may be written into the cell header. If the
          switch does not support virtual paths it is acceptable for
          both Min VPI and Max VPI to specify the same value, most
          likely zero.

          Use of the Label Range message allows the range of VPI's
          supported by the port to be changed. However, the Min VPI
          and Max VPI fields in the Port Configuration and All Ports
          Configuration messages always report the same default values
          regardless of the operation of the Label Range message.



Sundell                  Expires û April 2004                [Page 30]


                 GSMPv3 Packet Capable Switch Support     October 2003


         Min VCI
            The default minimum value of dynamically assigned incoming
            VCI that the connection table on the input port can support
            and may be controlled by GSMP. This value is not changed as
            a result of the Label Range message.

         Max VCI
            The default maximum value of dynamically assigned incoming
            VCI that the connection table on the input port can support
            and may be controlled by GSMP.

            At power-on, after a hardware reset, and after the Reset
            Input Port function of the Port Management message, the
            input port MUST handle all values of VCI within the range
            Min VCI to Max VCI inclusive, for each of the virtual paths
            in the range Min VPI to Max VPI inclusive, and GSMP MUST be
            able to control all values within this range. It should be
            noted that the range Min VCI to Max VCI refers only to the
            incoming VCI range that can be supported by the associated
            port on each of the virtual paths in the range Min VPI to
            Max VPI. No restriction is placed on the values of outgoing
            VCI's that may be written into the cell header.
            Use of the Label Range message allows the range of VCI's to
            be changed on each VPI supported by the port. However, the
            Min VCI and Max VCI fields in the Port Configuration and
            All Ports Configuration messages always report the same
            default values regardless of the operation of the Label
            Range message.

   For a port over which the GSMP protocol is operating, the VCI of the
   GSMP control channel may or may not be reported as lying within the
   range Min VCI to Max VCI. A switch should honour a connection
   request message that specifies the VCI value of the GSMP control
   channel even if it lies outside the range Min VCI to Max VCI.


8.4 Port Type Specific Data for Frame Relay

   If PortType=FR, the Default Label Range Block have 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |x|S|x|x|    FR Label (0x101)   |          Label Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |x x x x|Res|Len|                   DLCI                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Sundell                  Expires û April 2004                [Page 31]


                 GSMPv3 Packet Capable Switch Support     October 2003


        Res
           The Res field is reserved in [9], i.e. it is not
           explicitly reserved by GSMP.

        Len
           This field specifies the number of bits of the DLCI. The
           following values are supported:

           Len  DLCI bits
           0    10
           2    23

        Min DLCI, Max DLCI
           Specify a range of DLCI values, Min DLCI to Max DLCI
           inclusive. The values SHOULD be right justified in the 23-
           bit fields and the preceding bits SHOULD be set to zero. A
           single DLCI may be specified with a Min DLCI and a Max DLCI
           having the same value. In a request message, if the value
           of the Max DLCI field is less than or equal to the value of
           the Min DLCI field, the requested range is a single DLCI
           with a value equal to the Min DLCI field. Zero is a valid
           value.


8.5 Port Type Specific Data for MPLS

   The Default Label Range Block for PortTypes using MPLS labels. These
   types of 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 [11]. Ports of the Type MPLS has 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |x|x|x|x| MPLS Gen Label (0x200)|          Label Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |x|x|x|x|x|x|x|x|x|x|x|x|              MPLS Label               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


       Min MPLS Label, Max MPLS Label
           Specify a range of MPLS label values, Min MPLS Label to Max
           MPLS Label inclusive. The Max and Min MPLS label fields are
           20 bits each.




Sundell                  Expires û April 2004                [Page 32]


                 GSMPv3 Packet Capable Switch Support     October 2003



8.6 Port Type Specific Data for FEC

   The Default Label Range Block for PortTypes using FEC labels is not
   used. The Label Range Count and Label Range Length fields defined in
   [7][8.2.1] should be set to 0.


8.7 Service Configuration

   The Service Configuration message is defined in [7]. This chapter
   defines the Capability Set Records, carried in the Service Records,
   in a Service Configuration message. A Service Configuration message
   carries a sequence of zero or more Service Records. The switch
   returns one Service Record for each Service that it supports on any
   of its ports. A Service record contains the configuration data of
   the specified Service. Each Service Record has 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Service ID           |  Number of Cap. Set. Records  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                     Capability Set Records                    ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Service ID
          The Service ID Field identifies the Service supported by the
          port. The Services are defined with their Service ID values
          as described in [7].

       Number of Cap. Set. Records
          Field gives the total number of Capability Set Records to be
          returned in the Service Record field.

       Capability Set Records
          The switch returns one or more Capability Set Records in
          each Service Record. A Capability Set contains a set of
          parameters that describe the QoS parameter values and
          traffic controls that apply to an instance of the Service.
          Each Capability Set record has the following format:







Sundell                  Expires û April 2004                [Page 33]


                 GSMPv3 Packet Capable Switch Support     October 2003



       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Cap. Set ID          |       Traffic Controls        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     CLR       |                     CTD                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Frequency   |                     CDV                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Capability Set ID
          The value in this Field defines a Capability Set ID
          supported by the switch. The values of a Capability Set ID
          are assigned by the switch and used in Port Configuration
          messages to identify Capability Sets supported by individual
          ports. Each Capability Set Record within a Service Record
          MUST have a unique Capability Set ID.

       Traffic Controls
          Field identifies the availability of Traffic Controls within
          the Capability Set. Traffic Controls are defined as part of
          the respective Service definition, see Chapter 9. Some or
          all of the Traffic Controls may be undefined for a given
          Service, in which case the corresponding Flag is ignored by
          the controller. The Traffic Controls field is formatted
          into Traffic Control Sub-fields as follows:

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

          Traffic Control Sub-fields have the following encoding:

             0b00 Indicates that the Traffic Control is not available
                  in the Capability Set.

             0b01 Indicates that the Traffic Control is applied to all
                  connections that use the Capability Set.

             0b10 Indicates that the Traffic Control is available for
                  application to connections that use the Capability
                  Set on a per connection basis.

             0b11 Reserved



Sundell                  Expires û April 2004                [Page 34]


                 GSMPv3 Packet Capable Switch Support     October 2003



          Traffic Control Sub-fields:

             U: Usage Parameter Control
                  The Usage Parameter Control sub-field indicates the
                  availability of Usage Parameter Control for the
                  specified Service and Capability Set.

             D: Packet Discard
                  The Packet Discard sub-field indicates the
                  availability of Packet Discard for the specified
                  Service and Capability Set.

             I: Ingress Shaping
                  The Ingress Shaping sub-field indicates the
                  availability of Ingress Traffic Shaping to the Peak
                  Cell Rate and Cell Delay Variation Tolerance for the
                  specified Service and Capability Set.

             E: Egress Shaping, Peak Rate
                  The Egress Shaping, Peak Rate sub-field indicates
                  the availability of Egress Shaping to the Peak Cell
                  Rate and Cell Delay Variation Tolerance for the
                  specified Service and Capability Set.

               S: Egress Traffic Shaping, Sustainable Rate
                  The Egress Shaping, Sustainable Rate sub-field, if
                  set, indicates that Egress Traffic Shaping to the
                  Sustainable Cell Rate and Maximum Burst Size is
                  available for the specified Service and Capability
                  Set.

               V: VC Merge
                  The VC Merge sub-field indicates the availability of
                  ATM Virtual Channel Merge (i.e., multipoint to point
                  ATM switching with a traffic control to avoid AAL5
                  PDU interleaving) capability for the specified
                  Service and Capability Set.


          QoS Parameters
             The remaining four fields in the Capability Set Record
             contain the values of QoS Parameters. QoS Parameters are
             defined as part of the respective Service definition, see
             Chapter 9.6 [To be referred].
             Some or all of the QoS Parameters may be undefined for a
             given Service, in which case the corresponding field is
             ignored by the controller.


Sundell                  Expires û April 2004                [Page 35]


                 GSMPv3 Packet Capable Switch Support     October 2003



             CLR: Cell Loss Ratio
                  The Cell Loss Ratio parameter indicates the CLR
                  guaranteed by the switch for the specified Service.
                  A cell loss ratio is expressed as an order of
                  magnitude n, where the CLR takes the value of ten
                  raised to the power of -n, i.e., log(CLR)=-n.
                  The value n is coded as a binary integer, having a
                  range of 1 <= n <= 15.
                  In addition, the value 0b1111 1111 indicates that no
                  CLR guarantees are given.

             Frequency
                  The frequency field is coded as an 8 bit unsigned
                  integer. Frequency applies to the MPLS CR-LDP
                  Service (see Section 10.4.3). Valid values of
                  Frequency are:

                    0 - Very frequent
                    1 - Frequent
                    2 - Unspecified

             CTD: Cell Transfer Delay
                  The CTD value is expressed in units of microseconds.
                  It is coded as a 24-bit integer.

             CDV: Peak-to-peak Cell Delay Variation
                  The CDV value is expressed in units of microseconds.
                  It is coded as a 24-bit integer.


9. Service Definitions

   In the GSMP Service Model a controller may request the switch to
   establish a connection with a given Service. The requested Service
   is identified by including a Service ID in the Add Branch message or
   the Reservation Message. The Service ID refers to a Service
   Definition (defined in chapter 10 of [7]). The Service IDÆs for L2
   and Packet capable switches are in the range 1-127. This chapter
   defines the various Service IDÆs for L2 and Packet capable switches.

   The following Service Identifiers are defined for Packet Capable
   switches:

             ID          Service Type

             1           CBR= 1
             2           rt-VBR.1
             3           rt-VBR.2

Sundell                  Expires û April 2004                [Page 36]


                 GSMPv3 Packet Capable Switch Support     October 2003


             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-29      Reserved
             30         Frame Relay Service
             31-63      Reserved
             64          Int-Serv Controlled Load
             65-69       Reserved
             70          MPLS CR-LDP QoS
             71-127      Reserved


9.1 ATM CBR

   Service Identifier:
      CBR.1 - Service ID = 1

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

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

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

   Traffic Controls, see [7]:
      - (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


9.2 ATM rt-VBR

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

Sundell                  Expires û April 2004                [Page 37]


                 GSMPv3 Packet Capable Switch Support     October 2003



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

   Traffic Parameters, see [7]:
      - 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


9.3 ATM 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 [14].

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

   QoS Parameter:
      - Cell Loss Ratio

   Traffic Controls, see [7]:
      - (U) Usage Parameter Control
      - (I) Ingress Traffic Shaping to the Peak Cell Rate
      - (E) Egress Traffic Shaping to the Peak Cell Rate

Sundell                  Expires û April 2004                [Page 38]


                 GSMPv3 Packet Capable Switch Support     October 2003


            and Cell Delay Variation Tolerance
      - (S) Egress Traffic Shaping to the Sustainable Cell Rate
            and Maximum Burst Size
      - (P) Packet Discard
      - (V) VC Merge


9.4 ATM UBR

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

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

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

   QoS Parameter:
      None

   Traffic Controls, see [7]:
      - (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
      - (P) Packet Discard
      - (V) VC Merge


9.5 ATM ABR

   ABR is not supported in this version of GSMP.


9.6 ATM GFR

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

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

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

Sundell                  Expires û April 2004                [Page 39]


                 GSMPv3 Packet Capable Switch Support     October 2003


      - Minimum Cell Rate
      - Maximum Burst Size
      - Maximum Frame Size

   QoS Parameter:
      - Cell Loss Ratio

   Traffic Controls, see [7]:
      - (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

9.7 Frame Relay

   Service Identifier:
      Frame Relay Service - Service ID = 30

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

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

   QoS Parameters:
      None.

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

9.8 Integrated Services - Controlled Load

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

   Service Characteristics:
      See [16].

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

Sundell                  Expires û April 2004                [Page 40]


                 GSMPv3 Packet Capable Switch Support     October 2003



   QoS Parameter:
      None.

   Traffic Controls:
      None.


9.9 MPLS CR-LDP

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

   Service Characteristics:
      See [17].

   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. 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 9. The format and encoding of these parameters are
   given below.


10.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

Sundell                  Expires û April 2004                [Page 41]


                 GSMPv3 Packet Capable Switch Support     October 2003


      - Maximum Frame Size

   are defined in [14]. 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:

       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 9 in the order
   given there.


10.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 [16]. 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 [16]. They are encoded as 32 integer in units of
   bytes.










Sundell                  Expires û April 2004                [Page 42]


                 GSMPv3 Packet Capable Switch Support     October 2003


   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.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 [17] 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 [17] 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. The
   Traffic Parameters Block for the CRLDP Service is as follows:








Sundell                  Expires û April 2004                [Page 43]


                 GSMPv3 Packet Capable Switch Support     October 2003


       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.4 Traffic Parameters for Frame Relay Service

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

   are defined in [15]. Format and encoding of these parameters for
   frame relay signaling messages are defined in [18]. (Note than in
   [18] the Committed Information Rate is called "Throughput".) GSMP
   uses the encoding defined in [18] 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        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       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).



Sundell                  Expires û April 2004                [Page 44]


                 GSMPv3 Packet Capable Switch Support     October 2003


       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)

11. Traffic Controls (TC) Flags

   The TC Flags field, in Add Branch messages for connections using the
   Service Model, is 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.

        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.

Sundell                  Expires û April 2004                [Page 45]


                 GSMPv3 Packet Capable Switch Support     October 2003



        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 of [7]) 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.

12. Events

   Editors note: Currently there is no use of the recently added
   Extensions Value field in Event messages. The Block Length for
   Message Types 80-85 and Tech Types = 0x01 and 0x02 will be 0. Still
   need to examine the effects for Message Type = 86 (Recovery Event).


13. Failure Response Codes

13.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.



Sundell                  Expires û April 2004                [Page 46]


                 GSMPv3 Packet Capable Switch Support     October 2003


   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.)

   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. Note
   that failure codes that are general for GSMPv3 are defined in [7].


13.2 Connection Failures

   The following two Failure response codes (11 and 12) are general for
   GSMPv3 and already specified in [7], this subsection specifies how
   theses Failure response codes should be interpreted in the case of
   ATM virtual path connections.

   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.3 ATM Virtual Path Connections

   The GSMPv3 as specified in [7], does not specify how ATM virtual
   path connection failures are handled. This subsection specifies
   Failure response codes for these cases.

   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. One or both of the requested input and output ports

Sundell                  Expires û April 2004                [Page 47]


                 GSMPv3 Packet Capable Switch Support     October 2003


       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.


Appendix A  Summary of Extended Messages


   Message Name                     Message Number


   Connection Management Messages

   Add Branch
      ATM Specific - VPC............26

   Move Output Branch
      ATM Specific - VPC............27

   Move Input Branch
      ATM Specific - VPC............28



Security Considerations

   The security of GSMP's TCP/IP control channel has been addressed in
   [8]. 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 [8].




Sundell                  Expires û April 2004                [Page 48]


                 GSMPv3 Packet Capable Switch Support     October 2003






References


   1  Bradner, S., "The Internet Standards Process -- Revision 3",
      BCP 9, RFC 2026, October 1996.

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

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

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

   5  Doria, A., Hellstrand, F., Sundell, K., Worster, T., "General
      Switch Management Protocol version 3", RFC 3292, June 2002.

   6  Doria, A., Sundell, K., "General Switch Management Protocol
      Applicability", RFC 3294, June 2002.

   7  Doria, A., "GSMPv3 Base Specification", Work in progress, draft-
      ietf-gsmp-v3-base-spec-04.txt, October 2003.

   8  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.

   9  Conta, A., et al, "Use of Label Switching on Frame Relay
      Networks", RFC 3034, January 2001.

   10 "Integrated Services Digital Network (ISDN) Data Link Layer
      Specification For Frame Mode Bearer Services",
      ITU-T Recommendation Q.922, 1992.

   11 Rosen, E., et al, "MPLS Label Stack Encoding",
      RFC 3032, January 2001.

   12 Anderson, L., et al, "LDP Specification",
      RFC 3036, January 2001.

   13 IANA Assigned Port Numbers, http://www.iana.org

Sundell                  Expires û April 2004                [Page 49]


                 GSMPv3 Packet Capable Switch Support     October 2003





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

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

   16 Wroclawski, J., "Specification of the Controlled-Load Network
      Element Service", RFC 2211, Sep. 1997.

   17 Jamoussi, B., et al. "Constraint-Based LSP Setup using LDP",
      RFC 3212, January 2002.

   18 "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", ITU-T Recommendation Q.933, 1995.





cknowledgments

   <Add any acknowledgements>


uthor's Addresses

   Kenneth Sundell
   Nortel Networks
   S:t Eriksgatan 115A
   SE-11585 Stockholm, Sweden
   Phone: +468 5088 3538
   Email: ksundell@nortelnetworks.com













Sundell                  Expires û April 2004                [Page 50]