Technical Specification

MEF 18

Abstract Test Suite for Circuit Emulation

Services over Ethernet based on MEF 8

May 2007

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 1
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

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
(c) any form of relationship between any MEF member companies and the recipient or user of this
document.
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.
© The Metro Ethernet Forum 2007. All Rights Reserved.

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 2
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

Table of Contents
1. ABSTRACT ......................................................................................................................................................... 5

2. TERMINOLOGY ................................................................................................................................................ 5

3. SCOPE .................................................................................................................................................................. 5

4. COMPLIANCE LEVELS ................................................................................................................................... 5

5. TESTING FRAMEWORK ................................................................................................................................. 6

5.1 MEF 8 CONFORMANCE .................................................................................................................................... 6
5.2 GENERIC TEST BEDS ........................................................................................................................................ 7
5.2.1 Test Bed 1 .............................................................................................................................................. 7
5.2.2 Test Bed 2 .............................................................................................................................................. 8

6. TESTS FOR MANDATORY REQUIREMENTS ............................................................................................ 9

6.1 ENCAPSULATION LAYERS ................................................................................................................................ 9
6.1.1 Emulated Circuit Identifier and Frame Sequencing .............................................................................. 9
6.1.2 CESoETH control word ....................................................................................................................... 10
6.2 PAYLOAD FORMAT......................................................................................................................................... 13
6.2.1 Structure Agnostic Emulation .............................................................................................................. 13
6.3 SYNCHRONISATION ........................................................................................................................................ 15
6.4 DEFECTS, PERFORMANCE MONITORING AND MANAGEMENT......................................................................... 17
6.4.1 Misconnection ...................................................................................................................................... 17
6.4.2 Late Arriving Frames........................................................................................................................... 21
6.4.3 Jitter Buffer Overrun and Underrun Defects ....................................................................................... 21

7. TESTS FOR DEPENDENT REQUIREMENTS ............................................................................................ 24

7.1 TESTS FOR OCTET ALIGNED PAYLOAD OF DS1 CIRCUITS .............................................................................. 25
7.2 TESTS FOR STRUCTURE-LOCKED ENCAPSULATION ........................................................................................ 26
7.3 TESTS FOR STRUCTURE-INDICATED ENCAPSULATION .................................................................................... 28
7.4 TDM APPLICATION SIGNALING ..................................................................................................................... 29
7.4.1 CE Signaling Frames ........................................................................................................................... 29
7.4.2 Channel associated Signaling (CAS) Frames ...................................................................................... 30

8. TESTING SUMMARY ..................................................................................................................................... 32

9. REFERENCES .................................................................................................................................................. 35

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 3
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

List of Figures
Figure 5-1: MEF8 Operating Modes .............................................................................................................................6
Figure 5-2: Generic Test Bed 1 .....................................................................................................................................7
Figure 5-3: Generic Test Bed 2 .....................................................................................................................................8

List of Tables
Table 2-1: Terms and Abbreviations .............................................................................................................................5
Table 8-1: Requirement Status and Test Summary ..................................................................................................... 35

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 4
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

1. Abstract
This document describes a set of test procedures for evaluating the conformance of equipment for delivering Circuit
Emulation Services over Ethernet (CESoETH) to the MEF 8 Implementation Agreement.

2. Terminology
This document uses the terms defined in MEF8, plus the following additional terms:

Term Definition
DUT Device Under Test
MRTIE Maximum Relative Time Interval Error
PRBS Pseudo-Random Binary Sequence

Table 2-1: Terms and Abbreviations

3. Scope
The scope of this document is limited to the description of testing procedures for pass/fail assessment of
conformance with each of the operating modes in MEF 8. Conformance with MEF 8 should be viewed as a pre-
requisite for any interoperability testing. This document does not cover either interoperability tests or performance
evaluation.

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 used in upper case, bold text.
The following convention is used to identify tests:
<doc reference>.Rn-Rp (e.g. MEF8.R1-R3) Test covers all requirements from Rn to Rp inclusive
<doc reference>.Rn,Rp (e.g. MEF8.R1,R3) Test covers only the requirements Rn and Rp, not those in-between

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 5
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

5. Testing Framework
5.1 MEF 8 CONFORMANCE
MEF 8 describes several operating modes for the implementation of CESoETH. Figure 5-1 shows these modes
using a tree diagram (section numbers given are from MEF 8). Only one mode is mandatory to claim conformance
with MEF 8, structure-agnostic emulation using a raw (i.e. non-octet-aligned) encapsulation. Several optional
operating modes are described in MEF 8, e.g. structure-aware emulation modes, and different signaling types.
Within each operating mode, a number of requirements are defined. Some of these requirements are mandatory (as
indicated by the key words “MUST” or “SHALL”), and some are optional (as indicated by the key words
“SHOULD”, “MAY” or “OPTIONAL”). There are three categories of requirements for MEF8 compliance:
· Mandatory – the mandatory requirements for the mandatory structure-agnostic emulation mode. These
requirements must be met to claim MEF 8 conformance.
· Dependent – the mandatory requirements for the optional modes. These requirements must be met to claim
MEF 8 conformance for those optional modes (i.e. their status is dependent on whether the
relevant operating mode is supported).
· Optional – these requirements describe permitted options. These requirements do not have to be met to
claim MEF 8 conformance.
Table 8-1 in section 8 lists each of the MEF 8 requirements, together with its category and the reference of the test
used to verify it. This specification defines tests for all the mandatory requirements in section 6, and dependent
requirements in section 7.

Emulation Encapsulation Application

Type Type Signaling

Raw encapsulation Sole mandatory mode

(section 6.3.1) in MEF8
Structure-agnostic
Octet-aligned
(section 6.3.1.1)
Mandatory for
Basic service structure-locked
MEF8 encapsulation mode
Basic service with
Structure-locked
(section 6.3.2) separate signaling
(section 6.5)

Embedded CAS
Structure-aware Mandatory for
Basic service structure-indicated
encapsulation mode
Basic service with
Structure-indicated
(section 6.3.3) separate signaling
(section 6.5)

Section numbers relate to MEF8 Embedded CAS

Figure 5-1: MEF8 Operating Modes

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 6
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

5.2 GENERIC TEST BEDS

The majority of tests will use one of the two following generic test beds. Some tests will require extra facilities, and
these are described alongside the relevant tests. Note that the device under test may be provided by multiple pieces
of equipment, provided the necessary functions and interfaces are provided.

5.2.1 Test Bed 1

The first generic test bed consists of equipment for generating and receiving TDM services (e.g. DS1, E1, DS3 or E3
circuits), the device under test, equipment for examining the content of Ethernet frames, and equipment for
generating Ethernet frames with specific contents. The device under test is controlled by a management station.
This is connected to the device via a management interface. The nature of this interface will be specific to the
device under test.

Figure 5-2: Generic Test Bed 1

