.gif)
CARRIER ETHERNET - Repositioning the Purple Line
When Kireeti Kompella and David Noguer Bau ask the service provider community about the future of transport networks, there is general agreement that the future is in Ethernet. So what are the wider implications of this position?
Driven by the reduced cost per bit, Ethernet is becoming the standard interface in the telecommunications industry; we can find Ethernet ports from DSLAMs to mobile base stations. At the same time, Ethernet VPNs are gaining popularity to provide connectivity between enterprise branches.
This change in the industry is driving the requirement for an efficient transport model. The limitations in extending Ethernet into the MAN and WAN are well known (scalability, resiliency, lack of OAM...), so its growing importance is pushing for optimized transport mechanisms:
- T-MPLS: A ‘profile' of MPLS that meets transport requirements (only)
- PBB-TE: Purpose: to make Ethernet carrier-grade (or transport-grade)
- MSP: Multiservice Provisioning Platform that adds functionalities to SDH nodes (trying to extend SDH live).
- MPLS: A true Multiservice transport (IP + Ethernet + legacy)
However, before jumping to quick fixes for Ethernet limitations, let's look at a brief history of the transition from TDM-centric networks to packet-centric networks; hopefully, in doing so, we will gain better perspective on why things are the way they are, and what really needs to be changed.
A bit of history
Fine-grained Time Division Multiplexing (TDM) networks were designed primarily for voice services and adapted reasonably successfully for leased line circuits as data requirements became more important.
A decade ago, with the incipient demand of data services, the network was still able to accommodate it.
The transport requirements for TDM were clear, making SDH a magic layer providing the required features for data:
- Frequency synchronization
- Deep Channelization: down to DS0
- Framing
- Integrated OAM model
- Redundancy with Fast Restoration (around 50ms)
- Traffic Engineering for path an capacity management
So the combined SDH + DWDM model was emerging as a universal transport, common to all services and mainly voice- and circuit-centric. The transport department was in charge of providing the right requirements (bandwidth, resiliency, framing...) and all the services ran across the top. We'll define the separation between the two departments, Services and Transport, as ‘the Purple Line'.
This model is still implemented in most service provider organizations today; however the idea is to get a sense of the value of TDM networks, what the issues are, and how this should evolve around the growing dominance of Ethernet.
The next generation
The massive demand for best-effort Internet services, the migration of voice services to IP, the quick replacement of leased lines by Ethernet and IP VPNS, as well as the growing importance of IPTV, is challenging this model. The requirements for the transport layer are new and Ethernet appears to look well positioned.
This transition towards Ethernet consequently forces re-allocation of the missing functions: OAM, Traffic Engineering, Synchronization and Fast Restoration should move into the new ‘magic layer'. Today, the industry is struggling to find the best technology to fulfill the magic layer requirements, positioning at the heart of this debate technologies such as T-MPLS, PBB-TE and MSE, all designed to complete and optimize the transport of Ethernet.
The ‘Purple Line' made sense 20 years ago, when several independent services rode over the transport network. The Purple Line drew a demarcation between ‘infrastructure' and ‘services'. A particular service failure would typically affect just that service while an outage in the infrastructure would affect all services. Keeping infrastructure separate enabled a very stable network, over which each service could be managed on its own.
Today, with the NGN (Next Generation Network) model, there is essentially just a single ‘traditional service' over transport, namely IP/MPLS. Replacing SDH with an enhanced Ethernet technology is not going to change it. All the real services will still be sitting at a higher layer. Since IP/MPLS carries all the services, it must have the same stability and resilience as the ‘infrastructure' below the Purple Line. The natural consequence of this is that IP/MPLS must be part of the transport infrastructure, i.e., the Purple Line must be redrawn ....
Placing the line
Where should the new Purple Line be placed? In other words, is ‘IP/MPLS' really a service? Having a transport-specialized MPLS and keeping IP as part of the services would separate IP and MPLS into different departments, therefore negating the tight synergy between IP and MPLS.
The right model is having IP/MPLS as part of the transport side of the Purple Line and all the real applications and control services sitting on top of it. This model shows a good partition between infrastructure and services maintaining the synergy between MPLS and IP. Also note that we can now finally fill in the "magic layer": a thin layer of Ethernet (for framing) and G.709 (for optical OAM/FEC).
This model is the only way for networks to take a giant step forward and become packet-centric rather than optimized for TDM circuits. Keeping IP/MPLS separated from transport introduces inefficiencies and duplications as two different departments have to deal with the same issues: resiliency, traffic engineering, capacity. This integration will also help equipment vendors to find new synergies between IP/MPLS and optical transport. As we begin the process of moving the Purple Line, a long list of opportunities for improving the overall network will arise.
Consequences
Moving the Purple Line is not at all easy, as 20 years is a long time for habits and attitudes to take hold. This particular future has consequences for many groups: vendors, service providers, regulators, unions. How quickly and effectively these groups respond to the challenge will determine how fast we can move to the new paradigm of packet-centric networks.
New platforms have to be built to meet the new requirements. New architectures and new management paradigms are needed to best use these new platforms. New regulations may be needed to say which platforms can be deployed, where and how. The labour force may need to be reorganized to address the new opportunities.
The Purple Line served a very useful purpose, but has become stagnant over time, and now finds itself out of place. However, the idea of separating "services" and "infrastructure" is still valid and should be preserved. Redrawing the Purple Line must be the first priority in designing a packet-centric Next Generation Network in order to truly optimize it for cost and efficiency within the new communication paradigms (point-to-point, any-to-any, multicast ...) and this may be challenging for many.
In this new context, the way packet and optical switches are built, deployed and managed has to be rethought. The good news is the validation from both the packet and the transport worlds - IP control and data plane infrastructure is effective, robust and future-proof, service-enabling and scalable.
Leaders will define the future, followers will live in it.
Kireeti Kompella is Distinguished Engineer and Fellow at Juniper Networks, and David Noguer Bau is Head of Carrier Ethernet and Multiplay Marketing for EMEA at Juniper Networks
Share this article with others
Post to del.icio.us
Printed from http://www.eurocomms.com/features/112308/CARRIER_ETHERNET_-_Repositioning_the_Purple_Line.html
Comment on this article
Skip to comments
We encourage users to analyse, comment on and even challenge European Communications's articles, including the one above - 'CARRIER ETHERNET - Repositioning the Purple Line'
User reviews and comments that include profanity or personal attacks or other inappropriate comments or material will be removed from the site.
Additionally, entries that are unsigned or contain "signatures" by someone other than the actual author will be removed. We will take steps to block users who violate any of our posting standards, terms of use or privacy policies or any other policies governing this site.