Subject: AW: [msf-switch] GSMP/MSF Forum Joint editing session concerning contribution 14

From: "Buerkle Joachim (UC-ON/EMY2) *" <[email-masked]>
Date: Wed, 16 Feb 2000 09:09:14 +0100

Hi Clint,
isn't it necessary to have also the following fields

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |           SubMessage Number   |           Length              | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

after the row of partion ID and transaction ID and before the message body?

"""
SubMessage Number:
	- When a message is segmented because it exceeds the MTU of the link
layer, each segment will include a submessage number to indicate its
position. All messages in a segmented message, except for the last segment,
will also have the More bit set. 

Length:
	- Message length including header. 
"""
	(2^16 = 65536 octets)

According to
http://www.ietf.org/internet-drafts/draft-ietf-gsmp-encaps-00.txt
the MTU in the AAL5 case is:
	"The maximum transmission unit (MTU) of the GSMP Message field is
1492 octets."
the MTU in the Ethernet case is:
	"The maximum transmission unit (MTU) of the GSMP Message field is
1492 octets."

You are right if you say these fields are not part of the current connection
message in
http://www.ietf.org/internet-drafts/draft-ietf-gsmp-03.txt
but at least for my implementation I expected this to be a typo.
See also the definition of the GSMP message header in chapter 3.1 of the
current GSMP draft:

"""
    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                     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |           SubMessage Number   |           Length              | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   ~                          Message Body                         ~ 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
"""

Please correct me if I'm wrong that I can correct my implementation.

Regards
Joachim 

- - - - - - - - - - - - - - - - - - - - - 

> -----Ursprüngliche Nachricht-----
> Von:	Clint Bishard [SMTP:[email-masked]]
> Gesendet am:	Dienstag, 15. Februar 2000 23:11
> An:	[email-masked]; [email-masked]
> Cc:	Bishard, Clint
> Betreff:	[msf-switch] GSMP/MSF Forum Joint editing session concerning
> contribution 14
> 
> 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 bulleted changes listed
> 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 v.3.
> 
> 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.
> 
> 
>  << Datei: GSMP_Contribution14.doc >>

---

From: Clint Bishard <[email-masked]>
Date: Thu, 17 Feb 2000 16:04:32 -0600

Buerkle,

Thanks for the feedback.  Your suggestion is mentioned at the beginning of
section 3.1 of the latest internet draft (due to expire June 24th).
However, the connection message format listed in section 4.1 does not
contain the fields.  I assume the GSMP editors must have missed this field
from the connection message format.  Is this correct?
Furthermore, I noticed the additional 'Reservation ID' field which had been
added in the latest draft.

Therefore, the new recommended format, (with these two additional
components) is shown below as follows:

New Connection Message Format illustrating the possible needed changes for
this proposal to specify parameters for both ports in a connection. (typed
in Courier New, size 10)

  0                   1                   2                   3
 |                         Reservation ID                        |

Under certain conditions (iQMS or oQMS set such that traffic parameters are

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.

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.

-----Original Message-----
From: Buerkle Joachim (UC-ON/EMY2) *
[mailto:[email-masked]]
Sent: Wednesday, February 16, 2000 2:09 AM
To: [email-masked]'
Cc: [email-masked]'; [email-masked]'
Subject: AW: [msf-switch] GSMP/MSF Forum Joint editing session
concerningcontribution 14

Hi Clint,

"""
SubMessage Number:

Length:

According to

"""
    0                   1                   2                   3

Regards
Joachim