The IP Over NBMA (ION) Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Integrated service does not scale over non-IP large cloud
[On scaling of multicast over a large ATM cloud] kowens@tellabs.com wrote: [ ... ] > > The proper answer is: > > > > "Sure, the Internet and the Catenet model will work." > > > > which obsoletes RFC1620 and NHRP. > > > > Masataka Ohta > > > No, the proper answer is there is a solution to every problem if one has the > intelligence to look in the correct places! Perhaps so, but what Masataka says in draft-ohta-mcast-large-cloud-01.txt is pretty undeniable: "For example, both the Internet with RSVP signaling and ATM networks with UNI 4.0 Q.2931 [maybe that should be Q.2971?] signaling scale. "The problem proven in this memo is that such scalability is lost when IP signaling mechanism, such as RSVP, is used *over* a non-IP large cloud such as a large Q.2931 signaled ATM network." [Emphasis mine.] This problem, which Masataka briefly describes, is philosophically the same as routing loop problems when two global but incompatible routing schemes are used simultaneously (IP and ATM). Of course solutions can be found, but they might very well _not_ lie in the simple layering of one scheme _on top of_ the other. For example, perhaps I-PNNI is going to be needed to solve the routing loop problems (I think it is). Perhaps the same type of approach will be needed here, to allow ATM large clouds to multicast IP intelligently. I happen to believe that an ATM solution will be needed, simply because the IP solution itself is incomplete (for integrated services), as we've already discussed. So I'm not convinced that just using RSVP with CSRs will be _the_ solution. But I also cannot buy the idea that RSVP layered over UNI 4.0, for example, necessarily must be a workable solution. It very well might be unworkable. Bert manfredi@engr05.comsys.rockwell.com
|
|