synchronization over packet networks

48
Synchronization over Packet Networks April 2008 Maamoun Seido – System Architect

Upload: fred-madison

Post on 21-May-2017

219 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: Synchronization over Packet  Networks

Synchronization over Packet Networks

April 2008Maamoun Seido – System Architect

Page 2: Synchronization over Packet  Networks

[Page 1]

Solutions for Next-Generation Timing

Two solutions are becoming dominant– Physical Layer Synchronization or Synchronous Ethernet

(SyncE)– Protocol Layer Synchronization or Timing Over Packet (ToP)

Each technology has its place in Next-Generation Timing Architectures

Page 3: Synchronization over Packet  Networks

Physical Layer Synchronization –Synchronous Ethernet (SyncE)

Page 4: Synchronization over Packet  Networks

[Page 3]

What is SyncE?

Packet networks are asynchronous based on +/-100ppm oscillatorSyncE is a physical layer technologyCircuit-switched services require synchronous transmissionPacket networks supporting Synchronous Ethernet can carry circuit-switched servicesSyncE is a point-to-point technology

Ethernet

ZL30106ZL301061GbEPHY ZL30106ZL30106

1GbEPHYZL30106ZL30106

1GbEPHY

+/-100 ppmFree-run

+/-100 ppmFree-run

+/-100 ppmFree-run

Data Data

Synchronous Ethernet

PLL PLL PLL

ZL30106ZL301061GbEPHY ZL30106ZL30106

1GbEPHYZL30106ZL30106

1GbEPHY

BITS/SSU

PRS

Data Data

Page 5: Synchronization over Packet  Networks

[Page 4]

Access Metro Core

Why SyncE?

PSN

DWDMDWDM

SyncE

Legacy FAX

PON ONT/ONUACCESS

DLC or OLT

IAD

SOHO/Residential

SyncE allows operators to converge services onto a single cost-efficient networkSyncE provides a simple, reliable, and well understood method of distributing synchronization over the physical layer through packet networksSyncE is based on a well established SONET/SDH synchronization distribution model

Page 6: Synchronization over Packet  Networks

[Page 5]

SyncE Clock Solution Requirements

Requirement Function

Wander Filtering Meet standard requirements of wander filtering (ITU G.8262)

Low Jitter Generation Meet jitter specifications for GE and 10GE physical interfaces

Clock Rate Conversion Tx Path: System Clk to Ethernet PHY Clk Rx Path: Ethernet PHY clk to System Clk

Clock for GE and 10GE WAN & LAN PHY

Generate 25MHz, 125MHz, 155.52MHz and 156.25MHz clock rates

Page 7: Synchronization over Packet  Networks

[Page 6]

SyncE Advantage

Existing TDM system can be easily upgraded– Add new GE or 10 GE line cards that support SyncE timing

Extract system clock and convert into SyncE clockRate convert SyncE clock to internal synchronization clock

Clock accuracy similar to what is achieved today using SONET/SDH and PDH timingPerformance is independent of network configuration and trafficConsented standards– G.8262 defining the SyncE clock specifications– G.8264 defining the Ethernet Synchronization Messaging Channel

Page 8: Synchronization over Packet  Networks

[Page 7]

SyncE Challenge

Cannot transfer Time-of-Day information– Single path timing hence

cannot calculate round-trip delays

Allow for the transfer of the “physical timing flow only”– If an independent “service

timing flow” is required, adaptive or differential protocol layer timing is needed

Physical Timing FlowService Timing FlowMessage Timing Flow

Physical Timing FlowService Timing FlowMessage Timing Flow

ETH

ETY

PDH Stream

Logical Flows

Logical FlowsETH

ETY

PDH Stream

Logical Flows

Logical Flows

* ITU G.8264 Figure I.1 Example of Timing Flows

Page 9: Synchronization over Packet  Networks

Protocol Layer Synchronization –Timing-over-Packet (ToP)

Page 10: Synchronization over Packet  Networks

[Page 9]

The ToP ConceptToP allows the transfer of timing over asynchronous packet networksThe ToP Server transmits timing packets over the asynchronous data path The ToP Slave recovers timing from the timing packets

PLL

Timing Distribution Using ToP

BITS/SSUPLL

ZL30106ZL301061GbEPHYZL30106ZL30106

1GbEPHY

PRS

TimingPackets

+/-100ppm

DataPackets

ZL30106ZL301061GbEPHY

+/-100ppm

ServerToP

Engine

PLL

TimingPackets

TimingPackets

