城域以太网论坛(MEF) MEF3标准编程频道|福州电脑网

2024年2月7日发(作者：)

Technical Specification

MEF 3

Circuit Emulation Service Definitions, Framework

and Requirements in Metro Ethernet Networks

April 13, 2004MEF 3

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 1 of 65

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

Disclaimer

The information in this publication is freely available for reproduction and use by any recipient and is believed to be

accurate as of its publication date. Such information is subject to change without notice and the Metro Ethernet

Forum (MEF) is not responsible for any errors. The MEF does not assume responsibility to update or correct any

information in this publication. No representation or warranty, expressed or implied, is made by the MEF

concerning the completeness, accuracy, or applicability of any information contained herein and no liability of any

kind shall be assumed by the MEF as a result of reliance upon such information.

The information contained herein is intended to be used without modification by the recipient or user of this

document. The MEF is not responsible or liable for any modifications to this document made by any other party.

The receipt or any use of this document or its contents does not in any way create, by implication or otherwise:

(a) any express or implied license or right to or under any patent, copyright, trademark or trade secret rights held or

claimed by any MEF member company which are or may be associated with the ideas, techniques, concepts or

expressions contained herein; nor

(b) any warranty or representation that any MEF member companies will announce any product(s) and/or service(s)

related thereto, or if such announcements are made, that such announced product(s) and/or service(s) embody

any or all of the ideas, technologies, or concepts contained herein; nor

Implementation or use of specific Metro Ethernet standards or recommendations and MEF specifications will be

voluntary, and no company shall be obliged to implement them by virtue of participation in the Metro Ethernet

Forum. The MEF is a non-profit international organization accelerating industry cooperation on Metro Ethernet

technology. The MEF does not, expressly or otherwise, endorse or promote any specific products or services.

MEF 3

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 2 of 65

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

Table of Contents

.10

MEF 10

CIRCUIT EMULATION 11

6.1 TDM

LINE

SERVICE

(T-LINE)............................................................................................................................11

6.1.1 Operational Modes of a .12

6.1.1.1 Unstructured 12

6.1.1.2 Structured 13

6.1.1.3 13

6.1.2 Bandwidth Provisioning for a 14

6.1.2.1 Bandwidth allocation at 100 kbit/14

6.1.2.2 14

6.1.2.3 15

6.2 TDM

ACCESS

LINE

SERVICE

(TALS)................................................................................................................15

6.2.1 Operational Modes of a 16

6.3

6.4

CUSTOMER

OPERATED

MIXED-MODE

CES

.18

CIRCUIT EMULATION 19

7.1 GENERAL

7.1.1 Use of .19

7.2 SERVICE

INTERFACE

.19

7.2.1 Examples of TDM 20

7.2.2 TDM Service Processor (TSP)..................................................................................................................20

7.2.3 Circuit Emulation Inter-working Function (CES IWF)...........................................................................21

7.2.3.1 PDH Circuit 22

7.2.3.2 SONET/SDH Circuit .22

7.2.4 Emulated Circuit De/Multiplexing Function (ECDX).............................................................................23

7.2.5 Ethernet Flow Termination Function (EFT)............................................................................................23

7.2.6 .23

7.23

7.3.1 CES Interworking Function- 25

7.3.2 Synchronous IWF and 27

7.3.2.1 Synchronous IWF 27

7.3.2.2 Synchronous IWF and .27

7.3.3 Asynchronous IWF and 27

7.3.3.1 Asynchronous IWF, 28

7.3.3.2 Asynchronous IWF, 28

MEF 3

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 3 of 65

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

7.3.4 28

7.3.4.1 Single Service-Provider 29

7.3.4.2 Multi Service-Provider 31

7.3.4.3 Private (customer owned) 34

7.4 PERFORMANCE

MONITORING AND

7.4.1 Facility 35

7.4.35

7.4.2.1 35

7.4.2.2 36

7.4.2.3 Buffer Underflow .36

7.4.2.4 Alarms in 36

7.4.3 .36

7.5 SERVICE

7.5.1 Errors within the MEN causing TDM 37

7.5.1.1 37

7.5.1.2 Frame Delay and 37

7.5.1.3 37

7.5.1.4 Frame Error Ratio and 37

7.5.2 Relationship to TDM service 38

7.5.3 Errored Seconds Requirement for 38

7.5.4 Severely Errored Seconds Requirement for 39

7.5.5 Service Impairments for SONET/41

7.5.5.1 Performance Objectives for the SONET/41

7.5.5.2 MEN 42

7.5.5.3 Summary & .45

7.5.6 45

7.6 TDM

7.46

7.7.1 Provider 46

7.7.2 Customer 47

7.48

7.8.1 Scenario 1 – dual .48

7.8.2 Scenario 2 – dual 48

7.8.3 Scenario 3 – Single 49

7.8.4 Scenario 4 – Single to dual 49

7.9

7.10

7.11

SERVICE

CIRCUIT EMULATION 51

8.1 STRUCTURED

DS1/E1

NX64 KBIT/S

.51

8.1.1 51

8.1.2 51

8.1.3 51

8.1.52

8.1.5 Jitter .52

MEF 3

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 4 of 65

8.1.6

8.1.7

8.1.8

8.1.9

8.1.10

8.1.11

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

Facility 52

Bit 52

.53

Lost and Out of 53

Buffer 53

8.2 DS1/E1

UNSTRUCTURED

8.2.54

8.2.3 Jitter .54

8.2.4 Facility 54

8.2.54

8.2.6 Lost and Out of 55

8.2.7 Buffer 55

8.3 UNSTRUCTURED

DS3/E3

8.3.55

8.3.56

8.3.3 Jitter .56

8.3.56

8.3.5 Lost and Out of 56

8.3.6 Buffer 57

8.4 SONET/SDH

8.4.1 Framing and 57

8.4.58

8.4.3 59

8.4.4 Jitter .60

8.4.60

8.4.6 Buffer 60

8.5 GENERAL

8.5.61

8.5.2 Frame Loss 61

8.5.61

9. 62

.62

ETHERNET

FRAME

ETHERNET

FRAME

NETWORK

BANDWIDTH

9.1

9.2

9.3

9.4

9.5

10. 64

MEF 3

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 5 of 65

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

List of Figures

Figure 1: TDM Line Service over Metro 11

Figure 2: Possible TDM Virtual Private 12

Figure 3: Example Multi-point to Point T-Line 14

Figure 4: Multiplexing across a single Ethernet 15

Figure 5: Handoff of a multiplexed trunk to an 16

Figure 6: Possible TDM 17

Figure 7: Customer Operated CES over a Metropolitan Ethernet Service (e.g. E-Line)..............................................17

Figure 8: 18

Figure 9: Functional Elements and 19

Figure 10: Functional Elements of SONET/SDH 22

Figure 11: Interworking 23

Figure 12: Timing distribution architecture showing 24

Figure 13: CES IWF Synchronization 26

Figure 14: Synchronization Administration for a Single 30

Figure 15: Synchronization Administration for a Multi 31

Figure 16: Synchronization Administration for a 34

Figure 17: Allowed Frame Error Ratio to meet 39

Figure 18: Relationship between Packing and FER for 0.01% 40

Figure 19: Relationship between Packing and FER for 0.01% SES based on 10 BER on end to end TDM data

Figure 20: Provider Controlled 47

Figure 21: Customer Controlled 47

Figure 22: Dual .48

Figure 23: Dual 49

Figure 24: Single 49

Figure 25: Single to dual .49

-3MEF 3

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 6 of 65

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

List of Tables

Table 1: TDM .20

Table 2: CES TDM 22

Table 3: Timing 24

Table 4: CE Synchronization modes and Expected 25

Table 5: CES IWF 26

Table 6: Timing Options per .28

Table 7: CES Services and supporting Synchronization .29

Table 8: Timing Options Single-Service Provider .30

Table 9: Timing Options Multi-Service Provider 32

Table 10: Timing Options for a 34

Table 11: Example conversion from ES to FER for Ethernet .38

Table 12: Sparse FER objectives for MEN [G.826].........................................................................................................43

Table 13: Background FER and BER objectives for MEN [G.826]................................................................................43

