Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2297

Ipsilon's General Switch Management Protocol Specification Version 2.0

Pages: 109
Informational
Updates:  1987
Part 4 of 4 – Pages 86 to 109
First   Prev   None

Top   ToC   RFC2297 - Page 86   prevText
9.6 QoS Connection Management Message

   The QoS Connection Management message is used by the controller to
   establish and modify virtual channel connections and virtual path
   connections across the switch which require QoS parameters to be
   specified. The functionality of the QoS Connection Management message
   is identical to that of the Add Branch connection management message
   with the additional specification of QoS parameters.  No specific QoS
   connection release messages are defined. QoS connections may be
   released with the Delete Tree, Delete All, and Delete Branches
   messages defined in Section 4, "Connection Management Messages." When
   a QoS connection is released, all associated QoS resources are
   released.

   There are three styles of connection with specified QoS parameters:

   QoS Connection:
      This connection style specifies its own individual QoS parameters
      and is routed independently to the waiting room and output port
      specified in the QoS Connection Management message. It is not a
      member of a QoS class. Each output branch of a point-to-multipoint
      QoS connection may specify its own QoS parameters which may be
      different from all other output branches of that point-to-
      multipoint QoS connection, if the switch supports this capability.
      However, all output branches must specify identical connection
      policer parameters. A QoS Connection Management message requesting
      this style of connection is identified by a QoS Class Identifier
      with the value 0xFFFFFFFF.
Top   ToC   RFC2297 - Page 87
   QoS Class Connection:
      This connection style does not specify its own individual QoS
      parameters. It is a member of a QoS class, and the QoS parameters
      are specified by the QoS class.  It is, however, routed
      independently to the waiting room and output port specified in the
      QoS Connection Management message.  Each output branch of a
      point-to-multipoint QoS Class Connection must use the same QoS
      parameters. A QoS Connection Management message requesting this
      style of connection will have a valid QoS Class Identifier and a
      valid Scheduler Identifier.

   QoS Class Member:
      This connection style does not specify its own individual QoS
      parameters. It is a member of a QoS class, and the QoS parameters
      are specified by the QoS class.  The QoS class also specifies the
      waiting room and output port to which all members of the class are
      routed. This style of connection does not support point-to-
      multipoint connections. A QoS Connection Management message
      requesting this style of connection will have a valid QoS Class
      Identifier and a Scheduler Identifier with the value 0xFFFF.

   To request a virtual channel connection with specified QoS
   parameters, the Virtual Channel Connection (VCC) QoS Connection
   Management message is:

      Message Type = 100.

   To request a virtual path connection with specified QoS parameters,
   the Virtual Path Connection (VPC) QoS Connection Management message
   is:

      Message Type = 101.

   The QoS Connection Management message has the following format for
   both request and response messages:
Top   ToC   RFC2297 - Page 88
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    | Message Type  |    Result     |     Code      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Transaction Identifier                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Port Session Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Input Port                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|Q|B|C|      Input VPI        |          Input VCI            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Output Port                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |x x x x|      Output VPI       |          Output VCI           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Number of Branches       |     Scheduler Identifier      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      QoS Class Identifier                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Regulator   | Excess Action |       Connection Weight       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |S|A|x x x x x x|   Reserved    |      Excess Scheduler Id      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                         UPC Parameters                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                      Regulator Parameters                     ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Port Session Number
   Input Port
   Input VPI
   Input VCI
   Output Port
   Output VPI
   Output VCI
   Number of Branches
             The definition of these fields is exactly the same as
             defined for the Add Branch message in Section 4.1,
             "Connection Management Messages."
