Carrier Ethernet Synchronization - Data Edgedataedge.ie/wp-content/uploads/2013/12/Part-1-Standards-and... · RAN BS GIWF UNI GIWF RAN Agg ... WCDMA 50 ppb TD-SCDMA 50 ppb 3µs

Carrier Ethernet Synchronization

Technologies and Standards

DataEdge, Dublin, May 19, 2010

PAGE 2© COPYRIGHT SYMMETRICOM (2009)

Overview

What and Where of Synchronization

Synchronization Delivery Strategies

o Synchronous Ethernet

o IEEE 1588-2008

Selecting a Synchronization Method

Network Impairments

Deployment Guidelines


Making It Happen, The Real World

Mobile broadband use will double every

year through 2013*.

► 10M new IP connections will be made

to base stations in the next 5 years,

► The mobile sector will drive the market

(products & practices).

Pure packet deployment has been slow

… driven by concerns for voice quality.

Synchronization challenges include:

► Selecting the strategy

► Knowing the goals

► Engineering for cost, performance &

simplicity

* Cisco® Visual Networking Index (VNI) Mobile Forecast

** Source. Infonetics

*** Source. Heavy Reading

0

1

2

3

4

5

6

CY'07 CY'08 CY'09 CY'10 CY'11 CY'12 CY'13

Mil

lio

ns

**BaseStation Backhaul Connections

Non-IP Connections IP Backhaul Connections

***Live Packet Backhaul Deployments


MEF: Where is Sync Required?

►MEF 2 Requirements and Framework for Ethernet Service Protection

►MEF 3 Circuit Emulation Service Definitions, Framework and Requirements in MEN

►MEF 4 Metro Ethernet Network Architecture Framework Part 1: Generic Framework

►MEF 6.1* Metro Ethernet Services Definitions Phase 2

►MEF 7 EMS-NMS Information Model

►MEF 8 Implementation Agreement for the Emulation of PDH Circuits over MEN

►MEF 9 Abstract Test Suite for Ethernet Services at the UNI

►MEF 10.1* Ethernet Services Attributes Phase 2*

►MEF 11 User Network Interface (UNI) Requirements and Framework

►MEF 12 Metro Ethernet Network Architecture Framework Part 2: Ethernet Services Layer

►MEF 13 User Network Interface (UNI) Type 1 Implementation Agreement

►MEF 14 Abstract Test Suite for Traffic Management Phase 1

►MEF 15 Requirements for Management of Metro Ethernet Phase 1 Network Elements

►MEF 16 Ethernet Local Management Interface

►MEF 17 Service OAM Framework and Requirements

►MEF 18 Abstract Test Suite for Circuit Emulation Services

►MEF 19 Abstract Test Suite for UNI Type 1


►MEF 21 Abstract Test Suite for UNI Type 2 Part 1: Link OAM

►MEF 22 Mobile Backhaul Implementation Agreement

* MEF 10 .1 replaces and enhances MEF 10 Ethernet Services Definition Phase 1 and replaced MEF 1 and MEF 5. MEF 6.1 replaced MEF 6.


MEF: Where is Sync Required?

►MEF 2 Requirements and Framework for Ethernet Service Protection

►MEF 3 Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks►MEF 4 Metro Ethernet Network Architecture Framework Part 1: Generic Framework

►MEF 6.1 Metro Ethernet Services Definitions Phase 2

►MEF 7 EMS-NMS Information Model

►MEF 8 Implementation Agreement for the Emulation of PDH

Circuits over Metro Ethernet Networks ►MEF 9 Abstract Test Suite for Ethernet Services at the UNI

►MEF 10.1 Ethernet Services Attributes Phase 2*

►MEF 11 User Network Interface (UNI) Requirements and Framework

►MEF 12S Metro Ethernet Network Architecture Framework Part 2: Ethernet Services Layer


►MEF 14 Abstract Test Suite for Traffic Management Phase 1

