Unified MPLS for Multiple Applications Transport Profile

Transcription

1 25 August 2010 Unified MPLS for Multiple Applications Transport Profile Abstract This paper outlines important packet and transport network convergence opportunities & challenges, and illustrates how Multiprotocol Label Switching (MPLS) has been extended to address them. The industry has faced and has been facing many questions about what the correct way to ensure a successful network convergence is, especially considering the operational and sometimes organizational changes needed to realize the full cost-saving potential of a de-layered packet & transport network. This paper highlights how past and currently proposed extensions transform the time-tested MPLS protocol suite into something very suitable for next generation transport networks & services.

2 Network Convergence Past and Present Communication networks have evolved and converged significantly over the past century, however, within large networks, many overlayed or parallel silo s of service or application specific connectivity solutions have been built, and in many cases have dedicated support organizations and systems. Further network convergence - and removal of such silos - is driven by both business and technology factors to reduce operational costs whilst delivering new services and thereby generate higher revenue and profits. One inherent challenge in network convergence is that while an operator invests in new infrastructure and offers new services, they must also sustain the existing legacy services & related infrastructure. In this period of transition, the revenue from legacy services is typically in a mature to declining stage, while underlying infrastructure becomes outdated, and often expensive to upgrade. For the transition phase, a more common, future-proof & adaptable infrastructure is needed to scalably deliver current generation services and also deliver newer generation services over the future time. This flexible generation of infrastructure delivers higher return on investments. Examples of equipment exhibiting this characteristic can be found in multiple generations of transport equipment from ADM through MSPP to POTP (Packet Optical Transport Platform) and also strongly in the network Edge, where an extremely high degree of network convergence support is now available in today s ultra-flexible Multi-Service Edge Routers. The following is a list of key goals to achieve through network convergence: lower CAPEX and OPEX smooth migration to the next generation of services and infrastructure consolidated network management & operations inter-operability across technology & operator domains opportunity for radical de-layering of the network infrastructure via consolidation of service delivery and transport on the layer (MPLS) that has maximum flexibility The invention of MPLS in mid 1990s has been a boon to networking industry. It enabled a protocol agnostic transport infrastructure. Operators around the world have successfully migrated to Ethernet/ATM/Frame Relay/IP services over MPLS networks to meet business goals. The success of this migration allowed voice, video and data services to be delivered over a single high speed network. As the Figure 1 illustrates, MPLS is the fastest growing technology choice for packet transport networks. This diagram considers packet services and not more traditional, TDM based enterprise/business transport interconnect services that currently are also often used to transport packet services. MPLS based network infrastructure enables lower opex than other options in the packet technology field since newer extensions and services can strongly leverage the existing infrastructure. With the transport profile adaptations to the standard, it also now Figure 1: Current State of Packet Transport Technology Lifecycle & Deployment Rate challenges the presumption that traditional transport methods (such as TDM) are automatically lower cost. The primary motive driving the convergence over to packet network technology is that it consistently delivers more functionality per dollar invested while achieving significant savings on op-ex side. Network Convergence-Past and Present

3 The ongoing migration of transport services from SONET/SDH networks to packet based infrastructure requires us to appropriately dimension for two substantially different paradigms of information transfer: The first is the ability to deliver sophisticated connectivity services to multiple remote destinations over a single cloud, mesh or hub and spoke topology. These services inherently embody some risk in operations due to the economic necessity of oversubscription and inability to predict loading patterns at any individual point in time. The second being the significantly simpler and deterministic operations associated with simple point to point services whereby the metric of success is perfection in information transfer. MPLS has evolved to meet this challenge. However, whilst being perfectly fit to deliver the bulk of services (capacity and revenue), there is also still the need for a small, but significant set of services to be supported by an even more robust technology, one that can deliver extreme low latency and offer the traffic separation and performance monitoring needed by top-grade enterprise services, such as in the financial segment and also carriers-carrier connectivity. OTN has emerged as a good complementary fit to MPLS for the provision of this top range of services, with SAN (Storage Area Networking) and Lambda also available for similar high-profit services. All technologies can be simultaneously supported from many modern, converged packet Transport systems, networks avoiding the need for overlay, or parallel network infrastructure. Unified MPLS for Multiple Applications Introduction MPLS has been extended to support the operational characteristics required for a transport service over packet network architecture. This is achieved by enhancing the existing MPLS OAM suite with additional tools able to offer a richer OAM capability at the same time as a higher level of network reliability and manageability. Section 2.3 provides more details on this. The resulting new generation of MPLS will continue to provide all the benefits offered by current MPLS, while also incorporating the capabilities to accommodate new transport requirements. This has been carefully architected for backward compatibility. This approach has been well received by operators and vendors who formed one of the most active groups in the IETF standardization arena. Considering the scope of the effort, the standardization and documentation process has been progressing extremely fast and is leading towards a set of extensions that define the new generation of MPLS, known as MPLS-TP. MPLS Tested by time for flexibility When MPLS was first introduced, the goal was to use new capabilities to optimize traffic throughput and engineer traffic placement in IP networks. MPLS has exceeded those initial expectations, and over the years it has become a toolbox used for several types of networks. MPLS has evolved significantly over the years with extensions to deliver new functionalities. Table 1: MPLS Standardization Timeline Network Convergence-Past and Present unified mpls for multiple applications