ZL30106ZL30106

1GbEPHY

SlaveToP

Engine

Page 11: Synchronization over Packet  Networks

[Page 10]

Why ToP?RAN Metro Core

BasestationController

PSN

DWDMDWDM

ToP ServerToP Client

2G BTS

3G Node B

Server to Clientpacket flow

ToP allows operators to offer synchronous services over an existingpacket network infrastructureToP provides a method of distributing frequency synchronization and time-of-day alignment over packet switched networksToP functionality is only required at both ends of the connection

Page 12: Synchronization over Packet  Networks

[Page 11]

ToP Clock Solution Requirements

Requirement Function

Timing-over-Packet Clock Recovery Algorithms

Client: filter through packet network impairments and generate accurate timing data to drive output clock

Time Stamp Generation Server: convert input reference clock to time stamp information

Clock Synthesis Client: convert algorithm filtered timing information to desired output clocks

Accurate Time Insertion Server & Client: packet interface (MAC) insert timing information at accurate instances

Wander Filtering Server: meet standard requirements of wander filtering

Accurate Holdover Client: ride through periods with no valid timing information

Page 13: Synchronization over Packet  Networks

[Page 12]

ToP Advantage

Transfer Time-of-Day

Allow timing to be supported in non-synchronous packet network (i.e. already deployed packet switched networks)

Can operate over another service provide network– It provides a method for sending

independent service timing flow

Page 14: Synchronization over Packet  Networks

[Page 13]

ToP Challenge

Several protocols are available RTP (CES IWF), NTP (IETF), PTP (IEEE1588 ver2) – details available in supporting slides

Time-of-Day (ToD) accuracy limited by network delay asymmetry between forward and reverse paths– Time-of-Delay calculations as based on symmetric path delay

Performance is dependent on network topology and on network loading conditions – as detailed in following slides

Page 15: Synchronization over Packet  Networks

[Page 14]

ToP: Network Topology and Loading Conditions – 1

G.8261 Test NetworkTCXOG.8261 Traffic Model 2 (dominated by large packets)Constant Network Traffic

Page 16: Synchronization over Packet  Networks

[Page 15]

ToP: Network Topology and Loading Conditions – 2

MTIE to meet G.824 Synchronization Mask 1Hz phase alignment of +/-3usec or better Fractional Frequency Offset f = +/-15ppb or better

Test Number

Number Of Hops

Network Load (%)

ToP Packet Rate(sync/delay_req)

MTIE(ns)

Sync Mask (1us)

FFO(+/-ppb)

1Hz Alignment(+/- ns)

1 7 80 64/16 602 Pass 8 7252 8 70 64/16 447 Pass 8.5 5253 9 70 64/16 620 Pass 8 7204 10 60 64/16 448 Pass 7 650

Page 17: Synchronization over Packet  Networks

[Page 16]

Applications: Deployment in Wired and Wireless Telecom Infrastructure

SONET/SDH

DWDM

Mobile Switching Center

ADM ADMADM

PBX

Next Gen DLC

Legacy FaxBroadbandModem

Mobile Switching Center

GSM on

CDMABasestation

CDMABasestation

SDH SDH

PDHPDH

PDH PDHGPS

SDH

PDH

Multi-serviceSwitch

GSM Basestation Basestati

Frequency accuracy, limits channel interference between Carrier frequency bands

ToD phase alignment, limits coding time division overlap

Frequency accuracy, matches sampling clocks and limit buffer slips

Page 18: Synchronization over Packet  Networks

[Page 17]

Applications: Deployment in Wired and Wireless Telecom Infrastructure

SONET/SDH

DWDM

Mobile Switching Center

ADM ADMADM

IP PBX

Next Gen DLC

FaxBroadbandModem

Mobile Switching Center

UMTS-FDDNode B UMTS-FDD

Node B

UMTS-TDDNode B

UMTS-TDDNode B

PSNPSN

PSNPSN

Synchronization over PSN objective:Frequency Lock with ToD Correction

Synchronization over PSN objective:Frequency Lock

Multi-serviceSwitch

Page 19: Synchronization over Packet  Networks

[Page 18]

SummarySyncE and ToP technologies are available to provide synchronous services over Packet NetworksSynchronous Ethernet

– SyncE can be used in existing networksLine cards of existing equipments can be upgraded to support SyncE

– SyncE can be used in greenfield networks New equipment can be deployed with SyncE support

ToP– ToP can be deployed in existing asynchronous packet switched networks

Only the end nodes (master and slave) need to be upgraded to support ToP

