Multiservice Switch Test Highlights:Alcatel StarsTerrific ATMGood MPLSOther Vendors MIA

November 26, 2002

37 Min Read
Multiservice Switch Test

One of the big challenges facing carriers right now is how to boost the capacity of ATM infrastructure while paving the way for the rollout of IP-based services using MPLS. The most likely solution appears to be a new generation of multiservice switches, high-capacity devices that aim to handle ATM and MPLS equally well.

“Aim to” may be the operative words here. Plenty of vendors have announced multiservice switches, but how many of them can deliver blistering performance when handling IP and MPLS as well as ATM?

To get an answer to this question, Light Reading asked the European Advanced Networking Test Center AG (EANTC) to run an exhaustive series of tests on this type of equipment.

The tests were groundbreaking in three respects. First, they were truly independent; they were paid for by Light Reading, not by participants. Second, they were conducted by EANTC, a lab with a world-class reputation for testing ATM and MPLS equipment. And third, the tests themselves were very thorough – a serious effort at pinning down the ATM, IP, and MPLS performance parameters that matter for most operators.

So, what was the outcome?

The good news is that at least one vendor – Alcatel SA (NYSE: ALA; Paris: CGEP:PA) – has a multiservice switch that's likely to meet and exceed expectations of carriers. The Alcatel 7670 RSP passed all tests, and blew the doors of some of them. The niggles we had (no product is perfect) were over minor points that have either been rectified in subsequent releases of software or wouldn’t present a problem in the real world.

The bad news is that no other vendor was prepared to have its multiservice switch undergo the same series of tests. Many of them studied the test plan with great care and even suggested revisions to it, but that's as far as they got. Every man-jack of them bowed out.

Why? They had their excuses, but the bottom line is that Alcatel proved that its multiservice switch works in the world's first independent test of this type of equipment: Everybody else didn't – leaving questions hanging over whether their switches are up to snuff.

This report goes into the details of how the Alcatel 7670 RSP was tested, and what results were obtained. A hyperlinked summary follows:

  • Page 2: Background

    • Why we staged the test, what we focused on, what test equipment we used, details of Alcatel's switch, background reading

    Page 3: Results in Nutshell

    • Our scoring system explained, plus the results of all 17 tests together with brief comments

    Page 4: No Shows

    • Who was invited to participate in the test but didn't turn up, with comments and links to relevant articles

    Page 5: MPLS Signaling Performance & Capacity

    • Sustained RSVP-TE path establishment

    • RSVP-TE tunnel capacity

    Page 6: ATM Signaling Performance & Capacity

    • ATM call establishment performance, UNI interface

    • ATM call establishment performance, PNNI interface

    Page 7: MPLS, IP, ATM Data Throughput Performance & Delay

    • MPLS packet forwarding

    • Basic IP forwarding and routing

    • IP/MPLS data latency

    • ATM data latency

    Page 8: Queuing & Prioritization

    • MPLS queue prioritization

    • ATM congestion control based on service category

    Page 9: Rerouting Performance

    • MPLS tunnel rerouting performance

    • ATM SPVC reroute performance

    Page 10: Service Availability During Software Upgrade

    • ATM availability

    • IP/eBGP availability

    • MPLS RSVP-TE availability

    Page 11: Ships in the Night

    • Sharing nodes handling ATM and MPLS

    Page 12: Glossary

    • Terms and abbreviations used in this report

About the Author: Carsten Rossenhövel is managing director, research and manufacturer testing, of European Advanced Networking Test Center AG (EANTC). He may be contacted at [email protected].

Want to know more? Carsten Rossenhövel, together with representatives from Alcatel, Agilent, and Light Reading, will be discussing this test in a session at next week's Lightspeed Europe 02 conference in London. For more details, click here.

In order to put this test in perspective, it's important to recognize two major trends in telecom networks that are likely to influence purchasing decisions regarding multiservice switches.

First, the rollout of DSL (digital subscriber line) technology in access networks is forcing service providers to upgrade their Asynchronous Transfer Mode (ATM) infrastructures.

This is often because their existing ATM switches simply can't cope with the number of connections they're now having to handle – bearing in mind that each DSL user needs at least a couple of ATM connections. The rollout of 3G (UMTS) mobile networks is likely to have a similar impact.

The key point here is that the scaleability of ATM signaling has become a crucial issue – even more so than the overall carrying capacity of switches in some cases.

