synce-ieee-sep08.pdf

IEEE Communications Magazine • September 2008126 0163-6804/08/$25.00 © 2008 IEEE

INTRODUCTION

A number of key changes are occurring in cur-rent telecom networks that will have wide andfar reaching consequences for the transport envi-ronment. These changes also provide some keychallenges, especially in the area of frequencysynchronization.

Ethernet has become the universal low-costmature technology of choice in both the enter-prise and residential markets. It is only a naturalstep for this to be applied in the wide area net-work (WAN) environment. In many cases it isthe access network that is the first part of thearchitecture impacted by this evolution. Howev-er, Ethernet was not designed for the transportof synchronization, which is a key requirementfor certain existing applications, especially con-cerning time-division multiplexing (TDM) emu-lation and mobile backhaul. Frequencysynchronization is also a key aspect of future

applications primarily covering next-generationmobile, and may also provide support to the dis-tribution of very accurate time of day at thephysical layer.

Synchronous Ethernet (SyncE) is a key devel-opment of the evolution of Ethernet into a carri-er grade technology suitable for the WANenvironment where frequency synchronization isrequired.

EVOLVING THETRANSPORT ARCHITECTURE

KEY ISSUESMigration from existing circuit-switched technol-ogy based on TDM networks to packet-switchedtechnology based on Ethernet is seen as thefuture in the telecommunication networks. Com-munications providers (CPs) are under pressureto reduce costs but increase bandwidth for newservice types. The need for flexibility to carrydifferent types of services over the same network(convergence of services and networks) is alsocritical to create increasing efficiency. Synchro-nization and its evolution in these convergednetworks is a key issue that needs addressing.

SYNCHRONIZATION EVOLUTIONSwitching from TDM networks to packet net-works could at first be seen as an importantchange requiring careful study. TDM networks(e.g., synchronous optical network/digital hierar-chy [SONET/SDH], plesiochronous digital hier-archy [PDH]) are technologies that natively havethe capability to carry a timing reference at thephysical layer. Packet technologies were initiallydesigned to work in asynchronous mode wherethe oscillators in the equipment are free run-ning. Although this allows the underlying infra-structure to operate, many applications exist thatrequire frequency synchronization. For example,frequency synchronization and stability are

ABSTRACT

This article discusses the evolving transportarchitecture, covering some of the synchroniza-tion distribution problems to many endpointswhere mobile backhaul and TDM emulationoccur. It shows how Synchronous Ethernet fitsinto both the Ethernet and synchronizationarchitectures, and discusses how this helpeddevelopment in standardization bodies. Stan-dardization allows the key building blocks ofEthernet silicon and specific timing devices to bedeveloped, which allows a robust system imple-mentation to be constructed while allowinginterworking with and migration from existingSONET/SDH-based transport infrastructure.Finally, results are shown that indicate a veryhigh level of performance is achievable with Syn-chronous Ethernet not subject to the normalpacket delay variation and traffic load conditionsthat can occur in packet based networks.

CARRIER SCALE ETHERNET

Jean-Loup Ferrant, Alcatel-Lucent

Mike Gilson, British Telecom

Sebastien Jobert, France Telecom

Michael Mayer and Michel Ouellette, Nortel

Laurent Montini, Cisco

Silvana Rodrigues, Zarlink

Stefano Ruffini, Ericsson

Synchronous Ethernet: A Method toTransport Synchronization

required at mobile base stations in order tomake efficient use of the radio spectrum. Inaddition, TDM emulation may also require asynchronized and stable frequency to be avail-able at the emulation points, which are at theedge of the network. Clearly the requirement forfrequency synchronization is moving away froman infrastructure requirement of the core net-work toward a requirement of the edge applica-tion. Also, the ability to distributesynchronization from center to edge declines asinfrastructure evolves toward a packet-basedarchitecture. This can easily be represented as adiagram that increasingly looks like a doughnut(Fig. 1), where the hole describes the decliningrequirement and ability to transport frequencysynchronization in the center.

Traditional TDM technologies and applica-tions require frequency synchronization in allparts of the infrastructure (shaded areas in Fig.1) in order to work. When the infrastructure isno longer synchronized, data is lost, the appli-cation experiences impairment, and the serviceis degraded. Maximum levels of phase instabili-ty, described in terms of jitter and wander, aregoverned by the International Telecommunica-tion Union — Telecommunication Standard-ization Sector (ITU-T) G.81x series ofstandards. With the shift toward packet-basedtechnologies a hole opens up in the center ofthis architecture, as it is increasingly packet-based where synchronization is no longerrequired in the core; synchronization is onlyrequired at the edge by the application. Thiscreates a challenge for the delivery of frequen-cy synchronization.