Table 14: Maximal FER accounted by SESR [G.826].....................................................................................................44

Table 15: MEN FER Requirements for SDH/.45

MEF 3

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 7 of 65

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

1. Abstract

The emulation of TDM circuits over a Metro Ethernet Network (known as Circuit Emulation Services, or CES) is a

useful technique to allow MEN service providers to offer TDM services to customers. This document outlines the

types of the TDM services that can be offered over a MEN, and the requirements of such services. It covers both

PDH services (e.g. Nx64 kbit/s, T1, E1, T3, E3) and SONET/SDH services (STS-1, STS-3, STS-3c, STS-12, STS-12c and European equivalents).

The document contains three sections:

a set of service definitions for Circuit Emulation Services (CES) in the Metro Ethernet Forum context,

a framework section explaining issues with the implementation of such services

a set of requirements needed for providing such services in Metro Ethernet Networks (MEN).

Separate implementation agreements for PDH and SONET/SDH services will be produced which cover the

implementation of these services in an inter-operable manner. This document is intended as a reference against

which any Implementation Agreement can be compared to ensure that all the service requirements have been met.

2. Terminology

Term

AIS

ANSI

APS

BER

BBER

BLSR

CAS

CCS

CES

CRC

CUET

DSTM

DTM

E-Line

ECDX

ECID

EFT

ESR

MEF 3

Definition

Alarm Indication Signal

American National Standards Institute

Automatic Protection Switching

Bit Error Ratio

Background Block Error Ratio

Bi-directional Line Switched Ring

Channel Associated Signaling

Common Channel Signaling

Customer Equipment

Circuit Emulation Services

Clock Recovery.

Cyclic Redundancy Check

Customer Unit Edge Terminal

Derived System Timing Mode.

The IWF system clock is derived from the incoming Ethernet frames.

Derived Timing Mode.

The recovered service clock is derived from the incoming Ethernet frames.

Ethernet Line Service

Emulated Circuit De/Multiplexing Function

Emulated Circuit Identifier

Ethernet Flow Termination

Errored Second

Errored Second Ratio

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 8 of 65

Term

ESF

EVC

FDL

FER

HOVC

IETF

ITU-T

IWF

LOH

LOPS

LOS

LOVC

LTE

MIB

MEN

NNI

PDH

PLL

PRS

PSTN

PWE3

RDI

SDH

SES

SESR

SLA

SLS

SONET

SSM

TALS

TDM

T-Line

TSP

Definition

Extended Super Frame

Ethernet Virtual Circuit

Facility Data Link

Frame Error Ratio

Higher Order Virtual Container

Implementation Agreement

Internet Engineering Task Force

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

International Telecommunication Union – Telecommunication standardization sector

Inter-Working Function

Line OverHead

Loss Of Packet Synchronization

Loss Of Signal

Lower Order Virtual Container

Line Termination Equipment

Management Information Base

Metro Ethernet Networks

Network Equipment

Network to Network Interface

Plesiochronous Digital Hierarchy.

PDH refers to the DS1/DS2/DS3 and E1/E3/E4 family of signals

Provider Edge

Phase Locked Loop

Primary Reference Source

Public Switched Telephone Network

Pseudo-Wire Emulation Edge to Edge (an IETF working group)

Remote Defect Indication

Synchronous Digital Hierarchy

Severely Errored Second

Severely Errored Second Ratio

Super Frame

Service Level Agreement

Service Level Specification

Synchronous Optical Network

Synchronization Status Message

TDM Access Line Service

Time Division Multiplexing

(examples of TDM services include Nx64 kbit/s, T1, T3, E1, E3, OC-3, STM-1, OC-12, STM-4)

TDM Line Service

TDM Service Processing

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

MEF 3

Page 9 of 65

Term

UNI

Mapper

Mapping

Definition

User Network Interface

Virtual Container

Virtual Tributary

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

A device or logic that implements a mapping function

The process of associating each bit transmitted by the service into the SDH/SONET payload

structure that carries the service. For example, mapping a DS1 service into SONET VT-1.5 /

SDH VC-11 associate each bit of the DS1 with a location in the VT-1.5/VC-11

Transmit one or more channels over a single channel

A part of the SDH/SONET overhead that locates a floating payload structure. Frequency

differences between SDH/SONET network elements or between the payload and the

SDH/SONET equipment can be accommodated by adjusting the pointer value.

Multiplex

Pointer

3. Scope

The scope of this document is to address the particular requirements of transport over MEN for edge-to-edge-emulation of circuits carrying time division multiplexed (TDM) digital signals. It makes references to requirements

and specifications produced by other standards organizations (notably the ITU, ANSI, IETF PWE3 and ATM

Forum), and adapts these to address the specific needs of MEN. It is not in the scope of this document to duplicate

any work of other related standardization bodies.

The document covers the definition of such services, a framework in which the service provision can be understood,

and also the requirements for the defined services. The actual implementation of these services in an inter-operable

manner will be the subject of separate Implementation Agreements, and hence is outside the scope of this document.

4. Compliance Levels

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD

NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in

[RFC 2119]. All key words must be use upper case, bold text.

5. MEF Document Roadmap

MEF draft specifications and the document roadmap are available in the members area on the Metro Ethernet Forum

website at /.

MEF 3

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 10 of 65

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

6. Circuit Emulation Service Definition

Ethernet CES provides emulation of TDM services, such as Nx64 kbit/s, T1, E1, T3, E3, OC-3 and OC-12, across a

Metropolitan Ethernet Network. The object of this is to allow MEN service providers to offer TDM services to

customers. Hence it allows MEN service providers to extend their reach and addressable customer base. For

example, the use of CES enables metro Ethernet transport networks to connect to PBX’s on customer premises and

deliver TDM voice traffic along side of data traffic on Ethernet.

The CES is based on a point-to-point connection between two Inter Working Functions (IWF). Essentially, CES

uses the MEN as an intermediate network (or ‘virtual wire’) between two TDM networks. This is handled as an

application of the Ethernet service, using the interworking function to interface the applications layer onto the

Ethernet services layer.

6.1 TDM

LINE

SERVICE

(T-LINE)

The TDM Line (T-Line) service provides TDM interfaces to customers (Nx64 kbit/s, T1, E1, T3, E3, OC-3, OC-12

etc.), but transfers the data across the Metropolitan Ethernet Network (MEN) instead of a traditional circuit switched

TDM network. From the customer perspective, this TDM service is the same as any other TDM service, and the

service definition is given by the relevant ITU-T and ANSI standards pertaining to that service.

From the provider’s perspective, two CES interworking functions are provided to interface the TDM service to the

Ethernet network. The CES interworking functions are connected via the Metro Ethernet Network (MEN) using

point-to-point Ethernet Virtual Connections (EVCs) as illustrated in Figure 1. (For the purposes of CES, the service

provider owning the CES interworking functions is viewed as the “customer” of the MEN, providing the ability to

use an Ethernet UNI, and the performance and service attributes associated with this concept).

The TDM Service Processor (TSP) block shown in Figure 1 consists of any TDM grooming function that may be

required to convert the TDM service offered to the customer into a form that the CES IWF can accept (see section

7.2.2). For example, the TSP may be a Framer device, converting a fractional DS1 service offered to the customer

into a Nx64 kbit/s service for transport over the MEN. The operation of the TSP is outside the scope of this

document.

The TSP and the CES IWF may physically reside in the Provider Edge (PE) unit at the provider’s nearest point-of-presence, or in a service provider owned box in a customer location (e.g. a multi-tenant unit). From the architecture

perspective, there is no difference between these alternatives.

TDMCECES(optional)IWFEFTTSPService Provider NetworkCESTSP(optional)IWFEFTTDMCETDM LinkTDM LinkMENEVCUNI-CUNI-NUNI-NUNI-CETH Access LinkETH Access LinkTDM SubscriberEthernet UNIDemarcationEthernet UNITDM SubscriberDemarcation

Figure 1: TDM Line Service over Metro Ethernet Networks

MEF 3

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 11 of 65

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

6.1.1 Operational Modes of a T-Line Service

The basic T-Line service is a point to point, constant bit rate service, similar to the traditional leased line type of