– ToP can be used in greenfield networks to support ToD– Top can be used for sending service timing over other service provider

network

Carriers and equipment vendors are asking for both NOW!

Page 20: Synchronization over Packet  Networks

Standards

Page 21: Synchronization over Packet  Networks

[Page 20]

Standards Organizations

Multiple standards bodies are involved with synchronization over Packet Networks– International Telecommunication Union – ITU-T

Defining synchronization requirements for Packet Networks– Institute of Electrical and Electronic Engineer – IEEE1588

Defined the protocol to be used to carry synchronization over the Packet Network

– The Internet Engineering Task Force – IETF NTP version 4TICTOC (Timing over IP Connections and Transfer Of Clock)

– ATIS – Optical Transport and Synchronization Committee –OPTXS-SYNC

Page 22: Synchronization over Packet  Networks

ITU-T

Page 23: Synchronization over Packet  Networks

[Page 22]

ITU, SG15, Question 13

ITU-T G.8261 – Timing and Synchronization aspects in Packet Networks– First recommendation published in May 2006– New revision consented in February 2008– Defines timing and synchronization elements of packet networks– Specifies the minimum equipment tolerance to jitter and wander

at the boundary of the packet networks at TDM interfaces– Outlines the minimum requirements for the synchronization

function of network elements– Editor: Stefano Ruffini from Ericsson

Page 24: Synchronization over Packet  Networks

[Page 23]

ITU, SG15, Question 13 (cont’d)ITU-T G.8262 (former G.paclock) – Timing characteristics of Synchronous Ethernet Equipment slave clock (EEC) – Recommendation consented June 2007 – Amendment consented in February 2008 to align G.8262 to

G.8261 and G.8264– Outlines minimum requirements for timing devices used in

synchronizing network equipment that uses Synchronous Ethernet

– Defines clock (PLL) performance characteristics such as wander, jitter, phase transients, clock bandwidth, frequency accuracy, holdover, etc…

– Synchronous Ethernet clocks (EEC) are based on G.813 (Timing characteristics of SDH equipment slave clocks – SEC) performance characteristics

– Editor: Silvana Rodrigues from Zarlink

Page 25: Synchronization over Packet  Networks

[Page 24]

ITU, SG15, Question 13 (cont’d)

ITU-T G.8264 (former G.pacmod) – Distribution of timing through packet networks– First recommendation consented in February 2008– Outlines the requirements on Ethernet networks with respect to

frequency transfer– Specifies the SSM transport channel, namely the Ethernet

Synchronization Messaging Channel (ESMC) protocol behavior and message format

– Details the required architecture in formal modeling languageTiming flows are used to describe where and how time and timing will

flow through the architecture– Editor: Michael Mayer from Nortel

Page 26: Synchronization over Packet  Networks

[Page 25]

ITU, SG15, Question 13 (cont’d)ITU-T G.paclock-bis

– Under development– Outlines minimum requirements for timing devices used in synchronizing

network equipment as defined in G.8261– Supports clock distribution based on packet-based methods (e.g.

Adaptive and Differential Clock Recovery)– Defines the minimum requirements for clocks in the network elements

including clock accuracy, noise transfer, holdover performance and noise generation

– Editor: Silvana Rodrigues from ZarlinkITU-T G.pacmod.bis

– Under development– Defines various aspects related to timing distribution in packet networks

and to its modeling– IEEE-1588 profile– Editor: Michael Mayer from Nortel

Page 27: Synchronization over Packet  Networks

[Page 26]

ITU-T TDM Synchronization Standard vs. Packet Synchronization Standard

G.8264, G.781G.783, G.781Synchronization layer functions, Functional Blocks, Timing Flow, and SSM

Packet NetworkTDM NetworkRequirements

G.8262G.812 (Type IV), G.813Equipment Clock Specification

G.8261G.803, G.810G.823, G.824, G.825

Functional Architecture and Network Synchronization Requirements

Table XI.1/G.8261 - TDM synchronization Recommendation family versus the packet synchronization Recommendation family

Page 28: Synchronization over Packet  Networks

Synchronous Ethernet(ITU-T Recommendation

G.8262 and G.8264)

Page 29: Synchronization over Packet  Networks

[Page 28]

ITU-T Recommendation G.8262

EEC clocks are based on G.813 and G.812 type IVAllow interworking with the existing SONET/SDH synchronization network

S

S

S

S

S

S

S

SSU

SSU

E

E

E

E

S

S

S

SSU

SSU

S

H