Transport of synchronization has traditionallybeen performed for years with TDM networksby the line signals at the physical layer level,using well-known principles, engineering rules,and experience. This approach can also beapplied to Ethernet-based packet networks usingSynchronous Ethernet technology.

SCALABILITY

Another important consideration for frequencysynchronization, especially for large networkswith many endpoints, is the advantage of dis-tributing the synchronization from some central-ized location (i.e., the primary reference clock,PRC) toward the edge of the network. To get anidea of the scale of the number of endpoints thatmay have to be served, see Fig. 2. There are anumber of methods by which frequency synchro-nization can be provided. Using a key advantagefrom TDM, one of the methods that can guaran-tee the best quality in delivery of a stable fre-quency is via the physical layer as part of thephysical connection delivering the data.

With the convergence of fixed and mobileservices and the evolution from TDM to Ether-net, Synchronous Ethernet provides an evolu-tionary solution to deliver synchronization.Synchronous Ethernet is specified to run overthe Ethernet media types defined in IEEE 802.3[5]. An important consideration, especially in theaccess portion of the network, is the ability ofSynchronous Ethernet to interwork with syn-chronization networks operating over the fullrange of infrastructure, covering optical fiber,copper, and microwave. Although SynchronousEthernet is currently defined only for mediacontained within IEEE 802.3, the concept of fre-quency transfer may be provided over any physi-cal media, provided it operates in a constant bitrate fashion. Fiber access and microwave arepossible examples.

SYNCHRONOUS ETHERNETARCHITECTURE AND STANDARDS

KEY ARCHITECTURE ELEMENTSSynchronous Ethernet provides a mechanism totransfer frequency over the Ethernet physicallayer, which can then be made traceable to an

IEEE Communications Magazine • September 2008 127

n Figure 1. Frequency synchronization requirement in an evolving packet-based network.

R

R Synchronization reference

CBR/TDM switch

Router/packet switch

Requirement forsynchronization

Apps

Declining requirement in core and decliningability to transport at the physical layer

Apps

AppsApplications with nosynchronizationrequirements

Apps Applications requiringsynchronization

Apps

AppsR

Apps

Apps

R

Transport of

synchronization has

been traditionally

performed for years

with TDM networks

by the line signals at

the physical layer

level, using well-

known principles,

engineering rules

and experience. This

approach can also

be applied to

Ethernet based

packet networks

using Synchronous

Ethernet technology.

IEEE Communications Magazine • September 2008128

external source such as a network clock. Assuch, the Ethernet link may be used and consid-ered part of the synchronization network. Syn-chronous Ethernet must “fit” within the generalarchitecture of an Ethernet network. To makeuse of its ability to transfer timing, SynchronousEthernet must also fit within the general archi-tecture of synchronization networks. The Ether-net and synchronization network architecturesare based on the functional modeling approachdescribed in ITU-T Recommendations G.805and G.809.

Ethernet Architecture and Synchronization— Architectures have been developed within theITU-T for various technologies such as Ethernet,multiprotocol label switching (MPLS), asyn-chronous transfer mode (ATM), SONET/SDH,and optical transport network (OTN). Architec-tures describe the network in terms of its infor-mation transport capability and what is neededin terms of operations, administration, andmaintenance (OAM) to manage a multidomainnetwork.

ITU-T defines the network architecture interms of layers. While these are somewhat simi-lar to the way existing IEEE specifications aredescribed, based on the open systems intercon-nection (OSI) reference model, the ITU-Tmethodology has some subtle differences. TheITU-T definition of a layer includes the conceptof a monitored trail, which is necessary toachieve manageability in a multidomain network.Additionally, the ITU-T network layer modelsare not restricted to seven layers as in the OSImodel. New layers are created where necessary.Each layer, however, must be fully defined,again in order to ensure manageability across

multidomain and possibly multitechnology net-works. There are additional differences betweenthe two approaches, but they do not need to becovered in order to understand aspects of themodel related to synchronization. However,adherence to the strict conventions used todefine architectures is mandatory to result innetworks that are deployable in existing and newnetworks.

A layer network is defined in terms of theinformation to be transported across the net-work (i.e., the characteristic information, CI).Specific functions (i.e., adaptation and trail ter-mination functions) responsible for any format-ting changes are defined at the boundariesbetween network layers. Trail termination func-tions add any OAM information necessary tomanage the layer network.

G.8010 Ethernet Architecture — Ethernethas been described in ITU-T RecommendationG.8010 as a two-layer network, the ETH andETY layers. Simply, the ETY layer is the physi-cal layer as defined in IEEE 802.3, while theETH layer represents the pure “packet” layer.Ethernet medium access control (MAC) framesat the ETH layer are carried as a client of theETY layer. Various protocols and functionalitydefined within the IEEE standards are mappedto specific functions within the layer network. InOSI terminology, ETY is layer 1, ETH layer 2.