The generic test procedure will be to set up the device under test and the test equipment, then either:
a. Generate a TDM circuit using the TDM generator, and apply to the device under test. Examine the contents of
the resulting Ethernet frames containing the TDM data using the Ethernet frame analyser. Verify that the
format and contents are correct.
If relevant to the particular test, use the management station to verify that the correct alarms have been reported,
and that the statistics recorded are correct.
b. Generate a stream of Ethernet frames using the frame generator, and apply to the device under test. Examine
the resulting TDM stream using the TDM analyzer. Verify that the format and contents are correct.
If relevant to the particular test, use the management station to verify that the correct alarms have been reported,
and that the statistics recorded are correct.

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 7
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

5.2.2 Test Bed 2

The second generic test bed consists of equipment for generating and receiving TDM services (e.g. DS1, E1, DS3 or
E3 circuits), two identical devices to be tested, and equipment representing an Ethernet network. The devices under
test are controlled by a management station, connected via a management interface. The nature of this interface will
be specific to the device under test.

Mgmt.
Station

Mgmt. Mgmt.
Interface Interface

TDM Eth Eth TDM

TDM CESoETH Emulated CESoETH TDM
Tester DUT Network DUT Tester

Includes “sniffing” capability for monitoring

the contents of CESoETH frames

TDM testers may be the same physical device to

facilitate ceratin measurements (e.g. end-to-end latency)

Figure 5-3: Generic Test Bed 2

The generic test procedure will be to set up the devices under test and the test equipment, and then generate a TDM
circuit using the TDM generator, and apply to the first device under test. Ethernet frames generated by this device
are passed through the emulated network to the second device under test. This recreates the TDM stream, which is
passed to a TDM tester for analysis. In practice, the two TDM testers shown may actually be the same device,
facilitating error checking of the data or measurements such as end-to-end TDM latency.
Note that the function and nature of the emulated network may vary according to the test being conducted. For
example, in test case 6 it takes the form of an actual network of Ethernet switches (as described in Appendix VI of
G.8261). In many of the tests, the emulated network simply needs to have the capability to act as an Ethernet
“sniffer”, monitoring the contents of the stream of Ethernet frames flowing between the two DUTs without
modifying or impairing the stream. Lastly, some tests also require the ability to impair the stream in the following
ways, and these tests may require a “network emulator” box:
· Delay frames by a variable amount
· Delete frames
· Re-order frames
· Duplicate frames
· Insert spurious frames
· Insert data errors
The descriptions of each test describe how the emulated network should be configured and behave for the correct
operation of the test.

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 8
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

6. Tests for Mandatory Requirements

6.1 ENCAPSULATION LAYERS
This section describes the testing of the encapsulation layers, as described in MEF 8, Section 6.2. It covers
requirements R1 to R29.

6.1.1 Emulated Circuit Identifier and Frame Sequencing

ABSTRACT TEST CASES FOR CESoETH IMPLEMENTATION AGREEMENT
Test Name Test Case 1: Emulated Circuit Identifier and Sequencing
Test Definition MEF8.R1,R17-R18
ID
Reference MEF 8
document
Test Type Conformance
Test Status Mandatory
Requirement R1. Each TDM-bound IWF at a given MAC address MUST have a unique ECID value.
Description
R17. The SN field MUST be incremented by one for every CESoETH frame transmitted into
the MEN with the same ECID value, including those frames that are fragments of
multiframe structures.
R18. The initial value of the SN field on setup of an emulated circuit SHALL be random.
Test Object Determine that the attached device operates with a valid ECID attribute and sequencing function.
Test-Bed Generic Test Bed 1, with at least one CESoETH IWF connected at the MEF UNI.
Configuration Each IWF is configured for Structure-Agnostic emulation of E1, DS1, E3 or DS3.
Test Procedure TDM testers generate circuits for emulation by the CESoETH IWFs.
Ethernet Tester monitors the CESoETH service frames at the ingress UNI, and used to verify that
data frames associated with the same CES flow use the same destination MAC address, have the
correct CESoETH Ethertype, have the proper ECID attribute, and that the sequence number
increments correctly every frame.
Where multiple CESoETH IWFs are connected (e.g. in the case of a DUT that is capable of
emulating several TDM circuits simultaneously), the Ethernet tester must also verify that the
number of different ECID's received from the tested CESoETH device is equal to the number of
CESoETH IWFs connected at the MEF UNI.
Each IWF must be torn down and re-established several times, to verify that the initial value of
the sequence number is random.
Units Value of Sequence Number
Variables Multiple CESoETH IWFs per DUT
Results Pass or Fail
Remarks

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 9
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

6.1.2 CESoETH control word

ABSTRACT TEST CASES FOR CESoETH IMPLEMENTATION AGREEMENT
Test Name Test Case 2: ‘R’ bit of the CESoETH Control Word and its Usage
Test Definition MEF8.R4-R7
ID
Reference MEF 8
document
Test Type Conformance
Test Status Mandatory
Requirement R4. A TDM-bound IWF SHALL enter a Loss of Frames State (LOFS) following detection of
Description a locally preconfigured number of consecutive lost (including late frames that are
discarded) CESoETH frames.
R5. A TDM-bound IWF SHALL exit the Loss of Frames State (LOFS) following reception of
a locally preconfigured number of consecutive CESoETH frames.
R6. An MEN-bound IWF SHALL set the ‘R’ bit to 1 on all frames transmitted into the MEN
while its local TDM-bound IWF is in the Loss of Frames State (LOFS). The ‘R’ bit
SHALL be cleared at all other times.
R7. On detection of a change in state of the ‘R’ bit in incoming CESoETH frames, a TDM-
bound IWF MUST report it to the local management entity.
Test Object Verify that the CESoETH IWF device sets the ‘R’ bit to 1 on frames transmitted into the MEN
while its local TDM-bound IWF is in the Loss of Frames State (LOFS). Verify that the
CESoETH IWF device sets the ‘R’ bit to 0 at all other times.
Test-Bed Generic Test Bed 2 as shown in Figure 5-3. Network emulator required.
Configuration Each IWF is configured for Structure-Agnostic emulation of E1, DS1, E3 or DS3.
Test Procedure Valid CESoETH flow set up in both directions between the two CESoETH IWFs (known as the
“left” and “right” IWFs for the purposes of this test). Verify that frames received back from both
IWFs are valid, and contain ‘R’=0.
Network emulator is used to stop traffic flow in the left-to-right direction for a period larger than
the pre-configured number of consecutive frames defined in R4. Verify that the frames received
back from the right-hand IWF have the ‘R’ bit set to 1. Verify that the management station for
the left-hand IWF correctly reports the ‘R’ bit being set in frames received.
Network emulator re-enables the traffic flow in the left-to-right direction for a period larger than
the pre-configured number of consecutive frames defined in R5. Verify that the frames received
back from the DUT now have the ‘R’ bit cleared again. Verify that the management station for
the left-hand IWF correctly reports the ‘R’ bit being cleared again in frames received.
Test repeated using different threshold numbers for R4 and R5, and blocking frames in the right-
to-left direction.
Units N/A
Variables Number of consecutive frames before R flag is set.
Number of consecutive frames before R flag is cleared.
Results Pass or Fail
Remarks

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 10
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

ABSTRACT TEST CASES FOR CESoETH IMPLEMENTATION AGREEMENT

