The IP over ATM Mailing List Archive by date

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

if (a big if) you allocate a separate VCI/VPI for each source in a multipoint
session, then it can index the analagous state as the source does in IP
multicast quite happily.....if this state indicates a _set_ of sources
associated with a multipoint destination (which is the case, since
there is the conversation id used in the call setup), then you could
do the resequencing at the last switch before each receiver....or in
the receiver h/w....

or, you could allocate a VPI for the group, and a VCI for each source
if only there wasn't such a small VCI/VPI address space...

some folks say its too late to change, but i assert that there isnt
much deployed kit (compared, say, to OSI, or IP networks:-), so whats
the problem?

actually, itd be interesting to know how many switches actually have a
large cell laberl space internally, since its irrelvant what is seen
at the UNI for a circuit based net - the associateion between the
label and the actual multipoint group is done at call time, so so long
as we could increase the address space in the NNI, we could do the
multipoint-multipoint routing quite neatly - so here is a proposal

instead of stealing precious data space from the user by proposing a
MID for AAL5 (AAL5++, or AAL5 double cross as i heard someone refer to
it:-), we propose an _encapsulation_ of the cell in a multipoint
distribution protocol with a new global
group address header stuck on the front....(and the VCI/VPI address
space is then used for source identification - or vice versa - no
special preference...)

of course its going to break those systems already deployed, but then
better that than they break all the hosts already deployed - this
could be done transparently for Q.2931 or other signaling efforts, but
would involve NNI (Integrated multipoint private NNI - imp nii)....

of course there are those that argue that there is no need for so many
active sources, and so they can use the VPI/VCI hack above
instead...or suffer the signaling traffic...

cheers

jon