TDM service. However, service multiplexing may occur ahead of the CES inter-working functions, (e.g.

aggregation of multiple emulated T1 lines into a single T3 or OC-3 link), creating a multi-point to point or even a

multi-point to multi-point configuration (see Figure 2 below).

This service multiplexing is carried out using standard TDM multiplexing techniques, and is considered as part of

the TSP block, rather than the CES inter-working function. The TDM interface at the input of the CES inter-working function is the same as that output from the CES IWF at the opposite end of the emulated link. It is the

TSP that may be used to multiplex (or demultiplex) that TDM service into the actual TDM service provided to the

customer. This allows a TDM service to a customer to be provided as a collection of emulated services at lower

rates.

Point-to-point EVCsTDMCETSP /CES IWFT3TSP /CES IWFT3TDMCETSP /CES IWFT1TDMCEMENTSP /CES IWFT1TSP /CES IWFOC3TDMCETDMCE

Figure 2: Possible TDM Virtual Private Line Configurations

Hence there are three possible modes of operation of a T-Line service:

ii.

iii.

Unstructured Emulation mode (also known as “structure-agnostic” emulation)

Structured Emulation Mode (also known as “structure-aware” emulation)

Multiplexing mode

Modes (i) and (ii) are point-to-point connections. Mode (iii) permits multi-point-to-point and multi-point-to-multi-point configurations, although all of these modes are operated over simple point-to-point EVCs in the MEN.

6.1.1.1 Unstructured Emulation mode

In Unstructured Emulation Mode, a service is provided between two service-end-points that use the same interface

type. Traffic entering the MEN on one end-point leaves the network at the other end-point and vice-versa.

The MEN must maintain the bit integrity, timing and other client-payload specific characteristics of the transported

traffic without causing any degradation that would exceed the requirements for the given service as defined in the

Requirements section of this document. All the management, monitoring and other functions related to that specific

flow must be performed without changing or altering the service payload information or capacity.

MEF 3

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 12 of 65

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

Examples where unstructured emulation mode could be implemented are leased line services or any other transfer-delay sensitive (real time) applications. The specific transport rates and interface characteristics of this service are

defined in the Requirements section of this document.

6.1.1.2 Structured Emulation mode

In Structured Emulation Mode, a service that is provided between two service-end-points that use the same interface

type. Traffic entering the MEN on one end-point is handled as overhead and payload. The overhead is terminated

at the near end point, while the payload traffic is transported transparently to the other end. At the far end point the

payload is mapped into a new overhead of the same type as at the near end point.

The MEN must maintain the bit integrity, timing information and other client-payload specific characteristics of the

transported traffic without causing any degradation that would exceed the requirements for the given service as

defined in the Requirements section of this document. All the management, monitoring and other functions related

to that specific flow must be performed without changing or altering the service payload information or capacity.

An example of such a service is the transport of OC-3 when the SOH is terminated at both ends and the STS-1

payloads are transported transparently over the MEN. A second example is a fractional DS1 service, where the

framing bit and unused channels are stripped, and the used channels transported across the MEN as an Nx64 kbit/s

service. The specific transport rates and interface characteristics are defined in the Requirements section of this

document.

6.1.1.3 Multiplexing mode

In the multiplexing mode, multiple lower rate transparent services are multiplexed at a specific service-end-point of

the MEN into a higher digital hierarchy. Similarly, a higher rate service may be de-composed into several lower rate

services. For example, a customer may have several sites – a head office with a full DS1 connection, and several

satellites with fractional DS1 connections, as shown in Figure 3. The same architecture can be used for multiplexing

of other rate services, e.g. several full DS1 services onto a single DS3, or multiplexing of VT-1.5s into an STS-1.

The specific transport rates and interface characteristics are defined in the Requirements section of this document.

Service multiplexing is typically performed in the TDM domain as part of a TSP, not in the Ethernet domain. A

fractional TDM link going into the MEN comes out as a fractional TDM link, or at least as a payload containing

solely that fractional link. Multiplexing and de-multiplexing is performed outside the CES IWF, as part of any

native TDM signal processing, as shown in Figure 3. Therefore the customer service is multiplexed, but the

emulated service (i.e. the service handled by the IWF) is structured.

MEF 3

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 13 of 65

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

Fractional DS1 payloadto be multiplexedTDMmultiplexingfunction(TSP)Head OfficeTDMCEFractional DS1 linkTDMCESatellitesiteCES IWFCES IWFMENFull DS1 linkCES IWFPoint-to-point EVCsFractional DS1 linksTDMCETDMCESatellite sites

Figure 3: Example Multi-point to Point T-Line Multiplexed service

6.1.2 Bandwidth Provisioning for a T-Line Service

The Metro Ethernet service provider will need to allocate sufficient bandwidth within the network to carry the T-Line service. This may require very fine granularity of bandwidth provision to allow efficient allocation. For

example, an N x 64 kbit/s service may have very low bandwidth requirements where N is small. This could result in

very inefficient provisioning if the smallest unit increment of bandwidth provision is 1 Mbit/s. The following

sections outline three possible schemes to provision the bandwidth efficiently for low data rate CES.

6.1.2.1 Bandwidth allocation at 100 kbit/s granularity

The bandwidth required to be able to offer emulation of Nx64 kbit/s services increases with N in steps of 64kbit/s,

plus an overhead for encapsulation headers. Therefore, in order to be able to allocate MEN bandwidth efficiently

for such services, the bandwidth needs to be provisioned in similar step sizes. It is recommended that to achieve

reasonable efficiency, the granularity of service provisioning should be at 100 kbit/s or smaller.

However, most existing equipment only allows for bandwidth provision at multiples of 1 Mbit/s (or 1.5 Mbit/s for

much SONET-based Ethernet equipment), so this fine level of granularity is not guaranteed to be available.

Therefore alternative means of allocating bandwidth may need to be used to provide a reasonable level of efficiency,

such as described in sections 6.1.2.2 and 6.1.2.3 below.

6.1.2.2 TDM multiplexing

Multiple TDM services between the same two IWFs may be multiplexed together in the TDM domain before being

carried across the MEN. De-multiplexing at the far end is also accomplished in the TDM domain. For example,

several fractional DS1 services could be multiplexed onto a single full DS1 link before transmission across the MEN.

Bandwidth can then be provisioned for the full link, rather than individually for each fractional customer service.

MEF 3

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 14 of 65

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

Similarly, the same architecture can be used for multiplexing of other rate service, e.g. several full DS1 services

onto a single DS3 or SONET link.

6.1.2.3 Ethernet multiplexing

Another alternative is to multiplex several circuits across a single Ethernet Virtual Connection, as shown in Figure 4.

TDM links(may be full or fractional)TDMCETDMCETDMCETDMCETDMCECES IWFCES IWFTDMCEMENCircuit emulated linksCustomer sites(may or may not belong tothe same customer)TDMCETDMCECES IWFPoint-to-point EVCsTDMCETDMCE

Figure 4: Multiplexing across a single Ethernet Virtual Connection

All TDM circuit emulation between any two given IWFs is handled across a single point-to-point EVC. Individual

circuit emulated links are carried across that EVC using Ethernet multiplexing.. Customer separation is maintained

using this multiplexing.

The total bandwidth of circuit emulation traffic between two points is known in the case of constant bit rate, always

on service. Therefore the amount of traffic across that EVC is known and can be provisioned accordingly. This

allows efficient bandwidth provisioning. For example, 5 fractional TDM services at 384 kbit/s could share a single

2 Mbit/s EVC, and don’t have to be allocated 1 Mbit/s each.

6.2 TDM

ACCESS

LINE

SERVICE

(TALS)

The second type of TDM service that can be offered over Metropolitan Ethernet Networks is where the MEN

service provider hands off one (or both) ends of the network to a second network (e.g. the PSTN). For example,

Figure 5 shows the case where the customer interface is TDM, and the hand-off to an external network (in this case

the PSTN) is via some form of TDM or SONET trunk line (e.g. OC-3). The prime use of this type of service is

where the MEN is used as an access network onto the second network. With TALS service the customer-facing

IWF can be located on the customer’s site but is still under the control of the MEN operator.

Multiple customer services may be multiplexed up onto a single trunk to be handed off to the second network

