CARRIER ETHERNET. Black Book. Edition 10. Carrier Ethernet. PN Rev F October 2013 i

Size: px
Start display at page:

Download "CARRIER ETHERNET. Black Book. Edition 10. Carrier Ethernet. PN 915-2624-01 Rev F October 2013 i"

Transcription

1 CARRIER ETHERNET Black Book Edition 10 Carrier Ethernet PN Rev F October 2013 i

2

3 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 Your feedback is greatly appreciated! Copyright 2014 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 and FAR 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 Rev F October 2013 iii

4

5 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 Introduction to CE Testing Provider Bridges (802.1ad) and Provider Backbone Bridges (802.1ah)...25 Test Case: Provider Bridges 802.1ad E-Line Services...29 Test Case: Provider Backbone Bridges 802.1ah E-LAN Services...39 Ethernet/Link OAM (802.3ah) Functional Verification...51 Test Case: Ethernet/Link OAM Discovery Functional Verification...53 Test Case: Ethernet/Link OAM Event Notification...69 Test Case: Ethernet/Link OAM Remote Loopback...77 Service OAM...89 Test Case: Ethernet CFM Fault Detection with Continuity Check Messages...93 Test Case: Impairment Testing - Drop and Delay CCM Messages Test Case: Ethernet CFM - Fault Verification Using Loopback Test Case: Ethernet CFM - Fault Isolation Using Linktrace Test Case: Y Frame Loss Measurement Test Test Case: E-LMI Testing a Device as a Customer Edge (UNI-C) Test Case: SLA Configuration and Performance Testing per-evc Using Y Testing CE Test Case: ELINE Service Attribute - NON-LOOPING FRAME DELIVERY Test Case: ELINE Traffic Management - ONE-WAY FRAME LOSS RATIO PERFORMANCE Test Case: ELINE Service Attribute - NON-LOOPING FRAME DELIVERY Using IxNetwork Test Case: ELINE Traffic Management - ONE-WAY FRAME LOSS RATIO PERFORMANCE using IxNetwork Contact Ixia PN Rev F October 2013 v

6

7 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 Objective Setup Step-by-Step Instructions Test Variables Results Analysis Troubleshooting and Diagnostics Conclusions Provides background information specific to the test case. Describes the goal of the test. An illustration of the test configuration highlighting the test ports, simulated elements and other details. Detailed configuration procedures using Ixia test equipment and applications. A summary of the key test parameters that affect the test s performance and scale. These can be modified to construct other tests. Provides the background useful for test result analysis, explaining the metrics and providing examples of expected results. Provides guidance on how to troubleshoot common issues. 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 Rev F October 2013 vii

8 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 tenth edition of the Black Books includes twenty-two volumes covering some key technologies and test methodologies: Volume 1 Higher Speed Ethernet Volume 2 QoS Validation Volume 3 Advanced MPLS Volume 4 LTE Evolved Packet Core Volume 5 Application Delivery Volume 6 Voice over IP Volume 7 Converged Data Center Volume 8 Test Automation Volume 9 Converged Network Adapters Volume 10 Carrier Ethernet Volume 11 Ethernet Synchronization Volume 12 IPv6 Transition Technologies Volume 13 Video over IP Volume 14 Network Security Volume 15 MPLS-TP Volume 16 Ultra Low Latency (ULL) Testing Volume 17 Impairments Volume 18 LTE Access Volume ac Wi-Fi Benchmarking Volume 20 SDN/OpenFlow Volume 21 Network Convergence Testing Volume 22 Testing Contact Centers 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 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. Errol Ginsberg, Acting CEO PN Rev F October 2013 viii

9 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 PN Rev F October 2013 ix

10 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 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. 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-to-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. E-Tree is a rooted multipoint and again replaces services built with legacy technologies. These new connections are defined as PN Rev F October

11 CARRIER ETHERNET 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. 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 PN Rev F October

12 CARRIER ETHERNET 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 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) PN Rev F October

13 CARRIER ETHERNET 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-to-end to ensure the path is up. Using Service OAM an outage can be detected in sub-50ms and the node can move traffic to a backup path. PBB-TE is also gaining interest from Service Providers for certain service types. PN Rev F October

14 CARRIER ETHERNET 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, E-LMI (MEF 16) and Service OAM. 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 Remote Loopback Link Monitoring Remote Failure The first phase of Link OAM session establishment. It identifies devices in the network along with their OAM capabilities. AN OAM entity can put its remote peer into LB mode. This helps the network administrator during installation and troubleshooting. 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). Provides a way of detecting and indicating compromised or downed PN Rev F October

15 CARRIER ETHERNET Indication Polling of MIB Variables links under a variety of conditions. (Raises a flag at the local end, like SONET/SDH) 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. 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 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. 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 PN Rev F October

16 CARRIER ETHERNET 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. 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 PN Rev F October

17 CARRIER ETHERNET 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 C The Ethertype is 88-EE. The source address is the MAC of the sending port. PN Rev F October

18 CARRIER ETHERNET 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 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. Table 1. Possible Status Combinations for a Point-to-Point EVC New Active Not Active X X X X X X PN Rev F October

19 CARRIER ETHERNET Table 2. Possible Status Combinations for a Multipoint-to-Multipoint EVC New Active Not Active Partially Active X X X X X X X X X Information elements carried in the Status message for each Report Type include: Table 3. Possible Report Type Element for each Information Element 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 X X CE-VLAN ID/EVC MAP X X PN Rev F October

20 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 Rev F October

21

22 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 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 per-packet measurement Newer attributes such as Frame Delay Variation (frame jitter) is not included PN Rev F October

23 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 E-LINE, 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 Rev F October

24 CARRIER ETHERNET MEF 10.1 defines three types of bandwidth profiles including: port-based, port/vlan-based, Port/VLAN/CoS-based. These are covered in Y 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 Rev F October

25 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 Rev F October

26 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 end-to-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. 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 Rev F October

27

28 Introduction to CE2.0 Introduction to CE2.0 In 2012, Metro Ethernet Forum launched Carrier Ethernet 2.0, a new generation of Carrier Ethernet. CE 2.0 greatly expands from 3 services in CE 1.0 to 8 services, 2 of each respectively in E-Line, E-LAN, E-Tree and E-Access. It defines 3 powerful features: Industry's first standardized Multi-CoS, Interconnect, and Manageability. Multi-CoS Carrier Ethernet 2.0 multiple classes of service allow network optimization to fit a wide range of customer application requirements Carrier Ethernet 2.0 standardized classes of service are associated with MEF-defined performance objectives and performance tiers Managed Carrier Ethernet 2.0 Service OAM enables subscribers and service providers to check the continuity of an EVC across the entire network, to trace the path of a service or to ping a target MEP or configured MIP, for subscriber and test MEGs Carrier Ethernet 2.0 extends traffic management to include both ingress and egress bandwidth profile capabilities Carrier Ethernet 2.0 specifies standard granularities for per UNI, per EVC and per class of service bandwidth profiles to tightly fit customer bandwidth requirements Interconnected Carrier Ethernet 2.0 E-Access Services allow service providers to reach out-of-franchise customer locations and deliver port-based and VLAN-based services PN Rev F October

29 Introduction to CE2.0 Carrier Ethernet 2.0 Services CE2.0 defines 8 services, 2 of each respectively in E-Line, E-LAN, E-Tree and E-Access. E-Line Service Type Carrier Ethernet 2.0 EPL and EVPL services as defined in MEF 6.1 can be used to create a broad range of point-to-point services. PN Rev F October

30 Introduction to CE2.0 A Carrier Ethernet 2.0 EPL service uses dedicated UNIs and provides a high degree of transparency, such that Service Frames are identical at both the source and destination UNIs. All-to-one bundling at the UNIs minimizes the coordination between the Subscriber and Service Provider on the definition of the CE-VLAN ID/EVC Map at each UNI. A Carrier Ethernet 2.0 EVPL service allows for service multiplexing and bundling enabling the support of multiple EVCs at the UNI and the mapping of more than one CE-VLAN ID per EVC. E-LAN Service Type Carrier Ethernet 2.0 EP-LAN and EVP-LAN services as defined in MEF 6.1 can be used to create a broad range of multipoint-to-multipoint services. A Carrier Ethernet 2.0 EP-LAN service uses dedicated UNIs and provides a high degree of transparency such that Service Frames are identical at both the source and destination UNIs. All-to-one bundling at the UNIs minimizes the coordination between the Subscriber and Service Provider on the definition of the CE-VLAN ID/EVC Map at each UNI. A Carrier Ethernet 2.0 EVP-LAN service allows for service multiplexing and bundling enabling the support of multiple EVCs at the UNI and the mapping of more than one CE- VLAN ID per EVC. E-Tree Service Type Carrier Ethernet 2.0 EP-Tree and EVP-Tree services as defined in MEF 6.1 can be used to create a broad range of rooted-multipoint services. A Carrier Ethernet 2.0 EP-Tree service uses dedicated root and leaf UNIs and provides a high degree of transparency such that Service Frames are identical at both the source and destination UNIs. All-to-one bundling at the UNIs minimizes the coordination between the Subscriber and Service Provider on the definition of the CE-VLAN ID/EVC Map at each UNI. PN Rev F October

31 Introduction to CE2.0 A Carrier Ethernet 2.0 EVP-Tree service uses root and leaf UNIs and allows for service multiplexing and bundling enabling the support of multiple EVCs at the UNI and the mapping of more than one CE-VLAN ID per EVC. E-Access Service Type Carrier Ethernet 2.0 Access EPL and Access EVPL services as defined in MEF 33 can be used to create a broad range of access services. A Carrier Ethernet 2.0 Access EPL service interconnects a dedicated UNI and an ENNI. It provides a high degree of transparency such that Service Frames are delivered unchanged at the ENNI with the addition of an S-VLAN tag and the ENNI Frames are delivered unchanged at the UNI except for the removal of the S-VLAN tag. A Carrier Ethernet 2.0 Access EVPL service uses a UNI that can support multiple service instances. The Operator and Service Provider coordinate on defining the OVC End Point Map for each OVC at the UNI and for the value of the S-VLAN ID that maps to each OVC End Point at the ENNI. Access EVPL provides a high degree of transparency such that Service Frames are delivered unchanged at the ENNI with the addition of an S VLAN tag and the ENNI Frames are delivered unchanged at the UNI except for the removal of the S-VLAN tag. CE2.0 Certification The MEF CE 2.0 Certification Program is Introduced in Jan, 2013 and already has more than 50 certified devices from 20+ manufacturers. It enables network equipment manufacturers and Service providers to certify that their Carrier Ethernet products comply with the relevant MEF specifications, accelerates and ensure successful worldwide deployment of Carrier Ethernet services. Rapid adoption has been driven by implementation of CE 2.0 services in the market. PN Rev F October

32 Introduction to CE2.0 The Carrier Ethernet 2.0 Certification Test Plan is composed of the following two parts: Part 1: Carrier Ethernet 2.0 Services Attributes.This is the first part of the Carrier Ethernet 2.0 Test Plan. It defines Services Attributes test cases for Carrier Ethernet 2.0 Services. Part 2: Carrier Ethernet 2.0 Traffic Management. This is the second part of the Carrier Ethernet 2.0 Test Plan. It defines traffic management test cases for Carrier Ethernet 2.0 Services: PN Rev F October

33

34 Testing Provider Bridges (802.1 ad) and Provider Backbone Bridges (802.1 ah) 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 ad 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 Rev F October

35 Testing Provider Bridges (802.1 ad) and Provider Backbone Bridges (802.1 ah) 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 15-Frame Format of Provider Backbone Bridges (802.1ah) 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. PN Rev F October

36 Testing Provider Bridges (802.1 ad) and Provider Backbone Bridges (802.1 ah) 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 Rev F October

37

38 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 IxNetwork Port 3 is configured with S-VLAN 200 and C-VID In this test setup, the Provider Bridge DUT will be receiving Q-in-Q traffic from Ixia-emulated 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 ad Backbone Bridge Test Setup PN Rev F October

39 TEST CASE: Provider Bridges 802.1ad E-Line Services Step-by-Step Instructions Add ports to the test setup. Figure 17-Port Selection 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 18-Traffic Configuration Click the Advanced Wizard icon to start the traffic configuration. Figure 19-Advanced Traffic Wizard Selection PN Rev F October

40 TEST CASE: Provider Bridges 802.1ad E-Line Services 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 20-Traffic Type and Endpoint Selection In the Packet/QoS step, there is a packet editor view. Highlight the Ethernet II, then right-click select Append Protocol. Figure 21-Append Protocol In the Select Protocol pop-up window, select VLAN and press OK. Figure 22-Selecting Protocol to Append PN Rev F October

41 TEST CASE: Provider Bridges 802.1ad E-Line Services Select the VLAN header added in step 6 above, and select Append Protocol. Add another VLAN protocol header. Figure 23-Appending VLAN Header Click the icon for expanding the frame protocols tree node. Figure 24-Expanding Protocols Then, in the protocol tree, configure 4093 MAC Addresses for Destination and Source MAC Addresses. Figure 25-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 0, page 35). PN Rev F October

42 TEST CASE: Provider Bridges 802.1ad E-Line Services Highlight the Ethernet-Type and select Edit. Figure 26-Editing Ethernet-Type Value Enter a single value of 88a8 to change the Ether-type from 0x8100 to 0x88A8. Figure 27-Entering Ethernet-Type Value Now move to the first VLAN header and configure its VLAN-ID (S-TAG) to have the value 100. Figure 28-Configuring Outer VLAN-ID Value PN Rev F October