Top   ToC   RFC2297 - Page 89
   M B C Flags
             The definition of the M, B, and C flags is exactly the same
             as defined in Section 4, "Connection Management Messages."
             They apply to the QoS Connection Management message exactly
             as defined for the Add Branch message.

   Q: QoS Profile Flag The QoS Profile flag is not used in the QoS
             Connection Management message.

   Scheduler Identifier
             For QoS Connection and QoS Class Connection styles, the
             Scheduler Identifier points to the waiting room, on the
             output port specified by the Output Port field, to which
             all conforming traffic on the connection should be routed.
             The values 0 -- 255 specify the default settings for the
             scheduler. Each of the default values maps directly to one
             of the scheduler priority levels. A Scheduler Identifier in
             the range 0 -- 255 may be used without first being
             established by a Scheduler Establishment message. All
             Scheduler Identifiers in the range 0x0100 to 0xFFFE must
             first be established by a Scheduler Establishment message.

             A Scheduler Identifier with a value of 0xFFFF indicates
             that a QoS Class Member connection style is being
             requested. In this connection style, the waiting room and
             output port are specified by reference to the QoS class
             specified by the QoS Class Identifier field. In this case
             the QoS Class Identifier field must contain a valid QoS
             Class Identifier.

   QoS Class Identifier
             For QoS Class Connection and QoS Class Member connection
             styles, the QoS Class Identifier specifies the QoS Class to
             which the connection belongs. It must first be established
             by a QoS Class Establishment message and must have a value
             greater than 0 and less than 0xFFFFFFFF.

             A QoS Class Identifier with a value of 0xFFFFFFFF indicates
             that a connection of style "QoS Connection" is being
             requested. In this connection style, the connection does
             not belong to a QoS class. All QoS parameters are specified
             by the QoS Connection Management message and apply only to
             the specified connection.

   Regulator
   Excess Action
             The Regulator and Excess Action parameters are only used in
             connection requests of style "QoS Connection." The
Top   ToC   RFC2297 - Page 90
             definition of these fields in the QoS Connection Management
             message is exactly the same as defined for the QoS Class
             Establishment message with the exception that they apply to
             an individual connection rather than to an entire QoS
             class.

   Connection Weight
             This field is only used in connections of style "QoS
             Connection" and "QoS Class Connection." For QoS Class
             Member style connections, the QoS Class Weight parameter of
             the QoS Class Establishment message should be used to
             assign a weight to the QoS Class.

             If bit 0 of the Scheduler Flags field of the QoS
             Configuration message indicates that weighted service may
             be applied to a connection, the Connection Weight parameter
             specifies the share of the bandwidth available to the
             waiting room that should be given to this connection.

             The Connection Weight is an unsigned 16-bit field
             specifying a binary fraction.  I.e. the bandwidth share, as
             a fraction of the bandwidth available to the waiting room,
             is given by:

                Bandwidth share = Connection Weight * 2**(-16)

             A Connection Weight of zero indicates equal sharing between
             all connections in this waiting room that request a
             Connection Weight of zero.  While a 16-bit field is used to
             specify the Connection Weight it is understood that the
             accuracy of the bandwidth sharing is hardware dependent and
             is not specified.

             For connections of style "QoS Class Connection," if the
             Regulator function of the QoS Class is specified as None,
             or Policer, the Connection Weight should be applied to the
             waiting room pointed to by the Scheduler Identifier field
             in the QoS Connection Management message. If the Regulator
             function of the QoS Class is specified as Shaper, the
             Connection Weight should be applied to the waiting room
             pointed to by the Excess Scheduler Id field in the QoS
             Connection Management message.

             For connections of style "QoS Connection," if the Regulator
             field of the QoS Connection Management message specifies
             None, or Policer, the Connection Weight should be applied
             to the waiting room pointed to by the Scheduler Identifier
             field. If the Regulator field of the QoS Connection
