Carrier Ethernet 915-2624-01 RevD

CARRIER ETHERNET

Black Book Edition 7

Carrier Ethernet

http://www.ixiacom.com/blackbook

PN 915-2624-01 Rev D

December 2011

December 2011

i

CARRIER ETHERNET

Your feedback is welcome Our goal in the preparation of this Black Book was to create high-value, high-quality content. Your feedback is an important ingredient that will help guide our future books. If you have any comments regarding how we could improve the quality of this book, or suggestions for topics to be included in future Black Books, contact us at [email protected]. Your feedback is greatly appreciated!

Copyright © 2012 Ixia. All rights reserved. This publication may not be copied, in whole or in part, without Ixia’s consent. RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the U.S. Government is subject to the restrictions set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR 52.227-19. Ixia, the Ixia logo, and all Ixia brand names and product names in this document are either trademarks or registered trademarks of Ixia in the United States and/or other countries. All other trademarks belong to their respective owners. The information herein is furnished for informational use only, is subject to change by Ixia without notice, and should not be construed as a commitment by Ixia. Ixia assumes no responsibility or liability for any errors or inaccuracies contained in this publication.

PN 915-2624-01 Rev D

December 2011

iii

CARRIER ETHERNET

Contents How to Read this Book ................................................................................................................ vii Dear Reader ................................................................................................................................ viii Introduction to Carrier Ethernet.................................................................................................. 1 Introduction to Ethernet OAM .................................................................................................... 5 Introduction to Ethernet Service Activation Testing .............................................................. 13 Testing Provider Bridges (802.1ad) and Provider Backbone Bridges (802.1ah) ................. 19 Test Case: Provider Bridges 802.1ad E-Line Services .............................................................. 21 Introduction to Provider Backbone Bridges (802.1ah) .......................................................... 31 Test Case: Provider Bridges 802.1ah E-LAN Services .............................................................. 33 Ethernet/Link OAM (802.3ah) Functional Verification ........................................................... 45 Test Case: Ethernet/Link OAM Discovery Functional Verification........................................ 47 Test Case: Ethernet/Link OAM Event Notification .................................................................. 63 Test Case: Ethernet/Link OAM Remote Loopback ................................................................ 71 Service OAM ............................................................................................................................... 83 Test Case: Ethernet CFM – Fault detection with Continuity Check Messages .................. 87 Test Case: Impairment Testing - Drop and Delay CCM Messages .................................... 101 Test Case: Ethernet CFM - Fault Verification using Loopback ........................................... 113 Test Case: Ethernet CFM - Fault isolation using Linktrace ................................................... 123 Test Case: E-LMI – Testing a Device as a Customer Edge (UNI-C)..................................... 133 Test Case: SLA Configuration and Performance testing per-EVC using Y.1564 .............. 147

PN 915-2624-01 Rev D

December 2011

v

CARRIER ETHERNET

How to Read this Book The book is structured as several standalone sections that discuss test methodologies by type. Every section starts by introducing the reader to relevant information from a technology and testing perspective. Each test case has the following organization structure: Overview

Provides background information specific to the test case.

Objective

Describes the goal of the test.

Setup

An illustration of the test configuration highlighting the test ports, simulated elements and other details.

Step-by-Step Instructions

Detailed configuration procedures using Ixia test equipment and applications.

Test Variables

A summary of the key test parameters that affect the test’s performance and scale. These can be modified to construct other tests.

Results Analysis

Provides the background useful for test result analysis, explaining the metrics and providing examples of expected results.

Troubleshooting and Diagnostics

Provides guidance on how to troubleshoot common issues.

Conclusions

Summarizes the result of the test.

Typographic Conventions In this document, the following conventions are used to indicate items that are selected or typed by you: •

Bold items are those that you select or click on. It is also used to indicate text found on the current GUI screen.

•

Italicized items are those that you type.

PN 915-2624-01 Rev D

December 2011

vii

CARRIER ETHERNET

Dear Reader Ixia’s Black Books include a number of IP and wireless test methodologies that will help you become familiar with new technologies and the key testing issues associated with them. The Black Books can be considered primers on technology and testing. They include test methodologies that can be used to verify device and system functionality and performance. The methodologies are universally applicable to any test equipment. Step by step instructions using Ixia’s test platform and applications are used to demonstrate the test methodology. This seventh edition of the black books includes eighteen volumes covering some key technologies and test methodologies: Volume 1 – Higher Speed Ethernet

Volume 10 – Carrier Ethernet

Volume 2 – QoS Validation

Volume 11 – Ethernet Synchronization

Volume 3 – Advanced MPLS

Volume 12 – IPv6 Transition Technologies

Volume 4 – LTE Evolved Packet Core

Volume 13 – Video over IP

Volume 5 – Application Delivery

Volume 14 – Network Security

Volume 6 – Voice over IP

Volume 15 – MPLS-TP

Volume 7 – Converged Data Center

Volume 16 – Ultra Low Latency (ULL) Testing

Volume 8 – Test Automation

Volume 17 – Impairments

Volume 9 – Converged Network Adapters Volume 18 – LTE Access A soft copy of each of the chapters of the books and the associated test configurations are available on Ixia’s Black Book website at http://www.ixiacom.com/blackbook. Registration is required to access this section of the Web site. At Ixia, we know that the networking industry is constantly moving; we aim to be your technology partner through these ebbs and flows. We hope this Black Book series provides valuable insight into the evolution of our industry as it applies to test and measurement. Keep testing hard.

Victor Alston, CEO PN 915-2624-01 Rev D

December 2011

viii

CARRIER ETHERNET

Carrier Ethernet Test Methodologies

The tests in this booklet detail methodologies to verify the performance of Carrier Ethernet service enabling protocols. Subjects include Provider Bridges, Provider Backbone Bridges, Link OAM, Service OAM, E-LMI and Y.1564.

PN 915-2624-01 Rev D

December 2011

ix

CARRIER ETHERNET

Introduction to Carrier Ethernet Ethernet was developed as a LAN technology and was quickly adopted for its high speed, low latency, and plug-and-play features. Defined as an international standard by the IEEE 802.3 committee it has been widely deployed in the LAN. Since Ethernet provides the lowest cost per bit there was significant interest to use Ethernet in other parts of the network. First, Ethernet pushed into the Metro Area Networks (MAN) and its lower cost, lower complexity over existing technologies such as SONET/SDH proved successful. Although Ethernet usage continued to expand it was not without challenges. As a replacement technology for other well established it lacked feature sets that other more mature MAN technologies addressed like scalability and reliability. For example, SONET/SDH can recover from a fault in sub 50 milliseconds. In an effort to accelerate the development and adoption of Ethernet as a service enabling technology the Metro Ethernet Forum (MEF) was created. In addition to MAN services there was significant interest in using Ethernet as WAN L2 VPN service. The MEF has helped to advance this effort by defining Ethernet Services and related technical standards. Since Ethernet is evolving from a LAN technology to a MAN technology and now even a WAN service it is becoming “Carrier Grade” and is now referred to as Carrier Ethernet. To achieve this status, the MEF has defined five attributes: Standardized Services, Scalability, Reliability, Service Management and Quality of Service (See 0).

Figure 1-MEF Carrier Ethernet Attributes

To address the requirement for Standardized Services the MEF has defined the technical specification MEF 6 (now updated to 6.1) which outlines E-Line (EPL or EVPL), E-LAN and E-Tree services. Ethernet Private Line (EPL) defines the User Network Interface (UNI) as a physical Ethernet port. Ethernet Virtual Private Line (EVPL) defines the UNI as a virtual (VLAN tagged) interface. E-Line services can be used to replace traditional point-toPN 915-2624-01 Rev D

December 2011

1

CARRIER ETHERNET point services built by legacy technologies like TDM, SONET/SDH, Frame-Relay or ATM. E-LAN services can be used to replace multi-point-to-multi-point services built by legacy services like SONET/SDH, Frame-Relay, ATM or as an alternative to L3 based IP/MPLS. ETree is a rooted multipoint and again replaces services built with legacy technologies. These new connections are defined as Ethernet Virtual Connections (EVC). New Carrier Ethernet services are very attractive to enterprise customers since they are typically higher speed, lower cost and more flexible than legacy technologies. They are also effective for Service Providers since Ethernet is a less complicated, more cost effective transport to build services on. It is important to note that the MEF defines Carrier Ethernet (CE) as a service from UNI to UNI. They do not define “how” a service is build end-to-end. Many networks have legacy infrastructures in the Metro and leverage an IP/MPLS core, so the actual implementation may be a mix of interworked technologies. A provider may choose to extend MPLS into the Metro and use PWE and VPLS to build CE services. Or, a provider may choose to upgrade or replace their existing Metro technology (like SONET) with native Ethernet switches (see 0). MEF 9 specification defines how to test MEF 6 service definitions.

Figure 2-Carrier Ethernet Architecture

To address the Quality of Service requirement the MEF has defined the MEF 10 (updated to 10.2) technical specification to define Service Attributes establishing traffic classes. This requires IEEE 802.1Q (VLAN) tagging providing use of the priority bits. Implementing QoS provides the ability to offer Service Level Agreements (SLA) and service profiles. The service definition can include bandwidth, latency, delay variation (jitter), frame loss and other bandwidth related parameters. MEF 14 specification defines how to test MEF 10 service attributes. To address the scalability attribute of Carrier Ethernet services additional protocol development has evolved including IEEE 802.1ad Provider Bridges and IEEE 802.1ah Provider Backbone Bridges. These technologies enable service providers to build scalable services and keep customers traffic virtually separate using enhanced Ethernet technology.

PN 915-2624-01 Rev D

December 2011

2

CARRIER ETHERNET

Provider Bridges The IEEE standard 802.1Q introduced VLAN “Q” tagging which provided a mechanism to virtually separate traffic into virtual LANs. The VLAN tag also added three bits for priority defined as Priority Code Points enabling up to eight levels of service. This was extremely effective for LAN based networks since IT managers could provide connectivity with priority and security. As carriers began to use Ethernet in MANs a new standard was developed, IEEE 802.1ad Provider Bridges (PB). This standard defines how to add an additional VLAN tag to the Ethernet frame so that the provider could use tagging without using the customer tag. This new tag is defined as the S-VLAN tag (for Service Provider) while the existing tag is defined as the C-VLAN tag (for the Customer). One additional difference between the C-Tag and S-Tag is that the Canonical Format Indicator (CFI) bit is now used as a Drop Eligible Indicator (DEI) (see 0).

Figure 3-Sample Ethernet Frame Format adding VLAN Tags

This technology is often referred to as Q-in-Q since the original standard 802.1Q defines a VLAN tag and a second “Q” tag is being added. Since 802.1ad became a standard in 2005 it has been widely deployed as Ethernet use in the Metro increased. Leveraging Ethernet technology, 802.1Q and 802.1ad still use the same mechanisms including MAC address learning (with flooding) and Spanning Tree protocols are used for loop prevention. Two limitations have been exposed as services have grown: MAC Learning and the 12 bit VLAN address space. Since Provider bridges leverage Ethernet technology it results in all the Provider Bridges learning all the customer MAC addresses. This can begin to be a problem as customer networks grow and the numbers of customer networks grow. There are also concerns about MAC address flooding. The second significant limitation is that the VLAN ID field is only 12 bits which provides 4,096 unique addresses. This sounds like a pretty high PN 915-2624-01 Rev D

December 2011

3

CARRIER ETHERNET number, but each E-Line configured uses a dedicated S-VLAN and providers are beginning to reach the address limitation in some networks. To address these limitations Provider Backbone Bridging evolved.

Provider Backbone Bridges Provider Backbone Bridges (PBB) is defined by the IEEE 802.1ah (currently draft 4.2) specification. It was developed to address the scale limitations of PB and provide a migration path to a hierarchical Ethernet infrastructure. PBB encapsulates the client frame (which can be untagged, singled tagged or double tagged) with an additional MAC header, a Network tag (B-Tag) and a Service Instance Tag (I-TAG). (see 0)

Figure 4-Provider Backbone Bridges Ethernet Frame Format

While this may seem like a lot of overhead, most switches are leveraging hardware based forwarding and there is minimal performance impact. By using an additional MAC header the Backbone Destination Address (B-DA) and Backbone Source Address (B-SA) are used within the provider network preventing the core switches from needing to learn the customer MAC addresses. With the addition of the I-Tag, the Service ID (I-SID) provides 24 bits (2^24) for unique backbone service identifiers within a single PBB Network. This is extremely scalable and attractive for Service Providers to migrate to. It also provides a nice migration path from PB since the frames can be directly encapsulated in PBB. PBB is not yet widely implemented but there is growing interest and support being introduced by many Network Equipment Manufactures (NEM). Another standard in development is 802.1Qay Provider Backbone Bridging with Traffic Engineering (PBB-TE). This specification uses PBB as the data-plane and currently requires manually defined forwarding paths (usually statically provisioned by a management system). Then Service OAM (typically IEEE 802.1ag) connectivity check is used over the path end-toPN 915-2624-01 Rev D

December 2011

4

CARRIER ETHERNET end to ensure the path is up. Using Service OAM an outage can be detected in sub50ms and the node can move traffic to a backup path. PBB-TE is also gaining interest from Service Providers for certain service types.

Introduction to Ethernet OAM Ethernet OAM As Carrier Ethernet based services continue to grow Service Providers require an additional feature set to replace fault management capabilities legacy technologies provided. Operations Administration and Maintenance (OAM) benchmarks have been set by technologies like TDM, SONET, Frame-Relay and ATM. OAM benefits Service Providers by providing visibility to lower network layers and is used for troubleshooting and monitoring network services. OAM technologies can provide: •

Fault Detection

•

Fault Verification

•

Fault Isolation

•

Fault Recovery

•

Fault Notification

With these capabilities it can reduce OPEX by reducing truck rolls, troubleshooting time and overall network downtime. These are typically measured by Mean Time To Diagnose (MTTD) and Mean Time To Repair (MTTR) metrics. To address the MEF CE attribute for Service Management several technologies have been included as part of the new UNI Type 2 specifications. These include Link OAM, ELMI (MEF 16) and Service OAM.

PN 915-2624-01 Rev D

December 2011

5

CARRIER ETHERNET

Link OAM Link OAM is defined in the IEEE 802.3ah Clause 57 standard. It is referred to as “Ethernet in the first mile” since it only operates over a single segment and is typically used between the Customer UNI (UNI-C) and Network UNI (UNI-N). This standard provides five key mechanisms: Discovery

The first phase of Link OAM session establishment. It identifies devices in the network along with their OAM capabilities.

Remote Loopback

AN OAM entity can put its remote peer into LB mode. This helps the network administrator during installation and troubleshooting.

Link Monitoring

Provides a mechanism for an OAM entity to convey attributes and status in regard to link performance – particularly useful for slowly deteriorating link (e.g., symbol-error second count).

Remote Failure Indication

Provides a way of detecting and indicating compromised or downed links under a variety of conditions. (Raises a flag at the local end, like SONET/SDH)

Polling of MIB Variables

Read-only ‘in-band’ access to remote MIB variables

It uses a single OAM PDU format with a specific D-MAC, Type and Subtype. It is also a slow protocol so the max PDU rate is ten packets per second.

PN 915-2624-01 Rev D

December 2011

6