Test Name Test Case 3: ‘L’ bit and ‘M’ bits of the CESoETH Control Word and their Usage
Test Definition MEF8.R8,R10,R14
ID
Reference MEF 8
document
Test Type Conformance
Test Status Mandatory
Requirement R8. For structure-agnostic emulation, an MEN-bound IWF MUST set the ‘L’ bit to one when
Description loss of signal (LOS) is detected on the TDM service interface.
R10. An MEN-bound IWF MUST clear the ‘L’ bit as soon as the defect condition is rectified.
R14. A CES IWF (of either direction) MUST correctly support the conditions described for
which the value of the ‘M’ field equals “00”. Support for any other condition is
OPTIONAL.
Test Object Verify that the CESoETH IWF device sets the ‘L’ bit to 1 and ‘M’ bits to “00”on frames
transmitted into the MEN while LOS is detected on the TDM service interface. Verify that the
CESoETH IWF device sets the ‘L’ bit to 0 at all other times.
Test-Bed Generic Test Bed 1 as shown in Figure 5-2.
Configuration Each IWF is configured for Structure-Agnostic emulation of E1, DS1, E3 or DS3.
Test Procedure TDM tester generates a circuit for emulation by the DUT. Ethernet tester used to verify that the
CESoETH frames generated by the DUT are correctly formed with the L bit and M bits clear.
TDM tester generates LOS on the TDM circuit. Ethernet tester used to verify that the CESoETH
frames generated by the DUT now have the L bit set. The M bits should still be clear.
TDM tester clears LOS fault, and generates a valid circuit again. Ethernet tester used to verify
that the CESoETH frames generated by the DUT now have the L bit cleared again. The M bits
should also still be clear.
Units N/A
Variables LOS condition of TDM circuit.
Results Pass or Fail
Remarks

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 11
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

ABSTRACT TEST CASES FOR CESoETH IMPLEMENTATION AGREEMENT

Test Name Test Case 4: ‘L’ bit and ‘M’ bits of the CESoETH Control Word and their Usage
Test Definition MEF8.R16
ID
Reference MEF 8
document
Test Type Conformance
Test Status Mandatory
Requirement R16. A TDM-bound IWF MUST silently discard a CESoETH frame where the ‘M’ field is set
Description to a value it does not support.
Test Object Verify that the CESoETH device correctly discards frames where the ‘M’ field is set to a value it
doesn’t support..
Test-Bed Generic Test Bed 1 as shown in Figure 5-2.
Configuration Each IWF is configured for Structure-Agnostic emulation of E1, DS1, E3 or DS3.
Test Procedure Ethernet tester generates CESoETH frames with the L and M bits cleared. TDM tester verifies
that the circuit is correctly generated.
Ethernet tester changes the value of the L and M bits to each of the combinations specified in
MEF 8, Table 6-1. For all values other than M=00, the CESoETH frames should be discarded,
and replacement data generated according to MEF 8 R67. Note that this is easier to observe if the
IWF is configured to generate AIS, as in MEF8 R12a and R68a.
Note that RDI is a structure-aware condition, therefore frames with the combination L=0, M=10
should be discarded. Frames containing non-TDM data do not contribute to the TDM output,
therefore frames containing L=0, M=11 should also be discarded.
Units N/A
Variables Values of L and M bits in the CESoETH control word.
Results Pass or Fail
Remarks

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 12
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

6.2 PAYLOAD FORMAT

This section describes the testing of the payload format, as described in MEF 8, Section 6.3. It covers requirements
R30 to R46.

6.2.1 Structure Agnostic Emulation

ABSTRACT TEST CASES FOR CESoETH IMPLEMENTATION AGREEMENT
Test Name Test Case 5: Structure Agnostic Emulation
Test Definition MEF8.R30-R31
ID
Reference MEF 8
document
Test Type Conformance
Test Status Mandatory
Requirement R30. A CES IWF MUST support structure-agnostic emulation, as defined in section 6.3.1 of
Description MEF8. The use of the octet-aligned payload format for DS1, or either of the structure-
aware encapsulation formats is OPTIONAL.
R31. CESoETH implementations MUST support at least the following TDM payload sizes
where the indicated services are offered:
a. E1: 256 octets
b DS1: 192 octets
c. E3: 1024 octets
d. DS3: 1024 octets.
The use of any other TDM payload size is OPTIONAL.
Additional requirements from Y1413:
· The number of octets shall be the same in both directions, and shall remain unchanged for
the lifespan of the connection of the TFM data
Test Object Determine that the attached device operates with structure agnostic emulation using the defined
default payload sizes.
Test-Bed Generic Test Bed 2 as shown in Figure 5-3. Ethernet sniffer required to monitor CESoETH
Configuration frames.
CESoETH IWFs configured to support Structure-Agnostic emulation of E1, DS1, E3 and/or DS3
circuits, with the default payload size as defined in R31.

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 13
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

Test Procedure TDM testers generate framed or unframed TDM circuit for emulation by the CESoETH IWFs.
Circuits to contain a standard 220-1 PRBS pattern 1 (as defined in O.150) to enable data integrity
verification.
Ethernet sniffer is used to monitor the CESoETH service frames flowing in both directions,
allowing verification that data frames contain the correct number of octets as defined in R31 for
both directions, and that the number of octets in payload does not change for the whole test
sequence.
TDM testers check the received PRBS pattern to verify correct payload transport from end-to-end
in both directions. Since this is a “clean” laboratory environment with no impairments applied,
there should be zero bit errors detected over a test lasting between ten and thirty minutes.
Repeat for different circuit types as appropriate for DUTs.
Units Payload size in octets
Bit Error Rate expressed as number of errored bits received/total number of bits received
Variables Type of TDM circuit (framed, unframed, DS1, E1, DS3, E3)
Results Pass or Fail
Remarks

1
The PRBS sequence length was chosen to be much larger than the packet length (2048 bits for a standard E1
circuit, 8192 bits for E3 or DS3). 220-1 is often used for error rate testing in PDH circuits, and is at least 128 times
longer than the longest packet. However it is short enough to allow the test procedure to be carried out in a
reasonable time frame, without waiting too long for the test analyzer to lock onto the sequence.

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 14
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

6.3 SYNCHRONISATION
This section describes the testing of the synchronisation requirements, as described in MEF 8, Section 6.4. It covers
requirements R47 and R48.

ABSTRACT TEST CASES FOR CESoETH IMPLEMENTATION AGREEMENT

Test Name Test Case 6: Synchronization Test
Test Definition MEF8.R47-R48
ID
Reference MEF 8
document
Test Type Conformance
Test Status Mandatory
Requirement R47. The method of synchronization used MUST be such that the TDM-bound IWF meets the
Description traffic interface requirements specified in ITU-T recommendations [G.823] for E1 and E3
circuits, and [G.824] for DS1 and DS3 circuits. 1
R48. Jitter and wander that can be tolerated at the MEN-bound IWF TDM input MUST meet
the traffic interface requirements specified in ITU-T recommendations [G.823] for E1 and
E3 circuits, and [G.824] for DS1 and DS3 circuits.
Test Object Determine that the relevant clock quality standards are met when the device is operated over a
test network.
Test-Bed Uses the test bed described in [G.8261], Appendix VI.2.2 (Figure VI.4), with the CESoETH
Configuration IWFs configured for structure-agnostic emulation of DS1, E1, DS3 or E3 circuits as appropriate.
All tests to be conducted with devices configured in adaptive timing mode.
Use of the incoming TDM clock or an external reference is not tested, since the clock quality
depends entirely on the quality of the supplied clock, not the device action.
Use of a free-run timing is also not tested, since it is not locked to the source, and therefore key
parameters such as MRTIE do not apply.

