Subject: GSMP/MSF Forum Joint editing session concerning contribution 14

From: Clint Bishard <[email-masked]>
Date: Tue, 15 Feb 2000 17:09:31 -0600

All,

This email concerns one of the significant conclusions reached (contribution
14) at the joint GSMP/MSF Switch Control WG meeting on Feb 2.  The three
present GSMP editors agreed to the principle of the requested change and
suggested that the proposal be sent to the GSMP exploder to provide an
opportunity for input/feedback.

The contribution recommends that GSMP’s connection messages be changed such
that they specify parameters for each port in a given connection message
separately - instead of one set of parameters for the connection.  This
change is necessary to be able to build connections across a true
multi-service switch.  (see attachment for more details)

The below PDU format illustrates the changes that would need to be
implemented for the connection messages.  Additionally, comments are
requested concerning the semantics of the changes below and any problems
that anyone can foresee (particularly, the eight listed changes after the
PDU below).

The next step will be to initiate a co-authored ID between Tom Worster and
myself to include these changes into GSMP v3.

Note: I have not addressed the additional issue that came up concerning
separate parameters for policing and reservation, since that simply deals
with a change to the traffic parameters block.

Thank you in advance for your feedback,
Clint Bishard

New Connection Message Format illustrating the possible needed changes for
this proposal (changes are in bold). (typed in Courier New, size 10)

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Version    | Message Type  |    Result     |     Code      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Partition ID  |           Transaction Identifier              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Input Port Session Number                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Output Port Session Number                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Input Port                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |M|B|x|E|                  Input Label                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*~x x x|E|              Extended Input Label                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Input Service Selector                    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Output Port                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |x|x|x|E|                  Output Label                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*~x x x|E|              Extended Output Label                    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Output Service Selector                   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |iQMS|oQMS|T|N|x|x|        Encapsulation Method                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Under certain conditions (iQMS or oQMS set such that traffic parameters are
required) the Add Branch message has an additional, variable length data
block appended to the above message:
*Note: If T above is set, then only one set of Traffic Parameters Block is
required which pertains to both the input and output ports.

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Input TC Flags|                 Reserved                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                  Input Traffic Parameters Block               ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Output TC Flags|                 Reserved                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                  Output Traffic Parameters Block              ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Described Change:
A Input Port Session Number has been added so allow a connection to include
the session number for both the input and output ports.

Added another QMS field - one for the input port (iQMS) and one for the
output port (oQMS) to define the type of QoS Model Selector used at both the
input and output port.

The Service Selector has been changed to reflect one for the input port and
one for the output port.

The input and output Traffic Parameter Blocks have been individualized for
both the input and output ports.

An additional field has been added to describe what encapsulation method is
required to adapt the port technologies for each port to each other.  For
example, FRF.8 or FRF.5 for a connection built between and FR and ATM port.
Tom - you suggested a 32 bit opaque value - would 24 bits be enough.  24
bits seemed to fit easily with the additional QMS, T, and N bit.
Furthermore, I first suggested that an encapsulation would be needed for the
input and the output.  However, after further thought, I think one
encapsulation field specifying what encapsulation is needed between the two
ports should be sufficient.  We are not concerned with what the switch does
in the middle.

The added field 'T' would be used in the case that one set of Traffic
Parameters Block is used for both the input port and the output port.  For
example, the case when the two port types are the same and will use the same
traffic parameters.

The added field ‘N’ would be used to specify a Null encapsulation method.
For example, a connection between two ATM ports.

The MType defined for a switch in the switch configuration messages would no
longer be required and would be removed from those messages.

Note: It is assumed that the switch will determine what characteristics are
needed for the internal connection from the parameters specified for each
port.  For example, if a connection is built across an ATM switch from a FR
port (with given FR parameters for that port) to an ATM port (with given
parameters for that port indicating a nrt-VBR service category) - then the
ATM switch would use the nrt-VBR service category for the internal
connection class, but this would not be directly indicated to the switch in
the connection message.