Introduction to Ethernet Testing and TBERD-5800 Overview Jody Frey CES 763-772-8111 [email protected] Technical Support 855-ASK-JDSU (855-275-5378)

Introduction to Ethernet Testing and TBERD-5800 Overview

Jody FreyCES

[email protected]

m

Technical Support

855-ASK-JDSU(855-275-5378)[email protected]

mailto:[email protected]

© 2012 JDS Uniphase Corporation | JDSU CONFIDENTIAL AND PROPRIETARY INFORMATION 2

Agenda

JDSU TBERD-5800 Overview Key Ethernet Concepts

• Link Establishment• BERT vs. Packet Loss Testing• Loopback concept

Ethernet Testing Basics• Layered approach to testing• RFC2544• Intro to Y.1564/SAMComplete

Live Demo & Hands-on Exercises Q&A


Ethernet Link Establishment Process

Physical Layer Link Establishment

Step 1 (optical only)

Light is seen on both sides

Step 2

Byte synchronization takes place

Step 3 Each node is set for

Appropriate speed – 10/100/1000Mbps Half Duplex/Full Duplex Flow control on/off

Done by Manual Setup or Auto-Negotiation

Afterwards Link is active but no data is sent


Ethernet Link Establishment Process

Physical Layer Link Establishment

Step 1 (optical only)

Light is seen on both sides

Step 2

Byte synchronization takes place

Step 3 Each node is set for

Appropriate speed – 10/100/1000Mbps Half Duplex/Full Duplex Flow control on/off

Done by Manual Setup or Auto-Negotiation

Afterwards Link is active but no data is sent


Ethernet Auto-Negotiation & Duplex

Auto-Negotiation Advertises speed, flow control and FDX/HDX capabilities to the other side

Full Duplex/Half Duplex Whether the link can transmit in only one direction at a time

or can transmit in both directions simultaneously

FDX is used almost exclusively worldwide

Auto-Negotiation failures and duplex mismatches

account for significant percentage of problems

HDX

FDX

ON OFF


Ethernet Frame Structure and Size Range

Frames are sent from Source MAC Address to Destination MAC Address

Same frame setup regardless of rate (10M/100M/1 Gigabit/10 Gigabit) Variable Frame Size – 64 to 1518 bytes

6 byte Destination Address (DA) 6 byte Source Address (SA) 46 – 1500 Payload bytes 4 byte Frame Check Sequences (FCS)

FCS is used to check if errors occurred across the network Network may perform at some frame sizes but not at others – the

complete range must be tested!

Data (46-1500)SA (6)DA (6) FCS (4)SFD (1)Preamble (7) L/T (2)


VLAN (Virtual Local Area Network) Tagging

VLAN ID Specifies VLAN group and used to separate traffic by customer or

type VLAN Priority

Prioritize traffic (For example gold, silver, bronze) Voice, video, data, etc.

Data (46-1500)L/T (2)SA (6)DA (6) FCS (4)SFD (1)Preamble (7) VLAN (4)

TPID Priority CFI VLAN ID

2 bytes 3 bits 1 bit 12 bits

MTSO

(Mobile Telephone Switching Office)

3GLTE

Cell Site

SIAD

MSN Ethernet Switch/Router

VLAN Tag Customer application

NTENTE


Ethernet Concepts – BERT vs Frame Loss Tests

Errored Frames are discarded by Ethernet devices If one sees lost frames errors are occurring that means

that the frame was dropped in transit.

For example, errors occurring between A and B will be

seen by the switch receiving them.

However, errors occurring from A to B won’t be seen by C.

Only way to view this is to have a sequence number in

each packet and detect if packets were lost in transit.

Errored Frames Lost FramesA B C


Ethernet Concepts – Switching & Loopback

Switch will drop the frame coming from A to C, because it

assumes that C has received this frame from A, since they

are on the same Port #1

PC withMAC Address A

PC withMAC Address B

Dest Addr =C Source Addr =A Data

Port #1 Port #2

PC withMAC Address C

Hub


Ethernet Concepts – Switching, Loopback

Switch operation

Any traffic for A, forward to port #1

Any traffic for B, forward to port #2


PC withMAC Address B

Dest Addr =B Source Addr =A Data

Port #1 Port #2

MAC Address Port

A 1

B 2



Can’t hard loop a switch

Switch will see frame destined for B

coming into Port #2 and will not forward

it back to port #1. Frame will be

dropped. Assumption is B received the

frame.



Port #1Port #2

MAC Address Port

A 1

B 2

INVALID!



For a loop to work on the switch, the