►MEF 15 Requirements for Management of Metro Ethernet Phase 1 Network Elements

►MEF 16 Ethernet Local Management Interface

►MEF 17 Service OAM Framework and Requirements

►MEF 18 Abstract Test Suite for Circuit Emulation Services►MEF 19 Abstract Test Suite for UNI Type 1


►MEF 21 Abstract Test Suite for UNI Type 2 Part 1: Link OAM

►MEF 22 Mobile Backhaul Implementation Agreement

* MEF 10 .1 replaces and enhances MEF 10 Ethernet Services Definition Phase 1 and replaced MEF 1 and MEF 5. MEF 6.1 replaced MEF 6.


Carrier Ethernet Use cases for MBH:

Packet Offload or Full Ethernet

Packet Offload / Carrier Ethernet – Use Case 1

Carrier Ethernet

Network

Legacy Network

Non-Ethernet I/F

UNI

Non-Ethernet I/F

UNIGIWFRAN BS RAN AggGIWF

Carrier Ethernet Network

U

N

I

U

N

I

RAN BS RAN Agg

Full Ethernet – Use Case 2

BOTH CASES NEED SYNCH


MEF 8: Carrier Ethernet Private

Line (EPL)

Designed for TDM Replacement

Point-to-Point

EVC

Carrier Ethernet Network

CE

CE

CE

ISP

POP

Data Center Service

Internet


MEF 8: E-Tree (EP-Tree or EVP-

Tree)

A

B

C

EVC1

Root

Leaves

Efficient use of ISP router port

One subnet to configure on ISP router

Simple configuration

A, B, C can’t see each other’s traffic

Some limits on routing protocols used

Designed for mobile backhaul

and triple-play infrastructure


at the Wireless Air Interface …

Variations in the Radio frequency of

cellular base-stations affect the ability of

the system to hand-off calls without

interruption.

F1+ F

F1

T1 T2

+/- 50ppb

+/- 50ppb

Time

Mobile cannot lock to

BTS2

and call is dropped

BTS2 drifts outside 50ppb window

BTS 1

BTS 2

Mobility Standard Frequency Time/Phase

CDMA2000 50 ppb Range: <3µs to <10µs

GSM 50 ppb

WCDMA 50 ppb

TD-SCDMA 50 ppb 3µs inter-cell phase ∆

LTE (FDD) 50 ppb

LTE (TDD) 50 ppb *3µs inter-cell phase ∆

LTE MBMS 50 ppb *5µs inter-cell phase ∆

WiMAX (TDD) 50 ppb inter BTS Typically 1 - 1.5 µs

Backhaul 1 to 16 ppb

* Standards being consolidated 50 ppb or 5 x 10-8

MBH Sync Requirements


Mobile Back-Haul (MBH)

► First phase :

► Synchronization is delivered

1 outside of the Ethernet transport network

2 using a packet based method

(IEEE1588 PTP standard, or proprietary solutions)

► Subsequent (future) phases:

► Other synchronization methods

► Synchronous Ethernet

MEF 22 Mobile Backhaul Implementation Agreement

Approved as an official MEF Specification in January 2009.


NGN Synchronization Standards

ITU-T Frequency Time

Definitions-Terminology G.8260 G.8260

Basics G.8261 (G.pactiming) G.8271

Network Jitter-Wander G.8261

Network PDV G.8261.1 G.8271.1

Clock-SyncE G.8262

Clock-Packet G.8263 G.8272

Methods-SyncE G.8264

Methods-Packet G.8265 G.8275

PTP Telecom Profile G.8265.1 G.8275.1

PTP Telecom Profile 2 G.8265.2

IEEE 1588-2008IEEE Standard for a Precision Clock Synchronization Protocol

for networked measurement & control systems.

MEF MEF 3, MEF 8, MEF 18, MEF 22 MEF Standards that Refer to

or Require Synchronization.


Overview




o IEEE 1588-2008


Network Impairments



Sync Delivery Strategies

Synchronization Strategies