Top   ToC   RFC2297 - Page 91
             Management message specifies Shaper, the Connection Weight
             should be applied to the waiting room pointed to by the
             Excess Scheduler Id field.

             If the specified waiting room is unable to offer weighted
             sharing for a connection, a failure response message should
             be returned with the failure code indicating: "this waiting
             room is unable to offer weighted sharing for a connection."

   QoS Flags

        S: Selective Discard
             If the Selective Discard flag is set, only cells with the
             Cell Loss Priority (CLP) bit set will be subject to the
             discard mechanism when the number of cells in the waiting
             room exceeds the Discard Threshold.  If the Selective
             Discard flag is zero, all cells (CLP=0 and CLP=1) will be
             subject to the discard mechanism when the number of cells
             in the waiting room exceeds the Discard Threshold.
             Selective discard can be combined with packet discard. In
             this case only packets in which at least one cell has the
             CLP bit set will be subject to the discard mechanism.

        A: All Branches
             For a QoS Connection Management message that specifies a
             point-to-multipoint connection, if the All Branches flag is
             set, all branches of the point-to-multipoint connection
             must be set to the QoS parameters specified in the message.
             If the All Branches flag is zero, only the single output
             branch specified in the message should be set to the QoS
             parameters specified in the message. For a QoS Connection
             Management message that specifies a point-to-point
             connection, the All Branches flag is not used.

        x: Unused

   Excess Scheduler Id
             For connections of style "QoS Connection" and "QoS Class
             Connection," the Excess Scheduler Id points to the waiting
             room, on the output port specified by the Output Port
             field, to which all excess traffic should be routed. The
             values 0 -- 255 specify the default settings for the
             scheduler. Each of the default values maps directly to one
             of the scheduler priority levels. An Excess Scheduler Id in
             the range 0 -- 255 may be used without first being
             established by a Scheduler Establishment message. All
Top   ToC   RFC2297 - Page 92
             values of Excess Scheduler Id in the range 0x0100 to 0xFFFE
             must first be established by a Scheduler Establishment
             message.

             If this field is not used it should be set to 0xFFFF.  The
             Excess Scheduler Id must not point to the same waiting room
             on the same output port as the Scheduler Identifier.

   UPC Parameters
             All connection styles may be subject to a Usage Parameter
             Control (UPC) function, also known as a connection policer.
             The policing function is applied to each individual
             connection before it is combined with other connections
             into a QoS class by the classifier function. A policing
             function applied to an entire QoS class is defined in the
             QoS Class Establishment message.

             The connection policer is defined by reference to the
             Generic Cell Rate Algorithm (GCRA) defined by the ATM Forum
             [af-tm-0056], although any equivalent policing algorithm
             may be used. The GCRA takes two parameters, the increment
             (I) and the limit (L). The reciprocal of the increment
             (1/I) specifies the rate being policed. The limit specifies
             the burst tolerance. (For comparison with the token bucket
             policer discussed in [Partridge], the size of the token
             bucket is given by L/I.)

             Two policers in series may be specified to permit the
             policing of both peak rate and average rate (also called
             sustainable rate). The parameters for the first policer are
             Increment-1 and Limit-1. For comparison with the ATM Forum
             specification these would be used to police the Peak Cell
             Rate (PCR) and Cell Delay Variation Tolerance (CDVT)
             respectively. The parameters for the second policer are
             Increment-2 and Limit-2. For comparison with the ATM Forum
             specification these would be used to police the Sustainable
             Cell Rate (SCR), and Burst Tolerance.  (The Burst Tolerance
             may be computed from the Maximum Burst Size [af-tm-0056].)

             There are two configurations in which the two policers may
             be connected in series.  In the All Cells configuration,
             all cells (cells with the Cell Loss Priority (CLP) bit set
             to zero and cells with the CLP bit set to one) are subject
             to the policing action of both policers in series. In the
             CLP Selective configuration, all cells, both CLP=0 and
             CLP=1, are policed by the first policer; but only cells