CARRIER ETHERNET When testing Link OAM Ixia emulates the protocols as depicted below (see Figure 5.

Figure 5-. Ethernet Link OAM Testing

In addition to the Ethernet segments between the UNI-C and UNI-N Link OAM can be enabled on any segment in the network for additional OAM capabilities. The MEF has defined MEF 21 technical specification as how to test Link OAM.

Service OAM The second flavor of Ethernet OAM is known as Service OAM. A significant difference from Link OAM is that it can traverse layer 2 Ethernet hops running end-to-end over the service. There are two protocols that define Service OAM capabilities: IEEE 802.1ag Ethernet Connectivity and Fault Management (CFM) and ITU-T Y.1731 OAM Functions and Mechanisms for Ethernet Based Networks. The Y.1731 standard provides a superset of features. Both standards have in common the following: Continuity Check

Loopback Linktrace

PN 915-2624-01 Rev D

Using a Continuity Check Message (CCM) over the service, each endpoint transmits a CCM at a configured interval (CCI). This is used as a “heartbeat” to ensure the other endpoints of the connection is up. This is essentially a layer 2 Ethernet ping (echo request) which can be used to ping the far end MAC or points along the way. This is essentially a layer 2 Ethernet traceroute which can be used to determine the path to the far end MAC to isolate an issue.

December 2011

7

CARRIER ETHERNET In a Service OAM configuration there are two primary elements; a Maintenance End Point (MEP) and a Maintenance Intermediate Point (MIP). Service OAM also provides hierarchy so that Service Providers can segment the network into Maintenance Domains and also assign Levels. Levels are used so that different levels of visibility are provided on a service. This is especially useful if there are multiple operators’ networks that are used to build the service (see Figure 6).

Figure 6-

Service OAM Hierarchy

The relationship between MEPs is known as a Maintenance Association (MA). Since Service Provider networks can enable hundreds or thousands of E-Line or E-LAN services the number of MAs maintained can get large quickly. Also, the CCI can be as fast as 3.33ms putting strain on the MPs that needs to maintain the Continuity Check Data Base (CCDB). Ixia can emulate MEPs and MEPs testing the Device Under Tests functionality and scalability when processing Service OAM messages.

Figure 7-Testing Service OAM

Y.1731 adds additional performance measurement capabilities including Delay Measurement, Delay Variation Measurement and Frame Loss. Since these typically require hardware processing only new generation equipment are enabling these features. MEF 25 specification defines the testing required for Service OAM. PN 915-2624-01 Rev D

December 2011

8

CARRIER ETHERNET

Ethernet Local Management Interface (E-LMI) E-LMI is defined in the MEF 16 specification. The E-LMI protocol is used for the configuration and management of Customer Edge (CE) equipment that does not rely on any IP based protocol like SNMP. The Ethernet flavor of this protocol is based on the ITU-T Q.933 and X.36 which defines Frame Relay Local Management Interface (FR-LMI). Enabling E-LMI provides a mechanism for a Service Provider to receive information and status of an Ethernet service and enable them to change the service status and attributes. E-LMI is typically run on the User-Network-Interface (UNI) between the customer site (UNI-C) and the provider site (UNI-N).

Figure 8-E-LMI runs between the UNI-C and UNI-N

The E-LMI protocol provides the following notifications: • • • •

Notify the CE of the addition of an Ethernet Virtual Circuit (EVC) Notify the CE of the deletion of an EVC Notify the CE of the availability state of a configured EVC (Active, Not Active, or Partially Active) Communicate UNI and EVC attributes to the CE

E-LMI messages are encapsulated within Ethernet frames and use the destination MAC address 01-80-C2-00-00-07. The Ethertype is 88-EE. The source address is the MAC of the sending port. Note: The E-LMI message is not carried over a VLAN-tagged frame. The following are the two messages defined for the E-LMI protocol: • •

Status Status Enquiry

E-LMI messages consist of the following parts: •

Protocol Version

PN 915-2624-01 Rev D

December 2011

9

CARRIER ETHERNET • • •

Message Type Report Type Other information elements and sub-information elements

Sub-information elements consist of: • • • • •

UNI Identifier EVC Parameters EVC Identifier EVC Map Entry Bandwidth Profile

EVC Status messages use the following possible states: New, Active, Not Active or Partially Active. New

Active

X

X

Not Active

X

X X X

Table 1. Possible Status Combinations for a Point-to-Point EVC

New X

Active

Not Active

Partially Active

X

X

X

X

X X

X

X Table 2. Possible Status Combinations for a Multipoint-to-Multipoint EVC Information elements carried in the Status message for each Report Type include:

PN 915-2624-01 Rev D

December 2011

10

CARRIER ETHERNET Report Type Information Element Value Information Element

Full Status

E-LMI Check

Single EVC Asynchronous Status

Full Status Continued

Sequence Numbers

X

X

X

Data Instance

X

X

X

UNI Status

X

EVC Status

X

CE-VLAN ID/EVC MAP

X

X

X X

Table 3. Possible Report Type Element for each Information Element

PN 915-2624-01 Rev D

December 2011

11

CARRIER ETHERNET E-LMI uses the following periodic polling and asynchronous updates: • • • • •

Polling procedure invoked by CE N391 based Polling Counter, polling cycles between Full Status exchanges N393 based Status Counter, number of consecutive errors T391 based Polling Timer (PT), UNI-C transmits Status Enquiry T392 based Polling Verification Timer (PVT), timer by which UNI-N Expects to be polled.

Figure 9-E-LMI Periodic Polling and Asynchronous Updates

E-LMI provides communication between the UNI-C and the UNI-N. This enables the Service Provider to manage the Carrier Ethernet service more effectively. E-LMI is added to the MEF UNI Type 2 Implementation Agreement defined in the MEF 20 specification.

PN 915-2624-01 Rev D

December 2011

12

CARRIER ETHERNET

Introduction to Ethernet Service Activation Testing Ethernet Service Activation Measurement (SAM) In 2010, ITU-T tried to address the shortcomings of RFC 2544 for Ethernet Service testing and defined new standards based test methodology which could assess the quality of service, and network performance of an Ethernet-based service. Y.1564 is designed for Ethernet-based services and does not specifically test or characterize performance using upper layer protocols as TCP. It started with Y.156 SAM, and is a standard with Y.1564 in March of 2011. Why is a new test methodology needed? RFC 2544 was created in 1999, test network devices, not services. There are a few disadvantages (most test suites however added additional functionality beyond the documented requirements.) The disadvantages are as follows: • • • • • • •

It is time consuming, since, each test is run sequentially, as designed It is performance based, so it specifies a short duration The traffic requirement is a single stream, which does not address QoS based services The tests find the absolute performance limit of a device, not a service The throughput test uses a binary search which can have multiple iterations, and hence consume more time. The latency methodology specifies a sub-optimal mechanism, and not perpacket measurement Newer attributes such as Frame Delay Variation (frame jitter) is not included

PN 915-2624-01 Rev D

December 2011

13

CARRIER ETHERNET

With these disadvantages, there is room for new methodology which is focused and optimized to test Ethernet-based services. These services include MEF standards like ELINE, E-LAN and E-Tree (as defined in MEF 6.1). The methodology is designed to test end-to-end between the customer endpoints referred to as the UNI-C interfaces.

Figure 10-Ethernet Services are tested UNI-C to UNI-C

Y.1564 is designed to test Ethernet-based service attributes including: • • • •

Connection type Traffic parameters: QoS (including VLAN info.), traffic type (data vs. management), etc. Bandwidth profile (based on G.8011, applicable at the ingress and egress UNI) Performance criteria: Frame Loss, Frame Delay, Frame Delay Variation

PN 915-2624-01 Rev D

December 2011

14

CARRIER ETHERNET MEF 10.1 defines three types of bandwidth profiles including: port-based, port/VLANbased, Port/VLAN/CoS-based. These are covered in Y.1564.

Figure 11-MEF 10.1 types of bandwidth profiles

A Bandwidth Profile defines the following attributes (as defined in G.8011): •

•

• •

Committed Information Rate (CIR) – The maximum information rate the network is committed to transfer while meeting the performance level guaranteed in the Service Level Agreement (SLA). Performance guarantee is only at or below CIR. Committed Burst Size (CBS) - The number of allocated bytes available for bursts of ingress service frames transmitted at temporary rates above the CIR, while meeting the SLA Excess Information Rate (EIR) - The maximum information rate at which a user can exceed its expecting that excess traffic is carried through the network Excess Burst Size (EBS) - The number of allocated EIR conformant bytes available for bursts of ingress service frames sent at temporary rates above the EIR.

PN 915-2624-01 Rev D

December 2011

15

CARRIER ETHERNET There are two main phases of the Y.1564 methodology; a “Configuration” phase and a “Performance “phase: • •

Configuration: To validate that each Ethernet-based service is correctly configured Performance: To validate the quality of the services as delivered to the end-user

Figure 12-Y.1564 Methodology

PN 915-2624-01 Rev D

December 2011

16

CARRIER ETHERNET During the Network Configuration test, each service is tested individually with traffic starting at 25% of CIR, and stepping up to the configured CIR value. Post CIR, it steps to CIR+EIR. Final iteration is at CIR+EIR+ 25% EIR. In a typical test there are six iterations per configured service. After the Configuration test, is the Ethernet Services test runs parallel with CIR with single iteration of the configured services.

Figure 13-Network Configuration Test Iterations per Service

Test results listed below are compared against the expected service level: •

•

•

•

Throughput - throughput results are available for all flows simultaneously. For each flow, the minimum, maximum, average and current throughput is displayed. Frame Transfer Delay (FTD) - FTD results are displayed for all flows simultaneously. For each flow, the minimum, maximum, mean, median and current FTD is displayed. The display of the results also indicates whether the measurement is made end-to-end or round-trip. Frame Delay Variation (FDV) - FDV results are displayed for all flows simultaneously. For each flow, the updated result or current FDV is displayed. The display of the results also indicates whether the measurement is made endto-end or round-trip Frame Loss Ratio (FLR) - FLR results are displayed for all flows simultaneously. For each flow, the count and the ratio are displayed.

PN 915-2624-01 Rev D

December 2011

17

CARRIER ETHERNET Based on the test results the service is within the SLA, and “pass” or exceed the expected SLA for delay, delay variation, or, loss and “fail”.

PN 915-2624-01 Rev D

December 2011

18

PROVIDER BRIDGES AND PROVIDER BACKBONE BRIDGES

Testing Provider Bridges (802.1ad) and Provider Backbone Bridges (802.1ah) Introduction to Provider Bridges (802.1ad) IEEE 802.1ad (Provider Bridges) is an amendment to IEEE 802.1Q that provides separate instances of the MAC services to multiple independent users of a Bridged LAN in a manner that does not require cooperation among the users, and requires a minimum of cooperation between the users and the provider of the MAC service. 802.1ad builds on the VLAN capability provided by 802.1Q and adds another level of VLAN hierarchy, the S-TAG, to the Ethernet Frame, that is to be used by the service providers to separate traffic coming from different customers using their own private VLANs. Using 801.ad, service providers can let customers run their own VLANs using the VLAN provided by the service provider. This way the service provider can simply configure one VLAN for the customer and customer can then treat that VLAN as if it was a trunk.

Figure 14-Frame Format of Provider Bridges (802.1ad)

Relevant Standards IEEE 802.1ad Provider Backbone Bridges

PN 915-2624-01 Rev D

December 2011

19

TEST CASE: PROVIDER BRIDGES 802.1ad E-LINE SERVICES

Test Case: Provider Bridges 802.1ad E-Line Services Overview The Provider bridges perform the forwarding of traffic on the basis of the correct B-Tag and I-SID values. In this test we will be using two Ixia ports acting as backbone bridges to send PBB traffic to the DUT. The egress traffic from the DUT is then tracked to ensure that the forwarding decisions are taken correctly.

Objective The objective of this test is to verify that the DUT forwards customer frames that are configured with the correct Service TAG. In addition, the DUT should not forward traffic on to ports that are not configured with the correct C-TAG.

Setup A pair of Ixia ports emulating as Backbone Edge Bridges are connected to the DUT. The DUT is configured for port-based service over S-VLAN 100. IxNetwork Port 1 and IxNetwork Port 2 are configured for traffic with S-VLAN 100 and C-VID 2-4094. IxNetwork Port 3 is configured with S-VLAN 200 and C-VID 2-4094. In this test setup, the Provider Bridge DUT will be receiving Q-in-Q traffic from Ixiaemulated Backbone Edge Bridge (BEB) on its ingress port and forwarding the Q-in-Q traffic out to the correct egress port toward another Ixia-emulated BEB.

Figure 15-802.1ad Backbone Bridge Test Setup

PN 915-2624-01 Rev D

December 2011

21

TEST CASE: PROVIDER BRIDGES 802.1ad E-LINE SERVICES

Step by Step Instructions 1. Add ports to the test setup.

Figure 16-Port Selection

2. In the Test Configuration window, click on Traffic. This will take you to the Traffic configuration window in the main pane in the center of GUI.

Figure 17-Traffic Configuration

3. Click the Advanced Wizard icon to start the traffic configuration.

Figure 18-Advanced Traffic Wizard Selection

PN 915-2624-01 Rev D

December 2011

22

TEST CASE: PROVIDER BRIDGES 802.1ad E-LINE SERVICES

4. First, name the Traffic Item. In the example, the Traffic Item is named PB for Provider Bridges. a.

In the Type of Traffic, select Raw.

b.

Under Source/Destination Endpoints, select the Source and Destination ports. Then press Next.

Figure 19-Traffic Type and Endpoint Selection

5. In the Packet/QoS step, there is a packet editor view. Highlight the Ethernet II, then right-click select Append Protocol.

Figure 20-Append Protocol

6. In the Select Protocol pop-up window, select VLAN and press OK.

Figure 21-Selecting Protocol to Append

PN 915-2624-01 Rev D

December 2011

23

TEST CASE: PROVIDER BRIDGES 802.1ad E-LINE SERVICES

7. Select the VLAN header added in step 6 above, and select Append Protocol. Add another VLAN protocol header.

Figure 22-Appending VLAN Header

8. Click the icon for expanding the frame protocols tree node.

Figure 23-Expanding Protocols

9. Then, in the protocol tree, configure 4093 MAC Addresses for Destination and Source MAC Addresses.

Figure 24-MAC Address Configuration

•

Click the clock icon to enable tracking on that particular field.

The Tracking option will get statistics for the field selected. You may also review the fields on which tracking was enabled in the Track Flows by step, described below (step 16, page 27).

PN 915-2624-01 Rev D

December 2011

24

TEST CASE: PROVIDER BRIDGES 802.1ad E-LINE SERVICES

10. Highlight the Ethernet-Type and select Edit.

Figure 25-Editing Ethernet-Type Value

PN 915-2624-01 Rev D

December 2011

25

TEST CASE: PROVIDER BRIDGES 802.1ad E-LINE SERVICES 11. Enter a single value of 88a8 to change the Ether-type from 0x8100 to 0x88A8.

Figure 26-Entering Ethernet-Type Value

12. Now move to the first VLAN header and configure its VLAN-ID (S-TAG) to have the value 100.

Figure 27-Configuring Outer VLAN-ID Value

13. Moving onto the next VLAN header, configure an incrementing range of VLANIDs that will configure the C-TAG values from 2 to 4094 for a total of 4093 C-TAGs.

Figure 28-Configuring Inner VLAN-ID Value

PN 915-2624-01 Rev D

December 2011

26

TEST CASE: PROVIDER BRIDGES 802.1ad E-LINE SERVICES The above steps will result in the frames being generated as shown in Figure 29.

Figure 29-Resultant Frame Created

14. Click the

icon in the left pane.

15. Under Flow Group Transmission Mode, select Fixed Packet Count and enter 5000 in the Stop After packets field.

Figure 30-Setting Fixed Number of Packets to be Transmitted

16. Click Flow Tracking in the left pane. Under Track Flows by, you will see tracking already set on the fields for which tracking was enabled earlier (step 9 page 24). Note: You may check the Enable Egress Tracking box to enable Egress tracking on C-TAG to verify that the information contained has not been corrupted by the DUT.

PN 915-2624-01 Rev D

December 2011

27

TEST CASE: PROVIDER BRIDGES 802.1ad E-LINE SERVICES

17. Click

at the bottom on the Advanced Traffic Wizard window.

18. Apply traffic by clicking the traffic apply button 19. Switch view to the Statistics page by clicking display the Traffic Statistics window 20. Click the start traffic button

in the left pane. This will

.

Pressing this button should send 5000 packets that were configured in step 15 above. We will confirm this by looking at the statistics. 21. Click Traffic Item Statistics. This will bring the statistics for the Traffic Item PB we configured through the Advanced Traffic Wizard.

Figure 31-Selecting Traffic Item Statistics

22. Now start traffic by clicking the start traffic icon Notice that 5000 frames were transmitted and all of them were received with no packet loss.

Figure 32-Traffic Item statistics

PN 915-2624-01 Rev D

December 2011

28

TEST CASE: PROVIDER BRIDGES 802.1ad E-LINE SERVICES 23. To confirm that the traffic was sent from the correct MAC Address source, rightclick the Traffic Item PB and select Drill Down per Ethernet II: Source MAC Address.

Figure 33-Drilling down to View Statistics by Source MAC addresses

24. This will present a drill-down list of all Source MAC Addresses. Each row contains the traffic statistics associated with each Source MAC address. Notice that there are a total of 4093 rows. This corresponds to the number of Source MAC Addresses configured in Step 9, above.

Figure 34-Per-Session Statistics Arranged by Source MAC Addresses

Results Analysis DUT 802.1ad bridging performance can be judged using multiple criteria. Checking that the DUT forwarded the statistics to the correct port with zero loss indicates that only the pertinent traffic from the Q-in-Q cloud was forwarded to the correct port. On the other

PN 915-2624-01 Rev D

December 2011

29

TEST CASE: PROVIDER BRIDGES 802.1ad E-LINE SERVICES hand, the port with a different S-TAG value configured received no frames, indicating the correct behavior by the DUT.

Test Variables The following variables can be used to verify the behavior of a DUT bridge: 1. Source and Destination MAC Addresses Increasing the number of MAC Addresses results in DUT having to store more MAC Addresses in its MAC Address table. 2. S-TAG 3. C-TAG The larger the number of S-TAG and C-TAGs configured, the more state DUT has to maintain to forward the frames to the correct destination 4. Ports with different associated S-TAG and C-TAG values The larger the number of ports, the more state needs to be maintained at the DUT to associate ports with TAG values.

Troubleshooting and diagnostics Problem

Description

100 % frame loss on Receive port

Confirm that the Receive port is configured with the correct S-TAG/C-TAG. If true, then check that the transmit port’s S-TAG and C-TAG values match the ones on the expected receive port. Or the DUT has not done the MAC Address learning on all ports, resulting in traffic loss. Need to ensure that if Spanning Tree is enabled on the port, the port will be in blocking state.

0% frame loss on incorrect Receive port (Port 3 in this setup)

Confirm configured S-TAG/C-TAG values. Also check that the transmit port’s S-TAG and C-TAG values match the ones on the expected receive port and not the incorrect receive port

Conclusions Ethernet 802.1ad E-Line provides for point-to-point service on provider networks. IxNetwork can be used to verify the performance and scalability of Provider Bridge DUT.

PN 915-2624-01 Rev D

December 2011

30

PROVIDER BACKBONE BRIDGES

Introduction to Provider Backbone Bridges (802.1ah) IEEE 802.1ah (Provider Backbone Bridges, PBB) provides for routing of customer networks over service provider networks while preserving each customer’s unique VLAN definitions. The main thrust of 802.1ah is the complete separation of provider and customer domains. This requires a new Ethernet header that has the following basic components. Backbone: Backbone Destination Address (B-DA) Backbone Source Address (B-SA) Service: Service Instance VLAN Identifier (I-SID) Backbone VLAN ID (B-VID) Original Ethernet frame: MAC source address MAC destination address Customer VLAN ID (C-TAG) Payload

Figure 35-Frame Format of Provider Backbone Bridges (802.1ah)

PN 915-2624-01 Rev D

December 2011

31

PROVIDER BACKBONE BRIDGES The bridges in PBB learn on the basis of B-SA and the ingress port values and are unaware of the customer MAC address. This allows for complete separation between the customer and provider domains. To distinguish between services in the PBB domain, I-SID values are used. In networks each service (customer VLAN) is mapped to an I-SID, this way the service provider can burn a B-TAG for each customer and use I-SID to separate different services for each customer. This allows for much higher scalability numbers. Relevant Standards IEEE 802.1ah Provider Backbone Bridges

PN 915-2624-01 Rev D

December 2011

32

TEST CASE: PROVIDER BRIDGES 802.1ah E-LAN SERVICES

Test Case: Provider Bridges 802.1ah E-LAN Services Overview The PBB Backbone bridges perform the forwarding of traffic on the basis of the correct B-Tag and I-SID values. In this test we will be using three Ixia ports acting as backbone bridges. One Ixia emulated backbone bridge port will be transmitting MAC-in-MAC traffic to the DUT and the other two Ixia emulated backbone bridge ports will be receiving traffic from the DUT. The egress traffic from the DUT is then tracked to ensure that the forwarding decisions are taken correctly.

Objective The objective of this test is to verify that the DUT forwards backbone frames only to those bridges that are configured with correct I-SID and B-TAG values. The DUT should not forward traffic on to ports that are not configured with the correct values.

PN 915-2624-01 Rev D

December 2011

33

TEST CASE: PROVIDER BRIDGES 802.1ah E-LAN SERVICES

Setup A pair of Ixia ports emulating Backbone Edge Bridges are connected to the DUT. The DUT is configured for I-SID values 1->10 and B-TAG 100-> 110 on DUT port 2. While DUT port 3 is configured for a different set of I-SID and B-TAG values. Ixia port 1 is going to transmit MAC-in-MAC backbone traffic to the DUT (Provider Backbone Bridge) and Ixia ports 2 and 3 are set to receive forwarded traffic from the DUT. Since the DUT is forwarding traffic, both the Ixia ports are expecting to receive the traffic from Ixia port1.

Figure 36 - 802.1ah Backbone Bridge Test Setup

PN 915-2624-01 Rev D

December 2011

34

TEST CASE: PROVIDER BRIDGES 802.1ah E-LAN SERVICES

Step by Step Instructions 1. Add ports to the test setup.

Figure 37-Selecting Ports

2. In the Test Configuration window, click Traffic. This will take you to the Traffic configuration window in the main pane in the center of the GUI.

Figure 38-Configuring Traffic Options

3. Click the Advanced Wizard icon to start the traffic configuration.

Figure 39-Selecting Advanced Traffic Wizard

PN 915-2624-01 Rev D

December 2011

35

TEST CASE: PROVIDER BRIDGES 802.1ah E-LAN SERVICES 4. First, name the Traffic Item. In the example, the Traffic Item is named PBB for Provider Backbone Bridges. •

In the Type of Traffic, select Raw.

•

Under Source/Destination Endpoints, select the Source and Destination ports. Press Next.

Figure 40-Selecting Traffic Type and Endpoints

5. In the Packet/QoS step, there is a packet editor view. Highlight Ethernet II, then right-click select Replace Protocol.

Figure 41-Replacing Ethernet with MAC-in-MAC

6. In the Select Protocol pop-up window, select MAC in MAC and press OK.

Figure 42-Selecting MAC-in-MAC

PN 915-2624-01 Rev D

December 2011

36

TEST CASE: PROVIDER BRIDGES 802.1ah E-LAN SERVICES The packet format will change as shown in Figure 43.

Figure 43-MAC-in-MAC Frame

7. Click the icon for expanding the protocols tree node.

Figure 44-Expanding Frame Tree Protocols

8. In the protocol tree, configure 4093 MAC Addresses for Destination and Source MAC Addresses.

Figure 45-Configuring Backbone Source and Destination MAC Addresses

9. Configure 10 B-TAG values in the B-VLAN ID field and enable tracking.

Figure 46-Configuring B-TAG Values and Enabling Tracking

•

Click the clock icon to enable tracking on that particular field.

PN 915-2624-01 Rev D

December 2011

37

TEST CASE: PROVIDER BRIDGES 802.1ah E-LAN SERVICES •

The Tracking option provides the ability to get statistics for the field selected.

10. Configure I-SID value (1 through 10) in the I-Tag branch.

Figure 47-Configuring I-SID Values and Enabling Tracking

PN 915-2624-01 Rev D

December 2011

38

TEST CASE: PROVIDER BRIDGES 802.1ah E-LAN SERVICES

11. Enable Tracking by clicking the clock icon next to the I-SID field. •

The above steps will result in the frame shown in Figure 48.

Figure 48-Final MAC-in-MAC Frame

12. Click the

in the left pane.

13. Under Flow Group Transmission Mode, select Fixed Packet Count and enter 6000 in the Stop After packets field.

Figure 49-Configuring Fixed Number of Frames to Transmit

PN 915-2624-01 Rev D

December 2011

39

TEST CASE: PROVIDER BRIDGES 802.1ah E-LAN SERVICES 14. Click on Flow Tracking in the left pane. Under Track Flows by, you will see tracking already set on the fields for which tracking was enabled in the previous steps. 15. Click the icon in the left pane and then click the View Flow Groups/Packets button on the top right. This will result in all the 4093 generated packets to be listed:

Figure 50-Previewing the generated frames

16. Click on

at the bottom on Advanced Traffic Wizard window.

This will generate the Traffic Item. 17. Apply Traffic Item to the ports by clicking the traffic apply button 18. Switch view to the Statistics page by clicking the hand pane. This will display the Traffic Statistics window. 19. Click the start traffic button

button in the left

.

Pressing this button should send 6000 packets that we configured in step 13, above. We will confirm this by looking at the statistics.

PN 915-2624-01 Rev D

December 2011

40

TEST CASE: PROVIDER BRIDGES 802.1ah E-LAN SERVICES 20. Click on Traffic Item Statistics. This will display the statistics for the Traffic Item PBB we configured through Advanced Traffic Wizard.

Figure 51-Selecting Traffic Item Statistics

21. Now start traffic. Notice that 6000 frames were transmitted and half of them were received with 50% packet loss.

Figure 52-Traffic Item Statistics

22. Click Port Statistics in the left pane to bring up traffic statistics per port.

Figure 53-Per-port traffic statistics

Notice that one port has received 6000 packets, whereas the other has received none.

PN 915-2624-01 Rev D

December 2011

41

TEST CASE: PROVIDER BRIDGES 802.1ah E-LAN SERVICES 23. To confirm that the traffic was sent with the correct B-TAG source, right-click the Traffic Item and select Drill Down per MAC in MAC: B-VLAN ID.

Figure 54-Drilling down to MAC-in-MAC B-TAG values

24. This will display the User Defined Statistics view, with statistics for all the B-TAGs traffic

Figure 55-Traffic Statistics Arranged by MAC-in-MAC B-TAG Values

PN 915-2624-01 Rev D

December 2011

42

TEST CASE: PROVIDER BRIDGES 802.1ah E-LAN SERVICES 25. To observe the traffic statistics by I-SID, right-click the Traffic Item and select Drill Down per MAC in MAC: I-SID.

Figure 56-Traffic Statistics Arranged by MAC-in-MAC I-SID Values

Results Analysis DUT 802.1ah bridging performance can be judged using multiple criteria. Confirming that the DUT forwarded the statistics to the correct port with zero loss indicates that only the pertinent traffic from the MAC-in-MAC cloud was forwarded to the correct port. On the other hand, the port with a different S-TAG value received no frames, indicating the correct behavior by DUT. Since we had configured both the ports to receive traffic, we are showing a 50% loss as the received frames total exactly 50% of the expected received frames.

Test Variables The following variables can be used to verify the behavior of DUT bridge: 1. Source and Destination MAC Addresses Increasing the number of MAC Addresses results in the DUT having to store more MAC Addresses in its MAC Address table. 2. B-TAG 3. I-SID The larger the number of B-TAG and I-SIDs configured, the more states the DUT has to maintain to forward the frames to the correct destination. 4. Ports with different associated S-TAG and C-TAG values

PN 915-2624-01 Rev D

December 2011

43

TEST CASE: PROVIDER BRIDGES 802.1ah E-LAN SERVICES The larger the number of ports, the more states that need to be maintained at the DUT to associate ports with TAG values.

Troubleshooting and diagnostics Problem

Description

100 % frame loss on Receive port

Confirm that the Receive port is configured with the correct S-TAG/C-TAG. If that is true, then check that the transmit port’s STAG and C-TAG values match the ones on the expected receive port. Or the DUT has not done the MAC Address learning on all ports, resulting in traffic loss. Need to ensure that if Spanning Tree is enabled on the port, the port will be in blocking state.

0% frame loss on incorrect Receive port (Port 3 in this setup)

Confirm configured S-TAG/C-TAG values. Also check that the transmit port’s S-TAG and C-TAG values match the ones on the expected receive port and not the incorrect receive port

Conclusions Ethernet 802.1ad E-Line provides for point-to-point service on provider networks. IxNetwork can be used to verify the performance and scalability of Provider Bridge DUT

PN 915-2624-01 Rev D

December 2011

44

ETHERNET/LINK OAM FUNCTIONAL VERIFICATION

Ethernet/Link OAM (802.3ah) Functional Verification Introduction to Ethernet/Link OAM Ethernet/Link OAM is used between two Data Termination Equipment (DTE) devices to monitor the operation and health condition of a physical link, and to improve fault isolation when trouble arises. Under the IEEE 802.3ah architecture, OAMPDUs are an integral component. These packet data units (PDUs) are normal Ethernet frames that use a specific multicast destination address and EtherType.

Figure 57-OAMPDU Format and Flag/Code Definition

The discovery is the first phase of the IEEE 802.3ah OAM protocol and it consists of a sequence of OAMPDU exchanges between local and remote DTEs to discover each other’s capabilities, such as mode, loopback support, maximum PDU size, and a few other state and configuration parameters. When both ends of the link are satisfied with the settings uncovered during discovery, link OAM is enabled on the link.

PN 915-2624-01 Rev D

December 2011

45

ETHERNET/LINK OAM FUNCTIONAL VERIFICATION Remote failure is indicated by three flags in the OAMPDU for easy diagnostics and isolation. Link Fault flag is raised when a DTE stops receiving a transmit signal from its peer. Dying Gasp flag is raised when a DTE is about to reset, reboot, or otherwise go to an operationally down state. Critical Event flag indicates a severe error condition that does not result in a complete re-set or re-boot by the peer entity. Ethernet/Link OAM also defines a set of standard event conditions that Ethernet links should monitor in normal operation and, if detected, should notify a peer entity. These conditions reflect a degraded, but not yet inoperable, Ethernet connection. These conditions include threshold-crossing alarms on the frequency of symbol errors and frame errors. Ethernet/Link OAM further provides the capability to put a remote entity into loopback mode using a loopback-control OAMPDU. When an OAM entity is in loopback mode, every frame received is transmitted back on that same port except for OAMPDUs and pause frames. Last but not least, the IEEE 802.3ah Ethernet OAM specifications define a generic mechanism for one OAM entity to query another for the value of any management information base (MIB) variable, which is known as MIB variable retrieval. MIB variables include all performance and error statistics maintained on an Ethernet link. This capability provides a generic monitoring capability for one DTE to monitor any parameter on another DTE for performance or error detection. Relevant Standards IEEE 802.3ah Clause 57 Operation, Administration, and Maintenance (OAM)

PN 915-2624-01 Rev D

December 2011

46

TEST CASE: ETHERNET/LINK OAM DISCOVERY

Test Case: Ethernet/Link OAM Discovery Functional Verification Overview OAM discovery is the first phase in OAM protocol operation and is delivered over Information TLV PDU (code=0x00). It contains both the local and remote information for the physical link. A loss of link or a non-reception of OAMPDU for 5 seconds will cause restart of the OAM discovery process.

Figure 58-Information TLV used for Discovery

PN 915-2624-01 Rev D

December 2011

47

TEST CASE: ETHERNET/LINK OAM DISCOVERY Both local and remote information TLVs are further divided to contain many state and configuration parameters, as detailed below. The OAM discovery process is to ensure both ends of the link agree on the capabilities and, when they do, OAM is enabled.

Figure 59-Information TLV Expanded

Vars – Variable Retrieval support Events – Link Events support LB – Loopback support Unidir – Unidirectional support Mode – Active or Passive mode Max OAM PDU Size – Max PDU size

Objective There are many variants of the same test as each capability bit can deserve a separate test case. For complete and accurate protocol conformance verification, Ixia IxANVL Link OAM Test Suite is recommended. For the tests presented as examples here, the objective is to illustrate how to use IxNetwork to perform sample tests that include 1) verification of DUT mode (active or passive), and 2) verification of DUT Vars, Events, LB and Unidirectional capability support.

