Subject: RE: QOS parameters for the service model

From: [email-masked]
Date: Fri, 8 Oct 1999 15:24:00 +0300

> 
> I did not mean that the qos be per connection. What I meant
> is that the only allowed qos parameters are CLR, CTD, CVD and 
> frequency.
> For example, if some service model allows average cell 
> transfer delay (as
> opposed to the maximum cell transfer delay) as a parameter, would GSMP
> support it?

I think I  agree that we should not limit the service parameter list
too strictly.

Is there a set of service parameters that you suggest be added?
Or are you suggesting a mechanism?

>    
>       2. The QOS parameter values are selected by the switch for each
>          capability set and cannot be specified by the GSMP 
> controller. It
>          would be better if both options are allowed.

What concerns me here is an increase in complexity;
especially if we first make adding QoS parameters flexible,
then add flexibility in parameters values.  Adding variable values
would seem to necessitate adding value negotiation.

Are you suggesting a mechanism?

a.
-----------------------------------
avri doria
+1 617 678 9402

---

From: Mahesan Nandikesan <[email-masked]>
Date: Fri, 8 Oct 1999 16:32:47 -0400 (EDT)

Yes, we are thinking of a mechanism.

For the qos parameter types,
we can use bit-masks. Every parameter is given a code. More
parameters can be added in the future by giving them new codes.  This is
similar to the MType field in the ARM and the Service ID field in the
service model (except that MType and Service ID not use bit-masks).
An example is given below:

Suppose that the mask 8 bits long and is defined as follows (an
example):

 Bit 0: CTD
 Bit 1: CDV
 Bit 2: CLR
 Bit 3: Frequency
 Bit 4: Average cell transfer delay
 Bit 5: Average gap loss
 Bit 6: Reserved for future extensions
 Bit 7: Reserved for future extensions

Then, a bit mask value of 1110100 (bit 0 on the left) returned by the
switch would mean that the switch supports the following qos paramters:
CTD, CDV, CLR, average gap loss (since those bit-positions are '1'.

For the qos parameter values, we are working out a mechanism.
The basic idea is similar to that used for negotiating
the MType in the ARM.

Mahesan