E1/SDH Hybrid

Shorter term strategy based on use of legacy systems (higher

OPEX). Bandwidth & 4G/LTE limit long term suitability.

Adaptive Clock Recovery

A vendor specific book-end solution used to support TDMoIP

services. ACR methods are being superseded by IEEE 1588.

GPS Radio at Base Stations

Good performance, supporting wide range of applications. Cost

and autonomy define deployment adoption.

Synchronous Ethernet

An end-to-end solution that depends on the uninterrupted

SyncE deployment.

IEEE 1588-2008

A standards based solution with the flexibility, lowest cost, and

high rate of adoption (driven by mobile sector).

E1/SDH

Packet

ACR

Packet

SyncE

Packet

1588-v2

Packet



► Proposed in September 2004 to use the physical layer to transport a

frequency reference in order to

o Provide G.811 traceability to applications

o Provide a timing quality independent of traffic payload

► It was decided to align SyncE on SDH

o to avoid defining a new synchronous hierarchy

o To allow a mix of SDH and SyncE NEs in the G.803 reference chain

► Defined by 3 ITU-T SG15 recommendations (consented in Feb 2008)

o G.8261 for architecture and network limits

o G.8262 for the definition of the clock

o G.8264 for the definition of the SSM



Architecture

► In order to provide interworking between SyncE and SDH

o A chain of 20 SDH NEs must be replaceable by 20 SyncE NEs

o A chain of 20 NEs can mix SDH and SYNCE NEs

o An NE can be equipped with both SDH and SyncE ports

► The SyncE NE

o Must have a clock compatible with SDH/SONET

o Recovers timing from a synchronous Ethernet signal, with an SSM

o Must be able to recover the data from an Ethernet signal

o Must be able to provide traceablity via SSM


SyncE clock – G.8262

► Compliance with SDH implies that SyncE clocks are based on G.813

► Jitter is related with clock recovery

► Wander is due to noise accumulation in a chain of NE/clocks.

► Frequency pull-in range

o Must be 100 ppm on the port so that data of legacy Eth can be

processed

o Must be 4.6 ppm at clock input to comply with SDH clocks

100 ppm

TXTX

RXRX

4.6 ppm

TXTX

RXRX

TX

RX

TXTX

RXRX

Ext.Sync

Inaccurate

100 ppm

4.6 ppm

TX

RX

Accurate

SyncE Switch Asynchronous

Switch

Async Switch

SyncE Switch


SSM Transport – G.8264

► The SSM is transported in the ESMC Ethernet Synchronization

Messaging Channel

► Two types of messages are transmitted

o An event message sent immediately in case of SSM change

o A heartbeat message

Sent at a rate of about 1 Hz

No message for 5 seconds means ESMC failure

► Quality Level data is mapped into a TLV format

o Future information might be mapped according to TLV format


IEEE 1588 Overview

IEEE 1588-2008 …

► Is a protocol definition, not a product,

► is known as Precision Time Protocol (PTP)

► -2008 is also referred to as version 2

(with the Telecom Profile)

► is the second version of a mature IEEE

standard,

► defines how to transfer precise time over

networks. It does not define how to

recover frequency or high precision time of

day.

► The challenge is to convert packets to

traceable Time & Frequency, and cost

effectively.


1588 – Precision Time Protocol

• Each “event message” flow (sync,

delay_req) is a packet timing signal

• Master frequency determined by comparison

of timestamps in the event message flows

• e.g. comparison of t1 to t2 over multiple sync

messages, or t3 to t4 in delay_req messages

• Time offset calculation requires all four

timestamps:

• Client time offset = (t1 – t2) + (t4 – t3)

• assumes symmetrical delays

(i.e. the forward path delay is equal to the

reverse path delay)

• Time offset error = fwd. delay – rev. delay

2

2

Master Clock Time Slave Clock Time

Data atSlave Clock

Follow_Up messagecontaining true value of t1

Delay_Resp message

containing value of t4

Sync message

