Cell Relay Archive

[Baris Aksoy <baris@phoenixdsl.com>]

Hi,

When a line card designer wants to test the traffic shaping, she/he can use different AALs for testing. However, for the traffic shaper, it doesn't need to know which kind of AAL inside VCs explicitly. Because, when a VC connection is established either by Call Admission Control - signalling-  or manually, there are some parameters required by the application, for example :

> - data --> AAL5 --> use VBR-nrt
> - voice --> AAL1 --> use CBR (or AAL2 --> use VBR-rt)
> - video --> AAL5 -- > use VBR-rt
Those requirements from the application, defines the "traffic parameters"
of that connection. Moreover, "QoS parameters" are assigned to that connection.
All those defined in "Traffic contract" of your connection.

So, in the traffic shaper, decisions are done based on those negotiated parameters (traffic and QoS) for that specific connection. As soon as a cell is received, specific parameters are looked-up from the cell memory during header translation phase. At the end, VPI/VCI is replaced with specific descriptor of that connections based on their contract, etc.

It is true that it seems AALs implicitly affects traffic shaping, but the real source is application.

As an example, for VoDSL (with VTOA, not VoIP), consider the upstream case (Subscriber --> CO):

> Voice traffic is carried on AAL2, and the e-mail data is carried
> on AAL5, on the same physical pipe: xDSL. Eventually, AAL2 and AAL5, will
> be carried on different VPI/VCIs. When cells are received at the CO's ATM
> line card, first header translation is done to get the parameters specific
> to that connection (VPI/VCI). Then, policing (tag/drop cells) is done in
> order to see if the negotiated parameters (not AAL type) are respected
> or not. After, it goes to ATM switch to be sent to its destination with
> proper traffic&QoS parameters (shaping). Such as, cells containing
> AAL2 packets(eventually VOICE), will have the priority on cells that carry
> AAL5 data in the shaper.
I hope that wil give you some idea, not confusion :-)

Baris
 

Scott Ferguson wrote:

 
If "they" are switch designers debugging timing or firmware problems on
a new line card, and want to do protocol analysis on a Utopia bus or two
with their trusty logic analyzer. I suppose the line card designer can
shape traffic such that he/she knows which vp's/vc's are carrying which
AAL's by using a network analyzer for stimulus.

I work on software tools for decoding AAL's on a UTOPIA bus, being
probed by a logic analyzer.

So it's really a question of "how does a switch designer know which
AAL's are on which channels when debugging a design"; it's not a
question of how a network operator might allocate channels.