Synchronization-related work within the ITU-T has been ongoing in parallel with the develop-ment of the Ethernet architecture. Expertswithin ITU-T Study Group 15 responsible forstudying timing and synchronization have beeninvestigating the need to provide explicit addi-tions to general transport architectures in order

n Figure 2. Typical scale of synchronization delivery in a large communications provider network.

Synchronousphysical layer connection

Copper

TDM emulation

DeviceApps

Device

~100,000-Millions

~10,000sof multi-serviceaccessdevices

~100sof metrorouters

~10sof corerouters Data

center

Primaryreferenceclock

Mobile BS(e.g., 3G, LTE)

Applications

Endcustomer

Logical nodes

SyncE

Edge Core

AppsFiber

Wireless

Specific functions,

which are

responsible for any

formatting changes,

are defined at the

boundaries between

network layers.

“Trail termination

functions” add any

OAM information

necessary to manage

the layer network.


to support synchronization. The initial work wasrelated to circuit emulation services (CES)where a layer 1 service (e.g., T1/E1) is carriedover a layer 2 network (e.g., Ethernet). The CEScase is an important case architecturally, sincetiming is a distinct part of layer 1 service; howev-er, it must be achievable over a packet networkthat does not inherently transfer timing. One ofthe key network issues for certain types of CESmappings is how a network timing reference ismade available to the mapping points within anetwork.

Both CES and Synchronous Ethernet areadditions to the existing ITU-T models. Theintent of both is to not require changes to theexisting IEEE defined protocols, but to extendand work within these protocol definitions toprovide the functions on a network scale. Archi-tecturally, CES is viewed as a higher layer, orclient, to the Ethernet network, and as such isdefined in the necessary adaptation functions.Synchronous Ethernet, on the other hand, is notdefined as a function, but simply describes how afrequency reference is provided to currentlydefined functions (e.g., a trail termination func-tion that implements one of the IEEE802.3PHYs). Figure 3 shows the G.8010 architecturerepresenting both the CES aspects and Syn-chronous Ethernet relative to the ETH and ETYlayers defined in G.8010. This figure shows thetwo Ethernet architectural layers, ETH andETY, together with higher-level adaptation func-tions representing mapping and demapping ofan E1 circuit using circuit emulation with differ-ential clock recovery. In this example the variousfunctions are grouped into four network ele-ments (NEs), as indicated with dotted boxes.Network timing is provided to NE_A and NE_C

via external interfaces (Ext.Ref.) on those net-work elements. For simplicity, the synchroniza-tion network that carries the timing between theprimary reference source and the NEs is notshown. When it may be impractical to providean external clock at NE_D (e.g., due to cost orwhere access is impractical), timing to NE_D isprovided via Synchronous Ethernet. The linkbetween NE_C and NE_D shows an example ofSynchronous Ethernet. In this case the externalclock on the third NE (NE_C) provides timingto the Ethernet physical layer (ETY). The fourthNE (NE_D) can then recover this clock from thephysical layer (ETY). In this example the clocksignal is used by the NE as a reference to recon-struct the E1 timing carried by circuit emulation.

While the figure is primarily intended toshow frequency transfer, the model also allowsgreater understanding of other related function-ality and provides a starting point to investigatethe interactions of frequency synchronization(e.g., Synchronous Ethernet) with other forms offrequency and time transfer. The modeling alsoprovides a common understanding between vari-ous groups within the ITU-T.

DEVELOPMENT IN STANDARDS BODIESThe proposal to specify the transport of a refer-ence clock over Ethernet links was brought byoperators to ITU-T Study Group 15 in Septem-ber 2004. Analysis indicated that such a featureis consistent with the IEEE 802.3 standard,which specifies Ethernet clocks to be within±100 ppm (parts per million). Synchronous Eth-ernet clocks are within ±4.6 ppm, which is with-in the frequency range of Ethernet interfaces. Inaddition, by externally timing the Ethernet clock,PRC traceability of the interface is achievable.

n Figure 3. CES and synchronous Ethernet shown together with the ETY and ETH functions defined inG.8010.

CES/ETH

ETH

TDM timing

Ext. ref.Ext. ref.

Primaryreference

source

Interlayeradaptation

ETHlayer

Interlayeradaptation

ETYlayer

CES/ETH

E1NE_A

ETH

NE_B

ETH/ETY

ETY

ETH/ETY CES/ETH

ETH

CES/ETH

E1NE_D

ETH

NE_C

ETH/ETY

ETY

ETH/ETY

ETY

Adaptation function Network element boundary

Flow domain