(Figure 6). As with T-Line service, this multiplexing is implemented using conventional TDM techniques in a

native signal processing block. In some instances, both ends of the emulated TDM service may be within the

service provider network, e.g. backhaul of ATM or SONET services.

MEF 3

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 15 of 65

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

As with T-Line service, the customer-facing TSP and CES IWF may physically reside in the Provider Edge (PE)

unit at the provider’s nearest point-of-presence, or in a service provider owned box in a customer location (e.g. a

multi-tenant unit). From the architecture perspective, there is no difference between these alternatives.

TDMCECES(optional)IWFEFTTSPService Provider NetworkCESIWFEFTTSPMUXPSTNTDM LinkTDM Trunk LinkMENEVCUNI-CUNI-NUNI-NUNI-CETH Access LinkETH Access Link

TDM SubscriberEthernet UNIDemarcationEthernet UNINetworkDemarcationFigure 5: Handoff of a multiplexed trunk to an external network

6.2.1 Operational Modes of a TALS Service

The TALS service is essentially very similar to the multiplexed, multi-point-to-point T-Line service. The two

services use the MEN in the same manner (see Figure 6). The only difference is that the final multiplexed service

(e.g. OC-3) is handed off to another network rather than an end customer. As such, it may have some performance

requirements deriving from the requirements of the second network not present in the T-Line service.

The MEN must maintain the bit integrity, timing and other client-payload specific characteristics of the transported

traffic without causing any degradation that would exceed the requirements for the given service as defined in the

Requirements section of this document. All the management, monitoring and other functions related to that specific

flow must be performed without changing or altering the service payload information or capacity.

MEF 3

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 16 of 65

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

Point-to-point EVCsTDMCETSP /CES IWFT3TSP /CES IWFTDMCETDMCETSP /CES IWFT1MENT3TDMCETSP /CES IWFT1TSP /CES IWFOC3Multiple subscribershanded off toexternal networkPSTN

Figure 6: Possible TDM Handoff Configurations

6.3 CUSTOMER

OPERATED

CES

It is also possible for customers to operate the Circuit Emulation Service themselves across an E-Line service (see

Figure 7). However, in order to operate CES at a reasonable level of quality, the service provider will need to offer

a “premium SLA”, with tighter definitions of parameters such as packet delay, variation in packet delay, and packet

loss. The requirements section of this document covers the parameters that need to be controlled, and the

appropriate range of values over which CES can be operated with acceptable quality.

Some customers may choose to operate CES across a standard E-Line service with no special SLA for cost reasons.

In this case, the level of quality experienced is entirely the customer’s own responsibility. Since from the service

provider’s perspective this is purely an Ethernet service, the definition of this service is considered to be outside

the scope of this document, other than to document possible parameters of a service level specification for CES-capable E-Line service.

TDMCECES(optional)IWFEFTTSPService Provider NetworkCESTSPIWF(optional)EFTTDMCETDM LinkTDM LinkMENEVCUNI-CUNI-NUNI-NUNI-CCUETETH Access LinkETH Access LinkCUET

Ethernet UNICustomer DemarcationEthernet UNICustomer DemarcationFigure 7: Customer Operated CES over a Metropolitan Ethernet Service (e.g. E-Line)

MEF 3

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 17 of 65

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

6.4 MIXED-MODE

CES

OPERATION

A further scenario is a “mixed mode service”, where the customer interface is Ethernet at one side, and TDM at the

other. Therefore the customer is providing their own interworking function at one end of the service, and this must

inter-operate with the service provider’s interworking function at the far end (Figure 8).

This service may be operated using the same methods as the other services described in this document. However, it

may create significant issues as far as troubleshooting links between the service provider and the customer. For

example it may be difficult to determine whether a fault is in the customer’s own equipment, or in the service

provider’s equipment. Service providers offering mixed-mode services should be aware of the potential issues

involved.

Resolution of these types of issues, as well as any operations and management issues involved with running between

IWFs in different administrative domains are for further study. The MEF do not plan any further work on the

definition of such a service at present.

TDMCECES(optional)IWFEFTTSPService Provider NetworkCESTSPIWF(optional)EFTTDMCETDM LinkTDM LinkMENEVCUNI-CUNI-NUNI-NUNI-CCUETETH Access LinkETH Access LinkCUETTDM SubscriberDemarcation

Ethernet UNICustomer DemarcationFigure 8: Mixed-Mode Service

Ethernet UNIMEF 3

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 18 of 65

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

7. Circuit Emulation Service Framework

This section is intended to provide a framework within which the actual requirements for the Circuit Emulation

Service can be understood.

7.1 GENERAL

PRINCIPLES

In most service provider networks, SONET/SDH has been used as the technology for transporting customers’ PDH

or SONET/SDH traffic. The purpose of the CES is to allow the MEN to serve not only as a transport of Ethernet

and data services, but also as a transport of customer’s TDM traffic.

The CES solution in the MEN should therefore make the MEN behave as a standard SONET/SDH and/or PDH

network, as seen from the customer’s perspective. The intention is that the CES customer should be able to use the

same (legacy) equipment, regardless of whether the traffic is carried by a standard SONET/SDH or PDH network, or

by a MEN using CES.

7.1.1 Use of External Standards

Section 3.2 of the “Architectural Principles of the Internet” [RFC 1958] states “If a previous design, in the Internet

context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good

technical reason not to.”

Much of the material in the next two sections has been adapted from the ATM specification for circuit emulation

[ATM CES], since this covers broadly similar requirements. It also references the various applicable standards from

the ITU-T or ANSI for TDM services.

7.2 SERVICE

INTERFACE

TYPES

There are two basic service interfaces in the TDM domain. These are shown in Figure 9, and are defined as follows:

1) TDM Service Interface: The TDM service that is handed off to the customer or TDM network operator. TDM

services fall into two categories, unstructured and structured.

2) Circuit Emulation Service Interface (CES TDM Interface): The actual circuit service that is emulated between

interworking functions through the MEN.

For unstructured TDM service, the CES Interface carries all information provided by the TDM Service Interface

transparently. The service is emulated in its entirety by the IWF, including any framing structure or overhead

present.

For structured TDM service, the TDM service interface is operated on by the TSP (TDM Service Processor) to

produce the service that is to be emulated across the MEN. A single structured TDM service may be decomposed

into one or many CES flows, or two or more structured TDM services may also be combined to create a single CES

flow.

TDM ServiceInterfaceCustomerTDMServiceTSP(optional)(e.g. framing,mux/demux)CES TDMInterfaceCES IWF TypeTDMIWFPacketizationCES PayloadCES IWFAdaptedPayloadECDXEFTAdds DA, SA,and CRC fieldsEthernetInterfaceIWFAdds ECIDand Length/Type field

Figure 9: Functional Elements and Interface Types

MEF 3

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 19 of 65

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

7.2.1 Examples of TDM Service Interfaces

Table 1 shows examples of possible TDM service interfaces. These service interfaces are defined as standardized

PDH, SONET or SDH interfaces.

Unstructured TDM services are either emulated as is by the CES IWF, or mapped by the TSP onto the CES interface

without modifying their content. These services preserve the framing structure as well as SONET/SDH overhead as

input to the TDM service interface. These services provide point-to-point connectivity across a MEN.

Structured services may be either demultiplexed into any of their defined service granularities or multiplexed with

other structured TDM services. For example, an OC-3 structured service can be demultiplexed into three separate

STS-1 signals. Each of these signals can then be circuit emulated by different IWF across the MEN to one or more

service end-points. At these IWFs, these STS-1 can be reassembled with other STS-1s (from different originating

services) to form an entirely new OC-3 signal (provided each originating site uses a PRS level clock). Structured

service can be used to provide point-to-point, point-to-multipoint, and multipoint-to-multipoint TDM services.

TDM Service

Interface

DS1

DS3

OC-1

OC-3

OC-3c

STM-1

STM-1c

OC-12

OC-12c

STM-4

STM-4c

Unstructured

TDM Service

Yes

Structured TDM

Service

Yes

Structured TDM Service Granularity

Nx64 kbit/s

DS1, Nx64 kbit/s

Nx64 kbit/s

E1, Nx64 kbit/s, DS0

STS-1, VT-1.5, VT-2