Top   ToC   RFC2297 - Page 93
             with CLP=0 are subject to policing by the second policer.
             Either tagging or discard may be specified for each of the
             policer configurations.

             The values of the parameters Increment and Limit in the UPC
             Parameters fields are given in terms of a time unit
             specified by the switch in the QoS Configuration Parameters
             message. The time unit is specified by the switch as a
             rate, the Scaling Factor, which gives the rate in cells per
             second that would result from an Increment parameter value
             of one. Thus to determine the value of the Increment
             parameter from the desired policed rate given in cells per
             second:

                Increment parameter = (Scaling_Factor)/(policed_rate)

             To determine the value of the Limit parameter from the
             desired Cell Delay Variation Tolerance (CDVT) given in
             seconds:

                Limit parameter = CDVT * Scaling_Factor

             To determine the value of the Limit parameter from the
             desired Burst Tolerance (BT) given in seconds:

                Limit parameter = BT * Scaling_Factor

             The Increment and Limit parameters are specified as 32-bit
             unsigned integers; so the choice of the Scaling Factor
             allows the switch to select the range and granularity of
             the policer parameters with respect to the line rate of the
             switch port.  For example, a SONET STS-3c (155.52 Mbps)
             switch port has a line rate of approximately 353 kcells/s.
             With a Scaling Factor value of 353,000,000 we can specify a
             policed rate slightly less than the line rate with a
             granularity of 0.1%. For a policed rate of 1 kbps we can
             still support a bucket size of 31 cells.

             The UPC Parameters have the following format:
Top   ToC   RFC2297 - Page 94
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Increment-1                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Limit-1                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Increment-2                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Limit-2                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Reserved                     |C|A|x x x x x x|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Increment-1
             The increment parameter for the first policer, specified as
             a 32-bit unsigned integer.  A value of zero for the
             Increment-1 parameter is used to disable the first policer.
             In this case all cells will be considered to conform to the
             traffic parameters of the first policer.

   Limit-1
             The limit parameter for the first policer, specified as a
             32-bit unsigned integer.

   Increment-2
             The increment parameter for the second policer, specified
             as a 32-bit unsigned integer.  A value of zero for the
             Increment-2 parameter is used to disable the second
             policer.  In this case all cells will be considered to
             conform to the traffic parameters of the second policer.

   Limit-2
             The limit parameter for the second policer, specified as a
             32-bit unsigned integer.

   Flags

        C: Configuration
             If the Configuration flag is set, the policer should be set
             to the All Cells configuration. If the Configuration flag
             is zero, the policer should be set to the CLP Selective
             configuration.

             In the All Cells configuration, all cells (both CLP=0 and
             CLP=1) are subject to the policing action of both policers
             in series. In the CLP Selective configuration, all cells,
             both CLP=0 and CLP=1, are policed by the first policer; but
Top   ToC   RFC2297 - Page 95
             only cells with CLP=0 are subject to policing by the second
             policer. Either tagging or discard may be specified for
             each of the policer configurations.

        A: Action
             If the Action flag is zero, discard is required as the
             policing action. If the Action flag is set, tagging is
             required as the policing action.

             If tagging is selected in the All Cells configuration, any
             cell with CLP=0 in either policer, that the policer
             determines to be in excess of the specified policer
             parameters, will be changed to CLP=1. If discard is
             selected in the All Cells configuration, any cell (CLP=0 or
             CLP=1) in either policer, that the policer determines to be
             in excess of the specified policer parameters, will be
             discarded.

             In the CLP Selective configuration, the first policer is
             always set to discard any cell (CLP=0 or CLP=1) that it
             determines to be in excess of its specified policer
             parameters. If tagging is selected in the CLP Selective
             configuration, the second policer will change the CLP bit
             to CLP=1 of any cell that it determines to be in excess of
             its specified parameters. If discard is selected in the CLP
             Selective configuration, the second policer will discard
             any cell that it determines to be in excess of its
             specified parameters.

             To configure the policer for the conformance definitions
             specified by the ATM Forum [af-tm-0056] the following
             configurations are suggested:

                CBR.1:   One policer,     All Cells,        Discard
                VBR.1:   Two policers,    All Cells,        Discard
                VBR.2:   Two policers,    CLP Selective,    Discard
                VBR.3:   Two policers,    CLP Selective,    Tagging
                UBR.1:   One policer,     All Cells,        Discard
                UBR.2:   One policer,     All Cells,        Tagging.

        x: Unused

   Regulator Parameters
             Only connections of style "QoS Connection" require the
             Regulator Parameters to be specified in the QoS Connection
             Management message. For connections of style "QoS Class
             Connection" and "QoS Class Member" the Regulator Parameters
             are specified in the QoS Class Establishment message.