Terminal flow point

Trail termination function

Clock

Legend

ETY

The proposal to

specify the transport

of a reference clock

over Ethernet links

was brought by

operators to ITU-T

Study Group 15 in

September 2004.

Analysis indicated

that such a feature is

consistent with the

IEEE 802.3 standard,

which specifies

Ethernet clocks to be

within ±100 ppm.


Another key input that was also brought byoperators was the need for interworkingbetween SONET/SDH and Synchronous Ether-net equipment in order for them to have a sin-gle synchronization network to manage. Thisproposal was in line with the current exten-sions of SONET/SDH equipment with Ether-net interfaces. This resulted in three importantdecisions:• To extend the scope of the G.803 [7] refer-

ence synchronization chain to SynchronousEthernet equipment. This has been done inG.8261 [1], which defines the architecturalaspects of Synchronous Ethernet.

• To specify Synchronous Ethernet clockscompatible with SONET/SDH clocks asdefined in G.813 [8] and G.812 [9]. This hasbeen done in G.8262 [2], which specifiesthe clocks for Synchronous Ethernet equip-ment.

• To use the synchronization status message(SSM), as defined in G.707 [10]. Synchro-nization status messages contain an indica-tion of the quality level of the clock that isdriving the synchronization chain, and isused to control, maintain, and restore thesynchronization chains of Synchronous Eth-ernet equipment. The IEEE proposed asolution based on Slow Protocol to ITU-T.ITU-T further developed the protocol,which is included in RecommendationG.8264 [3].The details of the synchronization functions

that needed to be implemented in SynchronousEthernet equipment have been added in a new

release of G.781 [4], which originally specifiedthese functions only for SDH equipment.

ITU-T Recommendation G.8261 [1], releasedin 2006, was the first document to introduce theSynchronous Ethernet concept as part of thestudies related to the synchronization aspects inpacket networks. This technology has been stan-dardized by the ITU-T as a direct result of theexperience gained with the standardization oftiming distribution over SONET/SDH networks.

Since the very beginning, G.8261 was recog-nized as the main reference for this technology,although the first version of the standard pre-sented several aspects not fully defined. Due tothat, the initial concepts included in the 2006version of G.8261 have been expanded and com-plemented with a revised G.8261 (recently pub-lished). This revised version provides moredetailed requirements and architectural guide-lines in a similar manner as was done for thestandardization of synchronization networksbased on SONET/SDH. The standardization ofSynchronous Ethernet was finally completedduring the same period by two other fundamen-tal Recommendations, G.8262 and G.8264.

ITU-T Recommendation G.8262 [2] definesrequirements for clock accuracy, noise transfer,holdover performance, noise tolerance, andnoise generation. It defines two options forclocks for Synchronous Ethernet; these clocksare called Synchronous Ethernet equipmentslave clocks (EECs). The first option, referred toas EEC-Option 1, applies to Synchronous Ether-net equipment designed to interwork with net-works optimized for the 2048 kb/s hierarchy.Requirements for this option are based on thosefound in G.813 Option 1 used in SDH networks.The second option, referred to as EEC-Option2, applies to Synchronous Ethernet equipmentdesigned to interwork with networks optimizedfor the 1544 kb/s hierarchy. Requirements forthis option are compatible with the requirementsfor Stratum 3 clocks deployed in SONET net-work elements. These requirements are based ona combination of requirements from G.813Option 2 and G.812 Type IV.

To allow a Synchronous Ethernet link to con-vey the SSM quality level (QL) as defined inG.707 and G.781, a specific channel has beendefined based on IEEE 802.3, Organization Spe-cific Slow Protocol (OSSP), currently specifiedin IEEE 802.3ay [6], a revision to IEEE 802.3-2005 PAR. The Ethernet Synchronization Mes-saging Channel (ESMC, Table 1) protocol iscomposed of the standard Ethernet header for aslow protocol, an ITU-T specific header, a flagfield, and a type length value (TLV) structure.The use of flags and TLVs aims to optionallyimprove the management of the SynchronousEthernet link and associated timing chain. ITU-T Recommendation G.8264 [3] currently definestwo messages, Event and Information, both sup-porting the same mandatory QL TLV for SSMtransmission. The two message types are neces-sary to meet the strict delay requirements inITU-T Recommendation G.781 [4], while stillmeeting the message rate requirements placedon slow protocols. The protocol allows for futureenhancements through the definition of newTLVs as appropriate.

n Table 1. Ethernet Synchronization Messaging Channel (ESMC) protocoldata unit.

Octetnumber 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 octet 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–28 4 octets QL TLV (type, length, reserve, SSM)

29–1532 32-1486octets Future enhancement TLVs and padding

Last 4 4 octets FCS