Delay_Req message

timet1, t2, t3, t4

t1, t2

t2

t1, t2, t3

t2

t3

t1

t4


The PTP Protocol – Main Features

21

Rate of Delay_req/Delay_resp Transactions can be adjusted to cope with

Target frequency/time accuracy

Network conditions

64 transactions/sec/client is a good, practical value

30 to 128 transactions/sec range

PTP supports Unicast and Multicast

Unicast: more flexible, supported by all networks

Multicast: required later with larger numbers of clients

e.g., Femtocells

When core/access networks support it

Boundary Clocks

BC serving a sub-network can be sync’d to a remote St1 server

No need for a local Stratum1 reference



► Boundary Clocks

► Acts as a slave clock at the port that connects to the grand master, and as a

master to all other ports

► Therefore, it isolates the “down stream” clocks from any delays and jitter within the

switch

► Creates master-slave synchronization hierarchy

Grandmaster

S

Slave

Clock

Boundary

Clock

Transparent

Clock

Ordinary

Clock

S

M M

M

S

M

S

Ordinary

Clock

S

Ordinary

Clock

S

Slave

Clock



► End-to-end transparent clock► Alternative (simpler & cheaper implementation) to boundary clocks

► Switch/Router modifies time stamps in packets to adjust for delays introduced by Switch/Router itself

► Residence time is accumulated in special field (correction field) of PTP message event or associated

Follow_Up message

► Peer-to-peer transparent clock► Similar to end-to-end transparent clock but computes link delay in addition of residence time

PHY PHY

MACMAC

PORT1 PORT2

Switch1

PHY PHY

MACMAC

PORT2

Switch2

PORT1

Link time correction

Residence time correction

Residence time correction


Overview




o IEEE 1588-2008


Network Impairments



Selecting The Sync Strategy

► TDM circuits are the most widely used

method today.

► Will still be used beyond 2012

► SyncE & IEEE 1588 are standards based

► Supports interoperability

► Addresses multiple applications

► Cost effective & reached viability

► Can be used together

► Adaptive Clock Recovery is proprietary &

a bookend offer.

► No inter-operability

► Multiple parallel systems

► High engineering, management &

maintenance effort

► GPS & other methods will be used on

limited scale.

Source. Heavy Reading


Defining The Goals

Select the frequency goals:

► ITU-T G.823 sync mask

► Vodafone Lab Acceptance Mask

(G.823 sync mask + 1ppb)

► ITU-T G.823 traffic mask

► 1 - 15ppb (short & long term)

► Other proprietary masks

Define the Absolute Time/Phase goals:

► 3 µS absolute phase accuracy

► 5 µS absolute phase accuracy

► Other goals

What is the Time of Day interface?

FDD Objectives Time & Phase Objectives

0.1 1 10 100 1000 10000 100000

Observation Interval (sec)

100

1000

10000

MTIE

(nsec)

0.1 7.3 20 2000 100000

732732

20002000

5330


SyncE or IEEE 1588-2008

IEEE1588 needed when:

► Applications need time/phase

► Applications with leased services (no end-end SyncE path assurance)

► Transport other than switched Ethernet

Attribute IEEE 1588 SyncE

Capability Frequency, Time Frequency

Layer UDP/IP or Layer 2 Physical

Distribution In-band 1588 Packets Physical layer

Schema Point to multi-point Point to point

Distribution In-band 1588 Packets Physical layer

Transport MediaNative Ethernet, xDSL, Microwave

Native Ethernet

Inter-Operability

Standards based Grandmaster & slave. Independent of intermediate nodes.

Standard based SyncE switches only

Relevant Standards IEEE 1588, ITU G.8264 ITU G.8261/2/4


Overview




o IEEE 1588-2008


Network Impairments


PAGE 29© COPYRIGHT SYMMETRICOM (2009)29 19/05/2010

Packet Delay Variation

Packet

Environment

FIFO BuffersVoice

Video

Data

Voice

Video

Data

