New Ethernet test standards and procedures address changing network traffic

Service providers have significant interest in testing multiple traffic streams simultaneously to confirm the policing per stream, validate the transfer time and jitter across the network, and ensure the network can manage bursts of traffic for short durations.

Pennwell web 408 239

Network traffic requirements have diversified in recent years, transitioning from data centric to very mixed, with much more importance placed on real-time applications such as video and voice. The fact that network elements buffer traffic raises concerns about the potential effects on such real-time applications across the full network, especially if they are poorly implemented.

In most cases, the line rate of the data pipe can be increased to match future customer requirements. Service providers usually limit the transmission rate or police the link based on a service level agreement (SLA) or by contract terms. Most service providers limit customer traffic rates at the network ingress and egress points.

Service providers also can offer different Ethernet classes of service, usually via virtual local area networks (VLANs) or differentiated services code point (DSCP). Some service providers are starting to consider burst traffic for different durations, though this type of implementation isn’t common in today’s Ethernet networks.

With the combination of changing end-user traffic profiles (including multiple frame sizes) and streams that require different traffic priorities through the network, service providers discovered some shortcomings in the RFC 2544 standard. Many service providers also expect that they will require the network to offer a per-stream traffic policing capabilities, not a less complicated rate-limited model. Service providers therefore have significant interest in testing multiple traffic streams simultaneously to confirm the policing per stream, validate the transfer time and jitter across the network, and ensure the network can manage bursts of traffic for short durations.

Traffic policing parameters

Most modern switches and network interface devices (NID) can set different traffic policing parameters. When activated, a policer will monitor the incoming frames and determine their color mode (CM). If the CM is set to color-aware, the policer will then monitor incoming frames and assign them the relative color of green or yellow based on the frame header matching the policer setting and current information rate (IR).

Once confirmed to be color-aware, the frames are passed to the first of two token buckets (Figure 1). Frame headers are then checked to confirm the color they are tagged, commonly via the DSCP or priority code point (PCP) bits within the header. An incoming green frame IR is compared to the committed burst size (CBS) tokens in the bucket. If tokens remain in the bucket, the frame will consume a token and be passed to the egress of the network element. When the IR is lower than the CBS token replenishment rate, the bucket will be classified as full.

Pennwell web 408 239

Figure 1

Frames tagged as yellow and frames passed from the CBS bucket will be checked against the excess burst signal (EBS) bucket tokens. If the IR is lower than the number of tokens, they will be allowed to pass. Any frames above this rate will be tagged as red and discarded.

With networks evolving, a new standard – ITU-T Y.1564 – was developed. It addresses these different network configurations and ensures quality is maintained across networks with multiple streams with different policing parameters. The new standard also enables the engineer to input the service acceptance criteria (SAC) information that is normally based on a subset of the user’s SLA. By inputting the SAC information before the test is conducted, it’s possible to set basic pass/fail criteria to simplify the results and locate possible points of concern for the engineer. To make the tests more efficient and address all areas, the standard has been written around two core components -- Service Configuration Test and Service Performance Test.

Service configuration test

During the Service Configuration Test stage, each of the individual test flows are completed sequentially, confirming there are no network configuration issues. The service provider can configure each test flow according to frame sizes or a mixture of frame sizes, referred to as an EMIX, as well as adjust the throughput and other header information, such as MAC addresses, VLAN settings, IP addresses, and DSCP. The standard also allows engineers to configure different Service Configuration Tests, such as:

  • CIR: color-aware and non-color-aware, simple or stepped
  • EIR: color-aware and non-color-aware
  • Traffic policing: color-aware and non-color-aware
  • CBS: color-aware and non-color-aware
  • EBS: color-aware and non-color-aware with CIR=0, color-aware and non-color-aware with CIR>0.

The configured tests are then completed in seconds. Information such as IR, frame loss ratio (FLR), frame transfer delay (FTD), frame delay variation (FDV), and frame loss ratio with reference to the service acceptance criteria (FLRSAC) can be monitored and recorded.

Figure 2 shows frames traveling at the CIR, then bursting to the CBS. When conducting such a test, the equipment used must also comply with specific pre-burst and post-burst gaps to ensure the token buckets are in the correct status.

Pennwell web 419 101

Figure 2

Service performance test
Once the network configuration test is completed, service providers must confirm the network can operate under load over a configured time duration. The Service Performance Test (Figure 3) completes this phase by generating all test flows simultaneously at the CIR for a period of time – either 15 minutes, 2 hours, or 24 hours. The time period can also be selected by the user.

Pennwell web 341 170

Figure 3

Placing the network under load with multiple test flows for this time duration enables the engineer to see if other services are affecting the service under test. It also allows for statistics such as AVAIL (availability) and Un-AVAIL to be measured. With the test instrument generating each test flow and recording the IR, FTD, FDV, FLR, and AVAIL results for each frame simultaneously, test time is dramatically reduced.

The ITU-T Y.1564 standard offers a significant advancement on traditional testing methods used by service providers or manually configuring multiple streams. One of many key points is the ability to confirm each test flow at rates that exceed the network configuration, and then complete a timed test with all test flows concurrently.

As network services advance to include policing by color and burst rates, this standard will become essential for commissioning a circuit and completing testing after repair or during fault verification.

Stuart Whitehead is a business development manager for Anritsu Co. He has spent more than 20 years in the telecommunications industry, with a board range of experience stretching from optical communications to data technologies. In recent years, Stuart was involved in defining the ITU-T Y.1564 standard.

More in Test