The IP Over NBMA (ION) Archive

[Albert Manfredi <manfredi@engr05.comsys.rockwell.com>]

mohta@necom830.hpcl.titech.ac.jp wrote:

> > I think pt-mpt ABR can be useful for IP, but I agree with your concern
> > about the non-usefulness (or non-scalability, anyway) of any service
> > which constrains the throughput of the multicast tree according to the
> > rate of the slowest branch.
> 
> My concern is that no rate control policy of ATM is useful to IP.

I guess I don't understand this thread.

There is nothing inherent in RSVP that ATM doesn't have to address in 
essentially the same way. Let's keep in mind that RSVP is, after all, 
emulating circuit-switched systems! What better than ATM to do it 
right?

RSVP says, "... a single physical interface may receive multiple 
reservation requests from different next hops for the same session and 
with the same filter spec, but RSVP should install only one reservation 
on that interface. The installed reservation should have an effective 
flowspec that is 'largest' of the flowspecs requested by the different 
next hops. Similarly, a RESV message forwarded to a previous hop should 
carry a flowspec that is 'largest' of the flowspecs requested by the 
different next hops ..."

Now tell me, what is there in the above quote that an ABR leaf-initiated 
join multicast that UNI 4.x must support would not do? I see NOTHING 
unique or profound in that RSVP statement. If RSVP can juggle flowspecs 
according to new leafs joining, what makes this any more or less 
difficult or more or less essential in a native ATM implementation?

I'll agree that we can't forever fudge UNI 3.1 capabilities to meet all 
future IP features.

> My concern is that no rate control policy of ATM is useful to IP.

To respond to this, I would say that no ATM LIJ would be useful without 
natively supporting the pretty doggoned self-evident requirements 
mentioned in RSVP.

Bert
manfredi@engr05.comsys.rockwell.com