Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

MPLS fabric is natural fit for ISP backbone overlays

While data centers typically use an IP fabric under their network overlays, ISPs may find that MPLS fabric makes more sense as backbone underlays.

Editor's note: In the last of our three-part series on deploying network overlays in Internet service providers'...

backbones, we explore how ISPs might implement overlays in their core networks using MPLS fabric as the underlay. Part one examined the broader history of network overlays in the backbone and part two looked at the benefits overlays could bring to the backbone, and the role of fabric underlays in that environment.

Network overlays have the potential to dramatically increase agility and lower Opex -- benefits that Internet service providers (ISPs) can't afford to ignore when it comes to their backbone networks. While data center architects often select an IP fabric to perform forwarding functions, ISPs may choose to use a multiprotocol label switching (MPLS) fabric as the foundation of their backbone overlays.

The pervasiveness of MPLS in service provider backbones makes an MPLS fabric a logical fit for providers already invested in the technology. The protocol stack has been used for years in this environment, and network engineers are familiar with using MPLS for traffic separation, traffic engineering, fast rerouting and establishing VPNs.

In addition to leveraging existing investments, architects looking to use an MPLS fabric would argue that MPLS provides separation in the network rather than the end points. Therefore, tunneling protocols required by an IP fabric for multi-tenancy are obviated; the additional complexity in hypervisors needed for IP fabrics can be avoided with native, unified end-to-end label switching.

Ongoing work related to MPLS in the provider community is drawing increasing attention with the recent interest in software-defined networking. Developments in path computation element protocol (PCE-P) -- led by organizations like Google -- move the source-routed path computation that is typically performed at the "head end" router to servers. Using software running on services is not a new concept; some providers with MPLS backbones have been using software packets from vendors like Cariden and WANDL to compute a traffic matrix for the network and to push the LSPs to the routers to meet network capacity demands.

Service providers can't ignore the significant Opex reductions and increased agility that many believe network overlays can bring to the core network.

In his article on PCE-P, David E. Jacobs highlights several advantages of a centralized PCE and PCE-P in the age of software-defined everything. PCE-P provides the same functionality as OpenFlow without the investment in new network infrastructure. Work remains to enable MPLS as the unifying fabric between the provider core and data center networks. MPLS must be extended to the hypervisor. Kireeti Kompella -- a prominent player in the development of MPLS -- has his name on an IETF Internet draft that describes the extension of Address Resolution Protocol (ARP) to support label distribution. Labeled ARP is a simpler, configuration-free protocol for label distribution that adds plug-and-play functionality for hosts to interact with the MPLS fabric.

A second example of ongoing work is the extension of the MPLS PE into the virtualized realm. The Internet draft for the BGP/MPLS VPN Virtual PE outlines an architecture rather than specific protocols. The authors document two primary models:

  1. SDN model: vPE Forwarding (vPE-F) and control (vPE-C) are implemented on separate devices. The vPE-F would likely be located on the hypervisor or top-of-rack switch with the vPE-C on a different physical server. The control plane uses Interface to the Routing System (I2RS) or similar protocol.
  2. Traditional routing model: vPE-F and vPE-C are collocated on the same device. The standard multiprotocol BGP used in the core for VPN signaling is employed in this model.

Observing how these efforts to stitch labeling switching in the core to the data center will be interesting. At large ISPs, the operators and architects of the core and data center often work in separate organizations within the company. Traditionally, data center architects have shied away from MPLS for its perceived complexity and cost. The core engineers may experience some resistance in unifying WAN and data center on an MPLS fabric.

Service providers can't ignore the significant Opex reductions and increased agility that many believe network overlays can bring to the core network. Existing networks are too static and inflexible; provisioning and other network changes have time frames measured in weeks or even months. This article has illustrated some ways providers can implement overlays without completely starting from scratch. The speed of adoption of overlays in the core will probably lag that of the data centers; however, the commoditization of ISPs' services should drive a gradual shift toward network overlays.

Next Steps

How an MPLS network works

The future of networking, one step at a time

Beyond the hype: The relationship between network fabrics and SDN

This was last published in April 2015

Dig Deeper on Service provider networks and SDN

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Does MPLS fabric make sense as a backbone network underlay for ISPs?
Cancel

-ADS BY GOOGLE

SearchNetworking

SearchEnterpriseWAN

SearchCloudProvider

SearchUnifiedCommunications

SearchSecurity

SearchDataCenter

Close