The invite to the 2007 MPLS Roadmap conference provides some interesting and timely ‘facts’ about frame relay and its current use by service providers.
Fact #1: Carriers are rushing to move from legacy voice/data networks to an MPLS-based network for their enterprise services.
Fact #2: Frame relay, the dominant enterprise network service of the past 10 years, runs on the carriers’ legacy networks.
Fact #3: Some carriers will no longer respond to a frame relay RFP…and even those that do are including contract language that offers little – sometimes no – assurance that frame relay will be supported for the term of the agreement.
Reading this, I thought it about time I brought the story of frame relay up to date. I first wrote about frame relay services (FR) an absolute age ago in 1992 when they were the very latest innovation along side SDH and ATM. The core innovation in the frame relay protocol was its simplicity and data efficiency compared to its complex predecessor – X.25 and filled the gap for an efficient protocol wide area network services. Interestingly this is the same KISS motivation that lies behind Ethernet.
Throughout the 90s, frame relay services went from strength to strength and was the principle data service that carriers pushed to enterprises to use as the basis of their wide area networks (WANs). Mind you, there were mixed views from enterprises about whether they actually trusted frame relay services and they have the same concerns about IP-VPNs today.
As FR is a packet based protocol running on a shared carrier infrastructure (over ATM usually), many enterprises wouldn’t touch it with a bargepole and stuck to buying basic TDM E1 / T1 bandwidth services and managed the WAN themselves. It was the financial community that principally took this view and they have probably not changed their minds even now – in with the advent of MPLS IP-VPNs. Remember, the principle traffic protocol being transferred over WANs is IP!
Often things seem quite funny when looked at in hindsight. In The rise and maturity of MPLS, I talked about the Achilles heel in connectionless IP data services as exemplified by the Internet – lack of Class of Service capability. This can have tremendous impact when the network is carrying real time services such as voice of video traffic.
FR services, because they were run over ATM networks actually had this capability and carriers offered several levels of service derived from the ATM bearer such as:
- best effort (CIR=0, EIR=0) »
- guaranteed (CIR>0, EIR=0) »
- bandwidth on demand (CIR>0, EIR>0)
Where CIR is Committed Information Rate and EIR is Expected Information Rate and were applied to what were known as Permanent Virtual Networks (PVCs) although towards the end of the 90s, temporary Switched Virtual Networks (SVCs) became available. Also, voice over frame relay services were launched around the same time.
So frame relay did not suffer from the same lack as QoS as IP but still got steam rollered by the IP and MPLS bandwagon. Also, unlike IP, because frame relay was based on telecommunications standards that were defined by the ITU inter-connect standards were defined. Because of this, carriers did inter-connect frame relay services enabling the deployment of multi-carrier WANs. Again this was, and is, a weakness in MPLS as described in MPLS and the limitations of the Internet. It’s a strange world sometimes!
One of the principle reasons for frame relay’s downfall lay with its associated bearer service, ATM. In The demise of ATM I talked about how ATM was extinguished by IP and the direct consequence of this was that the management boards of carriers were unwilling to invest any more in ATM based infrastructure. Thus FR became tarred with the same brush and bracketed as a legacy service as well.
The second reason was the rise of MPLS and its associated wide area service, MPLS based IP-VPNs. Carriers wanted to reduce infrastructure CAPEX and OPEX by focusing on IP and MPLS based infrastructures only.
Where has it all ended up? Although frame relay was not a service that had so much religion associated with it as ATM and IP (as exemplified by ‘bellheads’ and ‘netheads’) it was the main data service for WANs for pretty much a decade. When, MPLS IP-VPNs, came along in the early years of this century, there seemed to be a tremendous resistance from the carrier frame relay data network folks who never believed for one moment that frame relay services were doomed.
We are now pretty much up to date. Carriers still have much legacy frame relay equipment installed and frame relay services are being supported for their customers, but frame relay can undoubtedly can be classed as a legacy service.
Like ATM and Ethernet, many carriers are migrating their legacy data services to being carried over their core MPLS networks encapsulated in ‘tunnels’. Thus frame relay could be considered to be just an access protocol in this new IP/MPLS world supported while customers are still using it.
Any Transport over MPLS is what it is all about these days. Ethernet, frame relay, IP and even ATM services are all being carried over MPLS-based core networks.
As an access service and because of its previous popularity with enterprises, frame relay will live on but it’s been several years since there has been any significant investment in frame relay service infrastructure in the majority of carriers around the world.
Other services that did not survive the IP and MPLS onslaught in the same time-frame were Switched Multi-Megabit Data services (SMDS) and the ill-feted Novell Network Connect Services (NCS) – more on this in a future post.
One protocol, that did not suffer but actually flourished was Ethernet whose genesis lay in local area networks like IP. Indeed, it could be said that LAN protocols have won the battles and wars with telecommunications industry defined standards.