4 For a long time IETF discussed the matter of how to deliver VPN solutions over IP networks. The specification on MPLS/ BG Layer 3 VPNs in early 1999 was a significant step in what would become the method by which MPLS is extended into new areas. RFC 4364 is the standard that describes MPLS/BGP VPNs, but was published several years later. The need to use IP networks to offer classical L2 services over wide areas lead to an MPLS based Pseudo-Wire technology, e.g. used for point to point ATM, TDM and Ethernet connectivity. Given that such L2 connectivity was specified by extending MPLS to support L2VPNs; for all practical purposes this is Wide Area Ethernet LAN services. The extensions we see today to meet Transport network requirements are very similar to how MPLS has been extended in the past, and are likely to be extended in the future. In addition to L2 and L3 VPN, the full MPLS functionality has been extended over the years to meet the requirements of specific purposes. The full scope of MPLS has been created over the years using contributions from many different parts of the industry and is captured in IETF standards by a number of working groups (e.g. MPLS, PWE3, L2VPN and CCAMP). One important aspect when it comes to safe-guarding technology evolution is to have guiding principles, typically referred to as architecture. These guiding principles define the methods for the introduction of new functionality into an existing technology, in order to provide interoperability and backwards compatibility. Any typical MPLS infrastructure deployment includes a few of the extensions, or may be required to be expanded with new capabilities (extensions) over time. When the first attempt was made to extend MPLS for Transport Networks (T-MPLS), the approach did not adhere to the MPLS architecture (RFC 3031) and was not backward compatible. This would have caused significant problems for deployments, operations and future extensions. More detail about issues arising from this kind of uncoordinated protocol development is captured in RFC T-MPLS is a distinct technology not upgradeable to MPLS-TP, despite the marketing efforts of some system vendors. MPLS Extensions Driven by Transport Requirements The principal extensions driven by Transport networks requirements are focused on data plane OAM and management. Although legacy MPLS has an existing suite of OAM tools (such as BFD for LSPs & LSP Ping and LSP traceroute), the toolset was originally architected for IP network optimization and consequently cannot achieve the precision desired for transport applications. The toolset was focused on the most common deployment scenarios, being: the LDP control plane, penultimate hop popping in the data plane, LSP merging and equal cost multi-path, all of which primarily address MPLS scalability, but at the expense of measurability. The extensions provided by the MPLS-TP project are aimed primarily at addressing the operational, administrative, and management needs of transport operators. As these needs are grounded in operational experience, it turns out that they also apply to other uses of MPLS, as they become more pervasive. These new or extended features include: Continuity Check and Connectivity Verification Alarm Management (AIS, RDI, Client Fail Indication) Diagnostics (Route Tracing, Loopback, Path Locking) Performance Monitoring (Packet Loss, Delay Measurement & Throughput Estimation) Fast protection switching The transport profile of MPLS (MPLS-TP) focuses on a subset of legacy MPLS behaviors to which enhanced OAM can be applied. In particular the focus is on connection oriented behavior and the ability for MPLS to be operational without a distributed control plane. This has always been possible but with functional gaps. What has been added is the ability to delegate control functions such as resilience, monitoring and management to the data plane, and the OAM suite has been enhanced in order to permit this. The fundamental fault management tools, LSP Ping and BFD are carried forward but with enhancements and additional protocols to support protection switching, alarm management and administrative functions. MPLS-TP is also enhanced to meet transport network resiliency requirements. A standard transport network requirement is to provide fast protection switching (<50ms), especially in ring topology. unified mpls for multiple applications