Top   ToC   RFC2297 - Page 96
             The Regulator Parameters are specified in a similar manner
             to the UPC parameters. If the regulator function is
             specified as Policing, a single GCRA policer is applied to
             all cells (both CLP=0 and CLP=1) on the connection. The
             policer takes two parameters: an increment, the Regulator
             Increment, and a limit, the Regulator Limit. The reciprocal
             of the increment (1/I) specifies the rate being policed.
             The limit (L) specifies the burst tolerance. (For
             comparison with the token bucket policer discussed in
             [Partridge], the size of the token bucket is given by L/I.)

             The Regulator Increment and Regulator Limit parameters are
             32-bit unsigned integers. Their values are determined in
             terms of the Scaling Factor specified by the switch in the
             QoS Configuration Parameters message. To determine the
             value of the Regulator Increment parameter from the desired
             policed rate given in cells per second:

                Regulator Increment = (Scaling_Factor)/(policed_rate)

             For a policed rate (r) the GCRA policer guarantees that
             over any time period T the amount of traffic determined by
             the policer to be conforming to the traffic parameters does
             not exceed:

                rT + L/I

             The value of the Regulator Limit may be determined from
             this relation.

             If the regulator function is specified as Shaping, only the
             Regulator Increment parameter is used. The Regulator Limit
             parameter is not used. The value of the Regulator Increment
             parameter is determined in terms of the Scaling Factor
             specified by the switch in the QoS Configuration Parameters
             message. To determine the value of the Regulator Increment
             parameter from the desired shaper rate, given in cells per
             second, on output from the shaper:

                Regulator Increment = (Scaling_Factor)/(shaper_rate)

             An Increment value of zero is used to disable the policer.
             In this case all cells on that connection will be
             considered to conform to the policer traffic parameters. A
             shaper given a Regulator Increment parameter of zero will
             perform no shaping function on that connection.

   The Regulator Parameters have the following format:
Top   ToC   RFC2297 - Page 97
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Regulator Increment                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Regulator Limit                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

9.7 QoS Failure Response Codes

   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.  The following additional
   failure codes are defined for use in response to QoS messages.
   General failure codes are specified in Section 3.2, Failure Response
   Messages.

       128: Weighted scheduling within this waiting room is unavailable.
       129: This waiting room is unable to offer weighted sharing for a
              QoS class.
       130: This waiting room is unable to offer weighted sharing for a
              connection.
       131: Scheduler Identifier still in use.
       132: QoS Class Identifier still in use.
       133: Invalid QoS parameter.
       134: Insufficient QoS resources.
       135: Any point-to-multipoint connection arriving on this input
              port must use the same QoS parameters for all output
              branches.


10. Adjacency Protocol

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

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

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    | Message Type  |     Timer     |M|     Code    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Sender Name                          |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                         Receiver Name                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Sender Port                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Receiver Port                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sender Instance                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Receiver Instance                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

   Message Type
             The adjacency protocol is:

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

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

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

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

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

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

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

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

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

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

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

   The rules and state tables use the following operations:

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

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

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

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

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

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

        C    The Receiver Instance, Receiver Port, and Receiver Name
             fields in the incoming message match the values of the
             Sender Instance, Sender Port, and Sender Name currently
             sent in outgoing SYN, SYNACK, and ACK messages.

        "&&" Represents the logical AND operation

        "||" Represents the logical OR operation

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

    o A timer is required for the periodic generation of SYN, SYNACK,
      and ACK messages. The value of the timer is announced in the Timer
      field.  The period of the timer is unspecified but a value of one
      second is suggested.
Top   ToC   RFC2297 - Page 102
      There are two independent events: the timer expires, and a packet
      arrives. The processing rules for these events are:

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

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

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

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

