MPLS providers tout that the MPLS services are interface-agnostic. In theory, this is a wonderful concept in that a customer does not have to migrate to different access interfaces, allowing them to leverage the current
Requires Free Membership to View
SearchEnterpriseWAN.com members gain immediate and unlimited access to breaking industry news, best practices for designing and managing Wide Area Networks, WAN Security, and more -- all at no cost. Join me on SearchEnterpriseWAN.com today!
Kate Gerwig, Editorial Director
CE routers and simplify the environment with a seamless migration. This also allows customers to evaluate high speed pipes such as Ethernet and Packet over SONET for WAN termination.
However, most MPLS providers have extended access across their private line, ATM and frame clouds for MPLS termination. This is not an access issue but an issue of how MPLS routers terminate access circuits and the interface card support on the provider edge (PE) routers that support the multiple access types.
Fortunately, the ability to deploy interface-agnostic MPLS access circuits is becoming a reality. This allows customers to terminate one CE on ATM, one CE on frame, one CE on Ethernet and another on private lines. Cisco refers to this as "any transport over Multiprotocol Label Switching (AToM)," and the carriers are executing on their road maps for delivering this type of connectivity. When evaluating providers' MPLS access circuits, be sure to nail them down on their road map for agnostic interface support.
Another enhancement of MPLS connectivity is remote access to an MPLS VPN. In the past, customers could support remote access over dial connections or over the Internet via IPsec tunnels with DSL, ISDN, etc. The remote access users would connect or dial in to a terminating node supported by the customer themselves. While this works fine and has been used for years for remote access, the customer is still required to support the access infrastructure for a mobile work force. Evolution of MPLS has now reached a point where providers can accept these types of connections and inject the remote customer into the enterprise VPN. This allows the customer to utilize the provider's cloud for all remote access customers. When evaluating a provider's remote-access capabilities, be sure to understand where they are on support for the remote-access solutions described above.
Yet another enhancement to the MPLS service portfolio is the addition of interior gateway routing protocol support between the PE and CE. Originally, most carriers touted support for BGP, OSPF, static and RIPv2 between the CE and PE. Now carriers are realizing the need to enhance the level of OSPF, support for EIGRP and support for IS-IS. This has been driven by the need for the MPLS backbone to integrate with the customer's interior gateway routing protocol. The capabilities are supported via MPLS -- the question is whether or not the provider supports the advanced features yet. Again this goes back to verifying the provider's road map for support of these protocols.
There are more advancements that are reaching maturity such as Multicast support, multi-provider VPN support and IPv6. I plan on discussing some, if not all, of these topics individually as I write the articles this year. Stay tuned!
Robbie Harrell (CCIE#3873) is the National Practice Lead for Advanced Infrastructure Solutions for SBC Communications. He has over 10 years of experience providing strategic, business and technical consulting services to clients. Robbie resides in Atlanta, and is a graduate of Clemson University. His background includes positions as a Principal Architect at International Network Services, Lucent, Frontway and Callisma.
This was first published in January 2005