43 TEST CASE: Provider Bridges 802.1ad E-Line Services Moving onto the next VLAN header, configure an incrementing range of VLAN-IDs that will configure the C-TAG values from 2 to 4094 for a total of 4093 C-TAGs. Figure 29-Configuring Inner VLAN-ID Value The above steps will result in the frames being generated as shown in Figure 30. Figure 30-Resultant Frame Created Click the icon in the left pane. PN Rev F October

44 TEST CASE: Provider Bridges 802.1ad E-Line Services Under Flow Group Transmission Mode, select Fixed Packet Count and enter 5000 in the Stop After packets field. Click Flow Tracking in the left pane. Figure 31-Setting Fixed Number of Packets to be Transmitted Under Track Flows by, you will see tracking already set on the fields for which tracking was enabled earlier (step 0 page 32). 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. Click at the bottom on the Advanced Traffic Wizard window. Apply traffic by clicking the traffic apply button Switch view to the Statistics page by clicking Traffic Statistics window in the left pane. This will display the Click the start traffic button. Pressing this button should send 5000 packets that were configured in step 15 above. We will confirm this by looking at the statistics. Click Traffic Item Statistics. This will bring the statistics for the Traffic Item PB we configured through the Advanced Traffic Wizard. Figure 32-Selecting Traffic Item Statistics Now start traffic by clicking the start traffic icon PN Rev F October

45 TEST CASE: Provider Bridges 802.1ad E-Line Services Notice that 5000 frames were transmitted and all of them were received with no packet loss. Figure 33-Traffic Item statistics To confirm that the traffic was sent from the correct MAC Address source, right-click the Traffic Item PB and select Drill Down per Ethernet II: Source MAC Address. Figure 34-Drilling down to View Statistics by Source MAC addresses 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 35-Per-Session Statistics Arranged by Source MAC Addresses PN Rev F October

46 TEST CASE: Provider Bridges 802.1ad E-Line Services 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 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 100 % frame loss on Receive port 0% frame loss on incorrect Receive port (Port 3 in this setup) Description 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. 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 PN Rev F October

47 TEST CASE: Provider Bridges 802.1ad E-Line Services 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 DU PN Rev F October

48 TEST CASE: Provider Backbone Bridges 802.1ah E-LAN Services Test Case: Provider Backbone 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 Rev F October

49 TEST CASE: Provider Backbone 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 ah Backbone Bridge Test Setup PN Rev F October

50 TEST CASE: Provider Backbone Bridges 802.1ah E-LAN Services Step-by-Step Instructions Add ports to the test setup. Figure 37-Selecting Ports 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 Click the Advanced Wizard icon to start the traffic configuration. Figure 39-Selecting Advanced Traffic Wizard PN Rev F October

51 TEST CASE: Provider Backbone Bridges 802.1ah E-LAN Services 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 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 In the Select Protocol pop-up window, select MAC in MAC and press OK. Figure 42-Selecting MAC-in-MAC PN Rev F October

52 TEST CASE: Provider Backbone Bridges 802.1ah E-LAN Services The packet format will change as shown in Figure 43. Figure 43-MAC-in-MAC Frame Click the icon for expanding the protocols tree node. Figure 44-Expanding Frame Tree Protocols In the protocol tree, configure 4093 MAC Addresses for Destination and Source MAC Addresses. Figure 45-Configuring Backbone Source and Destination MAC Addresses 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. The Tracking option provides the ability to get statistics for the field selected. PN Rev F October

53 TEST CASE: Provider Backbone Bridges 802.1ah E-LAN Services Configure I-SID value (1 through 10) in the I-Tag branch. Figure 47-Configuring I-SID Values and Enabling Tracking PN Rev F October

54 TEST CASE: Provider Backbone Bridges 802.1ah E-LAN Services 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 Click the in the left pane. Under Flow Group Transmission Mode, select Fixed Packet Count and enter 6000 in the Stop After packets field. Click on Flow Tracking in the left pane. Figure 49-Configuring Fixed Number of Frames to Transmit PN Rev F October

55 TEST CASE: Provider Backbone Bridges 802.1ah E-LAN Services Under Track Flows by, you will see tracking already set on the fields for which tracking was enabled in the previous steps. Click the button on the top right. icon in the left pane and then click the View Flow Groups/Packets This will result in all the 4093 generated packets to be listed: Figure 50-Previewing the generated frames Click on at the bottom on Advanced Traffic Wizard window. This will generate the Traffic Item. Apply Traffic Item to the ports by clicking the traffic apply button Switch view to the Statistics page by clicking the will display the Traffic Statistics window. button in the left hand pane. This Click the start traffic button. Pressing this button should send 6000 packets that we configured in step 13, above. We will confirm this by looking at the statistics. PN Rev F October

56 TEST CASE: Provider Backbone Bridges 802.1ah E-LAN Services Click on Traffic Item Statistics. This will display the statistics for the Traffic Item PBB we configured through Advanced Traffic Wizard. Now start traffic. Figure 51-Selecting Traffic Item Statistics Notice that 6000 frames were transmitted and half of them were received with 50% packet loss. Figure 52-Traffic Item Statistics 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 Rev F October

57 TEST CASE: Provider Backbone Bridges 802.1ah E-LAN Services 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 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 Rev F October

58 TEST CASE: Provider Backbone Bridges 802.1ah E-LAN Services 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 The larger the number of ports, the more states that need to be maintained at the DUT to associate ports with TAG values. PN Rev F October

59 TEST CASE: Provider Backbone Bridges 802.1ah E-LAN Services Troubleshooting and diagnostics Problem 100 % frame loss on Receive port 0% frame loss on incorrect Receive port (Port 3 in this setup) Description 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 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. 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 Rev F October

60 ETHERNET/LINK OAM (802.3ah) 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. 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 PN Rev F October

61 ETHERNET/LINK OAM (802.3ah) Functional Verification 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 reset 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 thresholdcrossing 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 Rev F October

62 Test Case: Ethernet/Link OAM Discovery Functional Verification 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 re-start of the OAM discovery process. Figure 58-Information TLV used for Discovery PN Rev F October

63 Test Case: Ethernet/Link OAM Discovery Functional Verification 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. 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 Figure 59-Information TLV Expanded 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 Rev F October

64 Test Case: Ethernet/Link OAM Discovery Functional Verification 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. Figure 61-Launch Link-OAM Protocol Wizard PN Rev F October

65 Test Case: Ethernet/Link OAM Discovery Functional Verification 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. 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 Rev F October

66 Test Case: Ethernet/Link OAM Discovery Functional Verification 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 Rev F October

67 Test Case: Ethernet/Link OAM Discovery Functional Verification 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 Rev F October

68 Test Case: Ethernet/Link OAM Discovery Functional Verification 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 protocol-specific changes and to observe DUT behavior. You can achieve much functional verification using this method. Below are a few examples to show you how to achieve specific test objectives. PN Rev F October

69 Test Case: Ethernet/Link OAM Discovery Functional Verification 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 Rev F October

70 Test Case: Ethernet/Link OAM Discovery Functional Verification 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 Rev F October

71 Test Case: Ethernet/Link OAM Discovery Functional Verification 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 Rev F October

72 Test Case: Ethernet/Link OAM Discovery Functional Verification 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 Rev F October

73 Test Case: Ethernet/Link OAM Discovery Functional Verification Figure 73-DUT OAM Statistics PN Rev F October

74 Test Case: Ethernet/Link OAM Discovery Functional Verification 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 Rev F October

75 Test Case: Ethernet/Link OAM Discovery Functional Verification Figure 75-DUT Display of New Capability and Remote Failure Flags 11. 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 Rev F October

76 Test Case: Ethernet/Link OAM Discovery Functional Verification Troubleshooting and diagnostics Problem Cannot display learned info from DUT DUT does not reflect new capability options or new failure indications Description 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. When new options or flags are toggled, it s required to click the Send Updated Parameters button in order to force the on the-fly 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 Rev F October

77

78 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 Rev F October

79 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 Steps 1 to 5 in the Ethernet/Link OAM Discovery test (page 55) can be re-used to set up OAM emulation. They are not repeated here for this test. PN Rev F October

80 Test Case: Ethernet/Link OAM Event Notification 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 Rev F October

81 Test Case: Ethernet/Link OAM Event Notification 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 Rev F October

82 Test Case: Ethernet/Link OAM Event Notification 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 Rev F October

83 Test Case: Ethernet/Link OAM Event Notification 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 Rev F October

84 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 Rev F October

85 Test Case: Ethernet/Link OAM Event Notification Troubleshooting and diagnostics Problem Cannot display learned info from DUT DUT does not reflect new event notification Ixia is not sending Event Notification Description 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. 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 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 Rev F October

86 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 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. 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 Rev F October

87 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 Repeat steps 1 thru 5 in the Ethernet/Link OAM Discovery test (page 55) if needed for a quick emulation setup using the Link-OAM protocol wizard. PN Rev F October

88 Test Case: Ethernet/Link OAM Remote Loopback Configure Ixia as Active mode. Figure 86-Configure Ixia Link-OAM in Active Operation Mode 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 Rev F October

89 Test Case: Ethernet/Link OAM Remote Loopback 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 Rev F October

90 Test Case: Ethernet/Link OAM Remote Loopback Figure 90-DUT Status After Loopback Request PN Rev F October

91 Test Case: Ethernet/Link OAM Remote Loopback 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 Rev F October

92 Test Case: Ethernet/Link OAM Remote Loopback 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 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 Rev F October

93 Test Case: Ethernet/Link OAM Remote Loopback Figure 94-Traffic Statistics Clearly Shows Loopback by DUT 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 Rev F October

94 Test Case: Ethernet/Link OAM Remote Loopback 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 Rev F October

95 Test Case: Ethernet/Link OAM Remote Loopback 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 Rev F October

96 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 Cannot display learned info from DUT DUT won t respond to Ixia loopback reqeust Ixia cannot loopback traffic to DUT Description 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. 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. 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 loopback request. The loopback state can be verified by multiple means including use of data plane traffic. DUT Config Excerpt Interface FastEthernet1/0/1 PN Rev F October

97 Test Case: Ethernet/Link OAM Remote Loopback switchport mode access ethernet oam remote-loopback supported ethernet oam PN Rev F October

98 SERVICE OAM Service OAM Service OAM is defined in IEEE 802.1ag (aka Ethernet CFM) and ITU-T Y 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. Comparing OAM Functionalities Ethernet CFM ITU-T Y.1731 ITU-T Y.1731 (IEEE 802.1ag) OAM Functions for Fault Management Ethernet continuity check (CCM) Ethernet loopback (LBM/LBR) Ethernet link trace (LTM/LTR) MEP Variables including remote defect indication (RDI) OAM functions for Fault Management Ethernet continuity check (ETH-CC) Ethernet loopback (ETH-LB) Ethernet link trace (ETH-LT) 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 (ETH-MCC) Ethernet experimental OAM (ETH-EXP) Ethernet vendor-specific OAM (ETH-VSP) OAM functions for Performance Monitoring Frame loss measurement (ETH-LM) Frame delay measurement (ETH-DM) Throughput measurement PN Rev F October

99 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 Rev F October

100 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. 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. PN Rev F October

101 SERVICE OAM 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 Ixia s IxNetwork supports both standards. See page 2 of the CFM/.1731 protocol wizard to select either protocol. PN Rev F October

102 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 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 Rev F October

103 Test Case: Ethernet CFM Fault Detection with Continuity Check Messages Step-by-Step Instructions 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) 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. 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 Rev F October

104 Optionally: Test Case: Ethernet CFM Fault Detection with Continuity Check Messages Change the Operation Mode to Y 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 for more information on the tree topology. Figure 104-CFM/Y.1731 Protocol Wizard PN Rev F October

105 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. Change the Number of Spoke MEPs per MIP to 4. This will create a topology the same as shown in 0, below. Optionally, configure the Starting MAC address and MEP ID/Step as desired. Figure 105-CFM/Y.1731 Protocol Wizard PN Rev F October

106 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. Change the MD Level ID to 6 as shown in the Setup section of this test case. This number must match the DUT. Change the MD name to MD-Level6 as shown in the Setup section of this test case. 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 Rev F October

107 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. 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. In most cases check the Enable VLAN. This will encapsulate the CFM messages over a VLAN. Choose Single VLAN or Stacked VLAN (QinQ). This will add S-VLANs and C-VLANs respectively. In this case use VLAN 777 Optionally, configure the VLAN Priority. PN Rev F October

108 Test Case: Ethernet CFM Fault Detection with Continuity Check Messages 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 Rev F October

109 Test Case: Ethernet CFM Fault Detection with Continuity Check Messages 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 Rev F October

110 Test Case: Ethernet CFM Fault Detection with Continuity Check Messages 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. Start the CFM Protocol on both ports. PN Rev F October

111 Test Case: Ethernet CFM Fault Detection with Continuity Check Messages 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. 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. Detect the fault using Port1 -> Learned Info -> CCM Database. 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 Rev F October

112 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 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 Rev F October

113 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 Rev F October

114 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 Description Variable 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 Increase MEPs per MIP More Maintenance Domains (MD) Add C-VLANs (QinQ) Enable MAC Ranges and send Traffic 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. Step 5: Increasing the number of Spoke MEPs per MIP. This creates more MEPS. 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. Step 12: This could potentially create 4095 x 4095 unique VLANs per port, increasing the potential number of MEPs and Services. 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 Rev F October

115 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 outof-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 137) to test the SUT at its maximum performance capability before deploying into a real-world Carrier Ethernet Network PN Rev F October

116 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 Rev F October

117 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 Rev F October

118 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. Optionally, Figure 120-Network Impairment view 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 Rev F October

119 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 Rev F October

120 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 Rev F October

121 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 Rev F October

122 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 Rev F October

123 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 Rev F October

124 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 Rev F October

