Market Leader Programs
5G Transport - A 2023 Heavy Reading Survey
2023 Open RAN Operator Survey
Coherent Optics at 100G, 400G, and Beyond
Open RAN Platforms and Architectures Operator Survey
Cloud Native 5G Core Operator Survey
Bridging the Digital Divide
5G Network Slicing Operator Survey
Open, Automated & Programmable Transport
The Journey to Cloud Native
I agree that MPLS has gathered an awful lot of moss since was positioned as "ATM without the complexity".
But is the best solution to:
A: Put MPLS on a diet. Take the parts you really want, and that help solve the problem you face - in this case for a simple, Ethernet & IP-friendly transport system that supports both dedicated capacity and stat muxing.
B: Invent something totally new and incompatible.
Option B always looks more attractive when you feel that any established technology is getting old and flabby (essentially it's the "grass is greener" viewpoint). But all that happens is that the "skinny new" solution you replace it with eventually ends up being loaded down with "enhancements". That's exactly how MPLS got where it is today.
I'm not going to harp on about the pros and cons of PBT vs T-MPLS, but as a general principle it makes sense to me to back a winning technology. Let's invest in making sure MPLS is fit for purpose - whatever the application.
I don't think there's anything fundamentally wrong with MPLS as a hierarchical labelling scheme. It's all the other baggage it has to carry with it that has to be rationalised. Some we keep, some we throw away.
Cheers,
Geoff
Problem with option A is you are reducing the addressable market of **your** product...somthing not likely to happen....
As for choosing and pruning, it is not endemic to the culture where MPLS originated, which it why we get typically two ways of doing things...let alone deprecating parts of one...
Option B the industry has no real stomach for IMO if you are truly referring to starting from scratch.
And I'm not sure Ethernet fits in the class of "starting from scratch". IEEE has done a pretty good job of keeping the moss off Ethernet for 30 years while progressively enhancing it. I do not believe they are about to change now....
D
I think that PBT (and derivatives) are not inventing a new technology. It is taking an existing technology which is more fit for purpose than MPLS for Layer 2 management. MPLS is way too complex and fat and was created for Layer 3 and above management in a multi-protocol world. If all you want to do is switch and transport pre tagged bits across a flexible optical network why would you pick MPLS or its derivatives?
Anyone who sees the PBT stack immediately gets a blast from the past, it's like what POS did for optical router links vs. ATM.
So the real question is how far you may extend the layer-2 domain?
/Light
We may have to agree to disagree about MPLS being more or less "fit for purpose" than PBT :-)
I think you need to separate three distinct aspects of these architectures:
- The labelling (and therefore switching) aspects (present in both MPLS and PBT)
- The Control Plane (absent in PBT)
- The applications (many and varied for MPLS, only one for PBT)
Let me explain what I mean by these...
Labelling
MPLS offers a simple, hierarchical encapsulation scheme that is not tied to either Layer 2 or Layer 3. For instance, it can be used very successfully with other "MAC Layers", and it could theoretically have been used with other Layer 3 protocols. I suppose the only Layer 3 example of importance today would be IPv6. I think this simple, and easily scalable labelling scheme is genuinely "fit for purpose", so what's not to like?
Control Plane
MPLS began life with a simple Control Plane. I won't get bogged down in discussing this in detail, but suffice to say that since then it grew without any overall idea of what we'd be using MPLS for. (This is not meant as a criticism of the people involved GÇô itGÇÖs pretty tough to predict the future!!). So I think it's perfectly reasonable to take a step back today and discuss how to rationalise it with the benefit of hindsight. This would actually be a very useful exercise if we could do it without too much vendor-specific campaigning. I think Dave made a good point in Post #3 on this.
Applications
MPLS began life as an IP-friendly alternative to ATM. Since then it has been adapted for a wide range of other applications, such as Layer 2 and Layer 3 VPNs, and extending it into the SDH/DWDM layer as a transmission network control plane.
WhatGÇÖs the problem?
ThereGÇÖs too much GÇ£protocolGÇ¥ in the MPLS stack. And the uncoordinated growth of protocol has been triggered by the need to use MPLS for new applications.
I think in isolation you could argue that MPLS has been extremely successful as a technology for Layer 3 VPNs. And in isolation you could make the same argument for MPLS as a Layer 2 VPN technology. You can carry on with such arguments for each of the application areas for which MPLS has been used over the years.
Now we have an interesting application challenge for MPLS as a low cost, simple, GÇ£circuit-switchedGÇ¥ transmission architecture for the delivery of Ethernet services. For this application itGÇÖs clear that the mass of protocol that we now see as GÇ£MPLSGÇ¥ is too flabby. In my personal opinion I think the labelling scheme is fine, but IGÇÖm open to discussion on that.
But the rest of MPLS GÇô the Control Plane and associated GÇ£protocolGÇ¥ that goes with it is pretty bulky. The argument goes that itGÇÖs hard to implement a cheap Ethernet switch that uses MPLS. Similarly the argument goes that itGÇÖs hard to manage MPLS because of all the associated protocols. At the moment IGÇÖm not personally convinced by these arguments, but I could be swayed. I think the issues are being distorted by vendor agendas on both sides (no change there then!)
So the conclusion that is being presented is that MPLS is a poor choice for the delivery of low cost, simple-to-manage Ethernet services GÇô so letGÇÖs turn the clock back to 1995 (which is when the first stirrings of MPLS began) and write something new.
I challenge that conclusion because thereGÇÖs nothing intrinsically wrong with the basic labelling scheme of MPLS. So if the problem lies in the protocol and Control Plane GÇô letGÇÖs fix that.
I also predict that if PBT carries on, that very soon we'll be talking about adding both control plane and application protocols to this "simple solution", and in three years we'll have something as bloated as MPLS is today.
Sorry to ramble :-)
Cheers,
Geoff
Isn't the simplified, transport-centric MPLS that Alwan is looking for T-MPLS (i.e. Transport MPLS as standardised by ITU-T and not MPLS-TE)?
That operates in an identical fashion to PBT, but is based on MPLS as a starting point rather than PBB.
Contrary to many statements made about T-MPLS, it is actually standardised by ITU-T already - just lacking work on ring topologies. It doesn't have a control plane either right now, but being based on MPLS, it's a case of "take your pick"!
When you look at PBT and T-MPLS, which are both addressing a pure "get the bits from here to there" problem, it seems many people are missing the plot. Perhaps the need is just for a reliable transport, like SONET/SDH and that IP/MPLS remains doing what it does well - delivery layer 3 services.
There seems to be a growing consensus that tallies with Basil Alwan's view -- that once PBB-TE is fully-formed it may well have many of the attributes that, according to testimony, can make MPLS challenging to deploy.
I have heard some industry folk refer to PBT as the 'Emperor's New Clothes' -- 2008 might help us decide whether this is anti-PBT spin or more an accurate assessment.
Ray
I do believe in technology that PBT has no difference to MPLS in the end even if there still a gap between two at present.
PBT and MPLS was just a technology to provide the service, MPLS is quite mature to provide almost any service, but PBT which originally proposed to replace the SDH still falling far behind.
Commercially the chipset of both technology will become same or a dual mode chipset will be available .
PBT is evolving to the PBB-TE which introduced the control plane, are they any difference ?
still the control plane will be complated like MPLS, there is no way to simplify the network complexity while provide the same automatic mechanism as MPLS.
the realistic to carrier is stick to mpls as much as possible and take a eye on the PBT.
at present, only mpls can provide all the service that is critical to carrier not the PBT.