ENGINEERING THE SOLUTION

SILICON AND TIMING DEVICE COMPONENTS

Several semiconductor companies are in the pro-cess of implementing Synchronous Ethernetfunctionalities. This includes both Ethernettransceiver manufacturers as well as timingdevice manufacturers.

As an example today, a typical Gigabit Ether-net Quad-PHY transceiver operating at100BASE-TX, 100BASE-FX, and 1000BASE-Xrates already uses a free-running input referenceclock (TX clock), and has a clock data recovery(CDR) block and in most cases a recovered out-put clock (RX clock) which is extracted from theline. These already available and important func-tions form the basis of Synchronous Ethernet.Today, the free-running input reference clockand extracted recovered output clock fromtransceivers are essential functions for properEthernet data transmission and recovery. For100BASE-TX transceivers, the input free-run-ning reference clock as specified by IEEE 802.3-2005 has an accuracy of 25 MHz ±0.01 percent(or 100 parts-per-million) as well as the recov-ered output clock frequency tolerance. For Giga-bit Ethernet the accuracy is 125 MHz ±0.01percent.

The primary idea behind Synchronous Ether-net is that the input reference clock is not free-running with an accuracy of ±100 ppm, butrather locked and traceable to a primary refer-ence clock as defined in ITU G.811 (achievinglong-term accuracy of ±10 parts-per-trillion). Ifthe input to a transceiver is very accurate andstable, the recovered clock of a transceivershould, in theory, be locked and traceable tothat input. In addition, Synchronous Ethernettransceivers will offer the possibility to selectfrom which port to extract the output clock (e.g.,with multi-PHY transceivers) as well as, forexample, a fast link failure mechanism andsquelching functions to prevent degraded outputreferences being used as a clock reference.These are important features for proper networksynchronization distribution.

In addition to the transceiver manufacturers,several timing device manufacturers are alsointroducing specialized Synchronous Ethernetcomponents that will be deployable within linecards and centralized timing cards. These com-ponents are introduced to provide functions theEthernet transceivers themselves might or mightnot provide beyond those listed above due totime to market. They are introduced so that sys-tem vendors can make use of current transceiverson existing line cards, but offload some of thesynchronization functions to those specializedcomponents.

These specialized components use, for exam-ple, integrated digital phase locked loop (DPLL)that includes different functions depending onwhether the components are deployed in a linecard or a central timing card. Functions that areimportant for line cards include frequency con-version, configurable PLL bandwidth for noisefiltering, and jitter attenuation. Functions thatare important for central timing cards includeclock accuracy, noise transfer, holdover perfor-

mance, noise tolerance, and noise generation,which are specified in G.8262 [2]. The functionsfound on central timing cards are primarily thesame as those currently used within SONET/SDH.

NETWORK, SYSTEM ANDEQUIPMENT IMPLEMENTATION

This section shows how some of the functionslisted earlier can be applied to implement Syn-chronous Ethernet on existing or new switchesand routers. For simplicity, Fig. 4 presents a dia-gram of two network elements connected via anEthernet interface (in practice there will be acascade of switches forming a synchronizationnetwork and timing chain). From a synchroniza-tion perspective we only show the distribution ofsynchronization from left to right, where theMaster NE distributes synchronization and theSlave NE recovers synchronization. Two types ofline cards are shown: Synchronous Ethernetcapable line cards and conventional Ethernetline cards. It can be seen from the figure thatthe Synchronous Ethernet line cards can inter-face to a timing backplane to source and termi-nate timing. For simplicity, the data paths arenot shown in the figure. Both card types areinterchangeable from the perspective of the datatransport capabilities.

The Master NE takes external input timingreferences coming from the network clock (SSUor BITS). These interfaces are specified in ITU-T G.703 (e.g., 2048 kHz synchronization inter-face). In the future an external input timingreference might be Synchronous Ethernet based.These references are then used as input to theITU G.8262 EEC clock, typically located on thecentral timing card of the NE. The figure alsoshows a free-running input crystal operating at±4.6 ppm, as specified in ITU G.8262 (samerequirement as in G.813 option 1 and G.812clock type IV). The EEC, for instance, specifiesthe level of jitter and wander at the input andoutput of the clock, as well as the specificationunder short-term and long-term transients suchas loss of timing reference or link failure. It isalso responsible for functions listed earlier suchas timing reference selection and switching. TheEEC output timing reference is then distributedvia the NE backplane to reach the Ethernet linecards.

