The IP over ATM Mailing List Archive by date

[Rick Bubenik <rick@stl.nexen.com>]

Tim writes:
>
> 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.

Agreed, although there was a proposal to the ATMF signalling and SAA groups
several months back that addressed the signalling problem and presented
a service definition.  This contribution was not accepted due to
lack of resolution of the traffic problems.  The signalling and
service model aspects were considered to be acceptable.

> If somebody is selling mpt-to-mpt ATM today it's a
> proprietary implementation, and not something the ip-atm group can
> build upon.

Agreed.  However, I think it would be a good idea to standardize
something along these lines in the future, as I believe it has the
potential to yield a better mechanism for multicast.

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

Disagree.  I think it is related to ABR in that a major open issue
is how to solve the traffic problem on mpt-to-mpt connections.  With
CBR and VBR mpt-to-mpt connections, one may need to change the 
bandwidth allocated to the connection as new participants come and
go.  However, with ABR mpt-to-mpt connections, this seems to be
unnecessary.  It may be that the Forum's ABR mechanism could be
enhanced to provide this functionality, which would be very useful.
I do not know enough about the fine details of the mechanism to
know whether this is possible.

	rick

> Tim
> 
> 
>