Main Delay Variation Causes

Waiting time jitter in network elements

Routers/switches congestion

Extended packet loss, Network outages/re-routing: may cause holdover from

lack of information

Note: absolute delay, even high, is not a problem for sync technologies


Class of Service Traffic Separation

► MEF provides service mapping guidelines for the number of CoS classes to use

► Bundles traffic types into limited number of CoS classes

► Describes CoS class performance requirements

Service

Class Name

Example of Generic Traffic Classes mapping into CoS

4 CoS Model 3 CoS Model 2 CoS Model

Very High

(H+)

Synchronization - -

High (H) Conversational,

Signaling and

Control

Conversational and

Synchronization,

Signaling and Control

Conversational and

Synchronization,

Signaling and Control,

Streaming

Medium (M) Streaming Streaming -

Low (L) Interactive and

Background

Interactive and

Background

Interactive and

Background

PAGE 31© COPYRIGHT SYMMETRICOM (2009) 19/05/2010

CoS/QoS- Priorities

► Even with priority schemes packet delay variation can be significant

Large Low priority Packet 1000 Bytes+

High priority Packet

At 100 Mbit/s 1000 byte packet = 8 x 1000 / 100 x 106 = 80 s

At 10 Mbit/s 1000 byte packet = 8 x 1000 / 10 x 106 = 0.8ms


Typical PDV Profile

32

Minimum Delay

Packets

PDV Tail

Distribution


Packet Network Characterization

Key characteristics:

• variance of minimum delay

• frequency of packets with minimum delay

10 switches, 20% load

10 switches, 40% load 10 switches, 80% load

10 switches, 60% load

Packets experiencing minimum delay


Sample Field Trial Result

Live deployed network in Europe

Sync was tested over MPLS-over-SDH, 2 weeks

Moderately loaded network ring (7 hops in one direction, 15 hops in the other)

TP500 Frequency ~0.1 ppb most of the time, worst case performance over

two weeks shown above, ~0.3 ppb


Sample Field Trial – MTIE

35Symmetricom Confidential

G.823 traffic

15 ppb

G.823 1 ppb

TP500

Same live network

Meets G.823 Sync Mask + 1 ppb with margin


SHDSL Field Trial: 0.26ppb


G.8261 Test Case 12: Description

Test case 12 models the “Static” Packet load.

Test Case 12 must use the following network conditions:

•Network disturbance load with 80% for the forward direction

(Server to Client)

•20% in the reverse direction (Client to Server) for 1 hour

•The test measurements should start after the clock recovery

is in a stable condition.


G.8261 Test Case 12: Phase


Other Freq+Phase Performance

► 10 hops, G.8261 traffic type and load variation

► Using carrier grade routers/switches► Pass = pass G.823PDH (sync) mask and <=1us phase accuracy

G.8261 Test

Case

Description Duration Result Comments

Test Case 13 Large, sudden

changes in traffic

load

6 hours Pass 2nd hardest test

Test Case 14 Slow, steady

traffic ramp up

and down

24 hours Pass Hardest Test

Test Case 17 Network failures

causing routing

changes with

impairment

2 hours Pass


Overview




o IEEE 1588-2008


Network Impairments


PAGE 41© COPYRIGHT SYMMETRICOM (2009) 41

Empirical Behaviour

Number of switches

2 4 6 8 10

Limit of operational area

Varies with:

Application requirements

Type of switches

Traffic loading patterns

Slave performance

Local oscillator stability

clock stability compliant with application

clock stability non-compliant with application

100%

80%

60%

40%

20%

0%

Tra

ffic

lo

ad

on

netw

ork

► Clock stability, showing dependence on network size and traffic load

► Green Zone expanding

► 5 nodes met under any conditions

► 10 nodes met under most network configurations

► Focussing on 20 nodes


Packet Sync Planning Strategy

► Step 1: Identify PTP slave locations

► Step 2: Identify suitable locations for PTP Grand Masters► Masters should be distributed towards the edge of the network