The Synchronous Ethernet line card includesthe Ethernet MAC and PHY transceiver, as wellas any timing device. The timing device providesfunctions listed earlier. Frequency conversionadapts backplane frequencies to frequencies thatare required as input reference clocks to thetransceiver (25 or 125 MHz). The output of thetiming device serves as the TX clock referenceinto the transceiver, replacing the free-runningcrystals with ±100 ppm accuracy in the conven-tional line card. The reference is then used tosynchronize the physical line coding (e.g., 4B/5Bfor FE, 8B/10B for GE) of the interface towardthe Slave NE.

At the Slave NE, the clock is recovered with-in the transceiver CDR in the Ethernet PHYblock of the Synchronous Ethernet line card(current operation of transceivers). In somecases where the RX clock is not available at the

In addition to the

transceiver

manufacturers,

several timing device

manufacturers are

also introducing

specialized

Synchronous

Ethernet

components that will

be deployable within

line cards and

centralized timing

cards.


transceiver, the use of an external CDR mightbe required to recover the clock. The recoveredoutput clock is then fed into a timing device forfunctions (e.g., those found in the Master NE)such as jitter attenuation and transceiver fre-quency conversion to backplane frequency. Theclock is then sent through the backplane toreach the Slave’s central timing card. This timingreference then becomes a reference to the EEC(also known as a line-timing reference). Asshown in the Slave NE, an EEC can accept lineand external references, as well as the input of a±4.6 ppm local oscillator (used in situationswhere there are no line or external referencesavailable). The EEC can also provide timingoutputs in the form of 2048 kHz synchronizationinterface to external SSU/BITS network ele-ments (typically Stratum 2 NE).

From this point on, the Slave NE thenbecomes the Master NE for the next down-stream NE, and synchronization us transportedon a node-to-node basis, where each node par-ticipates in recovery and distribution. It is by thisprocess that synchronization traceable to a pri-mary reference source can be recovered and dis-tributed within each NE. It is also important tonote that Synchronous Ethernet does not disruptthe IEEE 802.3 architecture.

In a real-world implementation, however,synchronization distribution would be bidirec-tional, and provide redundancy through multiplecentral timing cards and line cards. The EEC as

defined in ITU G.8262 was specified to inter-work with SONET/SDH, and by doing so, Syn-chronous Ethernet can inherit most of theSONET/SDH synchronization design principles.

It is important to note that Synchronous Eth-ernet can be applied to both existing networksand new networks (sometimes referred to asgreen-field networks). Synchronous Ethernetdeployment is not required ubiquitously over anentire network, only where frequency distribu-tion is needed. In the green-field case it isexpected that new Synchronous Ethernet equip-ment will be the preferred approach; however, inexisting networks, as an example, it may be pos-sible to simply replace asynchronous line cardswith new synchronous line cards to provide thiscapability. But this is dependent on the architec-ture of the existing equipment.

In addition to the distribution of physical signalsexplained above, a simple communication protocolis needed between NEs. This protocol is specifiedin ITU G.8264 as the ESMC and is describedabove. ESMC is used to transmit, from NE to NE,the clock quality level value. The ESMC will typi-cally be implemented outside the MAC and PHY,similar to other Ethernet OAM protocols.

NETWORK PLANNING CONSIDERATIONSThe deployment of synchronization networks uti-lizing layer 1 Synchronous Ethernet provides auseful tool to network operators to distribute fre-quency that is not subject to packet delay varia-

n Figure 4. Synchronous Ethernet network element and clock distribution.

Slave NE

Centraltiming card

Conventional Ethernetline card

Local osc+/- 4.6 ppm

N

2

Master NE

MAC MAC

Transmitclock

TransmitclockLocal osc

+/- 100 ppmLocal osc

+/- 100 ppm

Recoveredclock

Synchronous Ethernetline card

Conventional Ethernetline card

Synchronous Ethernetline card

2 SyncEtimingdevice

SyncEtimingdevice

Externalreference

from SSU/BITS

ITU G.8262EEC

Centraltiming card

Tim

ing

back

plan

e

Tim

ing

back

plan

e

EthernetPHY

MAC EthernetPHY

EthernetPHY

MACEthernetPHY

2

Local osc+/- 4.6 ppm

N

2

ITU G.8262EEC

Externalreference

to/from SSU/BITS

2

It is important to

note that

Synchronous

Ethernet can be

applied to both

existing networks

and new networks.

Synchronous

Ethernet deployment

is not required

ubiquitously over an

entire network, but

only in cases where

frequency

distribution is

needed.


tion. Due to the characteristics of the clocks, ingeneral, existing network planning and engineer-ing rules can be employed, greatly simplifying theintegration of Synchronous Ethernet technologyinto the SONET/SDH synchronization network.

However, as networks evolve, it is expectedthat operators will be dealing with a mix of Eth-ernet equipment that may or may not provideSynchronous Ethernet capabilities. An extra stepmay be required in network planning simply toensure that Ethernet links on equipment withappropriate Synchronous Ethernet functionalityare selected as timing links. This extra step con-trasts the SDH/SONET case, where all NEs bydefinition are capable of being integrated intothe synchronization network.