1
Since MEF8 was introduced in 2004, ITU-T recommendation G.8261 has been released (May 2006), specifying
tighter limits for the network wander allowed in circuit emulated segments of a TDM transmission path. However,
until MEF8 is formally changed, these tighter limits cannot be used for determining compliance with MEF8.

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 15
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

Test Procedure Follow selected test procedures as defined in [G.8261], Appendix VI.2, using Network Traffic
Model 2 only (see section VI.2.2.1.2 of G.8261 - this is closer to the expected traffic mix in a
general Metro Ethernet Network).
For each test, verify that the MRTIE (or MTIE as appropriate) is within G.823/G.824 traffic
interface mask over duration of tests. 1
Test Case 6a: Static Load Test/Sudden Changes in Network Load
Follow Test Case 2 defined in section V1.2.2.3 of G.8261, using Network Traffic Model 2.
Note that this will also cover the “Static Load Test” defined in Test Case 1 (section VI.2.2.2
of G.8261)
Test Case 6b: Slow Variation of Network Load
Follow Test Case 3 defined in section V1.2.2.4 of G.8261, using Network Traffic Model 2.
Test Case 6c: Temporary Network Outages
Follow Test Case 4 defined in section V1.2.2.5 of G.8261, using Network Traffic Model 2,
with network interruptions of 10 and 100s. This test should be repeated 10 times to verify
that the results are consistent.
Test Case 6d: Temporary Congestion
Follow Test Case 5 defined in section V1.2.2.6 of G.8261, using Network Traffic Model 2.
with network congestion periods of 10 and 100s. This test should be repeated 10 times to
verify that the results are consistent.
Test Case 6e: Routing Changes
Follow Test Case 6 defined in section V1.2.2.7 of G.8261, using Network Traffic Model 2.
Test Case 6f: Wander tolerance
Using the same network configuration as the previous tests but with no network load, apply
maximum input jitter and wander, as specified in G.823/G.824 to verify input jitter and
wander tolerance.
A standard 220-1 PRBS pattern (as defined in O.150) should be applied end-to-end during the
wander tolerance test to check data integrity (i.e. slips or bit errors) as stated in G.823/G.824.
Units MTIE measurement in ms. Jitter measurement in ns.
Variables Type of circuit (DS1, E1, DS3 or E3) as supported by DUT.
Results Pass or Fail
Remarks

1
The tests should also verify compliance with the G.8261 masks for completeness, although these limits cannot be
used for determining compliance to MEF8.

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 16
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

6.4 DEFECTS, PERFORMANCE MONITORING AND MANAGEMENT

This section describes the testing of Defect behavior, performance monitoring and management statistics, as
described in MEF 8, Sections 6.6, 6.7 and 9. It covers requirements R57 to R84, R87 and R88.

6.4.1 Misconnection
ABSTRACT TEST CASES FOR CESoETH IMPLEMENTATION AGREEMENT
Test Name Test Case 7: Effect of Stray Frames.
Test Definition MEF8.R57,R60
ID
Reference MEF 8
document
Test Type Conformance
Test Status Mandatory
Requirement R57. The CES IWF MUST only accept frames that contain the correct Ethernet destination
Description address field and ECID value for that IWF.
R60. When a stray frame 1 is detected by a Circuit Emulation Inter-working Function (CES
IWF), it MUST be discarded.
Test Object Verify that only genuine CESoETH frames are accepted by the CES IWF, and that all “stray
frames” are discarded.
Test-Bed Generic Test Bed 2 as shown in Figure 5-3. Network emulator must have the ability to inject stray
Configuration frames into the data stream (it could be replaced by a CESoETH frame generator and L2 switch if
preferred).
Configure the CESoETH IWFs for structure-agnostic emulation of DS1, E1, DS3 or E3 circuits,
and the TDM tester to generate a standard 220-1 PRBS sequence (as defined in O.150).
Test Procedure TDM tester generates a PRBS sequence to verify data integrity throughout the test. Network
emulator injects stray frames into the Ethernet data stream containing a known data pattern (e.g.
all-ones, alternating one/zero, all-zeroes).
If IWF accepts a stray frame, this will cause bit errors in the TDM output which will be detected
by the TDM tester. If no errors are detected in the TDM output, all stray frames must have been
detected and discarded.
If the IWF supports a count of stray frames detected (not a mandatory feature in MEF8), this
should be compared against the number of stray frames generated by the network emulator.
Units Number of stray frames detected,
Bit Error Rate expressed as number of errored bits received/total number of bits received
Variables
Results Pass or Fail.
Remarks

1
A CESoETH frame where the source and/or destination MAC addresses do not agree with the values expected for
that ECID.

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 17
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

ABSTRACT TEST CASES FOR CESoETH IMPLEMENTATION AGREEMENT

Test Name Test Case 8: Verification of lost frame detection in the presence of stray frames
Test Definition MEF8.R63
ID
Reference MEF 8
document
Test Type Conformance
Test Status Mandatory
Requirement R63. The mechanisms for detection of lost frames (e.g. expected next sequence number) MUST
Description NOT be affected by reception of stray frames.
Test Object Verify that the mechanisms for detection of lost frames are not affected by reception of stray
frames.
Test-Bed Generic Test Bed 2 as shown in Figure 5-3. Network emulator must have the ability to corrupt the
Configuration source and destination addresses of Ethernet frames.
Configure the CESoETH IWFs for structure-agnostic emulation of DS1, E1, DS3 or E3 circuits
and the TDM tester to generate a standard 220-1 PRBS sequence (as defined in O.150).
Test Procedure TDM tester generates a circuit for emulation by the DUTs. Network emulator is initially set to
forward the frames with minimal delay and no frame loss. Establish that the circuit is working
correctly with no data loss.
Set network emulator to corrupt the source and destination address of a known number of
individual frames (must take care that the Ethernet FCS is re-calculated, to avoid the corrupted
frame being dropped because of an invalid FCS). This creates a stray frame, but also has the
effect of dropping a frame from the normal sequence in the same place. This is the condition that
R63 of MEF8 is intended to address, where a stray frame could mask detection of a lost frame.
Verify that these corrupted frames are detected and dropped, creating a burst of bit errors in the
TDM data. If the DUT supports a count of lost CESoETH frames, verify that the number of lost
frames is equal to the number of frames corrupted by the network emulator.
Repeat the test, with the network emulator corrupting short bursts of frames (e.g. 2, 3, 10, 30, 50).
Units Number of lost frames detected,
Number of stray frames detected,
Bit Error Rate expressed as number of errored bits received/total number of bits received
Variables
Results Pass or Fail.
Remarks

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 18
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