State Tables

State: SYNSENT

+======================================================================+
|     Condition      |                Action               | New State |
+====================+=====================================+===========+
|    SYNACK && C     |  Update Peer Verifier; Send ACK     |   ESTAB   |
+--------------------+-------------------------------------+-----------+
|    SYNACK && !C    |            Send RSTACK              |  SYNSENT  |
+--------------------+-------------------------------------+-----------+
|        SYN         |  Update Peer Verifier; Send SYNACK  |  SYNRCVD  |
+--------------------+-------------------------------------+-----------+
|        ACK         |            Send RSTACK              |  SYNSENT  |
+======================================================================+
Top   ToC   RFC2297 - Page 103
State: SYNRCVD

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


State: ESTAB

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

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

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

10.3 Loss of Synchronization

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

   The preferred procedure for a switch to use when it looses
   synchronization with its active controller is to attempt to establish
Top   ToC   RFC2297 - Page 104
   synchronization with (one of) its backup controller(s).  However, in
   this preferred approach, it must not reset its state until it
   achieves synchronization with a backup controller.  This means that
   if, before achieving synchronization with a backup controller, it
   regains synchronization with its original controller, it may continue
   the original session (and cease attempting to establish
   synchronization with a backup controller). If synchronization with
   the original session is regained it is the responsibility of the
   controller to ensure consistent state between the switch and
   controller.

   While the above is the preferred procedure, it is also the case that
   the simplest procedure when declaring loss of synchronization with
   the active controller is to reset the switch state, and start
   searching for a controller.  This simple procedure is legitimate.

11. Summary of Failure Response Codes

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

        1: Unspecified reason not covered by other failure codes.
        2: Invalid request message.
        3: The specified request is not implemented on this switch.
        4: Invalid Port Session Number.
        5: One or more of the specified ports does not exist.
        6: One or more of the specified ports is down.
        7: Unused. (This failure code has been replaced by failure codes
             18--21.)
        8: The specified connection does not exist.
        9: The specified branch does not exist.
       10: A branch belonging to the specified point-to-multipoint
             connection is already established on the specified output
             port and the switch cannot support more than a single
             branch of any point-to-multipoint connection on the same
             output port.
       11: The limit on the maximum number of point-to-multipoint
             connections that the switch can support has been reached.
       12: The limit on the maximum number of branches that the
             specified point-to-multipoint connection can support has
             been reached.
       13: Unable to assign the requested VPI/VCI value to the requested
             branch on the specified point-to-multipoint connection.
       14: General problem related to the manner in which point-to-
             multipoint is supported by the switch.
       15: Out of resources (e.g. memory exhausted, etc.).
       16: Failure specific to the particular message type. (The meaning
             of this failure code depends upon the Message Type. It is
Top   ToC   RFC2297 - Page 105
             defined within the description of any message that uses
             it.)
       17: Cannot label each output branch of a point-to-multipoint tree
             with a different label.
       18: One or more of the specified input VPIs is invalid.
       19: One or more of the specified input VCIs is invalid.
       20: One or more of the specified output VPIs is invalid.
       21: One or more of the specified output VCIs is invalid.
       22: Invalid Class of Service field in a Connection Management
             message.
       23: Insufficient resources for QoS Profile.
       24: Virtual path switching is not supported on this input port.
       25: Point-to-multipoint virtual path connections are not
             supported on either the requested input port or the
             requested output port.
       26: Attempt to add a virtual path connection branch to an
             existing virtual channel connection.
       27: Attempt to add a virtual channel connection branch to an
             existing virtual path connection.
       28: Only point-to-point bidirectional connections may be
             established.
       29: Cannot support requested VPI range.
       30: Cannot support requested VCI range on all requested VPIs.
       31: The transmit cell rate of this output port cannot be changed.
       32: Requested transmit cell rate out of range for this output
             port.
      128: Weighted scheduling within this waiting room is unavailable.
      129: This waiting room is unable to offer weighted sharing for a
             QoS class.
      130: This waiting room is unable to offer weighted sharing for a
             connection.
      131: Scheduler Identifier still in use.
      132: QoS Class Identifier still in use.
      133: Invalid QoS parameter.
      134: Insufficient QoS resources.
      135: Any point-to-multipoint connection arriving on this input
             port must use the same QoS parameters for all output
             branches.


