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

From: [email-masked]
Date: Mon, 6 Mar 2000 09:11:38 -0600

Hi,

I am in the process of trying to fold your changes into
the spec before the deadline for the upcoming meeting.
by and large I accept all of it, though, due to other
changes necessitated by adding TLV type labels to support
the CES labels, I may end up shifting some of the bits around.

One comment I don't understand was the ability to eliminate
the MTYPE.  The solution you have proposed works fine for the 
default/standard service model being offered in GSMP.  The purpose
of the MTYPE was to allow vendors and carriers to define a 
completely different service model or resource model if they so 
desired.  In which case they would not append the encap method and 
traffic block as you have designed, but would instead append one 
of their own.

regards, 

a.
-----------------------------------
avri doria
Office: +1 781 993 4645
Mobile: +1 781 308 7680                

> -----Original Message-----
> From: EXT Clint Bishard [mailto:[email-masked]]
> Sent: 15 February, 2000 6:10 PM
> To: [email-masked]
> Cc: Bishard, Clint
> Subject: 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 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.
> 
> 
>

---

From: Clint Bishard <[email-masked]>
Date: Mon, 06 Mar 2000 13:53:03 -0600

Avri,

Thanks for the feedback.  Does your comment of accepting the changes mean
that you are working these into the latest GSMP draft (or I guess actually
updating it since the duel Service Selector was already in the last draft).
Some of the discussion was that a joint ID may need to be submitted to
institute these changes.  Is this still necessary?

Concerning the TLV labels, is this necessary since the type of label will
already be known by the controller and switch given the type of port that
was defined?

I probably do not fully understand the MTYPE.  However, the concept I
understood was that an MTYPE was defined for the switch, and then all
connections were built given that MTYPE.  However, connections are no longer
built under this assumption.  Each connection message states the connection
parameters separately for each port and no parameters regarding the switch
type are conveyed in the connection messages.  Doesn't this now negate the
need for a MTYPE being defined?

Thanks for your work Avri,
Clint

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Monday, March 06, 2000 9:12 AM
To: [email-masked]
Subject: RE: GSMP/MSF Forum Joint editing session concerning
contribution 14

Hi,

regards,

a.