ABSTRACT TEST CASES FOR CESoETH IMPLEMENTATION AGREEMENT

Test Name Test Case 9: Verification of discarding of out-of-sequence CESoETH frames
Test Definition MEF8.R66
ID
Reference MEF 8
document
Test Type Conformance
Test Status Mandatory
Requirement R66. Out-of-sequence CESoETH frames that cannot be re-ordered MUST be discarded, and
Description considered as lost.
Test Object Verify that CES IWF discards the out-of-sequence frame and recognizes it as being a frame loss.
Test-Bed Generic Test Bed 2 as shown in Figure 5-3. Network emulator must have the ability to delay and
Configuration re-order specific frames.
Configure the CESoETH IWFs for structure-agnostic emulation of DS1, E1, DS3 or E3 circuits
with a known jitter buffer size, and the TDM tester to generate a standard 220-1 PRBS sequence
(as defined in O.150).
Test Procedure TDM tester generates a circuit for emulation by the DUTs. Network emulator is initially set to
forward the frames with minimal delay and no frame loss. Establish that the circuit is working
correctly with no data loss.
Set network emulator to delay individual frames by 1ms greater than the jitter buffer size, forcing
them to be re-ordered because of the delay. All re-ordered frames should now be dropped, as
indicated by bit errors in the TDM data.
Repeat the test, with the network emulator delaying short bursts of frames (e.g. 2, 3, 10).
Units N/A
Variables Delay of CESoETH frames.
Results Pass or Fail.
Remarks

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 19
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

ABSTRACT TEST CASES FOR CESoETH IMPLEMENTATION AGREEMENT

Test Name Test Case 10: Compensation for Lost CESoETH Frames
Test Definition MEF8.R67
ID
Reference MEF 8
document
Test Type Conformance
Test Status Mandatory
Requirement R67. If loss of one or more CESoETH frames is detected by the TDM-bound IWF, it MUST
Description generate exactly one “replacement octet” for every lost octet of TDM data.
Test Object If this requirement was not met, the effect would be a change in latency in the presence of
Ethernet frame loss. Ultimately, this would cause underruns or overruns in the jitter buffer.
Therefore the object of this test is to verify that the latency of the TDM circuit remains constant
in the presence of Ethernet frame loss.
Test-Bed Generic Test Bed 2 as shown in Figure 5-3. Network emulator is required, with the ability to drop
Configuration Ethernet frames.
Configure the CESoETH IWFs for structure-agnostic emulation of DS1, E1, DS3 or E3 circuits,
with externally-supplied timing, such that both IWFs are timed from the same clock.
Configure the TDM tester to measure end-to-end latency of the TDM circuit.
Test Procedure TDM tester generates a circuit for emulation by the DUTs. Network emulator is initially set to
forward the frames with minimal delay and no frame loss. Establish that the circuit is working
correctly, and measure the latency of the TDM circuit from end to end.
Set the network emulator to drop 0.1% of frames. Verify that the end-to-end latency remains
constant (to within a TDM bit period), even in the presence of packet loss.
Increase the percentage of dropped frames to 1%. Verify that the end-to-end latency still remains
constant.
Increase the percentage of dropped frames to 5%. Verify that the end-to-end latency still remains
constant.
Repeat test 10 times to prove that the results are consistent.
Units N/A
Variables % of dropped frames
Results Pass or Fail.
Remarks

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 20
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

6.4.2 Late Arriving Frames

The test for the mandatory requirement "R71. A CESoETH IWF MUST discard frames that arrive too late to be
played out on the TDM interface" has been intentionally omitted from the Abstract Test suite, because of the fact
that some decent implementations of IWF cannot pass tests that validate this requirement.

6.4.3 Jitter Buffer Overrun and Underrun Defects

ABSTRACT TEST CASES FOR CESoETH IMPLEMENTATION AGREEMENT
Test Name Test Case 11: Detection of Jitter Buffer Overruns
Test Definition MEF8.R78-R79
ID
Reference MEF 8
document
Test Type Conformance
Test Status Mandatory
Requirement R78. A CESoETH IWF MUST detect the Jitter Buffer Overrun conditions.
Description
R79. If a CESoETH frame arrives that cannot be stored in the jitter buffer due to a jitter buffer
overrun condition, the TDM-bound IWF MUST discard the frame.
Test Object Verify that a CESoETH IWF detects jitter buffer overruns, and discards the CESoETH frames
accordingly.
Test-Bed Generic Test Bed 1, as shown in Figure 5-2, with the TDM generator replaced by a loopback
Configuration (TDM out connected to TDM in).
Configure the CESoETH IWFs for structure-agnostic emulation of DS1, E1, DS3 or E3 circuits,
with a known maximum jitter buffer size.
Ethernet Frame Generator/Analyzer is required, with the following capabilities:
· to generate valid CES stream
· analyze the received CES stream packets
Note that it may not be possible to provide all these capabilities in a single piece of equipment, so
this may need to be a composed of several separate items, e.g. an Ethernet frame generator, a
network emulator and an Ethernet sniffer.

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 21
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

Test Procedure See Remarks at the bottom of the table for some details/explanations.
Ethernet Frame Generator produces a valid structure-agnostic CES stream with the normal
payload size towards the DUT at a default frames rate. The payload of the CES stream should
contain a predefined pattern (e.g. a 32 bits automatically incremented counter). The DUT will
send back the payload received from the IWF due to the external TDM loopback.
Ethernet Analyzer captures the received data, and verifies that it receives back the payload which
was sent towards the DUT. This will establish that the DUT is working correctly, and that there is
end-to-end transmission with no data loss.
Ethernet Frame Generator should then increase the rate at which CES frames are sent (reduce the
packetization latency) by the factor of N . Ethernet Analyzer shall establish that at some point of
time (after the jitter buffer fills up entirely) the DUT starts to replace the payload of at least
N -1 1
received packets. The DUT may play up to of valid CES frames.
N N
The test shall be continued for a time period of at least 10 seconds.
Repeat the test with different values of N.
Units N/A
Variables N=2, 3, 4, 5
Results Pass or Fail.
Remarks The Jitter Buffer Overrun condition occurs when the jitter buffer at the TDM-bound IWF cannot
accommodate the newly arrived valid CESoETH frame in its entirety, e.g. due to insufficient
storage space. For example, Jitter buffer overruns will happen if (due to delay variations or a
Denial of Service Attack) the frames arrive at a rate higher than the rate at which the frames
played out of the jitter buffer. This condition may be an indication that the jitter buffer is
incorrectly configured, and either needs to be increased in size, or its “operating point” adjusted
to accommodate these earlier packets.
Therefore the procedure used to test the overrun behavior is to send CES frames at a rate higher
than expected by IWF. The normal packetization for structure-agnostic CES (See MEF-8, R31) is
256 octets for E1, 192 octets for T1. Such frames therefore are sent at a rate 1000 per second (the
packetization latency of such CES stream is 1 ms). When testing equipment increases the rate of
CES frames sent to DUT, the jitter buffer can no longer accommodate all received frames and
shall start dropping them.
For example, if the frames arrive at the double of normal rate, the IFW will play the data out of
the jitter buffer at a normal rate, so half of arrived packets shall be dropped. There may be vendor
specific implementations which can try to bring the operating point back to the middle of the jitter
buffer (i.e. recalibrate the jitter buffer). Such implementations may drop more than half of the
arriving frames.

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 22
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

