Team mixes MPLS and IPv6 for enterprising results

iLabs Advanced Internetworking Initiative team members took some time from their busy pre-show testing efforts last month to discuss their project with Network World Managing Editor Jim Duffy.

The iLabs Advanced Internetworking Initiative team in collaboration with Isocore Internetworking Lab this week will deploy a live, Multi-protocol Label Switching network to examine various MPLS VPN technologies, as well as some of the latest developments in IPv6/IPv4/MPLS integration. AII team members Hege Trovsik, Rajiv Papneja and Jim Martin took some time from their busy pre-show testing efforts last month to discuss their project with Network World Managing Editor Jim Duffy.

SIP aces basic interop tests

Vendors hit the 802.1X market for access, but security holes remain

What are the overall/overriding objectives of your tests?

Papneja: The overall objective is to establish the availability of advanced enterprise applications across a capable, interoperable MPLS-based core. This years’ demonstration is unique as it shows the readiness of the MPLS capability to support IPv6 customers without causing MPLS to be extended further, or the need to replace the IPv4-capable core routers in the existing service provider infrastructure. Also, this enables enterprise customers to move to IPv6 supported devices and still be transparently connected to same IPv4 infrastructure.

Are you testing MPLS’s edge service capabilities? Or core transport capabilities? Or both?

Papneja: The focus will be primarily on the edge services and applications. The demonstration will include cases showing how various MPLS technologies can benefit the enterprise customers, and these customers can deploy their own services without much of overhead. For example, the demonstration will be showing different types of MPLS VPNs [Layer 2/Layer 3], IPv6 over MPLS and Multicast over MPLS. In addition, certain core features, such as Fast Reroute across a [quality of service]-aware and a traffic-engineered core, will be examined. Attendees will be able to experience edge services such as Layer 2 point-to-point and point-to-multipoint VPNs [including virtual private LAN service], Layer 3 VPNs based on IETF RFC 2547bis, Fast Reroute capable Label Switched Paths using [Resource Reservation Protocol-Traffic Engineering] Extensions, Multicast over MPLS, and IPv6 tunneling over MPLS.

Martin: Our work with IP Multicast in some ways builds on the MPLS core and in others is completely orthogonal to it. The MPLS related portion involves attempting to deploy IP Multicast over [Border Gateway Protocol]/VPNs – the [IETF] “Rosen draft” – which allows private multicast domains to transit a MPLS-enabled core, and preserve most, if not all, of the key advantages of multicast, like non-replication of streams over a given link.

We will contrast this with providing private Layer 2 VPNs and running existing multicast protocols directly on those paths, which inherently can lead to replication. This investigation is crucial as more enterprises use multicast as part of their business and need to interconnect far-flung sites.

During hot stage testing, we were able to get a single vendor’s implementation to work at the provider edge, over a multi-vendor core. At the show, we intend to bring additional implementations into the mix at the edge and see how they interact. This is likely to be quite interesting, as the Rosen draft has one of the common pitfalls of modern standards: it specifies three possible sets of handling rules, with two different encapsulations. Thus with six different “draft-compliant” scenarios, interoperability is far from certain.

How many vendors are involved? How many platforms – label edge routers (LER), label switch routers (LSR) – connected via what speed links?

Trovsik: We have 24 participating vendors and 10 supporting vendors. About 15 are router vendors, and three are test equipment vendors that will also act as LERs and do IPv6 and multicast. We will have about four, core routers and 25 edge devices, though some of these will be doing IPv6 and multicast and not MPLS. We also have vendors of traffic analyzers, traffic policers and path optimizer technology participating.

What services – TDM, ATM, IP, frame, Ethernet, video, others – are you running across the MPLS network? How is each service benefiting – or not – from MPLS?

Papneja: For Layer 2 specific VPNs, based on the hardware availability, any-to-any connectivity will be demonstrated. For example, at one site, the attachment circuit could be Ethernet, port-based, and the remote end could be virtualized Ethernet ports, or virtual LANs. Other types of attachment circuits that will be carried across MPLS transport include ATM [virtual path identifier/virtual circuit identifier] and frame relay [data link circuit identifier]. With a network consisting of this many vendors and different routers, it was necessary to choose a few commonly used interface types as the preferred. Gigabit Ethernet and OC-12/OC-48 are the technologies we chose for the core.

Could you summarize the objectives behind the service-level agreement (SLA) aspects of your tests? What are the particular challenges in mapping quality-of-service (QoS) mechanisms at the edge of the network to those in the core, and then synchronizing these with edge and core fail-over mechanisms?

Papneja: Since this demo will show QoS aspects of a traffic-engineered core, several Label Switch Paths (LSP) will be established to carry Gold, Bronze and Silver services. These LSPs will also use color constraints as defined in RFC 2702. A demo case will be shown that shows the capability of the edge nodes to map high-priority traffic on the LSPs designed to support Gold service.

What are you exploring with regard to IPv6 and IPv6/IPv4/MPLS integration?

Papneja: The goal of this testing is to demonstrate various transition mechanisms that a service provider would like to evaluate as this does involve an immediate upgrade of their IPv4 core infrastructure. This addresses the issues of supporting the customers who have or are planning to migrate to IPv6 services due to various reasons. The results of the test were encouraging, but work still needs to be done in this area.

Martin: MPLS and IPv6 can be combined to create a very useful mechanism for enterprises to be able to deploy multi-site IPv6 without the service provider being required to fully IPv6 enable their infrastructure. Building on our previous success with IPv6 over BGP/VPNs, the AII team will test new implementations and equipment, validating both interoperability and functionality. Finally, our long reach goal is to determine the state of IP Multicast for IPv6. It’s been a fundamental part of the protocol from the beginning, but has received very little attention as the more basic capabilities of IPv6 were fleshed out. We’re looking to determine which vendors of both network and end nodes have support and if they’re basically interoperable.

Are you able to determine from these tests whether MPLS will improve productivity and cut operational costs? Can it literally carry multiple services seamlessly between remote sites while ensuring specific SLA/QoS characteristics for each service?

Papneja: The answer to this question depends on the scenario and what a service provider is looking to get from using MPLS. It is very difficult to generalize this statement across the industry. But, if you look at the case studies of the ISPs that have moved to a converged core based on MPLS, they have experienced the benefits of this transition. MPLS has really helped carriers converge their multiple networks onto a common MPLS-enabled IPv4 core, and that has significantly reduced operational costs and eased network management. Based on our testing, one could see how MPLS is helping carriers to carry multiple services seamlessly between multiple sites.