The IP over ATM Mailing List Archive by date

[Tim Dwight <0006078043@mcimail.com>]

Rick writes:

> > 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).
> 
> I'm aware of several ATM switches that support a true mpt-to-mpt
> (bidirectional) ATM level service.  The degree to which they solve
> the traffic problem varies, where some are better than others.
> The ideal building block would be a switch that can support (true)
> mpt-to-mpt connections for ABR.  However, I'm not sure whether
> the Forum's ABR mechanism is amenable to this.


There is no definition in the standards (ITU-T or ATM Forum) of how to
build mpt-to-mpt connections.  There are no or inadequate service 
descriptions, and none of the detailed support in traffic management,
signaling and network management that would be required to standardize
the service.  If somebody is selling mpt-to-mpt ATM today it's a
proprietary implementation, and not something the ip-atm group can
build upon.

This has nothing to do with ABR, and I'd appreciate it if these petty
digs would cease.

Tim