STS-3c

VC-11 (DS1), VC-12 (E1), VC-3 (DS3, E3, other)

VC-4, VC-3, VC-11, VC-12

VT-1.5 (DS1), VT-2 (E1),

STS-1 (DS3, E3, other), STS-3c

STS-12c

VC-11 (DS1), VC-12 (E1),

VC-3 (DS3, E3, other), VC-4

VC-4-4c

Table 1: TDM Service Interfaces

7.2.2 TDM Service Processor (TSP)

The TDM Service Processor is defined as a function, operating in the TDM domain, that:

a. modifies the bit rate or contents of the service to be emulated (e.g. overhead termination, removal of unused

channels in a fractional service)

b. multiplexes two or more TDM services into a single service to be emulated, and de-multiplexes the composite

service into its component services at the remote end as required (e.g. multiplexing of several Nx64kbit/s

services onto a larger Nx64kbit/s, or multiplexing of several DS1 services onto a DS3)

c. transparently maps the TDM service onto a different service to be emulated (e.g. asynchronous mapping of a

DS1 onto a VT-1.5)

MEF 3

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 20 of 65

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

It may make use of standard or proprietary techniques, and is not considered part of the inter-working function.

Therefore the requirements in this document and the related implementation agreements do not cover the operation

of any TSP function, which is considered part of an equipment vendors own value added domain.

By this definition therefore, a T1/E1 Framer would be considered a TSP (terminates the framing bits, breaks the

service down into an Nx64kbit/s service), whereas an LIU would not (bit rate and data to be emulated are the same

as in the TDM service offered to the customer). Another example of a TSP would be a DS1 to VT-1.5 mapper.

7.2.3 Circuit Emulation Inter-working Function (CES IWF)

Circuit Emulation Service is defined as an application service in terms of layered network model defined in the

MEN Architecture framework document. It uses the MEN as an intermediate network (or “virtual wire”) between

two TDM networks. The Circuit Emulation Interworking Function is therefore defined as the adaptation function

that interfaces the CES application to the Ethernet layer.

The CES IWF is responsible for all the functions required for an emulated service to function, e.g. data packetization

and de-packetization (including any padding required to meet the minimum Ethernet frame size), sequencing,

synchronization, TDM signaling, alarms and performance monitoring. Listed in Table 2 are the defined interface

types required to support circuit emulation over the MEN. These services are divided by payload type, CES

Interface type, CES rate, and IWF type. These interface definitions are illustrated in Figure 9.

Payload Type

PDH

CES TDM Interface Type

NDS0

DS1

DS3

SONET/SDH STS-1

STS-3

STS-3c

STM-1

STS-12

STS-12c

STM-4

SONET/SDH Tributary VT-1.5

VT-2

VC-11

VC-12

VC-3

STS-1P

STS-3P

VC-4

STS-3cP

STS-12P

STS-12cP

CES Rate

N x 64 kbit/s

1.544 Mbit/s

2048 kbit/s

34368 kbit/s

44.736 Mbit/s

51.84 Mbit/s

155 Mbit/s

622.08 Mbit/s

1.728 Mbit/s

2.176 Mbits

1.728 Mbit/s

2176 kbit/s

48384 kbit/s

50.112 Mbit/s

150.336 Mbit/s

601.344 Mbit/s

IWF Type

NDS0-CE

DS1-CE

E1-CE

E3-CE

DS3-CE

STS-1-CE

STS-3-CE

STS-3c-CE

STM-1-CE

STS-12-CE

STS-12c-CE

STM-4-CE

VT-1.5-CE

VT-2-CE

VC-11-CE

VC-12-CE

VC-3-CE

STS-1P-CE

STS-3P-CE

VC-4-CE

STS-3cP-CE

STS-12P-CE

STS-12cP-CE

MEF 3

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 21 of 65

Payload Type CES TDM Interface Type

VC-4-4

VC-4-4cP

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

CES Rate

601.344Mbit/s

IWF Type

VC-4-4P-CE

VC-4-4cP-CE

Table 2: CES TDM Interface Definition

7.2.3.1 PDH Circuit Emulation Service

PDH emulation services provide transport of PDH services through the MEN. Managed by the IWF, as defined in

Table 2, these services can be used to support structured or unstructured TDM service interfaces. As structured

TDM services, the input TDM service can be demultiplexed into its service granularity as defined in Table 1. This

service granularity includes DS0, Nx64 kbit/s, DS1, E1, DS3 or E3. Likewise, multiple structured TDM services

can be multiplexed into a single service and circuit emulated across the MEN as this new service. For example, a

multiple Nx64 kbit/s services can be multiplexed into a DS1 which is circuit emulated across the MEN and output as

a DS1 structured service.. These interface rates and IWFs are presented in Table 2.

7.2.3.2 SONET/SDH Circuit Emulation Service

SONET/SDH emulation services provide transport of SONET/SDH services through the MEN. Managed by the

IWF, as defined in Table 2, these services can be used to support structured or unstructured TDM service interfaces.

As structured TDM services, the input TDM service can be demultiplexed into its service granularity as defined in

Table 1. This service granularity includes STS-1, STM-1 or the appropriate virtual container. Likewise, multiple

structured TDM services can be multiplexed into a single service and circuit emulated across the MEN as this new

service. These interface rates and IWFs are presented in Table 2.

SONET/SDH emulation service provides emulation of the following services:

1. Higher order Virtual Container (HOVC): VC-3/STS-1, VC-4/STS-3c, VC-4-4c/STS-12c

2. Lower order Virtual Container (LOVC): VC-11/VT-1.5, VC-12/VT-2, none/VT-3, VC-2/VT-6, VC-3/none

SONET terminology refers to HOVC as Synchronous Payload Envelope (SPE) and for LOVC as Virtual Tributary

(VT).

Figure 10 shows an example of the functional blocks used in SONET/SDH structured emulation service. For

SONET/SDH interface, a SONET/SDH framer TSP is used to terminate and handle the section and line overheads.

The SONET/SDH Virtual containers (SPEs) are extracted and passed to the SONET/SDH IWF(s). Each virtual

container (SPE) can be sent to a different destination IWF. The ECDX and EFT are used to add the required

multiplexing and Ethernet headers and trailers as described in Figure 9. For PDH interfaces, a SONET/SDH mapper

TSP is used to map the PDH signal (T1/E1/T3/E3) into SONET/SDH virtual containers (SPE/VT). Each virtual

container can be sent to a different destination IWF, and either groomed to a SONET/SDH interface or mapped back

to a PDH interface.

TSPMapper To CEPDHIWFIWFIWFTSPFramer To MENECDXEFTSDH

Figure 10: Functional Elements of SONET/SDH emulation service

MEF 3

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 22 of 65

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

7.2.4 Emulated Circuit De/Multiplexing Function (ECDX)

The Emulated Circuit De-multiplexer (ECDX) is a function, operating in the packet domain, that:

a. Selects one (or more) IWF as the final destination of each Ethernet frame received from the MEN based on an

Emulated Circuit Identifier (ECID) attribute within the frame header.

b. Prepends an ECID attribute for each Ethernet frame sent to the MEN to allow circuit de-multiplexing on the

MEN egress.

c. Assigns the length/type field to each Ethernet frame sent to the MEN.

By this definition, equipment supporting 8 DS1 TDM service interfaces would be able to multiplex 8 DS1 interface

onto a single EVC. Each emulated circuit would be identified by a unique ECID attribute. The ECDX function

would examine the ECID attribute of received Ethernet frames and compare it to its local ECID to IWF association.

According to the look-up result the ECDX would pass the circuit emulation payload to the relevant IWF for

processing.

7.2.5 Ethernet Flow Termination Function (EFT)

A termination function is defined as: “A transport processing function which accepts adapted characteristic

information from a client layer network at its input, adds information to allow the associated trail to be monitored

(if supported) and presents the characteristic information of the layer network at its output(s) (and vice versa)”

In the context used here, an Ethernet Flow Termination function takes an adapted payload from the ECDX (the

MAC client information field), along with a Length/Type attribute describing it as CES payload. It adds the MAC

Destination and Source addresses, and finally the frame check sequence.