ABSTRACT TEST CASES FOR CESoETH IMPLEMENTATION AGREEMENT

Test Name Test Case 12: Verification of CESoETH implementation rule
Test Definition MEF8.R83
ID
Reference MEF 8
document
Test Type Conformance
Test Status Mandatory
Requirement R83. CESoETH implementations supporting DS1 circuit using ESF framing MUST NOT
Description change messages carried in the FDL (Facility Data Link), or insert new messages.
Test Object Verify that CESoETH implementations do not change the messages carried in the facility data
link which is the functionality in the ESF framing in the DS1 circuit.
Test-Bed Generic Test Bed 2 as shown in Figure 5-3. No network emulator is required, merely a cable
Configuration connecting the two DUTs directly.
Configure the CESoETH IWFs for structure-agnostic emulation of DS1 circuits.
Test Procedure TDM tester generates DS1 signal using ESF framing for emulation by the DUTs. Establish that
the TDM circuit is working correctly, and that there is end-to-end transmission with no data loss.
Configure the TDM tester to transmit specific, known messages in the FDL of the DS1 circuit.
Verify that the messages in the FDL are forwarded correctly with no errors or data loss, and that
no extra messages are inserted.
Units N/A
Variables
Results Pass or Fail.
Remarks

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 23
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

7. Tests for Dependent Requirements

There are several optional modes within MEF8, as indicated in Figure 5-1:
· Octet aligned payload for structure-agnostic emulation of DS1
· Structure-aware emulation using structure-locked formatting
· Structure-aware emulation using structure-indicated formatting
· Separate TDM application signaling
This section describes the tests required to verify these optional modes, should they be implemented.

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 24
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

7.1 TESTS FOR OCTET ALIGNED PAYLOAD OF DS1 CIRCUITS

ABSTRACT TEST CASES FOR CESoETH IMPLEMENTATION AGREEMENT
Test Name Test Case 13: Octet Aligned Payload for Structure Agnostic Emulation of DS1 Circuits
Test Definition MEF8.R32-R33
ID
Reference MEF 8
document
Test Type Conformance
Test Status Dependent (Mandatory for Octet-Aligned Payload support)
Requirement R32. The TDM-bound IWF MUST NOT assume any alignment with the underlying DS1
Description framing structure.
R33. CESoETH implementations supporting octet aligned DS1 MUST support a TDM payload
size of 200 octets (including padding).
Test Object Determine that the attached device operates with octet aligned structure agnostic emulation using
the defined default payload size.
Test-Bed Generic Test Bed 2 as shown in Figure 5-3. Ethernet sniffer required to monitor CESoETH
Configuration frames.
CESoETH IWFs support the Octet-Aligned Payload option for Structure-Agnostic Encapsulation
of DS1 circuits.
Test Procedure TDM testers generate an unframed DS1 circuit to each IWF. Circuits to contain a standard 220-1
PRBS pattern (as defined in O.150) to enable data integrity verification.
Ethernet sniffer is used to monitor the CESoETH service frames flowing in each direction to
verify that:
· Payload size is 200 octets
· Exactly one CESoETH frame is generated for every 193 octets of TDM input
(i.e. exactly one frame generated every 1ms)
TDM testers check the received PRBS pattern to verify correct payload transport from end-to-end
in both directions. Since this is a “clean” laboratory environment with no impairments applied,
there should be zero bit errors detected over a test lasting between ten and thirty minutes.
Test repeated several times using structured patterns with embedded framing information.
Units Payload size in octets
Bit Error Rate expressed as the number of errored bits received/total number of bits received
Variables Framed and unframed patterns.
Results Pass or Fail
Remarks

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 25
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

7.2 TESTS FOR STRUCTURE-LOCKED ENCAPSULATION

ABSTRACT TEST CASES FOR CESoETH IMPLEMENTATION AGREEMENT
Test Name Test Case 14: Structure Aware Emulation using Structure-Locked Encapsulation
Test Definition MEF8.R34-R36,R39
ID
Reference MEF 8
document
Test Type Conformance
Test Status Dependent (Mandatory for Structure-Locked Encapsulation support)
Requirement R34. The timeslots to be placed into the payload need not be contiguous, and the payload may
Description contain any combination of timeslots from the TDM circuit.
R35. The timeslots MUST be placed into the payload in the same order that they occur in the
TDM circuit.
R36. A CESoETH implementation supporting structure-locked encapsulation MUST support
values of N from 1 to 24 (where the TDM circuit is DS1) or from 1 to 31 (where the TDM
circuit is E1).
R39. A CESoETH structure-locked implementation supporting N x 64kbit/s basic service
MUST support the following set of configurable packetization latency values:
a. For N ³ 5: 1 ms (with the corresponding TDM payload size of 8N octets)
b. For 2 £ N £ 4: 4 ms (with the corresponding TDM payload size of 32N octets).
c. For N = 1: 8 ms (with the corresponding TDM payload size of 64N octets).
Test Object Determine that the attached device operates with structure aware emulation using structure
locked encapsulation using a variety of payload configurations.
Test-Bed Generic Test Bed 2 as shown in Figure 5-3. Ethernet sniffer required to monitor CESoETH
Configuration frames.
CESoETH IWFs configured for Structure-Locked Encapsulation of either DS1 or E1.

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 26
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

Test Procedure TDM testers generate framed DS1 or E1 circuits to each IWF with a pattern allowing each
timeslot to be uniquely identified (e.g. contain the timeslot number).
Configure IWF for structure-locked encapsulation of N x 64kbit/s “basic service”. Configure
with different numbers of timeslots in the CESoETH flow, and with default packetization latency
as defined in MEF 8 R39. At least the following numbers of timeslots should be picked:
· 1 timeslot (test for several different positions)
· 2 timeslots (test for several different positions and combinations)
· 4 timeslots (test for several different positions and combinations)
· 5 timeslots (test for several different positions and combinations)
· 24 timeslots (DS1) or 31 timeslots (E1)
· Several values in between, using combinations of contiguous and non-contiguous timeslots
Ethernet sniffer is used to monitor the CESoETH service frames in each direction, and is used to
verify that:
· The correct timeslots appear in the payload
· The timeslots appear in the same order in the Ethernet payload as in the circuit
· The CESoETH frames contain the correct payload length according to R39.
Repeat using the other TDM circuit type if supported by the DUT.
Repeat using a standard 220-1 PRBS pattern (as defined in O.150) in the TDM timeslots, to allow
TDM testers to verify data integrity.
Units N/A
Variables Number of timeslots per frame, timeslot combinations.
Input circuit type.
PRBS pattern or timeslot identification.
Results Pass or Fail.
Remarks

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 27
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

7.3 TESTS FOR STRUCTURE-INDICATED ENCAPSULATION