Source and Destination addresses

within the frame must be swapped

This is what happens when test

equipment is “looped up”



Port #1 Port #2

MAC Address Port

A 1

B 2

Dest Addr =A Source Addr =B Data

Unit gets receives frame and

swaps Destination and Source

Address

Test Set with

MAC Address BIn loopback mode


JDSU Ethernet Layered Testing Approach


Application Testing RFC6439 TCP test to verify data throughput; Capture/Decode with Wireshark and J-Profiler, VoIP & Video tests to verify QoE

SLA Verification Manual Traffic test, RFC 2544, Y.1564, or Multiple Streams test to verify service quality

Loop-Up far-end device, verify connectivity, VLAN & IP configuration

Far-End Connectivity

Sync and Link Active LED light up, Summary page turns green, verify Auto-negotiation, Link Speed & Duplex mode

Near-End Connectivity

Physical Layer

Copper Qualification; Clean & Inspect all Fibers;Fiber Characterization

Ethernet Layered Testing Process


EthernetMSPP

Service Level Agreements - SLAs

Cell Site

Mobile Operator

Ethernet Backhaul Network

VoiceSwitch

Core Network

Core Network

Data Network

Data Network

Cell Site

Cell Site

CIR Service Type

One-Way Delay (msec)

One- Way Jitter

(msec)

Frame Loss Ratio

CBS(Kbytes)

BER MTTR (hours) for services

Availability

40Mbps RT <4 <1.5 <10-6 128 <10-7 <3 >99.999%

SLA Example – Mobile Backhaul

Mobile Operator

Backhaul NetworkProvider

Transport Testing


SLAs Verification

Y.1564?

RFC634

9?

RFC2544?

MSPP

Cell Site

Ethernet Backhaul Network

Core Network

Core Network

Data Network

Data Network

How do we test SLA compliance? SLA verification should include testing the link for Throughput,

Delay, Frame loss, and Jitter using various frame sizes

End result is a Pass/Fail assessment on the overall quality of the link

Multiple standards exist that address SLA verification - RFC 2544 or Y.1564 – which one is most applicable?

MSC


RFC 2544 Overview

IEEE standard designed in 1999 for testing of Network Interconnect Devices – switches, routers, etc Throughput Latency Frame loss rate Back to back System recovery & System Reset

Full range of frame sizes: 64 bytes – 1518 bytes When Ethernet went to the Telco world, so did RFC 2544

– now an industry standard for qualifying an Ethernet service Delay Variation/Jitter was not specified in RFC 2544, but is now commonly

associated with RFC 2544 testing

GigE GigE

GigE

GigE GigE

GigE


SLA Testing with RFC 2544 – Single Service

Automated RFC 2544 test validates the key parameters of a single service SLA Throughput Frame Loss Delay Jitter

Tests various frame sizes to simulate different traffic types Generates a Pass/Fail report indicating whether the link meets the SLA

requirements – Circuit Birth Certificate

Single Service SLA:CIR, Frame Loss,

Frame Delay, Jitter

MSPPEthernet

MSC

Ethernet Network

VoiceSwitch

Core Network

Core Network

Data Network

Data Network

JDSU RFC2544 Implementation• Integrated J-QuickCheck – pre-test sanity• Throughput, Latency & Jitter in one test – test in ½ time• Optional CBS – Committed Burst Size test

Ethernet

CIR


ITU Y.1564/SAMComplete – Multiple Services

ITU standard for Ethernet Service Activation testing – adopted in 2011 Verifies Multi-Service SLA compliance Automated repeatable Multi-Stream

test with pass/fail results Two phase methodology

Ramp test – Service Configuration Multi-stream test – Service Performance

Ideal Use Cases Multi-Service LTE/4G Cell Site traffic Triple Play Testers

Service 1

Service 2

Service 3

CIR2, Delay2, Jitter2



Eth

ern

et

Cir

cu

it


Y.1564 Phase 1: Service Configuration Test

Phase 1 validates the network traffic profile configuration First stage, X steps to CIR, 1 to 60 seconds each

• Verifies SLA parameters are met for rates lower and equal to CIR• SLA parameters: Throughput, Delay (FD), Jitter (FDV) and Frame Loss (FL)

Then step to EIR and MIR line rate • Verifies throughput with error in excess of CIR• Verifies Max Throughput does not go over the maximum allowed

1 to 60 sec

CIR

EIR

MIR

Max Throughput Threshold

Level below which

SLA parameters are verified

time

All traffic compliant toDelay, Jitter & Frame Loss SLA

Throughput & SLANot guaranteed

