> >> In the ATM world, PNNI certainly is more evolved than standard OSPF, > >> but it still would need extension for current concepts of traffic > >> engineering. Why do the work twice, once for IP and once for ATM? > >> Optical routing is another concern; I've been bothered that layer 1 > >> optical folk again are reinventing routing algorithms usually > >> described as "based on OSPF," but that really aren't that different > >> than OSPF with additional constraints and the opaque LSA. > > > >That's exactly what I'm talking about. I think that MPLS's best use by far > >was its original conception which was to give carriers a completely > >generalized control-plane mechanism with which they could bind their WAN > >switches, their ADM's, their routers, and whatever else - > > Am I correct, then, that you see the core of MPLS control as > variously LDP, CR-LDP, or RSVP-TE? These are all literally path > setup protocols. What is the intelligence that tells them the > possible path topology? Manual provisioning?
Manual provisioning if necessary. LDP/RSVP in IP. PNNI (or a PNNI-complement) when dealing with ATM. Some other way to deal with ADM's, DACS systems, and those other physical-layer gear. An interworking method to combine all the various methods. This would be the ideal. Now, granted, this would be difficult. But I would contend that much of the IP work is done or close to it. Yet there seems to be correspondingly much less work done for other technologies, except for just forcing carriers to upgrade those technologies to understand IP. > > >and they could do > >so on their own pace and using their existing gear without requiring > >upgrades or fancy interworking. Instead, MPLS seems to now have effectively > >become a 'feature' of IP - if you want to use MPLS, you must use IP. > > > I would agree with your last statement, but I don't see what the > alternative is for topology discovery, fast failover without massive > redundancy ala SONET, etc. I would argue that MPLS could take advantage of the same dynamic discovery techniques available in PNNI. > > > > > > >I'm thinking of all the ATM signalling parameters, especially PNNI. Also > >UNI, things like that. > > > >You asked above of why do the work twice (once for IP, once for PNNI) if you > >want to incorporate current concepts of TE. But my question is, why force > >the current concepts of TE onto PNNI? Why not build out specs for MPLS to > >handle the existing PNNI parameters? Carriers who use PNNI seem to be fine > >with the existing PNNI feature set, so why force them to adopt a different > >TE model before they're ready? > > Again, I'm a little confused by what you mean by MPLS. There are at > least three logical parts: > > MPLS forwarding, presumably to include GMPLS non-packet-forwarding, > MPLS path setup > Topology information to guide MPLS path setup > and, if you split it up, fast failover, shared risk groups, > and the like. I am concerned at this time with path setup and the requisite topology information. > > > > >I can see a situation where a carrier with an existing ATM network can drop > >in MPLS switches that have the complete ATM control-plane built in, > >therefore not requiring that the carrier upgrade all its switches. > > That's not implausible. That additional board for MPLS is really an > IP control plane engine. I'm unclear how MPLS path setup signaling > would coexist with ATM path setup, or if they'd be ships in the night. The same that exists in the new Lucent multiservice switch (can't remember the name) that effectively interworks MPLS signalling with PNNI signalling. > > > As the > >existing ATM switches are retired, they are replaced with these MPLS > >switches. Eventually there will be no more legacy gear and everything will > >be MPLS. The point is that the carrier smoothly transitioned from legacy to > >modern technology. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=54514&t=53737 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