12. Summary of Message Set

   The following table gives a summary of the messages defined in this
   version of the specification. It also indicates which messages must
   be supported in a minimal implementation of the protocol. Those
   messages marked as "Required" must be supported by the switch for an
   implementation to be considered to conform to this specification.
   (While the controller should also implement those messages marked
Top   ToC   RFC2297 - Page 106
   "Required," conformance cannot be tested for the controller due to
   the Master-Slave nature of the protocol.)

       Message Name                Message Type    Status

   Connection Management Messages
       Add Branch VCC....................16        Required
                  VPC....................26
       Delete Tree.......................18
       Delete All........................20
       Delete Branches...................17        Required
       Move Branch VCC...................22
                   VPC...................27

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

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

   Configuration Messages
       Switch Configuration..............64        Required
       Port Configuration................65        Required
       All Ports Configuration...........66        Required

   Event Messages
       Port Up...........................80
       Port Down.........................81
       Invalid VPI/VCI...................82
       New Port..........................83
       Dead Port.........................84

   Quality of Service Messages
       QoS Configuration.................96
       Scheduler Establishment...........97
       QoS Class Establishment...........98
       QoS Release.......................99
       QoS Connection Management VCC....100
                                 VPC....101

   Adjacency Protocol....................10        Required
Top   ToC   RFC2297 - Page 107
REFERENCES

   [af-tm-0056] ATM Forum Traffic Management Specification 4.0, af-tm-
                0056.000, April 1996.

   [I.361]      "B-ISDN ATM Layer Specification," International
                Telecommunication Union, ITU-T Recommendation I.361,
                Mar. 1993.

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

   [IpsilonMIB] Ipsilon IP Switch MIB,
                http://www.ipsilon.com/products/ips.mib

   [Partridge]  C. Partridge, "Gigabit Networking," Addison-Wesley,
                1994.

   [RFC1700]    Reynolds, J., and J. Postel, "Assigned Numbers," STD 2,
                RFC 1700, October 1994.

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


SECURITY CONSIDERATIONS

   Physical security on the control link connecting the controller to
   the switch is assumed. Security issues are not discussed in this
   document.


AUTHORS' ADDRESSES

   Peter Newman                        Phone: +1 (408) 990 2003
   Nokia                               EMail: pn@ipsilon.com

   W. L. Edwards, Chief Scientist      Phone: +1 (913) 534 5334
   Sprint                              EMail: texas@sprintcorp.com

   Robert M. Hinden                    Phone: +1 (408) 990 2004
   Nokia                               EMail: hinden@ipsilon.com

   Eric Hoffman                        Phone: +1 (408) 990 2010
   Nokia                               EMail: hoffman@ipsilon.com
Top   ToC   RFC2297 - Page 108
   Fong Ching Liaw                     Phone: +1 (408) 873 2688
   Coppercom                           EMail: fong@coppercom.com

   Tom Lyon                            Phone: +1 (408) 990 2001
   Nokia                               EMail: pugs@ipsilon.com

   Greg Minshall                       Phone: +1 (650) 237 3164
   Fiberlane Communications            EMail: minshall@fiberlane.com

Nokia (Sunnyvale) is located at:

   232 Java Drive
   Sunnyvale, CA 94089
   USA

Sprint is located at:

   Sprint
   Sprint Technology Services - Long Distance Division
   9300 Metcalf Avenue
   Mailstop KSOPKB0802
   Overland Park, KS 66212-6333
   USA

Fiberlane Communications is located at:

   1399 Charleston Road
   Mountain View, CA 94043
   USA
Top   ToC   RFC2297 - Page 109
Full Copyright Statement

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

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

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

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