> >At the risk of starting a religious war, I've never understood why MPLS is > >so IP-centric. It's not called IPLS, it's called MPLS. With only a few > >exceptions, most MPLS initiatives I see presume that devices are running an > >IP stack to handle control-plane mechanisms. > > Look at the evolved GMPLS specification, which deals with > wavelengths, time slots, and physical ports as well as packets. Their > payloads are definitely not limited to IP, but could involve > SONET/SDH frames, lambdas, etc.
It's not the payloads I'm worried about, it's the control plane. Let me say that I haven't read many of the GMPLS spec's, so correct me if I'm wrong. But even with the GMPLS specifications, there seems to be an underlying presumption of an IP control plane, and only an IP control plane. If this is true, then that would mean that anybody who wants to implement GMPLS will be forced to use IP also, perhaps before they are ready to do so. > > 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 - 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. > > > > >MPLS in its original conception seemed to have the potential to be a perfect > >drop-in replacement for ATM. But only if MPLS incorporated all the ATM > >signalling parameters, which hasn't really been implemented (there has been > >some work done, but I would contend that the amount of IP-signalling work > >done and the amount of ATM-signalling work done is at least 10:1) > > I'm not sure which parameters you have in mind. Q.2931? Are you > thinking more of telephony function support or QoS? 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? 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. 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=53825&t=53737 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
