Cell Relay Archive

Cell Relay Retreat>List Archive>month:1998-Oct> msg00130



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Re: [Q] Overbooking of CBR connections

  • From: nulldevice <nulldevice@eli.net>
  • Date: Thu, 22 Oct 1998 23:19:39 GMT



Daniel J. Wentzel wrote:

> Question -
>
> If there are sufficient CBR reservations made on a (theoretical) switch,
> my understanding is that the switch will provide the requested SCR up to
> the limit of the line (OC3c, etc. less overhead).  However, suppose that
> a user is not actively transmitting any traffic, then this situation
> seems to reduce to a standard TDM mux with all of it's associated
> inefficiencies.

For ATM systems, 2 processes interact: the call admission control [CAC]and
the cell processing. The mechanism for each is vendor specific, but
each has specific functions governed by ATM Forum and ITU specs.

At PVC provisioning time or SVC setup time, the CAC looks at the traffic
contract and service objectives (subset of PCR, SCR, MBS, MCR, CDV, CDVT,
Delay, CLR) and says "Yes I can meet the objective and admit this call" or
"No I can't meet the objective and reject the call". The mechanism is
proprietary
and statistical. Typically the operator of the switch can adjust the CAC
parameters
to allow oversubscription, usually of the VBR-nrt, ABR and UBR classes.
This increases the statistical probability that the service objectives will
not be
met, particularly for the non-realtime based classes, in congested periods.
So oversubscription is a CAC function.

There is a real time queueing and priority system which deals with each cell

in the switch. Typically CBR has the highest priority, VBR-rt the next and
on
down to UBR. There might be 2 priorities, 4, 16, or more. Some switches
have class queues and some have per-VC queueing. Typically, the non-realtime

VC cells are queued to let the real-time VC cells go through first. All of
this is
vendor specific. So if the CBR VC is transmitting idle cells, the lower
priority
VC's can "reuse" the bandwidth that the CAC "reserved" for the CBR.

The complication is the AAL used by the application. Typically with AAL1,
which is used for many CBR applications, the AAL1 frames are emitted
at the PVC peak cell rate, even if there is no user data. The ATM switch
will forward these cells at the highest priority, end to end. So no one else

can "reuse" the bandwidth of the PVC.

> Here is a more detailed explanation of my situation for those
> interested:  I work for the US government, and so the normal rules of
> economics don't always apply :).  Generally, I provide communications
> service to users and we are recently migrating towards ATM on our LAN's.
> When a customer needs service, depending on the available
> infrastructure, they need not pay for anything.  Requirements still must
> be justified but generally this is not too difficult to do....
>
> So we end up with ridiculous situations where customers ask for more
> resources than they need (because they haven't done a good analysis of
> their real requirements) and then 'sit' on the bandwidth.  Migrations
> towards IP solutions have helped this situation since there is inherent
> resource sharing by doing this (instead of dedicated lines connected to
> systems, users now have IP capable devices that all sit behind a router
> with it's own dedicated serial line).  Again, this has helped, but only
> so far.
>
> So I'm basically trying to find out if ATM is going to help this
> situation.  Perhaps the answer is 'it depends on the vendor'?

ATM and frame relay are designed exactly with this in mind: the VC
meshexactly corresponds to the private line mesh between LAN sites. Since
LAN traffic is bursty, the VC peak rates can be overbooked by about
250-600%+.
This number should be adjusted if there is additional realtime traffic as
opposed
to client/server or typical Intra/Internet. This will save you quite a bit
over a private
line solution. An added advantage is that you can easily adjust the VC
bandwidth based on actual use or growth. I would strongly advise against
using
a CBR traffic contract for LAN traffic. You will not be able to add realtime

traffic later. For LAN data, you will get better performance (a lot better)
if
the VC is set for early packet discard and partial packet discard. You can
discuss
with your vendor whether to turn policing on or off.

One caveat: you will need to probe your LAN to ATM or frame equipment
vendor to determine exactly how they support what traffic contract. Many
will set the peak rate of the VC to the line rate no matter how you
configure
them.

R Wilcox
Electric Lightwave