125 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 Create multiple profiles Add multiple classifiers Apply impairments in both link directions Increase Delay Select among different kinds of delay units Apply different delay variations Description You can create up to 32 bidirectional, or 64 unidirectional impairment profiles per impairment port pair. 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. You can select to impair one or both the links. 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. Introduce delay in us, ms or km. 1 km of WAN Link causes a delay of 5 us. 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 PN Rev F October

126 Test Case: Impairment Testing - Drop and Delay CCM Messages Performance Variable Description packets. Apply different packet impairments Apply BER impairment 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 in the Other tab. Optionally, select to correct L2 FCS error, or, drop the packet with L2 FCS errors in the Checksum grid. 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 enabled but impairment statistics are not updated. Ensure that the Apply Impairments icon does not have any error. Make sure that traffic is flowing through the module and the drop rate is not set to 100%. No traffic is flowing through the impairment links. To ensure that traffic is flowing through the impairment modules, disable all the impairment profiles except the default profile, Apply 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. Traffic is not getting impaired though the Apply Impairment icon is not showing any error. 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. 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. Conclusions PN Rev F October

127 Test Case: Impairment Testing - Drop and Delay CCM Messages 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 Rev F October

128 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 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 Ethernet/Service OAM Test Setup PN Rev F October

129 Step-by-Step instructions Test Case: Ethernet CFM Fault Verification Using Loopback Follow Steps 1 through 18 in the Ethernet CFM Verifying fault detection with Continuity Check Messages test (page 94) to setup the Ethernet CFM emulation for use in this test case. Those steps are not repeated here. Create a fault by disabling a MEP on Port2. Note the MEP ID of 6 and the MAC address of Figure 133-Disabling MEP on Port 2 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 Rev F October

130 Test Case: Ethernet CFM Fault Verification Using Loopback 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 Rev F October

131 Test Case: Ethernet CFM Fault Verification Using Loopback 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 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 Rev F October

132 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 Rev F October

133 Test Case: Ethernet CFM Fault Verification Using Loopback 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 Rev F October

134 Test Case: Ethernet CFM Fault Verification Using Loopback 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 Rev F October

135 Test Case: Ethernet CFM Fault Verification Using Loopback Go to the MIPs/MEPs -> Periodic OAM Settings Tab. 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 Figure 140-Ixia Periodic OAM Configuration screen Stop and Restart the Ethernet CFM protocol on the ports where you are configuring Periodic OMA. 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 Rev F October

136 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 107) as a baseline configuration. Control Plane Performance Variables Performance Description Variable 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 Increase MEPs per MIP More Maintenance Domains (MD) Add C-VLANs (QinQ) Enable MAC Ranges and send Traffic 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. Step 5: Increasing the number of Spoke MEPs per MIP. This creates more MEPS. 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. Step 12: This could potentially create 4095 x 4095 unique VLANs per port, increasing the potential number of MEPs and Services. 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 Rev F October

137 Results Analysis Test Case: Ethernet CFM Fault Verification Using Loopback 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 MEPs will not come up Troubleshooting Solution 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 127) to test the DUT at its maximum performance capability before deploying into a real-world Carrier Ethernet Network. PN Rev F October

138 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 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 Rev F October

139 Step-by-Step instructions Test Case: Ethernet CFM - Fault Isolation Using Linktrace Follow Steps 1 through 18 in the Ethernet CFM Verifying fault detection with Continuity Check Messages test (page 94) to setup the Ethernet CFM emulation for use in this test case. Those steps are not repeated here. Create a fault by disabling a MEP on Port2. Note the MEP ID of 6 and the MAC address of Figure 144-Disabling MEP on Port 2 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 Rev F October

140 Test Case: Ethernet CFM - Fault Isolation Using Linktrace 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 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 Rev F October

141 Test Case: Ethernet CFM - Fault Isolation Using Linktrace Now, isolate the fault using Port1 -> Learned Info -> LinkTrace tab. 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 Rev F October

142 Test Case: Ethernet CFM - Fault Isolation Using Linktrace 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 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 Rev F October

143 Test Case: Ethernet CFM - Fault Isolation Using Linktrace 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 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 Rev F October

144 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 Rev F October

145 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: Go to the MIPs/MEPs -> Periodic OAM Settings tab. 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 Figure 152-Ixia Periodic OAM Configuration screen Stop and Restart the Ethernet CFM protocol on the ports you are configuring Periodic OMA. 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 Rev F October

146 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 107) as a baseline configuration. Control Plane Performance Variables Performance Variable Increase Ports Description 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 Increase MEPs per MIP More Maintenance Domains (MD) Add C-VLANs (QinQ) Enable MAC Ranges and send Traffic 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 Step 5: Increasing the number of Spoke MEPs per MIP. This creates more MEPS. 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. Step 12: This could potentially create 4095 x 4095 unique VLANs per port, increasing the potential number of MEPs and Services. 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 Rev F October

147 Test Case: Y Frame Loss Measurement Test 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 137) to test the DUT at its maximum performance capability before deploying into a real-world Carrier Ethernet Network. Test Case: Y Frame Loss Measurement Test Overview Frame Loss Measurement (ETH-LM) allows evaluation of service frame delivery between Maintenance End Points (MEP). It uses counters of received and transmitted service frames between a pair of MEPs to calculate frame loss ratio (as a percentage), which is a ratio of the number of service frames not delivered, divided by the total number of service frames during a time interval. The number of service frames not delivered (frame loss) is the difference between the number of service frames arriving at the ingress MEP and the number of service frames delivered at the egress MEP. PN Rev F October

148 Test Case: Y.1731 Frame Loss Measurement Test ETH-LM is performed by sending frames with ETH-LM information to a peer MEP and similarly receiving frames with ETH-LM information from the peer MEP. It can be performed in two different ways: Dual-ended LM Each MEP, periodically, sends CCM frames to its peer MEP. Each peer MEP terminates the CCM frames and performs near-end and far-end loss measurements using local counters and counter values in the received CCM frames. Single-ended LM A MEP sends LM request (LMM) frames to its peer MEP upon an on-demand administrative trigger. The peer MEP responds with LM reply (LMR) frames. Using counter values in LMR frames and its local counter value, a MEP performs near-end and far-end loss measurements. The following are the counters and formulas used in dual-ended and single-ended frame loss calculations: TxFCl - the value of the local counter for in-profile data frames transmitted toward the peer MEP. RxFCl - the value of the local counter for in-profile data frames received from the peer MEP. tc - the reception time of the current frame. tp - the reception time of the previous frame. Dual-Ended LM Calculation Frame loss far-end = TxFCb[tc] TxFCb[tp] RxFCb[tc] RxFCb[tp] Frame loss near-end = TxFCf[tc] TxFCf[tp] RxFCl[tc] RxFCl[tp] TxFCf - the value of the local counter TxFCl at the time of transmission of the CCM frame. RxFCb - the value of the local counter RxFCl at the time of reception of the last CCM frame from the peer MEP. TxFCb - the value of TxFCf in the last received CCM frame from the peer MEP. Single-Ended LM Calculation Frame lossfar-end = TxFCf[tc] TxFCf[tp] RxFCf[tc] RxFCf[tp] Frame lossnear-end = TxFCb[tc] TxFCb[tp] RxFCl[tc] RxFCl[tp] TxFCf - the value of the local counter TxFCl at the time of LMM frame transmission. RxFCf - the value of local counter RxFCl at the time of LMM frame reception. TxFCb - the value of local counter TxFCl at the time of LMR frame transmission. Frame Loss Ratio and Availability Each MEP performs frame loss measurements, which contribute to unavailable time. A nearend frame loss refers to frame loss associated with ingress data frames. Far-end frame loss refers to frame loss associated with egress data frames. Both near-end and far-end frame loss measurements contribute to near-end severely errored seconds and far end severely errored seconds which together contribute to unavailable time. PN Rev F October

149 Test Case: Y.1731 Frame Loss Measurement Test Objective The objective of this test is to measure frame loss between a pair of MEPs in a Carrier Ethernet network and verify DUT Frame Loss measurement function. Single-ended ETH-LM is used for this test. Setup One Ixia port is used to emulate one MEP behind one MIP. The DUT is also configured with one MIP and 1MEP attached. Ixia s ImpairNet module is used to introduce packet loss situations to verify accurate LM statistics on the DUT. Figure 155: Y.1731 Frame Loss Measurement test topology PN Rev F October

150 Step-by-Step Instructions 1. Configure the DUT Test Case: Y.1731 Frame Loss Measurement Test Y.1731 mode MEG level ID = 0 MEP ID: 2 VLAN ID: Reserve two Ixia ports and a pair of Impairment ports in IxNetwork. Figure 156: Y.1731 Frame Loss Measurement test Reserving ports PN Rev F October

151 Test Case: Y.1731 Frame Loss Measurement Test 3. Click the Add protocols button to open the IxNetwork Protocol Wizards window. Select CFM/Y.1731 and click Run Wizard. Figure 157: Y.1731 Frame Loss Measurement test - CFM/Y.1731 protocol wizard 4. In the screen #1 - Port Selection: Enable the first port and click Next. Figure 158: Y.1731 Frame Loss Measurement test Port selection 5. In the screen #2 Operation Mode: Select Y.1731 mode. Select Hub and Spoke topology type. PN Rev F October

152 Test Case: Y.1731 Frame Loss Measurement Test Leave the rest of settings at default values. Figure 159: Y.1731 Frame Loss Measurement test Operation Mode selection 6. In the screen #3 Topology Type: Leave the settings at default values except for number of MEPs. o 1 MEP per MIP Emulating 1 MEP behind each MIP Figure 160: Y.1731 Frame Loss Measurement test Topology Type settings PN Rev F October

153 Test Case: Y.1731 Frame Loss Measurement Test 7. CFM/Y.1731 Wizard MD/MEG Level: Leave the settings at default values. o Number of MEG: 1 o MEG Level ID: 0 Figure 161: Y.1731 Frame Loss Measurement test MD/MEG Level settings 8. CFM/Y.1731 Wizard MD/MEG Level Assignments (shows MEG Level ID assignment at each level of the topology): Leave the settings at default values. o Topology level 1: 0 MEP (1 MIP); MEG level 0 o Topology level 2: 1 MEP; MEG level 0 Figure 162: Y.1731 Frame Loss Measurement test MD/MEG Level Assignement PN Rev F October

154 Test Case: Y.1731 Frame Loss Measurement Test 9. CFM/Y.1731 Wizard MAC VLAN settings: Enable VLAN with default settings. Configure the same VLAN ID on the DUT. Enable MAC Range for hosts behind MEPs o o This MAC Range is used for the emulated hosts behind MEPs to generate Data traffic Assign a value different from that of MEPs o Leave the number of MAC Ranges and Count at 1. Figure 163: Y.1731 Frame Loss Measurement test MAC VLAN settings 10. CFM/Y.1731 Wizard Name: assign a name to this test configuration, and click the Generate and Overwrite Existing Configuration to apply the configurations defined in this test. Figure 164: Y.1731 Frame Loss Measurement test Generate configuration PN Rev F October

155 Test Case: Y.1731 Frame Loss Measurement Test 11. Review the configuration by validating the MIP (1) and MEP (1) created. Under Protocols -> CFM/Y.1731/PBB-TE, click MD/MEG Levels tab and check MD/MEG level (should be 0). Under MIP/MEPs tab, verify configuration of 1 MIP with 1 MEP behind it with appropriate MIP and MEP IDs. Figure 165: Y.1731 Frame Loss Measurement test CFM/Y.1731 configuration GUI view Take note of MAC address ranges as MIPs are also allocated unique addresses. PN Rev F October

156 Test Case: Y.1731 Frame Loss Measurement Test 12. Click the Loss Measurement tab (at the bottom). Configure the simulated counter in CCM/LMM message as follows: Enable LM Counter Update for the configured MEP (row 2) CCM/LMM TxFCf = 1 CCM/LMM TxFCf Step /100msec =10 LMR RxFCf = 1 LMR RxFCf step/100 msec = 10 This configuration simulates TxFCf counter of sending data traffic at the rate of 100 packets per second and RxFCf counter of receiving data traffic at the rate of 100 packets per second. Note: These counters are simulated counters. When CFM/Y.1731 protocol is started, the TxFCf and RxFCf counters are started with the initial value and are incremented by value of Step/100msec. These counters are not linked to Data plan traffic. To synchronize these counters with traffic, you must configure the counter increment, such that it is at the same rate as Data plane traffic rate. Figure 166: Y.1731 Frame Loss Measurement test CFM/Y.1731 configuration GUI Loss Measurement view 13. Setup static interface for the traffic destination port MAC Address: B VLAN ID: 10 Figure 167: Y.1731 Frame Loss Measurement test Traffic Wizard - Endpoints PN Rev F October

157 Test Case: Y.1731 Frame Loss Measurement Test 14. Click button and select Advanced L2-3 Traffic Wizard to generate data traffic (from emulated hosts behind MEPs). At Endpoints page, select source and destination endpoints as below to create bi-directional traffic between hosts behind Ixia emulated MEP and DUT MEP. a) Set the traffic type to Ethernet/VLAN. b) Enable Bi-Directional traffic generation checkbox. c) Select CFM/Y.1731 interface in the source port. d) Select Static interface in the destination port. e) Click the button to add an EndPoint Set. PN Rev F October

158 Test Case: Y.1731 Frame Loss Measurement Test Figure 168: Y.1731 Frame Loss Measurement test Traffic Wizard - Endpoints PN Rev F October

159 Test Case: Y.1731 Frame Loss Measurement Test In the Rate Setup page, set the rate to 100 frames per second. This is the same rate configured in CFM/Y.1731 loss management sub-tab. Figure 169: Y.1731 Frame Loss Measurement test Traffic Wizard Rate Setup In the Flow Tracking page, enable tracking by Traffic Item. Figure 170: Y.1731 Frame Loss Measurement test Flow Tracking Setup Complete the traffic wizard with default settings and click Finish to create the traffic item. PN Rev F October