PN 915-2624-01 Rev D

December 2011

48

TEST CASE: ETHERNET/LINK OAM DISCOVERY

Setup There is only one Ethernet/Link OAM session per physical port, therefore a single test port is sufficient to perform all the needed verification, as illustrated in the diagram below. More test ports can be used to scale up the test.

Figure 60-Ethernet/Link OAM Test Setup

Step by Step Instructions, OAM Discovery 1. Launch the Link-OAM Wizard and select the port or ports to be configured.

PN 915-2624-01 Rev D

December 2011

49

TEST CASE: ETHERNET/LINK OAM DISCOVERY

Figure 61-Launch Link-OAM Protocol Wizard

2. On Screen #2 of 5, use the default MAC address or modify as appropriate. Click to set the Operation Mode to be Active or Passive. When a port is configured in Passive mode, it is not supposed to initiate Discovery process nor should it send Variable Request PDU or Loopback Control PDU. If you’re testing a DUT that operates in Passive mode, then you must configure Ixia to be in Active mode. If you’re testing a DUT that operates in Active mode, you can configure Ixia in either Active or Passive mode.

PN 915-2624-01 Rev D

December 2011

50

TEST CASE: ETHERNET/LINK OAM DISCOVERY

3. Enable applicable capability bits (all are selected in this example) and remote failure indication flags (none are selected). Keep in mind that all flags can be toggled on or off in the GUI after wizard configuration. Organization Specific TLV can be configured in a separate pop-up window.

Figure 62-Link-OAM Wizard Screen #2 of 5

PN 915-2624-01 Rev D

December 2011

51

TEST CASE: ETHERNET/LINK OAM DISCOVERY

4. On Screen #3 of 5, enter events notification details as desired. This will be used by Ixia emulated OAM entity to report to DUT about its error conditions. The emulation software is fairly open in terms of error conditions that can be simulated.

Figure 63-Link-OAM Wizard Screen #3 of 5

PN 915-2624-01 Rev D

December 2011

52

TEST CASE: ETHERNET/LINK OAM DISCOVERY 5. On screen #4 of 5, input the number of MIB variables that will be used to respond to the DUT when MIB variable request is received by the Ixia emulator. For a large number of entries, it is common practice to click the column header and then perform a grid level operation such as increment or decrement.

Figure 64-Link-OAM wizard screen #4 of 5

PN 915-2624-01 Rev D

December 2011

53

TEST CASE: ETHERNET/LINK OAM DISCOVERY 6. On the last screen of the Link OAM wizard, assign a meaningful name and then select either option 2 or 3 to save the configuration to the physical port.

Figure 65-Link-OAM wizard screen #5 of 5

Once the configuration is done via the wizard, you can go the GUI to make protocolspecific changes and to observe DUT behavior. You can achieve many functional verifications using this method. Below are a few examples to show you how to achieve specific test objectives.

PN 915-2624-01 Rev D

December 2011

54

TEST CASE: ETHERNET/LINK OAM DISCOVERY 7. To change Ixia emulated OAM mode from Active to Passive or vice versa, go to Information OAMPDU tab and click the Operation Mode to select Active or Passive. Then either click Start to start the emulation or click Restart Discovery if the emulation has started already.

Figure 66-Change of Operation Mode

If the DUT is configured as Active mode, you will see discovery information from Ixia as shown in Figure 67.

