The IP over ATM Mailing List Archive by date[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Multicasting with ATM - a concern
Rick Bubenik writes: > There is an alternative that allows AAL5 to be used for mpt-to-mpt > connections. Namely, set up the connection as a switched VP and > either: 1) allocate a unique VCI to each transmitter or 2) set aside > a block of VCIs and have each transmitter randomly select a value > prior to sending a packet. The first approach guarantees no > interleaving, but requires a VCI assignment protocol (relatively > simple, but not trivial). The second approach allows occasional > interleaving, with an interleave probability that can be controlled > (based on the range of VCIs set aside and the number of expected > simultaneous transmitters). > > The advantage of using a true mpt-to-mpt ATM level service is that > only one connection need be set up to each participant and there is > no single point of failure. Also, this solution scales to very > large multicasts. I am confused. pt-mpt VPC's, like pt-mpt VCC's, are unidirectional. That is, they have one root (sender) and multiple leaves (receivers). To my knowledge there is no 'true mpt-to-mpt ATM level service'. mpt-mpt connectivity is a concept, not a service, whose most direct analogue at the ATM layer will be a mesh of pt-mpt connections. The difficulty in supporting true mpt-mpt is in bandwidth allocation (i.e., in the connection-oriented nature of ATM). It seems to me that servers like the MARS are going to be needed indefinitely, to provide mpt-mpt emulation by magically adding a user to or removing a user from, multiple pt-mpt VCC's. The existing MARS can likely be improved through the use of Leaf Initiated Join and Proxy Signaling (2 features of ATM Forum UNI 4.0). Rick was one of the authors of this work; perhaps he'd care to rough out the changes required to pick it up? Tim Dwight MCI |
|