160 Test Case: Y.1731 Frame Loss Measurement Test 15. Start Traffic and then CFM Protocols. The operation must be performed as fast as possible, so that simulated Loss Measurement counters are as close to real counter as possible. Add CFM Aggregated Statistics in the Statistics view and verify correct number of MEP/MIP emulations running on the port. Figure 171: Y.1731 Frame Loss Measurement test CFM Aggregated Statistics 16. In the left panel protocol tree, expand CFM/Y.1731/PBB-TE node to view the Learned Info page. Click the button to retrieve learned CCM database. Verify that DUT MEP is learned in CCM No Defect Database Figure 172: Y.1731 Frame Loss Measurement test CFM/Y.1731 Port Learned Info view PN Rev F October

161 Test Case: Y.1731 Frame Loss Measurement Test 17. Go to learned info -> Loss Measurement. Click Start Loss Measurement button(on the top ribbon) to send ETH-LM frames (LMM for single-ended). Verify the measured Near End Loss and Far End Loss. Ensure that there is no loss. Figure 173: Y.1731 Frame Loss Measurement test Check Loss Measurement Statistics 18. In the Impairment configuration, add two profiles by clicking twice on located on the top ribbon. Configure the profiles as follows (refer to the figures below for configuration steps): Profile 1 Match traffic to Ixia MEP : Profile Name: Far End Traffic Enable 20% Set classifier to packets with SA: A Enable PN Rev F October

162 Test Case: Y.1731 Frame Loss Measurement Test Profile 2 Match traffic to DUT MEP Profile Name: Near End Traffic Enable 30% Set classifier to packets with SA: B Enable Figure 174: Configuration of packet drop impairment PN Rev F October

163 Test Case: Y.1731 Frame Loss Measurement Test 19. Click to apply, and then verify loss on the flow statistics. Figure 175: Flow Statistics Check % Loss Statistics In the CFM protocol interface Learned Info, click Start Loss Measurement (on the top ribbon) and verify the measured Near End Loss (30%) and Far End Loss (20%). Figure 176: Y.1731 Frame Loss Measurement test Check Loss Measurement Statistics PN Rev F October

164 Test Case: Y.1731 Frame Loss Measurement Test Test Variables You can manipulate the following parameters for separate Y.1731 Frame Loss Measurement test cases. They all use the test case developed thus far as a baseline. Performance Variable CCM/LMM and LMR message rate Description Changing the CCM/LMM rates and the expected LMR rate on each MEP under Protocols>CFM/Y.1731/PBB-TE MIP/MEPs settings. Number of MEPs Number of Emulated Hosts behind each MEP Negative testing Number of MEPs behind each MIP Assigning multiple MAC address ranges for emulated hosts behind each MEP Using impairment to test thresholds and corner test cases for the delayed and dropped CFM packets Results Analysis Use the IxNetwork CFM/Y.1731 Learned Info to verify control plane message exchange and LM statistics under normal and impaired conditions. Verify the results against the DUT and the expected statistics. Loss Measurements are based on the calculations done the data obtained from LMM and LMR messages: Frame lossfar-end = TxFCb[tc] TxFCb[tp] RxFCb[tc] RxFCb[tp] Frame lossnear-end = TxFCf[tc] TxFCf[tp] RxFCl[tc] RxFCl[tp] Below are samples of LMM and LMR decoded messages with the counter values passed on. Figure 177: Decoded LMM PN Rev F October

165 Test Case: Y.1731 Frame Loss Measurement Test Figure 178: Decoded LMR Conclusions The ETH-LM test performed using LMM/LMR message validates that DUT response LMM messages with LMR messages and include proper counters for loss measurement calculation. The LMM should also be triggered from DUT side to validate DUT Loss measurement calculation. PN Rev F October

166 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 UNI ID: UNI_1 EVCs VLAN ID EVC_1 1 EVC_2 2 EVC_3 3 EVC_4 4 EVC_5 5 PN Rev F October

167 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: VLAN interfaces are also configured: 2. Click Add Protocols icon from the toolbar, select the E-LMI Wizard, and click the Run Wizard button: PN Rev F October

168 Test Case: E-LMI Testing a Device as a Customer Edge (UNI-C) 3. Select the UNI-N check box and click Next: Note: You may skip configuring Screen Click Next. PN Rev F October

169 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. PN Rev F October

170 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. PN Rev F October

171 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. PN Rev F October

172 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. PN Rev F October

173 9. Click Close. Test Case: E-LMI Testing a Device as a Customer Edge (UNI-C) 10. Navigate to the E-LMI node, and use the tabs to validate the E-LMI configuration: PN Rev F October

174 Test Case: E-LMI Testing a Device as a Customer Edge (UNI-C) PN Rev F October

175 Test Case: E-LMI Testing a Device as a Customer Edge (UNI-C) 11. Click the ELMI icon to start the protocol. 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 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. PN Rev F October

176 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: PN Rev F October

177 Test Variables Test Case: E-LMI Testing a Device as a Customer Edge (UNI-C) 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 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 PN Rev F October

178 Test Case: E-LMI Testing a Device as a Customer Edge (UNI-C) 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. 2. The packet count will increment while capturing. To view the real-time decode, click Packet Count. PN Rev F October

179 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 ah 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 Rev F October

180 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-toend 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-to-end 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. 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. PN Rev F October

181 Test Case: SLA Configuration and Performance Testing per-evc Using Y.1564 Service Name Service 1 Service 2 VLAN ID CIR EIR Maximum Frame Delay 10 8 Mbps 2 Mbps Mbps 4 Mbps Acceptable Frame Loss (frames) 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.1564-Service Activation Measurement Wizard and click Next. 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 PN Rev F October

182 Test Case: SLA Configuration and Performance Testing per-evc Using Y 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 Rev F October

183 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. PN Rev F October

184 Test Case: SLA Configuration and Performance Testing per-evc Using Y 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 PN Rev F October

185 Test Case: SLA Configuration and Performance Testing per-evc Using Y 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 PN Rev F October

186 Test Case: SLA Configuration and Performance Testing per-evc Using Y On the Traffic Options Screen; a. Change the Frequency of the Learning Frames (optional). Keep the default settings for the other fields. 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. g. Set Test Algorithm to Service Performance Test. This will run all services included in this wizard, simultaneously, at CIR rates PN Rev F October

187 Test Case: SLA Configuration and Performance Testing per-evc Using Y.1564 h. Enable the CBS/EBS test to run right after the Service Configuration or Service Performance test. 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. PN Rev F October

188 Test Case: SLA Configuration and Performance Testing per-evc Using Y 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 11. Navigate to QuickTests -> Y.1564 Configuration -> Start button, and start the test. PN Rev F October

