The time we came up with a solution – and found a big customer problem One of the more satisfying conference experiences in my career was giving a presentation in the SIGCOMM 2003 Outrageous Opinions session, entitled: MPLS Considered Helpful. The Outrageous Opinion session was at that point about eight years old; I had chaired the first such session in 1995. The inaugural session contained a …
At that time, I, and many others, considered MPLS to just be a continuation of the desperate attempt by telcos to keep a circuit-switching model alive and justify their very high enterprise networking prices - just like ATM and Frame Relay earlier. I often wondered why Cisco seemed so keen on it - I never realised it was partly because they hadn't solved the variable-length-prefix routing lookup problem at that time.
At that time we had bought heavily into the OSI network layer and ,y hardware colleagues had built chips that looked up variable length address prefixes for OSI routing, which we could easily repurpose for IP lookups (both IPv4 and IPv6).
Of course, both enterprise VPN security and capacity reservation (aka "circuits") are useful features that enterprises were interested in buying, but ultimately the price was just too high. MPLS seemed like a solution which reduced the costs slightly (although the telcos looked to be planning to keep that reduction as profit, rather than giving it back to their customers!) but also didn't allow the guarantees the telco circuits had previously provided.
But it was a long time ago now.
Kind of.
I think there were a couple of issues though. Cost is an obvious one. So telcos would offer SDH, Frame Relay, ATM, Internet and other services. All generally run as separate networks, or network layers. So high capex and opex costs to deliver and support each product line.
And customer's were increasingly using those services to create their IPVPNs. This created challenges, ie ATM's 'cell tax', ability to provide good SLA's, or topology decisions. Oh, and having sales who could explain the pros and cons of different services, and leaky buckets. Which lead to stuff like 'fully meshed' networks. That was a bit of a red herring given most customer's traffic flows were client-server, or hub & spoke. Frame Relay could support either, but creating all the VCs needed for a large, full mesh network was painful.
But that's also a pricing issue. ATM and FR networks were typically sold with per-port, and per-VC rental charges, so full or partial meshes could get expensive given the number of VCs needed, especially if there were multiple hubs. Which also lead to product complexity wrt SLA's and service contracts.
So figure on an 11 site network. If hub & spoke, say 1Mbps per VC CIR (Committed Information Rate), the hub connection would neeed to be 100Mbps to honour CIR. If traffic exceeds CIR, then there's a BE, or 'burst excess', typically per VC that is the 'leaky bucket' that defined a frame's discard eligibility. That doesn't necessarily play nicely with IP, which has limited traffic management capability. And as well as per-VC cost/complexity, it could increase port costs. So Ethernet tails and FR ports often weren't a thing, so the hub connection might have needed to be a 155Mbps STM-1, which wasn't cheap. Especially as the hub would also need to be a larger router.
If only there was an easier way.
So enter tag switching, and then MPLS, especially the multi-protocol part. Services just became VPNs, whether RFC2547 IP, or Ethernet leased lines, especially if those needed to be multi-point Ethernet. Just slap a label on the packet or frame, and switch it to the VRF it belonged to. Service providers could strip out service layers, and build MPLS core and edge networks. That saved a lot of money in tin. ATM was great, but ATM switches were very expensive.
It also simplified traffic engineering and management. So instead of provisioning separate, dedicated capacity per service, it just had to provision and manage an MPLS core. So there's more capacity efficiency, and oversubscription potential. The MPLS label contains TE (Traffic Engineering) bits to support QoS and CoS services to deliver decent SLA's. And it's much easier to explain to sales and customers.
Much as I loved ATM, and sometimes did nefarious things with SVCs, MPLS was and especially is a lot simpler and cheaper.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