ABSTRACT TEST CASES FOR CESoETH IMPLEMENTATION AGREEMENT
Test Name Test Case 15: Structure Aware Emulation using Structure-Indicated Encapsulation
Test Definition MEF8.R45
ID
Reference MEF 8
document
Test Type Conformance
Test Status Dependent (Mandatory for Structure-Indicated Encapsulation support)
Requirement R45. All compliant implementations that support structure-indicated encapsulation for DS1 and
Description E1 service MUST support 1 AAL1 PDU per frame, and SHOULD support from 2 to 8
AAL1 PDUs per frame.
Test Object Determine that the attached device operates with structure-indicated encapsulation for DS1 and
E1 service using the defined default payload size, and the recommended payload size range.
Test-Bed Generic Test Bed 2 as shown in Figure 5-3. Ethernet sniffer required to monitor CESoETH
Configuration frames.
CESoETH IWFs configured for Structure-Indicated Encapsulation of either DS1 or E1.
Test Procedure TDM testers generate framed DS1 or E1 circuits to each IWF with a pattern allowing each
timeslot to be uniquely identified (e.g. contain the timeslot number).
Configure IWF for structure-indicated encapsulation of N x 64kbit/s “basic service”. Configure
with different numbers of timeslots in the CESoETH flow, and with one AAL1 PDU per
CESoETH frame, as defined in MEF 8 R45. At least the following numbers of timeslots should
be picked:
· 1 timeslot (test for several different positions)
· 24 timeslots (DS1) or 31 timeslots (E1)
· Several values in between, using combinations of contiguous and non-contiguous timeslots
Ethernet sniffer is used to monitor the CESoETH service frames in each direction, and is used to
verify that
· The correct timeslots appear in the payload
· The CESoETH frames contain exactly one AAL1 PDU
Repeat using the other TDM circuit type if supported by the DUT.
Repeat using a standard 220-1 PRBS pattern (as defined in O.150) in the TDM timeslots, to allow
TDM testers to verify data integrity.
Units N/A
Variables Number of timeslots per frame, timeslot combinations.
Input circuit type.
PRBS pattern or timeslot identification.
Results Pass or Fail
Remarks

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 28
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

7.4 TDM APPLICATION SIGNALING

This section describes the testing of TDM Application Signaling, as described in MEF 8, Section 6.5. It covers
requirements R49 to R56.

7.4.1 CE Signaling Frames

ABSTRACT TEST CASES FOR CESoETH IMPLEMENTATION AGREEMENT
Test Name Test Case 16: Signaling Frame Format Requirements
Test Definition MEF 8.R49-R51
ID
Reference MEF 8
document
Test Type Conformance
Test Status Dependent (Mandatory for TDM Application Signaling support)
Requirement R49. CESoETH data frames and their associated signaling frames MUST have the same:
Description
a. Destination MAC address
b. Ethertype
c. Usage of the RTP header (i.e. either both use it or both do not use it)
R50. CESoETH data frames and their associated signaling frames MUST use different ECID
Values.
R51. CESoETH data frames and their associated signaling frames MUST use a separate
sequence number space.
Test Object Determine that signaling frames use the correct format related to the flow of CES data frames.
Test-Bed Generic Test Bed 1 as shown in Figure 5-2. TDM Tester must be capable of generating CAS
Configuration signaling events.
Test Procedure TDM Tester sets up a framed TDM circuit, and generates CAS signaling events at frequent
intervals. CESoETH IWF is configured for structure-aware operation with generic TDM
application signaling as described in MEF8 section 6.5.
Ethernet Tester monitors the CESoETH service frames and verifies that both signaling and data
frames associated with the same CES flow:
· use the same destination MAC address
· have the proper CESoETH Ethertype
· use different ECID values
· use different sequence number spaces
Units N/A
Variables None
Results Pass or Fail
Remarks

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 29
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

7.4.2 Channel associated Signaling (CAS) Frames

ABSTRACT TEST CASES FOR CESoETH IMPLEMENTATION AGREEMENT
Test Name Test Case 17: CAS Signaling Frame Format Requirements
Test Definition MEF 8.R53-R55
ID
Reference MEF 8
document
Test Type Conformance
Test Status Dependent (Mandatory for TDM Application Signaling support)
Requirement R53. The payload of each signaling frame MUST comprise N 32-bit words (where N is the
Description number of timeslots in the service).
R54. The i-th word of the payload MUST contain the current “ABCD” value of the CAS signal
corresponding to the i-th timeslot, and MUST be encoded in accordance with RFC 2833,
section 3.14, table 6 (see figure below):
0 7 8 9 10 15 16 31

Event code (8 bits) E R Volume (6 bits) Duration (16 bits)

ABCD signaling value not required – set to zero

(codes 144-159)

R55. Signaling frames MUST be sent three times at an interval of 5ms on any of the following
events:
a. Setup of the emulated circuit
b. A change in the signaling state of the emulated circuit.
c. Loss of Frames defect has been cleared
d. Remote loss of Frames indication has been cleared
Test Object Determine that a correct number of 32-bit words is forming the CAS Signaling frames, according
to the number of time-slots associated with the TDM-CAS flow.
Test-Bed Generic Test bed 1 as shown in Figure 5-2. TDM Tester must be capable of generating CAS
Configuration signaling events.

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 30
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

Test Procedure TDM Tester sets up a framed TDM circuit, and generates CAS signaling events at frequent
intervals. CESoETH IWF is configured for structure-aware operation with generic TDM
application signaling as described in MEF8 section 6.5.
Ethernet Testers monitors the CESoETH service frames generated by the DUT, and generates a
flow of CESoETH frames back to the and verifies that the CAS Signaling frames, associated
with the same CES flow:
· consists of exactly N 32-bit words, where N stands for the number of timeslots in the
associated CESoETH service.
· contains the correct ABCD code for the CAS signaling change just generated
· are sent three times on each of the events listed in R55
Test repeated several times with different signaling events on different timeslots. Also repeated
with different values of N in the emulated circuit.
Units Number of valid frames
Variables Timeslots used for signaling events
Type of signaling event
Number of timeslots in emulated circuit (value of N)
Results Pass or Fail
Remarks

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 31
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

8. Testing Summary
Level
Test
(mandatory/
Requirement Description Case Test reference Comments
dependent/
No.
optional)

MEF8.R1 ECID attribute Mandatory 1 MEF8.R1,R17-R18

ECID reserved field –
MEF8.R2 Optional None
transmit
ECID reserved field –
MEF8.R3 Optional None
reception
MEF8.R4 LOF State entry Mandatory 2 MEF8.R4-R7
MEF8.R5 LOF State exit Mandatory 2 MEF8.R4-R7
MEF8.R6 R bit setting conditions Mandatory 2 MEF8.R4-R7
R bit change of state
MEF8.R7 Mandatory 2 MEF8.R4-R7
detection
MEF8.R8 L bit setting conditions Mandatory 3 MEF8.R8,R10,R14
MEF8.R9 L bit setting conditions Optional None
MEF8.R10 L bit clearing conditions Mandatory 3 MEF8.R8,R10,R14
L bit payload
MEF8.R11 Optional None
suppression
MEF8.R12 L bit reception actions Optional None
MEF8.R13 L bit reception actions Optional None
MEF8.R14 M field support Mandatory 3 MEF8.R8,R10,R14
Depends on DUT
MEF8.R15 M field support Optional None
capability
MEF8.R16 M field reception Mandatory 4 MEF8.R16
MEF8.R17 Sequencing Mandatory 1 MEF8.R1,R17-R18
MEF8.R18 Sequencing Mandatory 1 MEF8.R1,R17-R18
MEF8.R19 RTP support Optional None
MEF8.R20 RTP support Optional None
MEF8.R21 RTP support Optional None
MEF8.R22 RTP support Optional None
MEF8.R23 RTP support Optional None
MEF8.R24 RTP support Optional None
MEF8.R25 RTP support Optional None
MEF8.R26 RTP support Optional None

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 32
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