In the CE-bound direction, the EFT takes in an Ethernet frame from the MEN. It determines whether it contains CES

payload from the Length/Type field, and forwards it to its associated ECDX function, for passing to the appropriate

CES IWF.

7.2.6 Direction terminology

For each direction of an emulated circuit, there is a pair of CES interworking functions. The MEN-bound IWF

handles the packetization of the TDM data, encapsulation into Ethernet frames and forwarding into the Ethernet

network. The corresponding CE-bound IWF extracts the TDM data from the Ethernet frames, and recreates the

TDM service. Each direction of the service is handled separately by second pair of IWFs. Hence for a given MEN-bound IWF, the corresponding CE-bound IWF is at the other side of the MEN.

CES TDMInterfaceCES EthernetInterfaceCES EthernetInterfaceCES TDMInterfaceMEN-boundIWF 1CE-boundIWF 1MENCE-boundIWF 2MEN-boundIWF 2MEF 3

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 23 of 65

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

MENTSPCE1CES

IWFPHYME1MEnPHYCES

IWFTSPCE2SDCE1SDTDM1SDIWF1SDED0SDED1SDEDmSDEDnSDIWF2SDTDM2SDCE2Circuit Emulation ServiceTDM Emulation Service

Figure 12: Timing distribution architecture showing clock domains

The following notations are used in Figure 12:

Attribute

CES IWF

CEn

TSP

Description

Circuit emulation service interworking function.

Customer edge devices terminating/originating TDM circuits

The TDM Service Processor performs all TDM functions necessary to support structured or

unstructured TDM emulation service. These functions are performed in the TDM domain using

standardized techniques.

Metro Ethernet devices providing Circuit Emulation Service transport in the MEN

Physical interface terminating Ethernet traffic

The TDM-end service circuits

The CES IWF providing edge-to-edge-emulation for the TDM circuit

The synchronization domain used by Ethernet network elements (NEs) in the MEN cloud. This

timing information is used to transport packets between Ethernet NEs providing the CES. Since each

of these devices operates independently, the synchronization mode of each device must be

provisioned separately. Typical timing modes include line, external and free-run.

The synchronization domain used by CES IWF. This timing is used to transport the circuit emulated

service across the MEN. This synchronization domain is specific to the CES interface types as shown

in Table 2 (CES Interface Definition). Details of this synchronization domain are contained in the IA

reference as shown in Table 2 (CES Interface Definition)..

The synchronization domain used by the TSP. This timing is used to transport TDM signals between

the TSP and CE. This synchronization domain supports through timing mode.

The synchronization domain used by the CE devices to establish the TDM service clock. This timing

is used to transport TDM signals between the CE and the TSP. This synchronization domain supports

external, line, or free-run timing modes.

Table 3: Timing Distribution Definitions

One of the objectives of edge-to-edge-emulation of a TDM circuit is to preserve the service clock with a perfomance

level as specified in the relevant Implementation Agreements. For example, the performance objective could be to

MEF 3

MEn

PHY

SDEdn

SDIWFn

SDTDMn

SDCen

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 24 of 65

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

meet the G.823 Traffic Interface specification. The service clock can be either generated at a CE via external timing

mode, or recovered from the TDM bit stream via line/loop timing mode. It should be noted that loop timing mode is

a recovery process where timing is extracted from only one available input bit stream. Line timing mode is a

recovery process where timing is extracted from one of several input bit streams. Since the number of available

timing inputs is based on network design and system architecture, this document will use “line timing” when

describing timing modes where either line or loop timing are used.

Typical timing modes for a point-to-point CES connection are shown in Table 4. These timing modes are defined in

[T1.101] and [G.812].

Timing CE1 Timing Mode CE2 Timing Mode Comments

Option

1 External to PRS

traceable source

External to PRS

traceable source

Line timing mode

External to PRS

traceable source

Line timing mode

CE1 and CE2 will operate in a Plesiochronous mode. If

connected to other TDM circuits (in other synchronization

domains) network slip-rate objectives will be met.

CE2 will have the same average frequency as CE1. If

connection to other TDM circuits (in other synchronization

domains) network slip-rate objectives will be met.

CE1 will have the same average frequency as CE2. If

connection to other TDM circuits (in other synchronization

domains) network slip-rate objectives will be met.

CE2 will have the same average frequency as CE1. If

connection to other TDM circuits (in other synchronization

domains) undesirable slip performance may result.

CE1 will have the same average frequency as CE2. If

connection to other TDM circuits (in other synchronization

domains) undesirable slip performance may result.

CE1 and CE2 synchronization domains will operate

independently. TDM data will experience slips between

CE1 and CE2 and TDM circuits in other synchronization

domains.

3 External to PRS

traceable source

Line timing mode 4 Free-run mode

5 Line timing mode Free-run mode

6 Free-run mode Free-run mode

Table 4: CE Synchronization modes and Expected Timing performance

When the TDM circuit is transported via CES, this continuous signal is broken into packets at the MEN-bound IWF

of the CES connection and reassembled into a continuous signal at the CE-bound IWF of the CES connection. In

essence, the continuous frequency of the TDM service clock is disrupted when the signal is mapped into packets.

In order to recover the service clock frequency at the egress of the CES connection, the interworking function must

employ a process that is specific to the CES interface type. The description and requirements of the IWF service

clock recovery are contained in the Implementation Agreement for that service.

7.3.1 CES Interworking Function- Synchronization Description

The synchronization block diagram for the CES Interworking function is shown in Figure 13.

MEF 3

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 25 of 65

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

External TimingReferenceCES IWFETFDataCLKTo To MENR

Figure 13: CES IWF Synchronization Reference Model

The following notations are used in Figure 13:

Attribute

IWF

Processor

TDM Line

Ethernet

Line

EXT

SDIWF

ETF

Description

Performs all data, addressing and timing functions necessary to support circuit emulation over the

MEN.

A line timing option may be used to provide the IWF with a timing reference. TDM Line timing will

extract timing from either the TDM service SDTDM.

Ethernet Line timing will extract timing from either the MEN SDED or from the arriving Ethernet

frames.

An External timing option may be used to provide the IWF with a timing reference

An internal timing reference may be used to provide the IWF with a timing reference. This internal

timing reference may either be a free-running oscillator or an oscillator in holdover mode.

The synchronization domain for the IWF. The definition and requirements for the SDIWF

may be

found in the IA for the specific IWF per table 2 (CES Interface Definition)

Physical interface terminating Ethernet traffic

Table 5: CES IWF Synchronization Definitions

The main goal of the CES IWF is to preserve the service clock of the TDM service through the MEN. The CES

IWF must preserve the service clock to the accuracy defined in section 7 of this document even under the levels of

MEN jitter defined in section 9.2.

The operation and definition of the interworking functions are specific to the CES interface type as shown in Table 2

(CES Interface Definition Table). Specific information about operation and requirements for specific interworking

functions is contained in the implementation agreements as indicated in Table2 (CES Interface Definition Table).

The IWF can use a variety of timing inputs to use as a reference for service clock recovery. A list of the five

available timing inputs used by the CES IWF are shown below:

1. Line timing (from the CE) – This mode is used to recover timing from a CE. In order for this timing mode to

PRS traceable, the CE must be provisioned to recover and transmit PRS traceable timing. Line timing should

be used if synchronization messaging is available (e.g., SONET or SDH line timing sources).

MEF 3

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 26 of 65

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

2. Line timing (from the MEN) – This mode is used to recover timing from the MEN. In order for this timing

mode to be PRS traceable, the adjacent Ethernet NE (in the MEN) must be provisioned to recover and transmit

PRS traceable timing. Line timing should be used if synchronization messaging is available (e.g., SONET or

SDH line timing sources). Line timing can also include deriving a clock from incoming Ethernet packets (e.g.

use of adaptive or differential clock recovery methods).

3. External Timing – This mode is used to recover PRS traceable timing from a co-located building integrated

timing supply (BITS). Timing is typically sent to the TSP/IWF as an all ones DS1 or E1 with framing.

Synchronization status messaging (SSMs) may also be transmitted over the DS1 link using a “blue signal” (all

ones without framing) or via SSMs on the ESF data link as defined by ANSI T1.101.