Figure 67-Discovery Info from DUT

PN 915-2624-01 Rev D

December 2011

55

TEST CASE: ETHERNET/LINK OAM DISCOVERY If both ixia and the DUT are configured as Passive mode, you will not be able to see any learned info, as shown in Figure 68.

Figure 68-No Discovery Info When Both Are in Passive

8. To send new capability options from Ixia to the DUT and/or to send remote failure indication, simply toggle the applicable bits under Information OAMPDU and click Send Update Parameters.

Figure 69-Sending of New Capability and/or Remote Failure Flags

PN 915-2624-01 Rev D

December 2011

56

TEST CASE: ETHERNET/LINK OAM DISCOVERY 9. To verify new capability and remote failure indication from the DUT and ensure it reflects what was advertised by Ixia.

Figure 70-Verification of New Options and Flags

PN 915-2624-01 Rev D

December 2011

57

TEST CASE: ETHERNET/LINK OAM DISCOVERY 10. To view capability and remote failure indication flags advertised by the DUT, simply go to the Learned Info and click Refresh. It also displays all other values in the OAMPDU. The expected result is that Remote Stable = Yes and Local Discovery State = Send_Any. If either the remote or local state is different, it is a good indication that there are mismatches in advertised capabilities.

Figure 71-View of DUT Capability Options and Remote Failure Flags

In addition to the learned info for a specific session, the statistics page also provides a global view of all events in a single page across all test ports involved. The DUT also provides similar CLI to show all OAM statistics on a single test port.

Figure 72-Ixia OAM Aggregated Statistics

PN 915-2624-01 Rev D

December 2011

58

TEST CASE: ETHERNET/LINK OAM DISCOVERY

Figure 73-DUT OAM Statistics

PN 915-2624-01 Rev D

December 2011

59

TEST CASE: ETHERNET/LINK OAM DISCOVERY

Test Variables Any of the following variables may be used to verify DUT Link OAM discovery functions: Number of test ports – if there is a need to verify OAM capability across multiple DUT ports Operation Mode Remote Failure Indication flags Capability flags MTU Size OUI values

Result Analysis When sending new capability options or new remote failure indication flags, you can go to the DUT and verify if it is being learned by the DUT. Ixia has exposed all options in the GUI as radio buttons. Simply click the application options, then click Send Updated Parameters.

Figure 74-Sending of New Capability Options and Remote Failure Indication Flags

PN 915-2624-01 Rev D

December 2011

60

TEST CASE: ETHERNET/LINK OAM DISCOVERY

Figure 75-DUT Display of New Capability and Remote Failure Flags

When verifying the DUT’s new capability or remote failure indication flags, go to Learned Info under the protocol tree pane. The Discovered Info tab will display every single protocol option learned from the DUT. It is very easy to verify that they are consistent with the DUT’s configuration and, if not, where the differences are.

Figure 76-Ixia Display of Learned Info from DUT

PN 915-2624-01 Rev D

December 2011

61

TEST CASE: ETHERNET/LINK OAM DISCOVERY

Troubleshooting and diagnostics Problem

Description

Cannot display learned info from DUT

Check to make sure either the DUT or Ixia emulator is configured in Active mode. If both are configured in passive mode, none of them will start discovery process hence no learned info will be displayed.

DUT does not reflect new capability options or new failure indications

When new options or flags are toggled, it’s required to click the Send Updated Parameters button in order to force the on –thefly change.

Conclusions Ethernet/Link OAM discovery is the first phase of OAM protocol operation. Ixia OAM emulator provides the flexibility and ease of use to verify all protocol options and flags.

DUT Config Excerpt Interface FastEthernet1/0/1 switchport mode access ethernet oam mode passive ethernet oam remote-loopback supported no etherent oam link-monitor on ethernet oam

PN 915-2624-01 Rev D

December 2011

62

TEST CASE: ETHERNET/LINK OAM EVENT NOTIFICATION

Test Case: Ethernet/Link OAM Event Notification Overview Ethernet/Link OAM Event Notification is meant to notify the remote entity about the local link conditions in terms of errors. These conditions include threshold-crossing alarms on the four categories of errors listed below.

Figure 77-Link OAM Event Notification PDU Format

Errored Symbol Period Event - A window, measured in number of symbols, where the number of errored symbols exceeded a threshold. Errored Frame Event - A window, measured in 100ms intervals, where the number of errored frames exceeded a threshold. Errored Frame Period Event - A window, measured in received frames, where the number of errored frames exceeded a threshold. Errored Frame Seconds Summary - A window, in 100ms intervals, where the number of errored frame seconds exceeded a threshold.

PN 915-2624-01 Rev D

December 2011

63

TEST CASE: ETHERNET/LINK OAM EVENT NOTIFICATION

Objective The objective of this test is to illustrate how to use IxNetwork either to inject applicable error events to a DUT or to observe error events reported by a DUT when link monitoring is enabled.

Setup A single test port is sufficient to complete the functional verification of event notification, as illustrated below. More ports can be used if more OAM sessions are required.

Figure 78-Ethernet/Link OAM Event Notification Setup

Step by Step instructions, OAM Event Notification 1. Steps 1 to 5 in the Ethernet/Link OAM Discovery test (page 49) can be re-used to set up OAM emulation. They are not repeated here for this test.

PN 915-2624-01 Rev D

December 2011

64

TEST CASE: ETHERNET/LINK OAM EVENT NOTIFICATION 2. To send event notification TLVs to the DUT, first select the test port on the protocol tree. Then go to Event TLVs tab. Enable one Error Event at a time or all at once. When ready to send, click Start/Send button. By default the error event is sent as a single shot. You can configure Ixia to send periodically. You can verify if the DUT has successfully received and interpreted the TLV by type corresponding CLI. The diagram below shows DUT CLI output in conjunction with Ixia setup for Errored Symbol Period Event.

Figure 79- Injection of Errored Symbol Period and DUT Output

PN 915-2624-01 Rev D

December 2011

65

TEST CASE: ETHERNET/LINK OAM EVENT NOTIFICATION 3. Similarly, enable the Ixia side to send the Errored Frame Event TLV with desired parameter and verify from the DUT whether or not the DUT has received and interpreted the TLV that matches Ixia’s setup. The diagram below shows Ixia’s setup and the corresponding output from the DUT.

Figure 80-Injection of Errored Frame and DUT Output

PN 915-2624-01 Rev D

December 2011

66

TEST CASE: ETHERNET/LINK OAM EVENT NOTIFICATION 4. In a very similar way, you can enable the other two error events, Errored Frame Period and Errored Frame Seconds, one at a time. Or you can enable all error events together and verify the DUT’s CLI output. Below is an example of DUT CLI output when all four error events are enabled.

Figure 81-DUT Output to Multiple Event Notification

PN 915-2624-01 Rev D

December 2011

67

TEST CASE: ETHERNET/LINK OAM EVENT NOTIFICATION 5. To verify the DUT’s capability of event notification, select Learned Info from the protocol tree. Then select the Event Notification tab. Click Refresh to get the latest view what has been learned from the DUT.

Figure 82-Verifying DUT Event Notification Capability

Test Variables Any of the following variables may be used to verify DUT Link OAM Event Notification functions: •

Number of test ports – if there is a need to verify OAM Event Notification across multiple DUT ports

•

Operation Mode – Active or Passive

•

Event Notification in conjunction with Remote Failure Indication flags

•

Event Notification in conjunction with Capability flags

•

Organization specific OAMPDU data

PN 915-2624-01 Rev D

December 2011

68

TEST CASE: ETHERNET/LINK OAM EVENT NOTIFICATION

Results Analysis By use of Learned Info on Ixia and CLI output on DUT, it is very easy to verify if the DUT has received and interpreted a specific error event correctly, based on standard. Ixia Link-OAM emulation also gives global statistics that contain every single Link OAM operation statistic in a single page.

Figure 83-Control plane statistics

PN 915-2624-01 Rev D

December 2011

69

TEST CASE: ETHERNET/LINK OAM EVENT NOTIFICATION

Troubleshooting and diagnostics Problem

Description

Cannot display learned info from DUT

Check to make sure either the DUT or Ixia emulator is configured in Active mode. If both are configured in passive mode, none of them will start discovery process, so no learned info will be displayed.

DUT does not reflect new event notification

When new options or flags are toggled, it is required to click the Send Updated Parameters button to force the on–the-fly change before clicking on Start/Send Link Event PDU

Ixia is not sending Event Notification

During discovery phase, if Ixia concludes that local is not in stable state (can be verified via Learned Info->Discovered Info>Local Information->Local Stable), it will refuse to send any Event Notification to DUT. To fix this, you can override the local stable state as shown here:

Conclusions Ethernet/Link OAM Event Notification allows communication to the peer regarding current link status in terms of error conditions. Ixia Link-OAM emulation provides a powerful yet flexible means to either inject applicable error events to the DUT or to verify error conditions from the DUT.

DUT Config Excerpt Interface FastEthernet1/0/1 switchport mode access ethernet oam mode passive ethernet oam remote-loopback supported ethernet oam

PN 915-2624-01 Rev D

December 2011

70

TEST CASE: ETHERNET/LINK OAM REMOTE LOOPBACK

Test Case: Ethernet/Link OAM Remote Loopback Overview Loopback is an effective trouble shooting and isolation method that is commonly used by traditional technologies such as SONET/SDH, T1/E1 and so many others. In order for Ethernet to replace the old technologies, it must support loopback. Ethernet/Link OAM defines procedures to put a remote entity into loopback mode using a loopbackcontrol OAMPDU. When an OAM entity is in loopback mode, every frame received is transmitted back on that same port except for OAMPDUs and pause frames. When an OAM entity is configured in Passive mode, it can only respond to, but not initiate, a loopback request. In order to both initiate and respond to a loopback request, it must be configured in Active mode.

Figure 84-Ethernet/Link OAM Loopback PDU Format

PN 915-2624-01 Rev D

December 2011

71

TEST CASE: ETHERNET/LINK OAM REMOTE LOOPBACK

Objective The test objective is to discover whether or not the DUT can respond to and/or initiate a loopback request. Data plane traffic is used to verify the hardware status.

Setup One or more Ixia test ports can be used to verify DUT’s OAM loopback capability.

Figure 85-Link OAM Remote Loopback Test Setup

Step by Step Instructions 1. Repeat steps 1 thru 5 in the Ethernet/Link OAM Discovery test (page 49) if needed for a quick emulation setup using the Link-OAM protocol wizard.

PN 915-2624-01 Rev D

December 2011

72

TEST CASE: ETHERNET/LINK OAM REMOTE LOOPBACK 2. Configure Ixia as Active mode.

Figure 86-Configure Ixia Link-OAM in Active Operation Mode

3. Verify the DUT is also in Active mode and, more importantly, the DUT indeed supports Remote Loopback.

Figure 87-Verify DUT in Active Mode and Support of Remote Loopback

PN 915-2624-01 Rev D

December 2011

73

TEST CASE: ETHERNET/LINK OAM REMOTE LOOPBACK 4. To send a loopback request, first select the Learned Info. Then choose Enable Loopback and click Send Loopback. To confirm DUT loopback status, click Refresh and verify Remote Mux Action and Remote Parser Action. Also confirm loopback status from the DUT — both before and after the request.

Figure 88-Sequence to Send a Loopback Request

Figure 89-DUT Status Before Loopback Request

PN 915-2624-01 Rev D

December 2011

74

TEST CASE: ETHERNET/LINK OAM REMOTE LOOPBACK

Figure 90-DUT Status After Loopback Request

PN 915-2624-01 Rev D

December 2011

75

TEST CASE: ETHERNET/LINK OAM REMOTE LOOPBACK 5. Ultimately, you will need to verify the loopback by use of data plane traffic. The simplest way to do this is to click Quick Flow Groups and add 1 flow group to the port in use. A quick flow group will be generated.

Figure 91-Use Quick Flow Group to Create a Flow Group

PN 915-2624-01 Rev D

December 2011

76

TEST CASE: ETHERNET/LINK OAM REMOTE LOOPBACK 6. You can quickly modify the content of the frame by clicking the Encapsulation Editor and modifying the Src/Dest MAC address as appropriate. Add any high layer protocols as you wish.

Figure 92-Modify Frame Contents As Needed

7. Click L2-L3 Traffic to push flow group definition to Ixia hardware and then click the green arrow to start sending traffic. Verify the traffic from Statistics > Port Statistics. As expected, Frames TX and Frames RX, as well as Frames Tx Rate and Frames Rx Rate are matching. A small variant is due to the OAMPDUs.

Figure 93-Push Flow Group Definition to Ixia HW and Start Traffic

PN 915-2624-01 Rev D

December 2011

77

TEST CASE: ETHERNET/LINK OAM REMOTE LOOPBACK

Figure 94-Traffic Statistics Clearly Shows Loopback by DUT

8. To disable the loopback, simply go to Learned Info and click to select Disable Loopback command, then click Send Loopback. The DUT status can be verified in many ways — the simplest and most reliable one is to check traffic stats. The port used for sending a loopback command no longer receives traffic; and the other port is receiving traffic now since the DUT is a layer 2 switch, in this case, and it is broadcasting frames to all ports.

Disable Loopback

Figure 95-Traffic Statistics Shows Disable of Loopback

PN 915-2624-01 Rev D

December 2011

78

TEST CASE: ETHERNET/LINK OAM REMOTE LOOPBACK 9. In some cases a Loopback command cannot be sent from Ixia due to local unstable state as indicated by the error message Packet Sent: 0 Error: Discovery not in stable state. To fix this, you can go to the Advanced tab and select Override Local Stable and then Send Updated Parameters.

Figure 96-Trouble Shoot if Loopback Can’t be Sent

Figure 97-Override Local Stable Condition

PN 915-2624-01 Rev D

December 2011

79

TEST CASE: ETHERNET/LINK OAM REMOTE LOOPBACK 10. To test the DUT’s ability to issue a loopback request, you can type the appropriate CLI from the DUT and then go to the Ixia port and check on the Learned Info > Local Information. It should show the port is in LB state with DISCARD mux action. Should you decide to send traffic to test he loopback, make sure you set the Ethernet Type to match the traffic you’re sending from the DUT.

Figure 98-Verify DUT’s Ability to Send Loopback Request

Figure 99-Configure the Ethernet Type to Match DUT’s Traffic Type

PN 915-2624-01 Rev D

December 2011

80

TEST CASE: ETHERNET/LINK OAM REMOTE LOOPBACK

Test Variables Any of the following variables may be used to verify DUT Link OAM Loopback functions: •

Number of test ports — if there is a need to verify OAM Loopback across multiple DUT ports

•

Operation Mode — Active or Passive — Only Active mode supports Loopback request. Passive mode can only respond but can’t initiate.

•

Loopback request in conjunction with Remote Failure Indication flags

•

Loopback in conjunction with Capability flags

•

Loopback only on data but not on OAMPDUs and Pause frames

•

Traffic rate and packet size

Results Analysis Loopback state can be verified in multiple ways. The DUT usually has a CLI to clear the display interface state. Ixia learned info will show all discovered info including loopback state. Most importantly, loopback can be confirmed using data plane traffic.

Troubleshooting and diagnostics Problem

Description

Cannot display learned info from DUT

Check to make sure either the DUT or Ixia emulator is configured in Active mode. If both are configured in passive mode, none of them will start the discovery process, so no learned info will be displayed.

DUT won’t respond to Ixia loopback reqeust

When Ixia is in Local Unstable state during discovery phase with DUT, it will not be able to send Loopback command. To fix it, you can override the local stable state via the Advanced function.

Ixia cannot loopback traffic to DUT

Most likely the DUT is sending/forwarding traffic with a different Ethernet Type value than default “0xFFFF”.

Conclusions Ethernet/Link OAM Loopback allows the remote end to loopback the traffic for efficient trouble shooting in a real network. Ixia’s Link OAM emulation provides the ability to verify both the DUT’s response to a loopback request and its ability to initiate a

PN 915-2624-01 Rev D

December 2011

81

TEST CASE: ETHERNET/LINK OAM REMOTE LOOPBACK loopback request. The loopback state can be verified by multiple means including use of data plane traffic.

DUT Config Excerpt Interface FastEthernet1/0/1 switchport mode access ethernet oam remote-loopback supported ethernet oam

PN 915-2624-01 Rev D

December 2011

82

SERVICE OAM

Service OAM Service OAM is defined in IEEE 802.1ag (aka Ethernet CFM) and ITU-T Y.1731. These standards address OAM for end to end Ethernet services and infrastructure. Table 1 below describes various OAM functionalities and how these two standards solve them. Note that that Y.1731 is a superset of 802.1ag. Table 1.

Ethernet CFM (IEEE 802.1ag)

Comparing OAM Functionalities

ITU-T Y.1731

ITU-T Y.1731

OAM Functions for Fault Management

OAM functions for Fault Management

OAM functions for Performance Monitoring

Ethernet continuity check (CCM) Ethernet loopback (LBM/LBR)

Ethernet continuity check (ETH-CC)

Frame loss measurement (ETH-LM)

Ethernet loopback (ETH-LB)

Ethernet link trace (LTM/LTR)

Ethernet link trace (ETH-LT)

