The MPLS test approach - Technology Information

Proper installation requires analysis in several areas.

Today, equipment manufacturers, service providers and users have recognized that traffic engineering (TE) features need to be added to Internet protocol (IP) for a "more efficient Internet." Following individual efforts by many companies to create solutions, the Internet Engineering Task Force has proposed multiprotocol label switching (MPLS) as the standard for traffic engineering. The result has been heated activity in this area, with network equipment manufacturers (NEMs), such as Cisco, Juniper and others, rushing to implement MPLS on their devices, and infrastructure service providers (SPs), such as AT&T, Sprint and others, attempting to integrate this new technology to create competitive service advantages.

This activity has created a new emphasis on MPLS testing. As for any other protocol, there are many facets of testing required to guarantee proper MPLS implementation. What are some of those MPLS testing requirements?

For NEMs, there are many critical testing points in the product development/ release cycle. These include development testing (Dev Test) during software development; software quality assurance (SQA), which is done by an SQA team before trying the software out on the device; and system integration testing (Sys Test), which happens after software and hardware integration, and before shipment to the customers.

Service providers will also test devices from NEMs prior to deployment, and will have software testing and system testing done prior to deployment into their networks. In addition, both NEMs and SPs must also perform post-deployment troubleshooting if a device or a network fails in the field.

Two terms used interchangeably are implementation under test (IUT) and device(s) under test (DUT) (an IUT runs on one or more DUT). IUT and DUT denote the MPLS protocol implementation or MPLS-enabled device(s) being tested, respectively. The MPLS-enabled device could be a switch or a router.

MPLS technology is being used to set up traffic paths, called label switched paths (LSPs). Using extensions of existing IP-routing protocols and new MPLS signaling protocols, data traffic is sent over these paths, as opposed to allowing individual intermediate routers to make independent path decisions when sending traffic. MPLS testing must determine that all aspects of MPLS function correctly and efficiently, all of the time.

The scope and sequence of MPLS testing--which can involve a single device or a network of devices--can be defined as follows:

* conformance, * functional, * stress, * interoperability and * service verification.

MPLS TESTING SCOPE

Conformance testing. This type of testing involves rigorous checking, on a step-by-step basis, of each section of the MPLS protocol specification, varying protocol date unit types and contents. Conformance testing is normally conducted by the development or SQA groups of NEMs before handing software over to the sys test group, generally responsible for release.

Service provider evaluation laboratories may also want to ensure that NEM implementations conform to full protocol specifications, and can use conformance testing to accomplish this.

Functional testing. While this is similar to conformance testing, functional testing ensures that the protocol being tested works together with all other underlying and overlying protocols.

So, functional testing includes verification of the following:

* routing information has been properly exchanged, processed and updated in the DUT;

* signaling exchange information is correctly using this routing information and setting up the LSPs and

* data can be sent over these LSPs.

Functional testing is required to ensure that the above steps happen in every typical or required network scenario (topology) used by the SPs. Functional is generally conducted by the same groups as those performing conformance testing.

Interoperability testing. This category of testing is an important part of the testing process.

Interoperability (IOP) testing is often difficult to conduct for the simple reason that, to fully understand why a device from one NEM is accepting or rejecting a packet (e.g., an LSP setup request) from a device of another NEM, the logs of both devices must be synchronized and examined. While this can be done using an analyzer on the link between them, figuring out why a particular device is behaving in a particular manner can be difficult.

To facilitate this process, IOP testing events are often conducted between companies by university labs and industry bodies, such as the MPLS Forum. Normally, special interop test groups of the NEMs participate at these events, and are available to assist in analyzing device behavior.

Interoperability testing is also critical for SPs, which must ensure that new network equipment can "coexist" with legacy devices and technologies. A major part of service provider evaluation lab's efforts are often focused in this area, as well as the predeployment sys test groups.

Stress testing. If a DUT is conformant and functional (and also interoperates) in simple scenarios, the next question is whether the device will "scale" under real-life "load" conditions.

Three general areas exist for stress testing:

* Scaling. One purpose of stress testing is to test the DUT under load conditions, by setting up a large number of LSPs with the DUT, with exchange of large amounts of routing and signaling information.

* Data load. Once the LSPs are set up, large volumes of data are sent to determine if the DUT handles this data correctly.

* Random changes under load. When the DUT is under heavy load conditions, a random set of events can be generated. For example, a set of nodes connected to the DUT can go down, with this event information passed to the DUT by the routing protocols. The DUT then may have to update its internal tables based on this new information, set up new LSPs and send data over these new paths. Many other different types of events are also possible. This kind of testing is a key part of the sys test process at both the NEMs and SPs, and is used to benchmark the devices.

Service verification. MPLS provides SPs control over the quality of service (QoS) and resulting service-level agreements (SLAs) provided to their customers.

Service verification testing evaluates whether the SLA agreed on by the SP is actually being provided. This type of testing includes routing and signaling protocol negotiation, and the sending of traffic at the full negotiated data rate and LSP parameters (in other words, the QoS agreed on). This requires sophisticated equipment. As a result, this kind of testing is generally conducted by sys test groups at the NEMs and SPs.

TESTING GUIDELINES

The next question is how these tests are performed.

For conformance testing, a protocol implementation conformance statement (PICS) document can be created using the protocol specifications, detailing the features being implemented in the DUT. For functionality testing, the PICS document may be used, assuming that the underlying protocols have been verified to work correctly.

For stress testing, however, a device-specific guideline must be created, based on the "capabilities" of the DUT.

For interoperability testing, the test laboratories often develop interoperability test specifications, which detail the test scenarios and the expected behavior of the DUTs.

There is no set guideline for service verification testing--it is a combination of functional and stress testing and can be a challenging task to set up.

In order to perform these tests, a test platform will include various modules of software and hardware, and different types of interfaces on the hardware. A single point of control is preferred to speed testing operations and diagnosis.

The typical set of tools used include:

* protocol analyzer,

* traffic generator

* protocol validation test tool--which includes conformance- and functionality-testing capabilities,

* stress test tool,

* interoperability test tool and

* network emulator--which can be used for service verification and pre-and post-deployment network scenario emulation.

There are a number of freely available MPLS stacks on the Linux platform. Information can be obtained from MPLS mailing list archives. A network planning and analysis tool; conformance test tools for RSVP/ RSVP-TE and LDP/CR-LDP protocols; stress test tools for RSVP/ RSVP-TE and LDP/CR-LDP protocols; and MPLS analyzer and traffic generator products are available from various vendors and on various sites on the Internet. Search for MPLS, and learn more about the subject.

Gupta is a product marketing specialist with Agilent Technologies in Bedford, MA.

www.dtix.com Circle 274 for more information from Digital Technology

COPYRIGHT 2000 Nelson Publishing
COPYRIGHT 2001 Gale Group