Transcript
Comparing PBB, PBT/PBB-TE, T-MPLS
and MPLS as Next Generation Ethernet
Transport Solutions
Kireeti Kompella
Juniper Fellow
Truth In Advertising
. The title is rather a big mouthful
. No problem --this is not what I’m going to talk about
. The problem at hand is not about technology: which of these proposals is “better” or “should be used”
. This is useful, interesting, controversial, fun; but most of all: done (see Dr. Yakov Rekhter’s presentation last year at this conference)
. The problem is that we are at a crossroads in network architecture in the broadest sense
. We need to look at the big picture, understand it in its entirety and decide how to proceed, both as vendors and as service providers
. I’ll attempt to paint that picture and suggest a way forward,but we must collectively arrive at a solution
Setting the Stage
. First, we’ll take a look at core networks, and the issues that they face with respect to this problem
. Hopefully, this will be easier to visualize
. Then, we’ll take a brief look at metro networks
. This is not a reflection on the relative importance of either, or whether packet transport (aka PBB/PBT/T-MPLS/MPLS) ismore applicable to the core versus the metro
. On the contrary, lessons from one are fully leverageable in the other
The “Legacy” Picture
SONET/SDH
Deep Channelization: down to DS0
Framing: carry bits/cells/packets/frames
Overhead: OAM: liveness, management
Fast Restoration (1+1, ring-oriented)
Traffic Engineering (path and capacity mgmt)
Timing (clock/frequency synchronization)
The Small Picture
SONET/SDH
Deep Channelization: down to DS0
Framing: carry bits/cells/frames/packets
Overhead: OAM: liveness, management
Fast Restoration (ring-oriented)
Traffic Engineering (path and capacity mgmt) Timing (clock/frequency synchronization)
Ethernet
Magic layer (PBT/TMPLS/MPLS)
to recapture TE, FRR, packet OAM, etc.
Framing: to carry packets
G.709: optical OAM, FEC, coarse chan, framing
Timing (synchronous Ethernet, if needed)
DWDM
Fiber
Clearly, getting rid of functions that are no longer required leads to savings
The Small Picture
. In the narrow view, the transition from TDM to packet transport is driven by:
1.
New way to “fill pipes”: replace time-division multiplexingof circuits with statistical multiplexing of packets
2.
Elimination of legacy functions
. Fine-grained TDM and timing being the main candidates
3. Replacing the remaining functions
. These include OAM, p2p TE, and Fast Re-route
. Put them in the “magic” layer
4. Elimination of a whole range of interface types and link layers in favor of just Ethernet
. Improves both CapEx and OpEx
Question: What should the “magic” layer be?
The Small Picture
. It’s hard to argue with the benefits listed in the previousslide
. However, it doesn’t address functional redundancy …
.
Traffic Engineering in the transport layer or in higher layers?
.
OAM in the transport layer or in higher layers?
.
Restoration in the transport layer or higher layers?
. … or the issue with managing multiple layers
. How should the layers interact? What is the right approach to “multilayer restoration”? How to manage the various layers?
. But the real issue is, this approach misses the Big Picture
. We’ll get to that, but first let’s explore the above issues
Aside 1: Technology
. PBT started life as a point-to-point technology, focused onreplacing point-to-point transport circuits (SDH, ATM, T1/E1)
. Questions were raised regarding point-to-multipoint and any-to-any
. So, PBT is now addressing these, with “Provider Link StateBridging” (PLSB) and other extensions
. Yay! They’ve discovered link state protocols!
. There are still many open questions about PLSB
.
What about Equal Cost Multi-Path (ECMP)?
.
What about transient loops when the topology changes?
. Should a TTL field be introduced in the Ethernet header?
.
What about IGP-based Fast Reroute? (LFA, not-via, …)
.
What is the effect of the PLSB IGP on the IGP used for IP? Have we learned from the ATM overlay debacle?
.
How about multi-area/multi-level IGPs? Is there a way to achieve the equivalent of IP address summarization?
Aside 1: Technology
. Okay, we have a link-state IGP. What about inter-provider?
. Should we expect Provider BGP Bridging (P.BGP.B)?
. GMPLS extensions have been proposed and are moving forward in the IETF CCAMP WG
.
Both P2P and P2MP TE “LSPs” are envisioned
.
Soon, we will have Provider MPLS Bridging (P.MPLS.B)!
. 802.1ag is a very complicated OAM mechanism
. How about P.BFD.B? Much simpler, gets the job done
. I have no doubt all of these will be addressed over time, with the help of the experience of IP/MPLS deployments
.
But in the end, the control planes are the same (or very similar), the data plane concepts are similar (still need the TTL field!)
.
So, what has been gained from all this exercise?
Multi-Layer Duplication
. While it’s not clear what has been gained, what has been lost is very clear
.
There is now very clear (almost perfect!) duplication of functionality between the “magic” layer and the IP/MPLS layer
.
The “magic” layer, whether it is PBT, T-MPLS or MPLS, as a
separate layer, offers little benefit to the service layer, but it
.
adds to both CapEx and OpEx
.
may require a further inter-working layer
.
reduces overall availability (more things that can go wrong)
.
leads to greater confusion in the overall architecture
. The aforementioned developments in PBT are being viewed with suspicion even by the supporters of PBT … . … which brings us to the real problem
Picture from the Past (20/15/10/5 years ago)
transport
SONET/SDH
DWDM
Fiber
Picture Today
Internet Protocol
MPLS (P2P, P2MP, MP2P, MP2MP)
services
transport
?
DWDM
Fiber
Picture in a Couple of Years
Internet Protocol
MPLS (P2P, P2MP, MP2P, MP2MP)
services
transport
?
DWDM
Fiber
Logical Progression?
. This looks like a fairly natural progression in networkarchitecture, does it not?
. Actually, there is an “elephant in the room” that is so obvious that it is invisible
.
This “elephant” results in sub-optimal design, overlapping network functions, and duplicate efforts in operations
.
It also contributes significantly to network cost
.
At the same time, it offers little in constructive value
. Let’s look again …
Picture from the Past (20 years ago)
transport
SONET/SDH
DWDM
Fiber
Picture in a Few Years
Internet Protocol
MPLS (P2P, P2MP, MP2P, MP2MP)
services
transport
?
DWDM
Fiber
The Hidden Picture
. The “elephant” is the purple line that separates the“IP/MPLS” part of the network from “transport”
. This has become entrenched in network architectures over the past 20 years, and manifests itself
.
In organizational structures, both in service providers and equipment vendors
.
In philosophies of deployment and implementation
.
IP/MPLS: dynamic, fluid, distributed control plane, new services
.
Transport: static, centralized, fixed notion of services, stable
.
In regulations and laws set by governments
.
In unions and internal politics of various flavors
.
And in so many other hidden or unnoticed ways
The Hidden Picture
. The purple line made sense 20 years ago, when severalservices rode over the transport network
.
The purple line separated “infrastructure” from “services”
.
Keeping infrastructure separate allowed for a very stable network, over which each service could be managed independently
.
A particular service failure would typically affect just that service
. The infrastructure going down would affect all services
. Today, there is essentially just one “service” over transport, namely IP/MPLS. The real services are above that
.
If the “infrastructure” below the purple line is up, but IP/MPLS fails, all services go down --so, what’s the point of a stable “infrastructure”?
.
If IP/MPLS is as stable as the “infrastructure”, and IP/MPLS carries all the services, then it follows that IP/MPLS must be part of the infrastructure, i.e., the purple line must be redrawn …
.
…where?
The Right Picture?
services
transport
MPLS (P2P, P2MP, MP2P, MP2MP)
Also, placing the line here
?
captures only a few services
DWDM
Fiber
This would negate the power of MPLS --its
tight integration and excellent synergy with IP!
The Right Picture?
transport Internet Protocol MPLS (P2P, P2MP, MP2P, MP2MP)
services
Ethernet + G.709
DWDM
Fiber
This maintains the synergy between MPLS and IP, and has the right partition between infrastructure and services. Also note that we can now finally fill in the “?”: a thin layer of Ethernet (for framing) and G.709 (for optical OAM/FEC)
The Big Picture
. We (as a total community) have to confront the purple line
.
If not, one cannot build an efficient, cost-effective network
.
All the talk of saving CapEx and OpEx will just be meaningless
. This will not be easy
. 20 years is a long time for habits and attitudes to accrete
. But it has been done and is being done today
.
Several large carriers have already integrated their “transport” and “IP/MPLS” groups, both in architecture and in operations
.
Others are doing this now, or have just begun
. And, once this is done, and we’ve found the right view of the new network, I suspect that talk of PBT and T-MPLS will just not be as interesting any more
.
One could imagine a place for these in the new architecture …
.
…or not
.
Talk of PBT/T-MPLS/MPLS is premature until we’ve settled this
Aside 2: But IP/MPLS Is Expensive!!!
. First, let’s define IP/MPLS
1. Edge platforms offer IP, MPLS and Layer 2 services
. and offer a very diverse interface mix for customer interconnect
2. Core platforms connect edge boxes via MPLS LSPs
. with whatever is the right mix of interfaces for core interconnect
3. All platforms participate in a common, IP-based control plane
.
This may involve hierarchy --IGP areas, multiple ASs, Route Reflectors, LSP hierarchy, etc.
.
But all components of the control plane work together synergistically
4. This in turn means that all platforms have enough IP handling capability so that they can:
.
send, receive and forward control packets, and
.
protect themselves against unwanted traffic, especially control traffic
. Second, let’s see how this is implemented and deployedtoday
Aside 2: IP/MPLS Deployment
Aside 2: Cost Trends
Routers, Ethernet
Optimized
Switches with router functions
Cost
Time
Economics dictates that these will intersect
Which is the more effective strategy: starting with a switch, and trying to add routing, or starting with a router and cost-reducing and optimizing for Ethernet?
(slide from 3 years ago: been there, done that, shipped!)
Aside 2: Costs Below the Purple Line
Time
The Time Has Come for a Transport Router
. A transport router is fully part of the IP/MPLS control plane
.
No overlays, no centralized provisioning, no interworking
.
No new standards, no unproven technology
.
Robust, highly reliable, highly available
. A transport router has to be Ethernet-centric
.
Assumption: a carrier has control over their infrastructure, and can move over time to pure 10G/40G/100G Ethernet core interconnects
.
This leads to cost savings on all fronts
. A transport router has to be integrated with the “rest” of transport
. That is to say, deep G.709 and optical integration
. A transport router has to be cost optimized
.
All of the above contribute to improved price points
.
Other techniques may also help cost reduction
Aside 3: SDH Replacement? Or Removal?
Aside 4: But MPLS OpEx Will Kill You!
. I’ve said several times that MPLS can be made “Plug and Play”, with significantly easier provisioning and management
. There is now a report by an independent third party that presentsthe results of comprehensive tests evaluating MPLS Plug-and-Play
.
Dynamic and Fast Plug And Play Provisioning
.
Auto-Discovery of MPLS Service End Points
.
Ethernet Unnumbered Interfaces
.
Rapid Service Activation of Ethernet Services
.
Error-resilient configuration and automated fault diagnosis
Isocore feels comfortable in stating that the elaborate feature set offered by <vendor deleted> MPLS Plug-and-Play solution brings together the best of the hardened MPLS technology and Ethernet thus simplifying theprovisioning and deployment of metro Ethernet networks in a true carrier-class environment
Okay. What’s the Metro Picture?
. Sometimes, it feels like the entire metro is below the purpleline!
.
No service delivery, just service backhaul
.
There also seems to be another line separating metro and core
. However, as the metro evolves to higher bandwidths and new services, SPs are migrating to delivery of some services in the metro. The reasons include:
. Multicast for IPTV, local VoD servers, ad insertion, DPI, better scaling and distribution, better control of services, location-based services, efficient integration with IMS, better QoS, improved security, …
. So, there is either a divide between “MPLS” and “transport”or “IP/MPLS” and transport in the metro
.
The issues (and conclusions) are the same as in the core
.
There is also great benefit in integrating the metro with the core using common forwarding and control planes
Recap
. The purple line served a very useful purpose, but has remained stagnant over time, and now finds itself astray
. However, the idea of separating “services” and “infrastructure” is sound, and should be recaptured
. Redrawing the purple line should be the first priority in designing a “Next Generation Network” --one that optimizes for cost and efficiency of the new communication paradigms (point-to-point, any-to-any, multicast, …)
. This will not be easy for anyone
. In concert with the above, the way that packet switches arebuilt and how/where they are deployed has to be revisited aswell, again, in order to optimize their cost and efficiency
. The good news: the services, control and data plane infrastructure has proven effective, robust and future-proof --they have met the challenges of the current generation of always-on, any-to-any communication, and will carry us into a ubiquitous, mobile future
Thanks!
Perhaps this talk should have been entitled
“Pictures at a Conference”
(with apologies to Mussorgski)