Frame delay measurement (ETH-DM) Throughput measurement

MEP Variables including remote defect indication (RDI)

Ethernet alarm indication signal (ETH-AIS) Ethernet remote defect indication (ETH-RDI) Ethernet lock signal (ETH-LCK) Ethernet test signal (ETH-Test) Ethernet automatic protection switching (ETH-APS) Ethernet maintenance communications channel (ETHMCC) Ethernet experimental OAM (ETH-EXP) Ethernet vendor-specific OAM (ETH-VSP)

PN 915-2624-01 Rev D

December 2011

83

SERVICE OAM Service OAM also provides hierarchy so that Service Providers can segment the network into Maintenance Domains and also assign Levels. One example of this hierarchical Maintenance Domain model is when service providers contract with operators to provide an Ethernet service to a customer. All three will have their own domain, but the service provider’s domain is a superset of the operators' domain, and the customer’s domain is a superset of the service provider's domain.

Figure 100-Service OAM Hierarchy example

When using Ethernet CFM in the domain, there are two primary elements: a Maintenance End Point (MEP) and a Maintenance Intermediate Point (MIP). Maintenance endpoints (MEPs) live at the edge of a maintenance domain, and maintenance intermediate points (MIPs) are within the domain.

Figure 101-MEPs and MIPs in a Service OAM Network

The relationship between MEPs within a given service is known as a Maintenance Association (MA). Since Service Provider networks can enable hundreds or thousands of E-Line or E-LAN services, the number of MAs maintained can quickly grow. Also, the Continuity Check Interval (CCI) can be as fast as 3.33ms, putting strain on the MPs that needs to maintain the Continuity Check Data Base (CCDB). Ixia can emulate many MEPs and MIPs, in turn testing the DUT functionality and scalability when processing Service OAM messages.

PN 915-2624-01 Rev D

December 2011

84

SERVICE OAM

Ethernet CFM (Connectivity Fault Management) – 802.1ag Ethernet CFM is an end-to-end per-service (typically per-VLAN) Ethernet layer OAM protocol. It can monitor connectivity, perform fault verification and fault isolation all at Ethernet Layer 2. CFM is unlike other Ethernet OAM protocols that are not end-to-end technologies. For example, IEEE 802.3ah Link OAM is a single hop per physical wire protocol and is not end-to-end or service aware. CFM can run on any service from CE-PE, PE-PE, or CE-CE device. It is the standard for generating Layer 2 pings and Layer 2 traceroutes, as well as providing connectivity verification of the Ethernet network. Fault Detection – Continuity Checks IEEE 802.1ag and ITU-T Y.1731 support fault detection through Continuity Check Messages (CCM). These are keepalive messages issued periodically by maintenance end points. They allow MEPs to detect an interruption in service. If either end does not receive a CCM within a specified duration, then a fault is detected against the service. Fault Verification - Loopback IEEE 802.1ag and ITU-T Y.1731 support fault verification through Loopback Messages (LBM) and Loopback Reply (LBR). These can be used by a MEP to detect a fault to another MEP. Loopback is conceptually similar to an ICMP Echo (Ping) Fault Isolation – Linktrace IEEE 802.1ag and ITU-T Y.1731 support fault isolation through Linktrace Messages (LTM) and Linktrace Reply (LTR). This serves two purposes. Under normal conditions, it allows the operator to determine the path (hop by hop) used by the service through the network. While under fault conditions, it allows the operator to isolate the fault location without making a site visit. Linktrace is conceptually similar to a UDP traceroute.

Performance Monitoring – the Y.1731 difference In addition to supporting all the functions of Ethernet CFM 802.1ag, Y.1731 also supports a number of performance monitoring functions to measure frame loss ratio, frame delay, and frame delay variation (jitter). Frame Loss Ratio ITU-T Y.1731 calculates frame loss by sending transmit and receive counters within the CCM for dual-ended measurements. The far end counters can then be compared with those produced locally to derive frame loss as a percentage.

PN 915-2624-01 Rev D

December 2011

85

SERVICE OAM Frame Delay Similarly, ITU-T Y.1731 calculates frame delay (or latency) by using a timestamp in the DM (Delay Measurement). The receiving end can derive the time delay experienced across the network. This requires each service end point to have synchronized clocks. Alternatively, DMM/DMR (Delay Measurement Message and Reply) can be used to calculate the two-way frame delay; this method does not require clock synchronization. Frame Delay Variation Finally, ITU-T Y.1731 calculates frame delay variation (or jitter) by tracking frame delay measurements. Relevant Standards • Service OAM o IEEE 802.1ag o ITU-T Y.1731

Note: The three test cases below use IEEE 802.1ag standard (aka Ethernet CFM) instead of ITU-T Y.1731. Ixia’s IxNetwork supports both standards. See page 2 of the CFM/.1731 protocol wizard to select either protocol.

PN 915-2624-01 Rev D

December 2011

86

Test Case: Ethernet CFM – Fault detection with Continuity Check Messages

Test Case: Ethernet CFM – Fault detection with Continuity Check Messages Overview Continuity Check Messages (CCMs) are keepalive messages issued periodically by maintenance end points. Each MEP will broadcast a CCM message at a predetermined interval (ranging from every 3.33milliseconds to 10minutes) towards other MEPs it has a service with. CCM messages (or lack thereof) are used to quickly detect faults in services over Carrier Ethernet networks. This test uses Ethernet CFM (IEEE 802.1ag), but can easily be modified to run ITU-T Y.1731. See page 2 of the CFM/Y.1731 Protocol Wizard

Objective The objective of this test is to verify that CCMs can be sent at their smallest interval (3.33ms) without loss or out-of-order CCM packets between MEPs. Additionally, negative test scenarios such as incorrect CCM intervals will be used to verify the receiving MEP shows a correct fault.

Setup There will be two Ixia ports cabled to two ports on an Ethernet CFM DUT. While the DUT can also terminate MEPs, in this case it will be a MIP pass-through device. The DUT will simply pass the CCMs between the MEPs on the Ixia ports. Each Ixia port will emulate and belong to the same Carrier Ethernet service. The green E-Lan service will have a MIP on each Ixia port with 4 MEPs behind it, for a total of an 8-site E-Lan service.

Figure 102-Ethernet/Service OAM Test Setup

PN 915-2624-01 Rev D

December 2011

87

Test Case: Ethernet CFM – Fault detection with Continuity Check Messages

Step by Step Instructions 1. After reserving the ports, Launch the CFM/Y.1731 Wizard and select the ports.

Figure 103-Launch CFM/Y.1731 Protocol Wizard

The Operation Mode window configures the protocol, Topology type, and Maintenance Association (MA) 2. Change the CCI Interval to 3.33ms. This will verify that the DUT can handle the fastest rate for Continuity Check messages for all 8 Endpoints (MEPs) This number needs to match the DUT. 3. Change the Short MA Name to MA-1. If the Increment Short MA name remains unchecked, then all configured MEPs will belong to the same service.

PN 915-2624-01 Rev D

December 2011

88

Test Case: Ethernet CFM – Fault detection with Continuity Check Messages 4. Optionally: •

Change the Operation Mode to Y.1731. The wizard will change slightly to match the technology described in Y.1731, however it is very similar (actually a superset) to CFM.

•

Change the Topology type to Tree Topology. The picture and wizard will change to match. See the Ethernet CFM Application note at http://www.ixiacom.com/solutions/testing_carrier_ethernet for more information on the tree topology.

Figure 104-CFM/Y.1731 Protocol Wizard

PN 915-2624-01 Rev D

December 2011

89

Test Case: Ethernet CFM – Fault detection with Continuity Check Messages The CFM Topology Type window configures the MAC addresses and number of MEPs to be used. 5. Change the Number of Spoke MEPs per MIP to 4. This will create a topology the same as shown in 0, below. 6. Optionally, configure the Starting MAC address and MEP ID/Step as desired.

Figure 105-CFM/Y.1731 Protocol Wizard

PN 915-2624-01 Rev D

December 2011

90

Test Case: Ethernet CFM – Fault detection with Continuity Check Messages The CFM MD Level window configures the number of Maintenance Domain (MD) levels to use, their name and Level ID. 7. Change the MD Level ID to 6 as shown in the Setup section of this test case. This number must match the DUT. 8. Change the MD name to MD-Level6 as shown in the Setup section of this test case. 9. Optionally, change the number of MD Levels to greater than 1 to create multiple Management Domains within the same wizard run. Each one can then be configured for its MD Level ID and MD Name

Figure 106-Link CFM/Y.1731 Protocol Wizard

PN 915-2624-01 Rev D

December 2011

91

Test Case: Ethernet CFM – Fault detection with Continuity Check Messages The CFM MD Level assignment allows each level of the Topology tree to be configured at different MD level. •

Note at Topology Depth 1there are no MEPs. This represents the MIP at the front of the Ixia port. This is also as depicted in the Setup section of this test case.

•

Note at Topology Depth 2 there are 4 MEPs. This represents the MEPs at the back of the Ixia port (using the Tree Topology). This is also as as depicted in the Setup section of this test case.

10. Optionally, if multiple MD Levels are configured, you can change the MD Level ID here. In some cases IxNetwork may not allow ascending or descending numbers, as described in the standard.

Figure 107-CFM/Y.1731 Protocol Wizard

The MAC/VLAN Configuration page allows VLANs, QinQ, and Traffic Sources and Destinations to be configured. 11. In most cases check the Enable VLAN. This will encapsulate the CFM messages over a VLAN. 12. Choose Single VLAN or Stacked VLAN (QinQ). This will add S-VLANs and C-VLANs respectively. In this case use VLAN 777 13. Optionally, configure the VLAN Priority.

PN 915-2624-01 Rev D

December 2011

92

Test Case: Ethernet CFM – Fault detection with Continuity Check Messages 14. Optionally: check the Enable MAC Range to create Source and Destination MAC Ranges in the CFM Protocol grid. The MACs will show up as Sources and Destinations in the traffic wizard when using the Ethernet/VLAN encapsulation.

Figure 108-CFM/Y.1731 Protocol Wizard

PN 915-2624-01 Rev D

December 2011

93

Test Case: Ethernet CFM – Fault detection with Continuity Check Messages 15. On last screen of the CFM/Y.1731 wizard, assign a meaningful name and then select either option 3 or 4 to save and overwrite the configuration to the IxNetwork GUI. Note: The diagram in the upper panel displays the text of what was configured. See how this matches the Topology setup for this test case.

Figure 109-CFM/Y.1731 Protocol Wizard

Once the configuration is done via the wizard, you can go the main GUI to start the protocol, make protocol-specific changes and observe DUT behavior. You can achieve much functional verification using this method. Below are a few examples that show how to achieve specific test objectives relating to CCMs

PN 915-2624-01 Rev D

December 2011

94

Test Case: Ethernet CFM – Fault detection with Continuity Check Messages 16. View the configuration that the wizard created: •

See the MD Levels created on both ports. They need to be the same if the MEPs from one port are to talk with the other.

•

See the MIPS/MEPs on each port. Note the MIP on each port that is only acting as a pass through for the MEPs (and CCMs). It does not need a MA name as it is not specifically associated with the service.

•

See the 4 MEPs on each port with unique MEP IDs. The same MD and MA level is required for them to be part of the same Service instance.

•

See the CCI interval, of 3.33ms. This must be the same for all MEPs on this E-Lan Service.

•

See the links and how the MEPS go through the MIP on each port.

Figure 110-Viewing configuration post-wizard.

17. Start the CFM Protocol on both ports.

PN 915-2624-01 Rev D

December 2011

95

Test Case: Ethernet CFM – Fault detection with Continuity Check Messages 18. View the CFM Learned Info – CCM DataBase on each port to see what is coming from the neighbor MEPs (in this case from Port2). •

If there are many MDs, S-VLANs, or C-VLANs configured, use the Advanced Filter options to only show the MEPs of choice.

•

Verify there are no Alarms (RDI, Defects, AIS).

Figure 111-Viewing Learned CCM Info.

19. Create a fault by changing a CCM interval on one of the MEPs on Port2 to 1 second. Remember to disable and then enable the MEP for it to take effect.

Figure 112-Creating faulty MEP.

20. Detect the fault using Port1 -> Learned Info -> CCM Database. 21. View the CCM Defect Database. Verify the Remote MEP has a fault. Note the CCI interval is 1 second.

Figure 113-Viewing CCM Defect Database

PN 915-2624-01 Rev D

December 2011

96

Test Case: Ethernet CFM – Fault detection with Continuity Check Messages In addition to the Learned Info, the statistics page also provides a global view of all CFM statistics in a single page for all test ports involved, including CCM TX/RX/OOS.

Figure 114-Ixia CFM Aggregated Statistics

22. For additional troubleshooting and validation of CFM elements, use the capture/analyzer tool. It can automatically filter out unrelated protocol messages, providing a clear trace of the conversations between CFM endpoints, in real time. The tool captures both incoming and outgoing CFM messages, with on-the-fly filters to quickly find a specific packet.

Figure 115-Ixia Capture/Analyzer

PN 915-2624-01 Rev D

December 2011

97

Test Case: Ethernet CFM – Fault detection with Continuity Check Messages The Expanded Decode of the Continuity Check Message packet is shown below (0). •

Note the highlighted fields - MD Level, CCM Interval, CC Sequence #, CC MEP ID, MD Name and MA Name, and TLVs.

Figure 116-Ixia Capture/Analyzer Full Decode

PN 915-2624-01 Rev D

December 2011

98

Test Case: Ethernet CFM – Fault detection with Continuity Check Messages •

Also note that MIP/MEPs and Custom TLVs can be added (0).

Figure 117-Ixia MIPs/MEPs TLVs and Customer TLVs

Test Variables Each of the following variables can be used in separate test cases or combined to test a CFM DUT. They can all use the CCM test case, above, as a baseline configuration. Control Plane Performance Variables Performance Variable

Description

Increase Ports

Step 1: By increasing ports, there will be many more MEPS, MIPS, Domains, MA (Services),and CCMs travelling through or to the DUT, that need to be processed.

Use Tree Topology

Step 4: Besides using the lowest CCM interval of 3.33ms, use the tree topology. This will create more MEPs and hops on a given port or VLAN, and stress the DUT’s ability to maintain a view of the network and its services.

Increase MEPs per MIP

Step 5: Increasing the number of Spoke MEPs per MIP. This creates more MEPS.

More Maintenance Domains (MD)

Step 9: Increasing the number of MDs will cause the DUT to maintain more unique tables, increase its memory consumption, and test the scalability of the DUT.

Add C-VLANs (QinQ)

Step 12: This could potentially create 4095 x 4095 unique VLANs per port, increasing the potential number of MEPs and Services.

Enable MAC Ranges and send Traffic

Step 14: Creating MAC ranges and then building/sending traffic with them will force the DUT to maintain CCMs and tables while forwarding traffic at high rates.

PN 915-2624-01 Rev D

December 2011

99

Test Case: Ethernet CFM – Fault detection with Continuity Check Messages

Results Analysis This test verified that CCMs can be sent at their smallest interval (3.33ms) without loss or out-of-order CCM packets between MEPs (through the DUT). Additionally, when performing negative functions such as an incorrect CCM interval on one of the MEPs in the Service, the other MEPs were able to see the problem and detect a fault in the MEP.

Troubleshooting Tips Issue

MEPs will not come up

Troubleshooting Solution

• Check CFM Aggregated statistics for various statistics including CCM Rx, Invalid CCM Rx, Defect counters, AIS errors, Invalid or Defective MEPS, etc. • Verify CC Interval is the same for all MEPs within the same service instance. • Verify Domain (MD) and Association (MA) are the same for all MEPs within the same service instance. • Check the CCM Defect and CCM No Defect tabs under learned info for any faults.

Conclusions This test verified that the CFM CCM messages can be sent and received at their lowest intervals (3.33ms) across 2 ports and 8 MEPS on a multipoint ELAN service. However, scalability and performance are of paramount importance when testing a DUT acting as a MIP or MEP. Follow the Test Variables section (page 131) to test the SUT at its maximum performance capability before deploying into a real-world Carrier Ethernet Network

PN 915-2624-01 Rev D

December 2011

100

Test Case: Impairment Testing - Drop and Delay CCM Messages

Test Case: Impairment Testing - Drop and Delay CCM Messages Overview In the previous test case, Ixia Test Ports were configured to send CCM messages. CCM messages also play an important role in delay and loss measurement. This is achieved by adding sequence number and timestamp to the CCM messages. If the CCM messages are impaired by the underlying E-Line service or MPLS-TP based transport network, the network device can measure the loss and delay based on CCM messages received. Since the loss and delay reported by these devices are used to monitor the performance of the network, it is important to validate that the network device is measuring the loss and delay of CCM messages accurately. Here it is discussed how Ixia’s ImpairNet module can be configured to introduce drop, delay and jitter impairments in the CCM messages.

Objective The objective of this test is to introduce drop, delay and jitter in the CCM messages flowing through the ImpairNet module. Though the focus of this test is to impair CCM messages, the same steps can be used to impair other OAM messages and Ethernet/VLAN Traffic. At the end of this test, other test variables are discussed that provide more performance test cases.