189 Test Case: SLA Configuration and Performance Testing per-evc Using Y (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 Rev F October

190 Test Case: SLA Configuration and Performance Testing per-evc Using Y 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. PN Rev F October

191 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. 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 realworld environment. PN Rev F October

192 Test Case: SLA Configuration and Performance Testing per-evc Using Y Close the Data Miner window. 15. Click QuickTests, and double-click on Y.1564 Configuration.. PN Rev F October

193 Test Case: SLA Configuration and Performance Testing per-evc Using Y 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. 17. (Optional) Change the Name of the QuickTest to Y Performance PN Rev F October

194 Test Case: SLA Configuration and Performance Testing per-evc Using Y Navigate to QuickTests -> Y.1564 Performance -> Start to start the test. PN Rev F October

195 Test Case: SLA Configuration and Performance Testing per-evc Using Y (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. PN Rev F October

196 Test Case: SLA Configuration and Performance Testing per-evc Using Y 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. PN Rev F October

197 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. PN Rev F October

198 Test Case: SLA Configuration and Performance Testing per-evc Using Y (Optional) Click the Generate Report button at the top of the Data Miner Window to generate a PDF Report of this test run. 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 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 PN Rev F October

199 Test Case: SLA Configuration and Performance Testing per-evc Using Y.1564 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. 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 PN Rev F October

200 Test Case: SLA Configuration and Performance Testing per-evc Using Y.1564 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 Rev F October

201

202 Testing CE2.0 Testing CE2.0 The creation of Carrier Ethernet 2.0 E-Line, E-LAN and E-Tree services as defined in MEF 6.1 and E-Access services as defined in MEF 33 requires different combinations of service attributes and performance attributes. To assess compliance of each service independently, all the attributes defining the specific service must be verified. IxANVL CE2.0 test suite verifies the conformance of Carrier Ethernet 2.0 services based on MEF Carrier Ethernet 2.0 Certification Test Plan. It offers an automated test cases library and is a cost effective tool to simultaneously reduce time-to-market and product errors. IxANVL CE 2.0 test suite can help NEM and Service provider to validate CE2.0 conformance and prepare for CE2.0 certification test. In addition to CE 2.0 conformance validation, IxNetwork offers capabilities to characterize CE2.0 service performance, mixed services testing, OAM scale and performance testing, as well as Ad hoc test and troubleshooting. IxNetwork s Advanced traffic generation, along with innovated multi-fields tracking and drilldown feature, provides manual, but flexible way to validate various service attributes and performance attributes. The following sections demonstrate how to test CE 2.0 using IxANVL. Same test cases are also demonstrated using IxNetwork. Sample test cases for ELINE service attributes and Traffic management are described in details. PN Rev F October

203

204 Test Case: ELINE Service Attribute NON-LOOPING FRAME DELIVERY Test Case: ELINE Service Attribute - NON-LOOPING FRAME DELIVERY Overview ELINE service is a point-to-point Ethernet service that connects exactly 2 UNIs. Those 2 UNIs can communicate only with each other. An Ingress Service Frame that is mapped to the EVC can be delivered to one or more of the UNIs in the EVC other than the ingress UNI. It is never looped back to the ingress interface. Objective Determine ingress Service Frames that are mapped to the EVC can be delivered to the UNIs in the EVC other than the ingress UNI. It MUST NOT be delivered back to the ingress UNI. Setup Two Ixia ports are connected to DUT. One E-LINE EVC is configured on DUT to associate 2 UNI connected to 2 Ixia ports. All CE-VLAN IDs are mapped to the EVC. PN Rev F October

205 Test Case: ELINE Service Attribute NON-LOOPING FRAME DELIVERY Step-by-Step Instructions Creating a New Test Instance 1. In the Setup -> Test Suite panel, expand Metro Ethernet Suite and select CE2.0. Right-click to create a new test instance and name it. Your new test instance is created and is listed in the Config sub-panel. Configure IxANVL GUI 2. In the Test Configuration -> Configuration window, configure Network Interface and DUT Automation. Fill the DUT Automation section when you want to configure the DUT using script. By default, sample expect script for a device is available with the installer. You can import the default configuration for CE2.0 by clicking the Import button. It contains the default configuration entries and you must update the interface details based on their configuration. PN Rev F October

206 Test Case: ELINE Service Attribute NON-LOOPING FRAME DELIVERY 3. Select the configuration file for CE2.0. The location is C:\IxANVL\engine\DocUser\anvlce2.cfg 4. Use the VNIC interface in this test. Click the Browse button in the Interface field to open Interface Selector window. 5. Click the Remote Interfaces tab and add Ixia chassis. Enter the name or IP address of the chassis in the Chassis Name field. PN Rev F October

207 Test Case: ELINE Service Attribute NON-LOOPING FRAME DELIVERY 6. IxANVL locates the chassis, then retrieves and displays its configuration. You can see the available ports in the chassis. 7. The virtual network interface designation comprises the following elements: v:<chassis IP address>;<card number>;<port number>. This port can be used for the CE2.0 testing. Configuring the Device Under Test An ANVL test case requires special configuration of the DUT. When ANVL test starts, it pauses for DUT configuration and prompts to configure the DUT. To automate such configuration for unattended testing, specify the required DUT configuration in parameter values and in command script files such as Expect script files. PN Rev F October

208 Test Case: ELINE Service Attribute NON-LOOPING FRAME DELIVERY 8. Go to Test Configuration -> Parameter window. Click the Import button and browse pre-defined CE2.0 IxANVL parameter file, if you prefer to use default provided values. You can also change the parameters based on your test requirement. PN Rev F October

209 Test Case: ELINE Service Attribute NON-LOOPING FRAME DELIVERY 9. Update the configurable entries after importing the default configuration and default parameter file. These are the configurable entries based on the configuration and parameter file. PN Rev F October

210 Test Case: ELINE Service Attribute NON-LOOPING FRAME DELIVERY Run the tests 1. At Test Configuration -> Test Cases window, select Test case 1.1 ~1.4 for ELINE EPL Service Non-looping Frame Delivery. 2. Click the Start button at top manual. Selected test cases will run at one time, sequentially. 4. ANVL GUI automatically navigates to Test Progress -> Log window. 5. Test 1.1 for Non-looping broadcast frame perform following test. Test 1.2 ~ 1.4 are similar except offered frame to be Multicast, Unicast, Unknown DA, respectively. Configure EPL service in DUT between DIface-0 and DIface-1 Send 10 Ethernet Service Frames to DUT through <DIface-0> with Destination Address set to <BROADCAST-MAC-ADDR> Check that the Ethernet frames are not looped back on DIface-0 Send 10 Ethernet Service Frames to DUT through <DIface-1> with Destination Address set to <BROADCAST-MAC-ADDR> Check that the Ethernet frames are not looped back on DIface-1 PN Rev F October

211 Test Case: ELINE Service Attribute NON-LOOPING FRAME DELIVERY 6. While the test case is executed, the log displays the packet sent, received. Sending Ethernet Frame from 00:04:03:03:03:03 to FF:FF:FF:FF:FF:FF P> 0.0;0;1;802.2 (CNTL = 0x05);FF:FF:FF:FF:FF:FF;00:04:03:03:03:03; ; : ---- Ethernet Header : 802.3: Destination = FF:FF:FF:FF:FF:FF 802.3: Source = 00:04:03:03:03: : 802.3: ---- VLAN Tag Header : TPID = 802.1Q 802.3: user_priority = : CFI = False 802.3: VID = 11 Now ANVL will be waiting for the packet on DIface-0 to check, if it is received on the interface. After each packet is sent from DIface-0, ANVL checks, if the packet is looped back. The test log displays, if the packet is received. <TESTER-1> correctly did not receive Ethernet Service Frames from <DIface-0> Once the test run is complete, the test result is displayed. PN Rev F October

212 Test Case: ELINE Service Attribute NON-LOOPING FRAME DELIVERY Results Analysis The color of the checkbox adjacent to the test case indicates the test result: A red checkbox indicates that the test has failed. An orange checkbox indicates that the test was inconclusive. A green checkbox indicates that the test has executed successfully. Troubleshooting and diagnostics Packet Decode To display the packet decode view, click the Packet Decode tab in the Log page, or click Packet Decode in the Test Configuration tree. Ladder Diagram To view the Ladder Diagram of the executed test, click the Ladder Diagram tab in the Log page, or click Ladder Diagram in the Test Configuration. PN Rev F October

213 Conclusions Test Case: ELINE Service Attribute NON-LOOPING FRAME DELIVERY For all 4 different offered frames types, no packet is detected to be looped back to ingress UNI. DUT properly implemented Non-looping frame requirement for CE2.0 ELINE EPL Service. PN Rev F October

214 Test Case: ELINE Traffic Management ONE-WAY FRAME LOSS RATIO PERFORMANCE Test Case: ELINE Traffic Management - ONE-WAY FRAME LOSS RATIO PERFORMANCE Overview The EVC Related Performance Service Attributes specify the Service Frame delivery performance. Four performance attributes are defined in MEF10.2. These are Frame Delay Performance, Inter-Frame Delay Variation Performance, Frame Loss Ratio Performance, and Availability Performance. One-Way Frame Loss Ratio Performance from the ingress UNI to the egress UNI is calculated for a time interval T, as the ratio, expressed as a percentage, of the number of ingress Qualified Frames not delivered at the egress UNI divided by the total number of ingress Qualified Frames that should have been delivered. Note: For traffic related test cases in CE2.0 test suite, Ixia load module is required. We need to use VNIC for the traffic test cases. Objective Determine One-way Frame Loss Ratio Performance of ELINE service for both EPL service and EVPL Service under test. verify that for all Qualified Service Frames associated with a particular CoS Label, that arrive at the UNI during a time interval T, the One-Way Frame Loss Ratio Performance is less than or equal to the One-Way Frame Loss Ratio Performance Objective specified in MEF 23.1 Table 6 for Metro PT CPOs, Table 7 for Regional PT CPOs, Table 8 for Continental PT CPOs, or Table 9 for Global PT CPOs, where the table selection is dependent on the applicable PT. PN Rev F October

215 Test Case: ELINE Traffic Management ONE-WAY FRAME LOSS RATIO PERFORMANCE Setup Two Pairs of Ixia ports are connected to DUT. One pair is connected to 2 UNIs on DUT for EPL services and the other pair is connected to 2 UNIs on DUT for EVPLS services. Step-by-Step Instructions Creating a New Test Instance 1. In the Setup - Test Suite panel, expand Metro Ethernet Suite and select CE2.0. Right-click to create a new test instance and name it. Your new test instance is created and is listed in the Config sub-panel. PN Rev F October

216 Test Case: ELINE Traffic Management ONE-WAY FRAME LOSS RATIO PERFORMANCE Configure IxANVL GUI 2. In the Test Configuration -> Configuration page, configure Network Interface and DUT Automation. Fill the DUT Automation section when you want to configure the DUT using the script. By default, sample expect script for a device is available with the installer. You can import the default configuration for CE2.0 by clicking the Import button. It contains the default configuration entries and you must update the interface details based on their configuration. 3. Select the configuration file for CE2.0. The location is C:\IxANVL\engine\DocUser\anvlce2.cfg 4. Use the VNIC interface in this test. Click the Browse button in the Interface field to open the Interface Selector window. PN Rev F October

217 Test Case: ELINE Traffic Management ONE-WAY FRAME LOSS RATIO PERFORMANCE 5. Click the Remote Interfaces tab and add Ixia chassis. Enter the name or IP address of the chassis in the Chassis Name field. 6. IxANVL locates the chassis, then retrieves and displays its configuration. You can see the available ports in the chassis. 7. The virtual network interface designation comprises the following elements: v:<chassis IP address>;<card number>;<port number>. This port can be used for the CE2.0 testing Configuring the Device Under Test An ANVL test case requires special configuration of the DUT. When ANVL test starts, it pauses for DUT configuration, and prompts you to configure the DUT. To automate such configuration for unattended testing, specify the required DUT configuration in parameter values and in command script files such as Expect script files. PN Rev F October

218 Test Case: ELINE Traffic Management ONE-WAY FRAME LOSS RATIO PERFORMANCE 8. Go to Test Configuration -> Parameter page. Click the Import button and browse pre-defined CE2.0 IxANVL parameter file, if you prefer to use default provided values. You can change the parameters based on your test requirement. 9. Update the configurable entries after importing the default configuration and default parameter file. These are the configurable entries for the user based on the configuration and parameter file. PN Rev F October

219 Test Case: ELINE Traffic Management ONE-WAY FRAME LOSS RATIO PERFORMANCE Run the tests 1. In the Test Configuration -> Test Cases window, select Test case 15.1 for ELINE EPL ONE-WAY FRAME LOSS RATIO PERFORMANCE. PN Rev F October

220 Test Case: ELINE Traffic Management ONE-WAY FRAME LOSS RATIO PERFORMANCE 2. Click the Start button at top manual. Selected tests cases will be run at one time, sequentially. 3. ANVL GUI automatically navigate to Test Progress -> Log window. 4. Test 15.1 for ONE-WAY FRAME LOSS RATIO PERFORMANCE, perform the following tests: o Configure EPL service in DUT between DIface-0 and DIface-1 with EVC Id EVC_1, VLAN Id = ALL o Configure DUT with Profile Name = PROFILE_1, CIR = 3 Mbps, CBS = <paramtrafficcbs(taken from the parameter file that is user configurable)> KB, EIR = 0 Mbps, EBS = 0 KB, Actions (Confirm, Exceed, Violate) = transmit, drop, drop o o o Configure DUT to bind policy information, Name = PROFILE_1, Type = ingress per COS, Association = UNI_A Configure DUT to bind policy informations, Name = PROFILE_1, Type= ingress per COS, Association = UNI_B Send unique Traffic Frames on <DIface-0> with Unique Sequence Number in TCP Header in each frame VLAN Id, Priority = 11, <DEFAULT-CoS> Duration (T) = <T> second --- This value is taken from the user PN Rev F October

221 Test Case: ELINE Traffic Management ONE-WAY FRAME LOSS RATIO PERFORMANCE Frame Length (L) = <LAMBDA> byte Frame Rate (R) = Y per second Variance (V) =.02 * ((CIR * T) + CBS) bytes o Listen upto <paramlistentime> on <DIface-1> for frames with VLAN Id set to 11 VLAN Priority set to <DEFAULT-CoS> o o o Send Traffic Frames on <DIface-1> Verify that the Frame Loss ratio of traffic delivered is according to the below mentioned specification Send unique Traffic Frames on <DIface-1> with Unique Sequence Number in TCP Header in each frame VLAN Id, Priority = 11, <DEFAULT-CoS> Duration (T) = <T> second Frame Length (L) = <LAMBDA> byteframe Rate (R) = Y per second Variance (V) =.02 * ((CIR * T) + CBS) bytes Listen upto <paramlistentime> on <DIface-0> for frames with VLAN Id set to 11 VLAN Priority set to <DEFAULT-CoS> o o Send Traffic Frames on <DIface-0> Verify that the Frame Loss ratio of traffic delivered is according to the below mentioned specification ========================================= CASE-1: Frame Length (L) = 600 byte Frame Loss Ratio For various type of PT CPOs CASE P : Metro PT CPOs PN Rev F October

222 Test Case: ELINE Traffic Management ONE-WAY FRAME LOSS RATIO PERFORMANCE Less than or equals to.01% for CoS Level High Less than or equals to.01% for CoS Level Medium Less than or equals to.1% for CoS Level Low CASE Q : Regional PT CPOs Less than or equals to.01% for CoS Level High Less than or equals to.01% for CoS Level Medium Less than or equals to.1% for CoS Level Low CASE R : Continental PT CPOs Less than or equals to.025% for CoS Level High Less than or equals to.025% for CoS Level Medium Less than or equals to.1% for CoS Level Low CASE S : Global PT CPOs Less than or equals to.05% for CoS Level High Less than or equals to.05% for CoS Level Medium Less than or equals to.1% for CoS Level Low NOTE: Here Frame Rate, Y, is calculated as Y = [(CIR * T) + CBS] byte Y = Y / (T * L) frame per second Y = Y + (2 * <RATE>) frame per second IxANVL verifies that the DUT can transmit the traffic based on the CIR or EIR configured. It configures the chassis port for sending the traffic. PN Rev F October

223 Test Case: ELINE Traffic Management ONE-WAY FRAME LOSS RATIO PERFORMANCE 5. While the test case is executed, you can see the test case result and the running log in the IxANVL GUI. ANVL configures the chassis port for sending the traffic. The test duration is taken from the user which is 5 seconds CIR is 3 Mbps, EIR is 0 After test run is complete, it shows the number of packets sent and received on the chassis port. PN Rev F October

224 Test Case: ELINE Traffic Management ONE-WAY FRAME LOSS RATIO PERFORMANCE The test result appears in the GUI. Results Analysis The color of the checkbox adjacent to the test case indicates the test result: A red checkbox indicates that the test has failed. An orange checkbox indicates that the test was inconclusive. A green checkbox indicates that the test has executed successfully. Troubleshooting and diagnostics Packet Decode To display the packet decode view, click the Packet Decode tab in the Log page, or click Packet Decode in the Test Configuration tree. PN Rev F October

225 Test Case: ELINE Traffic Management ONE-WAY FRAME LOSS RATIO PERFORMANCE Ladder Diagram To view the Ladder Diagram of the executed test, click the Ladder Diagram tab in the Log page, or click the Ladder Diagram in the Test Configuration. Conclusion All Qualified Service Frames associated with a particular CoS Label that arrive at the ingress UNI during a time interval T are delivered to egress UNI and no frame loss is detected. This validated that DUT ELINE EPL service meet the performance requirement of One-way Frame Loss Ratio Performance. PN Rev F October

226 Test Case: ELINE Service Attribute NON-LOOPING FRAME DELIVERY Using IxNetwork Test Case: ELINE Service Attribute - NON-LOOPING FRAME DELIVERY Using IxNetwork Overview ELINE service is a point to point Ethernet service that connects exactly 2 UNIs. Those 2 UNIs can communicate only with each other. An Ingress Service Frame that is mapped to the EVC can be delivered to one or more of the UNIs in the EVC other than the ingress UNI. It is never looped back to the ingress interface. Objective Determine ingress Service Frames mapped to the EVC that can be delivered to the UNIs in the EVC other than the ingress UNI. It MUST NOT be delivered back to the ingress UNI. Setup Two Ixia ports are connected to DUT. One E-LINE EVC is configured on DUT to associate 2 UNI connected to two Ixia ports. All CE-VLAN IDs are mapped to the EVC. Ixia port1 is connected to UNI A of the EVC and Ixia port2 is connected to UNI B of the EVC. Step-by-Step Instructions 1. Click the Add Ports button to open the Port Selection window. Add chassis and select ports used for the test. Name the ports for easy identification. 2. Click thetraffic in the left panel, and then click Add L2-3 Traffic Items button in the right panel or the ribbon, to open Advanced Traffic Wizard. PN Rev F October

227 Test Case: ELINE Service Attribute NON-LOOPING FRAME DELIVERY Using IxNetwork 3. At Endpoints page, configure following parameters: Name the Traffic item Select the Type of Traffic to be Raw. Select port UNI_A for source endpoint and port UNI_B for destination endpoint. Then click the green down arrow to add an endpoint set. Select port UNI_B for source endpoint and port UNI_A for destination endpoint. Then click the green down arrow to add the second endpoint set. PN Rev F October

228 Test Case: ELINE Service Attribute NON-LOOPING FRAME DELIVERY Using IxNetwork 4. In the Packet/QoS step, Select Per Encapsulation and highlight EndpointSet-1. Highlight the Ethernet II, then right-click select Append Protocol. In the Select Protocol pop-up window, select VLAN and click OK. Click the icon for expanding the frame protocols tree node. Configure source MAC Addresses to be a valid unicast MAC address. Configure Destination MAC addresses to be Broadcast MAC address. Configure VLAN ID to be 11 for traffic from UNI_A to UNI_B as showed below PN Rev F October

229 Test Case: ELINE Service Attribute NON-LOOPING FRAME DELIVERY Using IxNetwork 5. In the Packet/QoS step, highlight EndpointSet-2 and repeat step 4 with different source MAC addresses and VLAN ID. 6. In the Frame Setup page, click All Encapsulations radio button. Configure Fixed Frame Size to be Leave all other parameters as default. 7. In the Rate Setup page, click All Encapsulations radio button. Select Fixed Packet Count under Flow Group Transmission Mode. Configure 10 in the Stop After field Leave all other parameters as default. 8. At Flow Tracking page. PN Rev F October

230 Test Case: ELINE Service Attribute NON-LOOPING FRAME DELIVERY Using IxNetwork In the Track Flows by section, select Source/Dest Value Pair In the Egress Tracking section, select Enable Egress Tracking and select Outer VLAN ID (4 bits) 9. Click the button. 10. Apply and start traffic by clicking the traffic apply button. PN Rev F October

231 Test Case: ELINE Service Attribute NON-LOOPING FRAME DELIVERY Using IxNetwork 11. Traffic Item Statistics view should be automatically brought up at the lower window. In case the view set is pinned, the Traffic item Statistics view might not be auto-populated. Click the Select Views and select Traffic item statistics. 12. Now start traffic by clicking the start traffic icon Verify Traffic Items Statistics view. Notice that 20 frames were transmitted and all of them were received with no packet loss. 13. Right click the Traffic item row and select Drill Down per Rx Port. 14. Observe both UNI_A and UNI_B ports receive and only receive 10 frames. 15. Further switch current view to Ingress/Egress view. PN Rev F October

232 Test Case: ELINE Service Attribute NON-LOOPING FRAME DELIVERY Using IxNetwork 16. Verify that UNI_A only receive 10 frames with VLAN ID 12. These are the frames offered at UNI_B as ingress. No frame with VLAN ID 11 is received at UNI_A. This confirmed that UNI_A does not loop back the frames with VLAN ID 11, which are offered at UNI_A as ingress UNI. Same for UNI_B. Results Analysis The Traffic Item Statistics view and Ingress/Egress statistics view indicate that UNI_A received and only received 10 Ethernet frames with VLAN ID 12. There is no additional Ethernet frame received at UNI_A and there is no Ethernet frame with VLAN ID 11 detected at UNI_A. This confirmed that DUT does not loopback the service frame sent from UNI_A with VLAN ID 11 back to Ingress UNI_A. Same for UNI_B. Test Variables Type of Service frames (Broadcast, Multicast, Unicast, Unknown) Source MAC address and count VLAN ID and count Conclusions For all offered frame type, no packet is detected to be looped back to ingress UNI. DUT properly implemented Non-looping frame requirement for CE2.0 ELINE EPL Service. PN Rev F October

233

234 Test Case: ELINE Traffic Management ONE-WAY FRAME LOSS RATION PERFORMANCE Using IxNetwork Test Case: ELINE Traffic Management - ONE-WAY FRAME LOSS RATIO PERFORMANCE using IxNetwork Overview The EVC Related Performance Service Attributes specify the Service Frame delivery performance. Four performance attributes are considered in this specification. These are Frame Delay Performance, Inter-Frame Delay Variation Performance, Frame Loss Ratio Performance, and Availability Performance. One-Way Frame Loss Ratio Performance from the ingress UNI to the egress UNI is calculated for a time interval T, as the ratio, expressed as a percentage, of the number of ingress Qualified Frames not delivered at the egress UNI divided by the total number of ingress Qualified Frames that should have been delivered. Objective For the EPL or EVPL Service under test, verify that for all Qualified Service Frames associated with a particular CoS Label, that arrive at the UNI during a time interval T, the One-Way Frame Loss Ratio Performance is less than or equal to the One-Way Frame Loss Ratio Performance Objective specified in MEF 23.1 Table 6 for Metro PT CPOs, Table 7 for Regional PT CPOs, Table 8 for Continental PT CPOs, or Table 9 for Global PT CPOs, where the table selection is dependent on the applicable PT. Setup Two Ixia ports are connected to DUT. One ELINE EVPL EVC is configured on DUT to associate 2 UNIs connected to 2 Ixia ports. CE-VLAN IDs 11 is mapped to the EVC. Ixia port 1 is connected to DUT UNI_A of the EVC and Ixia port 2 is connected to UNI_B of the EVC. Step-by-Step Instructions 1. Configure the DUT with following bandwidth profile: PN Rev F October

235 Test Case: ELINE Traffic Management ONE-WAY FRAME LOSS RATION PERFORMANCE Using IxNetwork 2. Click Add Ports button to open Port Selection window. Add chassis and select ports used for the test. Name the ports for easy identification. 3. Click Traffic in the left panel, and then click Add L2-3 Traffic Items button in the right panel or ribbon to open Advanced Traffic Wizard. PN Rev F October

236 Test Case: ELINE Traffic Management ONE-WAY FRAME LOSS RATION PERFORMANCE Using IxNetwork 4. In the Endpoints page, configure following parameters. o o o o Name the Traffic item Select Type of Traffic to be Raw. Select port UNI_A for source endpoint and port UNI_B for destination endpoint. Then click the green down arrow to add an endpoint set. Select port UNI_B for source endpoint and port UNI_A for destination endpoint. Then click the green down arrow to add second endpoint set. 5. In the Packet/QoS step, select Per Encapsulation -> EndpointSet-1. Select Ethernet II, then right-click and select Append Protocol. In the Select Protocol pop-up window, select VLAN and click OK. PN Rev F October

237 Test Case: ELINE Traffic Management ONE-WAY FRAME LOSS RATION PERFORMANCE Using IxNetwork Click the icon for expanding the frame protocols tree node. Configure valid unicast Source MAC Address and Destination MAC Address. Configure VLAN ID 11, which is the VLAN ID mapped to this EVPL EVC. 6. In the Packet/QoS step, highlight EndpointSet-2 and repeat step 5 with reversed source and destination MAC addresses. Configure VLAN ID 11. PN Rev F October

238 Test Case: ELINE Traffic Management ONE-WAY FRAME LOSS RATION PERFORMANCE Using IxNetwork 7. In the Frame Setup page, click All Encapsulations radio button. Configure Fixed Frame Size to be 600. Leave all other parameters as default. 8. In the Rate Setup page, click All Encapsulations radio button. Clcik Fixed Duration in the Flow Group Transmission Mode section. Configure 300 seconds in the Stop After field. Configure Layer2 Bit Rate to be 3 Mbps (CIR). Leave all other parameters as default. Optionally, a burst traffic stream can be added to exercises both CIR and CBS at same time. 9. In the Flow Tracking page, In the Track Flows by section, select VLAN: VLAN-ID checkbox. 10. Click the button. PN Rev F October

Technical Specification MEF 6.1. Ethernet Services Definitions - Phase 2. April, 2008

Technical Specification MEF 6.1. Ethernet Services Definitions - Phase 2. April, 2008 Technical Specification Ethernet Services Definitions - Phase 2 April, 2008 contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is authorized

More information

Guidebook to MEF Certification

Guidebook to MEF Certification WHITE PAPER Guidebook to MEF Certification www.ixiacom.com Rev A September 2012, 915-6015-01 2 Table of Contents Introduction... 4 Benefits of Certification... 7 Overview... 7 Equipment Vendor... 7 Service

More information

Carrier Grade Ethernet. Ethernet in service provider networks, MAN/WAN

Carrier Grade Ethernet. Ethernet in service provider networks, MAN/WAN Carrier Grade Ethernet Ethernet in service provider networks, MAN/WAN Carrier grade The term Carrier Ethernet implies that Ethernet services are carrier grade. Carrier grade is a system that is extremely

More information

APPLICATION NOTE 210 PROVIDER BACKBONE BRIDGE WITH TRAFFIC ENGINEERING: A CARRIER ETHERNET TECHNOLOGY OVERVIEW

APPLICATION NOTE 210 PROVIDER BACKBONE BRIDGE WITH TRAFFIC ENGINEERING: A CARRIER ETHERNET TECHNOLOGY OVERVIEW PROVIDER BACKBONE BRIDGE WITH TRAFFIC ENGINEERING: A CARRIER ETHERNET TECHNOLOGY OVERVIEW By Thierno Diallo, Product Specialist Originally designed as a local-area network (LAN) communication protocol,

More information

Provider Backbone Bridging Traffic Engineering of Carrier Ethernet Services

Provider Backbone Bridging Traffic Engineering of Carrier Ethernet Services Provider Backbone Bridging Traffic Engineering of Carrier Ethernet Services Introduction Recently, a number of technologies have emerged for transporting Carrier Ethernet services. One such technology,

More information

MEF Carrier Ethernet Certified Professional Training Program

MEF Carrier Ethernet Certified Professional Training Program shaping tomorrow with you MEF Carrier Ethernet Certified A complete educational, study and preparation program for MEF Carrier Ethernet Certified Professional Certification (MEF-CECP) 1 Comprehensive Training

More information

Carrier Ethernet 2.0: A Chipmaker s Perspective

Carrier Ethernet 2.0: A Chipmaker s Perspective WHITE PAPER Carrier Ethernet 2.0: A Chipmaker s Perspective Tal Mizrahi Uri Safrai Marvell June 2015 ABSTRACT Over the past decade Ethernet has increasingly become a common and widely deployed technology

More information

Metro Ethernet Services

Metro Ethernet Services CHAPTER 6 Metro Ethernet Service Framework This chapter describes the typical available from service providers (SPs). For the most part, these services are derived from and map to the following Metro Ethernet

More information

Shortest Path Bridging IEEE 802.1aq Overview

Shortest Path Bridging IEEE 802.1aq Overview Shortest Path Bridging IEEE 802.1aq Overview Don Fedyk IEEE Editor 802.1aq Alcatel-Lucent IPD Product Manager Monday, 12 July 2010 Abstract 802.1aq Shortest Path Bridging is being standardized by the IEEE

More information

Ethernet Business Services

Ethernet Business Services Ethernet Business Services Introduction Why market Ethernet Business solutions? This represents large revenue streams for Service Providers Commercial services market experiencing huge growth Most Service

More information

DPoE Support of Carrier Ethernet Services

DPoE Support of Carrier Ethernet Services DPoE Support of Carrier Ethernet Services Hesham ElBakoury March 2012 www.huawei.com HUAWEI TECHNOLOGIES CO., LTD. HUAWEI TECHNOLOGIES CO., LTD. Page 1 Agenda MEF Carrier Ethernet Carrier Ethernet Architecture

More information

Using & Offering Wholesale Ethernet Network and Operational Considerations

Using & Offering Wholesale Ethernet Network and Operational Considerations White Paper Using and Offering Wholesale Ethernet Using & Offering Wholesale Ethernet Network and Operational Considerations Introduction Business services customers are continuing to migrate to Carrier

More information

Technical Specification MEF 30. Service OAM Fault Management Implementation Agreement. January 2011

Technical Specification MEF 30. Service OAM Fault Management Implementation Agreement. January 2011 Technical Specification Service OAM Fault Management Implementation Agreement January 2011 Disclaimer The information in this publication is freely available for reproduction and use by any recipient and

More information

Service Definition. Internet Service. Introduction. Product Overview. Service Specification

Service Definition. Internet Service. Introduction. Product Overview. Service Specification Service Definition Introduction This Service Definition describes Nexium s from the customer s perspective. In this document the product is described in terms of an overview, service specification, service

More information

How To Make A Network Cable Reliable And Secure

How To Make A Network Cable Reliable And Secure ETHERNET KEPT Provider Link State Bridging Gerard Jacobs Senior Solutions Architect Agenda > Network Visions > Carrier Ethernet > Provider Link State Bridging (PLSB) > Summary Network Visions HYBRID L1

More information

Ethernet Service OAM. Standards and Functionality. Connectivity Fault Management (CFM) Fault Detection. White Paper

Ethernet Service OAM. Standards and Functionality. Connectivity Fault Management (CFM) Fault Detection. White Paper White Paper Ethernet Service OAM Standards and Functionality As Ethernet continues to replace legacy TDM services in QoS sensitive, high-capacity applications such as business services and WiMAX/LTE 4G

More information

Connection-Oriented Ethernet On-Ramp Aggregation for Next-Generation Networks

Connection-Oriented Ethernet On-Ramp Aggregation for Next-Generation Networks Connection-Oriented Ethernet On-Ramp Aggregation for Next-Generation Networks Introduction The GIG and its component networks, including the DISN, form the state-of-the-art network foundation for DoD communications.

More information

Enterprise Business Products 2014

Enterprise Business Products 2014 Enterprise Business Products 2014 Enterprise Ethernet Services EPL (Ethernet Private Line) - provides point-to-point connectivity between two business locations with scalable bandwidth speeds via an Ethernet

More information

REMOTE MONITORING MATRIX

REMOTE MONITORING MATRIX 802.1ag/Y.1731 BASIC ADVANCED 802.3ah Link 802.1ag/Y.1731 RFC 2544 REMOTE MONITORING MATRIX Featuring a matrix of different features that will help you identify and select which Transition products best

More information

Ethernet as a Carrier Grade Technology: Developments and Innovations

Ethernet as a Carrier Grade Technology: Developments and Innovations 1 Ethernet as a Carrier Grade Technology: Developments and Innovations Rafael Sánchez (rsfuente@it.uc3m.es) Universidad Carlos III de Madrid, Spain Lampros Raptis (Lampros.Raptis@hol.net), Kostas Vaxevanakis

More information

UNDERSTANDING BUSINESS ETHERNET SERVICES

UNDERSTANDING BUSINESS ETHERNET SERVICES UNDERSTANDING BUSINESS ETHERNET SERVICES EMPOWER YOUR BUSINESS TO MEET 21ST CENTURY DEMANDS INTRODUCTION The network is your business has been a mantra for many years indicating how businesses rely more

More information

ethernet alliance Provider Backbone Transport Overview Version 1.0 December 2007 Authors:

ethernet alliance Provider Backbone Transport Overview Version 1.0 December 2007 Authors: Provider Backbone Transport Overview Version 1.0 December 2007 Authors: David Allen, Nortel Paul Bottorff, Nortel Harpreet Chadha, Extreme Networks Peter Lunk, Extreme Networks David Martin, Nortel ethernet

More information

UNDERSTANDING BUSINESS ETHERNET SERVICES

UNDERSTANDING BUSINESS ETHERNET SERVICES EMPOWER YOUR BUSINESS TO MEET 21ST CENTURY DEMANDS INTRODUCTION The network is your business has been a mantra for many years indicating how businesses rely more heavily on being networked between their

More information

Resiliency in Ethernet Based Transport Networks

Resiliency in Ethernet Based Transport Networks Resiliency in Ethernet Based Transport Networks Kari Seppänen Kari.Seppanen@vtt.fi Outline Introduction What is switched Ethernet? Legacy Ethernet Security and Reliability issues Rapid spanning tree protocol

More information

Understanding PBB-TE for Carrier Ethernet

Understanding PBB-TE for Carrier Ethernet Understanding PBB-TE for Carrier Ethernet Introduction Ethernet is evolving from an enterprise LAN technology to a much more robust, carrier-grade transport technology for metropolitan service networks.

More information

Scalability Analysis of Metro Ethernet

Scalability Analysis of Metro Ethernet Scalability Analysis of Metro Ethernet Heikki Mahkonen Helsinki University of Technology Email: heikki.mahkonen@piuha.net Abstract This document gives a scalability analysis of Metro Ethernet architecture.

More information

Provider Backbone Bridging Networks A Highly Scalable VLAN (Multicast) Architecture

Provider Backbone Bridging Networks A Highly Scalable VLAN (Multicast) Architecture Provider Backbone Bridging Networks A Highly Scalable VLAN (Multicast) Architecture Paul Bottorff, Mark Holness, Norival Figueira, Michael Chen, Dinesh Mohan, Glenn Parsons Version 2.0 Page 1 A Provider

More information

The Role of Carrier Ethernet in Business Applications

The Role of Carrier Ethernet in Business Applications The Role of Carrier Ethernet in Business Applications Examining the Choices for your Business Applications February 2012 Positioning Paper Page 1 of 11 Table of Contents 1 Introduction... 3 2 Characteristics

More information

EPIPE Connectivity Services

EPIPE Connectivity Services EPIPE Connectivity Services VTCW018 - I 08/13 EPIPE Connectivity Services 2 In an always on hyperconnected world choosing the right networking technology is now more important than ever. Around the world

More information

Broadband Networks. Prof. Abhay Karandikar. Electrical Engineering Department. Indian Institute of Technology, Mumbai.

Broadband Networks. Prof. Abhay Karandikar. Electrical Engineering Department. Indian Institute of Technology, Mumbai. Broadband Networks Prof. Abhay Karandikar Electrical Engineering Department Indian Institute of Technology, Mumbai Lecture - 32 Metro Ethernet Access Networks So, in today s lecture we will talk about

More information

Rohde & Schwarz R&S SITLine ETH VLAN Encryption Device Functionality & Performance Tests

Rohde & Schwarz R&S SITLine ETH VLAN Encryption Device Functionality & Performance Tests Rohde & Schwarz R&S Encryption Device Functionality & Performance Tests Introduction Following to our test of the Rohde & Schwarz ETH encryption device in April 28 the European Advanced Networking Test

More information

Ethernet OAM Overview: Making Ethernet Manageable

Ethernet OAM Overview: Making Ethernet Manageable Ethernet OAM Overview: Making Ethernet Manageable Frank Brockners Cisco Systems Hansaallee 249 40549 Düsseldorf frank.brockners@cisco.com Abstract: This paper provides an overview of three important tools

More information

How To Use Connection-Oriented Ether (Coe) For Cloud Services

How To Use Connection-Oriented Ether (Coe) For Cloud Services Connection-Oriented Ethernet for Delivery of Private Cloud Services Ralph Santitoro Director of Carrier Ethernet Market Development Ralph.Santitoro@us.Fujitsu.com February 23, 2012 Contents What problem

More information

Evaluating Carrier-Class Ethernet Services

Evaluating Carrier-Class Ethernet Services Technical Paper Evaluating Carrier-Class Ethernet Services Demand for Ethernet-based services is on the rise, and the key driving force behind this is continuous growth of data traffic in the metro/access

More information

EVOLVING ENTERPRISE NETWORKS WITH SPB-M APPLICATION NOTE

EVOLVING ENTERPRISE NETWORKS WITH SPB-M APPLICATION NOTE EVOLVING ENTERPRISE NETWORKS WITH SPB-M APPLICATION NOTE EXECUTIVE SUMMARY Enterprise network managers are being forced to do more with less. Their networks are growing in size and complexity. They need

More information

Ethernet Controller as Solution for Embedded Applications, New Developments and Innovations

Ethernet Controller as Solution for Embedded Applications, New Developments and Innovations IOSR Journal of Electronics and Communication Engineering (IOSR-JECE) ISSN: 2278-2834, ISBN: 2278-8735, PP: 39-43 www.iosrjournals.org Ethernet Controller as Solution for Embedded Applications, New Developments

More information

White Paper. Carrier Ethernet

White Paper. Carrier Ethernet White Paper Carrier Ethernet 26601 Agoura Road, Calabasas, CA 91302 Tel: 818.871.1800 Fax: 818.871.1805 www.ixiacom.com Rev. A, September 2007 2 Table of Contents Introduction... 4 Benefits of Carrier

More information

Technical Specification MEF 10.2. Ethernet Services Attributes Phase 2. 27 October 2009

Technical Specification MEF 10.2. Ethernet Services Attributes Phase 2. 27 October 2009 echnical Specification Ethernet Services Attributes Phase 2 27 October 2009 Disclaimer he information in this publication is freely available for reproduction and use by any recipient and is believed to

More information

Bandwidth Profiles for Ethernet Services Ralph Santitoro

Bandwidth Profiles for Ethernet Services Ralph Santitoro Ralph Santitoro Abstract This paper provides a comprehensive technical overview of bandwidth profiles for Ethernet services, based on the work (as of October 2003) of the Metro Ethernet Forum (MEF) Technical

More information

Carrier Ethernet A Wave is Building. Provider Backbone Bridges with Traffic Engineering (PBB-TE)

Carrier Ethernet A Wave is Building. Provider Backbone Bridges with Traffic Engineering (PBB-TE) Carrier Ethernet A Wave is Building Provider Backbone Bridges with Traffic Engineering (PBB-TE) D. Kent Stevens Western Region Optical Architect kesteven@nortel.com 714-803-1050 Next Generation Packet

More information

ethernet services for multi-site connectivity security, performance, ip transparency

ethernet services for multi-site connectivity security, performance, ip transparency ethernet services for multi-site connectivity security, performance, ip transparency INTRODUCTION Interconnecting three or more sites across a metro or wide area network has traditionally been accomplished

More information

Bandwidth Profiles for Ethernet Services Ralph Santitoro

Bandwidth Profiles for Ethernet Services Ralph Santitoro Ralph Santitoro Abstract This paper provides a comprehensive technical overview of bandwidth profiles for Ethernet services, based on the work of the Metro Ethernet Forum (MEF) Technical Committee. The

More information

Standardized Carrier Ethernet Services for Optical Transport Networks

Standardized Carrier Ethernet Services for Optical Transport Networks Standardized Carrier Services for Optical Transport Networks Carsten Rossenhövel MEF EMEA Marketing Co-Chair Managing Director, European Advanced Networking Test Center (EANTC) 1 Developing, Marketing

More information

White Paper: Carrier Ethernet

White Paper: Carrier Ethernet White Paper: Carrier Ethernet Activity and Task: JRA1 T1 Target Audience: NREN technical networking specialists Document Code: Authors: J. Kloots (SURFnet), V. Olifer (JANET) Acknowledgement: The research

More information

Driving Service Delivery with SLA Performance Management

Driving Service Delivery with SLA Performance Management Driving Service Delivery with SLA Performance Management Providers #1 competitive advantage Service providers more and more depend on Ethernet services as the networks are evolving from traditional voice

More information

Carrier Ethernet for Delivery of Private Cloud Services

Carrier Ethernet for Delivery of Private Cloud Services Carrier Ethernet for Delivery of Private Cloud Services An overview of the Ethernet Services for Cloud Service Providers and Cloud Service Concepts for Carrier Ethernet Service Providers February 2012

More information

SECURE AVAYA FABRIC CONNECT SOLUTIONS WITH SENETAS ETHERNET ENCRYPTORS

SECURE AVAYA FABRIC CONNECT SOLUTIONS WITH SENETAS ETHERNET ENCRYPTORS SECURE AVAYA FABRIC CONNECT SOLUTIONS WITH SENETAS ETHERNET ENCRYPTORS AUDIENCE Data networks consultants, Network architects, designers and administrators/ managers, Systems Integrators (SI) and networks

More information

Metro Ethernet Forum Layer 2 Control Protocol handling

Metro Ethernet Forum Layer 2 Control Protocol handling Metro Ethernet Forum Layer 2 Control Protocol handling This article provides some information about Layer 2 Control Protocols (L2CP) according to the Metro Ethernet Forum specifications. Most of the information

More information

Backbone Provider Bridging Networks A Highly Scalable VLAN (Multicast) Architecture

Backbone Provider Bridging Networks A Highly Scalable VLAN (Multicast) Architecture Backbone Provider Bridging Networks A Highly Scalable VLAN (Multicast) Architecture Paul Bottorff Version 1.0 July 12, 2004 Page 1 A Provider Bridge Scaling Solution Backbone Provider Bridging 802.1ad

More information

Driving Ethernet Deeper Ethernet Business Services over DOCSIS COX New Orleans (NOLA) Case Study

Driving Ethernet Deeper Ethernet Business Services over DOCSIS COX New Orleans (NOLA) Case Study Driving Ethernet Deeper Ethernet Business Services over DOCSIS COX New Orleans (NOLA) Case Study Kashif Islam, Technical Leader Cisco Carlos Sanchez, Systems Engineer Cisco Edward Kerner, Network Engineering

More information

How To Understand The Concept Of Redundancy In A Network (Uni, Enni)

How To Understand The Concept Of Redundancy In A Network (Uni, Enni) E-NNI Redundancy (Considerations and Musings) Stephen Haddock November 19, 2009 802.1 Plenary, Atlanta 1 Introduction This presentation is kind of a random walk considering aspects of providing redundancy

More information

Carrier Ethernet: The native approach

Carrier Ethernet: The native approach Carrier Ethernet: The native approach Howard Green, Sylvain Monette, Jonathan Olsson, Panagiotis Saltsidis and Attila Takács This article reviews the developments and emerging standards of native Ethernet

More information

TRILL for Data Center Networks

TRILL for Data Center Networks 24.05.13 TRILL for Data Center Networks www.huawei.com enterprise.huawei.com Davis Wu Deputy Director of Switzerland Enterprise Group E-mail: wuhuajun@huawei.com Tel: 0041-798658759 Agenda 1 TRILL Overview

More information

Carrier Ethernet Essentials

Carrier Ethernet Essentials shaping tomorrow with you Many technologies are used to deliver metro and wide-area services. Layer 1 TDM technologies used to deliver private line services include T1 and T3 copper circuits, and SONET-based

More information

Provider Backbone Transport

Provider Backbone Transport Provider Backbone Transport David Allan Paul Bottorff Dinesh Mohan Alan McGuire dallan@nortel.com pbottorf@nortel.com dmohan@nortel.com alan.mcguire@bt.com Agenda > Motivation > Problem statement > What

More information

The Evolution of Ethernet

The Evolution of Ethernet June 2010 White Paper The Evolution of Ethernet How Ethernet solutions, such as NTT America s VLink, can help businesses reduce private networking costs while leveraging Ethernet technology. Introduction

More information

Mobile Backhaul Implementation Agreement Phase 2. Implementation Agreement MEF 22.1. Mobile Backhaul Phase 2. January 2012

Mobile Backhaul Implementation Agreement Phase 2. Implementation Agreement MEF 22.1. Mobile Backhaul Phase 2. January 2012 Implementation Agreement Mobile Backhaul Phase 2 January 2012 Page i Disclaimer The information in this publication is freely available for reproduction and use by any recipient and is believed to be accurate

More information

Delivering Dedicated Internet Access (DIA) and IP Services with Converged L2 and L3 Access Device

Delivering Dedicated Internet Access (DIA) and IP Services with Converged L2 and L3 Access Device Delivering Dedicated Internet Access (DIA) and IP Services with Converged L2 and L3 Access Device THE NEED Communications Service providers (CSPs) have been transitioning from legacy SONET/SDH to IP and

More information

OAM Operations Administration and Maintenance

OAM Operations Administration and Maintenance OAM Operations Administration and Maintenance IERU Communications Ltd OAM Rev. A Page 1 of 9 Operations Administration and Maintenance 1. Overview This paper describes the Ethernet and Multi-Protocol Label

More information

Driving Service Delivery with SLA Performance Monitoring

Driving Service Delivery with SLA Performance Monitoring Driving Service Delivery with SLA Performance Monitoring 1. PROVIDERS #1 COMPETITIVE ADVANTAGE Service providers more and more depend on Ethernet services as the networks are evolving from traditional

More information

DELIVERING TRUE CARRIER ETHERNET BUSINESS SERVICES

DELIVERING TRUE CARRIER ETHERNET BUSINESS SERVICES DELIVERING TRUE CARRIER ETHERNET BUSINESS SERVICES Rapid increases in the breadth and sophistication of business applications are impacting enterprises networking requirements and driving the adoption

More information

IxNetwork TM MPLS-TP Emulation

IxNetwork TM MPLS-TP Emulation IxNetwork TM MPLS-TP Emulation Test the Functionality, Performance, and Scalability of an MPLS-TP Ingress, Egress, or Transit Node MPLS has come a long way since its original goal to allow core routers

More information

Riverstone Networks. Carrier Ethernet Standards Progress. Igor Giangrossi Sr. Systems Engineer, CALA

Riverstone Networks. Carrier Ethernet Standards Progress. Igor Giangrossi Sr. Systems Engineer, CALA Riverstone Networks Carrier Ethernet Standards Progress Igor Giangrossi Sr. Systems Engineer, CALA Agenda History Metro Ethernet Forum work IETF work IEEE work Conclusion 2 Ethernet Evolution What do we

More information

Innovation in Access and Metropolitan Area Networks -

Innovation in Access and Metropolitan Area Networks - Innovation in Access and Metropolitan Area s - Combining Ethernet and MPLS By Jim Metzler SPONSORED BY: K ubernan Guiding Innovation Innovation in Access and Metropolitan Area s - Combining Ethernet and

More information

Joint ITU-T/IEEE Workshop on Carrier-class Ethernet

Joint ITU-T/IEEE Workshop on Carrier-class Ethernet Joint ITU-T/IEEE Workshop on Carrier-class Ethernet Carrier Bridge Architecture Stephen Haddock Chief Technology Officer Extreme Networks 802.1 Bridging Architecture for Carrier Ethernet from D & Q bridges

More information

The Business Case for Ethernet Services Whitepaper Sponsored by Time Warner Cable Business Class

The Business Case for Ethernet Services Whitepaper Sponsored by Time Warner Cable Business Class The Business Case for Ethernet Services Whitepaper Sponsored by Time Warner Cable Business Class Executive Summary Network-based applications such as Voice over IP (VoIP), cloud, collaboration services

More information

Carrier Ethernet: New Game Plan for Media Converters

Carrier Ethernet: New Game Plan for Media Converters Introduction IEEE Std. 802.3ah, also referred to as Ethernet in the First Mile (EFM) standard, has a well established name within the industry today. It lays out ground rules for implementing Ethernet

More information

Carrier Ethernet Metro Ethernet Architectures

Carrier Ethernet Metro Ethernet Architectures Carrier Ethernet Metro Ethernet Architectures Eli Baruch Senior Director, Product Management ARRIS www.arrisi.com Agenda What s all the fuss about? Ethernet Services Basic Elements - & NID Carrier Ethernet

More information

VLANs. Application Note

VLANs. Application Note VLANs Application Note Table of Contents Background... 3 Benefits... 3 Theory of Operation... 4 IEEE 802.1Q Packet... 4 Frame Size... 5 Supported VLAN Modes... 5 Bridged Mode... 5 Static SSID to Static

More information

Software Defined Networking Supported by IEEE 802.1Q

Software Defined Networking Supported by IEEE 802.1Q Software Defined Networking Supported by IEEE 802.1Q János Farkas, Stephen Haddock, Panagiotis Saltsidis janos.farkas@ericsson.com, shaddock@stanfordalumni.org, panagiotis.saltsidis@ericsson.com Abstract

More information

Management Software. Web Browser User s Guide AT-S106. For the AT-GS950/48 Gigabit Ethernet Smart Switch. Version 1.0.0. 613-001339 Rev.

Management Software. Web Browser User s Guide AT-S106. For the AT-GS950/48 Gigabit Ethernet Smart Switch. Version 1.0.0. 613-001339 Rev. Management Software AT-S106 Web Browser User s Guide For the AT-GS950/48 Gigabit Ethernet Smart Switch Version 1.0.0 613-001339 Rev. A Copyright 2010 Allied Telesis, Inc. All rights reserved. No part of

More information

VPLS Technology White Paper HUAWEI TECHNOLOGIES CO., LTD. Issue 01. Date 2012-10-30

VPLS Technology White Paper HUAWEI TECHNOLOGIES CO., LTD. Issue 01. Date 2012-10-30 Issue 01 Date 2012-10-30 HUAWEI TECHNOLOGIES CO., LTD. 2012. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of

More information

MPLS Layer 2 VPNs Functional and Performance Testing Sample Test Plans

MPLS Layer 2 VPNs Functional and Performance Testing Sample Test Plans MPLS Layer 2 VPNs Functional and Performance Testing Sample Test Plans Contents Overview 1 1. L2 VPN Padding Verification Test 1 1.1 Objective 1 1.2 Setup 1 1.3 Input Parameters 2 1.4 Methodology 2 1.5

More information

Maximizing Revenue Opportunities with Converged IP Services over Ethernet Transport

Maximizing Revenue Opportunities with Converged IP Services over Ethernet Transport Extreme Networks Carrier Ethernet Transport Solution Overview Maximizing Revenue Opportunities with Converged IP Services over Ethernet Transport Carriers all over the world are facing explosive demand

More information

CE 2.0 Service Management Life Cycle White Paper

CE 2.0 Service Management Life Cycle White Paper CE 2.0 Service Management Life Cycle White Paper July 2014 White Paper Page 1 of 18 Table of Contents 1 Introduction and Overview... 3 1.1 Abstract... 3 1.2 Background... 3 1.3 Document Objective... 3

More information

PBBN in the Data Center IEEE 802.1 May 2009 Interim Meeting Pittsburgh, PA., USA

PBBN in the Data Center IEEE 802.1 May 2009 Interim Meeting Pittsburgh, PA., USA PBBN in the Data Center IEEE 802.1 May 2009 Interim Meeting Pittsburgh, PA., USA Bob Sultan Ben Mack-Crane www.huawei.com Growing number of MACs in Data Center Large numbers of servers with multiple Virtual

More information

IP Office Technical Tip

IP Office Technical Tip IP Office Technical Tip Tip no: 195 Release Date: October 26, 2007 Region: GLOBAL Using Packet Capture Software To Verify IP Network VoIP Quality Of Service (QoS) Operation Converged networks can experience

More information

ITU-T Y.1564. Ethernet service activation test methodology

ITU-T Y.1564. Ethernet service activation test methodology International Telecommunication Union ITU-T Y.1564 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (03/2011) SERIES Y: GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS AND NEXT-GENERATION NETWORKS

More information

Ethernet, VLAN, Ethernet Carrier Grade

Ethernet, VLAN, Ethernet Carrier Grade Ethernet, VLAN, Ethernet Carrier Grade Dr. Rami Langar LIP6/PHARE UPMC - University of Paris 6 Rami.langar@lip6.fr www-phare.lip6.fr/~langar RTEL 1 Point-to-Point vs. Broadcast Media Point-to-point PPP

More information

How To Configure Voice Vlan On An Ip Phone

How To Configure Voice Vlan On An Ip Phone 1 VLAN (Virtual Local Area Network) is used to logically divide a physical network into several broadcast domains. VLAN membership can be configured through software instead of physically relocating devices

More information

Enhancing Converged MPLS Data Networks with ATM, Frame Relay and Ethernet Interworking

Enhancing Converged MPLS Data Networks with ATM, Frame Relay and Ethernet Interworking TECHNOLOGY WHITE PAPER Enhancing Converged Data Networks with, Frame Relay and Ethernet Interworking Virtual Private Networks (VPN) are a popular way for enterprises to interconnect remote sites. Traditionally,

More information

Ethernet is service provider terms can be delivered from speeds starting from 1mb all the way up to 1Gb+.

Ethernet is service provider terms can be delivered from speeds starting from 1mb all the way up to 1Gb+. Carrier Ethernet vs. (Standard) Ethernet The Ethernet Evolution. The Basics What is Ethernet? Ethernet (technical term is IEEE 802.3) has set the standard in how service providers connect customers to

More information

MPLS-TP. Future Ready. Today. Introduction. Connection Oriented Transport

MPLS-TP. Future Ready. Today. Introduction. Connection Oriented Transport MPLS-TP Future Ready. Today Introduction As data traffic started dominating telecom networks, there was a need for transport data networks, as opposed to transport TDM networks. Traditional transport technologies

More information

WHY CHOOSE COX BUSINESS FOR YOUR COMPANY S NETWORK SERVICE NEEDS?

WHY CHOOSE COX BUSINESS FOR YOUR COMPANY S NETWORK SERVICE NEEDS? WHY CHOOSE COX BUSINESS FOR YOUR COMPANY S NETWORK SERVICE NEEDS? This document provides an overview of the Cox Business portfolio of business networking services and explains why customers should consider

More information

multi-site, private networking service Uses MPLS access-agnostic transport routing intelligence in the network Class of Service (CoS)

multi-site, private networking service Uses MPLS access-agnostic transport routing intelligence in the network Class of Service (CoS) MPLS IP-VPN Overview XO MPLS IP-VPN is a multi-site, private networking service for IP data and voice transport Uses MPLS and is competitive with legacy services such as ATM, Frame-Relay, and long-haul

More information

> ADDING SCALE, QoS AND OPERATIONAL SIMPLICITY TO ETHERNET

> ADDING SCALE, QoS AND OPERATIONAL SIMPLICITY TO ETHERNET > ADDING SCALE, QoS AND OPERATIONAL SIMPLICITY TO ETHERNET White Paper Provider Backbone Transport Market overview For many years, Ethernet has been the dominant networking protocol in the LAN. Its simplicity

More information

L2 VPNs. Pseudowires. Virtual Private LAN Services. Metro/Carrier Ethernet.

L2 VPNs. Pseudowires. Virtual Private LAN Services. Metro/Carrier Ethernet. L2 VPNs. Pseudowires. Virtual Private LAN Services. Metro/Carrier Ethernet. Petr Grygárek rek 1 Layer 2 VPNs 2 Usages of L2 VPNs Server farms/clusters and other L2- dependent applications redundancy and

More information

Transport for Enterprise VoIP Services

Transport for Enterprise VoIP Services Transport for Enterprise VoIP Services Introduction Many carriers are looking to advanced packet services as an opportunity to generate new revenue or lower costs. These services, which include VoIP, IP

More information

Configuring IP SLA - Service Performance Testing

Configuring IP SLA - Service Performance Testing Configuring IP SLA - Service Performance Testing This module describes how to configure the ITU-T Y.1564 Ethernet service performance test methodology to measure the ability of a network device to carry

More information

Best Practices: Multiple Classes of Service in Carrier Ethernet Mobile Backhaul Networks

Best Practices: Multiple Classes of Service in Carrier Ethernet Mobile Backhaul Networks Best Practices: Multiple Classes of Service in Carrier Ethernet Mobile Backhaul Networks April 2013 Best Practices Document Page 1 of 21 Table of Contents 1 Introduction... 3 1.1 Purpose of this Best Practices

More information

Simwood Carrier Ethernet

Simwood Carrier Ethernet Simwood Carrier Ethernet Simwood Carrier Ethernet is a high security, low latency means to connect sites or services either point-to-point or as a mesh. We use a number of technologies on top of our own

More information

Asynchronous Transfer Mode: ATM. ATM architecture. ATM: network or link layer? ATM Adaptation Layer (AAL)

Asynchronous Transfer Mode: ATM. ATM architecture. ATM: network or link layer? ATM Adaptation Layer (AAL) Asynchrous Transfer Mode: architecture 1980s/1990 s standard for high-speed (155Mbps to 622 Mbps and higher) Broadband Integrated Service Digital Network architecture Goal: integrated, end-end transport

More information

RFC 2544 Testing of Ethernet Services in Telecom Networks

RFC 2544 Testing of Ethernet Services in Telecom Networks RFC 2544 Testing of Ethernet Services in Telecom Networks White Paper Nigel Burgess Agilent Technologies Introduction The object of this paper is to discuss the use and testing of Ethernet services in

More information

Carrier Ethernet 2.0 Service Delivery Case Study: Telstra s Ethernet Services Powered by MRV

Carrier Ethernet 2.0 Service Delivery Case Study: Telstra s Ethernet Services Powered by MRV White Paper Carrier Ethernet 2.0 Service Delivery Case Study: Telstra s Ethernet Services Powered by MRV Prepared by Heavy Reading www.heavyreading.com on behalf of www.mrv.com March 2014 Introduction

More information

Implementation Agreement MEF 35. Service OAM Performance Monitoring Implementation Agreement. April 2012

Implementation Agreement MEF 35. Service OAM Performance Monitoring Implementation Agreement. April 2012 Implementation Agreement Service OAM Performance Monitoring Implementation Agreement April 2012 Disclaimer The information in this publication is freely available for reproduction and use by any recipient

More information

Central Office Testing of Network Services

Central Office Testing of Network Services Central Office Testing of Network Services Rev 4 Application Note Ethernet is rapidly becoming the predominant method for deploying new commercial services and for expanding backhaul capacity. Carriers

More information

Cox Business. L2 / L3 and Network Topology Overview. February 1, 2011

Cox Business. L2 / L3 and Network Topology Overview. February 1, 2011 Cox Business L2 / L3 and Network Topology Overview February 1, 2011 Layer 3 / Layer 2 Comparo Protocol Architecture Control Change: Adding sites Change: IP changes Faults: Management Faults: Calls Layer

More information

SPIRENT PERFORMANCE MONITORING FOR ETHERNET QUALITY OF SERVICE SPIRENT TESTCENTER LIVE PERFORMANCE MONITORING

SPIRENT PERFORMANCE MONITORING FOR ETHERNET QUALITY OF SERVICE SPIRENT TESTCENTER LIVE PERFORMANCE MONITORING SPIRENT PERFORMANCE MONITORING FOR ETHERNET QUALITY OF SERVICE SPIRENT TESTCENTER LIVE PERFORMANCE MONITORING Spirent TestCenter Live Performance Monitoring ENSURING YOUR ETHERNET QUALITY OF SERVICE (QoS)

More information

Building a Bigger Pipe: Inverse Multiplexing for Transparent Ethernet Bridging over Bonded T1/E1s

Building a Bigger Pipe: Inverse Multiplexing for Transparent Ethernet Bridging over Bonded T1/E1s Building a Bigger Pipe: Inverse Multiplexing for Transparent Ethernet Bridging over Bonded T1/E1s The fast path to increased bandwidth for carriers, service providers, and enterprises Printed in the USA.

More information