GuaranteedDrop

Policing = Discard


Y.1564 Phase 2: Service Performance Test

Phase 2 validates the quality of service of each defined service and proves SLA conformance

All services are generated simultaneously to their CIR and all KPIs are measured for all services

This phase is a single measurement done over a mid to long-term time period This procedure allows the characterization of each service and its influence on

others and ensures that they all comply to their respective SLA

Service 1

CIR

Mbps Mbps

Service 2

CIR

Service 3CIR

Transmitted traffic Measured traffic

Frame DelayFrame Delay Variation

Frame Loss Rate


Frame Loss Rate


Frame Loss Rate


JDSU Y.1564 Implementation - SAMComplete

Integrated J-QuickCheck• Pre-test before starting• Saves time on end-to-end setup

Time Saving Throughput Test• Start at CIR• If CIR fails start at -0- and step up

Easy Guided Workflow• 1. Configure test• 2. Run Test• 3. Create Report

Time Saving Troubleshooting• RFC 2544 Zeroing-In Algorithm• Scan thru Multiple Frame Sizes

Integrated CBS – Committed Burst Size Test

Time Saving• Steps to CIR X Time per

Step

• Ex: 3 steps x 60 seconds = 3 Minutes


10 Minute Break!

Followed by live demonstration!

Truespeed/RFC6349


Service Performance Issues in Ethernet/IP Networks

Recent customer poll during JDSU TrueSpeed Webinar

How many respondents said Yes - that customers still complain about network performance after they have

successfully run traditional L2/L3 service activation tests?

50%!!!


Most Common Real-World Applications use TCP

Transport4

Application

Presentation

Session

Network

Datalink

Physical1

2

3

5

6

7Web, FTP, E-Mail, IM, YouTube, FaceBook, Twitter, etc, etc, etc

TCP

IP

Ethernet

RFC-2544 & Y.1564

RFC-6349 TrueSpeedTM


Turn-up Related Problem RFC2544 Y.1564 RFC 6349

Single Service, Layer 2/3 SLA Issues (loss, jitter, etc.)

N/A

Multi-service, Layer 2/3 SLA Issues (service prioritization, loss, jitter, etc)

N/A

Demonstrate the effect of End customer TCP Window size on throughput (CPE issue)

Inadequate device buffers to handle bursty applications

Policing effects to TCP performance

Lack of TCP Testing is a Service Activation Gap

• RFC2544 and Y.1564 are essential L2/L3 turn-up steps• however end-customers run applications over TCP

• End-customers still complain that the “network is slow” and is the cause of poor application performance (i.e. Facebook, YouTube, web surfing)


When Layer 2/3 tests pass, end-customers may still complain that the network is “slow” and application performance is poor (i.e. FTP, web browsing, etc.)

JDSU RFC6349/Truespeed Test validates real-world network performance and resolves end-customer finger-pointing issues

RFC6349/Truespeed Tests: MTU Discovery - Determine Path MTU

RTT Test - Measure Round Trip Delay

Calculate Bandwidth Delay Product (Ideal TCP Window Size)

BDP = RTD * Link BW / 8

Walk the Window Test - Measure actual versus ideal throughput for a single connection at various window sizes

TCP Throughput Test - Measure and graph actual versus ideal throughput for multiple simultaneous connections

Shaping & Policing Test – Shaping, Policing and Buffers effect on TCP throughput

RFC-6349 TCP Throughput Testing


RFC 6349 = TrueSpeedTM

RFC 6349 compliant TrueSpeedTM test can be run in as little as 3 minutes by novice technicians with the “push of a button”

Innovative “Walk the Window” step automatically tests 4 TCP window sizes and highlights actual throughput vs ideal throughput

A more detailed TCP throughput test is automatically conducted and provides RFC6349 compliant metrics

TCP Efficiency = Loss MetricBuffer Delay = Network Buffer Metric

Capture/Decode, J-Mentor, J-Profiler

Passive Monitoring & Analysis


Passive Monitoring & Analysis - Capture/Decode

The ability to capture & analyze packets traveling across a live network

Allows to detect a wide range of network and protocol problems which affect the network but cannot be analyzed through active tests such as RFC 2544 or Y.1564

Hardware implementation guarantees loss-less capture at all supported line rates – tremendous advantage over PC-based Wireshark and similar applications

Monitoring via SPAN portor Network Tap

In-line Monitoring

Documents

Introduction to Ethernet Testing and TBERD-5800 Overview Jody Frey CES 763-772-8111 [email protected] Technical Support 855-ASK-JDSU (855-275-5378)