► Rule of thumb: For minimum dependency on traffic load, the PTP Master should be no more than 8/10 switches from the PTP Slave

► Step 3: Check that► Grand Master capacity constraints are not exceeded

► The “8/10 switch distance rule” is not violated, or that the traffic load is appropriate to the network span

► Step 4: Field trial – measure performance on critical links► Monitor TIE, MTIE, TDEV of output timing signals

► Also monitor PDV of packet network to verify suitability for timing distribution

► Step 5: Ongoing monitoring of critical or selected links to ensure synchronization quality is maintained in operation


Redundancy Strategy

► Redundancy Strategy

► Separate Grand Masters, or built-in redundancy?

► Best Master Clock Algorithm, or manual configuration?

► BMCA requires multicast message distribution

► BMCA may elect a grandmaster that is not close to the slave

► Unicast slaves are configured with the correct master address

► Unicast slaves can switch to an alternate master in the event of a master failure

► Symmetricom product redundancy features

► TP5000 has redundant power and redundant clock cards

► Multiple PackeTime blades can be placed in an SSU shelf to give redundancy


Security

► A PTP slave needs to be able to trust that timing

messages:

► Come from the correct master

► Have not been tampered with in transmission

► IEEE1588-2008 defines an experimental security protocol

► This is not widely implemented at present

► Network-based security methods

► Use VLANs to prevent distribution of timing messages outside of the

defined VLAN

► In a Metro Ethernet network, use E-Line or E-LAN services

► Similar to VLANs, running over a public Metro Ethernet network

► In an MPLS network, use pseudo-wires

► Symmetricom recommend the use of network-based

security


Multicast vs. Unicast

► Unicast facilitates the use of distributed masters

► Allows easier planning of the synchronization network

► Redundancy strategy can be carefully managed

► Unicast packets propagate uniformly through the network

► Multicast requires packet replication at each network element – may add

variable delay

► Upstream multicast often not supported in telecom networks

► Symmetricom recommend use of unicast transmission in telecom

synchronization networks


Frequency of Timing Packets

► Frequency required is dependent on several factors

► Amount of noise in the network

► Local oscillator stability

► Efficiency of clock servo algorithm

► Doubling number of timing packets does not double the

performance of the system or the reach of the network

► Better to manage traffic load than increase timing message frequency

► PTP slave determines the message rate required

► Recommended settings for the TP500 PTP slave:

► 2 announce messages per second

► 64 sync messages per second

► 64 delay_request messages per second


Quality of Service

► Use simplest QoS techniques, where available

► In general, switches/routers optimized for maximum throughput with

minimum intervention

► Example: rate metering for bandwidth consumption requires

computational effort, which causes delay

► Depends heavily on implementation technique

► Symmetricom recommended traffic classes:

► Diffserv Expedited Forwarding (EF) Class

► IEEE 802.1 p-bit marking of 5 or above

► UMTS conversational class

(3GPP TS23.107, normally mapped to p-bit = 5)


Telecom Profile

► “Telecom Profile” for PTPv2 under development in ITU-T Synchronization Group► Set of options and parameters for telecom usage, to ensure

interoperability of PTP equipment

► Likely to consist of separate profiles for frequency and time synchronization

► De-facto understanding of telecom profile used in inter-operability trials► Unicast-only operation

► PTPv2 short messages, running over IPv4/UDP/Ethernet

► Two-way operation (includes delay_request/response)

► Manual configuration (no Best Master Clock Algorithm)

► No on-path support (boundary clocks/transparent clocks)

► No encryption or authentication support

► De-facto profile supported by Symmetricom products, as will future profiles to be defined by ITU-T

Thank You!

Documents

Carrier Ethernet Synchronization - Data Edgedataedge.ie/wp-content/uploads/2013/12/Part-1-Standards-and... · RAN BS GIWF UNI GIWF RAN Agg ... WCDMA 50 ppb TD-SCDMA 50 ppb 3µs