The IP Over NBMA (ION) Archive

[Tim Dwight <0006078043@mcimail.com>]

I guess I'm confused too.  In particular, I don't know what the 
discussion has to do with the topic, since whether or not ATM rate
control is useful to IP has nothing to do with whether IP multicast
over ATM will scale.  For that to be so, someone would have to prove
that (a) IP multicast over ATM requires pt-mpt ABR, and either (b1) IP 
multicast over ATM+ABR won't scale, or (b2) pt-mpt ABR will not exist.

>From your mail it seems that mapping an IP+RSVP multicast tree directly
to an ATM pt-mpt VCC (with or without ABR), would today be difficult.  
This has been noted by others in the past.  The problem is that currently
ATM signaling does not support dynamic re-negotiation of the traffic
parameters (the equivalent of flowspec) associated with a VCC.  


best regards,

tim

> 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