Level
Test
(mandatory/
Requirement Description Case Test reference Comments
dependent/
No.
optional)

MEF8.R27 RTP support Optional None

MEF8.R28 RTP support Optional None
MEF8.R29 RTP support Optional None
MEF8.R30 Payload format Mandatory 5 MEF8.R30-R31
Default structure-
MEF8.R31 Mandatory 5 MEF8.R30-R31
agnostic payload sizes
MEF8.R32 Octet-aligned framing Dependent 13 MEF8.R32-R33 Mandatory if being
tested for compliance
MEF8.R33 Octet-aligned framing Dependent 13 MEF8.R32-R33 with octet-aligned
payload
Structure-locked
MEF8.R34 Dependent 14 MEF8.R34-R36,R39
encapsulation
Mandatory if being
Structure-locked tested for compliance
MEF8.R35 Dependent 14 MEF8.R34-R36,R39
encapsulation with structure-locked
encapsulation
Structure-locked
MEF8.R36 Dependent 14 MEF8.R34-R36,R39
encapsulation
Structure-locked
MEF8.R37 Optional None
encapsulation
Structure-locked
MEF8.R38 Optional None
encapsulation
Structure-locked
MEF8.R39 Dependent 14 MEF8.R34-R36,R39
encapsulation
Structure-locked with
MEF8.R40 Optional None
CAS
Structure-locked with
MEF8.R41 Optional None
CAS Support for trunk-
specific CAS
Structure-locked with
MEF8.R42 Optional None signaling is optional
CAS
with structure-locked
Structure-locked with encapsulation.
MEF8.R43 Optional None
CAS
Structure-locked with
MEF8.R44 Optional None
CAS
Structure-indicated
MEF8.R45 Dependent 15 MEF8.R45
encap.
Structure-indicated
MEF8.R46 Optional None
encap.
MEF8.R47 Synchronization Mandatory 6a-e MEF8.R47-R48
MEF8.R48 Synchronization Mandatory 6f MEF8.R47-R48

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 33
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

Level
Test
(mandatory/
Requirement Description Case Test reference Comments
dependent/
No.
optional)

MEF8.R49 Generic TDM Signaling Dependent 16 MEF8.R49-R51

MEF8.R50 Generic TDM Signaling Dependent 16 MEF8.R49-R51 Generic TDM
Signaling is an
MEF8.R51 Generic TDM Signaling Dependent 16 MEF8.R49-R51
optional means of
MEF8.R52 Generic TDM Signaling Optional None carrying signaling
(e.g. CAS) for
MEF8.R53 Generic TDM Signaling Dependent 17 MEF8.R53-R55
structure-aware
MEF8.R54 Generic TDM Signaling Dependent 17 MEF8.R53-R55 operation.
MEF8.R55 Generic TDM Signaling Dependent 17 MEF8.R53-R55
MEF8.R56 Generic TDM Signaling Optional None
MEF8.R57 Misconnection Defect Mandatory 7 MEF8.R57,R60
MEF8.R58 Misconnection Defect Optional None
MEF8.R59 Misconnection Defect Optional None
MEF8.R60 Misconnection Defect Mandatory 7 MEF8.R57,R60
MEF8.R61 Misconnection Alarm Optional None
MEF8.R62 Misconnection Alarm Optional None
MEF8.R63 Lost frame detection Mandatory 8 MEF8.R63
MEF8.R64 Re-ordering Optional None
MEF8.R65 Re-ordering Optional None
MEF8.R66 Re-ordering Mandatory 9 MEF8.R66
MEF8.R67 Replacement data Mandatory 10 MEF8.R67
MEF8.R68 Replacement data Optional None
MEF8.R69 Frame Loss Alarm Optional None
MEF8.R70 Frame Loss Alarm Optional None
MEF8.R71 Late Frames Mandatory None See 6.4.2
MEF8.R72 Late Frames Alarm Optional None
MEF8.R73 Late Frames Alarm Optional None
MEF8.R74 Malformed Frames Optional None
MEF8.R75 Malformed Frames Optional None
Malformed Frames
MEF8.R76 Optional None
Alarm
Malformed Frames
MEF8.R77 Optional None
Alarm
MEF8.R78 Jitter Buffer Overrun Mandatory 11 MEF8.R78-R79

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 34
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.
 Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8

Level
Test
(mandatory/
Requirement Description Case Test reference Comments
dependent/
No.
optional)

MEF8.R79 Jitter Buffer Overrun Mandatory 11 MEF8.R78-R79

MEF8.R80 Jitter Buffer Overrun Optional None
MEF8.R81 Jitter Buffer Overrun Optional None
MEF8.R82 Facility Data Link Optional None
MEF8.R83 Facility Data Link Mandatory 12 MEF8.R83
MEF8.R84 Frame Error Ratio Optional None
Requirement on
MEF8.R85 Bandwidth provisioning Optional None
MEN
MEF8.R86 MEN Specification Optional None
MEF8.R87 MEN-bound Statistics Optional None
MEF8.R88 TDM-bound Statistics Optional None

Table 8-1: Requirement Status and Test Summary

9. References
Reference Reference Details
RFC 2119 “Key words for use in RFCs to Indicate Requirement Levels”, RFC 2119, S. Bradner,
March 1997, http://www.ietf.org/rfc/rfc2119.txt
RFC 2833 “RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals”, RFC
2833, H. Schulzrinne, S. Petrack, 2000, http://www.ietf.org/rfc/rfc2833.txt
MEF 3 “Circuit Emulation Service Definitions, Framework and Requirements in Metro
Ethernet Networks”, MEF 3, April 13, 2004,
http://www.metroethernetforum.org/PDFs/Standards/MEF3.pdf
MEF 8 “Implementation Agreement for the Emulation of PDH Circuits over Metro Ethernet
Networks”, MEF 8, October 2004,
http://www.metroethernetforum.org/PDFs/Standards/MEF8.pdf
G.823 “The control of jitter and wander within digital networks which are based on the 2048
kbit/s hierarchy”, ITU-T recommendation G.823, March 2000
G.824 “The control of jitter and wander within digital networks which are based on the 1544
kbit/s hierarchy”, ITU-T recommendation G.823, March 2000
G.8261 “Timing and Synchronisation aspects in Packet Networks”, ITU-T recommendation
G.8261, June 2006
O.150 “General Requirements for Instrumentation for Performance Measurements on Digital
Transmission Equipment”, ITU-T recommendation O.150, May 1996

MEF 18 © The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 35
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.