ACHIEVABLE RESULTSThis section discusses the performance that canbe achieved by Synchronous Ethernet based on asubset of results that have been presented withinITU-T for the development of G.8262.

The test and measurements were doneaccording to Fig. 1a of ITU-T G.810 [11]. Thetestbed, shown in Fig. 5, consisted of a timingchain of four cascaded Ethernet switches, wherethe clock was transported across the networkthrough 1000BASE-X and 100BASE-TX inter-faces. In addition, Ethernet traffic, not shown inthe figure, was sent through the Ethernet switch-es, and the last Synchronous Ethernet port wascongested with a subscription ratio of 10:1.

Figure 6 shows the time interval error (TIE)and maximum TIE (MTIE) for a three-day peri-od. TIE is a metric used to represent the phasemovement of the recovered signal (here the Eth-ernet recovered clock at the end of the timingchain) against an ideal reference. The filteringbandwidth of the EEC clocks was set to 10 Hzfor testing purposes, but could have been set aslow as 0.1 Hz, which would have produced evenlower TIE/MTIE performance. The TIE isbounded within approximately ±10 ns, and theMTIE is bounded to about 25 ns; therefore, themeasured MTIE meets the required mask. Theseresults, combined with the fact that EEC Options1 and 2 meet the same noise transfer and noisegeneration requirements as for SDH andSONET, respectively, clearly indicate that theclock chain requirements in G.803 are met. Basedon this, it is expected that current network syn-

chronization guidelines and practices can beretained as operators migrate from SONET/SDHtoward Ethernet. In addition, the results are notimpacted by packet network impairments such astraffic load, latency, or delay variation (10:1 over-subscription in this test).

CONCLUSIONMeasured results show that very high levels offrequency transfer performance are achievablewith Synchronous Ethernet, delivering phase

n Figure 5. Synchronous Ethernet testbed.

Ethernetswitch 1

EEC

Cesiumreference(G.811)

Ethernetswitch 2

Ethernet Ethernet Ethernet Ethernet Wandermeasurement

Externalreference

Externalreference

EEC

Ethernetswitch 3

EEC

Ethernetswitch 4

EEC

n Figure 6. Achievable results: TIE and MTIE for three days.

Elapsed time (s)50,000

TIE

(ns)

-5.0

0.0

5.0

10.0

0 100,000

Cursor 119738.80 sTime

4.7 sTIE

150,000 200,000

Observation intervalEmbedded mask: ITU-T, G.823, MTIE, 6.2.3 Table 10 Fig 8,

SEC interface output wander limit

0.1

MTI

E (n

s)

10

1

0.1

100

1000

10,000

100,000

0.01 1 10 100 1000 10,000 100,000 1,000,000

Cursor 0.02 sObs. interval

8.2 nsMTIE

0.0 nsMask


performance in the region of a few tens ofnanoseconds. Such performance replicates thatachievable from SONET/SDH transport net-works, providing security of synchronization sup-ply as well as a migration path from TDM toEthernet for service delivery. Furthermore, assuch a solution uses the physical layer, it hasbeen shown to be immune to traffic load andpacket delay variation.

A key aspect to success is that it does notfundamentally change the Ethernet technologyor the standards that describe Ethernet. Archi-tecturally, the well defined layers within Ether-net allow this evolution in Ethernet to occur.Lengthy analysis of this architecture and itsdescription within standards, together withappropriate reuse of existing standards and com-ponents, has enabled Synchronous Ethernet tobe developed relatively easily. It is also compati-ble with the current synchronization network.

Such a solution will allow communicationsproviders considerable flexibility in serving manynodes and applications with defined levels ofperformance, and provides a well understoodevolution path from existing transport networksto Ethernet-based transport networks.

REFERENCES[1] ITU-T Rec. G.8261, “Timing and Synchronization Aspects

in Packet Networks,” Feb. 2008.[2] ITU-T Rec. G.8262, “Timing Characteristics of Synchronous

Ethernet Equipment Slave Clock (EEC),” Aug. 2007.[3] ITU-T Rec. G.8264, “Distribution of Timing Through

Packet Networks,” Feb. 2008.[4] ITU-T Rec. G.781, “Synchronization Layer Functions,”

Feb. 2008.[5] IEEE 802.3-2005, “CSMA/CD Access Method and Physi-

cal Layer Specifications,” 2005.[6] IEEE 802.3ay (IEEE P802.3Rev) Maintenance #9 (Revi-

sion) Task Force, expected 2008.[7] ITU-T Rec. G.803, “Architecture of Transport Networks