4. Free-Run – This mode is considered a standalone mode. It should only be used when a suitable line or external

timing reference is not available. The frequency and stability of this timing mode is determined by the

TSP/IWF’s internal oscillator.

5. Holdover – This mode is usually considered a backup or protection timing mode. Holdover mode may be

initiated when the external or line timing references have been lost due to a failure. This failure is indicated to

the CES IWF via a loss of frame (LOF), loss of signal (LOS) or SSM indication. Unlike free-run, this timing

mode relies on the TSP/IWF’s internal oscillator that has been trained by an external timing reference (e.g., PRS

traceable timing source). See ANSI T1.101 for performance specifications of this and other timing modes.

Holdover may also be used when there is a cessation of activity on the MEN-bound TDM interface (e.g. due to

the normal operation of a variable bit rate IWF).

7.3.2 Synchronous IWF and Associated Tributaries

Synchronous IWFs require that the IWF synchronization domain (SDIWF) at both the MEN-bound IWF and the CE-bound IWF use common clock synchronization (e.g. timing that is traceable to the same physical clock).

Unless specific mechanisms have been put in place to ensure that a common clock is distributed between both IWFs,

it should be assumed that the IWFs are NOT synchronous. It is not reasonable to assume the IWFs have suitable

clocking information unless it has been specifically provided for.

Tributaries to the IWFs consist of those TDM services that originate at the CE and are terminated at the IWF. The

service clock of each tributary may be either synchronous (PRS traceable) or asynchronous (not PRS traceable).

7.3.2.1 Synchronous IWF and Tributaries

Synchronous IWF: In this scenario, the synchronization domains at the MEN-bound and CE-bound IWFs (SDIWF)

use common clock synchronization (e.g. timing that is traceable to the same physical clock).

Synchronous Tributary: The synchronization domains of the CE devices (SDCen) require that at least one of the CE

devices use external timing that is PRS traceable. The other CE, in the CES connection, may be either line-timed to

the originating CE or externally-timed to a PRS traceable source.

7.3.2.2 Synchronous IWF and Asynchronous Tributaries

Synchronous IWF: In this scenario, the synchronization domains at the MEN-bound and CE-bound IWFs (SDIWF)

use common clock synchronization (e.g. timing that is traceable to the same physical clock).

Asynchronous Tributary: The synchronization domains of the CE devices (SDCen) require that at least one of the

CE devices be externally-timed to a non-PRS traceable source or use its internal free-running oscillator. The other

CE can be either line-timed, be externally-timed, or operate on its internal free-running oscillator. Of these options,

only the line-timed option will provide slip-free performance under non-fault conditions (see Table 4).

7.3.3 Asynchronous IWF and Associated Tributaries

In the Asynchronous network, the synchronization domains of all IWFs (SDIWF) do not use a common source of

timing. For example, the IWFs may receive plesiochronous timing as defined in [T1.101]. Tributaries to the IWF

MEF 3

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 27 of 65

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

consist of TDM services that originate at the CE and are terminated at the IWF. At the TDM Service Processor,

the service clock of each TDM tributary (SDCen) is terminated. This service clock will be used to support any

functions necessary to create structured or unstructured TDM emulation services. After these services are created,

the service clock along with the TDM data are then input to the CES IWF.

7.3.3.1 Asynchronous IWF, Asynchronous Tributaries

Asynchronous IWF: In this scenario, not all of the synchronization domains of the IWF devices (SDIWF) use

common clock synchronization (e.g. timing from the same physical clock). Timing distribution for the IWF may be

configured with each either line-timed to the MEN, line timing to a dedicated CE, or externally-timed to a PRS

traceable source.

Asynchronous Tributary: The synchronization domains of the CE devices (SDCen) require that at least one of the

CE devices be externally timed to a non-PRS traceable source or use its internal free-running oscillator. The other

CE can be either line-timed, externally-timed, or operate on its internal free-running oscillator. Of these options,

only the line timed option will provide slip-free performance under non-fault conditions (see Table 4).

7.3.3.2 Asynchronous IWF, Synchronous Tributaries

Asynchronous IWF: In this scenario, not all of the synchronization domains of the IWFs (SDIWF)

use common

clock synchronization (e.g. timing from the same physical clock). Timing distribution for the IWFs may be

configured with each either line timed to the MEN, line-timing to a dedicated CE, or externally-timed to a PRS

traceable source.

Synchronous Tributary: The synchronization domains of the CE devices (SDCen) require that at least one of the CE

devices use external timing that is PRS traceable. The other CE, in the CES connection, may be either line-timed to

the originating CE or externally-timed to a PRS traceable source.

7.3.4 Synchronization Administration

Proper synchronization administration is crucial to support the transport of TDM emulation and circuit emulation

services. Each synchronization domain in the CES needs to be considered and provisioned independently. Table 6

provides a summary of typically available options per synchronization domain.

SDCE

External

Line

Free-Run

IWF

SDIWF

Per IA

TSP

SDTDM

External

Line – CE

Line-MEN

Free-Run

Table 6: Timing Options per Synchronization Domain

Proper synchronization administration begins with the following concepts:

• Separate and Diverse – Synchronization equipment and paths should follow separate and diverse paths. This

reduces the chance that a single point of failure will cause service disruption. This philosophy extends to

equipment placement, cable routing, powering sources and network element configuration.

Synchronization Trail – All synchronization flows have a defined source and end. The context of this flow is

based on a logical flow rather than a topology (which could be linear, ring, mesh, or a combination of these).

The flow can even span multiple transport technologies including Ethernet, SONET and SDH. The source of a

synchronization trail should be from an independent reference that is either PRS traceable or from a free-running oscillator. The synchronization trail ends on a specific device that does not further propagate the source

timing information. Such a terminating device is necessary to prevent timing loops, which will cause transport

errors in the physical layer. Intermediate equipment in the synchronization trail can use timing information

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

MEN

SDED

PRS Traceable

Non-PRS Traceable

•

MEF 3

Page 28 of 65

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

derived from the source in a daisy-chained configuration. It should be noted that upstream timing events

(protection switching, holdover events, clock failures, etc.,) will be propagated to downstream equipment in this

configuration. For these cases, downstream equipment will need to have pre-determined fault modes to deal

with these circumstances when they arise. Such fault modes may include protection switching to use a different

line-timed reference or entry into holdover.

• Service Clock Preservation – The service clock is defined at the timing source used to generate the client

signal. In a CES transport network, the service clock frequency must be preserved in order to have error-free

transport of the physical layer. That is to say that the average bit rate of the transmitting and receiving

Customer Edge devices must be the same. Otherwise, the transport capability of the CES will be compromised.

Synchronization Traceability – In synchronization network planning, it is important to know where a timing

source originates, how it flows in the network, and its quality. The concept of traceability provides the answers

to these quantities. Synchronization flows can be described in terms of source traceability. That is to say, that

timing originates at a physical location and is used by equipment in a synchronization trail either by external or

line timing options. Common clock distribution is an example of a source traceable clock scheme. In the case

of frequency traceability, the quality of a timing signal can be specified. For example, the frequency of

synchronization sources may be specified as being PRS traceable or accurate to within 1 e-11 or (.00001 parts

per million). Plesiochronous clock distribution is an example of a frequency traceable clock scheme.

•

Three synchronization administration models are presented in the following sections. These models have been

chosen to illustrate how they may be used to accommodate the CES definitions presented in Section 6. These

models are:

•

Single Service Provider Owned Network – A single service provider controls the entire transport

synchronization trail. The service synchronization trail is separate.

Multi-Service Provider Owned Network – Multiple service providers control the transport synchronization

trail. The service synchronization trail is separate.

Private (customer owned) Network – A customer controls the entire transport and service synchronization

trails.

Table 7 summarizes these synchronization administration models and shows how they map to the CES service

definitions of Section 6.

CES Service

TDM Virtual Private Line

Service

TDM Access Line Service

Customer operated CES

over Metro Ethernet Service

Sync Admin Model Notes

Single Service Provider Can also be used with Private Network model.

Model

Single Service Provider Handoff to PSTN does not retime the payload (DS1 or

Model DS3). Therefore, there is no new sync trail.

Multi-Service Provider

Model

IWF at CES egress may be owned by a different service