S

H

S

S

S

SSU

SSU

a) b) c)Figure D.1 /G.8261 - Synchronization chains implemented with different types of NEs

Page 30: Synchronization over Packet  Networks

[Page 29]

G.8262 Clock Parameters

Equivalent to G.813 Table 4 for MTIEEquivalent to G.813 Table 5 for TDEV

Equivalent to G.813 Table 1 and Table 2 for MTIEEquivalent to G.813 Table 3 for TDEV

Wander in locked mode

Specified in IEEE 802.3Specified in IEEE 802.3Jitter

G.8262EEC-Option 2

G.8262 EEC-Option 1

G.8262 Parameter

Equivalent to G.813 Table 11 for TDEV

Equivalent to G.813 Table 8 for MTIEEquivalent to G.813 Table 9 and 10 for TDEV

Wander tolerance

Equivalent to G.812 Type IV Table A.2

Equivalent to G.813 Option 1Pull-in/hold-in

Equivalent to G.812 Type IV Table A.1

Equivalent to G.813 Option 1Frequency Accuracy

Page 31: Synchronization over Packet  Networks

[Page 30]

G.8262 Clock Parameters (cont’d)

Equivalent to G.812 Type IV Table A.18

Equivalent to G.813 Figure 14Long-term phase transient response (Holdover)

Equivalent to G.813 Table 14 Equivalent to G.813 Figure 12 Short-term phase transient response

For further study (G.813 clause 10.3 (item b) is also for further study)

Equivalent to G.813 clause 10.3 (item a)

Phase response to input signal interruptions

G.8262EEC-Option 2

G.8262 EEC-Option 1

G.8262 Parameter

The same as in short-term phase transient response

Equivalent to G.813 clause 10.4 (item a)

Phase discontinuity

Equivalent to G.813 Section 9 (item b)

Equivalent to G.813 Section 9 (item a)

Noise transfer

Specified in IEEE 802.3Specified in IEEE 802.3Jitter Tolerance

Page 32: Synchronization over Packet  Networks

[Page 31]

SSM for Synchronous Ethernet

For existing SDH-based SSM, the SSM message is carried in fixed locations within the SDH frameIn the case of Synchronous Ethernet, there is no equivalent of a fixed frame– SSM must be carried over a protocol

For Synchronous Ethernet SSM, the message channel is an Ethernet protocol based on an IEEE Organization Specific Slow Protocol (OSSP) The details of SSM for Synchronous Ethernet is detailed in ITU-T Recommendation G.8264

Page 33: Synchronization over Packet  Networks

[Page 32]

Sync Selection Based on SSM

SSM messages represent the quality level of the system clocks located in the various network elementsQuality level refers to the holdover performance of a clock– For the purposes of SSM selection, the G.8262 EEC option 1

clock is treated as a G.813 Option 1, while the EEC Option 2 is treated as a G.812 Type IV clock (i.e., QL-SEC and QL-ST3, respectively)

SSM CodeMessageClock

1010QL-EEC2EEC2

1011QL-EEC1EEC1

Table 10.1/G.8264: SSM messages for Synchronous Ethernet

Page 34: Synchronization over Packet  Networks

[Page 33]

Ethernet Synchronization Messaging Channel (ESMC) Format

Octet number Size Field

1-6 6 octets Destination Address =01-80-C2-00-00-02 (hex)

7-12 6 octets Source Address

13-14 2 octets Slow Protocol Ethertype = 88-09 (hex)

15 1 octets Slow Protocol Subtype =0A (hex)

16-18 3 octets ITU-OUI = 00-19-A7 (hex)

19-20 2 octets ITU Subtype

21 4 bits Version

1 bit Event flag

3 bits Reserved

22-24 3 octets Reserved

25-1532 36-1490 octets Data and Padding (See point J)

Last 4 4 octets FCS

Table 10-6-2/G.8264: ESMC PDU format

Page 35: Synchronization over Packet  Networks

IEEE-1588

Page 36: Synchronization over Packet  Networks

[Page 35]

IEEE-1588 – Version 2

The PAR (Project Authorization Request) was approved in March 2005 – P1588 – Precise Networked Clock Synchronization Working

Group was formed Resolution of known errorsConformance enhancementsEnhancements to address new applications (including Telecom)

P1588 version 2 draft– Chairman: John Eidson from Agilent– Secretary: Silvana Rodrigues from Zarlink– Editor: John MacKay from Progeny

IEEE-1588 is completed– IEEE meeting on March 26, 2008 for final approval