Based on the Synchronous Digital Hierarchy (SDH).”[8] ITU-T Rec. G.813, “Timing Requirements of SDH Equip-

ment Slave Clocks (SEC).”[9] ITU-T Rec. G.812, “Timing Requirements of Slave Clocks

Suitable for Use as Node Clocks in Synchronization Net-works.”

[10] ITU-T Rec. G.707, “Network Node Interface for theSynchronous Digital Hierarchy (SDH).”

[11] ITU-T G.810, “Definitions and Terminology for Syn-chronization Networks.”

BIOGRAPHIESJEAN-LOUP FERRANT ([email protected]),graduated from INPG Grenoble, France, joined Alcatel in1975, and worked on analog systems, PCM, and digitalcrossconnects. He has been working on SDH synchroniza-tion since, 1990 and on SDH and OTN standardization formore than 15 years in ETSI TM1 and TM3, and ITU-TSG13 and SG15. He has been rapporteur of SG15 Q13 onnetwork synchronization since 2001. He is one of Alcatel-Lucent’s experts on synchronization in transport net-works.

MIKE GILSON ([email protected]) is a technologist with BTDesign at Adastral Park. He joined BT in 1983, and hasplayed a major role in developing and implementing BT’sTime and Timing strategy from 1988 to the present. He iscurrently actively contributing to the ITU and IETF stan-dards bodies, and the ITSF and NIST synchronizationforums. He has a B.A. (Hons) degree in business studiesand is a member of the Institute of Engineering and Tech-nology.

SEBASTIEN JOBERT ([email protected]) isan R&D engineer, Network Synchronization, France Tele-com. He graduated in computer science and telecommuni-cations from Paris 6 University, and joined France TelecomR&D in 2005 after one year working on VoIP aspects. Heworked on data synchronization aspects for a year, partici-pating in the Open Mobile Alliance (OMA) DS WG. He iscurrently working on network synchronization aspects, andfollows Q13/SG15 at the ITU-T.

MICHAEL MAYER ([email protected]) graduated from QueensUniversity (B.Sc.EE). In 1982 he joined Bell-NorthernResearch (now Nortel). For the past 12 years, his area offocus has been systems design and standardization, and hehas actively contributed to standards in the areas of syn-chronization, OTN, SONET/SDH, and ASON control planearchitecture. Within the ITU, he has been a technical editorof several ITU-T Recommendations covering the ASON opti-cal control plane and synchronization related topics.

LAURENT MONTINI ([email protected]) is a technical leaderin the office of the CTO at Cisco. He has focusedg his workon frequency and time distribution over next-generationnetworks for the last two years, participating in the stan-dardization efforts since 2005. Prior to this function hespent six years as a consulting system engineer for mobileoperators dealing with service and traffic convergence inbackbone and radio access networks where the emergenceof pseudo-wire techniques raised the timing issue.

MICHEL OUELLETTE ([email protected]) joined Nortel in1997 and is a member of scientific staff in the CTO group.Current responsibilities include the design, performance,and standardization of network synchronization architec-ture, frequency and time distribution for carrier-Ethernetand 2G/3G/4G wireless backhaul, as well as the develop-ment of algorithms for Mobile IP. He is involved in ITU-TSG15/Q13, has published 15 journal/conference papers,and has eight patents granted.

SILVANA RODRIGUES ([email protected]) is a sys-tem architect, Timing and Synchronization, Zarlink Semi-conductor. She graduated in electrical engineering fromCampinas University, Brazil. She started her carrier at theTelecommunication Research Center, Brazil. She has beenworking on synchronization since 2002. She participates inseveral standards groups; she is the editor of theG.paclock.bis and G.8262 Recommendations in ITU-T, andsecretary for IEEE-1588. She is also an active participant inthe OPTXS-SYNC standard committee and TICTOC at IETF.

STEFANO RUFFINI ([email protected]) is an expertin R&D, and manager of Ericsson’s Network Synchroniza-tion Center. He joined Ericsson in 1993 and has been work-ing on synchronization aspects for about 15 years. He hasrepresented Ericsson in various standardization organiza-tions (including ETSI, ITU, 3GPP, and IETF) and is currentlyactively contributing to ITU-T SG15 Q13 (editor of ITU-TRecommendation G.8261, which introduces SynchronousEthernet technology) and IETF TICTOC. He is one of Erics-son’s experts involved in the definition of equipment andnetwork synchronization solutions.

A key aspect to

success is that it

does not change

fundamentally the

Ethernet technology

or the standards that

describes Ethernet.

Architecturally the

well defined layers

within Ethernet allow

this evolution in

Ethernet to occur.

synce-ieee-sep08.pdf

Documents