Setup The setup is similar to the setup in the previous test case except that an impairment module is inserted between the Ixia test port and Ethernet CFM DUT.

Figure 118-Impairment testing – Drop and Delay CCM Messages

PN 915-2624-01 Rev D

December 2011

101

Test Case: Impairment Testing - Drop and Delay CCM Messages

Step by Step Instructions These instructions result in Delay, Jitter and Drop Impairment test for the CFM topology. You can use the steps below as a guide to build other Impairment test scenarios. 1. Follow the steps in the Test Case: Ethernet CFM – Fault detection with Continuity Check Messages to configure MIP/MEP Topology. Note: The configuration parameters in this test case are different from those of the previous test case and accordingly there are differences in the impairment statistics. 2. Reserve two impairment ports in IxNetwork. The Impairment ports are added in the same way as other Ixia test ports with the exception that Impairment Ports are always selected as a pair of ports.

Figure 119-Impairment Port Selection

Optionally, Rename the ImpairNet ports just like any other test ports for easy reference throughout the IxNetwork application.

PN 915-2624-01 Rev D

December 2011

102

Test Case: Impairment Testing - Drop and Delay CCM Messages

3. Click the Network Impairment icon on the Test Configuration pane to switch to the Network Impairment view. Select the Profiles tab. Click Add Profile to create an impairment profile. Note: The exclamation mark on the Apply Impairment icon indicates that the previous impairment profile changes are not applied to the hardware.

Figure 120-Network Impairment view

Optionally, Click the Profile Name grid to change the name of the impairment profile. The profile has been named Impair CCM here. Note: Each profile has a checkbox to enable or disable the profile. The impairment profile Default Profile cannot be disabled.

PN 915-2624-01 Rev D

December 2011

103

Test Case: Impairment Testing - Drop and Delay CCM Messages Optionally, You can create impairment profile for the Ethernet/Service Traffic. Switch to the L2-3 Flow Groups view, select the traffic flow group, and right click. Create Impairment Profile from list.

Figure 121-Create Impairment Profile from Traffic

Creating impairment profile directly from the traffic flow group has the advantage that all the L2-3 traffic classifiers are automatically added to the traffic classifier for this profile. Note: After the profile is created, the view will automatically switch to Network Impairment view.

PN 915-2624-01 Rev D

December 2011

104

Test Case: Impairment Testing - Drop and Delay CCM Messages 4. Click the classifier grid of the Impair CCM profile. The classifier pattern value has hexadecimal format, and is aligned to an octet boundary. The unused bits in the value are ignored using ‘don’t care bits’ in the mask. Click the Add/Edit icon to open the Packet Templates Manager. Add the Ethernet -> VLAN -> CFM protocol layers and select CFM Op Code. Set the Op code value to 01 and mask to FF in the Packet Classifier. Note: The offset and field-size values are already set when you select the field from Packet Templates Manager. Select the classifier.

Figure 122-Adding CCM Traffic classifier

PN 915-2624-01 Rev D

December 2011

105

Test Case: Impairment Testing - Drop and Delay CCM Messages 5. Click the Links grid of the Impair CCM profile. These links denote traffic direction inside impairment module. Select the links so that the impaired traffic passes through the DUT.

Figure 123-Impairment Link Selection

6. Select the Delay tab, to apply delay and jitter impairments in Network Impairment -> Profiles tab. Select the impairment profile and right click on Delay grid. Select the Enabled checkbox and enter delay as 300 microseconds.

Figure 124-Delay Impairment Configuration

PN 915-2624-01 Rev D

December 2011

106

Test Case: Impairment Testing - Drop and Delay CCM Messages 7. Select the impairment profile and right click on Delay Variation grid. Select the Enabled checkbox and select Gaussian delay variation. Enter the value of Standard Deviation as 50 microseconds.

Figure 125-Jitter Impairment Configuration

8.

Click the Apply Impairment icon, in the Configuration ribbon, to apply the impairment profile in the hardware. Only Enabled profiles are applied to the hardware. If applying impairment profile changes is successful, the exclamation mark on the Apply Impairment icon disappears.

Figure 126-Apply Impairment Icon Change

Note: If the impairment profile contains configuration errors, the exclamation mark remains, and an error notification window appears. For further troubleshooting, follow the instructions in the Troubleshooting Tips section.

PN 915-2624-01 Rev D

December 2011

107

Test Case: Impairment Testing - Drop and Delay CCM Messages 9. Select Impairment Profile Statistics and click the Delay tab.

Figure 127-Delay Impairment Profile Statistics

Note: Two profiles show delay statistics, Impair CCM Impairment profile, and Impairment Profile 1. Impairment Profile1 shows an intrinsic delay of 30 us. As per delay variation configuration, delay is expected in the range from ~150 us to ~450 us and is achieved in this setup. However, the amount of delay applied, varies with the spacing between packets and the amount of traffic flowing through the ImpairNet module. 10. Select Impairment Link Statistics tab in the Impairment Statistics view, and select Delay tab, to check the packet delay/jitter statistics for impairment links. Note: Unlike impairment profile statistics, impairment link statistics show delay statistics for all packets passing through the links; therefore, Link statistics values vary from the Profile statistics values.

Figure 128-Delay Impairment Link Statistics

PN 915-2624-01 Rev D

December 2011

108

Test Case: Impairment Testing - Drop and Delay CCM Messages 11. Right-click the Drop grid of Impair CCM impairment profile, to apply drop impairment. Select the Enabled checkbox and set the drop percentage to 50%.

Figure 129-Drop Impairment Configuration

12. The Apply Impairment icon shows an exclamation mark as the latest impairment profile changes are not yet applied to hardware. Click Apply Impairment icon to apply the impairment profile changes. Note: The impairment profile changes are applied without disrupting the traffic flowing through the ImpairNet module. 13. Select Impairment Profile Statistics tab and click the Dropped tab.

Figure 130-Drop Impairment Profile Statistics

PN 915-2624-01 Rev D

December 2011

109

Test Case: Impairment Testing - Drop and Delay CCM Messages

14. Select Impairment Link Statistics tab in the Impairment Statistics view and select Dropped tab, to check the dropped packet statistics for each link direction of the Impair CCM Impairment profile.

Figure 131-Drop Impairment Link Statistics

Ensure that the packets are dropped as per the configured rate.

Test Variables Each of the following variables can be used in separate test cases. They use the test case detailed above as a baseline, modifying a few parameters in the same Network Impairment view. You can create various scalability tests to utilize the DUT operating completely in presence of actual world network impairments. Performance Variable

Description

Create multiple profiles You can create up to 32 bidirectional, or 64 unidirectional impairment profiles per impairment port pair. Add multiple classifiers You can add multiple classifiers in a single impairment profile. Classifiers can be copied and pasted across impairment profiles by using Copy Classifier and Paste Classifier commands in the Network Impairment Configuration tab. A maximum of 16 classifiers can be added for each link direction. Apply impairments in both link directions

You can select to impair one or both the links.

Increase Delay

Introduce delay to a maximum of 6s for every impairment profile on 1G impairment module, and to a maximum of 600 ms for every impairment profile on 10G impairment module.

Select among different kinds of delay units

Introduce delay in us, ms or km. 1 km of WAN Link causes a delay of 5 us.

PN 915-2624-01 Rev D

December 2011

110

Test Case: Impairment Testing - Drop and Delay CCM Messages Apply different delay variations

You can apply uniform, exponential and customized delay variations.

Apply different drop rates

Apply drop rates from 0-100% in clusters, to a maximum of 65535

Apply different packet impairments

Apply, reorder, and duplicate BER impairments in addition to drop impairments. Reorder and duplicate impairments are present in the Packet Actions tab.

Apply BER impairment

Apply BER impairment in the Other tab. Optionally, select to correct L2 FCS error, or, drop the packet with L2 FCS errors in the Checksum grid.

packets.

Results Analysis This test proved that WAN Link conditions such as delay, jitter and drop can be successfully emulated and CCM messages can be selected to impair. In this test only CCM messages were impaired, but other OAM messages like LMM, LMR, DMM, DMR, 1DM and 1DR can also be impaired in a similar way to completely test the delay and loss measurements reported by the network device.

Troubleshooting Tips Issue

Troubleshooting Solution

Impairment profiles are Ensure that the Apply Impairments icon does not have any error. enabled but Make sure that traffic is flowing through the module and the drop rate impairment statistics is not set to 100%. are not updated. No traffic is flowing To ensure that traffic is flowing through the impairment modules, through the impairment disable all the impairment profiles except the default profile , Apply links. Impairments and check that Rx/Tx Frames statistics for the impairment link corresponds to the traffic. Ensure that both the links for the impairment port pair are forwarding, i.e., the checkboxes for Interrupt Forwarding are clear. An error window appears, on clicking Apply Impairments.

Ensure that there is no impairment profile configuration error. Make sure that the impairments are applied with in the configuration limits. Check ImpairNet module specifications for the configuration limits.

Traffic is not getting impaired though the Apply Impairment icon is not showing any error.

Ensure that the classifier value, mask and offset are set correctly. Also make sure that a profile with generic classifier does not have a lower priority than that of the desired impairment profile. Also ensure that the Enabled checkbox is selected for the configured impairments.

PN 915-2624-01 Rev D

December 2011

111

Test Case: Impairment Testing - Drop and Delay CCM Messages

Conclusions This test verified that the device or system under test is generating the loss and delay reports accurately and the measurements match that of Impairment module.

PN 915-2624-01 Rev D

December 2011

112

TEST CASE: ETHERNET CFM – FAULT VERIFICATION USING LOOPBACK

Test Case: Ethernet CFM - Fault Verification using Loopback Overview While CCMs can help quickly detect a fault in a given CFM service between MEPs, the Loopback feature is designed to verify the fault, not only between MEPs, but also to the MIPS along the service path. Equivalent to the IP Ping command, service faults can be verified using Loopback Messages (LBM) and Loopback Reply messages (LBR). These messages can be sent to verify the location of the fault by querying MEPs and MIPs along the service path. This test uses Ethernet CFM (IEEE 802.1ag), but can easily be modified to run ITU-T Y.1731. See page 2 of the CFM/Y.1731 Protocol Wizard

Objective The objective of this test is to (purposely) create a fault in an Ethernet ELAN service and then use the Loopback messages to verify this fault.

Setup Two Ixia ports are cabled to two ports on an Ethernet CFM DUT. While the DUT can also terminate MEPs, in this case it will be a MIP pass-through device. The MEPs/MIPs on the DUT can also respond to Loopback messages, but in this test it will pass the Loopback messages between Ixia ports. Each Ixia port will emulate and belong to the same Carrier Ethernet service. The green E-Lan service will have a MIP on each Ixia port with 4 MEPs behind it, for a total of an 8-site E-Lan service.

Figure 132 - Ethernet/Service OAM Test Setup

PN 915-2624-01 Rev D

December 2011

113

TEST CASE: ETHERNET CFM – FAULT VERIFICATION USING LOOPBACK

Step by Step instructions 1. Follow Steps 1 through 18 in the Ethernet CFM – Verifying fault detection with Continuity Check Messages test (page 88) to setup the Ethernet CFM emulation for use in this test case. Those steps are not repeated here. 2. Create a fault by disabling a MEP on Port2. Note the MEP ID of 6 and the MAC address of 10 00 07.

Figure 133-Disabling MEP on Port 2

3. First, detect the fault using Port1 -> Learned Info -> CCM Database View the CCM Defect Database. Verify the Remote MEP that was brought down in Step2 has a fault.

Figure 134-Viewing CCM Defect Database

PN 915-2624-01 Rev D

December 2011

114

TEST CASE: ETHERNET CFM – FAULT VERIFICATION USING LOOPBACK 4. Verify the fault using Port1 -> Learned Info -> Loopback Tab. •

Click the Start loopback button. By default this performs an All-to-All loopback from all Source MEPs to all Destination MEPs on all S-VLANs and C-VLANs

•

The bottom of the window shows the Loopback Replies and the associated Metrics. Note that the disabled MEP from Step 2 is not responding to the Loopback messages.

Figure 135-Default Loopback parameters and results

PN 915-2624-01 Rev D

December 2011

115

TEST CASE: ETHERNET CFM – FAULT VERIFICATION USING LOOPBACK

5. Use the filters within the Loopback window to narrow the Loopback messages sent only to the points of interest. In this case, one way to see only the unreachable MEPs is to run the Loopback All Source MEPs to Destination MEP 00 00 00 10 00 07. Other filters include: Send Loopbacks per S-VLAN and/or C-VLAN. Send Loopbacks per Source or Destination MEP ID. Send Loopbacks per Destination MIP. Send Loopbacks only at a certain MD Level. Override and customize the Users input to show anything for MD Level, Source, Destination, S-VLAN, and C-VLAN.

Figure 136-Filtering Loopback messages to MEPs of interest

PN 915-2624-01 Rev D

December 2011

116

TEST CASE: ETHERNET CFM – FAULT VERIFICATION USING LOOPBACK In addition to the Learned Info, the statistics page also provides a global view of all CFM statistics in a single page for all test ports involved, including Loopback Messages sent/received.

Figure 137-Ixia CFM Aggregated Statistics

PN 915-2624-01 Rev D

December 2011

117

TEST CASE: ETHERNET CFM – FAULT VERIFICATION USING LOOPBACK 6. For additional troubleshooting and validation of CFM elements, use the capture/analyzer tool. It can automatically filter out unrelated protocol messages, providing a clear trace of the conversations between CFM endpoints, in real time. The tool captures both incoming and outgoing CFM messages, with on-the-fly filters to quickly find a specific packet.

Figure 138-Ixia Capture/Analyzer

PN 915-2624-01 Rev D

December 2011

118

TEST CASE: ETHERNET CFM – FAULT VERIFICATION USING LOOPBACK 7. The Expanded Decode of the Loopback Message Packet is shown in Figure 139. •

The Source and Destination are specifically between two MAC addresses (like a ping is between two IP addresses).

•

The OpCode for a Loopback Message is 3.

•

Not shown – The Loopback Reply message reverses the Src/Dst Mac as shown below, and an OpCode for a Loopback Reply Message is 2. All the other decode options are the same as below.

•

The mandatory and optional TLVs will also be shown/decoded.

Figure 139-Ixia Capture/Analyzer Full Decode

In accord with the standard, IxNetwork allows Periodic OAM messages for Loopback and Linktrace, (similar to sending continuous pings or traceroutes).To configure this:

PN 915-2624-01 Rev D

December 2011

119

TEST CASE: ETHERNET CFM – FAULT VERIFICATION USING LOOPBACK

8. Go to the MIPs/MEPs -> Periodic OAM Settings Tab. 9. Select the Enable Auto LT and Enable Auto LB checkbox and configure it to send the Loopback and Linktrace messages every 2 seconds to MAC address 00 00 00 10 00 07.

Figure 140-Ixia Periodic OAM Configuration screen

10. Stop and Restart the Ethernet CFM protocol on the ports where you are configuring Periodic OMA. 11. Go to Learned Info -> Periodic OAM tab, and leave the dropdown at Loopback. Click the Update button to show the most recent statistics for the ongoing loopback messages. By sending these messages repeatedly, it will ensure system stability over the Carrier Ethernet service.

Figure 141-Ixia Periodic OAM Updates screen

PN 915-2624-01 Rev D

December 2011

120

TEST CASE: ETHERNET CFM – FAULT VERIFICATION USING LOOPBACK Note that MIP/MEP and Custom TLVs can be added.

Figure 142-Ixia MIPs/MEPs TLVs and Custom TLVs

Test Variables Each of the following variables can be used in separate test cases or combined to test a CFM DUT. They can all use the Loopback test case above (beginning page 101) as a baseline configuration. Control Plane Performance Variables Performance Variable

Description

Increase Ports

Step 1: By increasing ports, there will be many more MEPS, MIPS, Domains, MA(Services),and CCMs travelling through or to the DUT, that need to be processed.

Use Tree Topology

Step 4: Besides using the lowest CCM interval of 3.33ms, use the tree topology. This would create more MEPs and hops on a given port or VLAN, and stress the DUT’s ability to maintain a view of the network and its services.

Increase MEPs per MIP

Step 5: Increasing the number of Spoke MEPs per MIP. This creates more MEPS.

More Maintenance Domains (MD)

Step 9: Increasing the number of MDs will cause the DUT to maintain more unique tables, increase its memory consumption, and test the scalability of the DUT.

Add C-VLANs (QinQ)

Step 12: This could potentially create 4095 x 4095 unique VLANs per port, increasing the potential number of MEPs and Services.

Enable MAC Ranges and send Traffic

Step 14: Creating MAC ranges and then building/sending traffic with them will force the DUT to maintain CCMs and tables while forwarding traffic at high rates.

PN 915-2624-01 Rev D

December 2011

121

TEST CASE: ETHERNET CFM – FAULT VERIFICATION USING LOOPBACK

Results Analysis This test verifies that the Loopback function of CFM can be used to verify the fault of a given MEP or MIP across a Carrier Ethernet Network. Additionally, when performing negative functions such as bringing down a MEP, the Loopback feature can verify the DUT Loopback Reply messages are correct.

Troubleshooting Tips Issue

Troubleshooting Solution