Page 37: Synchronization over Packet  Networks

[Page 36]

IEEE-1588 – Version 2 (cont’d)

Version 2 of the standard includes key features for Telecom– Short Frame– Unicast– Fault Tolerant Clocks– Allows different methods for Master clock selection

Telecom profile(s) need to be developed

Page 38: Synchronization over Packet  Networks

[Page 37]

Profiles in Version 2

Profile is a set of required options, prohibited options, and the ranges and defaults of configurable attributes“An IEEE-1588 profile may be developed by external organizations including: a) A recognized standards organization with jurisdiction over the industry, e.g. IEC, IEEE, IETF, ANSI, ITU, or;b) An industry trade association or other similar organization recognized within the industry as having standards authority for the industry;c) Other organizations as appropriate.”

Page 39: Synchronization over Packet  Networks

[Page 38]

Profiles

Different applications need different profiles– Need to understand the application

According to IEEE-1588TM a profile should define:– Best master clock algorithm options– Configuration management options– Path delay measurement option (delay request-response or peer

delay)– Range and default values of all configurable attributes and data

set members– Transport mechanisms required, permitted, or prohibited– Node types required, permitted, or prohibited– Options required, permitted, or prohibited– It also allows to extend the standard

Page 40: Synchronization over Packet  Networks

[Page 39]

Profiles (cont’d)

But… in addition to IEEE-1588 profile parameters, other aspects need to be considered Clock requirements

– What is the clock bandwidth? What is the frequency and holdover accuracy? Etc…

– ITU-T is working on the clock requirementsFunctions to be implemented (e.g., on-path support)

– Does it support Boundary Clocks?– Does it support Transparent Clocks?– Does it support Synchronous Ethernet?

Network Metrics– Does the network support QoS?– Characterization of the network – ITU-T is studying metrics to

characterize the network (e.g., minTDEV)– Traffic load– Number of hops

Page 41: Synchronization over Packet  Networks

[Page 40]

On-Path Support

Boundary Clocks– How many Boundary Clocks can we cascade on a

synchronization trail?– What is the clock bandwidth?

Transparent Clocks– Can it be used in a Unicast environment?

Synchronous Ethernet – Well understood as it is similar to SONET/SDH– ITU-T finished all Recommendations for Synchronous Ethernet

Page 42: Synchronization over Packet  Networks

IETF

Page 43: Synchronization over Packet  Networks

[Page 42]

IETF

NTP – Version 4– NTP version 4 draft is currently being reviewed at IETF– Working Group was formed November 2004 and work is

progressing– It is backwards compatible with NTP version 3 and version 2– Represents a significant revision of the NTP version 3TICTOC– Held first meeting in Prague, March 2007– Working Group was approved in March 2008– The application areas of focus for this WG are:

Network infrastructures with the need for highly accurate time and frequency distribution within well-engineered service provider or enterprise campus networks.

Individual hosts and devices on the public Internet requiring functionality or performance not currently available in NTP

Page 44: Synchronization over Packet  Networks

[Page 43]

TICTOC First Phase Objectives

To develop a time and frequency distribution requirements document To develop a document defining the modular breakdown of functionality within the solution spaceTo determine the extent to which these requirements can be satisfied using IEEE1588v2 and NTPv4 – Including associated gap analysis for what requirements are not

met without adaptation or extension of these protocolsTo develop an IEEE1588v2 profile as necessary for time and frequency distribution, with primary focus on application (1)– Including MIB module for IEEE1588v2

Page 45: Synchronization over Packet  Networks

[Page 44]

TICTOC First Phase Objectives (cont’d)

To develop extensions to NTPv4 as necessary for time and frequency distribution, with primary focus on application (2)To develop mechanisms for coexistence of IEEE1588v2 and NTPTo document threat analyses and security mechanisms for all protocols developed by the WGTo document media mappings for link layer technologies of interest

Page 46: Synchronization over Packet  Networks

ATIS

Page 47: Synchronization over Packet  Networks

[Page 46]

ATIS – OPTXS

OPTXS-SYNC (formerly T1X1.3)– Technical report recently pre-published

ATIS-0900002 – Synchronization of Packet Networks https://www.atis.org/docstore/product.aspx?id=22686

Addresses synchronization issues in packet networks

United States input to ITU-T– U.S. position– Sector member contributions– Timing-over-Packet synchronization requirements for North

AmericaNew working being discussed– PTP/NTP physical interface document

Page 48: Synchronization over Packet  Networks

Zarlink Semiconductor