synchronization over packet networks

Post on 21-May-2017

219 Views

Category:

Documents

1 Downloads

Preview:

Click to see full reader

TRANSCRIPT

Synchronization over Packet Networks

April 2008Maamoun Seido – System Architect

[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

Physical Layer Synchronization –Synchronous Ethernet (SyncE)

[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 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 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 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 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

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

[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 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 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 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 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 14]

ToP: Network Topology and Loading Conditions – 1

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

[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 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 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 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!

Standards

[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

ITU-T

[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 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 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 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 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

Synchronous Ethernet(ITU-T Recommendation

G.8262 and G.8264)

[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 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 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 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 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 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

IEEE-1588

[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 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 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 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 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 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

IETF

[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 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 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

ATIS

[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

Zarlink Semiconductor

top related