The IP over ATM Mailing List Archive by date

[Grenville Armitage <gja@thumper.bellcore.com>]

Joel,

>>While working on the MPOA material for the ATM Forum, several of us
>>were discussing multicast support.  Our goal has been to make use of
>>the effort put in by Grenville and the IP/ATM working group on this
>>problem.

I'm about half-way through generating an MPOA version of the MARS
protocol, so I have some thoughts on this.

(just re-arranging a bit..)

>>[If there is something which does this already in ipmc-06, my apologies
>>for posting before having time to read the most recent spec.]

No, there's nothing in ipmc-06 to address the re-sizing of the CMI.
Your comments are quite appropriate.

	[..]
>>However, it is clear that in the long run one will want to be able
>>to relax restriction 2 above.  And do so without needing a new
>>packet format.

I tentatively agree with your first observation, but disagree with the
second.

On the first observation...

The scope over which the CMI is unique is certainly an important
question. However, I dont entirely share your concern that having
a scope of > 65k unique identifiers (approximately the current limit)
is a near-term or mid-term goal. The reason I say this is that the
real problem is not with picking a unique value, but co-ordinating
its use across all the clusters/LISs you may wish to 'cut-through'
(given that I assume this is the scenario you are alluding to?)

Or to phrase it differently, if the source identifier is to be
dynamically assigned, the infrastructure (e.g. inter-linked MARSs)
need to co-ordinate. If the source identifier is to be static, then
you side-step this problem to some degree. (as a matter of fact, I
have been toying with multi-cluster models where each MARS doles
out CMIs in non-overlapping blocks. 'cut through' traffic would
carry CMIs that were locally assigned {where 'local' is the scope
of the source's cluster} but still globally unique provided your
definition of 'global' was < 65k endpoints. Of course, cut-through
would have to stop at the edge of the region of co-operating MARSs.)

>>This means that a short, locally assigned, source identifier will not work.
>>The source identifier for multicasts needs to be a value that is
>>gloablly (or nearly globally) unique.

I deliberately avoided this when pushing the extended encaps that is
currently in ipmc-06 because 'global' means 'many bytes long', which
makes it less attractive for high speed interfaces that need to
perform match/keep/discard operations on every PDU that arrives with
the 'extended encaps' LLC/SNAP header. It struck me that we have
a trade-off between providing more performance for the definately
local (intra-cluster, or at least intra-cooperating-clusters)
multicast packet traffic (i.e. a small source ID), and complete
generality (globality?) of a 6 or 8 byte source ID (perhaps taken
from the ESI+SEL of the MARS client).

Which leads me to the second observation....

It is in fact not at all clear to me that we should try to
avoid another LLC/SNAP code-point to identify an 'extended
encapsulation with much bigger source ID' payload. On the
contrary I think it would be a perfect way to introduce a
new encaps at some future time when such cut-through scenarios
are shown to be necessary and acceptable from a performance
standpoint.

Regardless of all the above, I must point out an alternative
solution to the dilemma.

	(a) Limit 'cut through' to groups where the sources
	    establish direct VCs to the group members (i.e. NOT
	    through an MCS).
	(b) Modify receive side of MARS clients so that packets
	    arriving with CMI of 0 are _always_ accepted.
	(c) Cause senders to insert CMI = 0 when they are transmitting
	    on a direct VC.

Point (a) completely elimitates the need for extended encaps
(Do we want to restrict the use of MCSs in this way? What
does it mean to allow an MCS to use 'cut through' ?)

Point (b) is trivial.

Point (c) requires certain additional knowledge to be passed
back in the MARS_MULTIs (but this can be achieved by defining
a suitable supplementary parameter [section 10 of ipmc-06],
and I am presupposing that some sane mechanism actually exists
for a MARS to resolve all a group's members across a global
scope.)

We can thus keep small CMIs for speedy processing within the
confines of a cluster or group of clusters whose MARSs have
coordinated the CMI allocation. No new-new encaps needed.

Blatantly stupidities in the above text will be blamed on
the hour of the morning.

cheers,
gja