The second major trend is the emergence of Multiprotocol Label Switching (MPLS) as a mechanism for aggregrating customer data IP streams in carrier networks, to make them manageable. It underpins the rollout of IP-based services such as VPNs (virtual private networks) and LAN-interconnect, services that promise to help carriers make a profit sooner or later.

Although the rollout of MPLS is still in its early days (and there are those who question whether it's really needed at all), carriers can't ignore it. They need to make sure that whatever ATM equipment they install now will support MPLS and native Internet Protocol (IP) when and if they need it – and not just support it but also deliver outstanding performance so they're not left behind in the race to roll out next-generation IP services.

Light Reading's Tests

Plenty of vendors say their multiservice switches address both of these concerns. They can handle much higher numbers of ATM connections in addition to much more data; and the same switch will also turn in blistering MPLS performance when carriers migrate to a next-gen infrastructure.

In order to see whether vendors can deliver on these promises, Light Reading commissioned EANTC to run a public performance evaluation of next-gen ATM/MPLS multiservice switches for service provider networks. The topmost questions were:

  • 1. How well do the switches integrate ATM and MPLS in the backbone?

    2. How well do they manage to combine ATM’s rich traffic management features and high availability with MPLS functionality and performance?

The test focused on ATM and IP/MPLS in parallel, each of the technologies taking around half of the test cases. Naturally, data throughput performance is not the only requirement of a carrier – feature richness, signaling and routing robustness, and overall switch resilience are often at the top. This is what we evaluated:

  • Data forwarding performance

  • Signaling performance

  • Traffic engineering

  • Robustness/resilience

Other important aspects like provisioning, network management, operations, and billing and accounting are usually implemented differently in each device. We left them out of this test, which aimed to compare a common set of functions that all multiservice switches offer.

It's important to note that there are different sorts of multiservice switch. Traditionally, the term has been applied to edge devices that enable carriers to offer a range of services such as frame relay and circuit emulation. These are mature, well proven products.

This test focuses on what could be termed "next-generation multiservice switches," those that address the need to boost ATM capacity and provide a migration path to MPLS.

For this test, we stipulated that switches must have an internal ATM connection capacity of at least 40 Gbit/s. Other kinds of backplanes – for IP or Ethernet packet data, for instance – were optional. The switch had to provide legacy Layer 2 (ATM) interfaces and IP transport integration with MPLS.

Since structuring larger MPLS networks with hundreds and more MPLS routers is becoming a reality, it is important for customers to know about the limits of the data plane (forwarding speed) and especially the control plane (signaling and routing implementations) of their network components.

As already noted, operator requirements for the ATM side of these switches are also changing, to support DSL and UMTS deployments. Consequently, the test plan evaluated ATM-specific control plane parameters in parallel.

Test Equipment

A comprehensive set of test tools from Agilent Technologies Inc. (NYSE: A), in combination with EANTC test suites, was used to simulate dynamic MPLS network topologies and traffic patterns within the test bed and measure their affects on multiservice switch performance.

The Agilent equipment included:

  • Agilent RouterTester 900

  • Agilent QA Robot

  • Agilent Broadband Series Test System (BSTS)

For more detailed information on this test equipment, please go to:

Details of the test methodology are given in the descriptions of individual tests, on subsequent pages.

Alcatel's Switch

As noted, the Alcatel 7670 Routing Switch Platform (RSP) was the only switch tested.

For product details on Alcatel's Website, click here

Light Reading articles about the Alcatel 7670 RSP:

  • Alcatel ATM Switch Steps Up

  • Alcatel, BT Sign $167M Deal

  • Belgacom Picks Alcatel Routing Switch

  • Alcatel Passes MPLS Testing

  • Alcatel Completes MPLS Tests

  • Alcatel Launches 7670 With ACEIS

  • China Telecom Picks Alcatel

  • Optus Deploys Alcatel RSP

Background Reading on Multiservice Switches, ATM, and MPLS

The Alcatel 7670 RSP passed all tests. In most cases, performance met or exceeded our expectations, sometimes by a long way.

There is no question that the Alcatel 7670 RSP proved itself to be a true multiservice switch. Its data plane and control plane performance was great in all applications, whether MPLS, pure IP, or pure ATM.

The 7670 RSP also supported all requested features, so all test cases could be performed – none had to be left out.

In a few MPLS test cases, the control plane or data plane had performance limitations. However, none of these instances would present a critical problem in real-world networking applications.

The results of the reroute performance test reflect the fact that MPLS fast rerouting (see MPLS Vendors Demo Fast Reroute) has not been implemented in the 7670 RSP yet.

A scoring system is used in this report to give an overall assessment of each of the 17 aspects of the Alcatel switch that were tested:

score1.gif – Poorscore2.gif – Fairscore3.gif –Goodscore4.gif – Very Goodscore5.gif – Excellent

A summary of all the tests and scores, together with brief comments, are provided in the table below. Detailed results follow in subsequent pages.

table1.gifSeventeen vendors were invited to participate in this test. Participation was free – Light Reading shouldered the cost – and vendors were given ample opportunity to comment on the test plan and suggest revisions.

Indeed, the test plan was modified after feedback from potential participants, to give equal emphasis to ATM and MPLS. Previously, the test had focused mainly on MPLS.

As noted, all but one vendor – Alcatel – declined to participate in the test or didn't reply to our invitation. We got a variety of reasons for not participating, including lack of available products ("they're all in customer trials"), lack of resources, and quibbles with the test plan.

Check out the results of this Light Reading Research Poll for some views on such excuses, and the importance of vendors not paying to participate in tests.

Here's a list of the vendors that were invited to participate in the test, and didn't, together with comments and links to relevant articles, where available and appropriate.

Goal

This set of tests focused on the scaleability of the Alcatel 7670 RSP when handling floods of MPLS RSVP-TE (resource reservation protocol – traffic engineering) path messages. Two particular issues were baselined:

Sustained RSVP-TE path establishment How fast can the switch establish new paths? This is important in everyday life (for small bursts) and during major network outages when heavy rerouting takes place (for long bursts of signaling messages).

RSVP-TE tunnel capacity Can the switch handle a realistically large number of LSPs (label-switched paths) in parallel? This is important when the network is loaded under normal conditions and becomes crucial when the switch needs to take over additional rerouted connections for a limited time.

Test Setup

The setup below was used to test both of these aspects when the Alcatel 7670 RSP was being used as an intermediate LSR (label switch router) – in other words, in the middle of an MPLS network.

image11.jpg

The Agilent RouterTester's MPLS Emulator bombards the Alcatel switch with floods of MPLS RSVP-TE path messages. Agilent's QA Robot reads the corresponding messages coming out of the downstream side of the switch. This was done using one input and one output port, and then two input and two output ports.

The diagram below shows how the setup was modified to repeat the tests when the Alcatel 7670 RSP was being used as an Egress LER (label edge router) – in other words, at the downstream edge of an MPLS network.

image12.jpg

Sustained RSVP-TE Path Establishment

The Agilent QA Robot stressed the switch with LSP establishment requests at maximum speed, with the goal of measuring per-port and per-switch speed.

Two different situations were emulated:

  • Small rerouting event – 50 LSPs were established in a small burst

  • Major rerouting event – 1,000 LSPs were established as quickly as possible

We certainly gave the switch a hard time by offering such a lot of LSP requests at wire rate. The device under test needed to either process them at wire speed or provide a suitably large buffer.

Overall, the switch delivered superb performance, only reaching a limit in a few 4-port tests.

score4.gif

The following two charts show the results in more detail.





The 7670 RSP established all tunnels. With more than 700 tunnels established per second, the setup performance was excellent, even for large bursts of 1,000 tunnel setups, which typically happen during major network reroutings. Small bursts of 50 tunnel setups, which are more common, were processed with even higher performance of up to 1,137 tunnel setups per second.

In two scenarios, the Alcatel switch was overloaded by 2x500 path messages arriving on two ports at maximum traffic generator speed. The switch ignored around 350 path messages – the load generator retried their establishment after 30 seconds, as it would in a real network. The retry time is the reason for the low setup performance of 19 tunnels per second in these cases, shown in the first chart. Although this may look bad, this behavior conforms to the standards; it affects only performance under heavy rerouting scenarios.

RSVP-TE Tunnel Capacity

The RouterTester sequentially established as many MPLS LSPs as possible. This was done at medium speed to ensure the switch was not overloaded purely by the number of path requests per second. The test halted as soon as the switch rejected further requests, when the maximum LSP capacity had been reached. All LSPs remained active during the test duration. To ensure the vendor couldn’t cheat, we verified the capacity per port, per module, and per switch.

score3.gif

Alcatel passed the test case. There is a switch-wide capacity limit of 4,000 LSPs enforced, no matter how many ports are used.

Is this enough? That's an interesting question. As long as RSVP-TE is used in medium-sized networks to aggregate large amounts of data into tunnels for traffic engineering, very probably yes: There are no accepted standard capacities in the industry yet. For larger networks and especially for use in edge devices, the required capacity should be calculated carefully on a per-project basis.

This is why we gave the Alcatel 7670 RSP a score of only three stars – good but not great – for this test.

Goal

This set of tests focused on the scaleability of the Alcatel 7670 RSP when handling large numbers of ATM virtual circuits, concentrating on the scaleability of the signaling system and its overall capacity in terms of the number of simultaneous connections it can hold. In other words, this is the ATM equivalent of the MPLS tests covered in the previous section.

This has become of much greater importance in recent years because of the widespread rollout of DSL. This means that the number of virtual connections an ATM switch can handle is becoming just as important as, if not more important than, the amount of data it can handle.

The issue promises to become even more crucial as 3G mobile networks are deployed, because once again, each base station is likely to need a couple of ATM virtual connections.

Two particular issues were baselined:

ATM call establishment performance We verified robustness (long-term stability of the signaling implementation) and performance (short-term maximum speed). This was done for three classes of connection – UBR (unspecified bit rate), CBR (constant bit rate), and VBR (variable bit rate) – and for three types of signaling – UNI (user network interface) and flat and hierarchical PNNI (private network-to-node interface) signaling.

ATM call capacity What is the maximum number of simultaneous ATM signaled connections the switch can hold? Capacity counts in busy ATM networks, and it is especially important in failure situations when each redundant switch must take over a large number of additional connections. As in the equivalent MPLS test, we asked for the per-port, per-module, and per-switch capacities.

Test Setup

Alcatel's switches were connected with two ports, then with four ports to the tester, and the test was executed for point-to-point connections.

In the first test, the ports were all located on one interface module; later on, they were on different modules. This way, the performance could be tested:

  • per port (on one or on different modules)

  • per module (on the same module)

To assess the ATM UNI call setup performance, simple point-to-point connections were tested by connecting ports of a single Alcatel 7670 RSP to a call generator.

To assess ATM PNNI call setup performance, two switches were connected via a call generator. The transmit port was connected to one switch, the receive port to the other. Both switches were connected with one link, PNNI-enabled. All measurements were done three times.

The diagrams below show the test setup for a flat hierachy. The physical layer setup was identical in both cases. In the hierarchical setup, each switch was configured into its own basic and parent routing peer group – it had to manage both hierarchies. The two switches saw each other only at the top-most peer group.

Single Hierarchy PNNI Test Setup

image2.jpg Three-Tier Hierachy PNNI Test Setup

image3.jpg

ATM Call Establishment Performance, UNI Interface

By generating a lot of call setups in a short time, we aimed to quickly uncover any problems that might occur in long-term operation:

  • Whether the signaling implementation is likely to be stable

  • How the switch would accept a signaling storm typically observed in ATM SVC networks after power failures or other kinds of major network topology changes

The tests established 1,000 signaled calls (switched virtual circuits or SVCs) between two user (UNI) ports on one switch module in the shortest possible time. Later, the test was repeated with four ports in four different modules.

The important metrics measured are primarily the average number of established connections per second, plus the establishment delay introduced by the switch (call-establishment latency).

The results were outstanding.

score5.gif

The Alcatel 7670 RSP setup rates and establishment latencies of both scenarios were superb and exceeded the expectations by far. Not a single call was lost in any test run.

The very small average time to set up a call (including exchange of four signaling messages) of less than 70 milliseconds is impressive, given the substantial load presented by the call generator. The maximum latency of only 180 microseconds indicates the switch is not overloaded at all.

The 7670 RSP pushed the call generators to the limit in the four-port test: The vendor agreed with the results of the two-port/one-module test, but expected higher values in the four-port/four-module test run.

ATM Call Establishment Performance, PNNI Interface

The big question with these tests was whether the performance would drop in proportion to the number of hierarchies.

The quick answer is that latencies increased, but the results were still very good. Hence the score: score4.gif

The following two charts give the results in more detail.

The call establishment rates with flat PNNI hierarchy were comparable to the UNI results – and way beyond our expectations. However, the switch takes more time in processing the setup messages – the average latency is now between 290 and 960 milliseconds, and it is obvious the call admission control has more tasks to complete with CBR and VBR calls than with UBR (performance difference of 25 percent).

There is a natural performance decrease of around 35 percent for a three-level PNNI hierarchy, compared to a flat hierarchy. Still, the implementation performs very well, and the latency is stable at around one second even under sustained burst conditions.

ATM Call Capacity

Like the MPLS call capacity test, as many ATM signaled virtual channels as possible were established in parallel. The goal was to find the maximum simultaneous signaled call capacity, not the setup performance limit. The calls were established at a medium speed, and the emulator continued until calls started to fail.

The Alcatel 7670 RSP handled a maximum of 16,085 connections per port – that's 32,170 when two ports were used and 64,340 when four ports were used, regardless of whether the ports were on the same line card.

This exceeded the calculated requirements for the test by an order of magnitude. Hence our score:

score5.gif

Alcatel says overall switch capacity will continue to scale linearly as ports and line cards are added. It also says that it has denser line cards – the MR16 with 256,000 connections and an OC48/STM16 line card that has 128,000 connections.

Goal

After all the signaling control plane tests, we had a more detailed look at the data plane. Usually, one would expect wire-rate throughput in all cases. Trivially, an ATM switch provides wire rate with ATM forwarding, but how does it perform as an IP and MPLS router?

MPLS Packet Forwarding

In different roles, it has to do a number of additional tasks:

  • Ingress label edge router (LER) Filtering and classification take place, and labels are pushed onto packets

  • Intermediate label switch router (LSR) Only label swapping, the most simple role

  • Egress label edge router (LER) Removing label, forwarding IP packet based on IP routing rules

We distributed 1,000 routes to the system under test using OSPF (open shortest path first) emulation on the RouterTester, then configured label switched paths (LSPs) and sent bidirectional IP traffic through the LSPs. The packet sizes corresponded to a typical Internet mix (7 percent 40-byte packets, 56 percent 576-byte packets, 37 percent 1,500-byte packets). The tests were executed on POS (packet over Sonet) OC48. Throughput was then measured according to the Internet Engineering Task Force (IETF)'s RFC2544.

The maximum source-rate tested for LER ingress was not 100 percent, because MPLS signaling and OSPF routing need a small amount of bandwidth to work. We tested at a maximum of 99.8 percent throughput to ensure that OSPF and MPLS worked.

Results

score4.gif

The Alcatel 7670 RSP passed the more difficult parts of the test without any loss – ingress and egress LER functionality at POS OC48. The full 99.8 percent of traffic was forwarded in both cases, and not a single packet was lost during a sustained two-minute bandwidth test.

Working as an intermediate LSR, however, we discovered a lack of performance in the 7670. The maximum POS OC48 throughput was 97.9 percent in this case. According to Alcatel, the expected 99.8 percent throughput cannot be reached due to firmware/software issues with the 7670.

We verified that the problem was in the POS module rather than the core forwarding engine by running the same test with ATM interfaces – achieving the expected 99.8 percent thoughput.



Basic IP Forwarding and Routing

Next, we baselined the performance of IP forwarding and routing. These tests are pretty basic for an IP router – but not for ATM switches. So this is the proof that IP and ATM have been integrated successfully, both providing high performance to the users.

Two POS ports were connected with the Agilent RouterTester; 25,000 iBGP routes set up between these; and wire-speed traffic sent by the RouterTester with one IP flow per route. We used the same Internet traffic mix as before (see above). This time, we chose 99.9 percent throughput as the maximum bandwidth to allow BGP updates to be forwarded.

As expected, the Alcatel 7670 RSP passed this test without loss.Second, we checked the BGP table capacity. Using two BGP peers, as before, we advertised unique BGP routes in increments of 12,500 routes from each of the analyzer ports until the switch stopped redistributing the routes. The BGP table capacity of the Alcatel 7670 RSP was measured with 249,998 routes.

Finally, we verified the performance of the routing engine under routing load using longest-match lookups: We advertised 25,000 routes per port, and an additional 12,500 routes per port with shorter prefixes than some entries in the baseline table.

In parallel, IP data was sent at wire speed to see whether the routing engine load influences data plane throughput. We observed a small packet loss on one interface (about 20 packets/s) at 99.9 percent and at 50 percent loads. Alcatel attributed this effect to a hardware failure of a line card; after it had been changed, no packet loss was observed anymore, and the 7670 RSP mastered this test case, too: The maximum load of 99.9 percent was achieved without any problems.

The bottom line? Fault-free operation (if the hardware failure is ignored) and another top score:

score5.gif

IP/MPLS/ATM Data Latency

Throughput is only one half of the necessary data plane performance. The forwarding latency is equally important, especially for all interactive or real-time applications.

We verified latency on all kinds of traffic supported by the switch: IP, MPLS, and ATM. For the first two, variable size frames were sent through the switch, at a rate known to be lossless. The ATM latency test used single ATM cells instead.

IP/MPLS data latency

score3.gif

ATM Data Latency

score5.gif

Here are the detailed results.





The charts above show the maximum latency – the issue that most concerns carriers. Each column represents the average of maximum latencies found in four tests – two per direction of traffic.

The maximum latencies all fell between 60 and 100 microseconds for the MPLS streams over ATM OC12 (622 Mbit/s) interfaces, shown in the top chart.

In the second case – IP over an OC48 (2.5 Gbit/s) POS interface – latencies are generally much lower, as one would expect, because the transmission speeds are higher. However, one reproducible exception happened at 99.9 percent offered load when handling 512-byte frames. In this case the latency shot up to 370-375 microseconds – around 15 times higher than other latency readings. Alcatel said the increased latency for 512-byte packets is a known firmware issue, which will be addressed in a subsequent release.

The ATM cell transfer delay measured for OC12 ATM interfaces on one switch was as expected: At maximum load, it showed a good 26 microseconds.

Alcatel says the 7670 RSP has other modules that are designed for PNNI side interfaces. These have lower cell latency because they provide less traffic management functionality.

Goal

This first group of traffic engineering tests verified the basic ability of the multiservice switch to prioritize high-priority streams over low-priority streams – in both MPLS and ATM environments.

MPLS Queue Prioritization

MPLS traffic can be prioritized using three techniques:

  • Integrated Services (IntServ) Using RSVP-TE signaling messages to establish tunnels with well-defined QOS requirements

  • Differentiated Services (DiffServ) Using the TOS/DiffServ fields in IP/MPLS packets and local policy on each node to define the quality requirements for each MPLS packet without specific signaling

  • Diffserv is further divided into E-LSP (using multiple QOS classes within one MPLS tunnel) and L-LSP (splitting traffic with different traffic management requirements into different tunnels).

Each of these alternatives has its applications and its enthusiasts, so we tested all of them.

Test Setup

To test Alcatel's IntServ implementation, two switches were configured, one as intermediate LSR, the other as egress LER, as shown in the diagram below.

image4.jpg The analyzer sent two streams to the switches from two source ports – one high-priority stream and one low-priority, best-effort stream.

The traffic load on the low-priority stream was gradually increased to oversubscribe the output (destination) port. The test benchmarked delay and packet loss of both packets, expecting that only the low-priority stream would experience packet loss and delay.

The corresponding setup to test Alcatel's DiffServ implementations is shown in the diagram below.

image5.jpg In this case, a single switch was configured as an ingress LER, and, as before, low-priority traffic loads were increased until the egress link was oversubscribed; the traffic coming out of the switch was then analyzed.

ResultsIn every case, Alcatel's switch forwarded all of the high-priority traffic without packet loss, ensuring that only low-priority traffic was dropped when the connection was oversubscribed.

However, the 7670 got mixed results on latency, and thus didn't get a top score.

score3.gif

Here are the details:

Chart13.gifThe Alcatel 7670 RSP passed the IntServ test case very successfully. The high-priority stream didn’t see a change in packet loss and latency.

When using both forms of DiffServ, however, the latency of the high-priority data stream shot up, from below 50 microseconds to more than 200 microseconds under port congestion – which definitely should not happen.

Alcatel says this is a "known issue that occurs only at high levels of sustained congestion."

ATM Congestion Control Based on Service Category

We also ran the counterpart of the MPLS prioritization test, a verification of pure ATM congestion control.

Test Setup

image6.jpg ATM cell streams were sent from two ingress ports on two PVCs with different traffic contracts: one high priority; the other, best effort. Both PVCs sent the traffic to the same egress port of the switch, generating congestion.

As previously, the high-priority traffic should have been forwarded and only the best-effort stream should have suffered packet losses or delays. And that's precisely what happened.

score5.gif

Goal

The following tests verified that a multiservice switch can properly reroute signaled ATM and MPLS connections through the network. Although the mechanisms are fundamentally different for both technologies, the requirements are comparable:

  • Rerouting should result in only a small service interruption

  • Rerouting needs to work reliably for a large number of connections

MPLS Tunnel Rerouting Performance

One of the requirements for RSVP-TE traffic engineering is the capability to reroute an MPLS tunnel upon failure of a resource along the established path.

Test Setup

To evaluate, we set up two multiservice switches with two redundant links in between, as shown in the diagram below.

image7.jpg Next, a number of MPLS tunnels were configured on the RouterTester attached to both switches. The analyzer established these tunnels and started sending traffic at a fixed high rate on all of them. It was verified that no cell loss happened. Then, we disconnected the active link to force rerouting of all the tunnels while continuing to send data. Afterwards, the rerouting time of each tunnel was derived from the number of lost packets the analyzer detected.

Results

score2.gif

In the first test run, the Alcatel 7670 RSP showed a total rerouting time of 4.5 seconds for ten tunnels, and 9 seconds for 1,000 tunnels. In general, all LSPs were reestablished. The device did not show queueing.



Part of the time is necessary because the 7670 RSP observes the standard Sonet Alarm Declaration Timer (2,500 milliseconds) and RSVP Local Repair Timer (2,000 milliseconds).

Although Alcatel does not recommend reducing the Sonet Alarm Declaration Timer substantially in real scenarios, we ran the test a second time with each of the timers reduced to 100 milliseconds. The results are shown in the chart below.



Naturally, rerouting takes more time to reestablish 1,000 tunnels than ten tunnels. We measured 4.3–5.0 seconds – far away from what one would expect from "fast rerouting" mechanisms. Obviously, they are not yet implemented. (For more on MPLS fast reroute, see MPLS Vendors Demo Fast Reroute, MPLS Fast Reroute Gains Momentum and MPLS Fast Reroute Gets a Boost.)

Alcatel says that MPLS fast rerouting, with rerouting times below 50 milliseconds, is planned for the next release of the 7670 RSP.

Surprisingly, the switch took up to 8.7 seconds to reroute 1,000 tunnels in some cases. The expected time was 4 to 6 seconds. The result was partly reproducible but not consistent, and Alcatel could not explain it at the time of the test. Afterwards, it said that it was caused by a software defect that has been rectified in subsequent releases.

ATM SPVC Reroute Performance

With ATM, connection rerouting works differently: The network just tears down the connection if a segment becomes unavailable; the end system needs to take care of connection reestablishment. (There are some alternatives in new ATM Forum recommendations, but they are too new to be implemented anywhere.)

So we chose a kind of ATM connection for this test whereby the switches act as end systems themselves: Signaled Permanent Virtual Connections (SPVCs). This way, they have full control of the rerouting time.

Test Setup

We set up this test similarly to the MPLS reroute test.

image8.jpg

A number of SPVCs were configured on two switches, and PNNI with one peer group enabled on the network link between the two switches to allow dynamic rerouting.

Using a load generator we sent ATM cell traffic on all the SPVCs; we then physically disconnected the primary link between the two switches so the switches had to reestablish them over the other physical connection.

The cell loss (equivalent to rerouting time) was measured for different traffic categories. For this test, the Sonet Alarm Declare Timer of the Alcatel 7670 RSP was reduced from 2.5 seconds to 0.1 seconds, for the reasons explained in the MPLS rerouting test above.

Results

score4.gif

The Alcatel 7670 RSP passed this test: All connections were reestablished in a very short time. In more than twenty test runs, the signaling implementation proved to be very robust. The rerouting times for 5,000 connections are extraordinary, with an average rerouting time of 0.7 milliseconds per connection.

The rerouting time was only slightly different for traffic categories where connection admission control had to verify resource availability (CBR, rt-VBR, nrt-VBR, UBR+) and for service categories without that check (UBR). CBR and UBR were tested representing those two classes.

Goal

Network availability is affected not only by unplanned outages but also by planned upgrades and exchanges. While hot-swappable network modules are already industry standard, uninterrupted service during software upgrades is a rather new challenge.

Mastering lossless upgrades is one of the most challenging topics in multiservice switch implementation today. In the era of 99.999 percent availability, operators can’t afford a scheduled downtime for software upgrades anymore. Multiservice switches carrying voice and other real-time traffic, especially need to keep the famous 50 microsecond maximum connection interrupt time so that voice trunks remain established.

During an upgrade, the task for the switch is: Prepare a software upgrade on a standby CPU; copy all the static and dynamic configuration data from the active CPU running the old software (including ATM and MPLS signaled connections, IP routes, and other state information); and do the switch-over. If any of this status information cannot be copied accurately, the users will suffer loss of data, because ATM or MPLS connections need to be reestablished and IP routes exchanged with peers again.

Test Setup

image9.jpg We gave the Alcatel 7670 RSP a hard time. In the same two-switch setup used before, we configured up to:

  • 1,000 signaled ATM connections (SPVCs)

  • 20,000 IP routes using OSPF between the two switches and eBGP on the links to the generators (the multiservice switches acted as border routers)

  • 1,000 MPLS tunnels (LSPs) set up to destinations whose reachability was also advertised by BGP, so LSP outage is a function of both BGP reestablishment and RSVP-TE reestablishment during the upgrade

The load generators sent ATM, MPLS, and IP traffic on all these connections in parallel while the upgrade took place. Afterwards, lost cells and packets as well as interrupted connections were counted.

Results

ATM availability

score5.gifIP/eBGP availability

score5.gifMPLS RSVP-TE availability

score4.gifThe Alcatel 7670 RSP demonstrated superb performance for both ATM connections and IP flows – and very good performance for MPLS LSPs.

IP packet flows did not observe any packet loss during the software upgrade. Alcatel calls this feature "non-stop IP routing." eBGP peers are synchronized between the CPUs with hot-standby redundancy, so there is no need to reestablish any peerings.

MPLS LSPs had to be reestablished; but this happened within a very short time of less than 100 milliseconds. This seems more than acceptable, as long as MPLS is not used to carry voice TDM traffic. The interrupt times observed were in line with expected values, according to Alcatel’s product specification.

Goal

A very important aspect of ATM-to-MPLS migration is the ability to share nodes and links between ATM and MPLS, a feature with the lyrical name of "Ships in the Night." The simple variant is node sharing – the more complex one, link resource sharing.

This test case evaluates Ships in the Night functionality and performance for both situations.

What happens when ATM and MPLS fight for the same resources? Both worlds should share resources, assigning proper queue priorities.

Test Setup

To verify, we configured an ATM SPVC and an MPLS RSVP-TE tunnel over the same backbone link (STM4) running both MPLS and ATM.

image10.jpg The ATM connection was first set to CBR with peak cell rate set to 50 percent of the line rate of the common link, so transmitted ATM data would receive prioritized treatment. Sending 50 percent ATM data, we gradually increased MPLS load until the link was oversubscribed. As expected, the switch discarded only MPLS data – the ATM cells were still delivered and not queued.

Second, we exchanged roles: The ATM connection was configured as a UBR low-priority channel; and an IntServ traffic-engineered RSVP-TE tunnel was set up with a committed data rate (CDR) of 60 percent of the line rate. This time, we constantly transmitted 50 percent on the MPLS connection, gradually increasing the load of the ATM connection. As expected, the ATM virtual channel lost cells this time, while the MPLS tunnel was unaffected.

Results

In both cases, zero packet loss was observed on the high-priority streams, no matter whether an ATM SPVC or an MPLS LSP was configured as the high priority data stream.

Hence, our final score:

score5.gif

  • Abstract Node: A group of nodes whose internal topology is opaque to the ingress node of the LSP; an abstract node is said to be simple if it contains only one physical node

  • Downstream: The direction of the data flow toward the receivers or the egress node

  • Egress Node: The downstream edge node

  • Explicit Route Object (ERO): used to set up an LSP whose path is established by a means other than normal IP routing

  • Forward Equivalence Class (FEC): Packet streams to the same destination host or destination network which are handled in the same way in MPLS

  • Implementation Under Test (IUT): The protocol implementation to be investigated

  • Ingress Node: The upstream edge node

  • Label Edge Router (LER): ingress or egress MPLS router

  • Label Switched Path (LSP): A connection between MPLS routers that is established through a signaling protocol like RSVP-TE or LDP/CR-LDP

  • Label Switch Router (LSR): intermediate MPLS router

  • Penultimate Hop (PHOP): The case in which the penultimate node in an LSP removes the label stack from a packet before forwarding it to the egress node

  • Resource Reservation Protocol – Traffic Engineering (RSVP-TE): MPLS signaling protocol, used to establish and maintain LSPs

  • Soft State: A control state in hosts and routers that will expire if not refreshed in a specified amount of time

  • System Under Test (SUT); Device Under Test (DUT): This refers to the device that we are testing

  • Upstream: Signifies the direction towards the traffic source or ingress node



Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.

You May Also Like