provider.

Table 7: CES Services and supporting Synchronization Administration Models

7.3.4.1 Single Service-Provider Owned Network

The synchronization administration for a single service-provider owned network is illustrated in Figure 14.

MEF 3

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 29 of 65

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

SDCEServicesync trailTransportsync trailCE1SDIWFSDTDMIWFTSPTransport TimingSDIWFSDTDMIWFTSPSDCECE2MENSDEDService TimingFigure 14: Synchronization Administration for a Single Service-Provider Network

A summary of available timing options for the Single-Service Provider owned network is presented on Table 8.

Device

Timing

Domain

SDCE

Timing Options

External

Notes

Customer Option: Requires a collocated BITS or SSU to supply a

timing input to the CE. May be used as a source for the

synchronization trail.

Customer Option: May be used at the end of a synchronization trail.

Customer Option: May be used as the source for the synchronization

trail.

Service Provider Option:. Timing recovery for CES IWF must match

the IWF type. Details can be found in the IA as specified on Table 2

(CES Interface Definition).

Service Provider Option: Requires a collocated BITS or SSU to

supply a timing input to the PE.

Not Used since CE and TSP are on different synchronization trails.

Service Provider Option: Used if the IWF can provide timing.

Consistent with the service needs of the TSP. Options and capabilities

for a specific IWF is specified per the appropriate IA.

Service Provider Option: Used only if there is no suitable line or

external timing source.

Service Provider Option: Requires that all elements use PRS

traceable timing

Service Provider Option: Requires that one or more elements not use

PRS traceable timing.

Line

Free-Run

IWF SDIWF

See IA

TSP SDTDM External

Line – CE

Line-MEN

Free-Run

MEN SDED

PRS Traceable

Non-PRS

Traceable

Table 8: Timing Options Single-Service Provider Owned Network

Note that in the Single-Service Provider configuration, the synchronization trails for service-timing and transport-timing are separate. Separation of these synchronization trails is typically done for administrative and liability

reasons. An end customer will not be able to manage a service provider’s timing equipment. Likewise, a service

provider would typically not use timing from a CE due to the reliability and liability issues associated with a single

point of failure.

Separate synchronization trails also means that the physical timing source used to derive the service clock is not the

same as that used in the transport network (TSP/IWF and MEN). This is not to say that the source for the service

and transport cannot be PRS traceable, simply that one is not the source for the other.

MEF 3

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 30 of 65

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

7.3.4.1.1 Service Timing – Single Service Provider Network

The Customer Edge synchronization domain (SDCE) is owned and maintained by the customer. Timing for the CE

(SDCE) requires that at least one CE be the source of timing. Referring to Table 4, any of the 6 options listed can be

used. The choice of which option to use will depend on economic and service needs. A PRS traceable source can

be highly reliable and accurate but requires physical placement and substantial engineering support. It is for this

reason that option 1 may be more expensive to administer than options 2 and 3.

Options 4 and 5 rely on the CE’s internal oscillator to provide a frequency source for the service clock. In this case,

due to the relaxed need for additional timing equipment (BITS or SSUs) this option may be less expensive to

administer than option 1 and require less engineering support.

Option 6 may yield undesirable slip performance due to the frequency difference between the free-running clocks.

This option is generally the least expensive but also has the lowest overall performance.

7.3.4.1.2 Transport Timing – Single Service-Provider Network

Timing for the single service-provider network assumes that the service provider owns the TSP/IWF and all of the

Ethernet devices in the MEN. The equipment will encompass synchronization domains: SDIWF, SDTDM

, and SDED.

For this case, it is up to the service provider to perform the synchronization administration of all transport and

synchronization equipment.

Regardless of synchronization options that the service provider may use, as listed in Table 5, it is the ability of the

service provider’s network to accurately transport the service clock that is most important. Therefore, the operation

of the CES interworking function is key to transport timing.

For the CES interworking function (SDIWF

) must use timing that is consistent with the IWF type.

The TSP synchronization domain (SDTDM

) provides a foundation for the CE IWF. PRS traceable timing may be

available via externally timing the TSP/IWF or line timing (from the MEN). It should be noted that the use of

synchronization messaging (SSM) between the MEN and TSP/IWF is required to always ensure that the TSP/IWF is

receiving PRS traceable timing. SSMs facilitate fault or protection switching from upstream failures. If SSMs are

not available, then external timing is the preferred timing mode for PRS traceable timing.

7.3.4.2 Multi Service-Provider Owned Network

Synchronization administration for a multi service-provider owned network is illustrated in Figure 15.

Servicesync trailTransportsync trailSDCECE1PSTNSDTDMProvider - ATransport TimingProvider - BTransport TimingSDIWFSDTDMIWFTSPMENSDEDProvider - CTransport TimingSDIWFSDTDMIWFTSPSDCECE2Service Timing

Figure 15: Synchronization Administration for a Multi Service-Provider Network

A summary of available timing options for a multi service-provider owned network is presented on Table 9.

MEF 3

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 31 of 65

Device Timing

Domain

SDCE

Timing Options

External

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

Notes

Customer Option: Requires a collocated BITS or SSU to supply a

timing input to the CE. May be used as a source for the

synchronization trail.

Customer Option: May be used at the end of a synchronization trail.

Customer Option: May be used as the source for the synchronization

trail.

Service Provider Option: Requires a collocated BITS or SSU to

supply a timing input to the PE.

Customer Option: May be used to recover timing from the received

client signal. This mode should only be used if synchronization

messaging is available (e.g. SONET or SDH line timing sources)..

Service Provider Option: Used only if the connecting TSP equipment

is PRS traceable. This mode should only be used if synchronization

messaging is available (e.g. SONET or SDH line timing sources)

Service Provider Option: Used only if there is no suitable line or

external timing source.

Service Provider Option: Timing recovery for CES IWF must match

the IWF type. Details can be found in the IA as specified on Table 2

(CES Interface Definition).

Service Provider Option: Requires a collocated BITS or SSU to

supply a timing input to the PE.

Customer Option: May be used to recover timing from the received

client signal. This mode should only be used if synchronization

messaging is available (e.g. SONET or SDH line timing sources).

Service Provider Option: Used only if the connecting PSTN

equipment is PRS traceable. This mode should only be used if

synchronization messaging is available (e.g. SONET or SDH line

timing sources)

Service Provider Option: Used if the IWF can provide timing.

Consistent with the service needs of the TSP. Options and capabilities

for a specific IWF is specified per the appropriate IA.

Service Provider Option: Used only if there is no suitable line or

external timing source.

Service Provider Option: Requires that all elements use PRS

traceable timing

Service Provider Option: Requires that one or more elements not use

PRS traceable timing.

Line

Free-Run

PSTN SDTDM

External

Line – CE

Line-TSP

Free-Run

IWF SDIWF

See IA

TSP SDTDM External

Line – CE

Line – PSTN

Line-MEN

Free-Run

MEN SDED

PRS Traceable

Non-PRS

Traceable

Table 9: Timing Options Multi-Service Provider Owned Network

Note that in the Multi-Service Provider configuration, the synchronization trails for service-timing and transport-timing are separate. Also notice that the transport timing can be TDM based (PSTN) or Ethernet based (MEN).

Separation of these synchronization trails is typically done for administrative and liability reasons. An end customer

will not be able to manage a service provider’s timing equipment. Likewise, a service provider would typically not

use timing from a CE due to the reliability and liability issues associated with a single point of failure.

MEF 3

shall contain the following statement: "Reproduced with permission of the Metro Ethernet Forum."

No user of this document is authorized to modify any of the information contained herein.

Page 32 of 65

Circuit Emulation Service Definitions, Framework and

Requirements in Metro Ethernet Networks

Separate synchronization trails also means that the physical timing source used to derive the service clock is not the

same as that used in the transport network (TSP/IWF and MEN). This is not to say that the source for the service

and transport cannot be PRS traceable, simply that one is not the source for the other.

7.3.4.2.1 Service Timing – Multi Service Provider Network

The Customer Edge synchronization domain (SDCE) is owned and maintained by the customer. Timing for the CE

(SDCE) requires that at least one CE be the source of timing. Referring to Table 6, any of the 6 options listed can be