MEPs will not come up

• Check the CFM Aggregated statistics for various statistics including LBM and LBR Tx/Rx, Invalid LBM and LBR Rx, Defect counters, AIS errors, Invalid or Defective MEPS, etc. • Verify Domain (MD) and Association (MA) are the same for all MEPs within the same service instance. • Check the Loopback tabs under learned info for any faults

Conclusions The test verified that when there is a fault in the Carrier Ethernet network across a single or multiple domains or services, the Loopback function can be a valuable tool to ping and verify the fault. However, scalability and performance are of paramount importance when testing a Carrier Ethernet DUT. Follow the Test Variables section above (page 121) to test the DUT at its maximum performance capability before deploying into a real-world Carrier Ethernet Network.

PN 915-2624-01 Rev D

December 2011

122

Test Case: Ethernet CFM - Fault isolation using Linktrace

Test Case: Ethernet CFM - Fault isolation using Linktrace Overview CCM messages provide fault detection end-to-end on a given service path. Loopback messages provide fault verification within a given service path. LinkTrace messages provide fault isolation within a given service path. Linktrace is conceptually similar to a UDP traceroute. When a Linktrace message (LTM) is sent to a MEP, all nodes along the path (including MIPs) respond with a Linktrace Reply (LTR). The returned LTRs (and those not returned) identify the where the fault occurred. Linktrace can also be used to determine the path a service takes through the network. This test uses Ethernet CFM (IEEE 802.1ag), but can easily be modified to run ITU-T Y.1731. See page 2 of the CFM/Y.1731 Protocol Wizard

Objective The objective of this test is to (purposely) create a fault in an Ethernet ELAN service and then use the Linktrace messages to isolate exactly where this fault occurred.

Setup Two Ixia ports are cabled to two ports on an Ethernet CFM DUT. While the DUT can also terminate MEPs, in this case it will be a MIP pass-through device. The MEPs/MIPs on the DUT can also respond to Linktrace messages. Each Ixia port will emulate and belong to the same Carrier Ethernet service. The green E-Lan service will have a MIP on each Ixia port with 4 MEPs behind it, for a total of an 8-site E-Lan service.

Figure 143-Ethernet/Service OAM Test Setup

PN 915-2624-01 Rev D

December 2011

123

Test Case: Ethernet CFM - Fault isolation using Linktrace

Step by Step instructions 1. Follow Steps 1 through 18 in the Ethernet CFM – Verifying fault detection with Continuity Check Messages test (page 88) to setup the Ethernet CFM emulation for use in this test case. Those steps are not repeated here. 2. Create a fault by disabling a MEP on Port2. Note the MEP ID of 6 and the MAC address of 10 00 07

Figure 144-Disabling MEP on Port 2

3. First, detect the fault using Port1 -> Learned Info -> CCM Database. View the CCM Defect Database. Note that the Remote MEP that was brought down in Step2 has a fault.

Figure 145-Viewing CCM Defect Database

PN 915-2624-01 Rev D

December 2011

124

Test Case: Ethernet CFM - Fault isolation using Linktrace 4. Verify the fault using Port1 -> Learned Info -> Loopback Tab. 5. Click the Start loopback button. By default this performs an All-to-All loopback from all Source MEPs to all Destination MEPs on all S-VLANs and C-VLANs. The bottom panel shows the Loopback Replies and the associated Metrics. Note that the disabled MEP from Step 2 is not responding to the Loopback messages.

Figure 146-Default Loopback parameters and results

PN 915-2624-01 Rev D

December 2011

125

Test Case: Ethernet CFM - Fault isolation using Linktrace 6. Now, isolate the fault using Port1 -> Learned Info -> LinkTrace tab. 7. Click the Start LinkTrace button. By default this performs an All-to-All loopback from all Source MEPs to all Destination MEPs on all S-VLANs and C-VLANs. The bottom panel shows the Linktrace Replies and the associated Metrics. Note that the disabled MEP from Step 2 is not responding to the LinkTrace messages; therefore there are only 2 hops shown in the hops column, and the status is Partial Reply.

Figure 147-Default Linktrace parameters and results

PN 915-2624-01 Rev D

December 2011

126

Test Case: Ethernet CFM - Fault isolation using Linktrace 8. Use the filters within the Linktrace window to narrow the Linktrace messages sent only to the points of interest. In this case, one way to see only the unreachable MEPs is to run the Linktrace All Source MEPs to Destination MEP 00 00 00 10 00 07. Other filters include: •

Send Linktrace per S-VLAN and/or C-VLAN.

•

Send Linktrace per Source or Destination MEP ID.

•

Send Linktrace per Destination MIP.

•

Send Linktrace only at a certain MD Level.

•

Override and customize the Users input to be anything for MD Level, Source, Destination, S-VLAN, and C-VLAN.

Figure 148-Filtering Linktrace messages to Hops of interest

PN 915-2624-01 Rev D

December 2011

127

Test Case: Ethernet CFM - Fault isolation using Linktrace 9. In addition to the Learned Info, the statistics page also provides a global view of all CFM statistics in a single page for all test ports involved, including Linktrace Messages sent/received, Invalid messages, and RMEP errors/info.

Figure 149-Ixia CFM Aggregated Statistics

10. For additional troubleshooting and validation of CFM elements, use the capture/analyzer tool. It can automatically filter out unrelated protocol messages, providing a clear trace of the conversations between CFM endpoints, in real time. The tool captures both incoming and outgoing CFM messages, with on-the-fly filters to quickly find a specific packet.

Figure 150-Ixia Capture/Analyzer

PN 915-2624-01 Rev D

December 2011

128

Test Case: Ethernet CFM - Fault isolation using Linktrace The Expanded Decode of the Linktrace Message and Linktrace Reply message packets is shown in 0. •

Note the highlighted fields of the LinkTrace Message – Dst MAC is a multicast address, Originate/Target MAC Address, and TLVs.

•

Note the highlighted fields of the LinkTrace Reply – Specific Src and Dst MAC address, Next/Last Egress Identifiers, and TLVs.

Figure 151-Ixia Capture/Analyzer FullDecode

PN 915-2624-01 Rev D

December 2011

129

Test Case: Ethernet CFM - Fault isolation using Linktrace In accord with the standard, IxNetwork allows Periodic OAM messages for Loopback and Linktrace (similar to sending continuous Pings or Traceroutes). To configure this: 11. Go to the MIPs/MEPs -> Periodic OAM Settings tab. 12. Select the Enable Auto LT and Enable Auto LB checkbox and configure it to send the Loopback and Linktrace messages every 2 seconds to MAC address 00 00 00 10 00 07.

Figure 152-Ixia Periodic OAM Configuration screen

13. Stop and Restart the Ethernet CFM protocol on the ports you are configuring Periodic OMA. 14. Go to Learned Info -> Periodic OAM tab, and do not change the dropdown selection Link Trace. Click the Update button to show the most recent statistics for the ongoing linktrace messages. Sending these messages repeatedly will ensure system stability over the Carrier Ethernet service.

Figure 153-Ixia Periodic OAM Updates screen

PN 915-2624-01 Rev D

December 2011

130

Test Case: Ethernet CFM - Fault isolation using Linktrace Also note that MIP/MEP and Custom TLVs can be added.

Figure 154-Ixia MIPs/MEPs TLVs and Custom TLVs

Test Variables Each of the following variables can be used in separate test cases or combined to test a CFM DUT. They can all use the Loopback test case above (beginning page 101) as a baseline configuration. Control Plane Performance Variables Performance Variable

Description

Increase Ports

Step 1: By increasing ports, there will be many more MEPS, MIPS, Domains, MA (Services),and CCMs travelling through or to the DUT that need to be processed.

Use Tree Topology

Step 4: Besides using the lowest CCM interval of 3.33ms, also use the tree topology. This will create more MEPs and hops on a given port or VLAN, and stress the DUT’s ability to maintain a view of the network and its services

Increase MEPs per MIP

Step 5: Increasing the number of Spoke MEPs per MIP. This creates more MEPS.

More Maintenance Domains (MD)

Step 9: Increasing the number of MDs will cause the DUT to maintain more unique tables, increase its memory consumption, and test the scalability of the DUT.

Add C-VLANs (QinQ)

Step 12: This could potentially create 4095 x 4095 unique VLANs per port, increasing the potential number of MEPs and Services.

Enable MAC

Step 14: Creating MAC ranges and then building/sending traffic

PN 915-2624-01 Rev D

December 2011

131

Test Case: Ethernet CFM - Fault isolation using Linktrace Performance Variable

Description

Ranges and send Traffic

with them will force the DUT to maintain CCMs and tables while forwarding traffic at high rates.

Results Analysis This test verified that the Linktrace function of CFM can be used to isolate the fault of a given MEP or MIP across a Carrier Ethernet Network. Additionally, when performing negative functions such as bringing down a MEP, the Linktrace feature can verify the DUT Linktrace Reply messages are correct.

Troubleshooting Tips Issue

MEPs will not come up

Troubleshooting Solution

• Check the Statistics CFM Aggregated statistics for various statistics including LTM and LTR Tx/Rx, Invalid LTM and LTR Rx, Defect counters, AIS errors, Invalid or Defective MEPS, etc. • Verify Domain (MD) and Association (MA) are the same for all MEPs within the same service instance. • Check the Linktrace tabs under learned info for any faults.

Conclusions The test verified that when there is a fault in the Carrier Ethernet network across a single or multiple domains or services, the Linktrace function can be a valuable tool to Traceroute and verify the fault. However, scalability and performance are of paramount importance when testing a Carrier Ethernet DUT. Follow the Test Variables section above (page 131) to test the DUT at its maximum performance capability before deploying into a real-world Carrier Ethernet Network.

PN 915-2624-01 Rev D

December 2011

132

Test Case: E-LMI – Testing a Device as a Customer Edge (UNI-C)

Test Case: E-LMI – Testing a Device as a Customer Edge (UNI-C) Overview As described in the introduction section in the beginning of this document, E-LMI is an OAM protocol used for the configuration and management of Customer Edge (CE) equipment. Carrier Ethernet services are defined as Ethernet Virtual Circuits (EVCs), and this test case will describe how to test the Device Under Test (DUT) as it functions as a CE, while the Ixia port emulates the Provider Equipment (PE).

Objective The objective of this test is to notify the CE of the addition of five Ethernet Virtual Circuits (EVCs) and exchange the Status/Status Enquiry to verify that the service is running.

Setup One Ixia port is connected via Ethernet to the DUT. The DUT is configured as a UNI-C while the Ixia port emulates the UNI-N. A single UNI is configured with five EVCs, each on a separate VLAN ID. UNI-N

UNI-C

Figure 155

UNI ID: UNI_1

PN 915-2624-01 Rev D

EVCs

VLAN ID

EVC_1

1

EVC_2

2

EVC_3

3

EVC_4

4

EVC_5

5

December 2011

133

Test Case: E-LMI – Testing a Device as a Customer Edge (UNI-C)

Step by Step Instructions 1. Verify the DUT is configured as a UNI-C running E-LMI. The following is an example of the configuration on a Cisco switch: Global level commands:

Figure 156

VLAN interfaces are also configured:

Figure 157

2. Click Add Protocols icon from the toolbar, select the E-LMI Wizard, and click the Run Wizard button:

Figure 158

PN 915-2624-01 Rev D

December 2011

134

Test Case: E-LMI – Testing a Device as a Customer Edge (UNI-C) 3. Select the UNI-N check box and click Next:

Figure 159

Note: You may skip configuring Screen 2. 4. Click Next.

PN 915-2624-01 Rev D

December 2011

135

Test Case: E-LMI – Testing a Device as a Customer Edge (UNI-C) 5. Select Bundling from list for Map Type. Enter the UNI Identifier as UNI_1. Clear the Bandwidth Profile checkbox, and click Next.

Figure 160

PN 915-2624-01 Rev D

December 2011

136

Test Case: E-LMI – Testing a Device as a Customer Edge (UNI-C) 6. Configure the Number of EVC Per UNI to 5. Configure the Start EVC Reference ID to 1. . Configure the EVC Identifier to be EVC_1, and select the Increment checkbox. Change the Number of Bandwidth Profile Per EVC to 0, and click Next.

Figure 161

PN 915-2624-01 Rev D

December 2011

137

Test Case: E-LMI – Testing a Device as a Customer Edge (UNI-C) 7. Configure the Number of CE VLAN ID Range to be 1, and Start VLAN ID - to 1 with a count of 1, and click Next.

Figure 162

PN 915-2624-01 Rev D

December 2011

138

Test Case: E-LMI – Testing a Device as a Customer Edge (UNI-C)

8. Name the wizard configuration and select one of the options to generate, and click Finish.

Figure 163

PN 915-2624-01 Rev D

December 2011

139

Test Case: E-LMI – Testing a Device as a Customer Edge (UNI-C)

9. Click Close.

Figure 164

10. Navigate to the E-LMI node, and use the tabs to validate the E-LMI configuration:

Figure 165

PN 915-2624-01 Rev D

December 2011

140

Test Case: E-LMI – Testing a Device as a Customer Edge (UNI-C)

Figure 166

Figure 167

Figure 168

Figure 169

PN 915-2624-01 Rev D

December 2011

141

Test Case: E-LMI – Testing a Device as a Customer Edge (UNI-C)

11. Click the ELMI icon to start the protocol.

Figure 170

12. Expand the E-LMI node to validate that the protocol is running. Navigate to the ELMI Aggregated Statistics and verify that the UNI-N Configured, UNI-N Running and Session Operational area all equal to 1.

Figure 171

13. Navigate to the Learned Info view, and verify that the LMI Status is Operational. Click Refresh on the toolbar to update the status and counters.

Figure 172

PN 915-2624-01 Rev D

December 2011

142

Test Case: E-LMI – Testing a Device as a Customer Edge (UNI-C)

14. Verify the E-LMI EVCs, Parameters, Statistics and UNI Map on the DUT using the Show commands: Cisco Example:

Figure 173

PN 915-2624-01 Rev D

December 2011

143

Test Case: E-LMI – Testing a Device as a Customer Edge (UNI-C)

Test Variables Test variables for E-LMI testing include: • • • • • • • • • • •

DUT as a UNI-C or UNI-N Number of ports Number of EVCs per UNI CE VLANID/EVC Map type (type of bundling) UNI Identifier length and value If Bandwidth Profiles are enabled o Many devices at the point do not have full support for Bandwidth Profiles EVC Type (Point-to-Point or Multipoint-to-Multipoint) EVC Identifier length and value EVC Reference ID value EVC Status VLAN ID and Priority

Results The results are based on the validation on the Device Under Test. To ensure that E-LMI is working, verify the following: • • • • • • •

E-LMI is running (on Ixia, and on the DUT) Verify that the E-LMI Link Status, and UNI Status are running on the DUT, and shows the correct UNI ID Verify that the EVCs are defined and Active on the DUT Verify that the UNI ID, and map to the port is correct Verify that the Full Status Enquiry is sent by the DUT (at proper intervals) Verify that the Full Status is sent by Ixia, and received by the DUT Verify that there are no errors incremented on Ixia or DUT counters

Troubleshooting When troubleshooting E-LMI, verify the following: •

• • •

Verify that the physical port is running at the expected speed and duplex o You can use the down/up link on Ixia port to verify that corresponding DUT port sees the down/up event E-LMI message counters match Ixia and the DUT (it is advised to use default values) Verify that E-LMI is configured on the DUT and is in the proper mode (UNI-C or UNI-N) Verify that the EVC details are correct including the EV

PN 915-2624-01 Rev D

December 2011

144

Test Case: E-LMI – Testing a Device as a Customer Edge (UNI-C) • •

If using VLANs ensure that they are configured and running on the DUT Use the Counters and Learned Info on Ixia to understand what is being sent and received

For advanced troubleshooting, use the Capture/Decode i the following way: 1.

Navigate to the Captures view in the Test Configuration pane. Select the Control-Enable checkbox. . Click Capture.

Figure 174

2. The packet count will increment while capturing. To view the real-time decode, click Packet Count.

Figure 175

PN 915-2624-01 Rev D

December 2011

145

Test Case: E-LMI – Testing a Device as a Customer Edge (UNI-C)

3. Click on the packet to view the. In the adjacent window, view the Flow Summary or the Ladder Diagram..

Figure 176-802.1ah Backbone Bridge Test Setup

Conclusion In this test case, a typical example of a UNI-C is tested by enabling E-LMI on a single UNI with five EVCs, each on a separate VLAN. Run the E-LMI to give the Provider side of the network visibility to the status of each service running on the UNI-C. In this example, the activation on monitoring of the service is verified. Ongoing testing could test additional parameters covered in the Test Variables section.

PN 915-2624-01 Rev D

December 2011

146

Test Case: SLA Configuration and Performance testing per-EVC using Y.1564 -

Test Case: SLA Configuration and Performance testing per-EVC using Y.1564 Overview As described in the introduction section in the beginning of this document, Y.1564 is an Ethernet Service Activation Test Methodology used to verify the configuration and performance of end-to-end Carrier Ethernet Services. Customers, manufacturers and Service Providers need a test tool that can validate one or many services against the contracted Service Level Agreement (SLA). Send and measure traffic per Service at CIR/CBS, EIR/EBS to validate the configuration of SLAs per service using Ixia’s IxNetwork Y.1564 QuickTest. Verify the Frame Delay (FD), Frame Delay Variation (FDV), and Frame Loss (FL) for each Service. IxNetwork can also run a performance test of all Services simultaneously to ensure proper operation in a real-world environment.

