Subject: RE: QOS parameters for the service model

From: [email-masked]
Date: Thu, 7 Oct 1999 20:37:34 +0300

From: EXT Mahesan Nandikesan [mailto:[email-masked]]
> 
> We are working on a couple of Internet Drafts to accommodate the
> IEEE PIN resource and service models in the GSMP framework.
> We have a few questions about the QOS parameters in the GSMP
> service model framework. 
> 
>   1. The QOS parameter set in the capability set appears to be
>      fixed - CLR, CTD, CDV, frequency. Wouldn't it be better to
>      leave it open (like the traffic parameters)?
> 
>   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. 
> 

the idea behind the service model's traffic and qos
parameters is to allow folk to use the cac they 
already have on their atm switches. 

it is very uncommon for atm switches to be able to 
support arbitrary, per connection values of qos 
parameters as well as traffic parameters. in fact, 
many atm switches do not allow the value of  the 
qos parameters to be changed on the fly, instead
they need to be reconfigured. it's a lot harder to
write a service level cac that allows arbitrary, 
per connection qos parameters than it is to 
classify them and apply qos parameters to the 
classes. and if we note also that at the service
level (atm forum services, intserv and the rest)
there is no demand for connections each with their 
own unique values of clr, cdt, and cdv, i can't
see the motivation for allowing this in gsmp's
service model.

the service model was designed as a *high level*
interface that would work with a wide range of
today's switches. the problems you encounter arise
because this high level interface is inappropriate
for a *low level* model such as pin's. i really 
think you are giving yourselves a lot of problems 
by trying to hammer a square peg into a round hole. 

the only technical reason i can imagine for 
putting the pin model into the service model would 
be because you want to establish some gsmp 
connections with atm-forum-style-qos using the on 
switch cac and the service model and other gsmp 
connections with the ieee-pin model. but why would 
one want to do this? with an underlying ieee-pin 
model the controller is much better placed than 
the switch to combine services with the resource 
model. there is a natural layering here, you build
services out of resources; it's hard to run them
as peers.

c u
tom

---

From: Mahesan Nandikesan <[email-masked]>
Date: Thu, 7 Oct 1999 15:06:38 -0400 (EDT)

I think there is a misunderstanding.

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?

Moreover, we are not trying to put the resource model inside the
service model section of GSMP. The IEEE PIN resource model will go
in the ARM section. It has already been assigned MType 1. It is the
IEEE PIN service model that will go in the GSMP service model section.

Finally, I would like to reiterate question #2:

Mahesan