The IP over ATM Mailing List Archive by date

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

 >Also, I don't think you would need a layer 3 device at every merge point.

agree...

 >All you really need is something above the SAR layer that relays AAL5 SDUs.
 >This would not have to have any layer 3 awareness.  All that needs to be done 
 >is to re-assemble AAL5 SDUs and relay them out on the appropriate hop to the 
 >next switch (or next VC).  This is basically what an MCS is.

there are three approaches to supporting the IP multicast _model_
1/ use a MID type field
2/ do de-interleaving at all merge points
3/ use globally significant VCIs for multicast traffic...
and allocate different ones for different sources....
(i.e. put the MID mcast function  into the VC Identifier space)

the cost tradeoffs are clear - the MID uses bandwidth, but at the
gain of not introducing queueing/reassembly delays

the SAR de-shredder approach doesn;'t lose you the capacity, but
costs silicon (though as some people have said, for good IP support
for epd etc, you may have a lot of the silicon already)

the MID could be the IP source address....or we coulddefine AAL5.5,
which is AAL5 with a MID and a Bit...

.....any other possibilities, tradeoffs?

 jon