The IP over ATM Mailing List Archive by date

[Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>]

 >like it or not, this is how it is when talk about multi-point to point
 >flows.  atm switch can't handle those without store and forward.  but so
 >far atm forum or itu have not defined mp-to-p atm connections at all,
 >which means that you need to use a real layer 3 device at every point
 >when merging of flows takes place.
 
 juha


if the net is providing QoS support, and the unit of synchronisation
at the reecivers is a frame and not an ATM cell, there is no
contradiciton in the net having to be aware of the frame boundairies
as well as the cell boundaries - in fact, some switches that are very
smart might observe that MANY computer based applications will be
acommodated more easily and with a better QoS match if there are 2 (or
even 3) leaky buckets - one for packet (or frame) length bursts of
cells, one for the actual VBR (and the third if you have a dual leaky
bucket VBR server)........a very very smart switch might do the sort
of "converse" of MTU discovery - i.e. it might _learn_ the AAL5 MTU
and use this to adjust its buffering....i.e. you don;t have to do more
than have  deliberating _aliasing_ effect i nthe tiem granularity of
your cell policing and forwarindg scheduler....


cheers

 jon