5 New Capabilities Enabled by these Extensions Inherent MPLS capabilities in combination with extensions of MPLS OAM capabilities enable: Extending MPLS further towards the network edge: The resiliency without a control plane allows MPLS to be extended further towards the network edge. This diminishes the load that the plethora of edge devices places on the core control plane and allows for simple implementations in the edge boxes (this also allows edge node to meet lower cost targets). Backhaul from the edge requires limited LSP connectivity and can be easily provisioned (by an NMS), thus dramatically simplifying both the implementation requirements and the amount of control processing. Enhanced SLA support: The enhanced capabilities and precision of the OAM tools allows MPLS to support additional services and to demonstrate compliance for services with very stringent SLAs. Both innovations extend the addressable market of the overall MPLS architecture while maintaining backwards compatibility with existing deployments. MPLS Profiles MPLS, like many standard protocol suites, has many options. The historical method for addressing this is to define a profile and its applicability. That is, one defines a specific combination of options from the full suite. The combination is chosen to work well together, and to address a specific need. Such a specific combination (with or without the applicability, depending upon the specific case) is what is classically called a protocol profile. The MPLS-TP project as defined by ITU & IETF does not provide such a profile. Rather it provides a set of extensions to MPLS that can be used to address specific needs. Given those new features, and many existing capabilities of MPLS, the obvious question is what interoperable set of capabilities will meet the transport operational needs. i.e., what profile will address the problem. This gets slightly complicated, as not all operators have the same view on how they want to run their networks. First, any such profile would have to contain the basics of label switching, and support for label stacks. In addition, any transport profile would have to include the basic OA&M mechanism. While one could imagine implementations with fewer features, a profile that allows for flexible use, effective network operations, and device interoperability needs to include all of those components. All devices which are able to be the starting point for an LSP must support the use of backup LSPs with diverse paths, with the usage triggered by OA&M events from the data plane, without network management or control plane signaling. Network Convergence with MPLS MPLS is the one technology currently available that allows true multi service architecture to be built on a single converged network infrastructure. With the advent of MPLS Traffic Engineering (TE) and Pseudowire technology, the MPLS and PWE3 protocol suite has been used to support TDM, ATM, Frame Relay, IP and Ethernet transport services on a single converged network. The traffic engineering and resiliency properties of MPLS support the stringent latency and jitter requirements needed for many TDM services and ATM services. These services are critical to applications such as 2G and 3G Mobile Backhaul as well as legacy enterprise interconnect services. The same base technologies allow the Ethernet and IP services to be provided over the same network infrastructure. This allows applications such as 3G and 4G mobile backhaul, IPTV, Broadband Access and many others to be provided with the SLAs required by these applications and yet making the most efficient use of the network resources. Because profiles of MPLS are built on this strong base, they inherit the properties, and allow these same services to be provided over a more streamlined and cost reduced network infrastructure. The infrastructure can be tailored not only in function but also in terms of cost to the area of the network architecture where it resides, while keeping a consistent technology base and therefore consistent behavior, management and operations. For example, using MPLS toward the access of the network would have required using a full featured MPLS Label Switched Router that typically included hardware-based IP forwarding. This is the same router functionally that would be used in the core of the network, but only scaled down in terms of capacity which doesn t lead to significant cost reduction. Using an MPLS profile targeted unified mpls for multiple applications

6 to the access, only the MPLS functions needed to support the access network are provided. In this way we can produce a lower cost solution without technology changes, and be more in synch with how current transport networks are built. Profiles of MPLS can be combined to provide the right mix of MPLS support for specific services or applications. For example, a multicast profile of MPLS may include point to multipoint LSP support and associated control protocols for IPTV. This profile could be combined with an L3VPN profile to provide IP interconnect services over the same network. conclusion and Summary MPLS is a technology that has grown in importance for the networking community over the years. From a very humble beginning about 15 years ago where it was mostly targeted to deliver very limited traffic engineering functionality and a BGP free core, it has grown to become the major service delivery mechanism for IP networks. MPLS has reached this position because it combines the flexibility of connection-less IP networks, with the guaranteed services aspect of switched networks with the simplicity of transport networks. The suite of protocols developed over the years allows for MPLS and the related technologies, e.g. L2VPN, L3VPN and GMPLS, to be extended in such a fashion that a healthy architecture might be maintained. Industry/IETF Commitment IETF is the standards development organization and design authority for MPLS; where operators, vendors and academia meet to develop Internet standards, e.g. MPLS. The IETF and the industry share the commitment to keep MPLS backwards compatible while making it possible to extend in the future (RFC5317). The IETF has described rather simple steps that need to be taken by anyone that wants to add new functionality to MPLS (RFC4929). The MPLS-TP project is to some extent unique since it is based on a cooperation of two standards development organizations: IETF and ITU-T. The same guiding principles that control all IETF standardization, architectural consistency and backwards compatibility, is carried forward for the MPLS-TP project. Ericsson s Commitment Ericsson fully supports the approach taken by the IETF, both for the development and extension of the MPLS and the MPLS-TP project. Ericsson is a very active contributor to the standards development, and committed to utilize this new technology across its packet transport portfolio. unified mpls for multiple applications conclusion and summary