Objective The objective of this test is to verify the configuration and performance of two end-toend Carrier Ethernet Services (EVCs) with unique SLA parameters of CIR, EIR, Frame Delay, and Frame Loss settings to verify the DUT/SUT is working properly per Y.1564 standards. The first part of the test verifies the configuration of each Service one at a time, and the second part tests the performance of both services at the same time.

Setup Two Ixia ports are connected via Ethernet to the DUT/SUT. Use the IxNetwork Y.1564 QuickTest wizard to configure two ELine EVCs, each with a unique VLAN ID, on the Ixia ports with unique CIR, EIR, FD, and FL settings, simulating SLA parameters. The DUT/SUT is also configured to match these settings. See Diagram/table below for the network topology and SLA settings. Run the Y.1564 QuickTest, to send traffic unidirectional from Ixia Port1 to Ixia Port2, one EVC at a time, at different rates as per the Y.1564 specification. Port2 then validates the receipt of the traffic against each SLA setting, providing pass/fail metrics.

PN 915-2624-01 Rev D

December 2011

147

Test Case: SLA Configuration and Performance testing per-EVC using Y.1564 A second test run is initiated with both EVCs running at the same time at full CIR, to validate real-world performance. SLA pass/fail criteria include CIR, FD, and FL metrics for each service.

Figure 177

Service Name Service 1 Service 2

VLAN ID 10 11

CIR

EIR

8 Mbps 16 Mbps

2 Mbps 4 Mbps

Maximum Frame Delay 100 200

Acceptable Frame Loss (frames) 0 0

Step by Step Instructions 1. Verify that the DUT/SUT has the proper Eline EVCs configured as shown in the table above, especially the VLAN ID and CIR/EIR attributes. 2. After you open the IxNetwork program, connect to the chassis and reserve the ports (name them as P1 and P2); a. Navigate to QuickTests. Click Add QuickTests icon, select the Y.1564Service Activation Measurement Wizard and click Next.

Figure 178

PN 915-2624-01 Rev D

December 2011

148

Test Case: SLA Configuration and Performance testing per-EVC using Y.1564 3. On the Ports screen, make sure that the two ports are selected, and click Next: Note: Port counts of more than two are supported

Figure 179

4. On the Services Screen, Click Add Service button twice to add the two EVCs. Change the settings from default to match the SLA parameters used in this test; a. (optional) Service Name – Append VLAN 10 and VLAN 11 b. Change Profile to Port/VLAN ID i. Note: IxNetwork also supports Port and Port/VLAN/CoS profiles c. Change Mesh Type to ELINE i. Note: IxNetwork also supports ELAN Mesh Type d. Change Frame Size to 128 (or any frame size up to 13312) e. Change CIR to match the DUT/ SLA i. Service 1 – VLAN 10 = 8 Mbps ii. Service 2 – VLAN 11 = 16 Mbps Tip: To skip the CIR phase of this test, and go straight to the EIR, set CIR to 0 f. (optional) Change CIR Tolerance %. This may be required because of the difference in how the DUT/SUT versus IxNetwork calculate the CIR Rate sent and received, as defined in the previous step. i. Service 1 – VLAN 10 = 2 % ii. Service 2 – VLAN 11 = 2 % g. Change EIR to match the DUT/SLA i. Service 1 – VLAN 10 = 2 Mbps ii. Service 2 – VLAN 11 = 4 Mbps Tip: To skip the EIR phase of this test, and to only do a CIR, set the EIR to 0 h. Change the Frame Delay to match the maximum acceptable Latency of each Service/EVC as per the SLA. i. Service 1 – VLAN 10 = 100 ms ii. Service 2 – VLAN 11 = 200 ms

PN 915-2624-01 Rev D

December 2011

149

Test Case: SLA Configuration and Performance testing per-EVC using Y.1564 i.

(optional) Change the Frame Delay Tolerance %. This allows the Frame Delay (Latency) sent by the DUT to be higher than the configured Frame Delay in previous step and still consider it as pass. i. Service 1 – VLAN 10 = 2 % ii. Service 2 – VLAN 11 = 2 %

Optional, settings: j. Traffic Type dropdown can be MAC, IPv4, or IPv6 k. Load Unit can be bps, kbps, Mbps, or Gbps. This relates to the unit of measure for the CIR and EIR columns l. Frame Delay Unit can be ms (milliseconds), us(microseconds) ,or ns(nanoseconds). This relates to the unit of measure for the Frame Delay and Frame Delay Variation columns m. Change CBS/EBS bytes if you are also running the CBS/EBS test (see Test Parameters screen later in the wizard) n. Change Frame Delay Variation, if you enable this option to be measured (see Test Parameters screen later in the wizard) o. Small changes can be made to CIR Tolerance %, FD Tolerance %, Frame Loss Ratio %, and Acceptable Frame Loss settings so that IxNetwork is tolerant in passing the tests that use FD, FL, and FLR. It is important to understand that these tolerances are not part of the Y.1564 standard.

Figure 180

PN 915-2624-01 Rev D

December 2011

150

Test Case: SLA Configuration and Performance testing per-EVC using Y.1564 5. On the Traffic Screen a. Select the Service 1 – Vlan 10 from the drop-down list. b. Select P1 as the Source and P2 as the Destination. Click the arrow to add it as a Source/Destination Endpoint Set

(

)

optionally, select the Bi-Directional checkbox c. Repeat Steps a and b for Service 2 – Vlan 11

Figure 181

PN 915-2624-01 Rev D

December 2011

151

Test Case: SLA Configuration and Performance testing per-EVC using Y.1564

6. On the Frame Data Screen a. Select Service 1 – Vlan 10 from the drop-down list. b. Change the VLAN ID to 10. Optionally, change the other Frame Data settings c. Select Service 2 – Vlan 11 from the list. d. Change VLAN ID to 11. Optionally, change the other Frame Data settings

Figure 182

PN 915-2624-01 Rev D

December 2011

152

Test Case: SLA Configuration and Performance testing per-EVC using Y.1564

7. On the Traffic Options Screen; a. Change the Frequency of the Learning Frames (optional). Keep the default settings for the other fields.

Figure 183

8. On the Test parameters Screen; a. Clear the Delay Variation Measurement checkbox.(In this test, Average Latency is tested.) b. Select the Enable Pass/Fail evaluation checkbox and measure latency Average/Port c. Set test Algorithm to Service Configuration Test (default). This will test each Service one at a time. Iteration include; below CIR, CIR, CIR+EIR, CIR+EIR+25% of EIR. Optional settings; d. Select the Delay Variation checkbox, and Pass/Fail checkbox for Delay Variation (in addition to Pass/Fail Latency Maximum/Port). Remember to change the appropriate columns on the Services page. e. Latency Type can be Store/Forward, Cut-Thru, or MEF Frame Delay(FILO) f. Set the Initial Rate (% of CIR) to 75% or 100% if you are sure that the DUT can handle 25%, 50%, and 75% of CIR. This will reduce the number of iterations per service. PN 915-2624-01 Rev D

December 2011

153

Test Case: SLA Configuration and Performance testing per-EVC using Y.1564 g. Set Test Algorithm to Service Performance Test. This will run all services included in this wizard, simultaneously, at CIR rates h. Enable the CBS/EBS test to run right after the Service Configuration or Service Performance test..

Figure 184

9. On the Finish Screen; a. Provide a name, and click Finish. Note: After clicking the finish button wait for theY.1564 Wizard to populate the IxNetwork interface with the configuration. This includes Services, SLAs, traffic, and statistics.

Figure 185

PN 915-2624-01 Rev D

December 2011

154

Test Case: SLA Configuration and Performance testing per-EVC using Y.1564 10. Navigate through the IxNetwork GUI to see how it was configured based on the wizard. Go to Static LAN, L2-3 Traffic Items, and L2-3 Flow Groups

Figure 186

PN 915-2624-01 Rev D

December 2011

155

Test Case: SLA Configuration and Performance testing per-EVC using Y.1564

11. Navigate to QuickTests -> Y.1564 – Configuration -> Start button, and start the test.

Figure 187

PN 915-2624-01 Rev D

December 2011

156

Test Case: SLA Configuration and Performance testing per-EVC using Y.1564 12. (Optional) While the test is run; a. View the real-time scrolling Log b. Click the previous iterations to see the log for the selected iteration (click on ALL to get the log to scroll/show in real time) c. Real time stats including Tx/Rx Rate, Loss, and Latency d. Real Time Status on current iteration, which includes the statistics on how long the traffic has been running.

PN 915-2624-01 Rev D

December 2011

157

Test Case: SLA Configuration and Performance testing per-EVC using Y.1564 Figure 188

13. View end of test results. At the end of a QuickTest, the DataMiner window appears showing the saved detailed and summarized results. a. The Aggregated Results tab shows the key data that the pass/fail criteria was based on, for each iteration of each Service b. (Optional) Click the BwProfile Port VLAN ID tab to see results per VLAN c. (Optional) Click the Open Result file location button to see the saved CSV and LOG files for each tab in screenshot below d. (Optional) Click on the left pane to view previous runs of any QuickTest.

Figure 189

PN 915-2624-01 Rev D

December 2011

158

Test Case: SLA Configuration and Performance testing per-EVC using Y.1564 e. The Pass/Fail Log tab is a shortened summary version of the full log. It shows the important SLA parameters as defined per Service, the algorithms used to determine the result as per Y.1564 standard, the actual results, and clear pass/fail for each.

Figure 190

Now that the “Y/1564 – Service Configuration” test is complete, which tested one service at a time, the next step is to run the Y.1564 – Service Performance test. This test runs both services at the same time, at the CIR rate, to ensure that multiple services can be run simultaneously without affecting each other, and ensure overall DUT/SUT stability in a real-world environment.

PN 915-2624-01 Rev D

December 2011

159

Test Case: SLA Configuration and Performance testing per-EVC using Y.1564 14. Close the Data Miner window. 15. Click QuickTests, and double-click on Y.1564 – Configuration..

Figure 191

PN 915-2624-01 Rev D

December 2011

160

Test Case: SLA Configuration and Performance testing per-EVC using Y.1564 16. Run the Y.1564 – Service Performance test with the same services, and SLA settings. Navigate to the Test Parameters page, and change the Test Algorithm to Service Performance.

Figure 192

17. (Optional) Change the Name of the QuickTest to Y.1564 - Performance

Figure 193

PN 915-2624-01 Rev D

December 2011

161

Test Case: SLA Configuration and Performance testing per-EVC using Y.1564 18. Navigate to QuickTests -> Y.1564 – Performance -> Start to start the test.

Figure 194

PN 915-2624-01 Rev D

December 2011

162

Test Case: SLA Configuration and Performance testing per-EVC using Y.1564 19. (Optional) While the test is running; a. View the real-time scrolling Log b. Real time stats, include Tx/Rx Rate, Loss, and Latency c. Real Time Status on current iteration includes the duration of the traffic run.

Figure 195

PN 915-2624-01 Rev D

December 2011

163

Test Case: SLA Configuration and Performance testing per-EVC using Y.1564 20. View end of test results. At the end of a QuickTest, the DataMiner window appears that show the saved detailed and summarized results. a. The Aggregated Results tab shows the key data that the pass/fail criteria is based on each iteration, of each service b. (Optional) Click the BwProfile Port VLAN ID tab to see results per VLAN c. (Optional) Click the Open Result file location button, to see the saved CSV and LOG files for each tab. d. (Optional) Click on the left pane, to view previous runs of any QuickTest.

Figure 196

PN 915-2624-01 Rev D

December 2011

164

Test Case: SLA Configuration and Performance testing per-EVC using Y.1564 e. The Pass/Fail Log tab is a shortened summary version of the full log. It displays the important SLA parameters, as defined per service, the algorithms used to determine the result as per Y.1564 standard, the actual results, and clear pass/fail for each.

Figure 197

PN 915-2624-01 Rev D

December 2011

165

Test Case: SLA Configuration and Performance testing per-EVC using Y.1564 21. (Optional) Click the Generate Report button at the top of the Data Miner Window to generate a PDF Report of this test run.

Figure 198

Test Variables Test variables for Y.1564 include: • • •

Use more ports to emulate a true Carrier Ethernet environment Add more Services per port and across ports to emulate a true Carrier Ethernet environment Use a combination of ELINE and ELAN EVCs

PN 915-2624-01 Rev D

December 2011

166

Test Case: SLA Configuration and Performance testing per-EVC using Y.1564 •

• •

Uses the Profile called “Port/VLAN ID/VLAN COS”, and configure 2 or more VLAN COS values. IxNetwork equally distributes the Service Rate over each COS value and gives per COS results at the end of the test. To allow each COS value to have its own Rate and settings per COS, add new services each with unique COS values. Configure CBS Bytes and EBS Bytes and run the CBS/EBS test in addition to Service Configuration and Service Performance tests Configure and run additional IxNetwork Carrier Ethernet protocols on the same ports as used in the Y.1564 tests. Ensure the protocols are not affected when the Y.1564 test is run (and vice-versa)

Results In this Y.1564 test case, the DUT/SUT properly forwarded traffic at the configured SLA parameters defined in the QuickTest, including; Service Configuration Test • • •

In iterations 1 to 4, for both Services, IxNetwork sent traffic at 25%, 50%, 75%, and 100% of CIR. The DUT/SUT adhered to the SLA settings In iteration 5, for both Services, IxNetwork sent traffic at 100% of CIR + 100% of EIR. The DUT/SUT adhered to the SLA settings In iteration 6, for both Services, IxNetwork sent traffic at 100% of CIR + 125% of EIR. The DUT/SUT adhered to the configured SLA settings.

Service Performance Test •

In this 1 iteration test, both Service ran at the same time. IxNetwork sent traffic at 100% of CIR, and the DUT/SUT adhered to the SLA settings

Troubleshooting When troubleshooting Y.1564 issues: •

•

•

Where applicable, verify the CIR, EIR, CBS, EBS, FD, FDV and any other Service characteristics that are configured properly from end-to-end in the DUT/SUT. Configure IxNetwork similarly. If the Ixia fails the iteration/test because of a very small difference in Rate/Throughput calculation, increase the CIR Tolerance % slightly. This is needed since DUT/SUT and IxNetwork calculates Rate/Throughput differently. Changes can be made to the FD Tolerance %, Frame Loss Ratio %, and Acceptable Frame Loss settings so that IxNetwork has tolerance in passing the tests that use FD, FL, and FLR. These tolerances are not part of the Y.1564 standard.

PN 915-2624-01 Rev D

December 2011

167

Test Case: SLA Configuration and Performance testing per-EVC using Y.1564

Conclusion This test case is a typical example of Carrier Ethernet test bed using ITU-T Y.1564 to verify the configuration and performance of end-to-end Carrier Ethernet Services (EVCs); each with unique SLA parameters defined. It ensured the DUT/SUT is working properly per Y.1564 Test Methodology. Testing Carrier Ethernet Services using the Y.1564 standard helps Service Providers to ensure proper delivery of services to customers, making them more robust and reliable.

PN 915-2624-01 Rev D

December 2011

168

CONTACT IXIA Corporate Headquarters Ixia Worldwide Headquarters 26601 W. Agoura Rd. Calabasas, CA 91302 USA +1 877 FOR IXIA (877 367 4942) +1 818 871 1800 (International) (FAX) +1 818 871 1805 [email protected]

Web site: www.ixiacom.com General: [email protected] Investor Relations: [email protected] Training: [email protected] Support: [email protected] +1 877 367 4942 +1 818 871 1800 Option 1 (outside USA) online support form: http://www.ixiacom.com/support/inquiry/

EMEA Ixia Europe Limited One Globeside, Fieldhouse Lane Marlow, SL7 1HZ United Kingdom +44 1628 405750 FAX +44 1628 405790 [email protected]

Support: [email protected] +44 1628 405797 online support form: http://www.ixiacom.com/support/inquiry/ ?location=emea

Asia Pacific 210 Middle Road #08-01 IOI Plaza Singapore 188994 +65 6332 0126 [email protected]

Support: [email protected] +1 818 871 1800 (Option 1) online support form: http://www.ixiacom.com/support/inquiry/

Japan Ixia KK Aioi Sampo Shinjuku Building, 16th Floor 3-25-3 Yoyogi Shibuya-Ku Tokyo 151-0053 Japan +81 3 5365 4690 (FAX) +81 3 3299 6263 [email protected]

Support: [email protected] +81 3 5365 4690 online support form: http://www.ixiacom.com/support/inquiry/

Ixia India UMIYA Business Bay Tower – I, 7th Floor, Cessna Business Park Outer ring road (Marathalli- Sarjapur ring road) Kadubeesanahalli Village, Vartur Hobli Bangalore 560 037 India +91 80 42862600

Support: [email protected] +91 80 32918500 online support form: http://www.ixiacom.com/support/inquiry/ ?location=india

169