Sunteți pe pagina 1din 1058

Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Fundamentals Carrier Ethernet Carrier Ethernet Key Attributes


of Services over Services over Components of
Carrier Ethernet Transport Access of Carrier Ethernet
Technologies Technologies Carrier Ethernet Services

MEF Certification Typical Target Positioning of Synchronization Carrier Ethernet


of Applications for Carrier Ethernet over Service OAM
Carrier Ethernet Carrier Ethernet with other Carrier Ethernet &
Services Services Technologies Circuit Emulation

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

Ethernet Academy Metro Ethernet Forum


More and more


Carrier Ethernet Professionals are turning
to the MEF for information on the latest in
Carrier Ethernet standards development
and terminology. These professionals are
highly mobile and networked for their
work, so we at the MEF want to make our
materials as easy to access and review as
possible for professionals on the go!

Welcome to MEF on the Go!


Topics:
The MEF on the Go is designed to make your educational experience
MEF-CECP Study Guide
straight forward and simple. Start by downloading MEF reference Access the MEF-CECP Study
materials. Once you are familiar with the MEF reference material Guide
schedule your exam. Exams may be taken online in the convenience of
your home or office, at a testing center, or a special venue arranged by
MEF-CECP Exam Objectives
the MEF such as MEF Quarterly Meetings or events.
View and download MEF
reference documents for free

MEF-CECPs
View the current listing
of certified MEF-CECPs

Choose where to study


Training from one of our
Accredited Training Partners
(MEF-ATPs)

Schedule an exam
Schedule your exam to take it
For more information on the MEF Professional Certification program online, or at a testing center.
click here.

If you have questions regarding the MEF specifications, you should join
the experts at the Ethernet Academy and participate in the Forums and
Discussion Groups.

Contact Us
Copyright 2011-2012 Metro Ethernet Forum Copyright 2011-2012 Ethernet Academy

Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Fundamentals of Carrier Ethernet In this Section

1 Fundamentals of Carrier Ethernet


Study Guide Section 1
1.1 Carrier Ethernet and LAN
Introduction Ethernet

1.2 Carrier Ethernet Service Types


This first section in the MEF-CECP Study Guide describes the differences
between the familiar Ethernet LAN that has been in use for over 30 years and 1.3 Virtual Service and Private
Service
Carrier Ethernet as defined by the MEF over the last 10 years.

The fundamental concepts of Carrier Ethernet, Carrier Ethernet services and Download PDF
services types (E-Line, E-LAN and E-Tree) are introduced as well as the
concepts of private and virtual Carrier Ethernet services.
Download a pdf for
offline viewing.

Reference Documents

MEF 6.1

MEF-CECP Test Objectives

1 Services Definitions

Send Feedback

Name:

Email:
Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Services over Transport In this Section


Technologies 2 Carrier Ethernet Services over
Transport Technologies
Study Guide Section 2 2.1 Transport Technologies

Carrier Ethernet services are designed to be delivered over all deployed 2.1.1 IEEE-based transport
technologies
transport infrastructures. This section explains the capabilities and relative
advantages of each transport technology in order to deploy a given Carrier 2.1.1.1 Bridging

Ethernet service in the most effective way possible. 2.1.1.2 Provider Bridging (PB)

2.1.1.3 Provider Backbone


This section also explains about use of resilience and protection mechanisms Bridging (PBB)
within the underlying transport technology to maximize the resiliency of the
2.1.1.4 Provider Backbone
Carrier Ethernet service running over that technology. Bridging - Traffic Engineering
(PBB-TE)
This material is not intended to promote a given transport technology since
the MEF defines Carrier Ethernet services without reference to a particular 2.1.2 MPLS based
standard or technology for the underlying transport. 2.1.2.1 VPWS

2.1.2.2 VPLS

2.1.2.3 MPLS-TP

2.1.3 Transparent Transport

2.1.3.1 SONET/SDH

2.1.3.2 OTN

2.1.3.3 WDM

2.2 Protection and Resiliency

Download PDF
Download a pdf for
offline viewing.

Reference Documents

IEEE 802.1Q-2009

IEEE 802.1ad-2005

IEEE 802.1ah

IEEE 802.1Qay

ITU-T G.8031

ITU-T G.8032

ITU-T Y.1415

RFC 4448

RFC 4761

RFC 5921

RFC 5960

MEF-CECP Test Objectives

2 Transporting Carrier Ethernet


Services

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Services over Access In this Section


Technologies 3 Carrier Ethernet Services over
Access Technologies
Study Guide Section 3 3.1 Access Infrastructures

A key benefit of Carrier Ethernet is its ability to provide consistent, cost- 3.1.1 HFC (DOCSIS)
efficient, high-performance services delivered to users who are connected 3.1.2 PON
over the widest variety of access networks in any location. 3.1.3 Packet Radio

All the access infrastructures described in this section have significant 3.1.4 PDH

advantages depending on the range, bandwidth requirements, infrastructure 3.1.5 Fiber


availability and other capabilities required for delivery of the E-Line, E-LAN, 3.1.6 Bonded Copper
E-Tree or E-Access service. In fact, in many instances, Service Providers will
3.2 Comparisons
use a combination of several access technologies to their Subscriber's various
3.3 Examples
sites in order to complete the solution for the customer.

This section highlights the relative capabilities of each access technology so Download PDF
that both Subscribers and Service Providers can understand better how to
request and implement Carrier Ethernet services.
Download a pdf for
offline viewing.

Reference Documents

MEF Reference Presentation: Access


Technologies

MEF White Paper: Access


Technologies

IEEE 802.3
IEEE 802.16

MEF-CECP Test Objectives

3 Carrier Ethernet Access


Technologies

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Key Components of Carrier Ethernet In this Section

4 Key Components of Carrier


Study Guide Section 4 Ethernet

This section describes the basic constructs and definitions of Ethernet services 4.1 Subscribers, Service Providers
and Operators
including the following:
4.2 EVC, OVC, UNI, ENNI and CEN
Subscriber (MEN)
Service Provider 4.3 Service Models
Operator
Carrier Ethernet Network (CEN) Download PDF
User Network Interface (UNI)
External Network to Network Interface (ENNI)
Ethernet Virtual Circuit (EVC) Download a pdf for
Operator Virtual Circuit (OVC) offline viewing.

Reference Documents

MEF 10.2

MEF 13

MEF 26.1

MEF-CECP Test Objectives

4 Components of Carrier Ethernet

Send Feedback

Name:
Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Attributes of Carrier Ethernet Services In this Section

5 Attributes of Carrier Ethernet


Study Guide Section 5 Services

The Carrier Ethernet Service Definition Framework provides a model for 5.1
specifying Carrier Ethernet services. Carrier Ethernet Service types are generic 5.2 UNI Attributes
constructs used to create a broad range of services. Each Carrier Ethernet 5.3 EVC per UNI Attributes
service type has a set of Carrier Ethernet service attributes that define the
5.4 EVC Attributes
service characteristics. These Ethernet Service Attributes in turn have a set of
parameters associated with them that provide various options for the 5.4.1 L2CP per MEF 6.1.1

different service attributes as shown in the following figure: 5.5 ENNI Attributes

5.6 OVC Attributes

5.6.1 Hairpin switching

5.7 OVC End Point per ENNI


Attributes

5.8 Bandwidth Profiles

5.9
Figure 5.F1 - Type-Attribute-Attribute Parameter
[Source: MEF 6.1, figure 1] 5.10 EVC Performance Attributes

MEF 6.1 defines three Ethernet Service type generic constructs:


Download PDF
Ethernet Line (E-Line) Service type
Ethernet LAN (E-LAN) Service type
Ethernet Tree (E-Tree) Service type Download a pdf for
offline viewing.
MEF 6.1 also defines the associated service attributes and parameters for each
service type. The key differentiator is the type of connectivity provided, as
indicated by the EVC Type' service attribute. The UNI and EVC service
attributes and parameters are normatively defined in MEF 10.2. Reference Documents
The subsections of this part of the Study Guide describe each attribute type MEF 6.1
and explain how they are used to create the various Carrier Ethernet services. MEF 10.2

MEF 13

MEF 20

MEF 26.1

IEEE 802.1AX

IEEE 802.3 clause 43

MEF-CECP Test Objectives

5 Key UNI, ENNI, OVC, and EVC


Service Attributes

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

MEF Certification of Carrier Ethernet In this Section


Services 6 MEF Certification of Carrier
Ethernet
Study Guide Section 6 6.1 Purpose of Certification

Introduction 6.2 Definitions, IAs, ATSs, Test


Plans
The MEF is the only industry body offering certification of Carrier Ethernet 6.3 Testing and Certification Process
services for service providers and equipment vendors. This certification is
6.4 Certification for SPs
proof that a Carrier Ethernet service, or equipment used to deliver a Carrier
Ethernet service, has been tested successfully for compliance with the 6.5 Certification for Vendors

relevant MEF specifications.


Download PDF
This section describes the:-

Purpose of MEF Certification


Download a pdf for
Development of MEF Technical Specifications, Implementation offline viewing.
Agreements, Abstract Test Suites and from there test plans that are
used in the testing process
Testing and certification process itself
Range of certifications available for Service Providers and Equipment Reference Documents
Vendors

MEF-CECP Test Objectives

6 MEF Certification

Send Feedback

Name:

Email:
Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Typical Target Applications Using Carrier In this Section


Ethernet Services 7 Typical Applications Using Carrier
Ethernet Services
Study Guide Section 7 7.1 Access to IP Services

This section of the MEF-CECP Study Guide explains which aspects of Carrier 7.2 Wholesale Access Services
Ethernet need to be taken into account when running popular applications. 7.3 Mobile Backhaul
This is not an exhaustive list but does provide examples of the main factors 7.3.1 EVPL in Mobile Backhaul
relevant for different applications.
7.3.2 MEF 22 Use Cases

Section 7.1: Access to IP Services 7.4 Business Services


Popular application for enterprises using Carrier Ethernet to obtain services 7.5 TDM Private Line Replacement
from ISPs
7.6 Frame Relay/ATM Replacement
Section 7.2: Wholesale Access Services 7.7 WDM Private Network
Operators providing Carrier Ethernet services to service providers in order to Replacement

extend the coverage of the latter's footprint


Download PDF
Section 7.3: Mobile Backhaul
Using Carrier Ethernet for backhauling cell towers

Section 7.4: Business Services Download a pdf for


offline viewing.
Enterprises using Carrier Ethernet services to provide data connectivity
between 2 or more of their sites

Section 7.5: TDM Private Line Replacement


Carrier Ethernet services used to replace T1/E1 and other TDM legacy services Reference Documents

Section 7.6: Frame Relay/ATM Replacement MEF 6.1


Carrier Ethernet services used to replace Frame Relay and/or ATM network
MEF 8
infrastructure
MEF 10.2
Section 7.7: WDM Private Network Replacement
MEF 26.1
Carrier Ethernet services used instead of WDM connections
MEF 28
MEF Reference Presentation: Access
Technologies

MEF Reference Presentation: Mobile


Backhaul

MEF White Paper: CESoE

MEF-CECP Test Objectives

7 Target Applications for Carrier


Ethernet Services

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Positioning of Carrier Ethernet with other In this Section


technologies 8 Positioning of Carrier Ethernet
with other technologies
Study Guide Section 8 8.1 Carrier Ethernet and L2VPN

Carrier Ethernet vs L2VPN, IP and TDM 8.2 Carrier Ethernet and IP

8.3 Carrier Ethernet and TDM


This section provides information on L2VPN, IP and TDM service solutions
comparable to Carrier Ethernet in terms of the differences between these
Download PDF
solutions and Carrier Ethernet. In addition, information is provided on ways to
achieve a comparable service over a Carrier Ethernet Network (CEN).

Download a pdf for


offline viewing.

Reference Documents

MEF 6.1

MEF 8

MEF 10.2

MEF 22.1

MEF White Paper: CESoE

IETF RFC 4448

MEF-CECP Test Objectives

8 Comparing and Positioning Carrier


Ethernet Services
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Synchronization over Carrier Ethernet & In this Section


Circuit Emulation 9 Synchronization over Carrier
Ethernet & Circuit Emulation
Study Guide Section 9 < br/>

Circuit Emulation Service over Ethernet (CESoETH) is a technology that enables 9.1 Purpose and Need
transport of TDM services over a Carrier Ethernet Network (CEN) as well as 9.1.1 What is CESoETH
enabling packet-based clock synchronization over a CEN.
9.1.2 MEF 8 model

CESoETH is specified in MEF 8 "Implementation Agreement for the Emulation of < br/>
PDH Circuits over Metro Ethernet Networks".
9.2 CES Components

MEF 8 gives precise instructions for implementing interoperable CES solutions 9.2.1 Interface to Customer
that reliably transport TDM circuits across CENs while meeting the required 9.2.2 Generic Interworking
performance of circuit emulated TDM services as defined in ITU-T and ANSI Function (GIWF)
TDM standards. 9.2.3 Functional Layering

< br/>
This section:-
9.3 Service Definitions
Explains the concept of emulated TDM circuits over Ethernet
9.3.1 E-Line
Presents the MEF 8 model
9.3.2 UNI Attributes
Details the components required for the service
Details the specific UNI and EVC attributes of CES over Ethernet 9.3.3 EVC Attributes
Explains the concept of packet-based sychronization and its 9.3.4 EVC per UNI Attributes
implementation over Carrier Ethernet
< br/>

9.4 Synchronization

9.4.1 Packet Based


Synchronization Methods

9.4.1.1 Adaptive Clock Recovery

9.4.1.2 NTP
9.4.1.3 1588 v2

9.4.2 SyncE

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 8

MEF 22.1

MEF Reference Presentation: Access


Technologies

MEF-CECP Test Objectives

9 CES over Ethernet

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10 Maintenance

10.1 Relevant Standards


This section provides information about relevant standards, framework, fault
10.1.1 IEEE 802.1ag Overview
and performance management of Ethernet Service OAM.
10.1.2 Y.1731 Overview
< br/>
10.2 Framework

10.2.0 Domains

10.2.1 Constructs

10.2.1.1 MEP, MIP, MEG, MEG


Level

10.2.2 MEF 17

10.2.2.1 Model

10.2.2.2 Maintenance Entities

< br/>

10.3 Fault Management

10.3.1 Definition

10.3.2 Procedures

10.3.2.1 Continuity Check


Message

10.3.2.2 Loopback Message

10.3.2.3 Link Trace Message

< br/>
10.4 Performance Management

10.4.1 Definition

10.4.2 Procedures

10.4.2.0 Frame Delay

10.4.2.1 Delay Measurement


Message

10.4.2.2 Loss Measurement


Message

10.4.3 Computation Methods

10.4.3.0 Frame Delay

10.4.3.1 Inter-Frame Delay


Variation

10.4.3.2 Frame Loss Ratio

10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


LAN, E-Tree

< br/>

10.5 CoS Implementation


Agreement - MEF 23

10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Disclaimer
This MEF Study Guide is designed to provide as much useful information as possible for those learning about MEF-
standardized Carrier Ethernet, and specifically for those individuals planning to take MEF Professional Certification exams
such as MEF-CECP. The MEF makes every effort to keep the MEF Study Guide as up to date and as comprehensive as
possible. However, the MEF disclaims all responsibility for the accuracy and completeness of the MEF Study Guide and
disclaims all responsibility for any consequences whatsoever resulting from the use of the MEF Study Guide. Also, the MEF
does not provide any assurance that use of this MEF Study Guide will ensure that MEF-CECP examinees answer MEF-CECP
certification exams correctly or pass the exam.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

MEF-CECP Exam Objectives


MEF MEF IEEE ITU-T IETF
Objective Description
Specs Marketing Standards Standards RFC

Describe and distinguish


between the service
1.1 attributes of EPL, EVPL, EP- MEF 6.1
LAN, EVP-LAN, EP-Tree, and
EVP-Tree.

Describe how EPL, EVPL, EP-


LAN, EVP-LAN, EP-Tree, and
1.2 MEF 6.1
EVP-Tree are used to meet
various subscriber needs.

Describe the connectivity


properties of bridging,
provider bridging, provider
backbone bridging (PBB),
provider backbone bridging
with traffic engineering 802.1ah
4761
extensions (PBB-TE),
2.1 802.1Qay
Ethernet over SONET/SDH, 5921
Carrier Ethernet over MPLS 802.1ad-2005
VPWS, Carrier Ethernet over
MPLS VPLS, Carrier Ethernet
over MPLS TP, Carrier
Ethernet over OTN, and
Carrier Ethernet over WDM.

Describe the capabilities of


the bridging, provider
bridging, provider backbone
bridging (PBB), provider MEF White
backbone bridging with Paper:
4448
traffic engineering Ethernet
2.2 802.1ad-2005 Y.1415
extensions (PBB-TE), Services and 4761
SONET/SDH, MPLS VPWS, Access
MPLS VPLS, MPLS TP, OTN Technologies
and WDM with regards to
delivery of Carrier Ethernet
services.

Carrier
Describe the advantages of Ethernet 5921
2.4 specific Carrier Ethernet Access 802.1Q-2009
transport technologies. Reference 5960
Presentation

Mobile
G.8031
Describe service protection Backhaul
2.5 802.1Q-2009
mechanisms. Reference G.8032
Presentation

Describe the capabilities of


MEF White
Ethernet over PDH, Ethernet
Paper:
over bonded copper,
Ethernet
3.1 Ethernet over HFC, Ethernet
Services and
over packet radio, Ethernet
Access
over fiber and Ethernet over
Technologies
PON.

MEF White
Paper:
Compare and contrast
Ethernet
3.2 specific Carrier Ethernet
Services and
Access technologies.
Access
Technologies

Carrier
Ethernet
Access
Reference
Given a scenario, identify Presentation
which Carrier Ethernet 802.3-2005
3.3
Access Technology will meet MEF White 802.16-2009
the stated requirements. Paper:
Ethernet
Services and
Access
Technologies

Define Ethernet User-to-


Network Interface (UNI),
Ethernet External Network-
to-Network Interface MEF 10.2
4.1 (ENNI), Ethernet Virtual
Connection (EVC), Service MEF 26
Provider, Operator, and
Operator Virtual Connection
(OVC).

Describe the role of Ethernet


User-to-Network Interface
(UNI), Ethernet External
Network-to-Network
4.2 Interface (ENNI), Ethernet MEF 26
Virtual Connection (EVC),
Service Provider, Operator,
and Operator Virtual
Connection (OVC).

Define per UNI service


attributes (e.g., physical
MEF 10.2
interfaces, Frame format,
5.1
Ingress/egress Bandwidth MEF 20
Profiles, CE-VLAN ID/EVC
Map, UNI protection).

Define EVC per UNI service


MEF 6.1
attributes (e.g.
5.2
ingress/egress Bandwidth MEF 10.2
Profiles).

Define per EVC service


attributes (e.g., CE-VLAN ID
Preservation, CoS ID
Preservation, Relationship
5.3 MEF 10.2
between Service Level
Agreement and Service
Level Specification, Class of
Service).

Define OVC End Point per


ENNI service attributes
5.4 MEF 26
(e.g., ingress/egress
bandwidth profiles).

MEF 10.2
5.5 Describe bandwidth profiles.
MEF 26

Given a service scenario, MEF 6.1


describe relevant service
5.6 MEF 10.2
attribute
settings/parameters. MEF 26

Define and describe the


components of a Service
5.7 Level Specification and the MEF 10.2
relationship to Service Level
Agreement.

Define and describe ENNI


attributes (e.g., physical
interfaces, Frame format,
5.8 MEF 26
Ingress/egress Bandwidth
Profiles, End Point Map,
ENNI protection).

Define and describe OVC


attributes (e.g., CE-VLAN ID
Preservation, CoS ID
Preservation, Relationship
5.9 MEF 26
between Service Level
Agreement and Service
Level Specification, Class of
Service, hairpin switching).

Define and describe the MEF 20 802.1AX


5.10 Carrier Ethernet protection
mechanisms. MEF 26 802.3 clause 43

Describe the Certification


6.1 process and requirements
for networking equipment.

Describe the Certification


process and requirements
6.2
for services delivered by a
service provider

MEF 9
Describe what is covered by
6.3 MEF 9, MEF 14, and MEF 18 MEF 14
Certifications.
MEF 18

Describe the benefits of MEF


Certification for equipment
6.4
vendors, Service Provider,
and end users.

Carrier
Describe wholesale access
Ethernet
services, retail
Access
commercial/business
Reference
services, mobile backhaul
7.1 MEF 22 Presentation
services, Ethernet access to
IP services, and supporting
White Paper
legacy services over
Introduction
Ethernet.
to CESoE

Describe which UNI or ENNI


MEF 10.2
attribute values are selected
7.2
for a given target MEF 26
application.

Describe which EVC or OVC


MEF 10.2
attribute values are selected
7.3
for a given target MEF 26
application.

Describe how specific service


requirements of a target
application (e.g., frame
relay, Dedicated Internet MEF 6.1
7.4 Access, DSL or Cable
Internet access, TDM Private MEF 10.2
Lines, WDM private network
are met using Ethernet
services.

Mobile
Backhaul
Reference
Presentation
Given a scenario, determine MEF 6.1
7.5 appropriate Ethernet
Carrier
services. MEF 8
Ethernet
Access
Reference
Presentation

Compare and contrast


MEF 6.1 White Paper
Ethernet services with L2,
8.1 Introduction 4448
IP, and TDM private line MEF 8 to CESoE
services.
MEF 6.1
Given a scenario,
MEF 8
recommend an Ethernet
8.2
service to meet end user MEF 10.2
specifications.
MEF 22

Carrier
Define the purpose and need Ethernet
9.1 for Circuit Emulation over MEF 8 Access
Ethernet applications. Reference
Presentation

Carrier
Define the critical
Ethernet
components of circuit
9.2 MEF 8 Access
emulation over Ethernet
Reference
service.
Presentation

Define the MEF Service


9.3 Definitions used to deliver MEF 8
emulated circuits.

Define the EVC service


9.4 attributes required for MEF 8
emulated circuits.

Define the three techniques


and their uses for delivering
synchronized clock over
9.5 emulated circuits (e.g., MEF 22
Adaptive, 1588v2,
Synchronous Ethernet, NTP,
PTP).

Describe how circuit


9.6 emulation is used in Mobile MEF 22
Backhaul applications.

Describe the various


partitioning of
10.1 responsibilities for Service MEF 17
Operations Administration
and Maintenance (SOAM).

Describe the basic


10.2 mechanisms for fault MEF 17 Y.1731
management.

Global
Describe the basic MEF 10.2 Interconnect
10.3 mechanisms for performance Y.1731
Reference
management. MEF 17
Presentation

Describe the basic metrics MEF 6.1


10.4 for performance
management. MEF 10.2

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Diagrams

Fundamentals Carrier Ethernet Carrier Ethernet Key


Attributes of
of Services over Services over Components of
Carrier Ethernet
Carrier Ethernet Transport Access Carrier Ethernet
Services
Technologies Technologies

MEF Certification Typical Target Positioning of Synchronization


Carrier Ethernet
of Applications for Carrier Ethernet over
Service OAM
Carrier Ethernet Carrier Ethernet with other Carrier Ethernet &
Services Services Technologies Circuit Emulation

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

References
This page provides links to documents and associated links that are relevant for Carrier Ethernet study in general and
specifically for preparing for the MEF-CECP professional certification exam.

MEF Specifications MEF Specifications MEF Specifications


Service Definitions Service Attributes Service OAM
E-Line, E-LAN & E-Tree: EVC and UNI Requirements and Framework
MEF 6.1 MEF 10.2 Phase 1
MEF 17
ENNI Support for UTA and VUNI: OVC and ENNI
MEF 28 MEF 26.1

E-Access:
MEF 33

MEF Specifications MEF Specifications MEF White Papers


Implementation Abstract Test Suites
Agreements Ethernet Services and Access
Ethernet Services at the UNI Technologies
Emulation of PDH Circuits MEF 9
MEF 8 Introduction to CESoE
Traffic Management Phase 1
User Network Interface (Type 1) MEF 14
MEF 13
Circuit Emulation Services
UNI Type 2 MEF 18
MEF 20

Mobile Backhaul Phase 2


MEF 22.1

MEF Reference IEEE Standards ITU-T Recommendations


Presentations
Provider Bridges Ethernet-MPLS Interworking
802.1ad-2005 Y.1415
Carrier Ethernet and Access
Technologies Provider Backbone Bridges OAM Functions and Mechanisms
802.1ah-2008 Y.1731
Carrier Ethernet and Mobile
Link Aggregation Ethernet Protection Switching
Backhaul 802.1AX-2008 G.8031

Interconnect of Carrier Ethernet Virtual LANs Ethernet Ring Protection


Networks and Services 802.1Q-2005 Switching
G.8032
Provider Backbone Bridging -
Traffic Engineering (PBB-TE)
802.1Qay-2009

Ethernet
802.3-2005

Ethernet Link Aggregation


802.3 clause 43

Air Interface for Fixed and Mobile


Broadband Wireless Access
System
802.16-2009


IETF RFCs
Encapsulation Methods for
Transport of Ethernet over MPLS
RFC 4448

Virtual Private LAN Service


(VPLS) Using BGP for Auto-
Discovery and Signaling
RFC 4761

A Framework for MPLS in


Transport Networks
RFC 5921

MPLS Transport Profile Data


Plane Architecture
RFC 5960

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Disclaimer
This MEF Study Guide is designed to provide as much useful information as possible for those learning about MEF-standardized Carrier
Ethernet, and specifically for those individuals planning to take MEF Professional Certification exams such as MEF-CECP.

The MEF makes every effort to keep the MEF Study Guide as up to date and as comprehensive as possible. However, the MEF disclaims
all responsibility for the accuracy and completeness of the MEF Study Guide and disclaims all responsibility for any consequences
whatsoever resulting from the use of the MEF Study Guide.

Also, the MEF does not provide any assurance that use of this MEF Study Guide will ensure that MEF-CECP examinees answer MEF-CECP
certification exams correctly or pass the exam.

Continue toto Study


Continue Study Guide
Guide
Home About Contact

Ethernet Academy Metro Ethernet Forum


More and more


Carrier Ethernet Professionals are turning
to the MEF for information on the latest in
Carrier Ethernet standards development
and terminology. These professionals are
highly mobile and networked for their
work, so we at the MEF want to make our
materials as easy to access and review as
possible for professionals on the go!

MEF-CECP Exam Objectives

MEF MEF IEEE ITU-T IETF


Objective Description
Specs Marketing Standards Standards RFC

Describe and distinguish


between the service attributes
1.1 MEF 6.1
of EPL, EVPL, EP-LAN, EVP-
LAN, EP-Tree, and EVP-Tree.

Describe how EPL, EVPL, EP-


LAN, EVP-LAN, EP-Tree, and
1.2 MEF 6.1
EVP-Tree are used to meet
various subscriber needs.

Describe the connectivity


properties of bridging,
provider bridging, provider
backbone bridging (PBB),
provider backbone bridging
with traffic engineering 802.1ah
extensions (PBB-TE), Ethernet 4761
2.1 802.1Qay
over SONET/SDH, Carrier
5921
Ethernet over MPLS VPWS, 802.1ad-2005
Carrier Ethernet over MPLS
VPLS, Carrier Ethernet over
MPLS TP, Carrier Ethernet over
OTN, and Carrier Ethernet
over WDM.

Describe the capabilities of the


bridging, provider bridging,
provider backbone bridging MEF White
(PBB), provider backbone Paper:
bridging with traffic Ethernet 4448
2.2 802.1ad-2005 Y.1415
engineering extensions (PBB- Services and
4761
TE), SONET/SDH, MPLS VPWS, Access
MPLS VPLS, MPLS TP, OTN and Technologies
WDM with regards to delivery
of Carrier Ethernet services.

Carrier
Describe the advantages of Ethernet 5921
2.4 specific Carrier Ethernet Access 802.1Q-2009
transport technologies. Reference 5960
Presentation

Mobile
Describe service protection Backhaul G.8031
2.5 802.1Q-2009
mechanisms. Reference
G.8032
Presentation

Describe the capabilities of MEF White


Ethernet over PDH, Ethernet Paper:
over bonded copper, Ethernet Ethernet
3.1
over HFC, Ethernet over Services and
packet radio, Ethernet over Access
fiber and Ethernet over PON. Technologies

MEF White
Paper:
Compare and contrast specific
Ethernet
3.2 Carrier Ethernet Access
Services and
technologies.
Access
Technologies

Carrier
Ethernet
Access
Reference
Given a scenario, identify Presentation
which Carrier Ethernet Access 802.3-2005
3.3
Technology will meet the MEF White
802.16-2009
stated requirements. Paper:
Ethernet
Services and
Access
Technologies
Define Ethernet User-to-
Network Interface (UNI),
Ethernet External Network-to-
Network Interface (ENNI), MEF 10.2
4.1
Ethernet Virtual Connection
MEF 26
(EVC), Service Provider,
Operator, and Operator Virtual
Connection (OVC).

Describe the role of Ethernet


User-to-Network Interface
(UNI), Ethernet External
Network-to-Network Interface
4.2 (ENNI), Ethernet Virtual MEF 26
Connection (EVC), Service
Provider, Operator, and
Operator Virtual Connection
(OVC).

Define per UNI service


attributes (e.g., physical
interfaces, Frame format, MEF 10.2
5.1
Ingress/egress Bandwidth
MEF 20
Profiles, CE-VLAN ID/EVC Map,
UNI protection).

Define EVC per UNI service MEF 6.1


5.2 attributes (e.g. ingress/egress
Bandwidth Profiles). MEF 10.2

Define per EVC service


attributes (e.g., CE-VLAN ID
Preservation, CoS ID
Preservation, Relationship
5.3 MEF 10.2
between Service Level
Agreement and Service Level
Specification, Class of
Service).

Define OVC End Point per


ENNI service attributes (e.g.,
5.4 MEF 26
ingress/egress bandwidth
profiles).

MEF 10.2
5.5 Describe bandwidth profiles.
MEF 26
MEF 6.1
Given a service scenario,
5.6 describe relevant service MEF 10.2
attribute settings/parameters.
MEF 26

Define and describe the


components of a Service Level
5.7 Specification and the MEF 10.2
relationship to Service Level
Agreement.

Define and describe ENNI


attributes (e.g., physical
interfaces, Frame format,
5.8 MEF 26
Ingress/egress Bandwidth
Profiles, End Point Map, ENNI
protection).

Define and describe OVC


attributes (e.g., CE-VLAN ID
Preservation, CoS ID
Preservation, Relationship
5.9 MEF 26
between Service Level
Agreement and Service Level
Specification, Class of Service,
hairpin switching).

Define and describe the MEF 20 802.1AX


5.10 Carrier Ethernet protection
mechanisms. MEF 26 802.3 clause 43

Describe the Certification


6.1 process and requirements for
networking equipment.

Describe the Certification


process and requirements for
6.2
services delivered by a service
provider

MEF 9
Describe what is covered by
6.3 MEF 9, MEF 14, and MEF 18 MEF 14
Certifications.
MEF 18

Describe the benefits of MEF


Certification for equipment
6.4
vendors, Service Provider, and
end users.

Carrier
Describe wholesale access Ethernet
services, retail Access
commercial/business services, Reference
7.1 mobile backhaul services, MEF 22 Presentation
Ethernet access to IP services,
and supporting legacy services White Paper
over Ethernet. Introduction
to CESoE

Describe which UNI or ENNI MEF 10.2


7.2 attribute values are selected
for a given target application. MEF 26

Describe which EVC or OVC MEF 10.2


7.3 attribute values are selected
for a given target application. MEF 26

Describe how specific service


requirements of a target
application (e.g., frame relay,
Dedicated Internet Access, MEF 6.1
7.4
DSL or Cable Internet access,
MEF 10.2
TDM Private Lines, WDM
private network are met using
Ethernet services.

Mobile
Backhaul
Reference
Presentation
MEF 6.1
Given a scenario, determine
7.5
appropriate Ethernet services. Carrier
MEF 8
Ethernet
Access
Reference
Presentation

Compare and contrast MEF 6.1 White Paper


8.1 Ethernet services with L2, IP, Introduction 4448
and TDM private line services. MEF 8 to CESoE

MEF 6.1
Given a scenario, recommend MEF 8
8.2 an Ethernet service to meet
end user specifications. MEF 10.2

MEF 22

Carrier
Define the purpose and need Ethernet
9.1 for Circuit Emulation over MEF 8 Access
Ethernet applications. Reference
Presentation

Carrier
Define the critical components Ethernet
9.2 of circuit emulation over MEF 8 Access
Ethernet service. Reference
Presentation

Define the MEF Service


9.3 Definitions used to deliver MEF 8
emulated circuits.

Define the EVC service


9.4 attributes required for MEF 8
emulated circuits.

Define the three techniques


and their uses for delivering
synchronized clock over
9.5 emulated circuits (e.g., MEF 22
Adaptive, 1588v2,
Synchronous Ethernet, NTP,
PTP).

Describe how circuit emulation


9.6 is used in Mobile Backhaul MEF 22
applications.

Describe the various


partitioning of responsibilities
10.1 for Service Operations MEF 17
Administration and
Maintenance (SOAM).

Describe the basic mechanisms


10.2 MEF 17 Y.1731
for fault management.

Global
MEF 10.2 Interconnect
Describe the basic mechanisms
10.3 Y.1731
for performance management. MEF 17 Reference
Presentation

MEF 6.1
Describe the basic metrics for
10.4
performance management. MEF 10.2

For more information on the MEF Professional Certification program


click here.

If you have questions regarding the MEF specifications, you should join the experts at the Ethernet Academy and
participate in the Forums and Discussion Groups.

Contact Us

Copyright 2011-2012 Metro Ethernet Forum Copyright 2011-2012 Ethernet Academy


Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Fundamentals of Carrier Ethernet In this Section

1 Fundamentals of Carrier Ethernet


Study Guide Section 1.1
1.1 Carrier Ethernet and LAN
Carrier Ethernet and LAN Ethernet Ethernet

1.2 Carrier Ethernet Service Types


The very widely used LAN Ethernet technology developed and implemented
around the world since the 1970's is just that - a Local Area Network 1.3 Virtual Service and Private
Service
technology designed for use within buildings or between buildings in a
campus. LAN Ethernet is not designed for use over long distances within
Download PDF
cities, across regions and between continents.

LAN Ethernet is also designed for use only over specific short distance
infrastructures (e.g. 100BaseT cabling), not over Wide Area Network Download a pdf for
offline viewing.
infrastructures (e.g. PDH, SONET/SDH, DOCSIS, PON, WDM etc.)

The different aspects of a true service are also not supported by the very
popular LAN Ethernet technology which does not guarantee levels of
availability (e.g. 5 nines), Classes of Service suited to different application Reference Documents
and user needs nor does it support the type of management capabilities
MEF 6.1
required for large network service delivery that is available with legacy WAN
technologies.
MEF-CECP Test Objectives
In order to combine the advantages of LAN Ethernet's large installed base and 1 Services Definitions
the familiarity of its technology with the requirements of multi-site users and
their service providers, the MEF began in 2001 to develop the specifications
Send Feedback
that today provide the basis for the use of Ethernet as a global networking
solution.
Name:

The MEF defined five key attributes that differentiate Carrier Ethernet from
Email:
LAN Ethernet, and which form the basis for the development of Carrier
Ethernet specifications by the MEF. Comments

5 Attributes of Carrier Ethernet

Send Feedback

Figure 1.1.F1: 5 Attributes of Carrier Ethernet

Standardized services
Scalability
Reliability
Service management
Quality of service

Standardized services enable end users and service providers to coordinate in


order to achieve data connectivity based on Carrier Ethernet between
multiple end user sites as required by organizations around the globe.

Scalability enables the data connectivity of any number of multiple end user
sites over any distance, whether it be metro, regional, national or
intercontinental using Carrier Ethernet.

Reliability enables end users to rely on Carrier Ethernet to run their business
and mission critical applications.

Service management enables service providers to rollout, maintain and


troubleshoot data connectivity services based on Carrier Ethernet in a cost
effective and timely manner.

Quality of Service enables the use of a single network to run multiple


services to multiple end-users running a wide variety of applications with
different bandwidth and latency requirements - all by using Carrier Ethernet.

Based on the goals of the 5 attributes and the specifications developed by the
MEF, Carrier Ethernet

delivers Ethernet frames between different locations in any part of


the world at speeds between 1 Mbps and at least 10 Gbps
differentiates between traffic of multiple end-users running over a
single network
runs over multiple types of infrastructure and transport technologies
coexists with existing Layer 2 and Layer 3 solutions while taking
advantage of the huge worldwide Ethernet installed base

Carrier Ethernet Service

A Carrier Ethernet service is defined as a data communication service based


on Carrier Ethernet which is delivered to an organization (e.g. an enterprise)
by an Ethernet Service Provider. The purpose of an Ethernet service is to
connect one or more remote sites, or to connect one or more end-user sites
to an Internet service provider, in a reliable, scalable and manageable
manner. The end user (also referred to as a subscriber) benefits from a
ubiquitous, standardized, carrier-class service and network defined by five
attributes that distinguish it from familiar LAN based Ethernet.

Carrier Ethernet Network

Figure 1.1.F2: Typical Carrier Ethernet Network

The connection between the customer's site and the Carrier Ethernet Network
(CEN) is achieved by connecting a switch/router at the end-user premises
denoted as CE (Customer Equipment) to one or more switches/routers of the
Service Provider (SP). The interface between the CE and the CEN is referred
to as the User Network Interface (UNI)

Is Carrier Ethernet a service, a network or a technology?

For an end-user, Carrier Ethernet is a service defined by the five attributes of


Carrier Ethernet. For a service provider, Carrier Ethernet is simultaneously a:-

Set of certified network elements that connect to one another in


order to transport the services offered to the customer
Platform of value added services
Standardized service for all users

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Fundamentals of Carrier Ethernet In this Section

1 Fundamentals of Carrier Ethernet


Study Guide Section 1.2
1.1 Carrier Ethernet and LAN
Carrier Ethernet Service Types Ethernet

1.2 Carrier Ethernet Service Types


The service provider and the end-user coordinate between them the required
service in terms of standardized service types and service attributes. 1.3 Virtual Service and Private
Service
There are three service types that describe the basic connectivity options of a
Carrier Ethernet service: Download PDF

E-Line
E-LAN Download a pdf for
E-Tree offline viewing.

These Carrier Ethernet service types are fundamental to the Carrier Ethernet
service model and are defined in MEF 6.1. All aspects of the MEF's technical,
marketing and certification work flow from the definitions and uses of E-Line, Reference Documents
E-LAN and E-Tree. Brief descriptions for these service types are provided
below, and are expanded upon in the remainder of this MEF-CECP Study MEF 6.1
Guide.
MEF-CECP Test Objectives
E-Line
1 Services Definitions
An E-Line is a point to point Ethernet service that connects exactly 2 UNIs.
Those 2 UNIs can communicate only with each other.
Send Feedback

Name:

Email:
Comments

Figure 1.2.F1: E-Line Carrier Ethernet service type

E-Lines are used to create:-


Send Feedback

Ethernet Private Lines


Ethernet Virtual Private Lines
Ethernet Internet access

For example, it can be used to replace TDM private lines. E-Line is the most
popular Ethernet service type due to its simplicity.

E-LAN

An E-LAN is a multipoint to multipoint service that connects a number of UNIs


(2 or more) providing full mesh connectivity for those sites. Each UNI can
communicate with any other UNI that is connected to that Ethernet service.

Figure 1.2.F2: E-LAN Carrier Ethernet service type

E-LANs are used to create:-

Multipoint L2 VPNs
Transparent LAN services
Layer 2 VPNs (L2VPN)
Foundation for IPTV and Multicast networks

E-Tree

An E-Tree is a rooted multipoint service that connects a number of UNIs


providing sites with hub and spoke multipoint connectivity. Each UNI is
designated as either 'root' or 'leaf'. A root UNI can communicate with any leaf
UNI, while a leaf UNI can communicate only with a root UNI.

E-Trees provide the separation between UNIs required to deliver a single


service instance in which different customers (each having a leaf UNI) connect
to an ISP which has one or more root UNIs. Having more than one root UNI is
useful for load sharing and resiliency schemes.
Figure 1.2.F3: E-Tree Carrier Ethernet service type

E-Trees are used to create:-

Multicast delivery services


Internet access
Mobile backhaul services
Telemetry services

Difference between E-LAN and E-Tree

E-LAN services are appropriate when all UNIs can generate traffic towards any
other UNI and all UNIs belong to the same administrative domain - in other
words when traffic separation between different organizations sharing the
service is not required.

E-Tree services are appropriate when the service source is located at just one
UNI, or a small number of UNIs, each of which is designated a root UNI. The
end-users of the service are typically client organizations that require that
their respective traffic will not be visible to other clients of the service.

Root vs. Leaf

In E-Lines and E-LANs, all UNIs are designated as a root UNI.

In E-Tree, UNIs are designated either as root UNIs or as leaf UNIs.Root UNIs
are used to source traffic that can be directed to any other UNI in the E-Tree.
Those UNIs should be only able to see traffic that is originates in one of the
root UNIs in the E-Tree are designated as leaf UNIs.

For example in an E-Tree used to provide access to multiple organizations to a


single ISP, the ISP POP will sit at the root UNI, whereas each organization
accessing the ISP sits at a leaf UNI so that it is unable to see traffic to and
from other ISP clients.

Multiple root UNIs are permitted in E-Trees in order to support mirror sites
(resiliency) and load sharing configurations.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Fundamentals of Carrier Ethernet In this Section

1 Fundamentals of Carrier Ethernet


Study Guide Section 1.3
1.1 Carrier Ethernet and LAN
Virtual Service and Private Service Ethernet

1.2 Carrier Ethernet Service Types


In its simplest form, each UNI is dedicated to a single service instance,
providing very simple mapping of customer traffic into the service. 1.3 Virtual Service and Private
Service
This type of service is referred to as a private service and is also called port-
based, where the service granularity is the port used for the User Network Download PDF
Interface (UNI) connectivity.

Private services can be offered for any topology. Download a pdf for
offline viewing.
EPL: Ethernet Private Line for port-based point-to-point service. EPL
is the private variant of an E-Line
EP-LAN: Ethernet Private LAN for port-based multipoint-to-multipoint
service. EP-LAN is the private variant of an E-LAN Reference Documents
EP-Tree: Ethernet Private Tree for port-based rooted-multipoint
service. EP-Tree is the private variant of an E-Tree. MEF 6.1

The advantage of the private service approach is its simplicity. The MEF-CECP Test Objectives
disadvantage is its lack of scalability since it requires several ports on both
1 Services Definitions
the Customer Equipment (CE) and the switch/router at the provider edge.

To overcome this barrier to scalability, the MEF defined the virtual service Send Feedback
based on the concept of VLANs where each service is identified by one or
more VLAN IDs. Following IEEE 802.1Q, the VLAN tag is the C-Tag. Name:

A virtual service means that a UNI can deliver multiple services using a single Email:
physical port, and can be offered for any topology.
Comments
EVPL: Ethernet Virtual Private Line for VLAN-based point-to-point
service. EVPL is the virtual variant of an E-Line
EVP-LAN: Ethernet Virtual Private LAN for VLAN-based multipoint-to-
multipoint service. EVP-LAN is the virtual variant of an E-LAN Send Feedback

EVP-Tree: Ethernet Virtual Private Tree for VLAN-based rooted-


multipoint service. EVP-Tree is the virtual variant of an E-Tree.

Service Multiplexing

In order to enable a virtual service, the UNI attribute of Service Multiplexing


must be set to YES.

In contrast, to enable a private service, the UNI attribute of All-to-One


Bundling must be set to YES for all UNIs belonging to the service.

This is illustrated in the example of an EVP-Tree service:

Figure 1.3.F1: Example EVP-Tree

EVC1 is used for Internet access, providing service to 3 customers UNIs A, B


and C are leaf UNIs and therefore cannot see each other's traffic. This is an
instance of an EVP-Tree service. Note that if EVC1 had been implemented as
an EVP-LAN, then UNI A and UNI B would be able to communicate and receive
each other's traffic, which in this case is not desirable. Hence the use of EVP-
Tree.

EVC2 shares the same UNI port D with EVC1 and is used to deliver video
multicast to a different set of customers.

Multiple Services using single UNI

A single UNI can serve multiple Carrier Ethernet service types, as shown in
this example.

Figure 1.3.F2: Multiple Carrier Ethernet services using single UNI

The headquarters (HQ) of the enterprise has 2 services sharing a single port on
its router:

EVPL connect the organization to its ISP. The traffic sent to the ISP carries C-
Tags as agreed with the Carrier Ethernet Network (CEN) service provider
EVP-LAN connects the HQ with 2 other branches, providing L2VPN between
these three sites.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Download MEF-CECP Study Guide PDF

The MEF-CECP Study Guide is available for download.

This is intended for non-iPad users. iPad users automatically have an offline version.

Please note that this PDF version of the MEF-CECP Study Guide will change very frequently. If you
are using an offline version, you should check frequently to see if you have the latest version.

Current version: MEF On The GO 1.1.120617 (~21 MB)

Please note that the disclaimer for the MEF-CECP Study Guide applies equally to the PDF version as
well as to the online versions. By downloading this PDF document you are accepting this disclaimer.

'

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

MEF 6.1
Metro Ethernet Services Definitions Phase 2
Specification

MEF 6.1 is a specification document developed by the Technical Committee of the MEF.

Abstract:

"This document uses the service attributes and parameters that are defined in the MEF Technical Specification Ethernet
Services Attributes Phase 2 [2] and applies them to create different Ethernet services. This document defines three
generic service constructs called Ethernet Service types and specifies their associated service attributes and parameters
used to create Point-to-Point, Multipoint-to-Multipoint, and Rooted-Multipoint Ethernet services. This document also
defines the requirements for several Ethernet services that use these generic Ethernet Service types. In addition, an
informative appendix is provided showing examples of some of the defined services. This document supersedes and
replaces MEF 6, Ethernet Services Definitions - Phase 1 [1]."
Download

Reference Presentation

The MEF has prepared an overview presentation which explains the MEF 6.1 specification.

Download

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Test Objectives 1 1 In this Section


Service Definitions 1 Fundamentals of Carrier Ethernet

1.1 Describe and distinguish between the service attributes of EPL, EVPL, EP- 1.1 Carrier Ethernet and LAN
LAN, EVP-LAN, EP-Tree, and EVP-Tree. Ethernet

1.2 Carrier Ethernet Service Types


1.2 Describe how EPL, EVPL, EP-LAN, EVP-LAN, EP-Tree, and EVP-Tree are
1.3 Virtual Service and Private
used to meet various subscriber needs. Service

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 6.1

MEF-CECP Test Objectives

1 Services Definitions

Send Feedback

Name:

Email:
Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Services over Transport In this Section


Technologies 2 Carrier Ethernet Services over
Transport Technologies
Study Guide Section 2.1 2.1 Transport Technologies

Transport Technologies 2.1.1 IEEE-based transport


technologies
Carrier Ethernet services can be implemented over any network based on the 2.1.1.1 Bridging
following transport technologies:
2.1.1.2 Provider Bridging (PB)
Transparent Bridging 2.1.1.3 Provider Backbone
Provider Bridging (PB) Bridging (PBB)

Provider Backbone Bridging (PBB) 2.1.1.4 Provider Backbone


Bridging - Traffic Engineering
Provider Backbone Bridging with Traffic Engineering (PBB-TE)
(PBB-TE)
MPLS VPWS
MPLS VPLS 2.1.2 MPLS based
MPLS TP
2.1.2.1 VPWS
SONET/SDH
2.1.2.2 VPLS
OTN
DWDM and CWDM 2.1.2.3 MPLS-TP

It is important to understand which transport technologies enable which 2.1.3 Transparent Transport
Carrier Ethernet services and which attributes are required, as well as to 2.1.3.1 SONET/SDH
understand the differences in capabilities (e.g. transparency to L2CP,
2.1.3.2 OTN
topology) of these technologies. This is explained in the corresponding sections
on each technology. 2.1.3.3 WDM

For the sake of simplicity, the above technologies have been grouped under
the following categories: 2.2 Protection and Resiliency

IEEE-based transport technologies


Download PDF
MPLS-based transport technologies
Transparent transport technologies

Download a pdf for


offline viewing.

Reference Documents

IEEE 802.1Q-2009

IEEE 802.1ad-2005

IEEE 802.1ah

IEEE 802.1Qay

ITU-T G.8031

ITU-T G.8032

ITU-T Y.1415

RFC 4448

RFC 4761

RFC 5921

RFC 5960

MEF-CECP Test Objectives

2 Transporting Carrier Ethernet


Services

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Services over Transport In this Section


Technologies 2 Carrier Ethernet Services over
Transport Technologies
Study Guide Section 2.2 2.1 Transport Technologies

Protection and Resiliency 2.1.1 IEEE-based transport


technologies
When connecting network elements in order to create a network, it is 2.1.1.1 Bridging
common practice to consider and provision for various failures. Ideally, the
2.1.1.2 Provider Bridging (PB)
traffic should continue to flow even if a failure of a link or a port has
occurred. 2.1.1.3 Provider Backbone
Bridging (PBB)

There are three types of failures to consider: 2.1.1.4 Provider Backbone


Bridging - Traffic Engineering
1. Port Failure (PBB-TE)

2. Link Failure
2.1.2 MPLS based
3. Network Element (NE) Failure
2.1.2.1 VPWS
Since MEF services define interfaces only, we focus on the first two types of
2.1.2.2 VPLS
failures. It should be noted that NE failure handling is heavily dependent on
2.1.2.3 MPLS-TP
the transport technology of the specific network in question.

Port protection 2.1.3 Transparent Transport

2.1.3.1 SONET/SDH
We focus our discussion on the external Interfaces - namely UNI and ENNI.
2.1.3.2 OTN
MEF 20 defines as a mandatory feature of UNI Type 2.2 the capability to
2.1.3.3 WDM
protect against a UNI-N port failure and/or protect against a failure of a
physical link crossing the UNI point.
2.2 Protection and Resiliency
The solution is LAG (Link Aggregation). The basic concept is having standby
links that can be used upon failure of a working (active) link. LAG enables the Download PDF
definition of a LAG group of at least 2 ports/2 physical links and considering
them as a single logical link. The UNI-N and UNI-C can be perceived as
connected over this single logical link. Note that one could connect 4 X 1GbE Download a pdf for
links and operate 3 of them as active links with one standby link. This would offline viewing.
yield a logical link of 3 Gbps between the UNI-N and UNI-C.

For ENNI the definition is stricter. LAG is defined for exactly 2 ports where
only one link is active and the second one is standby. The reason for this Reference Documents
limitation is the desire to have the service frames and SOAM frame traverse
the same link as each other, which cannot be guaranteed with LAG operating IEEE 802.1Q-2009
more than one active link (load sharing LAG). MEF recommends operating LAG IEEE 802.1ad-2005
with its control protocol LACP.
IEEE 802.1ah

UNI protection is depicted in the following figure: IEEE 802.1Qay

ITU-T G.8031

ITU-T G.8032

ITU-T Y.1415

RFC 4448
2.2.F1 - UNI protection
RFC 4761
ENNI Protection is depicted in the following figure:
RFC 5921

RFC 5960

2.2.F2 - ENNI Protection MEF-CECP Test Objectives

2 Transporting Carrier Ethernet


It should be noted that some vendors do allow LAG between different line-
Services
cards or chasses and thus utilize LAG not only for port and link protection but
also for NE protection. However, there is no industry standard for this
Send Feedback
solution.

Service protection Name:

Service Protection deals with the need to ensure that the EVC/OVC can Email:
provide the service even if a specific link or node within the CEN fails. This
enables the Service Provider to offer high availability (e.g. five 9s Comments

availability). It should be noted that not all services require resiliency.


Services that offer this capability are sometimes priced higher. Also, it could
be that service protection is offered for a certain CoS ID and not for others.
Send Feedback
For example a certain enterprise could request that a business critical
application be protected while passing on protection for the lower-priority
Internet access. This is supported by the fact that performance attributes like
availability are per CoS ID.

There are two approaches:

Active:Standby EVC

In this approach, there are 2 EVCs with identical service attributes. At any
given time only one EVC is used for the service. At the ingress UNI a certain
logic is used to decide which of the 2 EVCs are in use.
2.2.F3 - Standby EVC in Mobile Backhaul

Single EVC with transport protection

In this approach, there is a single EVC. The transport network is provisioned to


provide protection in case of link failure. For example in MPLS-TP there would
be 2 LSPs connecting the UNIs, one designated as active while the other is
designated as standby.

Fault Identification and Recovery

When there are two paths through a network that act as active:standby, the
fundamental question is how to detect the situation where the active path is
no longer functioning.

A common requirement from the TDM world is to detect and switchover in less
than 50 msec. Ethernet protection that was built upon spanning tree would
take a few seconds to find a new path.

Since then, new mechanisms have been defined to facilitate the sub-50 msec
requirement. One common approach is to run CCM messages at a high rate
(e.g. 10 msec or even 3.33 msec).

When one end of the EVC does not receive 3 consecutive CCMs, it assumes
that the path is not functioning and will take several actions like issuing a link
fault alarm and switch to the backup path.

Note that some implementations may constantly monitor the backup path too
and determine whether the backup path is alive.

Once switchover has occured, the service is considered recovered.

This approach hides the internal resiliency mechanism from the end user who
will feel only a very short traffic disruption.

The concept is depicted in the following figure:

2.2.F4 - Internal resiliency mechanism

G.8031, G.8032

The ITU-T has defined two standards that handle path protection. These are
G.8031 (Ethernet linear protection switching) and G.8032 (Ethernet linear
protection switching) Both utilize Y.1731 CCM messages for fault detection.
G.8031 is similar to SONET path protection. It is based on a working and a
protection path between two end points. Switching upon failure can occur in
under 50 msec. The concept is illustrated in the following figure:

2.2.F5 - Link protection in G.8031 and G.8032


G.8031 can be implemented over many transport technologies and is network
topology independent.

G.8032 is specifically for ring architectures, including virtual rings, where


there are obvious main and alternate paths along the ring between any 2
points.

The protocol also breaks loops and therefore make STP redundant.

The following figure illustrates virtual ring made out of a physical star:

2.2.F6 - Virtual ring on physical star

The ring protection is illustrated in the following figure:

2.2.F7 - Ring protection

In both mechanisms assuming that the protection is done between two


external interfaces (UNI to UNI, UNI to ENNI, ENNI to ENNI), the EVC/OVC
does not sense the protection switching, other than the short interval where
all service frames are lost.

MPLS FRR

MPLS Fast ReRoute (MPLS FRR) is a local protection mechanism in MPLS


networks where the LSP can bypass a faulty node or link using locally created
bypass. This is achieved in under 50 msec and can be triggered locally upon
node or port down status.

The Ethernet layer does not sense the bypass and the EVC that is carried over
the LSP continues to flow normally, other than the short interval where all
service frames are lost.

This is illustrated in the figure below:

2.2.F8 - MPLS FRR

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Services over Transport In this Section


Technologies 2 Carrier Ethernet Services over
Transport Technologies
Study Guide Section 2.1.1 2.1 Transport Technologies

IEEE-based transport technologies 2.1.1 IEEE-based transport


technologies
Carrier Ethernet services can be delivered over IEEE 802.1 standards-based: 2.1.1.1 Bridging

Bridged networks 2.1.1.2 Provider Bridging (PB)


Provider Bridged (PB) networks 2.1.1.3 Provider Backbone
Provider Backbone Bridged (PBB) networks Bridging (PBB)

Provider Backbone Bridged with Traffic Engineering (PBB-TE) networks 2.1.1.4 Provider Backbone
Bridging - Traffic Engineering
All these networks require some form of layer 1/2 transport technology to (PBB-TE)

interconnect bridges. Typically, these bridges are interconnected with IEEE


2.1.2 MPLS based
802.3 Ethernet.
2.1.2.1 VPWS
The capabilities of each of the IEEE 802.1 standards-based technologies used
2.1.2.2 VPLS
in these networks needs to be taken into account when implementing any of
2.1.2.3 MPLS-TP
the six Carrier Ethernet services:

EPL 2.1.3 Transparent Transport

EVPL 2.1.3.1 SONET/SDH


EP-LAN 2.1.3.2 OTN
EVP-LAN
2.1.3.3 WDM
EP-Tree
EVP-Tree
2.2 Protection and Resiliency
These technologies, and the Carrier Ethernet services delivered over them,
can operate over any physical topology:
Download PDF
mesh
partial mesh
Download a pdf for
tree
offline viewing.
set of rings

Reference Documents

IEEE 802.1Q-2009

IEEE 802.1ad-2005

IEEE 802.1ah

IEEE 802.1Qay

ITU-T G.8031

ITU-T G.8032

ITU-T Y.1415

RFC 4448

RFC 4761

RFC 5921

RFC 5960

MEF-CECP Test Objectives

2 Transporting Carrier Ethernet


Services

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Services over Transport In this Section


Technologies 2 Carrier Ethernet Services over
Transport Technologies
Study Guide Section 2.1.1.1 2.1 Transport Technologies

Bridging 2.1.1 IEEE-based transport


technologies
Bridging refers to networks that pass frames using C-Tags in accordance with 2.1.1.1 Bridging
IEEE 802.1Q. The C-Tag frame format is shown below:
2.1.1.2 Provider Bridging (PB)

2.1.1.3 Provider Backbone


Bridging (PBB)

2.1.1.4 Provider Backbone


Bridging - Traffic Engineering
(PBB-TE)

2.1.2 MPLS based

2.1.2.1 VPWS

2.1.2.2 VPLS

2.1.2.3 MPLS-TP
2.1.1.1.F1 - C-Tag Frame Format
2.1.3 Transparent Transport
The format of the C-Tag itself is provided below:
2.1.3.1 SONET/SDH

2.1.3.2 OTN

2.1.3.3 WDM

2.2 Protection and Resiliency


2.1.1.1.F2 - C-Tag Format

Download PDF
In a CEN (Carrier Ethernet Network) that is based on bridging, the ingress
bridge translates the incoming CE-VLAN ID to a specific tag defined for a
service. Each service is identified by a unique VLAN ID. In such a scenario, the
Download a pdf for
available VLAN IDs in the range 1 through 4094 must be shared and offline viewing.
coordinated between the subscribers and the CEN operator to ensure that the
same value is not used twice.
Obviously, subscribers cannot send untagged frames and frames with priority
tags across a CEN based on bridging since the egress bridge will not know how Reference Documents
to regenerate the tags and priorities in the frames forwarded to the
subscriber site. In addition, MAC learning is shared by subscriber bridges and IEEE 802.1Q-2009
the CEN's bridges, which again implies several limitations. This fact coupled IEEE 802.1ad-2005
with limited port filtering of the bridges makes support of E-Tree a significant IEEE 802.1ah
configuration challenge. In addition, such a network cannot support bundling,
IEEE 802.1Qay
as it is not possible to regenerate the original CE-VLAN IDs on an egress UNI
ITU-T G.8031
using a single C-Tag.
Since the CEN operates using bridges, it relies on xSTP (any variant of ITU-T G.8032
Spanning Tree Protocol) for loop prevention and resiliency. In the event of a ITU-T Y.1415
link failure, xSTP is used to find a new path through the CEN. This implies RFC 4448
that some subscriber L2CPs will not be tunneled through a CEN based on
RFC 4761
bridging.
RFC 5921
Using the C-Tag for service identification and dividing the applicable VLAN ID
range between the operator and the subscriber affects the number of services RFC 5960
that can be supported.
Also, there must be coordination between all participating UNIs of the CE- MEF-CECP Test Objectives
VLAN IDs used for each service. 2 Transporting Carrier Ethernet
The CoS ID for an EVC is identified by the PCP bits. No other field can Services
represent the CoS within the CEN. Therefore, if the PCP bits are used to set a
specific EVC CoS, then the CE-VLAN CoS preservation attribute cannot be set Send Feedback
to Yes.
In addition, the 8 possible values are shared between CoS ID and frame color. Name:
These values need to be transported through the CEN.
It is clear that only small scale CENs will be based on bridging, and where Email:
there are no ENNIs (since they require use of S-Tags).
Comments

The support for the various Ethernet services is summarized in the following
table:
Send Feedback
2.1.1.1.T1 - Bridging support for Carrier Ethernet Services

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Services over Transport In this Section


Technologies 2 Carrier Ethernet Services over
Transport Technologies
Study Guide Section 2.1.1.2 2.1 Transport Technologies

Provider Bridging (PB) 2.1.1 IEEE-based transport


technologies
Provider Bridging (PB), as specified by IEEE 802.1ad, aims to solve the 2.1.1.1 Bridging
problematic coordination of VLAN IDs between service providers and
2.1.1.2 Provider Bridging (PB)
subscribers that is required in bridging. PB is also designed to support
tunneling of customer traffic through a service provider's network. This 2.1.1.3 Provider Backbone
Bridging (PBB)
tunneling is achieved using a stacked VLAN approach, also known as Q-in-Q.
2.1.1.4 Provider Backbone
The IEEE 802.1ad amendment introduced a second type of VLAN tag for the Bridging - Traffic Engineering
purpose of delineating the service provider's tag from the customer's tag. This (PBB-TE)
service provider tag is known as the S-Tag, while the customer continues to
use the original VLAN tag, known as the C-Tag. 2.1.2 MPLS based

2.1.2.1 VPWS
The Double Tag Frame Format is shown below:
2.1.2.2 VPLS

2.1.2.3 MPLS-TP

2.1.3 Transparent Transport

2.1.1.2.F1 - Double Tag Frame Format 2.1.3.1 SONET/SDH

2.1.3.2 OTN
The structure of the S-Tag is shown below:
2.1.3.3 WDM

2.2 Protection and Resiliency

Download PDF
2.1.1.2.F2 - S-Tag Format
Download a pdf for
The value of the S-VLAN ID can be 1 through 4094. offline viewing.

Typically, a PB can support up to 4094 services. In some specific


configurations, a specific S-VLAN ID can be used for more than one service so
long as it can be guaranteed that those services sharing the VLAN ID are
Reference Documents
transported through separate bridges with no overlap of their paths.

IEEE 802.1Q-2009
As shown in the figure above, the S-VLAN Priority field is 3-bit wide, allowing
for 8 possible values. The Drop Eligible Indicator can be used to represent a IEEE 802.1ad-2005
frame's color. When the DEI bit is clear, the frame is considered to be Green. IEEE 802.1ah
When the DEI bit is set, the frame is considered to be Yellow. IEEE 802.1Qay

The edge bridge of the PB network performs the mapping to an EVC or an ITU-T G.8031
OVC, where the EVC or OVC is identified by an S-VLAN ID. It is also possible to ITU-T G.8032
add an S-Tag to ingress C-Tagged frame, thereby preserving the Subscriber's ITU-T Y.1415
original C-VLAN ID. This is also true in the case of an untagged frame.
RFC 4448

PB supports all six MEF-defined services (EPL, EVPL, EP-LAN, EVP-LAN, EP- RFC 4761
Tree and EVP-Tree). PB inherently supports service multiplexing by allowing RFC 5921
service providers to map C-VLANs to S-VLANs at a port being used for the UNI.
RFC 5960

PB relies on the bridges within the CEN (Carrier Ethernet Network) for
multicast operations required by E-LAN and E-Tree services. MEF-CECP Test Objectives

2 Transporting Carrier Ethernet


Note that E-Tree requires certain specific filtering to be configured on those Services
bridges connected to leaf UNIs.
The capabilites are summarized in the following table: Send Feedback

Name:

Email:

Comments

Send Feedback
2.1.1.2.T1 - Provider Bridging Support for Carrier Ethernet Services

PB forwarding is based on spanning tree for finding a path from source to


destination. PB service resiliency is based on RSTP and MSTP. Pre-defined
backup paths are not supported and therefore, the convergence time depends
on the topology and RSTP message rate. Port protection for UNI or ENNI can
be supported using LAG.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Services over Transport In this Section


Technologies 2 Carrier Ethernet Services over
Transport Technologies
Study Guide Section 2.1.1.3 2.1 Transport Technologies

Provider Backbone Bridging (PBB) 2.1.1 IEEE-based transport


technologies
Provider Backbone Bridging (PBB) in IEEE 802.1ah was developed to solve the 2.1.1.1 Bridging
problem of scaling to more than 4,094 services in a Provider Bridged network,
2.1.1.2 Provider Bridging (PB)
and to provide service providers with a bridging technology that would allow
them to encapsulate the Subscriber's MAC addresses, VLANs, and data, making 2.1.1.3 Provider Backbone
Bridging (PBB)
the transport of such frames "transparent" across their network.
2.1.1.4 Provider Backbone
Bridging - Traffic Engineering
The concept of PBB is to create a backbone network that interconnects PB
(PBB-TE)
networks at the customer edge.
PBB can be used to connect C-Tagged networks (CEs in MEF's terminology). 2.1.2 MPLS based

A PBB network (PBBN) can be a service provider's CEN that provides 2.1.2.1 VPWS
connectivity between UNIs for Subscribers through EVCs. Similarly, a PBB 2.1.2.2 VPLS
network could be an operator's network that provides connectivity from ENNI- 2.1.2.3 MPLS-TP
to-ENNI or from ENNI-to-UNI for service providers through OVCs.
2.1.3 Transparent Transport
The concept of MAC-in-MAC was introduced in PBB. MAC-in-MAC allows the
2.1.3.1 SONET/SDH
service provider to fully encapsulate the customer 802.1Q frame within
another MAC, which abstracts the service provider from the Subscriber's 2.1.3.2 OTN
address and VLAN information. 2.1.3.3 WDM
At the ingress to the PBB network, a second MAC header is inserted by the
bridge. With this technique, the Subscriber's frame is kept intact and
2.2 Protection and Resiliency
unaltered from end-to-end throughout the provider's backbone network. The
backbone bridges can only interpret the outermost MAC header information.
Download PDF
Furthermore, a new Tag type called the I-SID (Backbone Service Instance
Identifier) was introduced by PBB. The I-SID provides 24 bits for identifying
services, which enables the PBB network (PBBN) to uniquely identify up to 16
Download a pdf for
million service instances. This is equivalent to the scalability provided by offline viewing.
MPLS. In fact, the number of services per link is even higher than 16M. This is
because a link can serve multiple destination B_DA, each of which supports
16M services. Therefore, in practice, the number of services per link in PBB is
unlimited. Reference Documents

PBB introduces two new types of tags: the Backbone VLAN Tag (B-Tag) and IEEE 802.1Q-2009
the Backbone Service Instance Tag (I-Tag). The B-Tag is identical to an S-Tag, IEEE 802.1ad-2005
but is the tag that Backbone Bridges within the PBBN use to make traffic
IEEE 802.1ah
forwarding decisions. The I-Tag encapsulates the Subscriber's MAC information
IEEE 802.1Qay
and identifies the service instance through the I-SID. The I-SID is a 24-bit field
that is used to uniquely identify up to 16 million service instances. ITU-T G.8031

ITU-T G.8032
The frame format is depicted below:
ITU-T Y.1415

RFC 4448

RFC 4761

RFC 5921

RFC 5960

2.1.1.3.F1 - frame format MEF-CECP Test Objectives

On ingress, each service frame is parsed in order to identify the correct 2 Transporting Carrier Ethernet
EVC/OVC to which it is mapped. A new MAC header is then added accordingly. Services

The CEN (Carrier Ethernet Network) then forwards the frame through the
PBBN according to the backbone header. Forwarding is performed exactly as Send Feedback
in PB (Provider Bridging). Bridges learn (backbone) addresses, flood when an
unknown address is identified, and use the same xSTP-based resiliency Name:
mechanisms as in PB.
Email:
The B-Tag (which is identical to an S-Tag is format and TPID) has 3 bits of PCP
Comments
for CoS identification and can use the DEI bit for color marking within the
CEN, which is necessary for ENNI color forwarding.

One of the following actions can be performed on the value of the B-Tag's
PCP: - mapped from the original S-Tag - set to the EVC/OVC attributes -
Send Feedback

mapped from the original frame's DSCP header. This enables PBB to support
up to 8 CoSs per EVC/OVC.
PBB provides the same connectivity properties of a PB. Therefore PB can
support E-LINE, E-LAN and E-Tree with same constraints as in PB networks. In
other words, in PBB networks, there is limited transparency for EPL due to
L2CP filtering by the ingress bridges. Also, there is the need to add leaf-to-
leaf filtering in an E-Tree since this is not an intrinsic PB or PBB cabability.

The support for the various Ethernet services is summarized in the following
table:
2.1.1.3.T1 - Provider Backbone Bridging Support for Carrier Ethernet Services

PBB forwarding is based on spanning tree. In some cases the forwarding tables
can be adjusted to provide a specific path between B_SA and B_DA. PBB
service resiliency is based on RSTP and MSTP. Pre-defined backup paths are
not supported and therefore, convergence time depands on the topology and
RSTP message rate. Port protection for UNI or ENNI can be supported using
LAG.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Services over Transport In this Section


Technologies 2 Carrier Ethernet Services over
Transport Technologies
Study Guide Section 2.1.1.4 2.1 Transport Technologies

Provider Backbone Bridging - Traffic Engineering (PBB-TE) 2.1.1 IEEE-based transport


technologies
PBB networks are quite different from other transport networks in some 2.1.1.1 Bridging
fundamental aspects. The PBB network selects the path between source and
2.1.1.2 Provider Bridging (PB)
destination without the operator's control. PBB lacks pre-defined back-up
paths that are essential for delivering sub-50 msec service protection. Finally, 2.1.1.3 Provider Backbone
Bridging (PBB)
the flooding of unknown frames can impact the the ability to provide a
2.1.1.4 Provider Backbone
service with guaranteed bandwidth. Bridging - Traffic Engineering
(PBB-TE)
PBB-TE (Provide Backbone Bridging - Traffic Engineering) was specified in IEEE
802.1Qay to address these issues. Note that some vendors refer to PBB-TE as 2.1.2 MPLS based
PBT (Provider Bridging Transport).
2.1.2.1 VPWS
PBB-TE uses the same frame format as in PBB. However PBB-TE enables 2.1.2.2 VPLS
definition of end-to-end active and backup paths by means of management 2.1.2.3 MPLS-TP
plane configuration. The network operator has administrative control over
these paths, which allows them to "traffic engineer" the network. This method 2.1.3 Transparent Transport
is sometimes referred to as Connection Oriented Ethernet. 2.1.3.1 SONET/SDH
Having pre-defined paths eliminates the need to flood the network with
2.1.3.2 OTN
unknown frames and also means that xSTP is not required. Instead, CCM
messages can be exchanged along the path to detect and recover from link or 2.1.3.3 WDM

node faults in less than 50 msec.

2.2 Protection and Resiliency


PBB-TE services and CoS capabilities are the same as with PBB. This results in
extremely scalable PBB-TE networks with guaranteed paths and ability to
Download PDF
more easily guarantee bandwidth.
The support for the various Ethernet services is summarized in the following
table: Download a pdf for
offline viewing.

Reference Documents

IEEE 802.1Q-2009

IEEE 802.1ad-2005

IEEE 802.1ah

IEEE 802.1Qay

ITU-T G.8031

ITU-T G.8032

ITU-T Y.1415

RFC 4448

RFC 4761

RFC 5921

RFC 5960

MEF-CECP Test Objectives

2 Transporting Carrier Ethernet


Services
2.1.1.4.T1 - PBB-TE Support for Carrier Ethernet Services
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Services over Transport In this Section


Technologies 2 Carrier Ethernet Services over
Transport Technologies
Study Guide Section 2.1.2 2.1 Transport Technologies

MPLS based transport technologies 2.1.1 IEEE-based transport


technologies
Carrier Ethernet services can be delivered over networks based on MPLS 2.1.1.1 Bridging
VPWS, MPLS VPLS and MPLS-TP. These technologies are based on MPLS
2.1.1.2 Provider Bridging (PB)
standards specified by IETF and ITU-T. They all require some form of layer
1/2 transport technology betweeen the routers. These technologies can 2.1.1.3 Provider Backbone
Bridging (PBB)
operate over any physical topology: mesh, partial mesh, tree or set of rings.
2.1.1.4 Provider Backbone
Bridging - Traffic Engineering
From the point of view of Carrier Ethernet, the fundamentals of VPWS, VPLS
(PBB-TE)
and MPLS TP are similar. LERs (PEs) at the network edges and LSRs (PEs) in
the core. 2.1.2 MPLS based

2.1.2.1 VPWS

2.1.2.2 VPLS

2.1.2.3 MPLS-TP

2.1.3 Transparent Transport

2.1.3.1 SONET/SDH

2.1.3.2 OTN

2.1.3.3 WDM

2.2 Protection and Resiliency

Download PDF
Download a pdf for
offline viewing.

Reference Documents

IEEE 802.1Q-2009

IEEE 802.1ad-2005

IEEE 802.1ah

IEEE 802.1Qay

ITU-T G.8031

ITU-T G.8032

ITU-T Y.1415

RFC 4448

RFC 4761

RFC 5921

RFC 5960

MEF-CECP Test Objectives

2 Transporting Carrier Ethernet


Services

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Services over Transport In this Section


Technologies 2 Carrier Ethernet Services over
Transport Technologies
Study Guide Section 2.1.2.1 2.1 Transport Technologies

Virtual Private Wire Service (VPWS) 2.1.1 IEEE-based transport


technologies
VPWS (Virtual Private Wire Service) is the simplest form of enabling Ethernet 2.1.1.1 Bridging
services over MPLS. It is also known as ETHoMPLS (Ethernet over MPLS), or VLL
2.1.1.2 Provider Bridging (PB)
(Virtual Leased Line)
2.1.1.3 Provider Backbone
VPWS comprises point-to-point LSPs that carry Ethernet PWs (pseudowires) Bridging (PBB)

between LERs (Label Edge Routers). These LERs or PEs (Provider Equipment) 2.1.1.4 Provider Backbone
Bridging - Traffic Engineering
in Carrier Ethernet terminology provide the UNI-N functionality. In such a
(PBB-TE)
case, the CEN (Carrier Ethernet Network) provides Ethernet services to CEs
(Customer Equipment) attached to the PEs. 2.1.2 MPLS based

In other deployments, the network is a CEN where some external interfaces 2.1.2.1 VPWS
are ENNIs. In such a case, the PW is between the ENNI-N and a UNI-N or 2.1.2.2 VPLS
between two ENNI-Ns. 2.1.2.3 MPLS-TP

The objective is to create virtual connections between PEs with pseudowires


2.1.3 Transparent Transport
and to transport the Ethernet services over these pseudowires.
2.1.3.1 SONET/SDH
The entire Ethernet frame (excluding FCS) is carried over the MPLS/PW. 2.1.3.2 OTN
Therefore, no MAC learning is required.
2.1.3.3 WDM

Forwarding of Ethernet frames within the MPLS network is performed using


MPLS labels. The setting of the labels and path selection is outside the scope
2.2 Protection and Resiliency
of this explanation.

Multiple PWs can be carried over a single LSP, and each PW can be configured Download PDF
to carry either one CoS (Class of Service) or multiple CoSs. Up to a maximum
of 8 CoSs can be carried over a given PW.
Download a pdf for
The following figure illustrates how a C-TAG frame sent from the CE is offline viewing.

encapsulated over MPLS PW:

Reference Documents

IEEE 802.1Q-2009

IEEE 802.1ad-2005

IEEE 802.1ah

IEEE 802.1Qay

ITU-T G.8031

ITU-T G.8032
2.1.2.1.F1 - VPWS
ITU-T Y.1415

RFC 4448
The tunnel label (LSP label) is a 20-bit field, yielding over 16 million unique
RFC 4761
labels over a link. Each LSP can carry one or more EVCs (Ethernet Virtual
Connection) or OVC (Operator Virtual Connection). Since an EVC or an OVC RFC 5921
can be mapped to a single PW or to multiple PWs, theoretically 16 million RFC 5960
EVCs and/or OVCs can be carried over a single LSP. This implies that an
almost unlimited number of Carrier Ethernet services can be implemented MEF-CECP Test Objectives
over a single VPWS.
2 Transporting Carrier Ethernet
Services
The MPLS network has a 3-bit CoS ID identifier called the EXP bits (also known
as the Traffic Class field in later RFCs). The EXP bits are used for CoS ID and
Send Feedback
color forwarding where applicable.

Up to eight CoSs can be delivered over MPLS LSPs. However, assuming that Name:
some CoSs need to also denote color, the effective number is five CoSs. MPLS
Email:
networks can support the 3-CoS model of MEF 23.
Comments
The ingress LER can tunnel almost any frame over a PW, with the exception of
PAUSE frames. It can support CE-VLAN ID and CE-VLAN CoS preservation.
Interworking with customer spanning tree is also specified. This means that
EPL and EVPL services can be provided over VPWS with transparent handling
Send Feedback
of L2CPs.

Multicast is not part of this transport technology. In the event that multicast
support is required, VPLS can be used (see next section).

Resiliency is provided by MPLS LSP and MPLS PW redundancy. This can be


based on G.8031 linear protection or MPLS FRR. Both of these techniques can
provide sub-50 msec protection. These resiliency capabilities can be
configured to provide transparent resiliency to the Ethernet service layer. This
is as a result of the fact that the protection mechanism changes the path
between the two PEs transparently to the Ethernet layer.

Support for the various Ethernet services is summarized in the following table:
2.1.2.1.T1 - VPWS Support for Carrier Ethernet Services

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Services over Transport In this Section


Technologies 2 Carrier Ethernet Services over
Transport Technologies
Study Guide Section 2.1.2.2 2.1 Transport Technologies

Virtual Private LAN Service (VPLS) 2.1.1 IEEE-based transport


technologies

2.1.1.1 Bridging

2.1.1.2 Provider Bridging (PB)

2.1.1.3 Provider Backbone


Bridging (PBB)

2.1.1.4 Provider Backbone


Bridging - Traffic Engineering
(PBB-TE)
2.1.2.1.F1 - VPLS

Resiliency is also provided by the MPLS LSP and PW layers which can be 2.1.2 MPLS based
considered to be independent of the VPLS service instance. Services are 2.1.2.1 VPWS
denoted in the same manner as for VPWS, as is CoS ID. 2.1.2.2 VPLS

2.1.2.3 MPLS-TP
Each PE includes a logical element called a VSI (Virtual Switch Instance). The
VSI emulates an IEEE 802.1Q Bridge. In other words, the VSI handles C-TAG 2.1.3 Transparent Transport

frames, learns the customer MAC addresses and makes the forwarding 2.1.3.1 SONET/SDH
decision. Once a destination or set of destinations is determined, the 2.1.3.2 OTN
appropriate frame is encapsulated with the tunnel and PW headers. When
2.1.3.3 WDM
there is a need to multicast or broadcast, the ingress PE replicates the frames
and sends a copy to each egress PE. In this manner, the service "virtually
bridges" the customer end-points, simulating a private LAN. 2.2 Protection and Resiliency

Download PDF
Multiple VPLS instances - one per service or L2VPN - can use the same
network infrastructure.
Download a pdf for
offline viewing.
VPLS provides support for all 6 MEF-defined Carrier Ethernet service types.
The L2CP handling capabilities are virtually the same as for provider bridging,
as both incorporate a bridge component that handles customer C-TAG frames.
Reference Documents

The CEN (Carrier Ethernet Network) does not use xSTP (variants of Spanning IEEE 802.1Q-2009
Tree Protocol) for forwarding or resiliency. The Customer xSTP is not tunneled
IEEE 802.1ad-2005
across the VPLS-based CEN.
IEEE 802.1ah

IEEE 802.1Qay
E-Tree is naturally supported by VPLS. The concept of hub (root) and spoke
ITU-T G.8031
(leaf) is also part of the VPLS standard.
ITU-T G.8032

ITU-T Y.1415
Support for the various Ethernet services is summarized in the following table:
RFC 4448

RFC 4761

RFC 5921

RFC 5960

MEF-CECP Test Objectives

2 Transporting Carrier Ethernet


Services

Send Feedback

Name:

Email:

Comments

Send Feedback

2.1.2.2.T1 - VPLS Support for Carrier Ethernet Services

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Services over Transport In this Section


Technologies 2 Carrier Ethernet Services over
Transport Technologies
Study Guide Section 2.1.2.3 2.1 Transport Technologies

MPLS-TP 2.1.1 IEEE-based transport


technologies
MPLS-TP (MPLS Transport Profile) is jointly specified by the IETF and the ITU- 2.1.1.1 Bridging
T. It is designed to be a sub-set of the MPLS framework that provides
2.1.1.2 Provider Bridging (PB)
connection-oriented services better suited to transport networks.
2.1.1.3 Provider Backbone
Bridging (PBB)

MPLS-TP uses the same packet format as MPLS, as well as uses LSPs (Label 2.1.1.4 Provider Backbone
Bridging - Traffic Engineering
Switched Paths) and PWs (pseudowires)
(PBB-TE)

2.1.2 MPLS based


The MPLS-TP path is configured by the management system, but can
optionally be determined and provisioned by the GMPLS control plane. MPLS- 2.1.2.1 VPWS
TP supports active and backup paths, providing linear protection with sub-50 2.1.2.2 VPLS
msec recovery. The concept of pre-defined active and backup paths facilitates 2.1.2.3 MPLS-TP
traffic engineering and enables guaranteed bandwidth across the CEN (Carrier
Ethernet Network) 2.1.3 Transparent Transport

2.1.3.1 SONET/SDH
MPLS-TP also provides extensive OAM support, including Y.1731 FM (Fault
Management) and PM (Performance Management). Unlike MPLS, MPLS-TP does 2.1.3.2 OTN
not use IP routing, so MPLS-TP CENs can be purely layer 2 networks. 2.1.3.3 WDM

MPLS supports point-to-point LSPs and also point-to-multipoint LSPs. Unlike 2.2 Protection and Resiliency
MPLS, the forward and reverse directions of traffic are carried over the same
network path at all times. Download PDF
E-LANs and E-Trees can be implemented by running VPLS over MPLS-TP based Download a pdf for
LSPs and PWs. offline viewing.

Due to the fact that MPLS-TP uses the same frame format as MPLS, the
scalability of services and CoS identification is the same. Refer to MPLS over Reference Documents
VPWS for more details.
IEEE 802.1Q-2009
EPL services can be provided over MPLS-TP with transparent handling of L2CPs
IEEE 802.1ad-2005
in a similar fashion to that supported by VPWS.
IEEE 802.1ah

Support for the various Ethernet services is summarized in the following table: IEEE 802.1Qay

ITU-T G.8031

ITU-T G.8032

ITU-T Y.1415

RFC 4448

RFC 4761

RFC 5921

RFC 5960

MEF-CECP Test Objectives

2 Transporting Carrier Ethernet


Services

Send Feedback

Name:

Email:

Comments

2.1.2.3.T1 - MPLS-TP Support for Carrier Ethernet Services


Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Services over Transport In this Section


Technologies 2 Carrier Ethernet Services over
Transport Technologies
Study Guide Section 2.1.3 2.1 Transport Technologies

Transparent Transport Technologies 2.1.1 IEEE-based transport


technologies
Carrier Ethernet E-Line services can be delivered transparently over networks 2.1.1.1 Bridging
based on SONET/SDH, OTN or WDM as explained in the following sections.
2.1.1.2 Provider Bridging (PB)
2.1.1.3 Provider Backbone
Bridging (PBB)

2.1.1.4 Provider Backbone


Bridging - Traffic Engineering
(PBB-TE)

2.1.2 MPLS based

2.1.2.1 VPWS

2.1.2.2 VPLS

2.1.2.3 MPLS-TP

2.1.3 Transparent Transport

2.1.3.1 SONET/SDH

2.1.3.2 OTN

2.1.3.3 WDM

2.2 Protection and Resiliency

Download PDF
Download a pdf for
offline viewing.

Reference Documents

IEEE 802.1Q-2009

IEEE 802.1ad-2005

IEEE 802.1ah

IEEE 802.1Qay

ITU-T G.8031

ITU-T G.8032

ITU-T Y.1415

RFC 4448

RFC 4761

RFC 5921

RFC 5960

MEF-CECP Test Objectives

2 Transporting Carrier Ethernet


Services

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Services over Transport In this Section


Technologies 2 Carrier Ethernet Services over
Transport Technologies
Study Guide Section 2.1.3.1 2.1 Transport Technologies

SONET/SDH 2.1.1 IEEE-based transport


technologies
Carrier Ethernet E-Line services can be delivered over SONET and SDH. SONET 2.1.1.1 Bridging
and SDH are widely deployed technologies in transport networks. They are
2.1.1.2 Provider Bridging (PB)
typically based on ring topologies. Each ring can operate at several rates, up
to a maximum of 10 Gbps. 2.1.1.3 Provider Backbone
Bridging (PBB)
An example of the network architecture is illustrated below:
2.1.1.4 Provider Backbone
Bridging - Traffic Engineering
(PBB-TE)

2.1.2 MPLS based

2.1.2.1 VPWS

2.1.2.2 VPLS

2.1.2.3 MPLS-TP

2.1.3 Transparent Transport

2.1.3.1 SONET/SDH

2.1.3.2 OTN

2.1.3.3 WDM

2.2 Protection and Resiliency

2.1.3.1.F1 - Network Architecture


Download PDF
Ethernet over SONET/SDH is used to deliver Carrier Ethernet E-Lines over
SONET and SDH. Ethernet over SONET/SDH refers to encapsulation of Ethernet
frames in a specific container which has pre-determined rate. There are Download a pdf for
offline viewing.
several means for encapsulating asynchronous Ethernet traffic in a
synchronous transport like SONET or SDH. With SONET/SDH, the end-to-end
(UNI to UNI) connection is known as the path , and the Subscriber data that
flows from end-to-end is known as the path data.
Reference Documents
Encapsulation of an Ethernet frame inside GFP-F frame is illustrated below:
IEEE 802.1Q-2009

IEEE 802.1ad-2005

IEEE 802.1ah

IEEE 802.1Qay

ITU-T G.8031

ITU-T G.8032

ITU-T Y.1415
2.1.3.1.F2 - Encapsulation of an Ethernet frame inside GFP-F frame RFC 4448

All of the encapsulation techniques (e.g. GFP, POS) are not aware of the RFC 4761
Ethernet frame structure. This means that any L2CP frame can be tunneled RFC 5921
through a SONET/SDH-based E-Line service. Also, no MAC learning, forwarding
RFC 5960
or filtering is performed by these network elements.

MEF-CECP Test Objectives


Each incoming service is transported transparently over the CEN (Carrier 2 Transporting Carrier Ethernet
Ethernet Network). Each service is carried in its own container with no Services
bandwidth sharing or contention amongst containers. Likewise, each service
requires a dedicated port on the ADM. For example, if a single CE sends traffic Send Feedback
for two different EVCs across a service multiplexed UNI, two different ports
on the ADM will be needed in order for the traffic to be mapped to distinct Name:
containers. This can be done by the ADM (Add/Drop Multiplexing) function of
SONET/SDH network element. Email:

Comments

Each SONET/SDH link can support several EVCs. However, the number of
services that can be supported is limited due to the static bandwidth
allocation mechanism of SONET/SDH. Each such SONET/SDH path has no CoS
Send Feedback
awareness or VLAN tag awareness.

Note: Throughout this text, the term "awareness" is used to describe a


network's ability to identify, interpret and act upon specific information
contained within datagrams. For example, VLAN-aware means that a network
may read, manipulate or make forwarding decisions based on VLAN tags.
Conversely, the term "unaware" means that a network does not have the
capability to identify, interpret or act upon specific information contained
within datagrams.

SONET/SDH technology is suitable only for E-Line services. It can provide some
sort of service multiplexing using external ADM device for delivering EVPLs.
Resiliency is inherently supported by this transport network, which provides
sub-50 msec service restoration that is transparent to the Ethernet layer.

Support for the various Ethernet services is summarized in the following table:

2.1.3.1.T1 - SONET/SDH Support for Carrier Ethernet Services

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Services over Transport In this Section


Technologies 2 Carrier Ethernet Services over
Transport Technologies
Study Guide Section 2.1.3.2 2.1 Transport Technologies

Optical Transport Network (OTN) 2.1.1 IEEE-based transport


technologies
E-Line services can be delivered over Optical Transport Networks (OTN) using 2.1.1.1 Bridging
Ethernet over OTN as specified by the ITU-T G.709 Recommendation. OTN is a
2.1.1.2 Provider Bridging (PB)
standard method for transparent transport of services over optical
wavelengths in WDM systems. OTN is often regarded as a next generation 2.1.1.3 Provider Backbone
Bridging (PBB)
SONET/SDH technology that supports 10, 40 and 100 Gbps transport links.
2.1.1.4 Provider Backbone
Transport of Ethernet frames over OTN is highly transparent. Bridging - Traffic Engineering
(PBB-TE)
In essence, Ethernet over OTN requires the mapping of ingress frames at a UNI
(ingress port) to a specific container called an Optical Channel Data Unit 2.1.2 MPLS based
(ODU). For example, the most appropriate OTN container for Carrier Ethernet
2.1.2.1 VPWS
services at the UNI is ODU0, which supports the transport of a 1000BASE-X
2.1.2.2 VPLS
signal mapped to the container using Generic Framing Procedure (GFP). This is
a scalable solution for delivering high bandwidth EPL Services. 2.1.2.3 MPLS-TP

Ethernet over OTN provides the same resiliency as SONET/SDH but with more 2.1.3 Transparent Transport
flexible bandwidth allocation. It is fully transparent to the Ethernet frame, 2.1.3.1 SONET/SDH
meaning any L2CP frame can be tunneled over the OTN-based network. No
2.1.3.2 OTN
MAC learning, forwarding or filtering is performed.
Support for EVPL is limited and requires specific mapping and depends on the 2.1.3.3 WDM

topology.

2.2 Protection and Resiliency


VLANs and CoS are not supported.

Support for the various Ethernet services is summarized in the following table: Download PDF
Download a pdf for
offline viewing.

Reference Documents

IEEE 802.1Q-2009

IEEE 802.1ad-2005

IEEE 802.1ah

IEEE 802.1Qay

ITU-T G.8031

ITU-T G.8032

ITU-T Y.1415

RFC 4448

RFC 4761

RFC 5921

RFC 5960

2.1.3.2.T1 - OTN Support for Carrier Ethernet Services MEF-CECP Test Objectives
2 Transporting Carrier Ethernet
Services

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Services over Transport In this Section


Technologies 2 Carrier Ethernet Services over
Transport Technologies
Study Guide Section 2.1.3.3 2.1 Transport Technologies

WDM 2.1.1 IEEE-based transport


technologies
Carrier Ethernet E-Line services can be delivered over Wave Division 2.1.1.1 Bridging
Multiplexed (WDM) networks using Ethernet over WDM technology. Both these
2.1.1.2 Provider Bridging (PB)
physical layer transport technologies carry packetized digital traffic (i.e.,
Ethernet frames) over photonic channels. DWDM and CWDM technologies can 2.1.1.3 Provider Backbone
Bridging (PBB)
be used to provide very high bandwidth connections in the order of hundreds
2.1.1.4 Provider Backbone
of Gbps over distances ranging up to 80km (50 miles) without repeaters. Bridging - Traffic Engineering
However, when WDM is used to deliver Carrier Ethernet services, it supports (PBB-TE)
point-to-point topologies only.
2.1.2 MPLS based
Incoming traffic is mapped by a multiplexer to a specific optical channel.
2.1.2.1 VPWS
Mapping is agnostic to the content and header of the Ethernet frame and
2.1.2.2 VPLS
therefore provides a very transparent point-to-point service.
2.1.2.3 MPLS-TP
This is illustrated in the following figure:
2.1.3 Transparent Transport

2.1.3.1 SONET/SDH

2.1.3.2 OTN

2.1.3.3 WDM
2.1.3.3.F1 - WDM

The WDMs cannot decipher the CoS Identifier and VLAN tag information 2.2 Protection and Resiliency
contained within an Ethernet frame, so all Ethernet frames associated with a
particular service are transported by the same photonic channel. Only physical Download PDF
layer failures can be detected and acted upon with this technology, and
recovery is performed without intervention from the Ethernet MAC layer.
Download a pdf for
offline viewing.

Reference Documents

IEEE 802.1Q-2009

IEEE 802.1ad-2005

IEEE 802.1ah

IEEE 802.1Qay

ITU-T G.8031

ITU-T G.8032

ITU-T Y.1415

RFC 4448

RFC 4761

RFC 5921

RFC 5960

MEF-CECP Test Objectives

2.1.3.3.T1 - WDM Support for Carrier Ethernet Services 2 Transporting Carrier Ethernet
Services

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

IEEE 802.1Q-2005
Virtual LANs (VLAN)

The 802.1Q-2005 standard developed by IEEE is a useful reference for understanding the topic of Virtual LANs (VLAN) in
the context of Carrier Ethernet networks. The standards document is not available directly from the MEF but may be
obtained from IEEE.

Other relevant links for VLANs can be found at the Wikipedia page on the topic.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

IEEE 802.1ad-2005
Provider Bridges

The 802.1ad-2005 standard developed by IEEE is a useful reference for understanding how Carrier Ethernet services can be
transported over Provider Bridge networks. The standards document is not available directly from the MEF but may be
obtained directly from IEEE.

Other relevant links for Provider Bridges can be found at the Wikipedia page on the topic.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

IEEE 802.1ah-2008
Provider Backbone Bridges

The 802.1ah-2008 standard developed by IEEE is a useful reference for understanding how Carrier Ethernet services can be
transported over Provider Backbone Bridge networks. The standards document is not available directly from the MEF but
may be obtained from the IEEE.

Other relevant links for Provider Backbone Bridges can be found at the Wikipedia page on the topic.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

IEEE 802.1Qay
Provider Backbone Bridging - Traffic Engineering (PBB-TE)

The 802.1Qay standard developed by IEEE is a useful reference for understanding how Carrier Ethernet services can be
transported over PBB-TE networks. The standards document is not available directly from the MEF but may be obtained
directly from IEEE.

Other relevant links for PBB-TEs can be found at the Wikipedia page on the topic.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

ITU-T G.8031
Ethernet Protection Switching

The G.8031 recommendation developed by ITU-T is a useful reference for understanding Ethernet Protection Switching in
the context of Carrier Ethernet networks. The document can be downloaded here.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

ITU-T G.8032
Ethernet Ring Protection Switching

The G.8032 recommendation developed by ITU-T is a useful reference for understanding Ethernet Ring Protection
Switching in the context of Carrier Ethernet networks. The document can be downloaded here.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

ITU-T Y.1415
Ethernet-MPLS Interworking

The Y.1415 recommendation developed by ITU-T is a useful reference for understanding Ethernet interworking with MPLS
in the context of Carrier Ethernet networks. The document can be downloaded here.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

IETF RFC 4448


Encapsulation Methods for Transport of Ethernet over MPLS Network

This IETF Request For Comments (RFC) provides useful background information on the transport of Carrier Ethernet
services over MPLS networks.

Abstract:

" An Ethernet pseudowire (PW) is used to carry Ethernet/802.3 Protocol Data Units (PDUs) over an MPLS network. This
enables service providers to offer "emulated" Ethernet services over existing MPLS networks. This document specifies the
encapsulation of Ethernet/802.3 PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a
"point-to-point Ethernet" service."

More links relating to Ethernet pseudowires over MPLS can be found at the Wikipedia page on this topic.
Document download

Wikipedia

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

IETF RFC 4761


Virtual Private LAN Service (VPLS) Using BGP
for Auto-Discovery and Signaling

This IETF Request For Comments (RFC) provides useful background information on the transport of Carrier Ethernet
services over VPLS networks.

Abstract:

"Virtual Private LAN Service (VPLS), also known as Transparent LAN Service and Virtual Private Switched Network service,
is a useful Service Provider offering. The service offers a Layer 2 Virtual Private Network (VPN); however, in the case of
VPLS, the customers in the VPN are connected by a multipoint Ethernet LAN, in contrast to the usual Layer 2 VPNs, which
are point-to-point in nature. This document describes the functions required to offer VPLS, a mechanism for signaling a
VPLS, and rules for forwarding VPLS frames across a packet switched network."
More links relating to VPLS can be found at the Wikipedia page on this topic.

Document download

Wikipedia

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

IETF RFC 5921


A Framework for MPLS in Transport Networks

This IETF Request For Comments (RFC) provides useful background information on the transport of Carrier Ethernet
services over MPLS-TP networks.

Abstract:

"This document specifies an architectural framework for the application of Multiprotocol Label Switching (MPLS) to the
construction of packet-switched transport networks. It describes a common set of protocol functions -- the MPLS
Transport Profile (MPLS- TP) -- that supports the operational models and capabilities typical of such networks, including
signaled or explicitly provisioned bidirectional connection-oriented paths, protection and restoration mechanisms,
comprehensive Operations, Administration, and Maintenance (OAM) functions, and network operation in the absence of a
dynamic control plane or IP forwarding support. Some of these functions are defined in existing MPLS specifications,
while others require extensions to existing specifications to meet the requirements of the MPLS-TP. This document
defines the subset of the MPLS-TP applicable in general and to point-to-point transport paths. The remaining subset,
applicable specifically to point-to-multipoint transport paths, is outside the scope of this document. This document is a
product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication
Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire
Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport
network as defined by the ITU-T."

More links relating to MPLS-TP can be found at the Wikipedia page on this topic.

Document download

Wikipedia

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

IETF RFC 5960


MPLS Transport Profile Data Plane Architecture

This IETF Request For Comments (RFC) provides useful background information on the transport of Carrier Ethernet
services over MPLS networks.

Abstract:

"The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the
construction and operation of packet-switched transport networks. This document specifies the subset of these functions
that comprises the MPLS-TP data plane: the architectural layer concerned with the encapsulation and forwarding of
packets within an MPLS-TP network. This document is a product of a joint Internet Engineering Task Force (IETF) /
International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS
Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the
capabilities and functionalities of a packet transport network.."

More links relating to MPLS-TP can be found at the Wikipedia page on this topic.

Document download

Wikipedia

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Test Objectives 2 1 In this Section


Transporting Carrier Ethernet Services 2 Carrier Ethernet Services over
Transport Technologies
2.1 Describe the connectivity properties of bridging, provider bridging,
provider backbone bridging (PBB), provider backbone bridging with traffic 2.1 Transport Technologies

engineering extensions (PBB-TE), Ethernet over SONET/SDH, Carrier Ethernet 2.1.1 IEEE-based transport
technologies
over MPLS VPWS, Carrier Ethernet over MPLS VPLS, Carrier Ethernet over MPLS
TP, Carrier Ethernet over OTN, and Carrier Ethernet over WDM. 2.1.1.1 Bridging

2.1.1.2 Provider Bridging (PB)


2.2 Describe the capabilities of bridging, provider bridging, provider backbone
2.1.1.3 Provider Backbone
bridging (PBB), provider backbone bridging with traffic engineering extensions Bridging (PBB)
(PBB-TE), SONET/SDH, MPLS VPWS, MPLS VPLS, MPLS TP, OTN and WDM with
2.1.1.4 Provider Backbone
regards to delivery of Carrier Ethernet services. Bridging - Traffic Engineering
(PBB-TE)
2.3 Deleted
2.1.2 MPLS based
2.4 Describe the advantages of specific Carrier Ethernet transport
2.1.2.1 VPWS
technologies.
2.1.2.2 VPLS
2.5 Describe service protection mechanisms.
2.1.2.3 MPLS-TP

2.1.3 Transparent Transport

2.1.3.1 SONET/SDH

2.1.3.2 OTN

2.1.3.3 WDM

2.2 Protection and Resiliency

Download PDF
Download a pdf for
offline viewing.

Reference Documents

IEEE 802.1Q-2009

IEEE 802.1ad-2005

IEEE 802.1ah

IEEE 802.1Qay

ITU-T G.8031

ITU-T G.8032

ITU-T Y.1415

RFC 4448

RFC 4761

RFC 5921

RFC 5960

MEF-CECP Test Objectives

2 Transporting Carrier Ethernet


Services

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Services over Access In this Section


Technologies 3 Carrier Ethernet Services over
Access Technologies
Study Guide Section 3.1 3.1 Access Infrastructures

Access Infrastructures 3.1.1 HFC (DOCSIS)

3.1.2 PON
Carrier Ethernet services are designed to be delivered over all the commonly
available packet access infrastructures deployed today including: 3.1.3 Packet Radio

3.1.4 PDH
HFC (DOCSIS)
3.1.5 Fiber
PON
Packet Radio 3.1.6 Bonded Copper

PDH (T1/E1/T3/E3) 3.2 Comparisons


Dark and active fiber 3.3 Examples
Bonded copper
Download PDF
This section explains the considerations to be taken into account when using
different access infrastructures for the implementation of Carrier Ethernet
services.
Download a pdf for
offline viewing.
The range of access technologies supporting Carrier Ethernet services are
depicted in the following figure:

Reference Documents

MEF Reference Presentation: Access


Technologies

MEF White Paper: Access


Technologies
3.1.F1 - Carrier Ethernet Services over Access Infrastructures
IEEE 802.3

IEEE 802.16

MEF-CECP Test Objectives

3 Carrier Ethernet Access


Technologies

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Services over Access In this Section


Technologies 3 Carrier Ethernet Services over
Access Technologies
Study Guide Section 3.1.1 3.1 Access Infrastructures

Carrier Ethernet over HFC (DOCSIS) 3.1.1 HFC (DOCSIS)

3.1.2 PON
Reach, Rates and Triple Play
3.1.3 Packet Radio
Hybrid fiber-coaxial (HFC) is an industry term for a broadband network which
3.1.4 PDH
combines optical fiber and coaxial cable. It has been commonly employed by
3.1.5 Fiber
MSO/cable TV operators since the early 1990s.
3.1.6 Bonded Copper
The fiber optic network extends from the cable operators' master/regional 3.2 Comparisons
head-end, to a neighborhoods hub site, and finally to a fiber optic node
3.3 Examples
which serves anywhere from 25 to 2,000 homes. A master head-end will
usually have satellite dishes for reception of distant video signals as well as IP
Download PDF
aggregation routers. Some master head-ends also house telephony equipment
for providing telecommunications services to the community.

By using frequency division multiplexing, an HFC network may carry a variety Download a pdf for
offline viewing.
of services, including analog TV, digital TV (standard definition and HDTV),
VoD, telephony, and high-speed data.

Data over Cable Service Interface Specification (DOCSIS) is an international


Reference Documents
standard developed by CableLabs and contributing companies. DOCSIS defines
the communications and operation support interface requirements for a data
MEF Reference Presentation: Access
over cable system. DOCSIS 1.0, 1,1 and 2.0 all utilize a single upstream and a Technologies
single downstream channel, while the DOCSIS 3.0 standard allows for channel
MEF White Paper: Access
bonding, and hence higher throughput rates. DOCSIS 3.0 allows for a peak Technologies
downstream rate of approximately 350 Mbps and a peak upstream rate of IEEE 802.3
approximately 125 Mbps.
IEEE 802.16

MEF-CECP Test Objectives

3 Carrier Ethernet Access


Technologies

Send Feedback
3.1.1.F1 - Carrier Ethernet and HFC


Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Services over Access In this Section


Technologies 3 Carrier Ethernet Services over
Access Technologies
Study Guide Section 3.1.2 3.1 Access Infrastructures

Carrier Ethernet over PON 3.1.1 HFC (DOCSIS)

3.1.2 PON
Reach, Rates and Triple Play
3.1.3 Packet Radio
Passive Optical Networking (xPON) is a point-to-multipoint optical access
3.1.4 PDH
architecture that facilitates broadband communications between an optical
3.1.5 Fiber
line terminal (OLT) at the central office and multiple remote optical network
units (ONUs) over a purely passive optical-distribution network with a reach of 3.1.6 Bonded Copper

approximately 40 km (25 miles). PON supports from 1 to 128 users per single 3.2 Comparisons
strand of fiber. 3.3 Examples

PON is a cost-effective access method because it conserves fiber for service


Download PDF
providers offering high bandwidth business and residential access applications,
green field deployments, mobile backhaul and any upgrade from twisted pair
or coaxial copper networks. PON typically provides asymmetric bandwidth,
Download a pdf for
with total downstream bandwidth reaching 10 Gbps (statistically shared offline viewing.
between all ONUs). The Ethernet Passive Optical Network (EPON) standard was
developed by the IEEE and the Gigabit Passive Optical Network (GPON) by the
ITU-T. EPON supports symmetrical 1 Gbps communications. GPON provides
1.25 Gbps upstream and 2.5 Gbps downstream. Ethernet services are Reference Documents
supported on both platforms. Standards are also underway at CableLabs for
translation of DOCSIS management commands into Ethernet formats to MEF Reference Presentation: Access
Technologies
manage EPON fiber access equipment. An upgrade path to 10 Gbps exists for
both PON types with work being done by the IEEE and ITU-T. MEF White Paper: Access
Technologies

IEEE 802.3
IEEE 802.16

MEF-CECP Test Objectives

3 Carrier Ethernet Access


Technologies
3.1.2.F1 - Carrier Ethernet Services over PON Infrastructures

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Services over Access In this Section


Technologies 3 Carrier Ethernet Services over
Access Technologies
Study Guide Section 3.1.3 3.1 Access Infrastructures

Carrier Ethernet over Packet Radio 3.1.1 HFC (DOCSIS)

3.1.2 PON
Reach, rates, licensed and unlicensed
3.1.3 Packet Radio
Where wireline services are not available or practical, delivering Ethernet
3.1.4 PDH
over a point-to-point wireless access network can make a previously
3.1.5 Fiber
unattainable connection practical. Also, where mobility is required, broadband
wireless services from mobile service providers may provide an effective 3.1.6 Bonded Copper

connectivity option. 3.2 Comparisons

3.3 Examples
Terrestrial Microwave

A microwave link uses microwave frequencies (above 1 GHz) for line of sight Download PDF
radio communications (32 to 48 KM, 20 to 30 miles) between two directional
antennas. This is also known as point-to-point (PtP) Microwave. Microwave
link transceivers are now available with standard Ethernet interfaces that can Download a pdf for
offline viewing.
be used to deliver Carrier Ethernet services. The distance and throughput that
can be achieved is a function of frequency and antenna size. For example,
100 Mbps Fast Ethernet can be achieved reliably over 13 KM (8 miles) at 11
GHz but will perform poorly over 24 KM (15 miles) due to rain fade at that Reference Documents
frequency. 100 Mbps Fast Ethernet can be achieved reliably up to 48 KM (30
miles) at 6 GHz. MEF Reference Presentation: Access
Technologies
The use of microwave links avoids the need to install cables between
MEF White Paper: Access
communication equipment. Microwave links may be set up over licensed Technologies
frequencies (filed and protected by government agencies) or over unlicensed IEEE 802.3
frequencies (through the use of low power within unlicensed regulatory limits)
IEEE 802.16
Broadband Wireless
MEF-CECP Test Objectives
EVDO (Evolution of Existing Systems for Data Only) is a commonly available
upgraded service of cellular providers with CDMA (Code Division Multiple 3 Carrier Ethernet Access
Technologies
Access) systems. EVDO Rev. A allows for a maximum data transmission rate of
approximately 3.1 Mbps on the forward (downstream) channel. The EVDO Rev.
Send Feedback
A system uses the same reverse channel which limits the uplink data
transmission rate to approximately 1.8 Mbps. The EVDO system has an
Name:
upgraded packet data transmission control system that allows for bursty data
transmission rather than for more continuous voice data transmission.
Email:
GSM (Global System for Mobile)
Comments
GSM is the most popular standard for mobile phones in the world. Its
promoter, the GSM Association, estimates that 80% of the global mobile
market uses the standard. Release '97 of the standard added packet data
capabilities, by means of General Packet Radio Service (GPRS). The latest Send Feedback

version of packet data communications are UMTS (Universal Mobile


Telecommunications System) and HSDPA/HSPA+ (High-Speed Downlink Packet
Access/ High-Speed Packet Access). These technologies enable download
speeds of up to 42 Mbps (22 Mbps in upload). One of the main advantages of
HSPA+ is its optional all-IP capability that is using native Ethernet connection
to the base station. Note that these are base station rates that are shared
amongst all active users served by a particular base station.

LTE (Long Term Evolution)

LTE is the name given to a project within the Third Generation Partnership
Project (3GPP) to improve the UMTS mobile phone standard to cope with
future technology evolutions. Goals include improving spectral efficiency,
lowering costs, improving services, making use of new spectrum and re-
farmed spectrum opportunities, and better integration with other open
standards. Being based on an all-IP infrastructure and native Ethernet
connectivity, LTE provides peak download rates of up to approximately 300
Mbps and peak upload rates of approximately 75 Mbps. Note that these are
base station rates that are shared amongst all active users served by a
particular base station.

WiMAX (Worldwide Interoperability for Microwave Access)

WiMax was created by the WiMAX Forum and is a wireless point-to-multi-point


data transmission technology that is based on the IEEE 802.16 standards. With
its latest version, 802.16e adds mobility and better support for quality of
service as well as symmetrical transmission capability of typically 40 Mbps for
fixed and 15 Mbps for mobile implementation. Peak rate of the base station
can reach 70 Mbps. As a "last mile" broadband wireless access, WiMAX can be
used in the following applications: replacement to legacy T1/E1, delivery of
triple-play services, backhaul technology for Wi-Fi hotspots and mobile
backhaul and for mobile emergency response services.
3.1.3.F1 - Carrier Ethernet over Packet Wireless

Access Technologies for Mobile Backhaul

For mobile backhaul, there are of variety of access technologies, depending


on the type of radio capability. Base stations of 2G and older 3G networks
have TDM interfaces making Ethernet over PDH (either E1/T1 or bonded
T1s/E1s) the prevailing option. 4G eNodeBs and LTE base stations have
Ethernet interfaces. For these, either fiber or PON could be the ideal option,
but since fiber is not available in all locations, some will use Point-to-Point
microwave towards an aggregation node. The choices are summarized in the
following figure:

3.1.3.F2 - Access Technologies for Carrier Ethernet Mobile Backhaul

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Services over Access In this Section


Technologies 3 Carrier Ethernet Services over
Access Technologies
Study Guide Section 3.1.4 3.1 Access Infrastructures

Carrier Ethernet over PDH 3.1.1 HFC (DOCSIS)

3.1.2 PON
An alternative to SONET/SDH nor Dark Fiber facilities are used by Service
Providers that have found that an existing PDH network - consisting of 3.1.3 Packet Radio
traditional DS1/E1, DS3 and E3 standard circuits - enable the Service Provider 3.1.4 PDH
to deliver Carrier Ethernet to locations that would otherwise be unreachable. 3.1.5 Fiber

Ethernet over Bonded T1/E1 3.1.6 Bonded Copper

3.2 Comparisons
T1 at 1.544 Mbps and E1 at 2.048 Mbps have been the dominant access
technologies for business voice and data services for decades. From their 3.3 Examples

humble beginnings as voice trunk line technologies, to their more recent


achievement as the gold standard of Internet access for small and medium- Download PDF
sized businesses, T1s and E1s have proven to be well-understood and versatile
last-mile technologies. Through the use of repeater technologies, T1/E1
facilities can be extended to practically unlimited distances from the serving Download a pdf for
offline viewing.
POP/CO.

These lines reach nearly every business in the modern world. Ethernet can be
transported over T1 and E1 as a single link or bonded group of links allowing
Reference Documents
service providers to deliver Ethernet at rates from 1 Mbps up to 16 Mbps.
Bonding brings with it the additional benefit of resiliency - a feature
MEF Reference Presentation: Access
demanded by many enterprise customers. Because there are multiple links Technologies
involved in the access method, it is inherently protected against interruptions MEF White Paper: Access
of one or more of those links (for example, a destruction of a facility by a Technologies
backhoe or an excavator). IEEE 802.3
There are three standardized methods for delivering Carrier Ethernet over IEEE 802.16

T1/E1 lines:-
MEF-CECP Test Objectives
multilink point-to-point protocol (MLPPP)
3 Carrier Ethernet Access
GFP/VCAT Technologies
G.bond or EFM
Send Feedback
While each technology has its strengths, they all deliver comparable
performance and are available from many equipment vendors.
Name:
Ethernet over DS3/E3
Email:
Just as T1/E1 is a desirable access technology for delivering Ethernet service,
DS3 and E3 circuits provide another alternative using readily available Comments
transport technology. Using DS3 and E3 circuits and circuit bonding, the
service provider can offer Carrier Ethernet services at flexible rates from 1
Mbps 130 Mbps. Ethernet over DS3/E3 is not only used as a retail service
access technology, but is often used as a low-cost infrastructure alternative Send Feedback

for backhaul between remote co-location facilities and points of presence.

3.1.4.F1 - Carrier Ethernet over DS3/E3

The following table depicts the rates that can be achieved using each variant
of Carrier Ethernet over PDH and the standards that define the bonding of
circuits:

3.1.4.T1 Summary Table for Carrier Ethernet over PDH

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Services over Access In this Section


Technologies 3 Carrier Ethernet Services over
Access Technologies
Study Guide Section 3.1.5 3.1 Access Infrastructures

Carrier Ethernet over Fiber 3.1.1 HFC (DOCSIS)

3.1.2 PON
For applications where it is available or where the bandwidth requirements
dictate it, delivering Ethernet over optical fiber is an excellent choice. With 3.1.3 Packet Radio
virtually unlimited bandwidth support, noise immunity and the ability to 3.1.4 PDH
traverse long distances, optical fiber can provide the performance for the 3.1.5 Fiber
applications of today and those envisioned for tomorrow.
3.1.6 Bonded Copper
Active Ethernet 3.2 Comparisons

One of the most common Ethernet over Fiber architectures is point-to-point, 3.3 Examples

where the connection is from the Service Providers aggregation switch to a


Network Interface Device (NID) located at the customer premises. Download PDF

Active fiber deployments are an excellent choice for service providers when
the customer is in an on-net building in a dense metropolitan area or in a new Download a pdf for
infrastructure build-out. Fiber optics as an access medium is also preferred offline viewing.

when Ethernet speeds are 1 Gbps or higher.

The capex investment in fiber optic infrastructure is a one-time investment


with minimal recurring operational cost. Fibers ability to service 100 Mbps, Reference Documents
Gigabit and 10 Gigabit data rates, as well as multiplex multiple channels using
Wavelength Division Multiplexing (WDM), enable it to support any foreseeable MEF Reference Presentation: Access
Technologies
future data rates and services.
MEF White Paper: Access
The distances that can be supported by a fiber infrastructure are limited only Technologies

by the active interface hardware. Using standard optics, 2 km-150 km (1.25 IEEE 802.3
94 mile) distances can be easily be achieved. IEEE 802.16

MEF-CECP Test Objectives

3 Carrier Ethernet Access


Technologies

Send Feedback

Name:

3.1.5.F1 Carrier Ethernet over Fiber


Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Services over Access In this Section


Technologies 3 Carrier Ethernet Services over
Access Technologies
Study Guide Section 3.1.6 3.1 Access Infrastructures

Carrier Ethernet over Bonded Copper 3.1.1 HFC (DOCSIS)

3.1.2 PON
Ethernet in the First Mile over Copper (EFMCu) allows fast deployment of
resilient symmetrical Ethernet Access/Backhaul links over existing voice-grade 3.1.3 Packet Radio
copper infrastructure, providing a very economical alternative to fiber. There 3.1.4 PDH
are two standardized EFMCu technologies: 3.1.5 Fiber

Long reach 2BASE-TL, delivering a minimum of 2 Mbit/s and a 3.1.6 Bonded Copper

maximum of 5.69 Mbit/s over distances of at least 2700 m, using 3.2 Comparisons
standard G.SHDSL.bis technology over a single copper pair. This 3.3 Examples
bandwidth is symmetrical.
Short reach 10PASS-TS, delivering a minimum of 10 Mbit/s over Download PDF
distances of at least 750 m (2460 ft), using VDSL technology over a
single copper pair. This bandwidth is asymmetrical, where uplink
bandwidth is around 1-2 Mbps. Download a pdf for
offline viewing.
Extensions to these standard technologies developed by some equipment
vendors have enabled Service Providers to improve on the rate/reach curves
provided by standard implementations.
Reference Documents
Both EFMCu technologies support an optional aggregation or bonding of
multiple copper pairs (up to 32), providing higher bandwidth, longer reach MEF Reference Presentation: Access
and improved resiliency. The aggregate bandwidth, in excess of 100 Mbps, for Technologies
downlink traffic, offered by copper bonding solutions meet the needs of most MEF White Paper: Access
bandwidth-intensive Carrier Ethernet applications. Technologies

IEEE 802.3
IEEE 802.16

MEF-CECP Test Objectives

3 Carrier Ethernet Access


Technologies

Send Feedback

Name:

3.1.6.F1 Carrier Ethernet over Bonded Copper


Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Services over Access In this Section


Technologies 3 Carrier Ethernet Services over
Access Technologies
Study Guide Section 3.2 3.1 Access Infrastructures

Comparisons 3.1.1 HFC (DOCSIS)

3.1.2 PON
Benefits of HFC (DOCSIS) for Carrier Ethernet services
3.1.3 Packet Radio
HFC permits the addition of high-speed data transfer to an existing Cable TV
3.1.4 PDH
(CATV) system. It is employed by many cable television operators to provide
3.1.5 Fiber
Internet access and Business Services over their existing (HFC) infrastructure.
3.1.6 Bonded Copper
With its large coverage and available performance, HFC/DOCSIS technology is 3.2 Comparisons
a valuable asset for Cable TV/MSO providers to deliver Ethernet-based
3.3 Examples
services to the SOHO/SMB and high-speed Internet access to residential
customers.
Download PDF
Benefits of PON for Carrier Ethernet services

PONs immediate benefit is the increase in the bandwidth delivered to the Download a pdf for
residential and SME/SMB subscriber compared to legacy twisted pair offline viewing.
technologies. Other benefits of PON include:

1. Delivery of new bandwidth-intensive applicaiton


2. Significant reductions in fiber infrastructure Reference Documents
3. Large reductions in electrical cost
4. Reduced maintenance requirements MEF Reference Presentation: Access
Technologies
Benefits of PDH for Carrier Ethernet services MEF White Paper: Access
Technologies
The primary benefit that comes from using T1/E1 for delivering Carrier
IEEE 802.3
Ethernet services is that Service Providers are able to reach all of their
customer locations, regardless of geography and proximity to their facilities. IEEE 802.16
In addition, the familiarity and turnkey nature of T1/E1 circuits means
services can be turned up quickly, whether access is on-net or off-net, MEF-CECP Test Objectives
allowing the service provider to recognize revenue sooner and to decouple 3 Carrier Ethernet Access
sales efforts from the infrastructure build-outs associated with many Technologies
alternative technologies.
Send Feedback
The primary benefit of using PDH (DS3/E3) is to deliver Carrier Ethernet at
rates greater than 3 Mbps over existing transport infrastructure. Rapid service Name:
turn-up and revenue recognition are additional side benefits of this
infrastructure. Email:

Benefits of Fiber for Carrier Ethernet services Comments

One major benefit of using fiber optic access technology is its ability to
future-proof bandwidth and distance requirements. Fiber offers easy
scalability to meet and adapt to the increasing customer needs.
Send Feedback

Beyond its bandwidth capacity, fiber also offers additional benefits such as
being able to transmit over greater distances and its inherent immunity to
noise and interference.

Benefits of Bonded Copper for Carrier Ethernet services

Using the existing voice-grade copper infrastructure keeps deployment costs


to a minimum, as there is no requirement for new cabling inside or outside
the residence or business. Using the multi-pair bonding service providers can
offer high performance (10-100 Mbps) service over a reliable infrastructure
with resiliency built-in.

Ethernet over Bonded Copper can also lower recurring operational costs for
CLECs or ILECs who are operating as CLECs in out-of-region territories. Using
bonded copper, Service Providers can deliver Carrier Ethernet services over
leased dry copper, which is typically much less expensive than alternatives.

Summary and Comparison

Summary of Carrier Ethernet Access Technologies


Carrier Technology Deployment Scenarios
Ethernet Alternatives (When to use the Advantages
Access technology)
Method
- Active Ethernet - On-net buildings - - Highest bandwidth -
Ethernet - Ethernet over Greenfield - Dense Noise immunity -
over Fiber SONET/SDH - Metro area - 1Gbit/s or Security - Long reach -
Passive Optical greater bandwidth SONET/SDH leverage
Network requirements existing - Growth
potential via xWDM
- Remote branch - Leverage existing
Ethernet - Bonded T1/E1 - offices - Off-net transport - Universally
over PDH DS3/E3 and customer locations deployable - Lower
bonded DS3/E3 (out of region, type 2) CAPEX - No reach
- SMB limitations - Well
understood provisioning
- Resiliency through
bonding
- Remote branch - Ubiquitous copper
Ethernet - 2BASE-TL - offices - On-net or off- availability - Rapid
over 10PASS-TS net - SMB - Campus deployment - Low cost
Copper settings - Traffic unbundled local loop -
monitoring Resiliency through
bonding
- Terrestrial - Remote branch office - Installation requires
Wireless microwave - - Campus setting - No no trenching - Rapid
Ethernet WiMAX - fiber or copper deployment - Some
Broadband available - Mobility alternatives offer
wireless - Free required mobility
space optics -
WiFi
Hybrid - Work at home - - Extensive coverage -
Fiber Coax DOCSIS 2.x/3.x SOHO/SMB - Remote High performance
branch office options - Deep
penetration into
residential and
suburban geographies

Each technology has different rate capabilities. Note that some offer only
limited uplink bandwidth. The following table summarizes the bandwidth per
each access technology:

Access Method Speed


10 Mbps, 100 Mbps, 1 Gbps, 10 Gbps, 40 Gbps
Ethernet over Active Fiber
and above
1 Gbps with EPON 1.25 Gbps upstream & 2.5
Ethernet over PON
Gbps downstream with GPON
Ethernet over SONET/SDH 155 Mbps to 1 Gbps
Ethernet over Up to 100 Mbps with DOCSIS 3.0
HFC/DOCSIS
Minimum of 2 Mbps using G.SHDSL Minimum of
Ethernet over DSL 10 Mbps over VDSL Up to 100 Mbps
(asymmetric)
Ethernet over T1/E1 1.5/2Mbps to 16 Mbps with bonding
Ethernet over DS3/E3 34/45 Mbps to 130 Mbps with bonding
Ethernet over Packet 1 Mbps to >1Gbps
Microwave
Ethernet over WiMax <70Mbps at 50km (31 mile)

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Services over Access In this Section


Technologies 3 Carrier Ethernet Services over
Access Technologies
Study Guide Section 3.3 3.1 Access Infrastructures

Examples 3.1.1 HFC (DOCSIS)

3.1.2 PON
When investigating access technologies for a specific scenario, the following
considerations should be taken: 3.1.3 Packet Radio

3.1.4 PDH
Existance of legacy lines
3.1.5 Fiber
Availability of fiber
Required bandwidth 3.1.6 Bonded Copper

Requirement for symmetric or mainly downlink bandwidth 3.2 Comparisons


Resiliency requirements 3.3 Examples
Long or short reach
Need to support TDM circuits Download PDF

Use case 1
Download a pdf for
When planning Carrier Ethernet service for a small office/home office (SoHo) offline viewing.
that is located in a new neighborhood, it is likely that there is fiber to the
premise already available. Since this is a residential area, it is also quite
possible that HFC is in place. However, HFC has limited upload bandwidth,
which can be sufficient if the SoHo only requires access to Internet services. Reference Documents
A higher symmetrical bandwidth service would be offered via direct active
MEF Reference Presentation: Access
fiber.
Technologies

MEF White Paper: Access


Use case 2 Technologies

IEEE 802.3
A SoHo requires access to Internet services. This SoHo is located in an urban
location. It is likely that there is no fiber to the premise and digging fiber is IEEE 802.16
not feasible from a cost and time perspective. More probable options include
Ethernet over bonded copper, or wireless Internet access services through MEF-CECP Test Objectives
WiMAX or LTE technologies. 3 Carrier Ethernet Access
Technologies

Use case 3
Send Feedback
A remote farm requires services for enabling video delivery and weather
information. Since the requirement is for high bandwidth of 20 Mbps, the Name:
solution would be packet microwave which is ideal for remote locations. Such
rates would exclude 3G/CDMA access, leaving WiMax or Point-to-Point Email:
microwave as possible alternatives.
Comments
Case Study Ubiquitous Ethernet Services in Action

EnvoEnvo is an environmental science company located in North America.


They specialize in data collection and analysis. Their instruments measure
Send Feedback

hydrology, chemistry, strain, pressure, chromatography, vibration,


temperature, particulates, aerosols, and other critical variables of interest to
business, industry and government. Monitoring services are provided for
clients large and small throughout the southeast US in both urban and rural
areas. Data throughput requirements range from a few hundred kbps to
500Mbps depending on the application. They also have truck-based mobile
facilities used for temporary installations.

A ubiquitous, flexible, secure and diverse network is required to support all of


EnvoEnvo's customers. EnvoEnvo's IT Director, working with the local cable
operator in northern Florida created a network that meets his challenging
requirements. Because most of the EnvoEnvo equipment has Ethernet ports,
over time he has created a large Ethernet WAN to collect data from remote
locations.

The local cable company manages the primary network. It was able to reach
many of the customer monitoring locations with an EPON network that
supports business and residential subscribers in the region. In some cases the
MSO contracts with the local ILEC or CLEC to reach locations using bonded T1s
and SONET and in some cases mid-band Ethernet over bonded copper pairs. To
meet the needs of extremely remote off-net locations, the IT Director
created a wireless system for the mobile facilities that can be connected to
most service provider's facilities. The core regional network aggregates these
signals for transmission over the MSO fiber on dedicated CWDM wavelengths.

Sample Access Connections into EnvoEnvo's E-LAN Service


B/W Access Media Access Service Application
Technology Provider
500kbps Wireless Wifi CLEC Hydrological pressure
measurement
100Mbps Fiber Ethernet MSO Remote imaging and
chemical analysis
4Mbps Copper - EFMCu ILEC Water, air, wind,
Twisted Pair temperature
50Mbps Fiber Ethernet MSO Motion and air quality
measurement
10Mbps Fiber Ethernet MSO Motion and air quality
measurement
500kbps Wireless Broadband Wireless Hydrological pressure
Wireless Operator measurement
10Mbps Copper T1 Ethernet over ILEC Air quality measurement
Bonded T1
150Mbps Fiber Ethernet over CLEC Remote imaging and
SONET chemical analysis
2Mbps Copper - HFC/DOCSIS MSO Chemical analysis
Coaxial
500Mbps Fiber Direct Fiber MSO Remote imaging and
Ethernet chemical analysis
6Mbps Wireless Microwave MSO Solar, humidity, wind and
other
3Mbps Copper - HFC/DOCSIS MSO Chemical analysis
Coaxial

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

MEF Reference Presentation


Carrier Ethernet Access
- Extending Ethernet into the First Mile

The presentation gives comprehensive overview of how Ethernet services can be delivered over various First Mile
infrastructures including HFC, PON, wireless, PDH, Fiber and bonded copper.

Download

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

MEF White Paper


Ethernet Services and Access Technologies

Abstract:

"This MEF white paper provides an overview of the various access technologies (also referred to as first-mile or last-
mile technologies) that are used to deliver MEF-compliant Carrier Ethernet services. The goal of this white paper is to
illustrate the fact that Service Providers who wish to deliver a ubiquitous Carrier Ethernet service can and should deploy
a number of available access technologies to ensure they can reach all of their business customers locations."

Download


Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

IEEE 802.3-2005
Ethernet

The 802.3 standard developed by IEEE is a useful reference for understanding how Carrier Ethernet services can be
transported over IEEE-based networks. The standards document is not available directly from the MEF but may be
obtained from IEEE.

Other relevant links for Ethernet technology can be found at the Wikipedia page on the topic.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

IEEE 802.16
Air Interface for Fixed and Mobile Broadband Wireless Access Systems

The 802.16 standard developed by IEEE is a useful reference for understanding how Carrier Ethernet services can be
transported over wireless networks. The standards document is not available directly from the MEF but may be obtained
from the IEEE.

Other relevant links for wireless networks can be found at the Wikipedia page on the topic.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Test Objectives 3 1 In this Section


Carrier Ethernet Access Technologies 3 Carrier Ethernet Services over
Access Technologies
3.1 Describe the capabilities of Ethernet over PDH, Ethernet over bonded
copper, Ethernet over HFC, Ethernet over packet radio, Ethernet over fiber 3.1 Access Infrastructures

and Ethernet over PON. 3.1.1 HFC (DOCSIS)

3.1.2 PON
3.2 Describe the advantages of specific Carrier Ethernet Access technologies.
3.1.3 Packet Radio
3.3 Given a scenario, identify which Carrier Ethernet Access Technology will 3.1.4 PDH
meet the stated requirements.
3.1.5 Fiber

3.1.6 Bonded Copper

3.2 Comparisons

3.3 Examples

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF Reference Presentation: Access


Technologies

MEF White Paper: Access


Technologies

IEEE 802.3
IEEE 802.16

MEF-CECP Test Objectives

3 Carrier Ethernet Access


Technologies

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Key Components of Carrier Ethernet In this Section

4 Key Components of Carrier


Study Guide Section 4.1 Ethernet

Subscribers, Service Providers and Operators 4.1 Subscribers, Service Providers


and Operators
The basic model described in MEF 10 for Ethernet services is of a Subscriber
4.2 EVC, OVC, UNI, ENNI and CEN
being the end user for the service (which can be an enterprise, an application (MEN)
service provider, SME, etc) contacting a Service Provider who manages and 4.3 Service Models
operates a Carrier Ethernet Network (CEN) for delivery of Ethernet services.

Download PDF
Subscriber is the organization purchasing and/or using Ethernet Services and
is also known as the end-user. The Subscriber describes the connectivity that
it requires and the traffic specifications in terms of guaranteed bandwidth
Download a pdf for
(CIR) and Excess Bandwidth (EIR). The Service Provider then offers the offline viewing.
Ethernet service(s) and provides (optionally) service performance metrics for
the guaranteed traffic.

Service Provider (SP) is the organization providing Ethernet Service(s). The SP


Reference Documents
contracts with the Subscriber for delivery of service per the service
requirements specified by the subscriber. The commitment of the SP is MEF 10.2
specified in the Service Level Agreement (SLA) which defines the service,
MEF 13
billing, support and maintenance.
MEF 26.1
Operators
MEF-CECP Test Objectives
MEF 26 expands the basic model (described in MEF 10) to facilitate the cases
where the service spans multiple CENs operated by different administrative 4 Components of Carrier Ethernet
entities.
Send Feedback
Each CEN is managed by an Operator where the Operator provides
connectivity services to the Service Provider that in turn provides the UNI-to-
Name:
UNI (end-to-end service) to the Subscriber (as described in the MEF 10
model) Email:

The Service Provider is in charge of assembling and managing the UNI-to-UNI Comments
service. This includes aspects of the service such as billing, technical support,
performance monitoring and reporting to the subscriber.

This model is illustrated below.


Send Feedback

Figure 4.1.F1 - Subscribers, Service Providers and Operators

The Operator may have only limited knowledge of the UNI to UNI service, or
indeed may know nothing at all about it if the Operator is simply providing a
transit CEN for several such services.

Note that the Service Provider may very well also be an Operator of a CEN. In
such cases, the Service Provider contacts another CEN operator in order to
extend the Service Provider reach to locations outside its coverage areas
('offnet locations')

The Service Provider can be a virtual entity with no ownership of its own
physical network. In such a case, the Service Provider stitches together
Ethernet services out of services bought from several CEN Operators.

The Subscriber is typically completely unaware of the existence of the


Operator and interacts only with the Service Provider.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Key Components of Carrier Ethernet In this Section

4 Key Components of Carrier


Study Guide Section 4.2 Ethernet

EVC, OVC, UNI, ENNI and CEN (MEN) 4.1 Subscribers, Service Providers
and Operators
Definition of UNI, UNI-N and UNI-C per MEF 10.2
4.2 EVC, OVC, UNI, ENNI and CEN
(MEN)
This section describes the basic constructs and definitions of Ethernet
4.3 Service Models
services.

The User Network Interface (UNI) is the physical interface or port that is the Download PDF
demarcation between the Subscriber and the Service Provider.

The network that provides the Ethernet services is called the Carrier Ethernet Download a pdf for
Network (CEN). Note that some earlier MEF specifications refer to CEN as MEN offline viewing.
(Metro Ethernet Network) The name was changed by the MEF since Carrier
Ethernet Networks can span any geography from metro through to
intercontinental and are not limited to just metro areas.
Reference Documents

MEF 10.2
The basic service model as described in MEF 10.2 is depicted below:
MEF 13

MEF 26.1

MEF-CECP Test Objectives

4 Components of Carrier Ethernet

Figure 4.2.F1 - Basic Service Model per MEF 10.2 Send Feedback
[Source: MEF 10.2 Figure 1]

The UNI is the demarcation point where the Customer Edge (CE) connects to Name:
the network.
Email:
The functionality of UNI-C (UNI Customer side) is located on the Subscriber
site whereas the functionality of UNI-N (UNI Network side) is located on the Comments
Service Provider site closest to that of the Subscriber.

It should be noted that UNI-N or UNI-C functionality can be realized by more


than one physical network element. Send Feedback

Figure 4.2.F2 - UNI-C and UNI-N

UNI-C is responsible for:

Sending the frames towards the Customer Edge (CE)


Formating the frames in ETH format
C-tagging the frames per the service definition

UNI-N is responsible for:

Exchange of data frames with UNI-C


Enforcing bandwidth profile
Mapping to and from the EVCs

The CE and CEN exchange Service Frames across the UNI. A Service Frame is
an Ethernet (per IEEE 802.3-2005) frame transmitted across the UNI toward
the Service Provider (called an ingress Service Frame ) or an Ethernet frame
transmitted across the UNI toward the Subscriber (called an egress Service
Frame)

In addition, the CE and the CEN can exchange OAM frames for management of
the UNI link. These are NOT considered service frames.

The Service Frame consists of the first bit of the Destination MAC Address
through the last bit of the Frame Check Sequence. The protocol as seen by
the CE connected to the UNI MUST be standard Ethernet with the exception
that it may have a length greater than that specified in IEEE 802.3-2005, and
thus support Jumbo frames.

UNI Type 1 and UNI Type 2

The MEF defines two UNI types:

1. UNI Type 1: Defined by MEF 11. This is a basic UNI with manual
configuration of UNI-N and UNI-C.

UNI Type 1.1 and 1.2 are defined:

Type 1.1 : Non-multiplexed UNI for services such as EPL

Type 1.2 : Multiplexed UNI for services such as EVPL


Services like EVPL

2. UNI Type 2: Defined by MEF 20. It presents an automated


implementation model allowing UNI-C to retrieve EVC status and
configuration information from UNI-N. It supports enhanced UNI
attributes and additional fault management and protection
functionality.

UNI type 2 is further divided into UNI type 2.1 and UNI type 2.2.

UNI Type 2.1

Mandatory Features

Backward compatible with UNI Type 1


Service OAM
Enhanced UNI attributes
L2CP handling

Optional Features

Link OAM
Protection
E-LMI

UNI Type 2.2

Mandatory Features

Backward compatible with UNI Type 1


Service OAM
Enhanced UNI attributes
L2CP handling
Link OAM
Protection
E-LMI

Definition of EVC

Ethernet services are delivered using Ethernet Virtual Connections (EVCs).


EVCs can be of three types (E-Line, E-LAN or E-Tree). EVCs connect two or
more subscriber UNIs for delivery of Ethernet frames (called Service Frames)

An EVC is an association of two or more UNIs. These UNIs are said to be in


the EVC. A given UNI can support more than one EVC via the Service
Multiplexing attribute.

An example of an E-Line EVC is depicted below:

Figure 4.2.F3 - EPL EVC

The ingress Service Frame that is mapped to the EVC can be delivered to one
or more of the UNIs in the EVC other than the ingress UNI. It MUST NOT be
delivered back to the ingress UNI (note that this limitation is only for service
frames and does not affect fault management frames like Loopback) It MUST
NOT be delivered to a UNI not in the EVC. An EVC is always bi-directional in
the sense that ingress Service Frames can originate at any UNI in an EVC.

Definition of ENNI

It is likely that a potential Subscriber for Ethernet Services will have locations
that are not all served by a single CEN Service Provider. Put another way, in
order for such a Subscriber to obtain services, multiple CEN Operators will
need to be used to support all of the Subscriber's User Network Interfaces
(UNIs)

The MEF has defined three fundamental constructs to facilitate global


interconnect:

ENNI (External Network to Network Interface) is the demarcation point


between two CEN operators that connect their CENs in order to provide
Ethernet services to subscribers.

Figure 4.2.F4 - ENNI

In terms of the service model, a new entity is defined - namely the Operator.

An Operator is a CEN provider that is not the Service Provider. The Operator
is not the entity providing the service to the subscriber.

Definition of OVC

OVC (Operator Virtual Connection) is the association of External Interfaces


(UNI or ENNI) within a single CEN, where at least one External Interface is an
ENNI (Note that without this limitation, an OVC could be an EVC)

An OVC can be of 2 types (more types to be included in future revisions of


MEF 26): Point-to-point OVC and Multipoint-to-Multipoint OVC.

The concept is illustrated below:

Figure 4.2.F5 - EVC and multiple OVCs

Concatenation of OVCs are used to create EVCs.

Concatenating OVCs A, B and C create the EVC illustrated above. Each OVC is
managed by a single CEN operator. The EVC is provided by the Service
Provider which may be a fourth entity or might also be one of the three
operators shown.

Functionality of UNI, ENNI, EVC and OVC

The UNI is the demarcation point between the Subscriber and the Service
Provider.

This demarcation point can be a virtual reference point or can reside on a


port on a switch or router.

The entities of the UNI are depicted in the following figure:

Figure 4.2.F7 - UNI Entities

The UNI-C provides the Customer Edge side functions which can be
implemented on a switch or router that connects to the Service Provider's
CEN.

The UNI-C provides the CE-VLAN ID marking and can perform traffic
management functions to ensure that the traffic offered to the CEN is within
the service specifications. The UNI-C also performs OAM functions, etc.

The UNI-N is the SP's side of the UNI. It can be implemented in a single
network element or can be distributed between several network elements
within the CEN. This internal CEN implementation is outside the scope of the
MEF technical specifications.

The UNI-N performs the following functions:

Ingress Bandwidth Profile


Map of Service Frames to EVC
Optional CE-VLAN ID manipulation
Mark Color
OAM functions
UNI link functions (LACP, Link OAM, etc.)
Fault management and performance monitoring of the EVC

The EVC is the basic service container. It connects all the UNIs that belong to
a service. It enforces the connectivity rules, by blocking Leaf to Leaf
communication. The EVC provides separation between Subscribers and
between services.

The EVC is the fundamental service identifier through which configuration,


enforcement, monitoring and reporting occur.

The ENNI is the demarcation point between two CEN operators that connect
their network in order that an SP can offer multi-CEN services to subscribers.

Similarly to the UNI, each side of the ENNI which resides in different CENs has
functions defined by the ENNI-N, as depicted in the following figure:

Figure 4.2.F6 - ENNI-Ns


[Source: MEF 26.1, figure 5]

ENNI-N has the following functionality:

Managing and maintaining the ENNI link (resiliency, fault


management)
Formatting of frames transmitted to and received from the ENNI
Contains several OVC end points
Participates in Service OAM functionalities (MIPs, MEPs)
Optionally performs hairpin switching
Enforces bandwidth profiles at the ENNI including color marking

OVC functionality is similar to EVC functionality where it is limited to a single


CEN.

The OVC connects OVC end points which can reside at External Interfaces (UNI
or ENNI) OVCs are the building blocks for creating EVCs in multi-CEN
scenarios. OVCs provide separation between different services supported for
an SP by the Operator. It also provides the preservation of S-tag and C-tag
where required.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Key Components of Carrier Ethernet In this Section

4 Key Components of Carrier


Study Guide Section 4.3 Ethernet

Service Models 4.1 Subscribers, Service Providers


and Operators
The MEF 26 Service Model
4.2 EVC, OVC, UNI, ENNI and CEN
(MEN)
MEF 26 expands the basic model described in MEF 10 to facilitate those cases
4.3 Service Models
where the service spans multiple CENs which are operated by different
administrative entities.
Download PDF
In such a case, each CEN is managed by an Operator where the Operator
provides connectivity services to the Service Provider which in turn provides
the service to the Subscriber (as in the MEF 10 model) Download a pdf for
offline viewing.
The Service Provider is responsible for assembling and managing the UNI-to-
UNI (end-to-end) service for the Subscriber. Management includes billing,
technical support, performance monitoring and reporting to the Subscriber.
Reference Documents
This model is illustrated below.
MEF 10.2

MEF 13

MEF 26.1

MEF-CECP Test Objectives

4 Components of Carrier Ethernet


Figure 4.3.F1 - MEF 26 Model

The Operator may have only limited knowledge of the UNI-to-UNI service, or Send Feedback
may know nothing at all about it in the case of the Operator that provides
transit CENs for several services. Name:
Note that the Service Provider may well also be an Operator of a CEN. In such
Email:
cases, the Service Provider/Operator contacts another CEN operator in order
to extend the Service Provider's reach to locations outside the Service Comments
Provider's coverage areas ('offnet coverage')

The Service Provider may be a virtual entity that stitches together Ethernet
services out of services the Service Provider buys from several CEN operators. Send Feedback

The Subscriber is not necessarily aware of the existence of the Operator(s).

Service Frames and ENNI frames

MEF 10.x defines the Service Frame as follows:

"An Ethernet frame transmitted across the UNI toward the Service Provider
(CEN) or an Ethernet frame transmitted across the UNI toward the Subscriber
from the CEN."

Ingress Service Frames typically map to an EVC at the UNI.

However, frames exchanged between the CE and the CEN's edge device
attached to it for the management of the UNI link (e.g. LACP, Link OAM) are
NOT service frames.

Service Frames are in the format defined by IEEE 802.3-2005 (except for
allowing larger frames like Jumbo frames). The Service Frame consists of the
first bit of the Destination MAC Address through the last bit of the Frame
Check Sequence.

MEF 26 defines the term ENNI Frame as any Ethernet (per IEEE 802.3-2005)
frame exchanged between two CEN Operators across an ENNI interface.

Note that ENNI Frame could be a service frame or could be an OAM frame of
the ENNI link.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

MEF 10.2
Ethernet Services Attributes Phase 2

MEF 10.2 is a specification document developed by the Technical Committee of the MEF that specifies the service
attributes of E-Line, E-LAN and E-Tree.

Abstract:

"The attributes of Ethernet Services observable at a User Network Interface (UNI) and from User Network Interface to
User Network Interface (UNI to UNI) are defined. In addition, a framework for defining specific instances of Ethernet
Services is described. This document supersedes and replaces MEF 10 [7]."

Download

Reference Presentation
The MEF has prepared an overview presentation which explains the MEF 10.2 specification.

Download

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

MEF 13
User Network Interface (UNI) Type 1 Implementation Agreement

MEF 13 is a specification document developed by the Technical Committee of the MEF that provides an Implementation
Agreement for UNI Type 1.

Abstract:

"This document specifies an implementation agreement for MEF User to Network Interface (UNI) Type 1. The main
objective of this version is to specify the MEF UNI characteristics and operation in manual configuration mode. This
allows existing Ethernet devices (switch, router, workstation, etc) acting as CEs to be instantly compliant to this IA with
no additional software or hardware upgrades. The main functionality of this version is to allow data-plane Ethernet
connectivity between the UNI-C and UNI-N. This document references MEF UNI Requirements and Framework [4] for all
concepts, constructs and terminology. The UNI Type 1 mode provides bare minimum data-plane connectivity services with
no control-plane or management-plane capabilities."
Download

Reference Presentation

The MEF has prepared an overview presentation which explains the MEF 13 Implementation Agreement.

Download

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

MEF 26.1
Metro Ethernet Services Definitions Phase 2
Specification

MEF 26.1 is a specification document developed by the Technical Committee of the MEF that defines the External Network
Network Interface (ENNI)

Abstract:

"The Metro Ethernet Network Architecture Framework specifies a reference point that is the in- terface between two
Metro Ethernet Networks (MENs), where each Operator MEN is under the control of a distinct administrative authority.
This reference point is termed the External Network Network Interface or ENNI.1 The ENNI is intended to support the
extension of Ethernet services across multiple Operator MENs. This Technical Specification specifies:

The requirements at the ENNI reference point as well as the interface functionality in sufficient detail to ensure
interoperability between two Operator MENs in- cluding Link OAM.
The connectivity attributes UNI to UNI, UNI to ENNI, and ENNI to ENNI such that multiple Operator MENs can be
interconnected and the Ethernet services and attributes in MEF 6.1 [9] and MEF 10.2 [5] can be realized."

Download

Reference Presentation

The MEF has prepared an overview presentation which explains the MEF 26.1 specification.

Download

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Test Objectives 4 1 In this Section


Basic Definitions 4 Key Components of Carrier
Ethernet
4.1 Define Ethernet User-to-Network Interface (UNI), Ethernet External
Network-to-Network Interface (ENNI), Ethernet Virtual Connection (EVC), 4.1 Subscribers, Service Providers
and Operators
Service Provider, Operator, and Operator Virtual Connection (OVC).
4.2 EVC, OVC, UNI, ENNI and CEN
(MEN)
4.2 Describe the role of Ethernet User-to-Network Interface (UNI), Ethernet
External Network-to-Network Interface (ENNI), Ethernet Virtual Connection 4.3 Service Models
(EVC), Service Provider, Operator, and Operator Virtual Connection (OVC).
Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 13

MEF 26.1

MEF-CECP Test Objectives

4 Components of Carrier Ethernet

Send Feedback

Name:
Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Attributes of Carrier Ethernet Services In this Section

5 Attributes of Carrier Ethernet


Study Guide Section 5.1 Services

This page is intentionally left blank. 5.1

5.2 UNI Attributes

5.3 EVC per UNI Attributes

5.4 EVC Attributes

5.4.1 L2CP per MEF 6.1.1

5.5 ENNI Attributes

5.6 OVC Attributes

5.6.1 Hairpin switching

5.7 OVC End Point per ENNI


Attributes

5.8 Bandwidth Profiles

5.9

5.10 EVC Performance Attributes

Download PDF

Download a pdf for


offline viewing.

Reference Documents
MEF 6.1

MEF 10.2

MEF 13

MEF 20

MEF 26.1

IEEE 802.1AX

IEEE 802.3 clause 43

MEF-CECP Test Objectives

5 Key UNI, ENNI, OVC, and EVC


Service Attributes

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

[15:33:56] Susan Bud:

In this Section
Attributes of Carrier Ethernet Services
5 Attributes of Carrier Ethernet
Services
Study Guide Section 5.2 5.1
UNI Service Attributes 5.2 UNI Attributes

This topic area describes the various UNI service attributes as specified in 5.3 EVC per UNI Attributes

section 7 of MEF 10.2. 5.4 EVC Attributes

5.4.1 L2CP per MEF 6.1.1


The entire list of parameters is shown on table 3 of MEF 6.1.
5.5 ENNI Attributes
These are the service attributes that are independent of the EVCs connecting 5.6 OVC Attributes
this UNI with other UNIs.
5.6.1 Hairpin switching
It should be noted that 2 UNIs connected with an EVPL service may have some 5.7 OVC End Point per ENNI
of their UNI attributes set differently. Attributes

5.8 Bandwidth Profiles

5.9

5.10 EVC Performance Attributes

Download PDF

Download a pdf for


offline viewing.

Reference Documents
MEF 6.1

MEF 10.2

MEF 13
Table 5.2.T1 - UNI Service Attributes
[Source: MEF 6.1, Table 3] MEF 20

MEF 26.1

UNI Identifier IEEE 802.1AX

IEEE 802.3 clause 43


A text string is used to uniquely identify this UNI in the CEN.

MEF-CECP Test Objectives

Physical Interface 5 Key UNI, ENNI, OVC, and EVC


Service Attributes
The UNI speed can be 10 Mbps, 100 Mbps, 1 Gbps or 10 Gbps. The Mode MUST
be set to Full Duplex. Send Feedback

Essentially, all PHYs defined by IEEE 802.3-2005 are supported with the
Name:
exceptions of 1000BASE-PX-D and 1000BASE-PX-U, since Link OAM is not
supported for these PHYs. Email:

UNI Type 1 supports only a sub-set of the list. Please refer to MEF 13 for Comments
details.

UNI Type 2 (MEF 20) added almost all of the PHYs defined in IEEE 802.3
excluding 1000BASE-PX-D and 1000BASE-PX-U (xPON). 1000BASE-PX-D and Send Feedback

1000BASE-PX-U were excluded since Link OAM (which is mandatory for UNI
Type 2) is not supported on these PHYs.

UNI MTU Size

The UNI MTU (Maximum Transmission Unit) Size service attribute specifies the
maximum Service Frame size (in bytes) allowed at the UNI. The UNI MTU Size
MUST be specified to have a value greater than or equal to 1522. When a
frame larger than the UNI MTU Size arrives at the UNI, it must be dropped. An
MTU size of 1522 bytes allows for a C-tagged frame of maximum frame size,
as defined by IEEE 802.3-2005.

Note that the maximal size of an untagged frame according to IEEE 802.3-
2005 is 1518 bytes.

However, MEF recognizes that a larger frame may be needed for the purposes
of encapsulation and tunneling. Furthermore, it allows the support of Jumbo
frames by setting a large value (e.g 9300 bytes).

The UNI MTU Size (and the EVC MTU Size) is a key service attribute. Some
service Providers do offer a larger MTU size for their subscribers. For
example, when using FCoE (Fiber-Channel over Ethernet) the MTU size would
need to be set to slightly above 2,048 bytes.

Note that some switches may drop any frame that is larger than the MTU
configured on their interface. This is acceptable behavior, as such a frame
can be passed. However, if the frame is dropped, it is not counted against the
Frame Loss Ratio performance attribute.

Bundling and Service Multiplexing

There are three UNI attributes that are interrelated.

They are set according to two fundamental aspects:

1. Virtual or Private Service

2. Single CE-VLAN per service or multiple CE-VLANs per service

When all UNIs associated by an EVC provide private service (i.e. a single
service per UNI port), then the All-to-One Bundling attribute is set to YES.
Note that this must be the setting for all UNIs belonging to this particular
service.

At that point, Bundling must be set to NO.

In the private case which enables the following services: EPL, EP-LAN, EP-
Tree, the UNI can be VLAN unaware, which may mean that the network
element that implements the UNI-N functionality can be VLAN unaware (for
example, when using ETH over SONET). For the private services, all VLAN Ids
and untagged frames are mapped to a single EVC. Such a service implies CE-
VLAN iD and CE-VLAN CoS preservation, meaning that any VLAN ID and VLAN
PCP which is send by the ingress CE will be sent out at the egress UNI(s)
unchanged.

When a virtual service is required - that is a VLAN-aware service - then the


following setting should apply:- Service Multiplexing attribute is set to YES. It
can still be set to NO for a specific UNI that is designed to support one
service instance.

VLAN-aware services have the UNI configured with a map of CE-VLAN IDs to
EVCs. Therefore, one or more EVCs may be built on such a UNI. In this way, it
is possible to build hundreds of EVPLs, EVP-LANs and EVP-Trees over a single
UNI port.

Note that such a UNI is still not considered to provide private service as other
UNIs associated with it do support multiple services.

The Bundling attribute controls whether multiple CE-VLAN IDs can be mapped
to a single EVC.
When Bundling is set to NO, at most one CE-VLAN ID can map to an EVC.
However, some EVCs may have no CE-VLAN IDs mapped to it.

The possible combinations are shown in table 10 of MEF 10.2:

Table 5.2.T2 - Attribute Combinations


[Source: MEF 10.2, Table 10]

Maximum Number of EVCs

This attribute defines the maximum number of EVCs that the UNI can support.
It MUST have a value of at least one. It can be set to a value higher than the
number of EVCs defined on a UNI in order to support future service growth.

This attribute is typically tied to UNI speed, and describes the limitation of
the service. MEF 13 defines a recommended minimum number of EVCs that a
UNI-N should be able to support as specified below:

Table 5.2.T3 - Minimum number of EVCs per UNI

Note that for higher rate UNIs, the number increases. This attribute enables
the Service Provider to set a higher or lower number, depending on the
service it offers.

CE-VLAN ID for untagged and priority tagged Service Frames

For Virtual services, service frames are mapped to a given service instance
(EVC) based on the CE-VLAN ID. This mapping is defined in the EVC per UNI
attributes.

There is a special case when the service frames are untagged or Priority
Tagged frames. These frames are first assigned a CE-VLAN ID in the range 1 to
4094 and are then mapped to the EVC to which that specific CE-VLAN ID is
mapped. An untagged frame at the UNI is any Ethernet frame that has
Ether_type other than 0x8100 (which indicates C-Tag).

Note that at the UNI a frame with S-Tag (Ether_type = 0x88a8) would be
considered untagged. An untagged frame is illustrated below:

Figure 5.2.T4 - Untagged frame at the UNI

A Priority Tagged Frame is a frame with Ether_type = 0x8100 that has a VLAN
ID of 0 and priority encoded by way of the PCP bits in the VLAN tag header.

Note that the CE-VLAN-ID / EVC map could then be set to discard these
frames (i.e. map to no EVC).

This attribute has no meaning for private services (when the All-to-One
Bundling attribute is set to YES), since in this case ALL Service frames
(including untagged frame and Priority Tagged) are mapped to a single EVC.

The purpose of this attribute is that IEEE 802.1 bridges assign a VLAN ID for
frames entering a port (this is sometimes referred to as PVID = Port VLAN ID)
This indicates to the bridged network that the original frame was untagged or
priority tagged.

Bandwidth Profile Per UNI

The Ingress Bandwidth Profile Per UNI and Egress Bandwidth Profile Per UNI
can be specified when enforcement is implemented per port and not per
service.

Once Ingress Bandwidth Profile Per UNI is specified, no other Ingress


Bandwidth Profile can be specified on this UNI.

Layer 2 Control Protocol Processing

Layer 2 Control Protocols (L2CP) are various Ethernet control protocols such as
Spanning Tree BPDUs, LACP, PAUSE Frames, etc.

Most of these protocols use untagged frames.

Some of the protocols are related to the UNI link or belong to the Subscriber
LAN. These must not pass the UNI-N and should be discarded.

However other protocols are designed for use also in carrier networks. For
example Precision Timing Protocol (PTP) IEEE 1588-2008 which does have to
be passed to an EVC in order to distribute clock information to remote UNIs.

In some cases, like Link Aggregation at a UNI, the UNI-N and UNI-C exchange
LACP frames. Therefore, the UNI-N needs to act as a peer for these L2CP
frames (i.e. respond to the incoming LACP frames)

L2CP header frame format is defined by various IEEE 802.1 specifications.

L2CP Frames have specific MAC DAs belonging to reserved multicast MAC
address ranges. Some of the L2CPs have their own MAC DA assigned to them.
For example the MAC DA 01-80-C2-00-00-07 is reserved for E-LMI.
Other protocols might share a MAC DA. For example, IEEE 802.3 had the
address 01-80-C2-00-00-02 allocated for all "slow protocols" like LACP.

Identifying a specific protocol can be done using MAC DA, Ether_type and slow
protocol sub-type. For more details please refer to IEEE 802.1Q.

It should be noted that a protocol might use more than one MAC DA. For
example LLDP uses 01-80-C2-00-00-00 if the subscriber wants to tunnel across
a port-based service (e.g. EPL), or it could use 01-80-C2-00-00-0E if it does
not require tunneling.

The two MAC groups are:

Table 5.2.T5 - MACs for Bridge and GARP


[Source: MEF 6.1, Table 30]

MEF 6.1.1 lists L2CP Protocols and Associated Ethertypes and Subtypes as
shown in the table below:

Table 5.2.T6 - L2CP Protocols and Associated Ethertypes and Subtypes

MEF defines the L2CP processing rules for Service Frames carrying a MAC
Destination Address (DA) within the range 01-80-C2-00-00-00 through 01-80-
C2-00-00-0F and 01-80-C2-00-00-20 through 01-80-C2-00-00-2F. The
treatment of Service Frames with other MAC DA's is defined to be the same as
the treatment of regular service frames.

Therefore if a certain vendor uses its own L2CP with MAC DA outside the
reserved MAC DA range, the L2CP handling rules do not apply to these frames.

The L2CP handling defined by MEF 6.1.1 was defined in order to align the
specification with IEEE 802.1.

For private service, the UNI for EPL, EP-LAN and EP-Tree behaves as if it were
implemented with an IEEE 802.1ad-2005 Provider Bridge S-VLAN Component.

For virtual services, the UNI for EVPL, EVP-LAN, EVP-Tree behaves as if it
were implemented with an IEEE 802.1ad-2005 Provider Bridge C-VLAN
Component associated with an IEEE 802.1ad-2005 Provider Bridge S-VLAN
Component.

There are 4 options for handling of the L2CP protocol at the UNI:

1. Discard The incoming frame is dropped by the CEN and no reply is


generated.
2. Peer The CEN acts as a peer with the CE and may generate an egress
frame based on the protocol rules. From the CE point of view, the CEN
is a single device that is running the Layer 2 Control Protocol.
3. Pass to EVC The incoming frame is mapped to an EVC based on the
CE-VLAN ID of the incoming frame. If the frame is untagged, it will be
mapped to the EVC to which all untagged frames are mapped.
4. Peer and Pass to EVC The CEN acts as peer with the CE and may
generate an egress frame. In addition, the frame is passed to the EVC.

The 'Peer' action is illustrated below:

Figure 5.2.F1 - 'Peer' action

The 'Pass to EVC' action is illustrated below:


Figure 5.2.F2 - 'Pass to EVC' action

Note that while MEF 6.1 included requirements for All Bridges, the All LANs
Bridge Management Group Address (01-80-C2-00-00-10) has been officially
deprecated in 802.1Q-2005, sub-clause 8.13.7. In the unlikely event that a
Subscriber uses this MAC Destination Address, MEF services are expected to
treat them as Data Service Frames.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Attributes of Carrier Ethernet Services In this Section

5 Attributes of Carrier Ethernet


Study Guide Section 5.3 Services

EVC per UNI Service Attributes 5.1

5.2 UNI Attributes


EVC-related attributes are divided into two groups:
5.3 EVC per UNI Attributes
1. EVC per UNI Attributes these are attributes that can be set differently
5.4 EVC Attributes
for each UNI associated with the EVC
5.4.1 L2CP per MEF 6.1.1
2. EVC Attributes these are general attributes that define the EVC and
its behavior and apply on all UNIs associated with the EVC 5.5 ENNI Attributes

5.6 OVC Attributes



5.6.1 Hairpin switching
UNI EVC ID
5.7 OVC End Point per ENNI
Attributes
A string formed by the concatenation of the UNI ID and the EVC ID.
5.8 Bandwidth Profiles

5.9
CE-VLAN ID / EVC Map 5.10 EVC Performance Attributes

The map defines which value(s) of CE-VLAN ID are mapped to each of the
Download PDF
EVCs.

Each CE-VLAN ID can be mapped to at most one EVC. The CE-VLAN ID / EVC
map is the basis for service identification, which is relevant for all virtual Download a pdf for
offline viewing.
services (In private services, all CE-VLAN IDs are mapped to the single EVC)
The creation of the map depends on whether the CE-VLAN IDs are actual
VLANs of the Subscriber's LANs, or are only added by the Customer Equipment
in order to map to the appropriate EVC to the ingress service with which the
Reference Documents
frame is associated.
MEF 6.1
Note that the map can vary between UNIs associated with the same EVC. This
can happen when CE-VLAN IDs are not preserved, and instead are translated MEF 10.2
by the Service Provider. MEF 13

MEF 20
More than one CE-VLAN ID can be mapped to an EVC only if Bundling is set to
Yes at that UNI. MEF 26.1

IEEE 802.1AX
Any value of CE-VLAN ID not assigned to an EVC at a UNI must be dropped.
IEEE 802.3 clause 43

MEF-CECP Test Objectives

5 Key UNI, ENNI, OVC, and EVC


Service Attributes

Send Feedback
Figure 5.3.F1 - Mapping CE-VLAN IDs to EVCs
[Source: MEF 10.2, Figure 9] Name:

An example of a map is given below:


Email:

Comments

Send Feedback

Figure 5.3.T1 - Mapping CE-VLAN IDs to EVCs


[Source: MEF 10.2, Figure 9]

In this example the UNI attribute CE-VLAN ID for untagged and priority tagged
Service Frames is set to 17

Another example:

Figure 5.3.F2 - Mapping CE-VLAN IDs to EVCs

In this example we see:

CE-VLAN ID 1 is mapped to Blue EVC


CE-VLAN ID 2 + untagged and priority tagged frames are mapped to
Red EVC
CE-VLAN ID 400, 405 are mapped to Green EVC (this requires Bundling
= Yes)
All other CE-VLAN IDs are dropped

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Attributes of Carrier Ethernet Services In this Section

5 Attributes of Carrier Ethernet


Study Guide Section 5.4 Services

EVC Attributes 5.1

5.2 UNI Attributes


EVC Attributes are detailed in section 6 of MEF 10.2. They are the same
attributes for all service types. However, some must be set in a certain 5.3 EVC per UNI Attributes
manner for a given service type. MEF 6.1 details the possible values for each 5.4 EVC Attributes
of the 6 service types. 5.4.1 L2CP per MEF 6.1.1

EVC Type 5.5 ENNI Attributes

5.6 OVC Attributes


Defines the service type - namely:-
5.6.1 Hairpin switching
Point-to-Point 5.7 OVC End Point per ENNI
Multipoint-to-Multipoint Attributes
Rooted-Multipoint 5.8 Bandwidth Profiles

5.9
Note that Private/Virtual is deduced by the UNI attributes.
5.10 EVC Performance Attributes

EVC ID Download PDF

An arbitrary string - unique across the CEN - for the EVC supporting the
service instance. Download a pdf for
offline viewing.

UNI List

The UNI List for an EVC is a list of pairs of the form <UNI Identifier, UNI
Reference Documents
Type>. One pair per UNI is associated with a particular EVC. UNI Type can be
Root or Leaf. For EVC types of Point-to-Point or Multipoint-to-Multipoint, it
MEF 6.1
must be Root.
MEF 10.2
MEF 13

Maximum Number of UNIs MEF 20

MEF 26.1
Any integer 2 is allowed. It must be 2 for Point-to-Point EVC.
IEEE 802.1AX

IEEE 802.3 clause 43


EVC Maximum Transmission Unit Size
MEF-CECP Test Objectives
EVC MTU Size must be lower or equal to the UNI MTU size. It must be at least
1522 bytes in oder to support the maximum size of a standard IEEE 802.3 5 Key UNI, ENNI, OVC, and EVC
Service Attributes
frame with a C-Tag. When an ingress frame larger than the MTU arrives at the
EVC, the SLS is not applied. The result of the bandwidth profile is not
defined. Note that such a frame may be dropped but could also be delivered Send Feedback
to the EVC.
Name:
In some cases the subscriber would require a larger MTU in order to support
the delivery of specific applications. For example, FCoE (Fiber Channel over Email:
Ethernet) provides connectivity between devices that have a Fiber Channel
Comments
interface. These devices have MTU of 2,000 bytes. With the addition of an
Ethernet header, the required MTU is closer to 2,100 bytes.

Another example would be a financial application, where the source and/or


destination uses an FDDI interface. FDDI is based on IEEE 802.4 and the
Send Feedback

maximum frame size is 4,352 bytes. So the MTU for such a service would need
to be about 4,400 bytes. It should be noted that in order for the service
provider to carry such large frames, its transport network would need to
support this large MTU in its switches and routers. Not all networking devices
support these frame sizes.

Frame Delivery

The frame delivery rules enable the service provide to specify how different
frame types are to be handled. They enable setting specific rules for
forwarding, discarding or conditionally forwarding specific frame types.

For example: Broadcast frames from a LAN could be blocked over the CEN in
order to save bandwidth.

Any DATA frame (Service frame that is NOT L2CP) is subject to the delivery
rule. There are three rules:

1. Unicast Service Delivery


2. Multicast Service Delivery
3. Broadcast Service Delivery

Each DATA frame is classified to be Unicast, Multicast or Broadcast based on


its MAC DA.

Delivery rule can be one of three. Note, however, that frames with invalid
FCS (CRC) MUST be dropped.

Discard - Allows for example, the blocking of Broadcast on a given EVC.


Deliver Unconditionally Any ingress frame is delivered to the egress UNI(s)
without additional limitations.

Deliver Conditionally Must specify the exact rule. For example, deliver only
unicast frames with a known address.

Delivery rules are set for each of the three data frame types.

For an EPL, all three types must be set to Deliver Unconditionally.

This is defined in order to provide the high transparency required for this
service type.

Preservation

EVC can be set to Preserve the CE-VLAN ID and CE-VLAN CoS. This is required
when the subscriber is using such VLAN header information between its
locations.

For example, if the subscriber's LAN uses VLANs in order to separate


departments (e.g. VLAN ID 4 denotes engineering while VLAN ID 6 denotes
marketing), such VLAN ID values MUST be identical after crossing the CEN in
order not to break the Layer 2 applications. In such a scenario, the subscriber
would require preservation from the service provider.

Figure 5.4.F1 - Preserving Customer VLAN-IDs


[Source: MEF 6.1, Table 32]

Traversing a PB network creates a challenge in distinguishing untagged and


priority tagged frames. Therefore, the following definition for Preservation
was created:

If All-to-one bundling is Yes, then preservation applies to all Ingress service


frames.

If All-to-one bundling is No, then preservation applies to Ingress service


frames having CE-VLAN ID 1 through 4094.

CE-VLAN CoS Preservation means that the PCP bits in the CE-VLAN tag of the
egress frame are identical to those of the ingress frame that yielded this
egress service frame.

The two Per EVC Attributes are:

CE-VLAN ID Preservation Yes, or No


CE-VLAN CoS Preservation Yes, or No

In some cases, the service may be set to perform CE-VLAN Translation. In


other words, changing the CE-VLAN ID between ingress and egress UNIs. This
is easily implemented with routers but could be challenging using switches.
Note that translation is always bi-directional.
Figure 5.4.F2 - CE-VLAN ID Preservation Example

In this illustration, ingress frames at UNI A have CE-VLAN ID 37, when the
egress at UNI B is assigned CE-VLAN ID 156.

CE-VLAN ID Preservation and CE-VLAN CoS Preservation must be set to Yes for
all private services (EPL, EP-LAN and EP-Tree)

L2CP Handling

L2CP handling rules are set according to the definition of MEF 6.1 section 8
and differ per service type.

EVC L2CP handling per protocol can be set to:

Discard Drop the frame Peer Participate in the protocol towards the CE.

Peer can be applicable for the following L2CP LACP/LAMP, Link OAM, Port
Authentication, and E-LMI.

Tunnel Pass to the egress UNI.

Since most of the L2CP protocols are carried using untagged frames, it is a
challenge to tunnel these frames when virtual services are supported.

For Spanning Tree, tunneling XSTP may mean that these frames will not reach
all the bridges and thus the service may be affected.

The following table specifies the L2CP processing requirements for EVPL
service. The first column identifies the standard protocol, and the second
column identifies the MAC DA used to carry that protocol data unit. The third
column specifies the required action, and the fourth column specifies the
applicability - i.e. whether the action taken must be the same at all UNIs in
the EVC, or the action taken can be different on different UNIs in the EVC.

Figure 5.4.T1 - Protocols

No protocol is allowed to be tunneled in an EVPL or any other virtual service.

For EPL, one is allowed to tunnel almost everything, but this can be easily
achieved when the CEN is not packet aware (e.g. carried over SONET/SDH,
OTN etc.). Switches that conform to the IEEE 802.1 standards (like PB bridges)
would not allow forwarding of LACP, PAUSE etc.

When the Subscriber is using Spanning Tree between locations, it must ask the
Service Provider to tunnel the spanning tree BPDUs. This capability cannot be
achieved when EVPL is being provided. When E-LMI is used on the UNI link, the
UNI-N has to be set to Peer E-LMI frames. This is true regardless of the
services being offered using this UNI. Tunneling E-LMI frames seems
undesirable for all service scenarios. For additional examples please refer to
Section 5.4.1.

CoS ID

The CoS ID (Class of Service Identifier) of an EVC defines the service


treatment, optionally bandwidth profile and optionally performance
objectives.

A CoS ID may include several priorities, but these are treated as one CoS by
the CEN.

CoS ID can be derived by one of the following mutually exclusive options:

Per EVC All frames entering a particular EVC will be set to a given CoS ID

By PCP values In this case, the map of PCP to CoS ID MUST include all
possible values (0 through 7) with no overlap. Untagged frames are mapped to
the same CoS ID as Data Service Frames with PCP=0.

For example, a Service Multiplexed UNI with two EVCs: EVC_1 and EVC_2. The
mapping may be as shown in the table below:

Figure 5.4.T2 - EVCs and CoS ID example

In addition, the following rule applies to L2CP (regardless of the method


selected above)

L2CP Any L2CP protocol that is tunneled through this EVC can be set to a
different defined CoS ID. For example, the three-CoS model specified in MEF
23 suggest the following mapping: High PCP 5 Medium PCP 2, 3 Low PCP
0, 1 (note: this includes untagged frames as they are mapped together with
priority tagged frames). PCP 6 and 7 can be mapped to another, non-standard
CoS ID.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Attributes of Carrier Ethernet Services In this Section

5 Attributes of Carrier Ethernet


Study Guide Section 5.4.1 Services

L2CP per MEF 6.1.1 5.1

5.2 UNI Attributes


This section expands on the EVC L2CP handling rules.
5.3 EVC per UNI Attributes
L2CP Processing Requirements for Service Frames with a MAC DA in the
5.4 EVC Attributes
range of 01-80-C2-00-00-00 to -0F
5.4.1 L2CP per MEF 6.1.1
The action (tunnel, peer, or discard) for each L2CP Service Frame is 5.5 ENNI Attributes
decided using a two-step logic based on the frame's:
5.6 OVC Attributes

1. MAC DA 5.6.1 Hairpin switching


2. Ethertype and subtype or LLC code (that is, based on the protocol) 5.7 OVC End Point per ENNI
Attributes
The logic for processing of the L2CP Service Frames is presented in the
5.8 Bandwidth Profiles
following Flow Chart:
5.9

5.10 EVC Performance Attributes

Download PDF

Download a pdf for


offline viewing.

Reference Documents
MEF 6.1

MEF 10.2
Figure 5.4.1.F1 - L2CP Handling Logic (Source MEF 6.1.1 figure A)
MEF 13

MEF 20
STEP 1 MEF 26.1

IEEE 802.1AX
Step 1 in the handling logic means that depending on the service type,
specific MAC DA's must be tunneled through the EVC. IEEE 802.3 clause 43

For private services - EPL (non-transparent option), EP-LAN and EP-Tree - MEF-CECP Test Objectives
which are delivered over a packet-aware network (e.g. IEEE 802.1 or MPLS
5 Key UNI, ENNI, OVC, and EVC
based) the following table applies:
Service Attributes

Send Feedback

Name:

Email:
Figure 5.4.1.T1 - L2CP Handling for Private Service
Comments
For virtual services - EVPL, EVP-LAN, EVP-Tree - the rule is:
For 01-80-C2-00-00-01 through 01-80-C2-00-00-0F Must not Tunnel (Go to Step
2)

Send Feedback

STEP 2

Step 2 is implemented only when Step 1 requires 'Not to Tunnel'.

For each service type, there is a specific table stating whether to Peer or
Discard the frame

For example: In the case of an EPL service.


Spanning tree frames that have MAC DA of 01-80-C2-00-00-00 are tunneled to
the EVC. However spanning tree frames with MAC DA 01-80-C2-00-00-01, for
example, would follow the definition of Step 2 to either peer for all UNIs or
discard for all UNIs. The Service Provider would select to peer on all UNIs
when the resiliency offered to the Subscriber is based on spanning tree
protocol.

Private Services

Here, the processing rules for the private services are described.

Processing rules for EPL (non-transparent option) are as follows:


Figure 5.4.1.T2 - Processing rules for EPL (non-transparent)

For EP-LAN and EP-Tree, the rules are as follows:

Figure 5.4.1.T3 - Processing rules for EP-LAN and EP-Tree

Note that the rules are similar to the ones for EPL with the following changes:

LLDP cannot operate over a service which is not point-to-point, hence


LLDP must be discarded for EP-LAN and EP-Tree
PTP Delay can be supported and if so must be peered on all UNIs

Virtual Services

The same rules apply for all 3 virtual service types as shown in the table
below:

Figure 5.4.1.T4 - Processing rules for EVPL, EVP-LAN and EVP-Tree

Transparent EPL Services

For the very transparent EPL option (which can be carried over non packet-
aware transport like SONET/SDH/OTN), the 2-step logic does not apply. The
logic is maintained from MEF 6.1 and is shown in the table below:

Figure 5.4.1.T5 - Processing rules for Transparent EPL Services


Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Attributes of Carrier Ethernet Services In this Section

5 Attributes of Carrier Ethernet


Study Guide Section 5.5 Services

ENNI Attributes 5.1

5.2 UNI Attributes


For each instance of an ENNI, there are two sets of ENNI Service Attributes -
one for each Operator - namely ENNI-N 1 and E-NNI-N 2. A given attribute in 5.3 EVC per UNI Attributes
the set can have an identical value for each Operator while another attribute 5.4 EVC Attributes
can have a different value for each Operator. The ENNIs are illustrated below: 5.4.1 L2CP per MEF 6.1.1

5.5 ENNI Attributes

5.6 OVC Attributes

5.6.1 Hairpin switching

5.7 OVC End Point per ENNI


Figure 5.5.F1 - Operator to Operator ENNI
[Source: MEF 26.1, Table 3] Attributes

5.8 Bandwidth Profiles


Operator ENNI Identifier
5.9
A unique text string identifying this ENNI within the CEN to which it belongs.
5.10 EVC Performance Attributes
It can be up to 45 bytes long.

Download PDF

Physical interface, frame format

Each link in an ENNI MUST be one of the following physical layers in full Download a pdf for
duplex mode as defined in IEEE Std 802.3 2005 : 1000Base-SX, 1000Base-LX, offline viewing.
1000Base T, 10GBASE-SR, 10GBASE-LX4, 10GBASE-LR, 10GBASE-ER, 10GBASE-
SW, 10GBASE-LW, 10GBASE-EW. Note that the physical layer at one ENNI
supported by the Operator CEN can be different than the physical layer at
Reference Documents
another ENNI supported by the Operator CEN.
Each ENNI Frame MUST have the standard Ethernet format with one of the tag MEF 6.1
configurations specified in the table below. [DA = Destination Address, SA = MEF 10.2
Source Address, ET = Ethertype/Length, S-Tag with Tag Protocol Identification MEF 13
Field (TPID) = 0x88A8, C-Tag with TPID = 0x8100.]
MEF 20

MEF 26.1

IEEE 802.1AX

IEEE 802.3 clause 43


Figure 5.5.T1 - ENNI Frame Tags
MEF-CECP Test Objectives
Note: Different ENNI frames can take different forms from those three forms
listed in the table (i.e. there is no ENNI attribute to set for the frame format) 5 Key UNI, ENNI, OVC, and EVC
Service Attributes

Number of Links Send Feedback


Specifies the number of physical links at the ENNI. The value can be 1 or 2.
Name:
2 are used when resiliency is implemented.
Email:

Comments

ENNI Resiliency

The Protection Mechanism defines the resiliency scheme at the ENNI. There
Send Feedback
are 3 alternatives:

None - No protection, applicable only if Number of Links is 1 and


must be set so in such a case.
Link Aggregation Performing LAG with exactly 2 links (Number of
Links = 2). LAG configuration is at the Operator's discretion.
Other Any other resiliency mechanism agreed upon between the 2
Operators. This option is valid only when Number of Links = 2.

ENNI Maximum Transmission Unit Size

ENNI Max MTU Size specifies the maximum frame length allowed at the ENNI.
It must be at least 1526 bytes (to support doubled-tagged frames) and
recommended to be at least 2000 bytes in order to support other headers and
encapsulations. Unlike UNI MTU, frames larger than ENNI MTU MUST be
discarded. They may or may not consume tokens from the BWP. This is not
specified. The ENNI MTU is recommended to be at least 4 bytes larger than
any EVC MTU size crossing this ENNI.

Maximum Number of OVCs

The maximum number of OVCs allowed on this ENNI. An integer greater or


equal to 1.

Maximum Number of OVC End Points per OVC

An upper bound to the number of OVC end points that can be associated with
an OVC at this ENNI. If set to 1, then Hairpin Switching cannot be supported
at the ENNI, as it requires 2 OVC end points.

End Point Map

The End Point Map specifies how each S-Tagged ENNI Frame is associated with
an OVC End Point within an Operator CEN. The End Point Map can be
represented by a three column table. Column 1 contains S-VLAN ID values.
Column 2 contains End Point Identifiers. Column 3 contains End Point types.
Each row in this table maps the S-VLAN ID value to the End Point Identifier
and End Point Type. End Point Type must be OVC. An S-VLAN ID value cannot
appear more than once in the table. An example is shown below:

Figure 5.6.1.F2 - Service Frame in Hairpin Switching

Some rules apply:

1. When the ingress frame has S-VLAN ID that is NOT in the map, it must
not be forwarded.
2. An S-VLAN ID value cannot appear more than once in the table.
3. Ingress frame with no S-Tag must not be mapped to OVC end point.

When the ingress frame has S-VLAN ID that is NOT in the map, it must not be
forwarded. An S-VLAN ID value cannot appear more than once.

End-Point Bundling

When multiple S-VLAN ID values are mapped to a single OVC end point, the
End Point map is said to have Bundling. Remember that this is quite similar to
UNI bundling of CE-VLAN IDs. When Bundling is set, S-VLAN ID Preservation
and CE-VLAN ID Preservation MUST be Yes. Bundling is useful when multiple
EVCs are tunneled via a single OVC transit tunnel. In such a case, different
EVCs may use the same MAC address ranges and the Operator should provision
for such a scenario.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Attributes of Carrier Ethernet Services In this Section

5 Attributes of Carrier Ethernet


Study Guide Section 5.6 Services

OVC Attributes 5.1

5.2 UNI Attributes


This section describes the OVC service attributes.
5.3 EVC per UNI Attributes

5.4 EVC Attributes
OVC ID 5.4.1 L2CP per MEF 6.1.1

A string of at most 45 bytes that uniquely identifies the OVC within a given 5.5 ENNI Attributes

CEN. 5.6 OVC Attributes

5.6.1 Hairpin switching



5.7 OVC End Point per ENNI
OVC type Attributes

5.8 Bandwidth Profiles


This can be Point-to-Point or Multipoint-to-Multipoint. An OVC that can
associate two or more OVC End Points is defined to have OVC Type of 5.9
Multipoint-to-Multipoint. An OVC that associates exactly two OVC End Points is 5.10 EVC Performance Attributes
defined to have OVC Type of Point-to-Point, and can be considered a special
case of the Multipoint-to-Multipoint OVC Type. Note that because an OVC can Download PDF
associate more than one OVC End Point at a given ENNI, the type of an OVC is
not determined by the number of External Interfaces supported by the OVC.
Download a pdf for
offline viewing.

OVC End Point List

A list of OVC End Point Identifiers.


Reference Documents

MEF 6.1
Maximum Number of UNI OVC End Points
MEF 10.2
The Maximum Number of UNI OVC End Points is the upper bound on the MEF 13
number of OVC End Points that are at different UNIs that can be associated by
MEF 20
an OVC. This must be an integer greater or equal to 0.
MEF 26.1
IEEE 802.1AX

Maximum Number of ENNI OVC End Points IEEE 802.3 clause 43

A list of OVC End Point Identifiers. The Maximum Number of ENNI OVC End
MEF-CECP Test Objectives
Points is the upper bound on the number of OVC End Points that are at an
ENNI that can be associated by an OVC. This must be an integer greater or 5 Key UNI, ENNI, OVC, and EVC
Service Attributes
equal to 1.

Send Feedback

OVC Maximum Transmission Unit Size


Name:
The OVC MTU size in bytes. The OVC MTU must be at least 1526 bytes and it
is recommended to be at least 2000 bytes. It must be less than or equal to Email:

the ENNI MTU size. When an ENNI frame is larger than the OVC MTU that is Comments
mapped to an OVC, then the frame must be discarded. It may or may not
consume tokens from the ingress BWP.

Note that when an EVC that spans multiple CENs is set with a specific MTU
Send Feedback
size, then each OVC that is part of the EVC should have its MTU set to at
least the MTU size of the EVC.

CE-VLAN ID preservation

OVC CE-VLAN ID Preservation is used to achieve EVC CE-VLAN ID Preservation


that is a key property of the EPL and EP-LAN Service Types specified in MEF
6.1. In order to achieve EVC CE-VLAN ID Preservation, all OVCs that are part
of this EVC must have their OVC CE-VLAN ID Preservation set to Yes. Similar
to EVC CE-VLAN ID Preservation, the handling of untagged and priority tagged
frames can be a challenge. Therefore, there is a distinction between the two
cases, which is analogous to the all-to-one bundling case for EVC CE-VLAN ID
Preservation.
The following table describes the relationship between an ingress frame at an
External Interface and the corresponding egress frame at an External Interface
for the case where all OVC end points associated with an OVC map ALL CE-
VLAN IDs to this OVC:

Figure 5.6.T1 - Correspondence between Ingress and Egress


[Source: MEF 26.1, Table 5]

Note: This handling is required when OVC CE-VLAN ID Preservation is set to


Yes.

The following table describes the relationship between ingress frame at


External Interface to the egress frame at the External Interface for the case
where all OVC end points associated with an OVC map some but NOT ALL CE-
VLAN IDs to this OVC:

Figure 5.6.T2 - Correspondence Ingress to Egress 2


[Source: MEF 26.1, Table 6]

(*) The S-tag value is defined in the OVC end point map and can take any
value, regardless of the value of CE-VLAN ID.
Note: This handling is required when OVC CE-VLAN ID Preservation is set to
Yes.

CE-VLAN CoS preservation

OVC CE-VLAN CoS Preservation is used to achieve EVC CE-VLAN CoS


Preservation. In order to achieve EVC CE-VLAN CoS Preservation, all OVCs that
are part of this EVC must have their OVC CE-VLAN CoS Preservation set to
Yes. The mechanism specified keeps the original PCP value in both C-tag and
S-tag. Note that this means that color forwarding should be done using DEI bit
in the S-tag.
The following table specifies the required mapping for implementing OVC CE-
VLAN CoS Preservation:

Figure 5.6.T3 - CE-VLAN CoS Preservation


[Source: MEF 26.1, Table 8]

S-VLAN ID & CoS preservation

S-VLAN ID Preservation and S-VLAN CoS Preservation apply between two ENNIs
connected by an OVC. This attribute does NOT affect ENNI to UNI frame
exchange. Preservation means that the value of S-VLAN ID and/or S-VLAN CoS
at one ENNI must be equal to the value at a different ENNI connected by the
OVC.
The following rules apply:

When an OVC has the S-VLAN ID Preservation attribute with a value of


Yes, it must associate at most one OVC End Point located at a given
ENNI.
When an OVC has the S-VLAN ID Preservation attribute with a value of
No, an egress ENNI Frame mapped to an OVC End Point resulting from
an ingress ENNI Frame mapped to a different OVC End Point MUST
have an S-VLAN ID value that has a one-to-one association with the
S-VLAN ID of the ingress service frame.

Note that S-VLAN ID preservation cannot be achived when hairpin switching is


enabled.

The benefit of using S-VLAN ID preservation is to allow simpler end-to-end


service provisioning and service monitoring for cases where an EVC spans
several CENs. In such a case, the SP may require S-VLAN ID preservation from
the CEN operators in order to easily define the mapping rules of EVC to OVC.

Color forwarding

Color Forwarding describes the relationship between the color on an ingress


frame into the Operator Network and the color of the resulting egress ENNI
Frame. When Color Forwarding is Yes, the OVC cannot promote a frame
from Yellow to Green. Promoting a frame from Yellow to Green could have an
undesired impact on the EVC performance. The newly promoted Green frames
are now competing with equal rights for resources as frames marked Green at
the ingress UNI. For this reason, this attribute is useful to prevent such
behavior. When color forwarding is set, an ingress frame at ENNI declared
yellow by an ingress BWP must have its color marked in the header, using PCP
bits or DEI bit. Note that this attribute does not describe Color marking of an
egress Service Frame at a UNI because a method for such marking is not
specified in MEF 23.

Frame Delivery

Similar to EVCs, OVCs also have three attributes to govern frame delivery
rules. These are:

Unicast Frame Delivery


Multicast Frame Delivery
Broadcast Frame Delivery

Each is independent from the others and can take two values:

Deliver unconditionally This means that assuming that the frame has
a valid FCS/CRC and assuming that the ingress BWP declared the
frame color as Green or Yellow, it should be passed to the OVC.
Delivery Conditionally Must specify the condition.

An example of such a condition is that the destination MAC address is known


by the Operator CEN to be at the OVC End Point.

In some E-LAN scenarios, the SP may want to limit the consumed bandwidth
over an OVC (for example tunnel to a UNI) and thus would like to avoid
flooding for unknown addresses.

SLS
The Service Level Specification (SLS) consists of definitions of delivery
performance attributes for frames between External Interfaces, e.g. delay,
loss. For each performance attribute, the SLS also contains a quantitative
objective. When the frame delivery performance level meets or exceeds the
objective for each performance attribute, the SLS is said to be met. The SLS
that applies to a given ENNI or Service Frame is based on the Class of Service
Identifier for the frame. When an ENNI Frame is not sufficiently compliant
with an ingress Bandwidth Profile that applies to it, the SLS does not apply to
the frame. Details of ENNI and OVC SLS are expected in future versions of MEF
26.x or MEF 23.x.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Attributes of Carrier Ethernet Services In this Section

5 Attributes of Carrier Ethernet


Study Guide Section 5.6.1 Services

Hairpin Switching 5.1

5.2 UNI Attributes


Hairpin Switching occurs when an ingress S-Tagged ENNI Frame at a given ENNI
results in an egress S-Tagged ENNI Frame with a different S-VLAN ID value at 5.3 EVC per UNI Attributes
the given ENNI. This behavior is possible when an OVC associates two or more 5.4 EVC Attributes
OVC End Points at a given ENNI. 5.4.1 L2CP per MEF 6.1.1

Hairpin switching provides value in several scenarios. 5.5 ENNI Attributes

5.6 OVC Attributes


One example is where an Operator supplying a Service Provider with a
5.6.1 Hairpin switching
tunneling service (e.g. E-Access) does not have suitable Carrier Ethernet
switching capability available in its own network. Therefore the tunnel service 5.7 OVC End Point per ENNI
Attributes
is connected to a PE in the Service Provider's CEN where the switching is
implemented. The switching decision may require sending traffic over the 5.8 Bandwidth Profiles

ENNI (Service Provider CEN - Operator CEN) towards a different UNI attached 5.9
to the Operator CEN. In this example, the Service Provider CEN provides the 5.10 EVC Performance Attributes
switching capability between the Operator's two UNIs facing the Subscriber.
Download PDF
Note that hairpin switching cannot occur at a UNI.

The concept of hairpin switching is illustrated in the following figure:


Download a pdf for
offline viewing.

Reference Documents
MEF 6.1

Figure 5.6.1.F1 - Hairpin Switching MEF 10.2


[Source: MEF 26.1, figure 16]
MEF 13
In order to facilitate hairpin switching the concept of OVC end points in
MEF 20
introduced.
MEF 26.1

IEEE 802.1AX
The figure below shows an example of the use of OVC End Points for Hairpin
IEEE 802.3 clause 43
Switching. In this example, there is one multipoint EVC that associates UNI
Aa, UNI Ab, and UNI B. Operator A has two OVCs. One associates the OVC End
MEF-CECP Test Objectives
Point A4 at UNI Aa and the OVC End Point A1 at the ENNI. The other OVC
associates the OVC End Point A3 at UNI Ab and the OVC End Point A2 at the 5 Key UNI, ENNI, OVC, and EVC
Service Attributes
ENNI. Operator B has one OVC that associates the OVC End Points B1 and B2
at the ENNI and the OVC End Point B3 at UNI B. At the ENNI, the End Point
Send Feedback
Maps are such that ENNI frames mapped to A1 by Operator A are mapped to
B1 by Operator B and similarly for A2 and B2. With this configuration, a
Name:
Service Frame sent from UNI Aa to UNI Ab will pass through the Operator B
MEN where it will be hairpin switched from B1 to B2. Likewise, a similar path
Email:
will be followed by a Service Frame sent from UNI Ab to UNI Aa.
Comments

Send Feedback

Figure 5.6.1.F2 - Hairpin Switching

Note that in this example, two OVCs are used in Operator MEN A to implement
the single EVC.
In order to support Hairpin switching the following attributes must be set:

S-VLAN ID Preservation must be set to No in order to support Hairpin


switching as the S-VID must be changed when the operation is
performed
Maximum Number of OVC End Points per OVC must be set to at least
2

Word of caution:
Improper use of hairpin switching can result in a data loop between two
Operator CENs at a single ENNI. It is up to the Service Provider and Operators
to ensure that such loops do not occur.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Attributes of Carrier Ethernet Services In this Section

5 Attributes of Carrier Ethernet


Study Guide Section 5.7 Services

OVC End Point per ENNI 5.1

5.2 UNI Attributes


There are service attributes for each instance of an OVC End Point at a given
ENNI. 5.3 EVC per UNI Attributes

5.4 EVC Attributes


OVC End Point Identifier
5.4.1 L2CP per MEF 6.1.1
The OVC End Point Identifier is a string of up to 45 bytes administered by the
5.5 ENNI Attributes
Operator that is used to identify an OVC End Point within a given CEN. The
5.6 OVC Attributes
OVC End Point Identifier is not carried in any field in the ENNI Frame. It must
be unique to all OVC end points in the CEN. 5.6.1 Hairpin switching

5.7 OVC End Point per ENNI


CoS ID Attributes

A Class of Service Identifier is a set of one or more S-Tag PCP values. Each 5.8 Bandwidth Profiles
Class of Service Identifier indicates a single Class of Service instance. The Class 5.9
of Service that applies to an ingress S-Tagged ENNI Frame that is mapped to 5.10 EVC Performance Attributes
the OVC End Point is the Class of Service identified by the Class of Service
Identifier that contains the S-Tag PCP value in the frame. For example, the S- Download PDF
Tag PCP values 0, 1, 2, and 3 could constitute a Class of Service Identifier that
indicates the silver service while the S-Tag PCP values 4, 5, 6, and 7 could
constitute a different Class of Service Identifier that indicates the gold Download a pdf for
service. In this example, an S-Tagged ENNI Frame with S-Tag PCP value = 3 offline viewing.
would be given the silver service. Note that in case of S-tag bundling, the map
is independent of the S-VLAN ID. The following rules apply:

Each PCP value must be mapped to exactly one COS ID Reference Documents
One CoS ID can be set to 100% discard
CoS ID can have different maps between different OVC end points, as MEF 6.1
long as they are associated with different OVCs MEF 10.2

Frame color can be marked in one of two methods: DEI bit or S-tag PCP MEF 13

values. According to MEF 23, the following values are recommended for a 3 MEF 20
CoS model: MEF 26.1

IEEE 802.1AX
For green color or when color is marked using DEI bit:
IEEE 802.3 clause 43

MEF-CECP Test Objectives

5 Key UNI, ENNI, OVC, and EVC


Service Attributes

Figure 5.7.T1 - H, M, L - Green Color Send Feedback


[Source: MEF 26.1, figure 9]

For yellow color or when color is marked using PCP bits: Name:

Email:

Comments

Figure 5.7.T2 - H, M, L - Yellow Color


Send Feedback

Bandwidth Profiles per OVC End Point

An Ingress Bandwidth Profile (BWP) can be applied per OVC end point or per
CoS ID per OVC End point per ENNI. Note that each ingress ENNI frame can be
subject to at most one BWP.

The handling of frames is described in the following table:

Figure 5.7.T3 - Ingress Bandwidth Profile Compliance


[Source: MEF 26.1, Table 7]

Ingress BWP per OVC End Point enables similar BWP as for Ingress BWP per
UNI. It can be used for example to enforce a rate limit into the network over
an external interface.

The following figure depicts ingress BWP per OVC end point:
Figure 5.7.F1 Bandwidth Profile per OVC

Each Ingress BWP must include suitable parameters <CIR, CBS, EIR, EBS, CF,
CM>. CM must be set to color aware.

Egress BWP

An Egress Bandwidth Profile (BWP) can be applied per OVC end point or per
CoS ID per OVC End point per ENNI.

Each Egress BWP must include suitable parameters <CIR, CBS, EIR, EBS, CF,
CM>.

CM must be set to color aware. This is the only change compared to MEF 10.2
definitions for Egress BWP at the UNI. The Egress Bandwidth Profile per OVC
End Point at a UNI describes egress policing by the Operator CEN on all egress
Service Frames mapped to a given OVC End Point at a UNI.

Note that each egress ENNI frame can be subject to at most one BWP.

The Egress Bandwidth Profile per OVC End Point describes egress policing by
the Operator on all egress ENNI Frames that are mapped to a given OVC End
Point.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Attributes of Carrier Ethernet Services In this Section

5 Attributes of Carrier Ethernet


Study Guide Section 5.8 Services

Bandwidth Profiles 5.1

5.2 UNI Attributes


Concept
5.3 EVC per UNI Attributes
A Bandwidth Profile (BWP) enforces the utilization of bandwidth according to
5.4 EVC Attributes
the Service Level Specification that has been agreed upon by the Subscriber
5.4.1 L2CP per MEF 6.1.1
and Service Provider. It can be thought of as enforcing the long term average
guaranteed bandwidth (CIR) and excess bandwidth (EIR) allowed by the 5.5 ENNI Attributes
service. CIR (Committed Information Rate) is the bit rate for which the SP 5.6 OVC Attributes
provides performance guarantees in terms of performance attributes for the 5.6.1 Hairpin switching
service. EIR (Excess Information Rate) is the additional bit-rate that the
5.7 OVC End Point per ENNI
subscriber can utilize and for which traffic can probably pass through the CEN Attributes
as long as there is no congestion. Note that the total rate, sometimes known
5.8 Bandwidth Profiles
as PIR (Peak Information Rate), is the sum of CIR and EIR. The BWP classifies
5.9
the service frames into 3 "colors" each denoting a certain compliance level:
5.10 EVC Performance Attributes
Green Frames within the CIR / CBS compliance level. These frames
are subject to the SLS. Download PDF
Yellow Frames exceeding the CIR/CBS but are within the EIR/EBS.
These frames are delivered as "best effort" without being subject to
the SLS. The CEN may drop some or all of these frames based on Download a pdf for
congestion conditions in the network. offline viewing.

Red Frames not conforming to the BWP are dropped, either because
the rate exceeds the sum of CIR and EIR, or because there are
insufficient yellow tokens to admit a frame that is within EIR/EBS .
Reference Documents
There are two types of bandwidth profiles:
MEF 6.1
Ingress Bandwidth Profile limits the rates of frames entering the MEF 10.2
CEN.
MEF 13
Egress Bandwidth Profile limits the rate of frames egressing the CEN
and thus protecting overload towards the egress CE. MEF 20

MEF 26.1
Bandwidth Profile can be applied in three forms:
IEEE 802.1AX

Per UNI IEEE 802.3 clause 43


Per EVC
Per CoS ID per EVC MEF-CECP Test Objectives

However, the algorithm is the same for all three forms. 5 Key UNI, ENNI, OVC, and EVC
Service Attributes
At a given UNI, at most one ingress BWP can be applied and at most one
egress BWP can be applied to a given service frame. This means that one Send Feedback
cannot define an ingress BWP per UNI in addition to an ingress BWP per EVC.
Name:
The three BWP forms are illustrated below:
Email:

Comments

Send Feedback
Figure 5.8.F1 - Ingress Bandwidth Profile Per Ingress UNI

Figure 5.8.F2 - Ingress Bandwidth Per EVC

Figure 5.8.F3 - Ingress Bandwidth Profile Per CoS ID

An example is a 100 Mb/s UNI that services 3 EVCs. Each EVC can have CIR of
30 Mbps and EIR of 20 Mbps.

Figure 5.8.F4 - Total Bandwidth at UNI

The subscriber is guaranteed 30 Mbps per each service (SUM of CIRs must be
<= UNI speed), however, the Subscriber cannot use the excess bandwidth
simultaneously for the 3 services, or else the Subscriber would be trying to
send 150 Mbps over a 100 Mbps link.

The concept of Egress BWP per EVC is illustrated below:


Figure 5.8.F5 - Egress Bandwidth Profile per EVC
[Source: MEF 10.2, Figure 18]

The Algorithm

The bandwidth profile rates are enforced through an algorithm which is


commonly implemented as a token bucket algorithm. The MEF has defined a
two rate, three color marker (trTCM) algorithm which can be implemented via
two token buckets.
One bucket, referred to as the Committed' or C' bucket, is used to
determine CIR-conformant, in-profile Service Frames while a second bucket,
referred to as the Excess' or E' bucket, is used to determine EIR-conformant,
excess Service Frames.
Each token bucket consists of a bucket of bytes referred to as tokens'.
Initially, each token bucket is full of tokens. The number of tokens in each
bucket represents the allowed burst size, CBS, for the Committed bucket and
EBS for the Excess bucket. As Service Frames enter the provider's network (or
pass the reference point where the BWP algorithm is applied), the trTCM
decrements the number of tokens in the C bucket (green tokens) by the
number of bytes received from the service frame. If green tokens still remain,
then the Service Frame is CIR-conformant, colored green and allowed into the
provider's network.

If no green tokens remain, then a second E bucket is checked to determine if


any E bucket tokens (yellow tokens) remain. If yellow tokens are available,
then the Service Frame is colored yellow and allowed into the provider's
network. If no yellow tokens are available, then the Service Frame is declared
red and discarded. Refer to the figure below.

The MEF has defined an additional, optional capability of the trTCM whereby
unused green tokens from the C bucket may be added to the E bucket as
yellow tokens when checking EIR-conformance. This parameter is called the
Coupling Flag (CF) and is enabled when CF=1. When this capability is enabled
and when operating in color-aware mode, more yellow Service Frames are
allowed into the service provider's network.

Figure 5.8.F6 - C-Bucket and E-Bucket

Frame color is never changed to promote a frame's drop eligibility , that is,
Yellow frames can never be re-marked as Green.
The following figure illustrates the effect of BWP on a fast incoming burst of
traffic. Initially, service frames are colored green, up to CBS, then for EBS by
tes. Thereafter they are colored yellow. Any additional frame will be marked
red and discarded.

Figure 5.8.F7 - Burst Threshold

Note that actual implementation operates on whole frames, so one might not
be able to use the entire CBS bucket. For example, we assume CBS=2000
bytes and EBS=3000 bytes. 5 back to back service frames arrive at the UNI-N,
each sized at 1522 bytes. The first frame consumes 1522 bytes from the C-
bucket and is marked green. We now have 2000 1522 = 478 tokens left in the
C-bucket. The second frame is larger than the C-bucket size and hence cannot
be marked green. If CF=1, the remainder of 478 bytes would be carried to the
E-bucket, for a total of 3478 yellow tokens. Assuming CF=0, the second frame
is declared yellow. We now have 1478 tokens left in the E-bucket. The third
frame arrives and is larger than the number of tokens in E-bucket and hence
is declared Red and is dropped immediately.

Color Mode (CM) determines whether the algorithm takes into account a
previous color marking, for example frame marked Yellow by the subscriber or
at an ingress UNI. When Color Mode = Yes it is often referred to as Color
Aware algorithm.

Coupling Flag (CF) determines whether the Yellow bucket can consume
tokens from the green bucket. CF has an effect only in Color aware mode.

When CF is set to 0, the long term average bit rate of Service Frames that are
declared Yellow is bounded by EIR. When CF is set to 1, the long term average
bit rate of Service Frames that are declared Yellow is bounded by CIR + EIR
depending on the volume of the offered Service Frames that are declared
Green. In both cases the burst size of the Service Frames that are declared
Yellow is bounded by EBS.

Effect of Each Parameter Setting

Setting the appropriate values for CIR and EIR is often relatively easy. They
are either set to the exact value required by the service or are set a bit
higher (mainly for CIR) when there is a strict need to have only guaranteed
service. For example, if a customer asks for 20 Mbps guaranteed service with
strict frame delay and frame loss ratio requirements, it may be wiser to set
CIR to be 21 or 22 Mbps to avoid occasional slips. When considering the effect
of CBS one should take into consideration the offered traffic source and its
burstiness. For example, carrying 2 Mbps E1 using CES, the traffic source sends
the traffic at 2 Mbps line rate, hence there is no need for large CBS, so CBS
could be set to 1522 bytes. Note that CBS must be at least the MTU size
unless it is set to 0. However, a TCP-based application like HTTP could send
256 Kbytes of traffic at LAN rate, due to TCP windowing affect. The subscriber
CE may shape the traffic to reduce the burstiness, but if not and if the SP
would like to account these bursts, then an appropriately large CBS should be
set.

When a specific service should not have its frames declared yellow, both EIR
and EBS should be set to 0. Note that if EIR=0 but EBS=10,000 bytes, then up
to 10,000 bytes could be declared yellow for a given burst of traffic. Egress
BWP should be set to color-aware mode in order to take into account the
color marking at the ingress UNI.

Applications

Consider an enterprise with 3 locations: An HQ and 2 branch offices.

Figure 5.8.F8 - EP-LAN Application

The enterprise asks for EP-LAN service of 100 Mbps guaranteed. An EVC Ingress
BWP could be set to provide
CIR=100 Mbps
CBS=50,000 Bytes
EIR=0
EBS=0
CM=0
CF=0

If the enterprise would like specific delay guarantees to its VoIP application,
then the SP may offer 2 CoS ID, letting the CE perform the priority marking.
The VoIP service is assumed to require 10 Mbps. High marked with PCP=5 and
Low marked with PCP=0. All other PCP values could be blocked

Figure 5.8.T1 - Example EP-LAN Attributes

Now two ingress BWPs should be set - one per each CoS ID

Example for Egress BWP

Consider EVP-LAN service servicing 10 UNIs If the SP would like to ensure that
the UNI link is not flooded, it should set the egress BWP to the desired rate.
Note that in such a case, coloring the frame may not be meaningful, so CIR=0,
CBS=0 and EIR=desired rate with some reasonable EBS is the suggested
solution.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Attributes of Carrier Ethernet Services In this Section

5 Attributes of Carrier Ethernet


Study Guide Section 5.9 Services

This page is intentionally left blank. 5.1

5.2 UNI Attributes

5.3 EVC per UNI Attributes

5.4 EVC Attributes

5.4.1 L2CP per MEF 6.1.1

5.5 ENNI Attributes

5.6 OVC Attributes

5.6.1 Hairpin switching

5.7 OVC End Point per ENNI


Attributes

5.8 Bandwidth Profiles

5.9

5.10 EVC Performance Attributes

Download PDF

Download a pdf for


offline viewing.

Reference Documents
MEF 6.1

MEF 10.2

MEF 13

MEF 20

MEF 26.1

IEEE 802.1AX

IEEE 802.3 clause 43

MEF-CECP Test Objectives

5 Key UNI, ENNI, OVC, and EVC


Service Attributes

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Attributes of Carrier Ethernet Services In this Section

5 Attributes of Carrier Ethernet


Study Guide Section 5.10 Services

EVC Performance Attributes 5.1

5.2 UNI Attributes


The EVC Related Performance Service Attributes specify the Service Frame
delivery performance. Four performance attributes are considered in this 5.3 EVC per UNI Attributes
specification. These are: 5.4 EVC Attributes

5.4.1 L2CP per MEF 6.1.1


Frame Delay
Inter-Frame Delay Variation 5.5 ENNI Attributes
Frame Loss Ratio 5.6 OVC Attributes
Availability 5.6.1 Hairpin switching

The Performance attributes are per CoS ID. They must be specified for at 5.7 OVC End Point per ENNI
Attributes
least one CoS ID, but some of the attributes can be set to N/S (Not
specified). 5.8 Bandwidth Profiles

5.9
In general, all service performance attributes are measured during some time
5.10 EVC Performance Attributes
interval T (e.g. 5 minutes, 2 hours, etc.).

Service performance is measured between an ordered pair of UNIs. Download PDF

For E-Line, there are 2 ordered pairs (UNI1, UNI2) and (UNI2, UNI1).
Download a pdf for
For E-LAN and E-Tree, measurement can be performed on any sub-set of the offline viewing.
ordered pairs.

For E-Tree, each pair must include at least one root UNI.

Reference Documents
Frames are counted against the performance attribute only if they meet all
the following criteria:
MEF 6.1
The egress frame results from an ingress frame where both UNIs MEF 10.2
(ingress and egress) belong to the ordered set. MEF 13
The first bit of the frame must arrive to the egress UNI during the
MEF 20
time interval T.
MEF 26.1
The ingress BWP had compliance level of green.
IEEE 802.1AX
Note that Unicast, Multicast, Broadcast and L2CP frames can all be used for
IEEE 802.3 clause 43
performance measurement.

One-way Frame Delay MEF-CECP Test Objectives

5 Key UNI, ENNI, OVC, and EVC


The One-way Frame Delay for an egress Service Frame at a given UNI in the Service Attributes
EVC is defined as the time elapsed from the reception at the ingress UNI of
the first bit of the corresponding ingress Service Frame until the transmission
Send Feedback
of the last bit of the Service Frame at the given UNI. This delay definition is
illustrated below.
Name:

Email:

Comments

Figure 5.10.F1. - One way frame delay Send Feedback


[Source: MEF 10.2, Figure 5]

Note that this definition of Frame Delay for a Service Frame is the one-way
delay that includes the delays encountered as a result of transmission across
the ingress and egress UNIs as well as that introduced by the CEN.

Measuring One-way delay requires clock synchronization between all UNIs


associated with an EVC, therefore, in some cases approximation can be used
from measuring Two-way delay. However, such approximation should be
carefully considered as the delay on each direction may be different in some
CEN technologies or under certain traffic and load conditions.

MEF 10.1 had Percentiles as the attribute for One-way delay.

The 99th Percentile is 50 msec means that 99% of the measurements during
the time interval T should be less than 50 msec.

For Multipoint EVCs, the Percentiles are calculated taking the MAX (worst
case) over all ordered UNI pairs defined for the sub-set (which could be all
UNIs in the EVC or any defined sub-set of them).

MEF 10.2 introduced two new metrics for One-way Frame Delay:

1. Delay Range The Maximal difference over time interval T between


Percentiles Py to Px
2. Mean Frame Delay The Arithmetic Mean of all measurements over
time interval T

Inter-Frame Delay Variation

Inter-Frame Delay Variation (IFDV) is the difference between the one-way


delays of a pair of selected Service Frames. This definition is borrowed from
RFC3393 where IP packet delay variation is defined. For a particular Class of
Service Identifier and an ordered pair of UNIs in the EVC, IFDV Performance is
applicable to Qualified Service Frames.

NOTE MEF 10.1 refer to Inter-Frame Delay Variation as Frame Delay


Variation.

This performance attribute is not Jitter which has a different definition and is
not appropriate for packet-based services.

The Inter-Frame Delay Variation Performance is defined as the P-percentile of


the absolute values of the difference between the Frame delays of all
Qualified Service Frame pairs that satisfy the following conditions:

The difference in the arrival times of the first bit of each Service
Frame at the ingress UNI was exactly D t.

Inter-Frame Delay Variation Performance depends on the choice of the value


for D t. Values for both D t and T typically should be chosen to achieve a
reasonable level of statistical accuracy.

The choice of the value for D t can be related to the application timing
information. As an example for voice applications where voice frames are
generated at regular intervals, D t may be chosen to be few multiples of the
inter-frame time.

Figure 5.10.F2 - Inter frame delay variation

For Multipoint EVC, the IFDV is calculated as the Maximal value over all
ordered pairs belonging to the sub-set of all possible ordered pairs.

Frame Loss Ratio

The Frame Loss Ratio (FLR) is calculated by counting the number of frames
sent (during time interval T with compliance level of green by Ingress BWP for
the given CoS ID) and the number of frames that arrived at the egress UNI.

Frame Loss Ratio = [(Number of Frames sent) - (Number of Frames Received)]


/ (Number of Frames sent)

For Multipoint EVC, the FLR is calculated as the maximum FLR value over all
ordered pairs belonging to the sub-set of all possible ordered pairs. For
example:
Figure 5.10.F3 - Frame loss ratio

Availability

Availability Performance is the percentage of time within a specified time


interval during which the Frame Loss Ratio (FLR) is small. As an example, a
service provider can define the availability performance to be measured over
a month and the value for the Availability Performance objective to be 99.9%.
In a month with 30 days and no scheduled downtime, this parameter will
allow the service to be unavailable for approximately 43 minutes out of the
whole month.

Informally, Availability Performance is based on Service Frame loss during a


sequence of consecutive small time intervals. If the previous sequence was
defined as available, and if the frame loss is high for each small time interval
in the current sequence, then the current sequence is defined as unavailable.
Otherwise the current sequence is defined as available. On the other hand, if
the previous sequence was defined as unavailable, and if frame loss is low for
each small time interval in the current sequence, then the current sequence is
defined as available. Otherwise, the current sequence is defined as
unavailable.

For Multipoint EVC, the Availability is calculated as the maximum value over
all ordered pairs belonging to the sub-set of all possible ordered pairs.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

MEF 20
User Network Interface (UNI) Type 2 Implementation Agreement

MEF 20 is a specification document developed by the Technical Committee of the MEF that provides an Implementation
Agreement for UNI Type 2.

Abstract:

"This document specifies an Implementation Agreement (IA) for MEF User to Network Interface (UNI) Type 2. This
Implementation Agreement adds new functionalities to MEF UNI Type 1 [MEF13], such as E-LMI based on [MEF16], Link
OAM based on clause 57 of [IEEE 802.3], Service OAM based on [ITU-T Y.1731] and [IEEE 802.1ag] and Protection using
Link Aggregation based on clause 43 of [IEEE 802.3].."

Download

Reference Presentation
The MEF has prepared an overview presentation which explains the MEF 20 Implementation Agreement.

Download

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

IEEE 802.1AX-2008
Link Aggregation

The 802.1AX-2008 standard developed by IEEE is a useful reference for understanding the topic of Link Aggregation in the
context of Carrier Ethernet networks. The standards document is not available directly from the MEF but may be obtained
from IEEE.

Other relevant links for Link Aggregation can be found at the Wikipedia page on the topic.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

IEEE 802.3 clause 43


Ethernet Link Aggregation

The 802.3 standard (clause 43) developed by IEEE is a useful reference for understanding Ethernet Link Aggregation in the
context of Carrier Ethernet. The standards document is not available directly from the MEF but may be obtained from
IEEE.

Other relevant links for Ethernet Link Aggregation technology can be found at the Wikipedia page on the topic.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Test Objectives 5 1 In this Section


Key UNI, ENNI, OVC, and EVC Service Attributes 5 Attributes of Carrier Ethernet
Services
5.1 Define per UNI service attributes (e.g., physical interfaces, Frame format,
Ingress/egress Bandwidth Profiles, CE-VLAN ID/EVC Map, UNI protection). 5.1

5.2 UNI Attributes


5.2 Define EVC per UNI service attributes (e.g. ingress/egress Bandwidth
5.3 EVC per UNI Attributes
Profiles).
5.4 EVC Attributes
5.3 Define per EVC service attributes (e.g., CE-VLAN ID Preservation, CoS ID 5.4.1 L2CP per MEF 6.1.1
Preservation, Relationship between Service Level Agreement and Service Level
5.5 ENNI Attributes
Specification, Class of Service).
5.6 OVC Attributes
5.4 Define OVC End Point per ENNI service attributes (e.g., ingress/egress 5.6.1 Hairpin switching
bandwidth profiles).
5.7 OVC End Point per ENNI
Attributes
5.5 Describe bandwidth profiles.
5.8 Bandwidth Profiles
5.6 Given a service scenario, describe relevant service attribute 5.9
settings/parameters.
5.10 EVC Performance Attributes

5.7 Define and describe the components of a Service Level Specification and
the relationship to Service Level Agreement. Download PDF

5.8 Define and describe ENNI attributes (e.g., physical interfaces, Frame
format, Ingress/egress Bandwidth Profiles, End Point Map, ENNI protection). Download a pdf for
offline viewing.
5.9 Define and describe OVC attributes (e.g., CE-VLAN ID Preservation, CoS ID
Preservation, Relationship between Service Level Agreement and Service Level
Specification, Class of Service, hairpin switching).
Reference Documents
5.10 Define and describe the Carrier Ethernet protection mechanisms.
MEF 6.1

MEF 10.2

MEF 13

MEF 20

MEF 26.1

IEEE 802.1AX

IEEE 802.3 clause 43

MEF-CECP Test Objectives

5 Key UNI, ENNI, OVC, and EVC


Service Attributes

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

The MEF Certification Program comprises three parts:-


In this Section
MEF Services Certification Program
6 MEF Certification of Carrier
MEF Equipment Certification Program Ethernet
MEF Professional Certification Program 6.1 Purpose of Certification

The purpose of these three certification programs is to provide the 6.2 Definitions, IAs, ATSs, Test
Plans
Subscribers, Service Providers and Operators with a neutral reference point for
compliance with and knowledge of Carrier Ethernet specifications. 6.3 Testing and Certification Process

6.4 Certification for SPs


MEF Certification in Subscriber RFPs
6.5 Certification for Vendors
Subscribers (e.g. enterprises, governmental organizations, health and
educational facilities) are buying more and more Carrier Ethernet services Download PDF
from Service Providers. When buying Carrier Ethernet services, Subscribers
often need to choose between several Service Providers in order to determine
their final choice. MEF certification of services provides a valuable starting Download a pdf for
point in the selection process of suppliers of Carrier Ethernet services. offline viewing.

MEF Certification in Service Provider and Operator RFPs

MEF Certification enables Service Providers and Operators to go to market wit


Reference Documents
Carrier Ethernet services certified as being compliant with MEF specifications
to support the following market requirements:
MEF-CECP Test Objectives
Subscribers demand of Service Providers that services be predictable in terms
of service functionality and performance. MEF certification increases the 6 MEF Certification
confidence of Subscribers that services offered to them do meet functionality
and performance requirements. Send Feedback

Services RFPs need to be less complex. MEF certification (e.g. MEF 9 and MEF Name:
14) in an RFP replace longform descriptions of Subscriber requirements.
Email:
Services certification also streamlines the interconnection services between
different Service Providers and Operators. Comments

Service Providers and Operators choosing equipment upon which to implement


Carrier Ethernet services have a very large range of vendor suppliers to choose
from. Increasingly, Service Providers and Operators are stating mandatory Send Feedback

requirements for MEF certification in their RFPs to Equipment Vendors to


reduce the number of products to be assessed. Once the field of of potential
products has been narrowed down, Service Providers and Operators save test
time in their own labs by relying on MEF certification to allow them to focus
on testing product features specific to their own needs, rather than having to
retest standardized Carrier Ethernet functionality.

MEF Certification Registry

As of March 2012, there are over 60 Service Providers around the world that
have demonstrated their commitment to Carrier Ethernet standardization
through MEF certification of their services. Similarly, more than 80 Equipment
Vendors with products certified as supporting Carrier Ethernet services in
compliance with MEF specifications.

The names of these certified Service Providers and Equipment Vendors can be
found at the MEF Certification Registry together with the respective serviecs
and products.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

MEF Certification of Carrier Ethernet In this Section


Services 6 MEF Certification of Carrier
Ethernet
Study Guide Section 6.2 6.1 Purpose of Certification

Definitions, Implementation Agreements, Abstract Test Suites and Plans 6.2 Definitions, IAs, ATSs, Test
Plans
The MEF produces three types of technical documents: 6.3 Testing and Certification Process

Technical Specifications (TS) 6.4 Certification for SPs

6.5 Certification for Vendors


The TS includes architectural and abstract models required to create a robust
platform of technical requirements and defintions. TSs are the principal
Download PDF
documents that define mandatory and optional elements, attributes etc. of a
Carrier Ethernet network (e.g. UNI, ENNI, services etc.) Examples of TSs
include MEF 6.1, MEF 10.2 and MEF 22.
Download a pdf for
Implementation Agreements (IA) offline viewing.

The IA typically quantify specific parameters and attributes called out in the
TS so that consistent, interoperable implementation can occur. The IA is
mainly used to define interfaces and system behavior. Examples of IAs include Reference Documents
MEF 20 and MEF 23.

Abstract Test Suites (ATS) MEF-CECP Test Objectives

The ATS comprises a series of tests to be used to measure conformance to 6 MEF Certification
specific MEF specifications - which can be Technical Specifications or
Implementation Agreements. The purpose of the ATS is to form the basis of Send Feedback
test plans such as those used in the MEF Certification Programs. Examples of
ATSs include MEF 9, MEF 14 and MEF 18 Name:

Test Plan
Email:
The MEF Certification Test Lab uses one or more ATSs to create a separate
Comments
Test Plan where each set of tests in the plan are based on specific test cases
in the ATS. In some cases, there will be a reference to the source TS or IA
that specified the requirement or capability that is being verified. A MEF
member that schedules certification of a service or device by the MEF Send Feedback

Certification Test Lab will receive the Test Plan as part of the preparation
process before undertaking the certification test.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

MEF Certification of Carrier Ethernet In this Section


Services 6 MEF Certification of Carrier
Ethernet
Study Guide Section 6.3 6.1 Purpose of Certification

Testing and Certification Process 6.2 Definitions, IAs, ATSs, Test


Plans
Requirements from Equipment Vendor 6.3 Testing and Certification Process

An Equipment Vendor can apply to have a service or device certified by the 6.4 Certification for SPs
MEF Certification Test Lab if it is a MEF member in good standing. The MEF 6.5 Certification for Vendors
member approaches the MEF approved test lab (Iometrix) at
certification@iometrix.com for more information on pricing and scheduling. Download PDF
The testing and certification process takes place directly between the MEF
member and Iometrix. The MEF's responsibility is to develop the underlying
Technical Specifications, Implementation Agreements, Abstract Test Suites Download a pdf for
and to approve the Test Plan developed by Iometrix. offline viewing.

Equipment Vendor Testing Process

Test plans, configuration guides and engineering support are made available Reference Documents
by Iometrix to Equipment Vendors at all stages of the vendor's preparation for
certification testing.
MEF-CECP Test Objectives
Testing takes place at the Iometrix facilities in San Francisco, California or
6 MEF Certification
under special arrangement at the vendor's facilities. Tests are typicall
scheduled at least one month in advance for a one week period at mutually
agreed dates. Send Feedback

Vendors are requested to provide on-site engineering support to configure Name:


equipment and resolve exceptions that may arise during the course of testing.
Email:
Vendors are responsible for the delivery of all components to be tested and
Iometrix supplies all test equipment and software. Comments

Requirements from Service Provider

A preliminary technical review is conducted by Iometrix to assess the Send Feedback

correspondence of a Service Provider's commercial offering, footprint and


network topology to MEF Ethernet service specifications and requirements.
Pre-qualified services are then fully described in the Service Implementation
Specification - a master document that governs the entire certification testing
process.

For Carrier Ethernet 1.0 (MEF 9 and MEF 14) certification, services submitted
for testing must be terminated at the UNI on MEF certified equipment - a list
of which can be found at the MEF Certification Registry.

No certification requirements apply to core network equipment. However,


Carrier Ethernet services offered on different transport technologies such as
SONET/SDH, DWDM and MPLS are generally subject to separate certifications.

Service Provider Certification Process

The number of sites selected for the service testing depends on the Carrier
Ethernet service. For EPL services, two sites are selected. For EVPL and E-LAN
services, three sites are selected. The sites selected will be readily accessbile
central offices distributed across the service coverage areas: Metro, regional
or national for domestic services; transnational, continental and
transcontinental for international services.

Tests are performed remotely from the Iometrix test control center using
probes supplied by Iometrix and installed by the Service Provider at each site
with a remote access connection. The IRU, AC powered probes are equipped
to test multiple services simultaneously and are attached to the Subscriber
side of the UNIs to verify end-to-end service delivery.

The time to complete a full cycle of MEF 9 and MEF 14 tests is typically two
weeks exclusive of service provisioning and troubleshooting.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

MEF Certification of Carrier Ethernet In this Section


Services 6 MEF Certification of Carrier
Ethernet
Study Guide Section 6.4 6.1 Purpose of Certification

Certification for Service Providers 6.2 Definitions, IAs, ATSs, Test


Plans
Carrier Ethernet 1.0 (MEF 9 and MEF 14) 6.3 Testing and Certification Process

Service provider members of the MEF seeking to certify one or more of their 6.4 Certification for SPs
EPL, EVPL and E-LAN services as conforming to MEF 9, MEF 14 and/or MEF 18 6.5 Certification for Vendors
specifications within the Carrier Ethernet 1.0 generations framework can apply
to the MEF Certification Test Lab (Iometrix) to schedule and prepare for Download PDF
independent, streamlined testing of their service(s).

The testing and certification in Carrier Ethernet 1.0 (MEF 9 and MEF 14) is
Download a pdf for
based on a 'Certification by ATS' model. This means that a single ATS is used offline viewing.
as the basis for each certification. MEF 9 is the Abstract Test Suite used as
the basis of the test plan for conformance to EPL, EVPL and E-LAN functional
specifications. MEF 14 is the Abstract Test Suite used as the basis of the test
plan for conformance to performance specifications for EPL, EVPL and E-LAN. Reference Documents

To date, over 60 Service Providers have certified well over 200 Carrier
Ethernet services as conforming with MEF 9 and/or MEF 14. MEF-CECP Test Objectives

6 MEF Certification
Carrier Ethernet 2.0 (E-Line, E-LAN, E-Tree and E-Access)

Carrier Ethernet 2.0 Certification becomes available in 2012. This 2.0 Send Feedback
certification transitions the industry from 'Certification by ATS' to
'Certification by Service'. Instead of certifying a service as conforming to a Name:
particular MEF ATS, the certification verifies that the service conforms to the
Email:
relevant sections of a range of Abstract Test Suites as described in the Carrier
Ethernet 2.0 Certification Blueprint.
Comments

Key Words

MEF 9; MEF 14; ATS; E-Line; E-LAN; E-Tree; E-Access


Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

MEF Certification of Carrier Ethernet In this Section


Services 6 MEF Certification of Carrier
Ethernet
Study Guide Section 6.5 6.1 Purpose of Certification

Certification for Equipment Vendors 6.2 Definitions, IAs, ATSs, Test


Plans
Carrier Ethernet 1.0 (MEF 9, MEF 14 and MEF 18) 6.3 Testing and Certification Process

Equipment vendor members of the MEF seeking to certify one or more of their 6.4 Certification for SPs
equipment products as conforming to MEF 9, MEF 14 and/or MEF 18 6.5 Certification for Vendors
specifications within the Carrier Ethernet 1.0 generations framework can apply
to the MEF Certification Test Lab (Iometrix) to schedule and prepare for Download PDF
independent, streamlined testing of their product(s).

The testing and certification in Carrier Ethernet 1.0 (MEF 9, MEF 14 and MEF
Download a pdf for
18) is based on a 'Certification by ATS' model. This means that a single ATS is offline viewing.
used as the basis for each certification. MEF 9 is the Abstract Test Suite used
as the basis of the test plan for conformance to EPL, EVPL and E-LAN
functional specifications. MEF 14 is the Abstract Test Suite used as the basis
of the test plan for conformance to performance specifications for EPL, EVPL Reference Documents
and E-LAN. MEF 18 is the Abstract Test Suite used as the basis of the test plan
for conformance to functional and performance specifications for circuit
MEF-CECP Test Objectives
emulation of TDM circuits over Carrier Ethernet networks.
6 MEF Certification
To date, over 80 Service Providers have certified nearly 1,000 Carrier Ethernet
services as conforming with MEF 9, MEF 14 and/or MEF 18.
Send Feedback
Carrier Ethernet 2.0 (E-Line, E-LAN, E-Tree and E-Access)
Name:
Carrier Ethernet 2.0 Certification becomes available in 2012. This 2.0
Email:
certification transitions the industry from 'Certification by ATS' to
'Certification by Service'. Instead of certifying a product as conforming to a
Comments
particular MEF ATS, the certification verifies that the product enables the
delivery of a service (E-Line, E-LAN, E-Tree and/or E-Access) conforming to
the relevant sections of a range of Abstract Test Suites as described in the
Carrier Ethernet 2.0 Certification Blueprint. Send Feedback

Key Words

MEF 9; MEF 14; MEF 18; ATS; E-Line; E-LAN; E-Tree; E-Access

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Test Objectives 6 1 In this Section


Certification 6 MEF Certification of Carrier
Ethernet
6.1 Describe the Certification process and requirements for networking
equipment. 6.1 Purpose of Certification

6.2 Definitions, IAs, ATSs, Test


6.2 Describe the Certification process and requirements for services delivered Plans
by a service provider. 6.3 Testing and Certification Process

6.3 Describe what is covered by MEF 9, MEF 14, and MEF 18 Certifications. 6.4 Certification for SPs

6.5 Certification for Vendors


6.4 Describe the benefits of MEF Certification for equipment vendors, Service
Provider, and end users. Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF-CECP Test Objectives

6 MEF Certification

Send Feedback

Name:

Email:
Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Typical Target Applications Using Carrier In this Section


Ethernet Services 7 Typical Applications Using Carrier
Ethernet Services
Study Guide Section 7.1 7.1 Access to IP Services

Access to IP Services 7.2 Wholesale Access Services

7.3 Mobile Backhaul


Many of today's enterprise applications are transported using IP. This can be
any Internet application but especially relevant are applications and content 7.3.1 EVPL in Mobile Backhaul
consumption from application content providers (e.g. VoIP gateway, video 7.3.2 MEF 22 Use Cases
content, etc.). Subscribers to a CEN Service Provider can take advantage of 7.4 Business Services
the benefits of Carrier Ethernet services when consuming IP services.
7.5 TDM Private Line Replacement

When connecting to the Internet, the CEN can provide the connectivity 7.6 Frame Relay/ATM Replacement
required to the ISP's POP facilitating any required bandwidth with the 7.7 WDM Private Network
granularity, manageability and service performance supported by Carrier Replacement
Ethernet. Likewise, when a subscriber wants to connect to an application such
as a VoIP gateway, this too can be delivered over Carrier Ethernet. One of the Download PDF
benefits to the Subscribers is that the same CEN Service Provider that provides
services for corporate interconnectivity can also provide the Internet
connectivity. Download a pdf for
offline viewing.
There are two Ethernet services that are appropriate for this application:

1. EVPL between each customer and the content provider or ISP.


2. EVP-Tree where the content provider/ISP is designated as a root and Reference Documents
each subscriber is designated as a leaf ensuring that each subscriber's
traffic cannot be seen by other subscribers. MEF 6.1

MEF 8
The EVPL is simpler from an implementation point of view, but has scalability
issues, requiring many EVPLs. Also, the bandwidth is not shared between MEF 10.2
subscribers, which may be a problem for large deployments in view of the MEF 26.1
fact that Internet access is often bursty and used at different times of the MEF 28
day by different subscribers.
MEF Reference Presentation: Access
Technologies
In the following example an ISP named Turbo 2000 Internet Access Inc. is
MEF Reference Presentation: Mobile
connected to three enterprises for Internet Access. Each customer connects to
Backhaul
the ISP's POP using EVPL with CE-VLAN ID of 2000. This enables the customer
MEF White Paper: CESoE
to use the same UNI port for other services (e.g. Disaster Recovery, L2VPN,
etc.) using different CE-VLAN ID(s).
MEF-CECP Test Objectives

7 Target Applications for Carrier


Ethernet Services

Send Feedback

Name:
Figure 7.1.F1: Example - Turbo 2000 Internet Access, Inc.

Email:
In this example, assume that Customer 1 has purchased a 300 Mbps downlink
service and 100 Mbps uplink service for connecting to the ISP over an Comments
unprotected UNI that will be used for another service too. The service has a
single CoS, with the following performance objectives measured over a 1 hour
period:
Send Feedback

Frame loss ratio = 0.1%


One-Way Mean Frame Delay = 30 msec

The appropriate UNI Attributes for Customer 1 are:

Table 7.1.T1: Example - UNI Service Attributes

The appropriate EVC attributes for the EVPL connecting Customer 1 to the ISP
POP are:

Table 7.1.T2: Example - EVC Service Attributes

Table 7.1.T3: Example - EVC per UNI Service Attributes

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Typical Target Applications Using Carrier In this Section


Ethernet Services 7 Typical Applications Using Carrier
Ethernet Services
Study Guide Section 7.2 7.1 Access to IP Services

Wholesale Access Services 7.2 Wholesale Access Services

7.3 Mobile Backhaul


Carrier Ethernet Service Providers often are required to provide service to
locations outside their CEN reach ('offnet'). In such cases, the SP can buy a 7.3.1 EVPL in Mobile Backhaul
tunnel service from an Access Service Provider. The latter may not be a full 7.3.2 MEF 22 Use Cases
CEN Operator, but rather a simplified service where the Access SP provides 7.4 Business Services
such service utilizing a relatively simple device, often referred to as a NID
7.5 TDM Private Line Replacement
(Network Interface Device). This NID is typically co-located at the End-User's
7.6 Frame Relay/ATM Replacement
site and acts as the demarcation point for the service. It only provides a
subset of the UNI functionality. The balance (and vast majority) of the UNI 7.7 WDM Private Network
Replacement
functionality is implemented "behind" the ENNI in the Service Provider's
network at a reference point known as the Virtual UNI (or VUNI). A tunnel is
Download PDF
created between the VUNI at the ENNI and the RUNI at the NID. This tunnel is
referred to as a UNI Tunnel Access (UTA), and provides a largely transparent
connectivity between the RUNI and the CEN's ENNI. Typically, most of the
Download a pdf for
UNI-N functions are implemented at the VUNI, while the RUNI functionality is offline viewing.
very basic.

The UTA service is very transparent. The Access SP provides a transparent EPL
with no service awareness. At the VUNI, the incoming service frames are Reference Documents
mapped to different EVCs based on the UNI CE-VLAN ID/EVC map.
MEF 6.1
The following figure illustrates this service set-up:
MEF 8

MEF 10.2
MEF 26.1

MEF 28

MEF Reference Presentation: Access


Figure 7.2.F1 Technologies
MEF Reference Presentation: Mobile
Backhaul
UTA Service Attributes
MEF White Paper: CESoE
This tunnel has a single CoS at the Access SP and is not service aware. There
could be a single per UNI bandwidth profile applied on all service frames MEF-CECP Test Objectives
mapped to the tunnel. L2CP rules must tunnel all protocols in order to
7 Target Applications for Carrier
provide the highest level of transparency possible. Ethernet Services
In some scenarios, there are more than 2 operators involved in the service
delivery. The following example presents a case where Operator 1 is the SP
Send Feedback
and 2 EVCs associate a RUNI served by Operator 3. A single UTA is created to
tunnel all traffic to/from this RUNI up to the VUNI at the ENNI-N on Operator
Name:
1 side of the ENNI between Operator 1 and Operator 2. The VUNI provides the
OVC end-point for each OVC associated with these EVCs. Email:

Comments

Send Feedback

Figure 7.2.F3

The UTA OVC End Point attributes at the RUNI have some additional
constraints which are described in the following table:

Table 7.2.T1

The UTA OVC attributes have some additional constraints which are described
in the following table:

Table 7.2.T2

The ENNI has only a single additional constraint: At an ENNI in the VUNI
Provider CEN, the End Point Type within an End Point Map for ENNI frames
mapped to a VUNI must the value of VUNI

For more details, refer to MEF 28.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Typical Target Applications Using Carrier In this Section


Ethernet Services 7 Typical Applications Using Carrier
Ethernet Services
Study Guide Section 7.3 7.1 Access to IP Services

Mobile Backhaul 7.2 Wholesale Access Services

7.3 Mobile Backhaul


The term Mobile Backhaul refers to the network between the base station
sites (NodeB, eNodeB, BTS) and the network controller site (Radio Network 7.3.1 EVPL in Mobile Backhaul
Controller = RNC, S-GW). This network is called the Radio Access Network 7.3.2 MEF 22 Use Cases
(RAN) by the 3GPP. Mobile backhaul networks have traditionally been realized 7.4 Business Services
using TDM and ATM technologies. However, next generation mobile equipment
7.5 TDM Private Line Replacement
and networks are based on Ethernet. Carrier Ethernet services provide the
7.6 Frame Relay/ATM Replacement
connectivity in the mobile backhaul network, possibly in a converged network,
together with traditional fixed services. Ethernet is becoming increasingly 7.7 WDM Private Network
Replacement
available, even at sites with access to legacy services. This opportunity allows
mobile operators to make the choice of which transport technology to utilize.
Download PDF
In some cases where there is circuit based equipment that is co-located with
newer Ethernet based equipment, it may be suitable to use a single transport
technology to lower costs. A mobile backhaul network can take on a
Download a pdf for
constellation of forms depending on factors such as transport technology, offline viewing.
mobile standard, operator preference, etc. Figure 1 describes a simple
reference model where the mobile backhaul is a single Carrier Ethernet
Network (CEN) that connects the mobile network nodes, referred herein as
RAN Customer Edge (RAN CE). RAN CE is a generic term that identifies a Reference Documents
mobile network node or site, such as a RAN Network Controller (RAN NC) or a
RAN Base Station (RAN BS). A RAN NC may be a single network controller or a MEF 6.1
site composed of several network controllers including: OSS, WCDMA Radio MEF 8
Network Controller, S-GW or synchronization server. A RAN BS may also be a
MEF 10.2
single base station or a collection of several base stations. Multiple RAN NCs
MEF 26.1
and RAN BSs can be connected to the CEN at any given time.
MEF 28

MEF Reference Presentation: Access


Technologies

MEF Reference Presentation: Mobile


Backhaul

MEF White Paper: CESoE

Figure: 7.3.F1
[Source: MEF 22, Figure 1] MEF-CECP Test Objectives

More complex scenarios involving multiple CEN domains are possible. Note 7 Target Applications for Carrier
Ethernet Services
that the CEN SP provides a service to a mobile operator and not to end users
(mobile users).
Send Feedback
For a GSM network with 3G and 3.5G (known as HSPA) technology, each NodeB
is connected to a single RNC location, which may encompass several co- Name:
located RNCs. NodeBs do not communicate directly one with the other (note
that in LTE this is no longer the case). Therefore, there are two suitable Email:
Carrier Ethernet services:
Comments

1. EVPL between each Base Station site to the RNC site


2. EP-Tree where each Base Station site is designated as a leaf and the
RNC site is designated as a root.
Send Feedback

The EVPL approach is illustrated in the following figure:

Figure: 7.3.F2
[Source: MEF 22, Figure 8]

For more detailed information on use of EVPLs for mobile backhaul, go to


EVPL in Mobile Backhaul.

The EP-Tree option is illustrated in the following figure:

Figure: 7.3.F3
[Source: MEF 22, Figure 11]

The mobile network has several classes of service for different applications
that use the network. The following table describes MEF 22 recommended
mapping between the 3GPP classes and the CEN CoSs:

Table: 7.3.T1
[Source: MEF 22, Table 2]

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Typical Target Applications Using Carrier In this Section


Ethernet Services 7 Typical Applications Using Carrier
Ethernet Services
Study Guide Section 7.5 7.1 Access to IP Services

TDM Private Line Replacement 7.2 Wholesale Access Services

7.3 Mobile Backhaul


For many years the popular service to connect PBXs over a public network was
implemented via Private Line services offered by Service Providers using their 7.3.1 EVPL in Mobile Backhaul
SONET/SDH networks. In these services, each location has a PBX connected via 7.3.2 MEF 22 Use Cases
an E1/T1 (or bundled E1/T1 for increased bandwidth) to an ADM switch of the 7.4 Business Services
SONET/SDH network.
7.5 TDM Private Line Replacement
For example, in the following figure we see a Private Line service providing 2
7.6 Frame Relay/ATM Replacement
Mbps between 2 PBXs.
7.7 WDM Private Network
Replacement

Download PDF

Figure 7.5.F1 - PBX over legacy PDH and SONET


Download a pdf for
E-Line is the modern solution for connecting PBXs and supports replacement offline viewing.
of TDM Private Line services. Carrier Ethernet Service Providers can offer not
only TDM Private Line replacement, but also a variety of other Carrier
Ethernet based solutions using the same infrastructure.
Reference Documents

The solution is implemented by implementing a CESoETH service between the MEF 6.1
two locations. MEF 8

MEF 10.2
MEF 26.1

Figure 7.5.F2 - PBX over Carrier Ethernet MEF 28

MEF Reference Presentation: Access


The service can be provided using EPL or EVPL. EVPL allows the Service Technologies
Provider to offer another communication service (e.g. L2VPN) for the
MEF Reference Presentation: Mobile
customer utilizing the same UNI port. Backhaul
In order to provide the required bandwidth, the service should offer the MEF White Paper: CESoE
following:
CIR=2 Mbps, CBS=10,000 bytes, EIR=0, EBS=0 MEF-CECP Test Objectives
Performance objectives: Frame Delay, Inter-Frame Delay Variation and Loss
7 Target Applications for Carrier
Ratio to ensure low loss rate and minimal delay variation.
Ethernet Services


Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Typical Target Applications Using Carrier In this Section


Ethernet Services 7 Typical Applications Using Carrier
Ethernet Services
Study Guide Section 7.6 7.1 Access to IP Services

Frame Relay/ATM Replacement 7.2 Wholesale Access Services

7.3 Mobile Backhaul


Some WAN services today are offered over ATM public networks or in some
cases over Frame Relay (FR). These legacy networks enable different types of 7.3.1 EVPL in Mobile Backhaul
transport protocols (IP, TDM, etc.) over virtual circuits. However, these 7.3.2 MEF 22 Use Cases
services are often highly bandwidth constrained and are relatively expensive. 7.4 Business Services
Furthermore, they mainly provide point-to-point connectivity (although some
7.5 TDM Private Line Replacement
ATM networks support Ethernet L2VPN using technologies like LAN Emulation
7.6 Frame Relay/ATM Replacement
(LANE).
7.7 WDM Private Network
The following figure describes such a scenario where an enterprise connects Replacement
its 3 locations over 3 point-to-point circuits from a WAN service provider who
operates an ATM or FR network: Download PDF

Download a pdf for


offline viewing.

Reference Documents

Figure 7.6.F1 - Legacy ATM-FR


MEF 6.1
In this set-up, each Network Edge at each location would have an ATM or FR MEF 8
interface(s) pointing towards the WAN provider. For the sake of this example,
MEF 10.2
we can assume that each circuit provides 2 Mbps guaranteed bandwidth
between each location. MEF 26.1

MEF 28
The need for more bandwidth at a lower price, and with a more sophisticated
MEF Reference Presentation: Access
and dynamic service provisioning, presents the opportunity for a Carrier Technologies
Ethernet Service Provider to offer a very attractive alternative.
MEF Reference Presentation: Mobile
Backhaul
The customer can buy one of the following two services and replace the
current Network Edge with a switch/Customer Edge: MEF White Paper: CESoE

1. 3 EVPLs, each having ingress BWP per EVC with CIR=2 Mbps, CBS=20 MEF-CECP Test Objectives
Kbytes and possibly also allowing for some additional traffic using EIR=2
7 Target Applications for Carrier
Mbps, EBS=20 Kbytes Ethernet Services
2. Single EVP-LAN with ingress BWP of 4 Mbps CIR. The choice of EVP-LAN
enables the enterprise to consider buying additional services like Send Feedback
Internet access. For this reason, the Service Provider facilitates the
addition of new Carrier Ethernet services over the same UNI. Name:

The first alternative is depicted below, where a site requires a single UNI port
Email:
for the 2 EVPLs:
Comments

Send Feedback

Figure 7.6.F2 - Carrier Ethernet replacing ATM-FR

Traffic Forwarding

In the ATM network, each incoming frame would have been classified and
directed towards the appropriate site. This would be done by setting the
appropriate ATM header fields (VPi, VCi). In the case of Carrier Ethernet
services , the CE would put an appropriate CE-VLAN ID at location A. The CE-
VLAN ID/EVC map would be:

Figure 7.6.T1 - Table of CE-VLAN ID per EVC

All other CE-VLAN IDs are not expected and therefore will be dropped.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Typical Target Applications Using Carrier In this Section


Ethernet Services 7 Typical Applications Using Carrier
Ethernet Services
Study Guide Section 7.3.1 7.1 Access to IP Services

EVPL in Mobile Backhaul 7.2 Wholesale Access Services

7.3 Mobile Backhaul


The following explanation expands on the use case where a distinct EVPL
service is implemented between each RAN BS and RAN NC with the following 7.3.1 EVPL in Mobile Backhaul
configurations: 7.3.2 MEF 22 Use Cases

7.4 Business Services


The RAN NC uses a configured CE-VLAN ID to identify a RAN BS in the
mobile backhaul network. The CE-VLAN ID is mapped at the RAN NC 7.5 TDM Private Line Replacement

UNI-N and at the RAN BS UNI-N to the EVC connecting the RAN BS and 7.6 Frame Relay/ATM Replacement
RAN NC. This implies that each RAN NC UNI can distinguish up to four 7.7 WDM Private Network
thousand distinct RAN BSs. Replacement
At the RAN NC side, the CE-VLAN ID assignment is performed at the
UNI-C. At the RAN BS side the CE-VLAN ID assignment can be either Download PDF
performed at the UNI-C or at the UNI-N depending on which option
(described later in this paragraph) is selected.
Bundling is disabled, which means that all traffic types are sent on Download a pdf for
offline viewing.
the same CE-VLAN ID.
Multiple Classes of Service can be supported. They are differentiated
through either PCP or DSCP marking. CoS ID is identified by
<EVC+PCP> or <EVC+DSCP>. In this use case CoS ID preservation is Reference Documents
enabled and 4 classes of service are supported.
MEF 6.1
The table below shows an example of how Carrier Ethernet services can be
delivered in the mobile backhaul according to the assumptions made for the MEF 8
present use case. MEF 10.2
MEF 26.1

MEF 28

MEF Reference Presentation: Access


Technologies

MEF Reference Presentation: Mobile


Backhaul
Table 7.3.1.T1 - EVC per EVP-Line
MEF White Paper: CESoE
This use case may also take into consideration additional factors that result in
four possible options, each using a different service frame format at the
MEF-CECP Test Objectives
RAN BS UNI-C:
7 Target Applications for Carrier
Option A : The CE-VLAN ID Preservation Attribute is enabled and the Ethernet Services
RAN BS UNI-C transmits/receives tagged service frames to/from the
RAN BS UNI-N with the CE-VLAN ID preconfigured for the RAN BS Send Feedback
itself. Either PCP or DSCP values specify different Classes of Service.
Option B : The CE-VLAN ID Preservation Attribute is disabled and the Name:
RAN BS UNI-C transmits/receives untagged service frames to/from
UNI-N where they are mapped to the default CE-VLAN ID. DSCP Email:

values specify different Classes of Service. A default mapping of Comments


untagged service frames is configured at each RAN BS UNI-N.
Option C : The CE-VLAN ID Preservation Attribute is disabled and the
RAN BS UNI-C transmits priority tagged service frames towards the
UNI-N, where they are mapped to the default CE-VLAN ID, and Send Feedback

receives untagged frames. PCP values specify different Classes of


Service. A default mapping of priority tagged service frames is
configured at each RAN BS UNI-N.
Option D : The CE-VLAN ID Preservation Attribute is disabled and BS
UNI-C transmits/receives tagged service frames to/from UNI-N with a
preconfigured CE-VLAN ID, identical for each BS. Either PCP or DSCP
values specify different Classes of Service.

Options B, C and D may ease the configuration of the RAN BS because they
are agnostic to the CE-VLAN ID value used to identify Service Frames in the
mobile backhaul.

The following shows an example of the CE-VLAN ID / EVC mapping for each
option and the configuration both at the RAN BS UNI-N and at the
RAN NC UNI-N:

Table 7.3.1.T2 - EVC ID at RAN NC UNI-NI

The symbol * indicates the CE-VLAN ID value used at the UNI for both
untagged and priority tagged frames.

The CoS ID Preservation attribute should be enabled for each option in order
to simplify configuration.

Note that the CoS ID per <EVC> model can also be supported by this use case
if the assumption to use a single EVP Line per RAN BS that supports multiple
services is removed. According to this new assumption each RAN BS can
support multiple EVP Lines whereby mobile traffic classes may be grouped into
different EVCs. Each EVP Line is mapped to a unique CE-VLAN ID and so each
CE-VLAN ID identifies a specific set of services between the RAN NC and a
specific RAN BS.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Typical Target Applications Using Carrier In this Section


Ethernet Services 7 Typical Applications Using Carrier
Ethernet Services
Study Guide Section 7.3.2 7.1 Access to IP Services

MEF 22 Use Cases 7.2 Wholesale Access Services

7.3 Mobile Backhaul


Based on the basic reference model described above, it is possible to derive
the use cases below, where each use case presents a possible deployment 7.3.1 EVPL in Mobile Backhaul
scenario using Ethernet services. Although the use cases are not exhaustive of 7.3.2 MEF 22 Use Cases
all possible deployment scenarios, they are the foundation of the Mobile 7.4 Business Services
Backhaul Implementation Agreement Phase 1 (MEF 22).
7.5 TDM Private Line Replacement
Use cases 1a and 1b below depict deployments where the RAN BS and RAN NC
7.6 Frame Relay/ATM Replacement
can not be directly connected to a UNI because they have non-Ethernet based
interfaces, such as ATM or TDM. These interfaces are illustrated in Figure 1 7.7 WDM Private Network
Replacement
and Figure 2 as Non-Ethernet I/F. Use cases 1a and 1b require that the RAN
CEs first connect to a Generic Inter-working Function (GIWF), which in turn is
Download PDF
connected to the UNI.

Download a pdf for


offline viewing.

Figure 1 (7.3.2.F1) - Generic Interworking Function with Legacy MBH Network


[Source: MEF 22, Figure 2]
Reference Documents
Figure 1, above, illustrates a split access scenario - Use Case 1 - where there
are two parallel networks, a legacy network and CEN, that transport different MEF 6.1
types of mobile traffic. This may be appropriate in cases where an Operator MEF 8
wants to offload low priority, high bandwidth traffic from the legacy network
MEF 10.2
to the CEN in order to scale according to network demand. How and where
MEF 26.1
traffic is split and sent over the legacy network is out of scope for this Study
Guide. MEF 28

MEF Reference Presentation: Access


Technologies

MEF Reference Presentation: Mobile


Backhaul

MEF White Paper: CESoE


Figure 2 (7.3.2.F2) - Generic Interworking Function without Legacy Network
[Source: MEF 22, Figure 3]
MEF-CECP Test Objectives
Figure 2 depicts a deployment scenario - Use Case 2 - where the legacy
7 Target Applications for Carrier
network has been substituted by a Carrier Ethernet Network and where the Ethernet Services
RAN CE is connected to the CEN via a GIWF. In this use case all traffic from
the RAN CE is transported over the CEN using Ethernet services. The last two
Send Feedback
use cases illustrate RAN CE equipment that can be connected directly to the
UNI via an Ethernet interface eliminating the need for a GIWF. Use Case 2 is
Name:
similar to Usase Case 1 in the way the CEN is used to offload certain traffic,
such as low priority high bandwidth traffic, from the legacy network. How the Email:
RAN CE transports real-time and synchronization traffic via the legacy network
is out of scope. Comments

Send Feedback

Figure 3 (7.3.2.F3) - UNI with MBH Legacy Network


[Source: MEF 22, Figure 4]

Lastly, Figure 4 shows the case where all traffic is transported via Ethernet
services over the CEN. How the Ethernet services are implemented may vary
depending on the mobile technology that is deployed, vendor equipment,
operator requirements, and the type of services offered by the carrier.

Figure 4 (7.3.2.F4) - UNI without Legacy MBH Network


[Source: MEF 22, Figure 5]

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Typical Target Applications Using Carrier In this Section


Ethernet Services 7 Typical Applications Using Carrier
Ethernet Services
Study Guide Section 7.4 7.1 Access to IP Services

Business Services 7.2 Wholesale Access Services

7.3 Mobile Backhaul


Carrier Ethernet for Business covers a wide variety of communication services
offered to enterprises, SMBs and corporate offices of all sizes. The following 7.3.1 EVPL in Mobile Backhaul
are the areas in which high-bandwidth, low-latency and reduced-cost are 7.3.2 MEF 22 Use Cases
enabling and improving applications. 7.4 Business Services

Site-to-site access 7.5 TDM Private Line Replacement

Data center & server consolidation 7.6 Frame Relay/ATM Replacement


Business continuity/disaster recovery 7.7 WDM Private Network
Service orientated architecture Replacement
Software as a service
Converged networking Download PDF

Carrier Ethernet provides scalable, efficient and easy to manage solutions for
enabling all of these services and applications. Download a pdf for
offline viewing.
For example, the following use case features a fashion retailer with over 200
store locations.

Limited bandwidth on legacy dial-up network required sending sales and stock
Reference Documents
information in batch up-loads overnight. This delayed fulfilling restocking,
resulting in the inability to quickly meet customer demand and poor MEF 6.1
utilization of resources. Security is a constant issue, but the CCTV is
MEF 8
essentially an offline and reactive service.
MEF 10.2
The goals of the project in this use case are to increase capacity, improve
MEF 26.1
network resiliency and scalability, provide the flexibility to simplify addition
MEF 28
and removal of new stores matching retail environment and reduce cost by
converging voice and data networks via VoIP and to improve security and fight MEF Reference Presentation: Access
Technologies
stock shrinkage with national central CCTV monitoring ability.
MEF Reference Presentation: Mobile
The low cost solution is based on a mixture of enabling transport technologies. Backhaul

The EP-Tree service type is implemented to ensure separation between the MEF White Paper: CESoE
divisional operations under the supervision of the corporate headquarters. This
solution is based on standardized, certified, Ethernet Business Services. MEF-CECP Test Objectives

7 Target Applications for Carrier


The following figure depicts the solution: Ethernet Services

Send Feedback

Name:

Email:

Figure 7.4.F1 - Example Business Services Application Comments

EP-Tree is selected in order to facilitatea high-degree of transparency


between the locations. It should be noted that each store location can
communicate with any node designated as a root (HQ is this case), for Send Feedback

example, enabling dual-homed UNI for additional resiliency, or enabling


connectivity to a central storage location. The service will support two CoSs:
H for delay sensitive applications like VoIP and disaster recovery and L for
any other type of traffic. H CoS is marked with PCP=5. L CoS is marked with
PCP=0

In this use case the following attributes should be set at the HQ UNI:

Figure 7.4.T1

The appropriate EVC attributes are:

Figure 7.4.T2
Figure 7.4.T3

In some cases when an enterprise wishes to buy a site-to-site service from an


SP, the reality is that the SP cannot reach all of the locations. This is because
the SP does not have local facilities in the area to serve a site. In such a case,
the SP contracts with another CEN Operator that has local facilities into these
locations in order to provide the service.

In the following example we have two services:

Point-to-point EVC between 2 subscriber sites (orange line)

Multipoint to Multipoint service between 4 locations (red line)

Figure 7.4.F2 - Operators and Service Providers for Business Services


Applications

The SP that also operates a CEN (right side) contracts Operator (left CEN) in
order to reach all locations.

The Point to Point EVC is realized by 2 point-to-point OVCs (OVC A and OVC
B) This can be an EVPL or EPL. For our example, we shall assume that the E-
Line is EPL.

The Multipoint to Multipoint EVC is realized by 2 multipoint-to-multipoint


OVCs (OVC C and OVC D).

However, the subscriber's UNIs are configured and the service is managed by
the SP, with no customer awareness of the existence of the ENNI and OVCs.

The following attributes should be set for OVC A:

Figure: 7.4.T4

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Typical Target Applications Using Carrier In this Section


Ethernet Services 7 Typical Applications Using Carrier
Ethernet Services
Study Guide Section 7.7 7.1 Access to IP Services

WDM Private Network Replacement 7.2 Wholesale Access Services

7.3 Mobile Backhaul


A WDM Private Network refers to the situation in which an enterprise
customer connects WDM links between its locations in order to obtain a high- 7.3.1 EVPL in Mobile Backhaul
bandwdith low-latency connection between its sites. Usually, these networks 7.3.2 MEF 22 Use Cases
are point-to-point where each router's port is connected to a specific router 7.4 Business Services
port at another location.
7.5 TDM Private Line Replacement
Such a scenario is illustrated in the following figure:
7.6 Frame Relay/ATM Replacement

7.7 WDM Private Network


Replacement

Download PDF

Download a pdf for


Figure 7.7.F1 - 3 E-Lines replace WDM offline viewing.

At each location, the router identifies the destination of each packet, based
on IP or MAC addresses, and forwards the packet to the correct port. Each of
these connections can be configured to, for example, 2 Gbps. For each
Reference Documents
connection there is full transparency, as the WDM network is packet unaware
and VLAN unaware. The disadvantage of this private solution is the need to MEF 6.1
install and manage the WDM links and also may not be feasible for long-haul
MEF 8
scenarios. This solution requires leasing dark fiber facilities from an Operator,
which is typically a very expensive offering, making this solution even less MEF 10.2
attractive for long-haul applications. Also, this type of solution cannot scale MEF 26.1
easily as the enterprise adds more locations. MEF 28

Carrier Ethernet offers a comparable solution where all locations are MEF Reference Presentation: Access
Technologies
connected using an EP-LAN service, which enables the relatively simple and
MEF Reference Presentation: Mobile
fast addition of new sites as the enterprise grows. It provides the same
Backhaul
transparency as a WDM network and supports any-to-any communication
MEF White Paper: CESoE
supporting new services like shared storage, video distribution etc.

The solution is depicted below: MEF-CECP Test Objectives

7 Target Applications for Carrier


Ethernet Services

Send Feedback

Name:

Figure 7.7.F2 1 E-LAN replaces WDM Email:

Example Comments

All three UNI ports will be configured to All-to-One bundling and therefore
require no VLAN configuration. Furtheremore, this service can now provide
multiple CoSs, each with its own bandwidth profile and performance
Send Feedback
requirements. In order to facilitate the legacy service example of 2 Gbps
between each 2 locations, the following bandwidth profile can be set:

Ingress bandwidth profile per UNI:

CIR = 4 Gbps

CBS = 1 Mbytes

EIR = 2 Gbps [Note: this enables the customer to use more


bandwidth than before, but without performance guarantees]

EBS = 256 Kbytes

And egress bandwidth profile per UNI:

CIR = 4 Gbps

CBS = 1 Mbytes

EIR = 2 Gbps EBS = 256 Kbytes

L2CP processing will be set to tunnel to the EVC all types of L2CPs in order to
provide the same transparency as the WDM private network previously
provided. Best of all, this Carrier Ethernet service does not require the
customer to lease costly dark-fiber services between locations.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

MEF 8
Implementation Agreement for the Emulation of PDH Circuits over Metro Ethernet Networks

MEF 8 is a specification document developed by the Technical Committee of the MEF that provides an Implementation
Agreement for emulation of TDM services over Carrier Ethernet.

Abstract:

"This document provides an implementation agreement for the emulation of TDM services belonging to the Plesiochronous
Digital Hierarchy (PDH) across a Metro Ethernet Network. Specifically it covers emulation of Nx64 kbit/s, DS1, E1, DS3
and E3 circuits. Generically this is referred to as Circuit Emulation Services over Ethernet (CESoETH)."

Download

Reference Presentation
The MEF has prepared an overview presentation which explains the MEF 8 specification.

Download

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

MEF 28
External Network Network Interface (ENNI) Support for UNI Tunnel Access and Virtual UNI
Technical Specification

MEF 28 is a specification document developed by the Technical Committee of the MEF that defines the External Network
Network Interface (ENNI) support for UNI Tunnel Access and Virtual UNI.

Abstract:

"The External Network Network Interface (ENNI) is a reference point that describes the interface between two Metro
Ethernet Networks (MENs) [Editor: Carrier Ethernet Networks (CENs)] and is intended to support the transparent
extension of Ethernet services across multiple Network Operator MENs [Editor: CENs], where each Network Operator MEN
[Editor: CEN] is under the control of a distinct administrative authority. This Technical Specification extends the ENNI by
defining the UNI Tunnel Access (UTA) which associates a Virtual UNI (VUNI), a remote UNI, and at least one supporting
OVC."
Download

Reference Presentation

The MEF has prepared an overview presentation which explains the MEF 28 specification.

Download

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

MEF Reference Presentation


Optimizing Mobile Backhaul

This presentation provides an overview of how Carrier Ethernet is used to maximize operational use of mobile backhaul
connectivity for cellular base stations.

Download

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

MEF White Paper


Introduction to Circuit Emulation Services over Ethernet

Abstract:

"This paper provides an introduction to Circuit Emulation Services over Ethernet (CESoE) enabling the support of
synchronous services such as T1/E1 over an asynchronous Ethernet infrastructure. The paper discusses the benefits of
CESoE to service providers offering Ethernet access services, as well as to subscribers to those services in various
applications. Finally, the paper discusses the current activities of the MEF in standardizing and promoting CESoE."

Download


Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Test Objectives 7 1 In this Section


Target Applications for Ethernet Services 7 Typical Applications Using Carrier
Ethernet Services
7.1 Describe wholesale access services, retail commercial/business services,
mobile backhaul services, Ethernet access to IP services, and supporting 7.1 Access to IP Services

legacy services over Ethernet. 7.2 Wholesale Access Services

7.3 Mobile Backhaul


7.2 Describe which UNI or ENNI attribute values are selected for a given target
7.3.1 EVPL in Mobile Backhaul
application.
7.3.2 MEF 22 Use Cases
7.3 Describe which EVC or OVC attribute values are selected for a given target
7.4 Business Services
application.
7.5 TDM Private Line Replacement
7.4 Describe how specific service requirements of a target application (e.g., 7.6 Frame Relay/ATM Replacement
frame relay, Dedicated Internet Access, DSL or Cable Internet access, TDM
7.7 WDM Private Network
Private Lines, WDM private network are met using Ethernet services. Replacement

7.5 Given a scenario, determine appropriate Ethernet services.


Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 6.1

MEF 8

MEF 10.2
MEF 26.1

MEF 28

MEF Reference Presentation: Access


Technologies

MEF Reference Presentation: Mobile


Backhaul

MEF White Paper: CESoE

MEF-CECP Test Objectives

7 Target Applications for Carrier


Ethernet Services

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Positioning of Carrier Ethernet with other In this Section


technologies 8 Positioning of Carrier Ethernet
with other technologies
Study Guide Section 8.1 8.1 Carrier Ethernet and L2VPN

Carrier Ethernet and L2VPN 8.2 Carrier Ethernet and IP

8.3 Carrier Ethernet and TDM


L2VPN over Metro or Wide Area Network is a service where a customer
connects several locations with Layer 2 connectivity, that is, without IP
Download PDF
routing. In the past, Service provides offered this service over Frame Relay
(FR) for relatively low-bandwidth applications of 56 Kbps to 40 Mbps and over
ATM for higher bandwidth, b ut even ATM networks would not support services
Download a pdf for
that require more than few hundred Mbps. offline viewing.

Each location connects to the SP's network using a switch that maps incoming
traffic flows to ATM/FR PVC (Permanent Virtual Circuit) having fixed CIR and
burst setting, with no ability for bandwidth sharing between different
Reference Documents
applications of the subscriber.
MEF 6.1
In most cases the service offered was point-to-point.
MEF 8
Note: ATM supported LANE (LAN Emulation) but this was never a widely used
MEF 10.2
service.
MEF 22.1
The network that realized the service was often TDM-based, providing very MEF White Paper: CESoE
predictable bandwidth and delay performance and high level of fault IETF RFC 4448
management and resiliency. However, these legacy networks were expensive
to manage, had a relatively limited bandwidth that could be allocated to a MEF-CECP Test Objectives
single service, and had relatively high price points.
8 Comparing and Positioning Carrier
Carrier Ethernet provides a much more scalable, cost-effective alternative. Ethernet Services
In CE, the subscriber can map traffic to the services based on CE-VLAN IDs Send Feedback
and can have bandwidth profiles that enable sharing of bandwidth between
different service instances. Name:

CE also enables the introduction of E-LAN and E-Tree services which could not Email:
be supported efficiently over ATM or FR.
Comments
Both technologies require no IP coordination with the SP as the forwarding
and mapping to the services are not based on IP routing.

To summarize, the key advantages of Carrier Ethernet over legacy L2 services


Send Feedback
are:

Scalable bandwidth (granularity, up to 10 Gbps)


Support of Multi-point services
Bandwidth sharing between services

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Positioning of Carrier Ethernet with other In this Section


technologies 8 Positioning of Carrier Ethernet
with other technologies
Study Guide Section 8.2 8.1 Carrier Ethernet and L2VPN

Carrier Ethernet and IP 8.2 Carrier Ethernet and IP

8.3 Carrier Ethernet and TDM


L3VPN / IP Service

Many core networks are built over IP/MPLS both nationally and internationally. Download PDF

IP/MPLS or L3VPN is a technology where the traffic is carried over PW over


LSP tunnels and the forwarding is L3-based. The infrastructure is made up of Download a pdf for
routers that are MPLS-capable. Such a network can provide connectivity offline viewing.
service to subscribers, in a similar manner to the way CEN provides Ethernet
services.

These L3 services are non-standard, and there is currently no Standards Reference Documents
Development Organization that is attempting to create standards for such
services. In contrast to L3VPN, Ethernet services are built on the concept of MEF 6.1
Ethernet based forwarding, hence can be referred to as L2VPN. When we MEF 8
consider L3VPN Vs. L2VPN the following comparison can be made:
MEF 10.2

L2VPN L3VPN MEF 22.1


Ethernet port (or PDH MEF White Paper: CESoE
Ethernet UNI
Customer Handoff circuit) IETF RFC 4448
Service Identification VLAN ID / EVC IP Address
Granular, up to 10 MEF-CECP Test Objectives
Service Rate Granular, up to 10 Gbps
Gbps 8 Comparing and Positioning Carrier
Defined by Service Ethernet Services
performance objectives,
SLS Proprietary Send Feedback
controlled by Bandwdith
profile
Name:
CoS Identification PCP, DSCP, Per EVC DSCP/ToS
Packet/Frame MAC Address (E-LAN) VLAN Email:
IP Address
Routing/Forwarding ID (E-Line)
Comments
Link Trace, Continuity
Fault Management Check (Layer 2 Ping), Traceroute, ICMP Ping
Loopbacks
Frame Delay, Frame Delay Packet Delay, Packet Send Feedback

Performance Management Variation, Frame Loss Delay Variation,


Ratio, Service Availability Packet Loss,

In some cases a global solution may result in a combination of L2VPN and


L3VPN services. The main reason is that for long haul, from time to time,
forwarding based on Ethernet addresses does not scale, whereas L3VPNs are
available throughout the globe on international links.

A simplified view of this combined service is depicted below:

Figure 8.2.F1: Carrier Ethernet and IP/MPLS Core Network

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Positioning of Carrier Ethernet with other In this Section


technologies 8 Positioning of Carrier Ethernet
with other technologies
Study Guide Section 8.3 8.1 Carrier Ethernet and L2VPN

Carrier Ethernet and TDM 8.2 Carrier Ethernet and IP

8.3 Carrier Ethernet and TDM


TDM Private Line services enable a subscriber to connect two locations using a
dedicated "pipe" having fixed bandwidth and fixed delay and delay variation
Download PDF
characteristics using a WAN network operator . This service is very bandwidth
limited, as it is often limited to about 50 Mbps. Furthermore, the bandwidth
is always symmetrical, although many applications are asymmetric in nature.
Download a pdf for
offline viewing.
The bandwidth allocated for a service instance is always allocated and cannot
be shared amongst services. This explains why these services are not cheap.
Migrating these services to Ethernet services enables the customer the
flexibility to buy the bandwidth it needs, in the direction it needs. It also
Reference Documents
enables more sophisticated bandwidth sharing schemes and of course scales as
the number of locations grow. For the cases where time synchronization is MEF 6.1
important, synchronization over packet networks (1588v2 or NTP) can be
MEF 8
used. TDM-based CES over Ethernet services also provides a comparable
MEF 10.2
service.
MEF 22.1
Example:
MEF White Paper: CESoE

Assuming that the customer has a symmetrical service of 4 Mbps using 2xE1s IETF RFC 4448
to connect two locations, then the most appropriate Ethernet service to start
with would be an EPL, which provides the most transparent service. In such a MEF-CECP Test Objectives
case the following UNI Attributes are recommended: 8 Comparing and Positioning Carrier
Ethernet Services
All-to-One Bundling = Yes (which means Bundling=No, Service
Multiplexing = No)
Send Feedback
Ingress Bandwidth Profile per UNI

CIR = 4 Mbps Name:


CBS = 50,000 bytes
EIR=0 Email:

EBS=0 Comments
L2CP Processing Tunnel all L2CPs

Where a single EVC with single CoS ID is planned, the following EVC Attributes
are recommended:
Send Feedback

No bandwidth profile
Conditional delivery Deliver Unconditionally for Unicast, Multicast,
Broadcast
Service Performance will be set to target the performance
guaranteed to the subscriber

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

MEF 22.1
Mobile Backhaul Implementation Agreement Phase 2

MEF 22.1 is a specification document developed by the Technical Committee of the MEF that provides an Implementation
Agreement for Mobile Backhaul.

Abstract:

"This document identifies the requirements for MEF Ethernet Services and MEF External Interfaces (EIs such as UNIs) for
use in Mobile Backhaul networks based on MEF specifications. In addition, new interface and service attributes have been
specified where needed. The services and requirements in this Implementation Agreement are based on the services
defined in MEF 6.1 [3] as well as the attributes in MEF 10.2 [7], in MEF 10.2.1 [8] and this IA. The aim is to be flexible
to support a wide range of Ethernet service based mobile network deployments."

Download
Reference Presentation

There is currently no overview presentation available for MEF 22.1.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Test Objectives 8 1 In this Section


Comparing and Positioning Ethernet Services 8 Positioning of Carrier Ethernet
with other technologies
8.1 Compare and contrast Ethernet services with L2, IP, and TDM private line
services. 8.1 Carrier Ethernet and L2VPN

8.2 Carrier Ethernet and IP


8.2 Given a scenario, recommend an Ethernet service to meet end user
8.3 Carrier Ethernet and TDM
specifications.

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 6.1

MEF 8

MEF 10.2

MEF 22.1

MEF White Paper: CESoE

IETF RFC 4448

MEF-CECP Test Objectives

8 Comparing and Positioning Carrier


Ethernet Services
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Synchronization over Carrier Ethernet & In this Section


Circuit Emulation 9 Synchronization over Carrier
Ethernet & Circuit Emulation
Study Guide Section 9.1 < br/>
Purpose and Need 9.1 Purpose and Need

Since the 1960's when TDM was first developed for wide area networks, a huge 9.1.1 What is CESoETH
installed-base of TDM circuits and equipment ports (T1/E1, T3/E3 etc.) has 9.1.2 MEF 8 model
emerged throughout the world supporting both voice communications and also < br/>
data networking.
9.2 CES Components
However, with the advent of the Internet, packet-based networking (Carrier 9.2.1 Interface to Customer
Ethernet, IP, MPLS) for both data networking and voice communications has
9.2.2 Generic Interworking
overtaken TDM, becoming the primary approach to digital networking in wide Function (GIWF)
area networks. 9.2.3 Functional Layering

The original purpose of TDM was to enable multiplexed voice calls over a < br/>
single physical circuit. Voice calls require minimum end-to-end delay (latency) 9.3 Service Definitions
and delay variation to achieve reasonable voice quality. This purpose was
9.3.1 E-Line
achieved by designing TDM in such a way that clock synchronization between
9.3.2 UNI Attributes
both ends of the circuit could be achieved via the TDM circuit, as well as
guaranteed and permanent transmission and receipt of TDM frames based on 9.3.3 EVC Attributes
the synchronized clocks - whether or not actual traffic is contained within the 9.3.4 EVC per UNI Attributes
TDM frames. This translates into low latency and delay variation at the < br/>
expense of bandwidth and flexibility.
9.4 Synchronization
Packet-based networking originally provided cost effective networking with 9.4.1 Packet Based
high bandwidth capabilities and flexibility, but without the guarantee of low Synchronization Methods
latency and delay variation required for voice calls and some data 9.4.1.1 Adaptive Clock Recovery
applications. However, with the advent of Carrier Ethernet, and the 9.4.1.2 NTP
improvement of the underlying transport infrastructures, it is now feasible to
9.4.1.3 1588 v2
guarantee low latency and delay variation in packet-based networks enabling
9.4.2 SyncE
the transport of all types of applications including voice and clock
synchronization.
Download PDF
With almost 50 years of deployment of equipment with TDM-ports (e.g. PBXs,
telephone switching centers, mobile backhaul equipment), there is still a need
to connect TDM equipment, albeit over packet-based networks rather than Download a pdf for
offline viewing.
TDM circuits.

Carrier Emulation Services over Ethernet (CESoETH) enables users of TDM


equipment and clock synchronization to use cost effective Carrier Ethernet
services to transport TDM and clock traffic together with all other applications Reference Documents
over a single packet-based network.
MEF 8
MEF 22.1

MEF Reference Presentation: Access


Technologies

MEF-CECP Test Objectives

9 CES over Ethernet

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Synchronization over Carrier Ethernet & In this Section


Circuit Emulation 9 Synchronization over Carrier
Ethernet & Circuit Emulation
Study Guide Section 9.1.1 < br/>
What is CESoETH? 9.1 Purpose and Need

Circuit Emulation Service over Ethernet (CESoETH) is a technology for 9.1.1 What is CESoETH
transporting TDM services over a Carrier Ethernet Network (CEN) 9.1.2 MEF 8 model

< br/>
CESoETH tunnels TDM traffic through a CEN where the packet network
emulates a circuit-switched network, re-creating the TDM circuit at the far 9.2 CES Components
end such that the CEN is invisible to TDM source and destination equipment. 9.2.1 Interface to Customer
CESoETH runs on a standard Ethernet point-to-point service (E-Line). CESoETH
9.2.2 Generic Interworking
can be referred to as TDM emulation over packet network. Function (GIWF)

9.2.3 Functional Layering


The service is illustrated in the following figure:
< br/>

9.3 Service Definitions

9.3.1 E-Line

9.3.2 UNI Attributes

9.3.3 EVC Attributes


Figure 9.1.1.F1 - CESoETH
9.3.4 EVC per UNI Attributes
CESoETH enables an Carrier Ethernet Service Provider to offer a true
< br/>
converged service over the packet network - a service that supports both
9.4 Synchronization
legacy TDM-based interfaces and services, along side more advanced
Ethernet-based services. 9.4.1 Packet Based
Synchronization Methods
CESoETH is the solution for any point-to-point service between locations that 9.4.1.1 Adaptive Clock Recovery
have TDM interfaces such as E1, T1, E3, T3 where the wide area network is a 9.4.1.2 NTP
CEN. When the service itself is TDM and when timing synchronization is
9.4.1.3 1588 v2
important (e.g. mobile backhaul) CEsoETH provides a solution for timing re-
generation. It is important to understand that the same UNIs that are used to 9.4.2 SyncE

support CESoETH service can be used to support other Ethernet services which
are packet based. However, this is achieved using a separate EVC. Download PDF


Download a pdf for
offline viewing.

Reference Documents

MEF 8

MEF 22.1

MEF Reference Presentation: Access


Technologies

MEF-CECP Test Objectives

9 CES over Ethernet

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Synchronization over Carrier Ethernet & In this Section


Circuit Emulation 9 Synchronization over Carrier
Ethernet & Circuit Emulation
Study Guide Section 9.1.2 < br/>
MEF 8 Model 9.1 Purpose and Need

MEF 8 is the Implementation Agreement for Circuit Emulation over a Carrier 9.1.1 What is CESoETH
Ethernet Network (CEN) 9.1.2 MEF 8 model

< br/>
The TDM service is carried over an E-Line. A single E-Line can support multiple
TDM services. The Subscriber connects to the Service Provider network via a 9.2 CES Components
TDM interface. However a CEN supports only Ethernet UNIs. A component is 9.2.1 Interface to Customer
defined to convert TDM to Ethernet. This component is called Generic
9.2.2 Generic Interworking
Interworking Function (GIWF) Function (GIWF)

9.2.3 Functional Layering


This model is illustrated in the following figure:
< br/>

9.3 Service Definitions

9.3.1 E-Line

9.3.2 UNI Attributes

9.3.3 EVC Attributes

9.3.4 EVC per UNI Attributes

< br/>
Figure 9.1.2.F1 9.4 Synchronization

It should be noted that this schematic drawing may be realized using a single 9.4.1 Packet Based
Synchronization Methods
network element at the CEN's edge which presents a TDM interface and has an
internal Carrier Ethernet UNI. The Carrier Ethernet UNI is a standard MEF UNI. 9.4.1.1 Adaptive Clock Recovery

9.4.1.2 NTP
From that point on, the transport network is 'unaware' that a TDM service is
9.4.1.3 1588 v2
being carried over the EVC/OVC.
9.4.2 SyncE
In order to provide the level of transparency and the constant bit-rate
required by TDM services, this specific EVC is not shared with other traffic. Download PDF

However, the same UNI can be used to support other services between these
customer locations, using separate EVCs and utilizing the service multiplexing
Download a pdf for
capabilities of MEF services. offline viewing.

It should be noted that similar techniques are used by IETF solutions for
carrying TDM traffic over MPLS or IP networks using pseudowires.
Reference Documents
When two Subscribers need a TDM service to access a PSTN, each customer
will have its own T-Line over an EVPL to the PSTN. If the 2 locations also
MEF 8
require communication between themselves, a third (not shown in the figure)
MEF 22.1
T-Line is created. This service scenario is depicted in the figure below:
MEF Reference Presentation: Access
Technologies

MEF-CECP Test Objectives

9 CES over Ethernet

Send Feedback

Name:

Email:

Comments

Figure 9.1.2.F1

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Synchronization over Carrier Ethernet & In this Section


Circuit Emulation 9 Synchronization over Carrier
Ethernet & Circuit Emulation
Study Guide Section 9.2 < br/>
CES Components 9.1 Purpose and Need

CESoETH requires several architectural components in addition to the 9.1.1 What is CESoETH
implementation of TDM to Ethernet conversion. This section describes the 9.1.2 MEF 8 model
various components and their use in the implementation of a Carrier Ethernet- < br/>
based TDM service.
9.2 CES Components

9.2.1 Interface to Customer

9.2.2 Generic Interworking


Function (GIWF)

9.2.3 Functional Layering

< br/>

9.3 Service Definitions

9.3.1 E-Line

9.3.2 UNI Attributes

9.3.3 EVC Attributes

9.3.4 EVC per UNI Attributes

< br/>

9.4 Synchronization

9.4.1 Packet Based


Synchronization Methods

9.4.1.1 Adaptive Clock Recovery

9.4.1.2 NTP
9.4.1.3 1588 v2

9.4.2 SyncE

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 8

MEF 22.1

MEF Reference Presentation: Access


Technologies

MEF-CECP Test Objectives

9 CES over Ethernet

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Synchronization over Carrier Ethernet & In this Section


Circuit Emulation 9 Synchronization over Carrier
Ethernet & Circuit Emulation
Study Guide Section 9.2.1 < br/>
Interface to Customer 9.1 Purpose and Need

The Subscriber of CESoETH is presented a TDM interface by the Service 9.1.1 What is CESoETH
Provider. TDM services may be transported in two ways:- 9.1.2 MEF 8 model

< br/>
structure-agnostic (where any underlying structure is ignored by the
transport mechanism) 9.2 CES Components
structure-aware (where the underlying structure is exploited by the 9.2.1 Interface to Customer
transport mechanism)
9.2.2 Generic Interworking
Function (GIWF)
MEF Specifications supports the following interfaces:
9.2.3 Functional Layering
DS1 at 1.544 Mbit/s as defined in ANSI [T1.102] and [T1.107] < br/>
E1 at 2.048 Mbit/s as defined in ITU-T Recommendations [G.702] and
9.3 Service Definitions
[G.704]
N x 64kbit/s data (i.e. 64 kbit/s, 128 kbit/s, 192 kbit/s) as defined in 9.3.1 E-Line

ITU-T recommendation [I.231.1] 9.3.2 UNI Attributes


DS3 at 44.736 Mbit/s as defined in ANSI [T1.107] 9.3.3 EVC Attributes
E3 at 34.368 Mbit/s as defined in ITU-T Recommendation [G.751]
9.3.4 EVC per UNI Attributes

The TDM data (and optionally clock) is converted and mapped to packets for < br/>
transport over a CEN. This operation is performed by the GIWF. After this 9.4 Synchronization
conversion from TDM to packet, there is a standard MEF ETH UNI - the point
9.4.1 Packet Based
at which the ETH service starts. Synchronization Methods

At the egress of the ETH service, the GIWF regenerates the TDM stream. 9.4.1.1 Adaptive Clock Recovery

9.4.1.2 NTP
Note that the ETH service that carries the CES data is managed and
9.4.1.3 1588 v2
maintained from UNI to UNI. However, the specific statistics that are
delivered for CESoETH are measured between GIWFs. 9.4.2 SyncE

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 8

MEF 22.1

MEF Reference Presentation: Access


Technologies

MEF-CECP Test Objectives

9 CES over Ethernet

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Synchronization over Carrier Ethernet & In this Section


Circuit Emulation 9 Synchronization over Carrier
Ethernet & Circuit Emulation
Study Guide Section 9.2.2 < br/>
Generic Interworking Function (GIWF) 9.1 Purpose and Need

The Circuit Emulation Interworking Functional, also known as the Generic 9.1.1 What is CESoETH
Inter-Working Function (GIWF), is defined as the adaptation function that 9.1.2 MEF 8 model
interfaces the CES application to the Ethernet layer. GIWF handles the < br/>
emulation of the service presented at the CES TDM Interface. The CES GIWF is
9.2 CES Components
responsible for all the functions required for the emulated service to function
including: 9.2.1 Interface to Customer

9.2.2 Generic Interworking


Encapsulation on ingress Function (GIWF)
Decapsulation on egress 9.2.3 Functional Layering
Payload formation and extraction
< br/>
Synchronization
Carriage of TDM signaling and alarms 9.3 Service Definitions
Error Response and Defect Behaviour 9.3.1 E-Line
TDM performance monitoring 9.3.2 UNI Attributes

The details of these functions are detailed in section 6 of MEF 8 but are 9.3.3 EVC Attributes
outside the scope of this study guide. 9.3.4 EVC per UNI Attributes

< br/>
The GIWF has two interfaces:
9.4 Synchronization
Customer facing - CES TDM Interface
9.4.1 Packet Based
ETH UNI facing - CES Payload (i.e. packetised TDM payload, CES Synchronization Methods
control word, optional RTP header)
9.4.1.1 Adaptive Clock Recovery

9.4.1.2 NTP
9.4.1.3 1588 v2

9.4.2 SyncE

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 8

MEF 22.1

MEF Reference Presentation: Access


Technologies

MEF-CECP Test Objectives

9 CES over Ethernet

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Synchronization over Carrier Ethernet & In this Section


Circuit Emulation 9 Synchronization over Carrier
Ethernet & Circuit Emulation
Study Guide Section 9.2.3 < br/>
Functional Layering 9.1 Purpose and Need

Circuit Emulation Services over Ethernet (CESoETH) uses a point-to-point 9.1.1 What is CESoETH
connection between two GIWFs. Essentially it uses the CEN as an intermediate 9.1.2 MEF 8 model
network (or virtual wire) between two TDM networks. This is handled as an < br/>
application layer function in terms of the layered network model defined in
9.2 CES Components
MEF 8. The GIWF provides the adaptation of the CES application to the
Ethernet services layer. 9.2.1 Interface to Customer

9.2.2 Generic Interworking


This functional layering is shown in the table below with mapping onto the Function (GIWF)
various encapsulation headers 9.2.3 Functional Layering

< br/>
CES Application Data
9.3 Service Definitions
Adaptation Function
9.3.1 E-Line
Ethernet Service Layer
9.3.2 UNI Attributes

9.3.3 EVC Attributes


When one considers a packet "inside the CEN" the realization of the above
layered model will look as shown below: 9.3.4 EVC per UNI Attributes

< br/>
TDM Payload
9.4 Synchronization
RTP (Optional) 9.4.1 Packet Based
Synchronization Methods
CESoETH Control Word
9.4.1.1 Adaptive Clock Recovery
Emulated Circuit Identifier
9.4.1.2 NTP
VLAN Tags 9.4.1.3 1588 v2

MAC SA 9.4.2 SyncE

MAC DA Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 8

MEF 22.1

MEF Reference Presentation: Access


Technologies

MEF-CECP Test Objectives

9 CES over Ethernet

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Synchronization over Carrier Ethernet & In this Section


Circuit Emulation 9 Synchronization over Carrier
Ethernet & Circuit Emulation
Study Guide Section 9.3 < br/>
Service Definitions 9.1 Purpose and Need

9.1.1 What is CESoETH

9.1.2 MEF 8 model


The Carrier Ethernet carrying the CESoETH must an E-Line with specific UNI,
EVC and EVC Per UNI attributes. This section explains why an E-Line must be < br/>
used and the attributes for that E-Line. 9.2 CES Components

E-Line requirement for CESoETH 9.2.1 Interface to Customer

UNI attributes for CESoETH 9.2.2 Generic Interworking


Function (GIWF)
EVC attributes for CESoETH
EVC Per UNI attributes for CESoETH 9.2.3 Functional Layering

< br/>

9.3 Service Definitions

9.3.1 E-Line

9.3.2 UNI Attributes

9.3.3 EVC Attributes

9.3.4 EVC per UNI Attributes

< br/>

9.4 Synchronization

9.4.1 Packet Based


Synchronization Methods

9.4.1.1 Adaptive Clock Recovery

9.4.1.2 NTP
9.4.1.3 1588 v2

9.4.2 SyncE

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 8

MEF 22.1

MEF Reference Presentation: Access


Technologies

MEF-CECP Test Objectives

9 CES over Ethernet

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Synchronization over Carrier Ethernet & In this Section


Circuit Emulation 9 Synchronization over Carrier
Ethernet & Circuit Emulation
Study Guide Section 9.3.1 < br/>
E-Line 9.1 Purpose and Need

Only E-Lines can be used for CESoETH. This is because the E-Line is the single 9.1.1 What is CESoETH
Carrier Ethernet service type for point-to-point connections, and CESoETH is 9.1.2 MEF 8 model
inherently a point-to-point service. In other words, only E-Lines connect < br/>
exactly two customer TDM interfaces over a CEN.
9.2 CES Components
Subscribers can choose between using an E-Line EPL (private service) and an 9.2.1 Interface to Customer
EVPL (virtual service) An EPL is chosen where only one Carrier Ethernet
9.2.2 Generic Interworking
service is required on the UNI (i.e. CESoETH) EVPL is chosen when more than Function (GIWF)
one Carrier Ethernet service is required on the UNI (e.g. CESoETH and Internet 9.2.3 Functional Layering
access; two CESoETH etc.)
< br/>
Altough EPL provides higher transparency in terms of L2CP processing, this is 9.3 Service Definitions
not relevant for CESoETH, which does not make use of L2CP.
9.3.1 E-Line

Note that the UNI-N in this case is a regular UNI-N supporting Ethernet 9.3.2 UNI Attributes
services. However, the UNI-C is internal to the GIWF since the customer has a 9.3.3 EVC Attributes
TDM interface to the network.
9.3.4 EVC per UNI Attributes

The service requirements for CESoETH are: < br/>

9.4 Synchronization
Point-to-point service
Guaranteed bitrate in known quantum (2 Mbps for E1, 1.5 for T1, 9.4.1 Packet Based
Synchronization Methods
etc.)
Single class of service 9.4.1.1 Adaptive Clock Recovery

9.4.1.2 NTP
Specific service performance targets to support service QoS similar to
TDM networks, meaning: 9.4.1.3 1588 v2

Low loss ratio 9.4.2 SyncE


Small delay
Small delay variation Download PDF

No VLAN manipulation is required


Download a pdf for
The following example describes how mobile backhaul of 2G traffic can be offline viewing.
realized using E-lines between each cell site and the BSC.

Reference Documents

MEF 8

MEF 22.1

MEF Reference Presentation: Access


Technologies

Figure 9.3.1.F1 - Mobile Backhaul


MEF-CECP Test Objectives

9 CES over Ethernet


Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Synchronization over Carrier Ethernet & In this Section


Circuit Emulation 9 Synchronization over Carrier
Ethernet & Circuit Emulation
Study Guide Section 9.3.2 < br/>
UNI Attributes 9.1 Purpose and Need

A UNI that is an end-point to a CESoETH service is a regular UNI with no 9.1.1 What is CESoETH
specific additional requirements imposed on the UNI. Either UNI type (1, 2.1, 9.1.2 MEF 8 model
2.2) can be used. Some specific UNI attributes should be set specifically in < br/>
order to facilitate the CESoETH service. The table below lists and explains the
9.2 CES Components
additional requirements of the various UNI attributes:
9.2.1 Interface to Customer

9.2.2 Generic Interworking


UNI Service Attribute Recommended Setting Function (GIWF)

9.2.3 Functional Layering


UNI Identifier No Aditional Requirement
< br/>
Physical Medium No Aditional Requirement
9.3 Service Definitions
Speed No Aditional Requirement 9.3.1 E-Line

Mode FDX 9.3.2 UNI Attributes

9.3.3 EVC Attributes


MAC Layer 802.3-2005
9.3.4 EVC per UNI Attributes
UNI MTU Size No Aditional Requirement
< br/>
Service Multiplexing Yes if there are several EVCs
connecting this UNI No if the UNI is 9.4 Synchronization
used for a single CESoETH and 9.4.1 Packet Based
nothing else Synchronization Methods

Bundling No 9.4.1.1 Adaptive Clock Recovery

9.4.1.2 NTP
All to One Bundling No if Service Multiplexing was set to
Yes Yes if Service Multiplexing was 9.4.1.3 1588 v2
set to No
9.4.2 SyncE
CE-VLAN ID for untagged and No Aditional Requirement
Priorty Tagged frames
Download PDF
Maximum Number of EVC No Aditional Requirement

Ingress BWP per UNI Should not be specified, as CESoETH


needs its own per-EVC BWP in order Download a pdf for
to ensure the CIR for constant rate offline viewing.
traffic

Egress BWP per UNI No

L2CP Processing Pass to EVC all L2CPs, expect for Reference Documents
PAUSE frames PAUSE cannot be
used along side with guaranteed bit- MEF 8
rate applications
MEF 22.1
MEF Reference Presentation: Access
Technologies

MEF-CECP Test Objectives

9 CES over Ethernet

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Synchronization over Carrier Ethernet & In this Section


Circuit Emulation 9 Synchronization over Carrier
Ethernet & Circuit Emulation
Study Guide Section 9.3.3 < br/>
EVC Attributes 9.1 Purpose and Need

The EVC that carries CESoETH can be an EPL or an EVPL. It carries non-VLAN 9.1.1 What is CESoETH
traffic and therefore VLAN and CoS preservation are irrelevant. Since CESoETH 9.1.2 MEF 8 model
uses no L2CP it implies that all L2CP can be discarded by the EVC. < br/>

The major issue to consider is the service performance attributes for this 9.2 CES Components
single CoS ID service. 9.2.1 Interface to Customer

The Delay and Delay Variation are to be set according to the specific 9.2.2 Generic Interworking
Function (GIWF)
requirements of the customers, but must be kept to a minimum.
9.2.3 Functional Layering
The following table lists the EVC attributes and the suggested settings for < br/>
such an EVC:
9.3 Service Definitions

EVC Service Attribute Recommended Value 9.3.1 E-Line

9.3.2 UNI Attributes


EVC Type Point to Point
9.3.3 EVC Attributes
UNI List No Additional Requirement
9.3.4 EVC per UNI Attributes
EVC MTU Size No Additional Requirement < br/>

CE-VLAN ID Preservation No 9.4 Synchronization

CE-VLAN CoS Preservation No 9.4.1 Packet Based


Synchronization Methods
Unicast Service frame Delivery Deliver unconditionally 9.4.1.1 Adaptive Clock Recovery

9.4.1.2 NTP
Multicast Service frame Delivery Deliver unconditionally
9.4.1.3 1588 v2
Broadcast Service frame Delivery Deliver unconditionally
9.4.2 SyncE
L2CP Processing Discard all L2CPs

EVC Performance Download PDF


Frame loss ratio 0.01%

One-Way Frame Delay 10 msec for


99th percentile Download a pdf for
offline viewing.
One-Way Frame Delay Variation 1
msec for 99 th percentile

Availability 99.95%

Reference Documents
Note that the exact values for service performance may be dictated by the
MEF 8
appropriate TDM standard or the service requirement that the Subscriber has.
MEF 22.1

MEF Reference Presentation: Access


Technologies

MEF-CECP Test Objectives

9 CES over Ethernet

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Synchronization over Carrier Ethernet & In this Section


Circuit Emulation 9 Synchronization over Carrier
Ethernet & Circuit Emulation
Study Guide Section 9.3.4 < br/>
EVC per UNI Attributes 9.1 Purpose and Need

The major issue to consider when setting the EVC per UNI attributes for 9.1.1 What is CESoETH
CESoETH is the ingress bandwidth profile (BWP) The service must guarantee 9.1.2 MEF 8 model
CIR at a rate that matches the TDM traffic CBR. Because the packetization < br/>
process adds additional overhead and because the BWP counts also the ETH
9.2 CES Components
headers in some cases, the CIR could be set a little higher compared to the
TDM nominal bitrate. 9.2.1 Interface to Customer

9.2.2 Generic Interworking


For example, for an EVC carrying E1, the CIR could be set to say 2.2 Mbps, Function (GIWF)
allowing 10% margin. If the service was originally an E3 of 34.368 Mbps, then 9.2.3 Functional Layering
the CIR could be set to say 38 Mbps.
< br/>
CBS can be set relatively to a relatively small level since the TDM traffic is 9.3 Service Definitions
very constant with minimal bursts. Since it is important not to drop any 'TDM
9.3.1 E-Line
service' packets, a CBS of 3 times the MTU could be set.
9.3.2 UNI Attributes
EIR and EBS are set to 0 since ALL traffic must be counted against the SLS. 9.3.3 EVC Attributes

CF and CM are not relevant in such a case. 9.3.4 EVC per UNI Attributes

< br/>
The following table lists the EVC per UNI attributes and the suggested settings
9.4 Synchronization
for such an EVC:
9.4.1 Packet Based
Synchronization Methods
EVC per UNI Service Attribute Recommended Value
9.4.1.1 Adaptive Clock Recovery
UNI EVC ID No Additional Requirement
9.4.1.2 NTP
CE-VLAN ID / EVC Map No Additional Requirement 9.4.1.3 1588 v2

Ingress Bandwidth Profile per CIR = 2.2Mbps for E1 service 9.4.2 SyncE
EVC CBS=3x1522 = 4566 bytes EIR=0,
EBS=0 CF=0, CM=0
Download PDF
Ingress Bandwidth Profile per CoS Must not specify
ID

Egress Bandwidth Profile per EVC Must not specify Download a pdf for
offline viewing.
Egress Bandwidth Profile per CoS Must not specify
ID

Reference Documents

MEF 8

MEF 22.1

MEF Reference Presentation: Access


Technologies

MEF-CECP Test Objectives

9 CES over Ethernet

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Synchronization over Carrier Ethernet & In this Section


Circuit Emulation 9 Synchronization over Carrier
Ethernet & Circuit Emulation
Study Guide Section 9.4 < br/>
Synchronization 9.1 Purpose and Need

Synchronization is the means of keeping all digital equipment in a 9.1.1 What is CESoETH
communications network operating at the same specified clock rate. 9.1.2 MEF 8 model
Differences in timing at nodes within a network cause the receiving node to < br/>
either drop or reread information sent to it. This is referred to as 'clock slip'.
9.2 CES Components
For example, if the sender operates with a clock rate faster than the
receiver's clock rate, the receiver cannot keep up with the incoming traffic. 9.2.1 Interface to Customer
When the receiver cannot keep up with the sender, it will periodically drop 9.2.2 Generic Interworking
some of the information sent to it resulting in reduced voice quality or Function (GIWF)

retransmission of data if the source can support this. 9.2.3 Functional Layering

< br/>
To achieve the required synchronization of the TDM nodes across the
asynchronous Ethernet network, a clock recovery mechanism must be 9.3 Service Definitions
employed at the receiver side of a CESoETH connection. Clock recovery 9.3.1 E-Line
mechanisms need to withstand the potential Frame Delay, Inter-Frame Delay 9.3.2 UNI Attributes
Variation (IFDV) and frame loss of Ethernet networks yet still comply with
9.3.3 EVC Attributes
strict synchronization standard requirements. Variations of recovered clocks
9.3.4 EVC per UNI Attributes
must be maintained within the range of a few nano-seconds to a few micro-
seconds (depending on the TDM services) even though Carrier Ethernet < br/>
Networks (CENs) may introduce frame delay variation in the order of 9.4 Synchronization
milliseconds.
9.4.1 Packet Based
Synchronization Methods
The different sync parameters are illustrated below:
9.4.1.1 Adaptive Clock Recovery

9.4.1.2 NTP
9.4.1.3 1588 v2

9.4.2 SyncE

Download PDF

Download a pdf for


offline viewing.

Reference Documents

Figure 9.4.F1 - Sync Parameters


MEF 8
Synchronization can be achieved for both phase and/or Time of Day. There MEF 22.1
are three catagories of solutions:
MEF Reference Presentation: Access
Technologies
1. External source GPS or TDM network. This is outside the scope of the
Carrier Ethernet domain.
MEF-CECP Test Objectives
2. Synchronization of packet network elaborated in the following
sections. 9 CES over Ethernet
3. Synchronization over physical Ethernet Synchronous Ethernet or SyncE
Send Feedback
Synchronization is a key component in cellular network technologies and
different cellular network technologies have different synchronization Name:
requirements.
Email:
Synchronization is used to support mobile application and system
requirements to minimize air interference, facilitate handover between base Comments
stations, and to fulfill regulatory requirements. Various cellular network
technologies stipulate that the radio signal must be generated in strict
compliance with frequency, phase and time accuracy requirements.
Send Feedback

The following table specifies for each mobile technology which parameters are
required to be synchronized:

Mobile Network Frequency Sync Time-of-day / Phase


Architecture Sync
CDMA2000 Yes
GSM Yes
UMTS-FDD Yes
LTE-FDD Yes
UMTS-TDD Yes Yes
LTE-FDD with MBMS- Yes Yes
Single Freq. Network
LTE-TDD Yes Yes
Mobile WiMAX Yes Yes
TD-SCDMA Yes Yes

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Synchronization over Carrier Ethernet & In this Section


Circuit Emulation 9 Synchronization over Carrier
Ethernet & Circuit Emulation
Study Guide Section 9.4.1 < br/>
Packet Based Synchronization Methods 9.1 Purpose and Need

Packet-based methods use a master-slave mechanism where a master 9.1.1 What is CESoETH
distributes timing to the slaves via packets that carry timestamps. The master 9.1.2 MEF 8 model
has access to an accurate reference, such as GPS and this source clock is < br/>
distributed from a Primary Reference Clock (PRC).
9.2 CES Components

9.2.1 Interface to Customer

9.2.2 Generic Interworking


Function (GIWF)

9.2.3 Functional Layering

< br/>

Figure 9.4.1.F1 - Packet Based Methods 9.3 Service Definitions

9.3.1 E-Line

9.3.2 UNI Attributes

9.3.3 EVC Attributes

9.3.4 EVC per UNI Attributes

< br/>

9.4 Synchronization

9.4.1 Packet Based


Synchronization Methods

9.4.1.1 Adaptive Clock Recovery

9.4.1.2 NTP
9.4.1.3 1588 v2

9.4.2 SyncE

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 8

MEF 22.1

MEF Reference Presentation: Access


Technologies

MEF-CECP Test Objectives

9 CES over Ethernet

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Synchronization over Carrier Ethernet & In this Section


Circuit Emulation 9 Synchronization over Carrier
Ethernet & Circuit Emulation
Study Guide Section 9.4.1.1 < br/>
Adaptive Clock Recovery 9.1 Purpose and Need

Adaptive Clock Recovery (ACR) is a method with several variants and 9.1.1 What is CESoETH
implementations. In all of them, ACR reconstructs (recovers) the original clock 9.1.2 MEF 8 model
from the actual payload of the data stream. In other words, a synchronous < br/>
clock is derived from an asynchronous packet stream.
9.2 CES Components
This is achieved by having the clock source send bits at a constant rate and 9.2.1 Interface to Customer
aggregated into packets. However, these packets experience variable delay
9.2.2 Generic Interworking
over the CEN. As long as the packets arrive with a high probability (meaning Function (GIWF)
very low FLR) and within bounds on delay and inter-frame delay variation, 9.2.3 Functional Layering
averaging functions can be employed to find the original clock rate.
< br/>
From the CEN's point of view, these packets can be carried in a dedicated EVC 9.3 Service Definitions
or could have a CoS with stringent performance objective within an EVC that
9.3.1 E-Line
carries other traffic.
9.3.2 UNI Attributes
These two approaches are illustrated below: 9.3.3 EVC Attributes

9.3.4 EVC per UNI Attributes

< br/>

9.4 Synchronization

9.4.1 Packet Based


Figure 9.4.1.1.F1 - Adaptive Clock Recovery Synchronization Methods

9.4.1.1 Adaptive Clock Recovery

9.4.1.2 NTP
9.4.1.3 1588 v2

9.4.2 SyncE

Download PDF

Figure 9.4.1.1.F2 - Adaptive Clock Recovery

Download a pdf for


offline viewing.

Reference Documents

MEF 8

MEF 22.1

MEF Reference Presentation: Access


Technologies

MEF-CECP Test Objectives

9 CES over Ethernet

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Synchronization over Carrier Ethernet & In this Section


Circuit Emulation 9 Synchronization over Carrier
Ethernet & Circuit Emulation
Study Guide Section 9.4.1.2 < br/>
NTP 9.1 Purpose and Need

Network Time Protocol (NTP) is one of the oldest Ethernet protocols still in 9.1.1 What is CESoETH
use. It was originally designed over 25 years ago. 9.1.2 MEF 8 model
NTPv3 is defined in RFC 1305. < br/>
NTPv4, which is backwards compatible with NTPv3, is defined in RFC 5905.
9.2 CES Components
NTPv4 offers several improvements over previous versions of NTP - one of 9.2.1 Interface to Customer
them being to extend the potential accuracy to tens of microseconds. NTPv4
9.2.2 Generic Interworking
can usually maintain time to within 10-20 milliseconds over the public Function (GIWF)
Internet and can achieve microsecond accuracy or better in local area 9.2.3 Functional Layering
networks (under ideal conditions)
< br/>
The main issue with NTP is that its accuracy can degrade substantially during 9.3 Service Definitions
periods of network congestion. NTP packets are carried over UDP/IP/ETH
9.3.1 E-Line
transport which is then encapsulated depending on the CEN transport
9.3.2 UNI Attributes
technology. Therefore, NTPv4 requires a dedicated CoS ID with stringent
performance objectives for Frame Loss Ratio, Frame Delay and Frame Delay 9.3.3 EVC Attributes
Variation. 9.3.4 EVC per UNI Attributes

< br/>
NTP is quite simple in its operation: The NTP client polls the NTP server at
regular intervals and the server responds with a time stamp. The disadvantage 9.4 Synchronization
of using NTP for precise timing applications is that there is no allowance to 9.4.1 Packet Based
account for network delays other than through multiple poll time averaging Synchronization Methods
techniques and buffering. So NTP, even in the latest implementation, does 9.4.1.1 Adaptive Clock Recovery
not meet the higher precision requirements for 3G/4G mobile backhaul. 9.4.1.2 NTP
9.4.1.3 1588 v2

9.4.2 SyncE

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 8

MEF 22.1

MEF Reference Presentation: Access


Technologies

MEF-CECP Test Objectives

9 CES over Ethernet

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Synchronization over Carrier Ethernet & In this Section


Circuit Emulation 9 Synchronization over Carrier
Ethernet & Circuit Emulation
Study Guide Section 9.4.1.3 < br/>
1588 v2 9.1 Purpose and Need

The Precision Time Protocol (PTP) specified in IEEE standard 1588v2 is the 9.1.1 What is CESoETH
latest in packet-based timing technology. Originally designed to provide 9.1.2 MEF 8 model
precise timing for critical industrial automation applications, it is now < br/>
providing the highest level of accurate frequency, phase and time of day to
9.2 CES Components
wireless backhaul networks.
9.2.1 Interface to Customer
PTP overcomes the Ethernet NTP latency and delay variation issues, providing
9.2.2 Generic Interworking
an unprecedented accuracy in the nanosecond range. The effects of network Function (GIWF)
latency are greatly reduced by using a technique whereby the master and 9.2.3 Functional Layering
slave communicate with one another to cancel out a measured delay between
< br/>
the two nodes.
9.3 Service Definitions
The IEEE1588 standard makes several assumptions about the network being
9.3.1 E-Line
used (e.g. multicast support) but the key assumptions that affect clock
9.3.2 UNI Attributes
accuracy are:
9.3.3 EVC Attributes
1. The transmission delays are almost constant over time (or at least
9.3.4 EVC per UNI Attributes
change slowly)
< br/>
2. The transmission delays are symmetrical between master and slave
(i.e. time to travel from master to slave is the same as from slave to 9.4 Synchronization
master) 9.4.1 Packet Based
Synchronization Methods
When carried over a Carrier Ethernet Network (CEN), 1588v2 requires a
9.4.1.1 Adaptive Clock Recovery
dedicated CoS or even a dedicated EVC with stringent requirements on Frame
9.4.1.2 NTP
Loss Ratio, Frame Delay and Inter-frame Delay Variation.
9.4.1.3 1588 v2
PTP Network Components
9.4.2 SyncE
The following figure shows an example PTP synchronization network topology.
Download PDF

Download a pdf for


offline viewing.

Reference Documents
Figure 9.4.1.3.F1 - PTP Synchronization Network Topology

Grandmaster Clock MEF 8

MEF 22.1
This is the primary reference source within a PTP sub-domain. The
MEF Reference Presentation: Access
Grandmaster clock has a high-precision time source, which can be a GPS Technologies
reference or an atomic clock.

MEF-CECP Test Objectives


Boundary Clock
9 CES over Ethernet
Boundary Clock (BC) is specified by both Version 1 and Version 2 of IEEE
standard 1588. The boundary clock functionality can be implemented in a
Send Feedback
switch/router at the boundary of a network.

IEEE 1588 boundary clocks are an effective way to reduce packet delay Name:
variation. A boundary clock runs the PTP protocol and is synchronized to the
Email:
master clock. The boundary clock, in turn, acts as a master clock to all slaves
within the same network. Comments

The boundary clock acts as an interface between separate PTP domains


intercepting and processing all PTP messages and passing all other network
traffic. The boundary clock does not pass Sync, Follow_Up, Delay_Req, or Send Feedback

Delay_Resp messages.

Cascading of boundary clocks introduces the cascade effect, because boundary


clocks distribute timing based on the a local clock and so each clock depends
on the quality of all preceding clocks. The Best Master Clock (BMC) algorithm
(see below in PTP Operation) is used by the boundary clock to select the best
clock any port can connect to. The chosen port is set as a slave to the
selected Grandmaster clock, and all other ports of the boundary clock are
asserted as masters to their domain. The following figure shows a network
topology with boundary clocks:

Figure 9.4.1.3.F2 - Network Topology with Boundary Clocks

Transparent Clocks
Transparent clocks were added to version 2 of the 1588 standard as an
improved method of forming cascaded topologies where each clock does not
depend on the quality of the preceding clocks. Rather than acting as a multi-
port ordinary clock as boundary clocks do, transparent clocks update a newly
introduced time-interval field within PTP event messages. This 64-bit time-
interval correction field allows for switch delay compensation to a potential
accuracy of less than ne picosecond.

There are two types of transparent clocks:- end-to-end and peer-to-peer.

End-to-end transparent clocks forward PTP event messages, but modify the
messages for the residence time for the message to traverse the transparent
clock. The residence times are accumulated in the correction field of the PTP
event message or the associated follow-up message.

Figure 9.4.1.3.F3 - Transparent Clocks

Peer-to-peer transparent clocks measure the local link delays using the peer
delay mechanism, in addition to the residence time. The computation of link
delay (peer delay mechanism) is based on an exchange of Pdelay_Req,
Pdelay_Resp, and possibly Pdelay_Resp_Follow_Up messages with the link
peer.

Figure 9.4.1.3.F4 -Peer to Peer

Peer-to-peer and end-to-end transparent clocks cannot be mixed on the same


communication path. Peer-to-peer transparent clocks can allow for faster
reconfiguration after network topology changes.

In summary, transparent clock is a PTP enhanced switch which modifies the


precise timestamps within the PTP messages to account for receive and
transmit delays within the individual switch itself, thus leading to more
accurate synchronization between the slave and master clocks.

PTP Operation

PTP operation is based upon the transfer of short messages to determine


system properties and to convey time information. A delay measurement
method is used to determine path delay, which is then used for the
adjustment of local clocks. IEEE 1588 uses a specific algorithm - the Best
Master Clock (BMC) algorithm - in order to determine which clock is of the
highest quality within the network and to create a master/slave hierarchy.

The BMC node (grandmaster clock) then synchronizes all other nodes (slave
clocks) in the network. The BMC algorithm is then run continuously to quickly
adjust for changes in network configuration. So, if the BMC node is removed
from the network or is determined by the BMC algorithm to no longer have
the highest quality clock, the algorithm determines the new BMC node.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Synchronization over Carrier Ethernet & In this Section


Circuit Emulation 9 Synchronization over Carrier
Ethernet & Circuit Emulation
Study Guide Section 9.4.2 < br/>
SyncE 9.1 Purpose and Need

The IEEE 802.3-2008 standard specifies that transmit clocks can operate with 9.1.1 What is CESoETH
a frequency accuracy of up to +/-100 ppm. 9.1.2 MEF 8 model

< br/>
The Synchronous Ethernet (SyncE) approach provides a mechanism to deliver a
network traceable physical layer clock over IEEE 802.3 PHYs with EEC as 9.2 CES Components
specified in ITU-T G.8262 [33]. The SyncE model follows the same approach 9.2.1 Interface to Customer
that was adopted for traditional TDM (PDH/SDH) synchronization (i.e. utilizing
9.2.2 Generic Interworking
the physical layer line signals) and implemented with similar engineering rules Function (GIWF)
and principles. Synchronous Ethernet has also been designed specifically to 9.2.3 Functional Layering
inter-work with the existing SONET/SDH synchronization infrastructure.
< br/>
Note that Synchronous Ethernet is used to deliver frequency, but not phase or 9.3 Service Definitions
time of day.
9.3.1 E-Line

The following figure proivdes an example of synchronization using Synchronous 9.3.2 UNI Attributes
Ethernet: 9.3.3 EVC Attributes

9.3.4 EVC per UNI Attributes

< br/>

9.4 Synchronization

9.4.1 Packet Based


Synchronization Methods

9.4.1.1 Adaptive Clock Recovery

9.4.1.2 NTP
Figure 9.4.2.F1 - Synchronization using Synchronous Ethernet
[Source: MEF 22.1, Figure 22] 9.4.1.3 1588 v2

The architectural aspects of Synchronous Ethernet are defined in ITU-T 9.4.2 SyncE
G.8261. SyncE provides the capability to provide an Ethernet clock that is
traceable to a primary reference clock (PRC) as defined in ITU-T G.811. Download PDF

The details of the clock aspects of Synchronous Ethernet equipment can be


found in the ITU-T G.8262. The latter specification defines the requirements Download a pdf for
for clock accuracy, noise transfer, holdover performance, noise tolerance and offline viewing.
noise generation.

It should be noted that SyncE requires all network elements in the network to
be upgraded to support SyncE. Therefore SyncE might only be practical for Reference Documents
use in small network domains, while a hybrid solution complemented by a
packet-based synchronization method would be required to extend its reach. MEF 8

MEF 22.1

MEF Reference Presentation: Access
Technologies

MEF-CECP Test Objectives

9 CES over Ethernet

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Test Objectives 9 1 In this Section


Circuit Emulation over Ethernet 9 Synchronization over Carrier
Ethernet & Circuit Emulation
9.1 Define the purpose and need for Circuit Emulation over Ethernet
applications. < br/>

9.1 Purpose and Need


9.2 Define the critical components of circuit emulation over Ethernet service.
9.1.1 What is CESoETH
9.3 Define the MEF Service Definitions used to deliver emulated circuits. 9.1.2 MEF 8 model

9.4 Define the EVC service attributes required for emulated circuits. < br/>

9.2 CES Components


9.5 Define the three techniques and their uses for delivering synchronized
clock over emulated circuits (e.g., Adaptive, 1588v2, Synchronous Ethernet, 9.2.1 Interface to Customer

NTP, PTP). 9.2.2 Generic Interworking


Function (GIWF)
9.6 Describe how circuit emulation is used in Mobile Backhaul applications. 9.2.3 Functional Layering

< br/>

9.3 Service Definitions

9.3.1 E-Line

9.3.2 UNI Attributes

9.3.3 EVC Attributes

9.3.4 EVC per UNI Attributes

< br/>

9.4 Synchronization

9.4.1 Packet Based


Synchronization Methods

9.4.1.1 Adaptive Clock Recovery

9.4.1.2 NTP
9.4.1.3 1588 v2

9.4.2 SyncE

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 8

MEF 22.1

MEF Reference Presentation: Access


Technologies

MEF-CECP Test Objectives

9 CES over Ethernet

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.1 Maintenance

10.1 Relevant Standards


Relevant Standards
10.1.1 IEEE 802.1ag Overview
Ethernet OAM is based on several standards: 10.1.2 Y.1731 Overview

IEEE 802.3ah: Link OAM < br/>


IEEE 802.1ag: Connectivity Fault Management (CFM) 10.2 Framework
ITU-T Y.1731: Requirements for OAM functions in Ethernet-based
10.2.0 Domains
networks and Ethernet services
10.2.1 Constructs
The following figure describes their relationship and applicability for Ethernet 10.2.1.1 MEP, MIP, MEG, MEG
services: Level

10.2.2 MEF 17

10.2.2.1 Model

10.2.2.2 Maintenance Entities

< br/>

10.3 Fault Management

10.3.1 Definition
10.1.F1 - SOAM relationship between standards
10.3.2 Procedures

10.3.2.1 Continuity Check


Message

10.3.2.2 Loopback Message

10.3.2.3 Link Trace Message

< br/>
10.4 Performance Management

10.4.1 Definition

10.4.2 Procedures

10.4.2.0 Frame Delay

10.4.2.1 Delay Measurement


Message

10.4.2.2 Loss Measurement


Message

10.4.3 Computation Methods

10.4.3.0 Frame Delay

10.4.3.1 Inter-Frame Delay


Variation

10.4.3.2 Frame Loss Ratio

10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


LAN, E-Tree

< br/>

10.5 CoS Implementation


Agreement - MEF 23

10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.1.1 Maintenance

10.1 Relevant Standards


IEEE 802.1ag Overview
10.1.1 IEEE 802.1ag Overview
IEEE 802.1ag specifies protocols and procedures for Connectivity Fault 10.1.2 Y.1731 Overview
Management (CFM) for VLANs or services. These services could be Ethernet
< br/>
Virtual Connections (EVCs) or Operator Virtual Connections (OVCs)
10.2 Framework
IEEE 802.1ag defines methods to:
10.2.0 Domains

detect 10.2.1 Constructs


verify 10.2.1.1 MEP, MIP, MEG, MEG
isolate Level
report 10.2.2 MEF 17

10.2.2.1 Model
end-to-end Ethernet connectivity faults.
10.2.2.2 Maintenance Entities
Ethernet OAM runs over bridged networks in the Ethernet service layer, as
< br/>
opposed to link layer OAM that is specified by IEEE 802.3 for cases where the
link is Ethernet. 10.3 Fault Management

10.3.1 Definition
IEEE 802.1ag and ITU-T Y.1731 define joint constructs and terminology. It
10.3.2 Procedures
enables defining levels of hierarchical administrative domains, performing the
CFM procedures within each domain independently. 10.3.2.1 Continuity Check
Message
The following procedures and packet formats are defined: 10.3.2.2 Loopback Message

10.3.2.3 Link Trace Message


1. Continuity Check
2. Loopback < br/>
3. Link trace 10.4 Performance Management
4. Alarm Indication Using Remote Defect Indication (RDI) - RDI is
10.4.1 Definition
triggered by the fault detection mechanism in the CCM procedure .
10.4.2 Procedures

10.4.2.0 Frame Delay

10.4.2.1 Delay Measurement


Message

10.4.2.2 Loss Measurement


Message

10.4.3 Computation Methods

10.4.3.0 Frame Delay

10.4.3.1 Inter-Frame Delay


Variation

10.4.3.2 Frame Loss Ratio

10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


LAN, E-Tree

< br/>

10.5 CoS Implementation


Agreement - MEF 23

10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.1.2 Maintenance

10.1 Relevant Standards


ITU-T Y.1731 Overview
10.1.1 IEEE 802.1ag Overview
ITU-T Y.1731 augments IEEE 802.1ag in defining capabilities to perform 10.1.2 Y.1731 Overview
Performance Monitoring (PM) for Ethernet services. It also provides additional
< br/>
Fault Management (FM) capabilities. Y.1731 defines the frame format and
multicast addresses to be used for both PM and FM. 10.2 Framework
The following procedures and packet formats are defined: 10.2.0 Domains

1. AIS (Alarm Indication Signal): Generated when an end-point detects loss 10.2.1 Constructs
of connectivity 10.2.1.1 MEP, MIP, MEG, MEG
2. Lock: Used to verify connectivity problems in out-of-service mode Level

3. Test: Used to test the connectivity out-of-service. It can be used as 10.2.2 MEF 17
part of RFC 2544 or ITU-T Y.1564 testing 10.2.2.1 Model
4. Delay Measurements: Using DMM/DMR procedure 10.2.2.2 Maintenance Entities
5. Loss Measurement: Using LMM/LMR procedure
< br/>
Some messages use unicast MAC DA and some use reserved multicast DA, 10.3 Fault Management
which is treated as L2CP. For multicast, the MAC DA address is defined as
10.3.1 Definition
follows:
10.3.2 Procedures
There are two types of frames: Class 1 and Class 2 10.3.2.1 Continuity Check
Message
Class 1 - used by CCM - uses MAC DA of 01-c2-80-00-00-30 through 01-c2-80-
10.3.2.2 Loopback Message
00-00-3x, where MEG level is represented by x
10.3.2.3 Link Trace Message
Class 2 - used by LBM and LTM - uses MAC DA of 01-c2-80-00-00-3y through < br/>
01-c2-80-00-00-3F, where y=8+MEG level
10.4 Performance Management

10.4.1 Definition

10.4.2 Procedures

10.4.2.0 Frame Delay

10.4.2.1 Delay Measurement


Message

10.4.2.2 Loss Measurement


Message

10.4.3 Computation Methods

10.4.3.0 Frame Delay

10.4.3.1 Inter-Frame Delay


Variation

10.4.3.2 Frame Loss Ratio

10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


LAN, E-Tree

< br/>

10.5 CoS Implementation


Agreement - MEF 23

10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.2 Maintenance

10.1 Relevant Standards


Framework
10.1.1 IEEE 802.1ag Overview
This section explains about the domains and constructs used in Ethernet 10.1.2 Y.1731 Overview
Service OAM, as well as MEF 17 Framework and Requirements Phase 1.
< br/>

10.2 Framework

10.2.0 Domains

10.2.1 Constructs

10.2.1.1 MEP, MIP, MEG, MEG


Level

10.2.2 MEF 17

10.2.2.1 Model

10.2.2.2 Maintenance Entities

< br/>

10.3 Fault Management

10.3.1 Definition

10.3.2 Procedures

10.3.2.1 Continuity Check


Message

10.3.2.2 Loopback Message

10.3.2.3 Link Trace Message

< br/>
10.4 Performance Management

10.4.1 Definition

10.4.2 Procedures

10.4.2.0 Frame Delay

10.4.2.1 Delay Measurement


Message

10.4.2.2 Loss Measurement


Message

10.4.3 Computation Methods

10.4.3.0 Frame Delay

10.4.3.1 Inter-Frame Delay


Variation

10.4.3.2 Frame Loss Ratio

10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


LAN, E-Tree

< br/>

10.5 CoS Implementation


Agreement - MEF 23

10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.2.0 Maintenance

10.1 Relevant Standards


Domains
10.1.1 IEEE 802.1ag Overview
An OAM Domain is defined as a network or sub-network, operating at the ETH 10.1.2 Y.1731 Overview
Layer and belonging to the same administrative entity within which OAM
< br/>
frames can be exchanged.
10.2 Framework
Each Service Provider and/or Operator network is typically associated with an
10.2.0 Domains
administrative boundary. A service may be implemented across a single or
10.2.1 Constructs
across multiple (sub)networks. An OAM Domain determines the span of an OAM
flow across such administrative boundaries. OAM Domains can be hierarchical 10.2.1.1 MEP, MIP, MEG, MEG
Level
but must not partially overlap.
10.2.2 MEF 17
A Subscriber's OAM Domain may completely overlap multiple Service Providers' 10.2.2.1 Model
OAM Domains such that Service Providers OAM Domains remain transparent to
10.2.2.2 Maintenance Entities
the Subscriber's OAM Domain.
A Service Provider's OAM Domain may completely overlap multiple CEN < br/>
Operators' OAM Domains such that CEN Operators OAM Domains remain 10.3 Fault Management
transparent to Service Provider's OAM Domain. 10.3.1 Definition

The following figure illustrates an OAM domain: A single CEN to which 4 CEs 10.3.2 Procedures
are attached: 10.3.2.1 Continuity Check
Message

10.3.2.2 Loopback Message

10.3.2.3 Link Trace Message

< br/>
10.4 Performance Management

10.4.1 Definition

10.4.2 Procedures
10.2.0.F1 - SOAM Domain 10.4.2.0 Frame Delay
[Source: MEF30, Figure 2]
10.4.2.1 Delay Measurement
Message

10.4.2.2 Loss Measurement


Message

10.4.3 Computation Methods

10.4.3.0 Frame Delay

10.4.3.1 Inter-Frame Delay


Variation

10.4.3.2 Frame Loss Ratio

10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


LAN, E-Tree

< br/>

10.5 CoS Implementation


Agreement - MEF 23

10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect
ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.2.1 Maintenance

10.1 Relevant Standards


Constructs
10.1.1 IEEE 802.1ag Overview
This section explains the basic constructs of Ethernet Service OAM. 10.1.2 Y.1731 Overview

ME (Maintenance Entity) represents an OAM entity that requires management. < br/>
An ME is essentially an association between two maintenance end points 10.2 Framework
within an OAM Domain, where each maintenance end point corresponds to a
10.2.0 Domains
provisioned reference point that requires management.
10.2.1 Constructs
The MEs that are relevant for E-Lines are shown in the figure below: 10.2.1.1 MEP, MIP, MEG, MEG
Level

10.2.2 MEF 17

10.2.2.1 Model

10.2.2.2 Maintenance Entities

< br/>
10.2.1.F2 - SOAM Maintenance Entities 10.3 Fault Management
[Source: MEF 17, Figure 1]
10.3.1 Definition
Subscriber ME is the OAM Domain that connects the Customer Equipment of
10.3.2 Procedures
the Subscriber. For E-LAN and E-Tree, there will typically be more than two
such end-points. 10.3.2.1 Continuity Check
Message
EVC ME is the OAM domain that connects the UNI-Ns of a given EVC. 10.3.2.2 Loopback Message

10.3.2.3 Link Trace Message


Operator ME is the OAM domain of the OVC within the Operator's CEN.
< br/>
UNI ME is the OAM domain between UNI-C and UNI-N.
10.4 Performance Management
NNI ME is the OAM domain between ENNI-Ns of a given ENNI. 10.4.1 Definition
Note that in some deployments not all MEs exist. For example when the UNI
10.4.2 Procedures
link is not managed, the UNI ME does not exist.
10.4.2.0 Frame Delay
Test ME is the OAM domain between UNI-Cs that enables the Service Provider 10.4.2.1 Delay Measurement
to isolate problems reported by the Subscriber. Message
Note that the Test ME is not active at all times, but is used on an on-demand 10.4.2.2 Loss Measurement
basis. Message

10.4.3 Computation Methods

10.4.3.0 Frame Delay

10.4.3.1 Inter-Frame Delay


Variation

10.4.3.2 Frame Loss Ratio

10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


LAN, E-Tree

< br/>

10.5 CoS Implementation


Agreement - MEF 23

10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.2.1.1 Maintenance

10.1 Relevant Standards


MEG, MEP, MIP and MEG Level
10.1.1 IEEE 802.1ag Overview
MEG (Maintenance Entity Group for ME Group) 10.1.2 Y.1731 Overview

A MEG consists of the maintenance entities (ME) that belong to the same < br/>
service inside a common Service OAM domain.
10.2 Framework
For a Point-to-Point EVC, a MEG contains a single ME. 10.2.0 Domains
For a Multipoint-to-Multipoint EVC of n UNIs, a MEG contains n*(n- 10.2.1 Constructs
1)/2 MEs.
10.2.1.1 MEP, MIP, MEG, MEG
Note that IEEE 802.1ag uses the terminology of MA (Maintenance Association). Level

MEF is aligned with the ITU-T terminology of MEG. 10.2.2 MEF 17

10.2.2.1 Model
MEP (MEG End Point)
10.2.2.2 Maintenance Entities
A MEP is a provisioned OAM reference point which can initiate and terminate
< br/>
proactive OAM frames. A MEP can also initiate and react to diagnostic OAM
frames. A MEP is represented by a triangle symbol as shown in the SOAM 10.3 Fault Management
Constructs section. 10.3.1 Definition

A Point-to-Point EVC has two MEPs, one at each end-point of the ME 10.3.2 Procedures
(i.e. each UNI-N) 10.3.2.1 Continuity Check
Message
A Multipoint-to-Multipoint EVC of n UNIs has n MEPs, one at each
end-point 10.3.2.2 Loopback Message
A Point-to-Point OVC has two MEPs, one at each end-point of the ME 10.3.2.3 Link Trace Message
(each External Interface associated with the OVC)
< br/>

10.4 Performance Management
MIP (MEG Intermediate Point) 10.4.1 Definition

A MEG Intermediate Point (MIP) is a provisioned OAM reference point which is 10.4.2 Procedures
capable of reacting to diagnostic OAM frames initiated by MEPs. A MIP does 10.4.2.0 Frame Delay
not initiate proactive or diagnostic OAM frames. A MIP is represented by a
10.4.2.1 Delay Measurement
circle symbol as shown in the SOAM Constructs section. The number of MIPs Message
in a Point-to-Point EVC or Multipoint-to-Multipoint EVC is dependent on the 10.4.2.2 Loss Measurement
specific deployments. MIPs are used for Fault Management. Message

10.4.3 Computation Methods

10.4.3.0 Frame Delay


MEG Level
10.4.3.1 Inter-Frame Delay
MEG Level is used to distinguish between OAM frames belonging to different Variation
nested MEs, as shown in the SOAM Constructs section. MEs belonging to the 10.4.3.2 Frame Loss Ratio
same MEG share a common MEG Level. Eight MEG Levels have been specified
10.4.3.3 Availability
for the purposes of Ethernet Sevice OAM: Levels 0 through 7.
10.4.4 Measurement in E-Line, E-
LAN, E-Tree

When Subscribers, Service Providers, and Network Operators share a given < br/>
MEG Level space, allocation of MEG Levels can be negotiated among the
10.5 CoS Implementation
different parties involved. Agreement - MEF 23
A default allocation of MEG Levels is such that:- 10.5.1 Ethernet Network Section

Service OAM frames for a Subscriber ME use MEG Level 7, 6 or 5 10.5.2 CoS Label Model
Service OAM frames for an EVC ME use MEG Level 3 or 4 as the EVC 10.5.3 Performance Parameters
ME belongs to a Service Provider OAM Domain
< br/>
Operator MEs use MEG Levels 2, 1, or 0.
The MEG Levels used for UNI ME and NNI ME will default to 0. 10.6 Performance Management
Implementation
This default allocation of MEG Level space between Subscribers, Service 10.6.1 Multi-CoS EVC
Providers and Operators can be changed according to mutual agreement of
10.6.2 Relationship to Bandwidth
the parties. Profile

MEF 30 specifies the following default MEG Level allocation per ME: 10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2
10.2.1.1.F1 - Default MEG Levels
[Source: MEF30, Table 3] MEF 17

MEG levels are allocated in a hierarchical manner to enable the following MEF Reference Presentation:
Interconnect
capabilities:
ITU-T Y.1731
From a given MEG level point of view, higher level MEGs are passed
transparently, but lower level MEGs are not allowed to pass MEF-CECP Test Objectives
A MEP at a given MEG Level must consume OAM frames with this MEG
10 Service OAM
level

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.2.2 Maintenance

10.1 Relevant Standards


MEF 17
10.1.1 IEEE 802.1ag Overview
MEF 17 is "Service OAM Framework and Requirements Phase 1". MEF 17 10.1.2 Y.1731 Overview
provides requirements to be satisfied by the Service OAM mechanisms in
< br/>
Carrier Ethernet Networks and a framework for discussing and implementing
those mechanisms. It also provides context for several MEF specifications (UNI 10.2 Framework
Type 2 and ENNI) and the work of other standards bodies. 10.2.0 Domains

10.2.1 Constructs
MEF 17 addresses the following specific functional areas of Service OAM:
10.2.1.1 MEP, MIP, MEG, MEG
Fault Management : detection, verification, localization and Level
notification of faults 10.2.2 MEF 17
Performance Monitoring (including performance parameter 10.2.2.1 Model
measurements)
10.2.2.2 Maintenance Entities
Auto-discovery (including discovering service aware network elements
within provider networks) < br/>
Intra-provider and inter-provider Service OAM 10.3 Fault Management

10.3.1 Definition
The reader should note that provisioning aspects of Ethernet services and
CENs are not addressed in MEF 17. 10.3.2 Procedures

10.3.2.1 Continuity Check


Message

10.3.2.2 Loopback Message

10.3.2.3 Link Trace Message

< br/>
10.4 Performance Management

10.4.1 Definition

10.4.2 Procedures

10.4.2.0 Frame Delay

10.4.2.1 Delay Measurement


Message

10.4.2.2 Loss Measurement


Message

10.4.3 Computation Methods

10.4.3.0 Frame Delay

10.4.3.1 Inter-Frame Delay


Variation

10.4.3.2 Frame Loss Ratio

10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


LAN, E-Tree

< br/>

10.5 CoS Implementation


Agreement - MEF 23

10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.2.2.1 Maintenance

10.1 Relevant Standards


Model
10.1.1 IEEE 802.1ag Overview
The Service OAM scope for Ethernet services is illustrated below: 10.1.2 Y.1731 Overview

< br/>

10.2 Framework

10.2.0 Domains

10.2.1 Constructs

10.2.1.1 MEP, MIP, MEG, MEG


Level
10.2.2.1.F1 - SOAM Service Scope
10.2.2 MEF 17
Provisioning and Turn-up of the Circuit is outside the scope of MEF
10.2.2.1 Model
specifications and this study guide.
10.2.2.2 Maintenance Entities
The following figure from MEF 30, which is based on MEF 17 figure 1,
< br/>
illustrates pairs of MEPs (thus MEs) and MIPs that may be communicating
10.3 Fault Management
across the various OAM domains defined by MEF 17, and also illustrates the
hierarchical relationship between these domains. Note that the orientations of 10.3.1 Definition
the MEPs in the diagram are exemplary, and are not requirements. 10.3.2 Procedures

10.3.2.1 Continuity Check


Message

10.3.2.2 Loopback Message

10.3.2.3 Link Trace Message

< br/>
10.2.2.1.F2 - SOAM Maintenance Entities 10.4 Performance Management
[Source: MEF 30, Figure 1]
10.4.1 Definition
A network element (NE) that implements UNI-N functionality, for example the
10.4.2 Procedures
NE denoted as 2 in the figure, has a MEP at MEG level 4 for each EVC instance
that associates that UNI. 10.4.2.0 Frame Delay

10.4.2.1 Delay Measurement


Any SOAM message with MEG level 4 or lower must be consumed by that NE. Message
Any SOAM message with MEG level 5 or higher is passed through transparently. 10.4.2.2 Loss Measurement
Message
One can also see that the same NE can have a MIP at MEG level 7, enabling
10.4.3 Computation Methods
the subscriber to troubleshoot connectivity problems between the CE and this
10.4.3.0 Frame Delay
NE.
10.4.3.1 Inter-Frame Delay
Since SOAM are used for fault management and performance management of Variation
interfaces and EVC/OVCs, they must traverse the same path as the service 10.4.3.2 Frame Loss Ratio
frames that are associated with that EVC/OVC. 10.4.3.3 Availability

This means that service frames and SOAM will have the same EVC headers as 10.4.4 Measurement in E-Line, E-
LAN, E-Tree
the service frames.
< br/>
This requirement leads to the requirement of deterministic and controlled
10.5 CoS Implementation
assignment of flows to shared links in a LAG. Agreement - MEF 23

10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.2.2.2 Maintenance

10.1 Relevant Standards


Maintenance Entities
10.1.1 IEEE 802.1ag Overview
MEF 17 and MEF 30 (which adds the Test ME) together define the following
10.1.2 Y.1731 Overview
MEs:
< br/>
Subscriber ME
10.2 Framework
The Subscriber ME spans the network between two UNI-Cs of the subscriber. It 10.2.0 Domains
is managed by the subscriber. However, the Service Provider (SP) and/or CEN
10.2.1 Constructs
Operator can configure MIPs inside the CEN - or at the CEN's edge (UNI-N) - to
10.2.1.1 MEP, MIP, MEG, MEG
help with connectivity troubleshooting. Any performance monitoring done Level
between MEPs of this ME are passed as service frames from the SP's point of
10.2.2 MEF 17
view. This ME must use the highest MEG levels. MEF 17 allocates levels 5, 6
and 7. SOAMs should be C-tagged with same CE-VLAN ID that is mapped to the 10.2.2.1 Model

appropriate EVC. 10.2.2.2 Maintenance Entities

< br/>
Test ME
10.3 Fault Management
The Test ME is assigned to the Service Provider for isolation of problems
10.3.1 Definition
reported by the subscriber. The Test ME uses MEPs placed in the subscriber's
equipment, at the UNI-C, and at least one MEP within the Service Provider's 10.3.2 Procedures
network. The Test ME is not active at all times, but is used on an on-demand 10.3.2.1 Continuity Check
basis. Message

10.3.2.2 Loopback Message


EVC ME
10.3.2.3 Link Trace Message
An EVC ME is intended to provide the most complete view of the EVC. The
< br/>
MEPs in the EVC ME are placed as close to the UNI reference point as possible.
10.4 Performance Management
This ME is used to perform performance monitoring of the EVC and can also
be used for EVC fault management. 10.4.1 Definition

10.4.2 Procedures
Operator ME
10.4.2.0 Frame Delay
An Operator ME is intended to provide the most complete view of the OVC.
10.4.2.1 Delay Measurement
The MEPs in the Operator ME are placed as close to the external interfaces Message
associated by this OVC as possible. This ME is used to perform performance
10.4.2.2 Loss Measurement
monitoring of the OVC and can also be used for OVC fault management. This Message
ME is confined to a single CEN and is used only for cases where an ENNI exists. 10.4.3 Computation Methods

UNI ME 10.4.3.0 Frame Delay

10.4.3.1 Inter-Frame Delay


A UNI ME is used to monitor the UNI link, as specified in MEF 20. It is Variation
mandatory for UNI Type 2. Since in many cases the UNI link is not a network,
10.4.3.2 Frame Loss Ratio
performance monitoring is less relevant. However fault monitoring activities
are important for this ME. 10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


ENNI ME LAN, E-Tree

ENNI ME is used to monitor the ENNI link between two ENNI-Ns. OAM messages < br/>
use the active link to ensure that they monitor the same physical link used for 10.5 CoS Implementation
ENNI frames. Since the ENNI link is a wire and not a network, performance Agreement - MEF 23
monitoring is less relevant. However fault monitoring activities are important 10.5.1 Ethernet Network Section
for this ME. 10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.3 Maintenance

10.1 Relevant Standards


Fault Management
10.1.1 IEEE 802.1ag Overview
This section provides the definition of fault management for Carrier Ethernet 10.1.2 Y.1731 Overview
services, as well as the procedures defined for implementing it.
< br/>

10.2 Framework

10.2.0 Domains

10.2.1 Constructs

10.2.1.1 MEP, MIP, MEG, MEG


Level

10.2.2 MEF 17

10.2.2.1 Model

10.2.2.2 Maintenance Entities

< br/>

10.3 Fault Management

10.3.1 Definition

10.3.2 Procedures

10.3.2.1 Continuity Check


Message

10.3.2.2 Loopback Message

10.3.2.3 Link Trace Message

< br/>
10.4 Performance Management

10.4.1 Definition

10.4.2 Procedures

10.4.2.0 Frame Delay

10.4.2.1 Delay Measurement


Message

10.4.2.2 Loss Measurement


Message

10.4.3 Computation Methods

10.4.3.0 Frame Delay

10.4.3.1 Inter-Frame Delay


Variation

10.4.3.2 Frame Loss Ratio

10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


LAN, E-Tree

< br/>

10.5 CoS Implementation


Agreement - MEF 23

10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.3.1 Maintenance

10.1 Relevant Standards


Definition
10.1.1 IEEE 802.1ag Overview
MEF FM describes the use of standard protocols, mechanisms, and procedures
10.1.2 Y.1731 Overview
for monitoring and investigating the status of Ethernet Virtual Connections
(EVCs), Operator Virtual Connections (OVCs), and External Interfaces (UNI and < br/>

ENNI) across a defined OAM Domain, where that domain can be a large 10.2 Framework
network (or subnetwork), or a simple link. SOAM FM uses the protocols 10.2.0 Domains
described in IEEE 802.1ag and ITU-T Y.1731. It provides end-to-end Ethernet
10.2.1 Constructs
connectivity management, mechanisms to detect, verify, isolate and report
10.2.1.1 MEP, MIP, MEG, MEG
faults that affect the external interfaces or the EVC/OVCs. The following
Level
sections describe the use of FM procedures and mechanisms with the
10.2.2 MEF 17
appropriate parameter settings that meet the requirements for fault
management of Ethernet services in the CEN. 10.2.2.1 Model

10.2.2.2 Maintenance Entities


It should be noted that the transport layer of the CEN may also have its own
< br/>
FM mechanism (e.g. BFD and VCCV in MPLS-based networks), these
mechanisms and the interaction between them and the Ethernet layer's FM 10.3 Fault Management
are outside the scope of this document. Once a fault is detected in the 10.3.1 Definition
Ethernet layer, reports are made available for any higher-layer that is carried 10.3.2 Procedures
over this layer. The details of reporting are outside the scope of this
10.3.2.1 Continuity Check
document. Message

10.3.2.2 Loopback Message

10.3.2.3 Link Trace Message

< br/>
10.4 Performance Management

10.4.1 Definition

10.4.2 Procedures

10.4.2.0 Frame Delay

10.4.2.1 Delay Measurement


Message

10.4.2.2 Loss Measurement


Message

10.4.3 Computation Methods

10.4.3.0 Frame Delay

10.4.3.1 Inter-Frame Delay


Variation

10.4.3.2 Frame Loss Ratio

10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


LAN, E-Tree

< br/>

10.5 CoS Implementation


Agreement - MEF 23

10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section

Administration and Maintenance 10 Carrier Ethernet Service


Operations, Administration and
Maintenance
Study Guide Section 10.3.2 10.1 Relevant Standards

Procedures 10.1.1 IEEE 802.1ag Overview

10.1.2 Y.1731 Overview


This section provides explanations of the procedures used for Fault
Management in Carrier Ethernet Service OAM: < br/>

10.2 Framework
Continuity Check Message
Loopback Message 10.2.0 Domains

Link Trace Message 10.2.1 Constructs

10.2.1.1 MEP, MIP, MEG, MEG


Level

10.2.2 MEF 17

10.2.2.1 Model

10.2.2.2 Maintenance Entities

< br/>

10.3 Fault Management

10.3.1 Definition

10.3.2 Procedures

10.3.2.1 Continuity Check


Message

10.3.2.2 Loopback Message

10.3.2.3 Link Trace Message

< br/>
10.4 Performance Management

10.4.1 Definition

10.4.2 Procedures

10.4.2.0 Frame Delay

10.4.2.1 Delay Measurement


Message

10.4.2.2 Loss Measurement


Message

10.4.3 Computation Methods

10.4.3.0 Frame Delay

10.4.3.1 Inter-Frame Delay


Variation

10.4.3.2 Frame Loss Ratio

10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


LAN, E-Tree

< br/>

10.5 CoS Implementation


Agreement - MEF 23

10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.3.2.1 Maintenance

10.1 Relevant Standards


Continuity Check Message (CCM)
10.1.1 IEEE 802.1ag Overview
The Continuity Check Message (CCM) is a message defined by IEEE 802.1ag in 10.1.2 Y.1731 Overview
order to verify the connectivity at the ETH layer between 2 MEPs sharing the
< br/>
same MEG Level within an ME. These messages are sent proactively at a
configurable interval. Both ends need to be configured with the proper 10.2 Framework
transmission interval. The far end declares a connectivity failure when it does 10.2.0 Domains
not receive a CCM within a time interval that is N times (default 3) the 10.2.1 Constructs
transmission interval.
10.2.1.1 MEP, MIP, MEG, MEG
Level
The sending interval depends on the application behind the sending of CCMs.
The following is common practice: 10.2.2 MEF 17

10.2.2.1 Model
Protection switching: 10 msec or 3.33 msec
10.2.2.2 Maintenance Entities
Availability measurement: 1 or 10 seconds < br/>

CCMs can be administratively turned on and off, but compliant NEs must 10.3 Fault Management
support CCMs. 10.3.1 Definition

10.3.2 Procedures
CCMs can be sent at any MEG Level, depending on the ME they monitor
(Subscriber ME, EVC ME, Operator ME, etc). 10.3.2.1 Continuity Check
Message
CCMs sent by the Subscriber ME must be set with the CE-VLAN ID that maps to 10.3.2.2 Loopback Message
the monitored EVC. Such frames are subject to the Bandwidth Profile and are 10.3.2.3 Link Trace Message
considered to be Service Frames.
< br/>
For SP ME, CCMs are carried using the same transport path and identifiers as 10.4 Performance Management
service frames for that EVC. Such frames may be subject to the EVC BWP, but
10.4.1 Definition
in some implementations, these CCMs are sent after the Ingress Bandwidth
10.4.2 Procedures
Profile point in order to reduce the risk of them being dropped. In such a
case, and when color forwarding is used, they are marked as green frames. 10.4.2.0 Frame Delay

10.4.2.1 Delay Measurement


Since CCMs can trigger protection switching, they should encounter the Message
minimal delay possible between MEPs, and should not be dropped due to 10.4.2.2 Loss Measurement
congestion. MEF recommends sending CCMs at the highest priority permissible Message
by the EVC (this makes sense when the EVC/OVC supports multiple CoS IDs). 10.4.3 Computation Methods
CoS IDs must be set to ensure lowest possible frame loss. 10.4.3.0 Frame Delay

When CCMs are sent for a given ME, this ME can have the following 10.4.3.1 Inter-Frame Delay
Variation
Connectivity Status values:
10.4.3.2 Frame Loss Ratio
Active : A ME Connectivity Status of active implies that Service OAM 10.4.3.3 Availability
frames can be exchanged between the MEPs in both directions.
10.4.4 Measurement in E-Line, E-
Not Active : A ME Connectivity Status of not active implies that LAN, E-Tree
Service OAM frames cannot be exchanged in both directions between
< br/>
the MEPs of the ME.
10.5 CoS Implementation
A Multipoint-to-Multipoint MEG can have the following Connectivity Status Agreement - MEF 23
values: 10.5.1 Ethernet Network Section

10.5.2 CoS Label Model


Active : A MEG Connectivity Status of active implies that each ME in
the MEG has a Connectivity Status of active. 10.5.3 Performance Parameters

Not Active : A MEG Connectivity Status of not active implies that each < br/>
ME in the MEG has a Connectivity Status of not active.
10.6 Performance Management
Partially Active : A MEG Connectivity Status of partially active implies Implementation
that there exist at least one active ME and one not active ME in the 10.6.1 Multi-CoS EVC
MEG.
10.6.2 Relationship to Bandwidth
Profile
The following figure illustrates CCMs monitoring 3 MEs:
10.6.3 Interconnect via ENNI
Subscriber ME (green line) between 2 MEPs at the CE. Used by the subscriber
in order to monitor the end to end connectivity between its locations. Download PDF

SP ME (blue line) between 2 MEPs at the UNI-N Operator. Note that in this
example, the EVC monitoring crosses 2 CENs. These CCMs can be used for EVC
Download a pdf for
availability measurement and thus are expected to be sent at 1 or 10 second offline viewing.
intervals.

Operator ME (orange line) between 2 MEPs at the OVC end points. Each of
the 2 CEN Operators run CCMs on its own operated OVC. These CCMs can be Reference Documents
used for OVC availability measurement and thus are expected to be sent at 1
or 10 second intervals. MEF 10.2

MEF 17
Note that these CCMs are constantly being sent. Once the Operator identifies
a fault, the Operator needs to isolate the fault. That is understand which MEF Reference Presentation:
Interconnect
network element or link has failed. In order to do so, the Operator can start
a Loopback or Linktrace procedure. ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback
10.3.2.1.F1 - Example use of SOAM CCM

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.3.2.2 Maintenance

10.1 Relevant Standards


Loopback Message (LBM)
10.1.1 IEEE 802.1ag Overview
Loopback messages (LBM) are defined by IEEE 802.1ag and are used on- 10.1.2 Y.1731 Overview
demand in order to isolate a fault, which may have been detected by CCMs.
< br/>
An LBM is sent from a MEP to a MIP or to a MEP in the same ME. The MIP/MEP 10.2 Framework
immediately replies with LBR (Loopback Reply)
10.2.0 Domains
LBM can be thought of as "layer 2 ping". LBMs are sent as a loopback (LB) 10.2.1 Constructs
session of N (default is 3) consecutive LBMs in a pre-defined time interval. If 10.2.1.1 MEP, MIP, MEG, MEG
an LBR is not received within a given time interval (default is 5 seconds), the Level
MEP declares the MIP as being faulty. 10.2.2 MEF 17

10.2.2.1 Model
The LBM uses Unicast MAC DA of the destination MIP/MEP, but it can also use
the same multicast MAC used by CCMs. It is recommended to use the highest 10.2.2.2 Maintenance Entities
CoS ID for an LBM - the one that yields the lowest possible loss for that < br/>
Ethernet service (EVC or OVC). An LBM is usually 64 bytes long, but can be
10.3 Fault Management
extended to any value up to the MTU size using specific TLVs.
10.3.1 Definition
The LBR is identical to the LBM except that the MAC DA and MAC SA are 10.3.2 Procedures
swapped. The following figure illustrates LBR sent by the SP ME in order to
10.3.2.1 Continuity Check
verify that the NE implementing ENNI-N at the far CEN is operating. An LB Message
session starts from the MEP at the UNI-N on the left destined for the ENNI-N 10.3.2.2 Loopback Message
in Operator 2's network. Once it replies the SP knows that the NE and the
10.3.2.3 Link Trace Message
OVC to it are functional.
< br/>
10.4 Performance Management

10.4.1 Definition

10.4.2 Procedures

10.4.2.0 Frame Delay

10.3.2.2.F1 - Example use of SOAM LBM 10.4.2.1 Delay Measurement


Message
10.4.2.2 Loss Measurement
Message

10.4.3 Computation Methods

10.4.3.0 Frame Delay

10.4.3.1 Inter-Frame Delay


Variation

10.4.3.2 Frame Loss Ratio

10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


LAN, E-Tree

< br/>

10.5 CoS Implementation


Agreement - MEF 23

10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.3.2.3 Maintenance

10.1 Relevant Standards


LTM
10.1.1 IEEE 802.1ag Overview
Link Trace procedure identifies all MIPs and MEPs belonging to a ME. It can be 10.1.2 Y.1731 Overview
thought of as a "layer 2 trace route". The procedure is similar to a LB
< br/>
procedure. A MEP initiates the procedure by sending a series of LTM messages
using a multicast MAC DA and the appropriate MEG level for this ME. It is 10.2 Framework
recommended that LTM makes use of the highest CoS ID available, which will 10.2.0 Domains
yield the lowest possible loss for a particular ETH service (EVC or OVC). Each 10.2.1 Constructs
MIP that belongs to this ME replies by generating an LTR unicast message .
10.2.1.1 MEP, MIP, MEG, MEG
This enables the originator to identify the path of this ME but can also Level
identify the broken link in case of a failure.
10.2.2 MEF 17

The following figure illustrates the use of LTM: 10.2.2.1 Model

10.2.2.2 Maintenance Entities

< br/>

10.3 Fault Management

10.3.1 Definition

10.3.2 Procedures
10.3.2.3.F1 - SOAM LTM
10.3.2.1 Continuity Check
In this example, an LTM procedure is issued from MEP1. MIP1 and MIP2 reply, Message
but MIP3 does not reply. 10.3.2.2 Loopback Message

The failure is between MIP2 and MIP3, or at the NE implementing MIP3. 10.3.2.3 Link Trace Message

< br/>
There is no sense in sending messages to MIP4 and MEP2 as they will not pass
10.4 Performance Management
through.
10.4.1 Definition
The LTM frames should be sent with same CE-VLAN ID that maps to the
10.4.2 Procedures
monitored EVC, that way it is guaranteed that the LTM passes the same path
10.4.2.0 Frame Delay
as the monitored EVC's service frames.
10.4.2.1 Delay Measurement
Message

10.4.2.2 Loss Measurement


Message

10.4.3 Computation Methods

10.4.3.0 Frame Delay

10.4.3.1 Inter-Frame Delay


Variation

10.4.3.2 Frame Loss Ratio

10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


LAN, E-Tree

< br/>

10.5 CoS Implementation


Agreement - MEF 23

10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.4 Maintenance

10.1 Relevant Standards


SOAM: Performance Management
10.1.1 IEEE 802.1ag Overview
This section provides the definition of performance management for Carrier 10.1.2 Y.1731 Overview
Ethernet services as well as explanations for the procedures to implement
< br/>
performance management, computation methods and implementation
mechanisms. 10.2 Framework

10.2.0 Domains

10.2.1 Constructs

10.2.1.1 MEP, MIP, MEG, MEG


Level

10.2.2 MEF 17

10.2.2.1 Model

10.2.2.2 Maintenance Entities

< br/>

10.3 Fault Management

10.3.1 Definition

10.3.2 Procedures

10.3.2.1 Continuity Check


Message

10.3.2.2 Loopback Message

10.3.2.3 Link Trace Message

< br/>
10.4 Performance Management

10.4.1 Definition

10.4.2 Procedures

10.4.2.0 Frame Delay

10.4.2.1 Delay Measurement


Message

10.4.2.2 Loss Measurement


Message

10.4.3 Computation Methods

10.4.3.0 Frame Delay

10.4.3.1 Inter-Frame Delay


Variation

10.4.3.2 Frame Loss Ratio

10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


LAN, E-Tree

< br/>

10.5 CoS Implementation


Agreement - MEF 23

10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.4.1 Maintenance

10.1 Relevant Standards


Definition
10.1.1 IEEE 802.1ag Overview
SOAM Performance Management (PM) handles the methods and procedures to 10.1.2 Y.1731 Overview
measure the performance attributes of a given EVC or OVC. It is used to verify
< br/>
that the EVC/OVC's performance meets the SLS. Performance metrics are:
10.2 Framework
Frame Delay (FD)
10.2.0 Domains
Inter-frame Delay Variation (IFDV)
10.2.1 Constructs
Frame Loss Ratio (FLR)
Availability 10.2.1.1 MEP, MIP, MEG, MEG
Level
PM covers aspects of the measurement technique for each of the performance 10.2.2 MEF 17
objectives, implications for the EVC/OVC and its CoS handling. 10.2.2.1 Model

In the context of the MEF PM framework, a PM Solution is a collection of 10.2.2.2 Maintenance Entities
interdependent and related requirements of the components that implement < br/>
that solution. A PM Solution uses PM Functions which are capabilities that are
10.3 Fault Management
specified for performance monitoring purposes (e.g. Single-Ended Delay,
10.3.1 Definition
Single-Ended Synthetic Loss). A PM Function is associated with an ITU-T PM
Tool which is a specific tool that is described in ITU-T Y.1731 (e.g. Single- 10.3.2 Procedures
Ended ETH-SLM). A PM Session is an instantiation of a PM Solution between a 10.3.2.1 Continuity Check
given pair of MEPs using a given CoS over a given (possibly indefinite) period of Message

time. 10.3.2.2 Loopback Message

10.3.2.3 Link Trace Message


The NE is responsible for conducting performance measurements, while the
EMS/NMS components are responsible for configuring, collecting, and < br/>
processing these performance measurements to determine one or more 10.4 Performance Management
performance metrics for the MEG. An implementation of a PM solution consists 10.4.1 Definition
of a MEG, supported by NEs, in which the MEPs of that MEG are implemented,
10.4.2 Procedures
and the management functionality supported by the EMS and NMS system(s)
that typically manage them as shown in the figure below: 10.4.2.0 Frame Delay

10.4.2.1 Delay Measurement


Message

10.4.2.2 Loss Measurement


Message

10.4.3 Computation Methods

10.4.3.0 Frame Delay

10.4.3.1 Inter-Frame Delay


Variation

10.4.3.2 Frame Loss Ratio


10.4.1.F1 - Performance monitoring definition
10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


LAN, E-Tree

< br/>

10.5 CoS Implementation


Agreement - MEF 23

10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.4.2 Maintenance

10.1 Relevant Standards


Procedures
10.1.1 IEEE 802.1ag Overview
This section provides explanations of two performance management 10.1.2 Y.1731 Overview
procedures - Delay Measurement Message (DMM) and Loss Measurement
< br/>
Message (LMM)
10.2 Framework

10.2.0 Domains

10.2.1 Constructs

10.2.1.1 MEP, MIP, MEG, MEG


Level

10.2.2 MEF 17

10.2.2.1 Model

10.2.2.2 Maintenance Entities

< br/>

10.3 Fault Management

10.3.1 Definition

10.3.2 Procedures

10.3.2.1 Continuity Check


Message

10.3.2.2 Loopback Message

10.3.2.3 Link Trace Message

< br/>
10.4 Performance Management

10.4.1 Definition

10.4.2 Procedures

10.4.2.0 Frame Delay

10.4.2.1 Delay Measurement


Message

10.4.2.2 Loss Measurement


Message

10.4.3 Computation Methods

10.4.3.0 Frame Delay

10.4.3.1 Inter-Frame Delay


Variation

10.4.3.2 Frame Loss Ratio

10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


LAN, E-Tree

< br/>

10.5 CoS Implementation


Agreement - MEF 23

10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.4.2.0 Maintenance

10.1 Relevant Standards


Frame Delay
10.1.1 IEEE 802.1ag Overview
The One-way Frame Delay for an egress Service Frame at a given UNI in the 10.1.2 Y.1731 Overview
EVC is defined as the time elapsed from the reception at the ingress UNI of
< br/>
the first bit of the corresponding ingress Service Frame until the transmission
of the last bit of the Service Frame at the given UNI. This delay definition is 10.2 Framework
illustrated in the following figure: 10.2.0 Domains

10.2.1 Constructs

10.2.1.1 MEP, MIP, MEG, MEG


Level

10.2.2 MEF 17

10.2.2.1 Model
10.4.2.0.F1 - Frame Delay for Service Frame
10.2.2.2 Maintenance Entities
Note that this definition of Frame Delay for a Service Frame is the one-way
< br/>
delay that includes the delays encountered as a result of transmission across
the ingress and egress UNIs as well as that introduced by the CEN. 10.3 Fault Management

10.3.1 Definition
When the UNIs are not Time-synchronized, measuring this one-way frame
10.3.2 Procedures
delay is not possible using the ETH-DM procedure. Therefore, an
10.3.2.1 Continuity Check
approximation is to take 1/2 of the two-way delay between the 2 UNIs.
Message

MEF 10.2 defines three performance attributes for One-Way Frame Delay: 10.3.2.2 Loopback Message

10.3.2.3 Link Trace Message


One-way Frame Delay Performance corresponding to a percentile of
the distribution < br/>
One-way Mean Frame Delay 10.4 Performance Management
One-way Frame Delay Range 10.4.1 Definition

The Performance objectives are given for a time interval T (e.g. 15 minutes). 10.4.2 Procedures
The Frame Delay measurements are done much more frequently (e.g. 1 per 10.4.2.0 Frame Delay
second) This yields several (900 in this example) data points per time interval 10.4.2.1 Delay Measurement
T. These data points can be used to derive a distribution or some statistical Message
function. 10.4.2.2 Loss Measurement
Percentile: if the x th percentile (e.g 95 th ) of the distribution over T Message
Mean: the statistical mean over all samples for time interval T 10.4.3 Computation Methods
Range: The difference between two pre-defined percentiles (e.g. 90th 10.4.3.0 Frame Delay
percentile to 20th percentile).
10.4.3.1 Inter-Frame Delay
Variation
Example:
10.4.3.2 Frame Loss Ratio
Assume an E-Line service with single CoS ID. 10.4.3.3 Availability

The SLS specified for Frame Delay is that for any given 1-hour the 95th 10.4.4 Measurement in E-Line, E-
LAN, E-Tree
percentile will be 50 msec.
< br/>
The Service Provider measures the Frame Delay every 1 second between 2
10.5 CoS Implementation
MEPs in the EVC ME. Agreement - MEF 23

10.5.1 Ethernet Network Section


Every sample is divided by 2 to obtain the one-way Frame Delay. For each
time interval T = 1 hour, the SP computes the 95th percentile. If the 95th 10.5.2 CoS Label Model
percentile is no greater than 50 msec, the SLS is met. 10.5.3 Performance Parameters

The reader can refer to section 6.9.2 of MEF 10.2 for formal definitions of < br/>

these performance attributes. The computation method above is applicable 10.6 Performance Management
for E-Line. Implementation

10.6.1 Multi-CoS EVC


For E-LAN and E-tree an additional step is required. Please refer to
10.6.2 Relationship to Bandwidth
Measurement in E-Line, E-LAN and E-Tree. Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.4.2.1 Maintenance

10.1 Relevant Standards


Delay Measurement Message (DMM)
10.1.1 IEEE 802.1ag Overview
ETH-DM procedure is an ITU-T Y.1731 procedure that can be used to 10.1.2 Y.1731 Overview
periodically measure Frame Delay and Inter-Frame Delay Variation in an EVC
< br/>
or OVC. Measurements are performed between 2 MEPs belonging to the same
ME (EVC ME or Operator ME). 10.2 Framework

10.2.0 Domains
The procedure involves the sender MEP sending a DMM (Delay Measurement
10.2.1 Constructs
Message) once per time interval (e.g. 1 second, 10 seconds, 1 minute). The
remote MEP responds with DMR (Delay Measurement Reply). 10.2.1.1 MEP, MIP, MEG, MEG
Level
Assuming that the 2 MEPs are not time-synchronized, then only two-way 10.2.2 MEF 17
measurements can be taken. In other words, each MEP performs its own 10.2.2.1 Model
measurements based on differences in the time between sending the DMM and
10.2.2.2 Maintenance Entities
receiving the DMR.
< br/>
Note that MIPs are transparent to this procedure.
10.3 Fault Management
These messages MUST traverse the same path as the service frames belonging 10.3.1 Definition
to the monitored EVC/OVC. The CoS ID of the DMM is set to match the 10.3.2 Procedures
monitored CoS ID.
10.3.2.1 Continuity Check
Message
When several CoS IDs are to be measured, a separate procedure is run for
10.3.2.2 Loopback Message
each CoS ID.
10.3.2.3 Link Trace Message
When using DMM/DMR PDUs, DMM frames are sent from a Controller MEP to a
< br/>
Responder MEP which, in turn, responds with DMR frames. Controller to
Responder measurements and Responder to Controller measurements are also 10.4 Performance Management
known as forward and backward measurements, respectively. With optional 10.4.1 Definition
time-of-day (ToD) clock synchronization one-way FD can be measured. Two- 10.4.2 Procedures
way FD and IFDV measurements and one-way IFDV measurements can always
10.4.2.0 Frame Delay
be taken and do not require ToD clock synchronization. For FD, if ToD
10.4.2.1 Delay Measurement
synchronization is not accurate enough for PM functions, the one-way metrics Message
of MEF 10.2 [12] and MEF 10.2.1 [13] can be estimated by dividing the two-
10.4.2.2 Loss Measurement
way measurement by 2, although this introduces considerable statistical bias Message
for delay metrics other than MFD (Mean Frame Delay).
10.4.3 Computation Methods

The process is illustrated below: 10.4.3.0 Frame Delay

10.4.3.1 Inter-Frame Delay


Variation

10.4.3.2 Frame Loss Ratio

10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


10.4.2.1.F1 - DMM LAN, E-Tree

Each DMM message sent contains the following information in the DMM PDU: < br/>

10.5 CoS Implementation


TxTimeStampf: Timestamp at the time of sending the DMM PDU
Agreement - MEF 23

Upon receiving DMM, the far end has the following variable: 10.5.1 Ethernet Network Section

10.5.2 CoS Label Model


RxTimeStampf: Timestamp at the time of receiving the DMM PDU
10.5.3 Performance Parameters
One-way frame delay can be computed as (RxTimeStampf TxTimeStampf)
< br/>

When two-way measurements are conducted, the remote MEP copies the 10.6 Performance Management
TxTimeStampf from the DMM to the DMR. The process should be completed as Implementation

fast as possible and should not involve the CPU of the NE, where possible. 10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Once the DMR is received by the sending MEP, it notes RxTimeb Timestamp at Profile
the time of receiving the DMR PDU.
10.6.3 Interconnect via ENNI

The two-way delay can be computed by (RxTimeb TxTimeStampf)


Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.4.2.2 Maintenance

10.1 Relevant Standards


Loss Measurement Message (LMM)
10.1.1 IEEE 802.1ag Overview
ETH-LM procedure is an ITU-T Y.1731 procedure that can be used to 10.1.2 Y.1731 Overview
periodically measure Frame Loss Ratio of an EVC or OVC. Measurements are
< br/>
made between 2 MEPs belonging to the same ME (EVC ME or Operator ME)
10.2 Framework
The procedure involves a sender MEP sending an LMM (Loss Measurement
10.2.0 Domains
Message) once per time interval (e.g. 1 second, 10 seconds, 1 minute) The
10.2.1 Constructs
remote MEP responds with an LMR (Loss Measurement Reply) The messages are
used to collect the counts of the number of service frames transmitted and 10.2.1.1 MEP, MIP, MEG, MEG
Level
received by the two MEPs in a point-to-point MEG. When using LMM/LMR
PDUs, LMM frames are sent from a Controller MEP to a Responder MEP, which 10.2.2 MEF 17

in turn responds with LMR frames. LMM PDUs can be sent to the unicast 10.2.2.1 Model
address of the Responder MEP at the MEG Level of the ME. 10.2.2.2 Maintenance Entities

For each ME for which an LM procedure is configured, a MEP maintains two < br/>
local counters for each peer MEP (MEP in its MEG) and for each CoS ID. 10.3 Fault Management

10.3.1 Definition
TxFCl: Counter for in-profile data frames transmitted towards the
peer MEP. 10.3.2 Procedures
RxFCl: Counter for in-profile data frames received from the peer 10.3.2.1 Continuity Check
MEP. Message

10.3.2.2 Loopback Message


The LM process is illustrated below:
10.3.2.3 Link Trace Message

< br/>
10.4 Performance Management

10.4.1 Definition

10.4.2 Procedures
10.4.2.2.F1 - SOAM Loss Measurement
10.4.2.0 Frame Delay
Note that MIPs are transparent to this procedure.
10.4.2.1 Delay Measurement
Message
These messages MUST traverse the same path as the service frames belonging
to the monitored EVC/OVC. The CoS ID of the LMM is set to match the 10.4.2.2 Loss Measurement
Message
monitored CoS ID.
10.4.3 Computation Methods
When several CoS IDs are to be measured, a separate procedure is run for 10.4.3.0 Frame Delay
each CoS ID.
10.4.3.1 Inter-Frame Delay
Variation
It should be possible to administratively configure the following information in
10.4.3.2 Frame Loss Ratio
the LMM PDU:
10.4.3.3 Availability
TxFCf Copied from the local TxFCl
10.4.4 Measurement in E-Line, E-
LAN, E-Tree
The Refector MEP generates LMR in return for any valid LMM received. The
LMR PDU contains: < br/>

10.5 CoS Implementation


TxFCf: Value of TxFCf copied from the LMM frame Agreement - MEF 23
RxFCf: Value of local counter RxFCl at the time of LMM frame 10.5.1 Ethernet Network Section
reception
10.5.2 CoS Label Model
TxFCb: Value of local counter TxFCl at the time of LMR frame
transmission 10.5.3 Performance Parameters

< br/>
Upon reception of the LMR, the Probe MEP performs the FLR calculation for
10.6 Performance Management
both ends for the time interval t 1 -t 0 (Where t 1 is the current time and t 0
Implementation
is the last sample time).
10.6.1 Multi-CoS EVC
Number of Frame Lost (local) = |TxFCf(t 1 ) TxFCf(t 0 )| - 10.6.2 Relationship to Bandwidth
|RxFCf(t 1 ) RxFCf(t 0 )| Profile

10.6.3 Interconnect via ENNI


Number of Frame Lost (Far end) = |TxFCb(t 1 ) TxFCb(t 0 )| -
|RxFCl(t 1 ) RxFCl(t 0 )|
Download PDF
Calculating FLR is explained in the section on Frame Loss Ratio.

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives


10 Service OAM

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.4.3 Maintenance

10.1 Relevant Standards


Computation Methods
10.1.1 IEEE 802.1ag Overview
This section provides an explanation on how SOAM Performance Management 10.1.2 Y.1731 Overview
procedures are are used to compute the performance attributes defined in
< br/>
MEF 10.2.
10.2 Framework
These performance attributes refer to EVC performance attributes for a
10.2.0 Domains
specific CoS ID. Similar attributes will be defined in the future for ENNI and
10.2.1 Constructs
will affect OVCs. It is assumed that the correct procedure is activated every
time interval and that the raw data is obtained. Subsequent sections explain 10.2.1.1 MEP, MIP, MEG, MEG
Level
the applications of these computation methods for different Ethernet service
types. 10.2.2 MEF 17

10.2.2.1 Model

10.2.2.2 Maintenance Entities

< br/>

10.3 Fault Management

10.3.1 Definition

10.3.2 Procedures

10.3.2.1 Continuity Check


Message

10.3.2.2 Loopback Message

10.3.2.3 Link Trace Message

< br/>
10.4 Performance Management

10.4.1 Definition

10.4.2 Procedures

10.4.2.0 Frame Delay

10.4.2.1 Delay Measurement


Message

10.4.2.2 Loss Measurement


Message

10.4.3 Computation Methods

10.4.3.0 Frame Delay

10.4.3.1 Inter-Frame Delay


Variation

10.4.3.2 Frame Loss Ratio

10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


LAN, E-Tree

< br/>

10.5 CoS Implementation


Agreement - MEF 23

10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.4.3.0 Maintenance

10.1 Relevant Standards


Computing Frame Delay
10.1.1 IEEE 802.1ag Overview
One-way Frame Delay 10.1.2 Y.1731 Overview

The One-way Frame Delay for an egress Service Frame at a given UNI in the < br/>
EVC is defined as the time elapsed from the reception at the ingress UNI of 10.2 Framework
the first bit of the corresponding ingress Service Frame until the transmission
10.2.0 Domains
of the last bit of the Service Frame at the given UNI. This delay definition is
10.2.1 Constructs
illustrated in the following figure:
10.2.1.1 MEP, MIP, MEG, MEG
Level

10.2.2 MEF 17

10.2.2.1 Model

10.2.2.2 Maintenance Entities

< br/>
Frame Delay for Service Frame
10.3 Fault Management
Note that this definition of Frame Delay for a Service Frame is the one-way 10.3.1 Definition
delay that includes the delays encountered as a result of transmission across
10.3.2 Procedures
the ingress and egress UNIs as well as that introduced by the CEN.
10.3.2.1 Continuity Check
When the UNIs are not Time-synchronized, measuring this one-way frame Message

delay is not possible using the ETH-DM procedure. Therefore, an 10.3.2.2 Loopback Message
approximation is to take 1/2 of the two-way delay between the 2 UNIs. 10.3.2.3 Link Trace Message

MEF 10.2 defines three performance attributes for One-Way Frame Delay: < br/>
10.4 Performance Management
One-way Frame Delay Performance corresponding to a percentile of
10.4.1 Definition
the distribution
One-way Mean Frame Delay 10.4.2 Procedures
One-way Frame Delay Range 10.4.2.0 Frame Delay

10.4.2.1 Delay Measurement


The Performance objectives are given for a time interval T (e.g. 15 minutes). Message
The Frame Delay measurements are done much more frequently (e.g. 1 per
10.4.2.2 Loss Measurement
second) This yields several (900 in this example) data points per time interval Message
T. These data points can be used to derive a distribution or some statistical
10.4.3 Computation Methods
function.
10.4.3.0 Frame Delay
Percentile: if the x th percentile (e.g 95 th ) of the distribution over T
Mean: the statistical mean over all samples for time interval T 10.4.3.1 Inter-Frame Delay
Variation
Range: The difference between two pre-defined percentiles (e.g. 90th
percentile to 20th percentile). 10.4.3.2 Frame Loss Ratio

10.4.3.3 Availability
Example:
10.4.4 Measurement in E-Line, E-
LAN, E-Tree
Assume an E-Line service with single CoS ID.
< br/>
The SLS specified for Frame Delay is that for any given 1-hour the 95th
10.5 CoS Implementation
percentile will be 50 msec. Agreement - MEF 23

The Service Provider measures the Frame Delay every 1 second between 2 10.5.1 Ethernet Network Section

MEPs in the EVC ME. 10.5.2 CoS Label Model

10.5.3 Performance Parameters


Every sample is divided by 2 to obtain the one-way Frame Delay. For each
time interval T = 1 hour, the SP computes the 95th percentile. If the 95th < br/>

percentile is no greater than 50 msec, the SLS is met. 10.6 Performance Management
Implementation
The reader can refer to section 6.9.2 of MEF 10.2 for formal definitions of 10.6.1 Multi-CoS EVC
these performance attributes. The computation method above is applicable
10.6.2 Relationship to Bandwidth
for E-Line. Profile

For E-LAN and E-tree an additional step is required. Please refer to 10.6.3 Interconnect via ENNI

Measurement in E-Line, E-LAN and E-Tree.


Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.4.3.1 Maintenance

10.1 Relevant Standards


Inter-Frame Delay Variation
10.1.1 IEEE 802.1ag Overview
Inter-Frame Delay Variation (IFDV) is the difference between the one-way 10.1.2 Y.1731 Overview
delay of a pair of selected Service Frames. This definition is borrowed from
< br/>
RFC 3393 where IP packet delay variation is defined. For a particular Class of
Service Identifier and an ordered pair of UNIs in the EVC, IFDV Performance is 10.2 Framework
applicable to Qualified Service Frames. 10.2.0 Domains

10.2.1 Constructs
Note: MEF 10 and 10.1 refer to Inter-Frame Delay Variation as Frame Delay
Variation. 10.2.1.1 MEP, MIP, MEG, MEG
Level
Note: The term Jitter is not an appropriate term to be substituted for Frame 10.2.2 MEF 17
Delay Variation. 10.2.2.1 Model

The Inter-Frame Delay Variation Performance is defined as the P-percentile of 10.2.2.2 Maintenance Entities
the absolute values of the difference between the Frame Delays of all < br/>
Qualified Service Frame pairs that satisfy the following conditions:
10.3 Fault Management
The difference in the arrival times of the first bit of each Service Frame at 10.3.1 Definition
the ingress UNI was exactly some (small) time value t . 10.3.2 Procedures
The concept is depicted below:
10.3.2.1 Continuity Check
Message

10.3.2.2 Loopback Message

10.3.2.3 Link Trace Message

< br/>
10.4.3.1.F1 - Inter-Frame Delay Variation Performance 10.4 Performance Management

10.4.1 Definition
Assuming that for a given EVC and for a specific CoS ID, ETH-DM procedure is
executed every 1 second (having D t = 1 second), the absolute value 10.4.2 Procedures

difference between 2 consecutive readings is the measured value. At the end 10.4.2.0 Frame Delay
of the time interval T, a percentile is calculated and is compared with the 10.4.2.1 Delay Measurement
objective. For the SLS, an Inter-Frame Delay Variation metric MUST specify a Message
set of parameters and an objective. The parameters and objective for an 10.4.2.2 Loss Measurement
Inter-Frame Delay Variation Performance metric are given in the following Message

table: 10.4.3 Computation Methods

10.4.3.0 Frame Delay


Parameter Description 10.4.3.1 Inter-Frame Delay
Variation
T The interval
10.4.3.2 Frame Loss Ratio

S Subset of the ordered UNI pairs of the EVC 10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


P Inter-Frame Delay Variation Performance percentile LAN, E-Tree

< br/>
The separation between frame pairs for which Inter-Frame
Dt 10.5 CoS Implementation
Delay Variation Performance is defined
Agreement - MEF 23

10.5.1 Ethernet Network Section


Inter-Frame Delay Variation Performance Objective
10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


The reader can refer to section 6.9.4 of MEF 10.2 for formal definitions of Implementation
these performance attributes. The computation method above is applicable 10.6.1 Multi-CoS EVC
for E-line. 10.6.2 Relationship to Bandwidth
Profile
An additional step is required in the case of an E-LAN or E-Tree. Please refer
10.6.3 Interconnect via ENNI
to Measurement in E-line, E-LAN and E-Tree.

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.4.3.2 Maintenance

10.1 Relevant Standards


Frame Loss Ratio
10.1.1 IEEE 802.1ag Overview
One-way Frame Loss Ratio (FLR) for a given EVC and for a specific CoS ID 10.1.2 Y.1731 Overview
measures the fraction of compliant frames dropped within the Carrier
< br/>
Ethernet Network (CEN) Only the following frames are counted: Frames that
entered the CEN within time interval T, declared green by the appropriate 10.2 Framework
ingress BWP and which have been forwarded to the egress UNI (not dropped 10.2.0 Domains
due to conditional delivery or L2CP handling rules). 10.2.1 Constructs
FLR is given from UNI A to UNI B, and can be different for each direction. A
10.2.1.1 MEP, MIP, MEG, MEG
more formal definition of one-way FLR is provided below: Level

10.2.2 MEF 17

Let denote the number of ingress Service Frames at UNI i whose first 10.2.2.1 Model
bit arrived at UNI i during the time interval T, whose Ingress Bandwidth 10.2.2.2 Maintenance Entities
Profile compliance was Green, and that should have been delivered to UNI j
< br/>
according to the Service Frame Delivery service attributes. Note that each
10.3 Fault Management
Service Frame can be a Unicast, Multicast, Broadcast or L2CP
10.3.1 Definition

10.3.2 Procedures
Let denote the number of such Service Frames delivered to UNI j.
10.3.2.1 Continuity Check
Message

10.3.2.2 Loopback Message

10.3.2.3 Link Trace Message

< br/>
Define
10.4 Performance Management
The following figure provides an example: 10.4.1 Definition

10.4.2 Procedures

10.4.2.0 Frame Delay

10.4.2.1 Delay Measurement


Message

10.4.2.2 Loss Measurement


Message

10.4.3 Computation Methods

10.4.3.0 Frame Delay


10.4.3.2.F1 - Frame Loss Ratio
10.4.3.1 Inter-Frame Delay
The reader can refer to section 6.9.6 of MEF 10.2.1 for formal definitions of Variation
these performance attributes. 10.4.3.2 Frame Loss Ratio

The computation method above is applicable for E-Line. 10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


For E-LAN and E-Tree an additional step is required. Please refer to the LAN, E-Tree
section Measurement in E-Line, E-LAN and E-Tree.
< br/>

10.5 CoS Implementation


Agreement - MEF 23

10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.4.3.3 Maintenance

10.1 Relevant Standards


Availability
10.1.1 IEEE 802.1ag Overview
Availability Performance is the percentage of time within a specified time 10.1.2 Y.1731 Overview
interval T during which the Frame Loss Ratio is small. As an example, a
< br/>
Service Provider can define the Availability Performance to be measured over
a month (T = 30 days) and the value for the Availability Performance 10.2 Framework
objective to be 99.9%. In a month with 30 days and no scheduled downtime 10.2.0 Domains
this parameter will allow the service to be unavailable for approximately 43 10.2.1 Constructs
minutes out of the whole month.
10.2.1.1 MEP, MIP, MEG, MEG
Level
Availability Performance is based on Service Frame loss during a sequence of
consecutive small time intervals. 10.2.2 MEF 17

If the previous sequence was defined as available, and if the frame loss is 10.2.2.1 Model
high for each small time interval in the current sequence, then the current 10.2.2.2 Maintenance Entities
sequence is defined as unavailable. Otherwise the current sequence is defined
< br/>
as available.
On the other hand, if the previous sequence was defined as unavailable, and 10.3 Fault Management

if frame loss is low for each small time interval in the current sequence, then 10.3.1 Definition
the current sequence is defined as available. Otherwise, the current sequence 10.3.2 Procedures
is defined as unavailable.
10.3.2.1 Continuity Check
Message

10.3.2.2 Loopback Message


The figure below presents an example of the determination of the availability
for the small time intervals with a sliding window of 10 small time intervals. 10.3.2.3 Link Trace Message

< br/>
10.4 Performance Management

10.4.1 Definition

10.4.2 Procedures
10.4.3.3.F1 -Availability for Small Time Intervals
[Source: MEF 10.2.1, Figure B] 10.4.2.0 Frame Delay

The Availability for a particular Class of Service instance from UNI i to UNI j 10.4.2.1 Delay Measurement
Message
for a time interval T excludes the small time intervals that occur during a
Maintenance Interval (MI). An MI is a time interval agreed to by the Service 10.4.2.2 Loss Measurement
Message
Provider and Subscriber during which the service may not perform well or at
10.4.3 Computation Methods
all. Examples of a Maintenance Interval include:
10.4.3.0 Frame Delay
A time interval during which the Service Provider may disable the
10.4.3.1 Inter-Frame Delay
service for network maintenance such as equipment replacement Variation
A time interval during which the Service Provider and Subscriber may 10.4.3.2 Frame Loss Ratio
perform joint fault isolation testing, and
10.4.3.3 Availability
A time interval during which the Service Provider may change service
10.4.4 Measurement in E-Line, E-
features and making the changes may disrupt the service.
LAN, E-Tree

The reader can refer to section 6.9.7 of MEF 10.2.1 for formal definitions of < br/>
these performance attributes. The computation method above is applicable 10.5 CoS Implementation
for E-Line. For E-LAN and E-tree an additional step is required, please refer to Agreement - MEF 23
Measurement in E-Line, E-LAN and E-Tree. 10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives


10 Service OAM

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.4.4 Maintenance

10.1 Relevant Standards


Measurements in E-Line, E-LAN, E-Tree
10.1.1 IEEE 802.1ag Overview
This topic discusses the implementation of the various Performance 10.1.2 Y.1731 Overview
Management attribute computation methods for a given Ethernet Service type.
< br/>
For E-Line services, the one-way performance attributes (Frame Delay, Frame 10.2 Framework
Loss Ratio, etc.) are measured and computed separately in each direction
10.2.0 Domains
(UNI A to UNI B and UNI B to UNI A). A SP may set performance objectives
10.2.1 Constructs
and measure performance for both directions or only one direction.
10.2.1.1 MEP, MIP, MEG, MEG
For E-LAN and E-Tree the computation is more complex. Such a service has N Level
UNIs associated with it. Since measurement is made between pairs of UNIs, 10.2.2 MEF 17
scalability and complexity issues may require monitoring only a sub-set of the 10.2.2.1 Model
UNI pairs. Note that for E-LAN with 6 UNIs, there are 6X5 = 30 UNI pairs. The
10.2.2.2 Maintenance Entities
Service Provider specifies a sub-set (denoted by S) of the UNI pairs for which
to perform performance monitoring. This could be the entire list, an empty < br/>
list or any sub-set of that list. 10.3 Fault Management

10.3.1 Definition
For a Rooted-Multipoint EVC, S must be such that all ordered pairs in S
contain at least one UNI that is designated as a Root. This is required since 10.3.2 Procedures
two leaf UNIs cannot communicate with each other. For each UNI pair within 10.3.2.1 Continuity Check
the sub-set S, the procedures are carried out and summarized every time Message

interval T (T can be different per attribute) 10.3.2.2 Loopback Message

10.3.2.3 Link Trace Message


The value for S is the Max value over all ordered pairs for this time interval T.
For example FLR for an E-LAN or E-Tree is computed after computing the FLR < br/>
for each ordered pair of UNIs within S, as: 10.4 Performance Management

10.4.1 Definition

10.4.2 Procedures

10.4.2.0 Frame Delay

10.4.2.1 Delay Measurement


Message
The only attribute that should be computed differently is One-Way Mean 10.4.2.2 Loss Measurement
Frame Delay. For Mean Frame Delay, the value is calculated as the Arithmetic Message
Mean over all Mean Frame Delays of the ordered UNI pairs. 10.4.3 Computation Methods

10.4.3.0 Frame Delay

10.4.3.1 Inter-Frame Delay


Variation

10.4.3.2 Frame Loss Ratio

10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


LAN, E-Tree

< br/>

10.5 CoS Implementation


Agreement - MEF 23

10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.5 Maintenance

10.1 Relevant Standards


Class of Service Implementation Agreement - MEF 23
10.1.1 IEEE 802.1ag Overview
MEF 23 is an Implementation Agreement (IA) that specifies a small common 10.1.2 Y.1731 Overview
set of Classes of Service (CoS) that can be used by Operators, Service
< br/>
Providers and their Subscribers to indicate the performance expectations to
be associated with a given set of frames. This common set of CoS is envisioned 10.2 Framework
as a subset of the CoS an Operator may provide. The MEF CoS IA facilitates: 10.2.0 Domains

10.2.1 Constructs
Ethernet service interoperability and consistency between Operators
a common CoS set for Subscribers to utilize and 10.2.1.1 MEP, MIP, MEG, MEG
Level
support of key applications
10.2.2 MEF 17
The Scope and applicability of the Class of Service Implementation Agreement: 10.2.2.1 Model

Both UNI and ENNI 10.2.2.2 Maintenance Entities


Both Multipoint and Point-to-Point and < br/>
Both single and multiple CENs
10.3 Fault Management
This is depicted in the following figure: 10.3.1 Definition

10.3.2 Procedures

10.3.2.1 Continuity Check


Message

10.3.2.2 Loopback Message

10.3.2.3 Link Trace Message

10.5.F1 Class of Service Implementation Agreement < br/>


10.4 Performance Management
A MEF CoS Model is defined that can be applied to the CoS instances of an
EVC. Guidance and requirements on Bandwidth Profile constraints and frame 10.4.1 Definition
disposition (i.e. Color) including Color Identification at the EI (External 10.4.2 Procedures
Interface) are provided. Place holders for Frame Delay, Frame Delay Variation 10.4.2.0 Frame Delay
and Frame Loss Ratio Performance Objectives are also specified. Values for
10.4.2.1 Delay Measurement
these Objectives are to be specified in Phase 2. This IA builds upon previous Message
work in IEEE, ITU and IETF for consistency, fast development and facilitation
10.4.2.2 Loss Measurement
of end-to-end CoS. Message

10.4.3 Computation Methods


The following terms are defined:
10.4.3.0 Frame Delay
CoS Label - a term independent of all Service Provider, Operator and
10.4.3.1 Inter-Frame Delay
other standards' CoS names. It is a label used in MEF CoS IA to refer Variation
to a MEF specified class or CoS. 10.4.3.2 Frame Loss Ratio
CoS Indication - At the UNI and the ENNI the CoS for a given frame is
10.4.3.3 Availability
indicated by a CoS Identifier
10.4.4 Measurement in E-Line, E-
Color Indication At the UNI and ENNI the Color for a given frame is
LAN, E-Tree
indicated by the Color Identifier. Color (Green,Yellow or Red) is a
part of the Bandwidth Profile specification. < br/>

10.5 CoS Implementation


The 3 CoS Model defines the CoS ID indication by PCP or DSCP bits and the Agreement - MEF 23
color indication: 10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC


10.5.F2 - 3 CoS Model 10.6.2 Relationship to Bandwidth
Profile
Common CoS lexicon between the Service Providers on either side of the
standardized Ethernet interconnect facilitates CoS alignment: 10.6.3 Interconnect via ENNI

CENs are still free to implement a subset or superset of the CoS Download PDF

MEF 23 specifies interoperability between CENs using up to 3 MEF CoS, and


any additional number of "proprietary CoS".
Download a pdf for
offline viewing.
A CEN operator may have more CoSs than a second CEN operator. When
interconnecting, mapping between CoS IDs must be agreed upon. The concept
is depicted in the following figure:
Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect
10.5.F3 Mapping CoS IDs
ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service OAM In this Section

10 Carrier Ethernet Service


Study Guide Section 10.5.1 Operations, Administration and
Maintenance
Ethernet Network Section
10.1 Relevant Standards
When CoS IA is to be applied to an OVC that, along with other OVCs, comprise
10.1.1 IEEE 802.1ag Overview
an EVC, the CENs associated with the OVCs are referred to as Ethernet
10.1.2 Y.1731 Overview
Network Sections (ENSs). Each ENS is usually aligned with a single CEN. In CoS
IA Phase 2 an ENS generally aligns with a MEN. Each OVC of a multiple CEN < br/>
EVC has separate per-OVC CPOs that need to have consistency with the UNI- 10.2 Framework
to-UNI CPOs for the EVC. Each CoS Frame Set associated with an OVC is
10.2.0 Domains
assigned a PT for its set of CPOs. The ENS Model is referring to the
10.2.1 Constructs
relationships the various OVC CPOs have with the EVC CPOs and to other OVC
CPOs that comprise the EVC. It may be necessary to concatenate the OVC 10.2.1.1 MEP, MIP, MEG, MEG
Level
CPOs to verify consistency with EVC CPOs (for example, when an EVC
comprised of 2 OVCs). This is illustrated in the following figure: 10.2.2 MEF 17

10.2.2.1 Model

10.2.2.2 Maintenance Entities

< br/>

10.3 Fault Management

10.3.1 Definition

10.3.2 Procedures

10.3.2.1 Continuity Check


Figure 10.5.1.F1 - ENS Model Illustration Message
[Source MEF 23.1 Figure 4]
10.3.2.2 Loopback Message

10.3.2.3 Link Trace Message
In this example, the EVC traverses an ENNI that connects two CENs. The EVC < br/>
will still have a UNI-to-UNI CPO set based on PT3 as represented by the
10.4 Performance Management
bracket on top. The OVCs that comprise the EVC may have CPOs as
10.4.1 Definition
represented by the bottom brackets.
The OVC in CEN1 (UNI-to-ENNI) uses PT1 and the OVC in CEN2 uses PT2 set of 10.4.2 Procedures
CPOs. Each of these OVCs is aligned with an ENS within an ENS Model that will 10.4.2.0 Frame Delay
relate OVC CPOs to the EVC CPOs using concatenation of OVC CPOs. 10.4.2.1 Delay Measurement
Even after measuring the performance on each OVC, the concatenation of the Message
results to the EVC's level is not trivial. For example when one measures 10.4.2.2 Loss Measurement
percentiles, there is no additivity. Message
Note that the OVC CPO values in PTs 1-4 in MEF 23.1 are not likely to 10.4.3 Computation Methods
concatenate precisely to the EVC CPO values in the PT 1-4 tables in in MEF 10.4.3.0 Frame Delay
23.1 The methods, techniques and negotiations needed to arrive at
10.4.3.1 Inter-Frame Delay
acceptable objectives are beyond the scope of MEF 23.1 and this study guide. Variation

10.4.3.2 Frame Loss Ratio

10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


LAN, E-Tree

< br/>

10.5 CoS Implementation


Agreement - MEF 23

10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.5.2 Maintenance

10.1 Relevant Standards


Class of Service Label Model
10.1.1 IEEE 802.1ag Overview
The CoS Label Model Tables provide normative information for each MEF CoS 10.1.2 Y.1731 Overview
Label in a Three CoS Label Model.
< br/>
This does not preclude implementation of a subset or superset of the CoS in 10.2 Framework
the Carrier Ethernet Networks.
10.2.0 Domains
The Tables provide: 10.2.1 Constructs

10.2.1.1 MEP, MIP, MEG, MEG


CoS Label Level
Class of Service Performance Objectives (CPO)
10.2.2 MEF 17
Bandwidth Profile constraints
10.2.2.1 Model
CoS Identifier
Color Identifier 10.2.2.2 Maintenance Entities

< br/>
Only the PCP and DSCP CoS ID components are specified with values. All CPO
requirements refer to UNI-to-UNI, UNI-to-ENNI and ENNI-to-ENNI performance 10.3 Fault Management
in MEF 23.1. 10.3.1 Definition

FD, MFD, IFDV, FDR and FLR CPOs are specified normatively as one of the 10.3.2 Procedures
following: 10.3.2.1 Continuity Check
Message
1. Numeric values expressed in milliseconds (ms) for FD, MFD, IFDV and
10.3.2.2 Loopback Message
FDR. FLR is expressed as a decimal number representing a percentage.
10.3.2.3 Link Trace Message
2. Unspecified performance for a particular CPO for a given CoS Label via
N/S < br/>
In MEF 23 (CoS IA Phase 1), CPOs were expressed in relative terms. In 10.4 Performance Management

contrast, inn MEF 23.1 (CoS IA Phase 2) CPOs are expressed using values. 10.4.1 Definition

10.4.2 Procedures
In Phase 2, the Phase 1 CoS Model table is divided into several ???
10.4.2.0 Frame Delay
Since MEF 23.1 supports a Three CoS Label Model and its subsets, there is a 10.4.2.1 Delay Measurement
need to interwork or map between the subsets. Message

10.4.2.2 Loss Measurement


Example
Message
The Operator of CEN 1 adopts all CoS Labels in the Three CoS Label Model. 10.4.3 Computation Methods
The Operator of CEN 2 adopts a subset with 2 CoS Labels including CoS Labels 10.4.3.0 Frame Delay
H and L. If CEN 1 and CEN 2 are connected via an ENNI there must be
10.4.3.1 Inter-Frame Delay
mapping between the two models. Specific mapping may be defined in future Variation
phases of MEF CoS IA.
10.4.3.2 Frame Loss Ratio

10.4.3.3 Availability
This model, as shown in Table 2, Table 3 and Table 4, specifies three MEF CoS
Labels denoted by CoS Labels H, M and L. There is no restriction on how 10.4.4 Measurement in E-Line, E-
LAN, E-Tree
Operators may use the PCP (i.e., 4, 6,7) and DSCP values not specified.
< br/>
Table 2 introduces the CoS Labels and specifies the Bandwidth Profile
10.5 CoS Implementation
constraints and CoS ID types in Phase 2. Agreement - MEF 23

Table 3 provides the PCP and DSCP values used for per frame Color ID when 10.5.1 Ethernet Network Section
CoS ID type is EVC or OVC EP. 10.5.2 CoS Label Model

Table 4 identifies the PCP and DSCP values to be used to identify the CoS 10.5.3 Performance Parameters
Label and per frame Color ID when CoS ID type is PCP or DSCP. < br/>

Note that the EVC or OVC part of the CoS Identifier is not explicitly shown for 10.6 Performance Management
Implementation
these cases. Furthermore, Table 4 does not include a separate column for
identifying the CoS Label when the CoS Identifier of the CoS Frame Set is only 10.6.1 Multi-CoS EVC
EVC or OVC EP, e.g., PCP values are not relevant to CoS ID or may not be 10.6.2 Relationship to Bandwidth
present as in the case of an EVC with only untagged frames. Profile

10.6.3 Interconnect via ENNI


Note that the DSCP and associated Per Hop Behavior (PHB) are provided.
However, DSCP is what is actually used in the Service Frame. The specific
Download PDF
values for PCP in Table 4 were derived from IEEE 802.1ad using Tables 6-4 and
G-5 Priority Code Point Decoding. The table row used is 5P3D scheme (5
traffic classes of which 3 also have drop eligibility PCP values).
Download a pdf for
In IEEE 802.1ad there is a traffic class called Best Effort which is associated offline viewing.
with PCP=1 when not drop eligible and PCP=0 when drop eligible.
In MEF 23.1 CoS Label L is aligned with this traffic class in terms of Bandwidth
Profile note that CoS Label L allows CIR or EIR = 0. The special case of CIR = 0
effectively results in no CPOs for the Performance Attributes (i.e. Not Reference Documents
specified (N/S)) while the case of CIR>0 requires conformance with the
CPOs.(N/S)) while the case of CIR > 0 will require conformance with CPOs. MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

10.5.2.T1 Class of Service Label Model Table 2 Name:


[Source: MEF 23.1, Table 2]

while the case of CIR > 0 will require conformance with CPOs.
Email:

Comments

Send Feedback

10.5.2.T2 Class of Service Label Model Table 3


[Source: MEF 23.1, Table 3]

In Table 3 the PCP and DSCP values for each CoS Label include all of the
values specified in Table 4 for that CoS Label. This is because the values in
Table 3 only indicate Color (not CoS Label) This is possible only when the CoS
ID is not indicated with the PCP or DSCP, but rather with the alternative EVC
or OVC EP mechanisms. For example, consider a case of a service multiplexed
UNI with two EVCs. CoS ID of EVC1 indicates CoS Label is H, while PCP and
DSCP values are not used for CoS ID, but only for Color ID as needed. CoS ID
of EVC2 indicates CoS Label is L and again the PCP and DSCP need only
indicate Color as needed. CIR > 0 will require conformance with CPOs.

10.5.2.T3 Class of Service Label Model Table 4


[Source: MEF 23.1, Table 4]

Note that EVC and OVC EP are valid CoS IDs that are not included in Table 4,
but can conform to the CPOs and Parameters for CoS Labels just as the CoS
IDs above. See Table 2.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service OAM In this Section

10 Carrier Ethernet Service


Study Guide Section 10.5.3 Operations, Administration and
Maintenance
Performance Parameters
10.1 Relevant Standards
Table 5 of MEF 23.1 specifies Performance Parameters required to derive and
10.1.1 IEEE 802.1ag Overview
specify CPOs. The CPOs in Table 6, Table 7, Table 8 and Table 9 are based on
10.1.2 Y.1731 Overview
the parameter values in Table 5.
< br/>
For a given CPO value, an Operator can provide parameter values less than
10.2 Framework
the maximum or more than the minimum parameter values (i.e. more
stringent parameter values) and still be compliant with MEF 23.1 IA. 10.2.0 Domains

10.2.1 Constructs
From a Service OAM Performance Monitoring (SOAM-PM) point of view, these
10.2.1.1 MEP, MIP, MEG, MEG
parameter values provide a basis for how the measurements are made for the Level
CoS Frame Sets. In Phase 2, parameters associated with each performance
10.2.2 MEF 17
metric are stated separately for each CoS Label due to variances in
10.2.2.1 Model
Percentiles, though the values are uniform across PTs.
10.2.2.2 Maintenance Entities
In MEF 23.1 the scope of CPOs is limited to Point-to-Point EVC/OVC types -
< br/>
Multipoint will be addressed in a later phase. There is no requirement that
parameters be uniform across CoS Labels, PTs, EVC/OVC types or between 10.3 Fault Management

performance metrics with similar parameters. Parameters may not be 10.3.1 Definition
specified (i.e., N/S) in MEF 23.1 when the associated CPOs are not specified 10.3.2 Procedures
(i.e., N/S).
10.3.2.1 Continuity Check
Message

10.3.2.2 Loopback Message

10.3.2.3 Link Trace Message

< br/>
10.4 Performance Management

10.4.1 Definition

10.4.2 Procedures

10.4.2.0 Frame Delay

10.4.2.1 Delay Measurement


Message

10.4.2.2 Loss Measurement


Message

10.4.3 Computation Methods

10.4.3.0 Frame Delay


Figure 10.5.3.T1 - Table 5: CoS Label H, M and L Parameter Values
[Source: MEF 23.1, Table 5] 10.4.3.1 Inter-Frame Delay
Variation
Tables 6, 7, 8 and 9 provide CPOs for each performance metric per each CoS
10.4.3.2 Frame Loss Ratio
Label. Each Table provides CPOs for one PT of the four PTs. These are
10.4.3.3 Availability
normative as per the requirements that refer to them.
Note: Multipoint includes Rooted Multipoint. 10.4.4 Measurement in E-Line, E-
LAN, E-Tree

< br/>

10.5 CoS Implementation


Agreement - MEF 23

10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

Figure 10.5.3.T2 - Table 6: Metro PT CPOs 10.6.3 Interconnect via ENNI


[Source: MEF 23.1, Table 6]

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect
Figure 10.5.3.T3 - Table 7: Regional PT CPOs ITU-T Y.1731
[Source: MEF 23.1, Table 7]

MEF-CECP Test Objectives

10 Service OAM

Send Feedback

Name:

Email:

Comments

Send Feedback

Figure 10.5.3.T4 - Table 8: Continental PT CPOs


[Source: MEF 23.1, Table 8]

Figure 10.5.3.T5 - Table 9: Global PT CPOs


[Source: MEF 23.1, Table 9]

Note that in the case of an EVC that comprises multiple OVCs, the EVC CPOs
in Tables 6, 7, 8 and 9 may not be met even if CoS Label mapping is aligned.
For example, when there is insufficient alignment of CBS between Operators
and/or insufficient shaping at the ENNI.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.6 Maintenance

10.1 Relevant Standards


Performance Management Implementation
10.1.1 IEEE 802.1ag Overview
This section describes how performance metrics are taken into account in 10.1.2 Y.1731 Overview
three different scenarios:
< br/>
Multi-CoS EVC 10.2 Framework
Using a Bandwidth Profile
10.2.0 Domains
Interconnect via ENNI
10.2.1 Constructs
10.2.1.1 MEP, MIP, MEG, MEG
Level

10.2.2 MEF 17

10.2.2.1 Model

10.2.2.2 Maintenance Entities

< br/>

10.3 Fault Management

10.3.1 Definition

10.3.2 Procedures

10.3.2.1 Continuity Check


Message

10.3.2.2 Loopback Message

10.3.2.3 Link Trace Message

< br/>
10.4 Performance Management

10.4.1 Definition

10.4.2 Procedures

10.4.2.0 Frame Delay

10.4.2.1 Delay Measurement


Message

10.4.2.2 Loss Measurement


Message

10.4.3 Computation Methods

10.4.3.0 Frame Delay

10.4.3.1 Inter-Frame Delay


Variation

10.4.3.2 Frame Loss Ratio

10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


LAN, E-Tree

< br/>

10.5 CoS Implementation


Agreement - MEF 23

10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.6.1 Maintenance

10.1 Relevant Standards


Multi-CoS EVC
10.1.1 IEEE 802.1ag Overview
Performance objectives are defined for a given CoS ID of an EVC. Each EVC 10.1.2 Y.1731 Overview
supports up to 8 CoS IDs and each can potentially have its own performance
< br/>
objectives. For example, an EVC with 3 CoS named H, M, L might have the
following performance objectives: 10.2 Framework

10.2.0 Domains

10.2.1 Constructs

10.2.1.1 MEP, MIP, MEG, MEG


Level

10.2.2 MEF 17

10.2.2.1 Model
10.6.1.T1 - Example CoS Performance Objectives
10.2.2.2 Maintenance Entities
All objectives are specified over time interval T of 60 minutes. Assuming that
< br/>
this exemplary EVC is an E-Line, there will be two MEPs in this EVC ME - one
at each UNI-N. In order to measure one-way Inter-Frame Delay Variation, 10.3 Fault Management
each of the MEPs will trigger ETH-DM procedure every 1 second for each of 10.3.1 Definition
the CoS. MEP A will send 3 ETH-DM with the CE-VLAN ID of the EVC and with: 10.3.2 Procedures

1. PCP value mapped to H CoS 10.3.2.1 Continuity Check


Message
2. PCP value mapped to M CoS
3. PCP value mapped to L CoS 10.3.2.2 Loopback Message

10.3.2.3 Link Trace Message


When multiple PCP values map to a single CoS ID, the PCP that yields the
< br/>
lowest loss is used. Therefore once a second there are 6 procedures initiated
(2 MEPs, 3 CoS each) At the end of the 60 minutes interval, each MEP 10.4 Performance Management
calculates the IFDV for each CoS ID and reports the measurement. This 10.4.1 Definition
measurement is compared with the performance objective for the given CoS 10.4.2 Procedures
ID.
10.4.2.0 Frame Delay
In the CoS Performance objectives example above, when we consider FLR we 10.4.2.1 Delay Measurement
see that there is no objective set for the L CoS ID. Therefore, the ETH-LM Message

procedure is executed at each MEP only for 2 CoS (H and M). We also see that 10.4.2.2 Loss Measurement
Message
Availability is not computed since it was not specified as a performance
objective for this service instance. 10.4.3 Computation Methods

10.4.3.0 Frame Delay

10.4.3.1 Inter-Frame Delay


Variation

10.4.3.2 Frame Loss Ratio

10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


LAN, E-Tree

< br/>

10.5 CoS Implementation


Agreement - MEF 23

10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.6.2 Maintenance

10.1 Relevant Standards


Relationship to Bandwidth Profile
10.1.1 IEEE 802.1ag Overview
Performance objectives for an EVC apply only for service frames that meet all 10.1.2 Y.1731 Overview
the following conditions:
< br/>
They are mapped to the EVC 10.2 Framework
Delivery rules allow delivery to the egress UNI(s)
10.2.0 Domains
The ingress bandwidth profile declared them as green frames
10.2.1 Constructs
The frame size is no greater than the EVC's MTU size
10.2.1.1 MEP, MIP, MEG, MEG
It should be noted that frames dropped by the egress BWP do count against Level
the SLS's performance objectives. From this definition it is clear that a Best 10.2.2 MEF 17
Effort service (ingress BWP per EVC set with CIR=0, CBS=0) yields no 10.2.2.1 Model
performance objectives, as no frame would meet the above criteria. In the
10.2.2.2 Maintenance Entities
case that this EVC crosses an ENNI, any green frame at the ingress UNI that is
dropped by the ENNI bandwidth profile would be counted against the SLS. < br/>

10.3 Fault Management



10.3.1 Definition

10.3.2 Procedures

10.3.2.1 Continuity Check


Message

10.3.2.2 Loopback Message

10.3.2.3 Link Trace Message

< br/>
10.4 Performance Management

10.4.1 Definition

10.4.2 Procedures

10.4.2.0 Frame Delay

10.4.2.1 Delay Measurement


Message

10.4.2.2 Loss Measurement


Message

10.4.3 Computation Methods

10.4.3.0 Frame Delay

10.4.3.1 Inter-Frame Delay


Variation

10.4.3.2 Frame Loss Ratio

10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


LAN, E-Tree

< br/>

10.5 CoS Implementation


Agreement - MEF 23

10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.6.3 Maintenance

10.1 Relevant Standards


Interconnection via ENNI
10.1.1 IEEE 802.1ag Overview
MEF 26.0.3 defines performance objectives for an OVC. The performance 10.1.2 Y.1731 Overview
objectives will be further enhanced in the coming MEF 23.1 specification.
< br/>
An E-Line may traverse multiple CENs. In the following example an E-Line
comprises two Point-to-Point OVCs. 10.2 Framework

10.2.0 Domains

10.2.1 Constructs

10.2.1.1 MEP, MIP, MEG, MEG


Level

10.2.2 MEF 17

10.2.2.1 Model
10.6.3.F1 - E-Line
10.2.2.2 Maintenance Entities
Calculating the performance objectives for each OVC in order to meet specific
< br/>
EVC performance objectives is made challenging by the fact that the
percentiles and FLR are not additive. 10.3 Fault Management

10.3.1 Definition
Future versions of MEF 23 and MEF SOAM PM specifications are expected to
10.3.2 Procedures
provide solutions for this use case.
10.3.2.1 Continuity Check
Message

10.3.2.2 Loopback Message

10.3.2.3 Link Trace Message

< br/>
10.4 Performance Management

10.4.1 Definition

10.4.2 Procedures

10.4.2.0 Frame Delay

10.4.2.1 Delay Measurement


Message

10.4.2.2 Loss Measurement


Message

10.4.3 Computation Methods

10.4.3.0 Frame Delay

10.4.3.1 Inter-Frame Delay


Variation

10.4.3.2 Frame Loss Ratio

10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


LAN, E-Tree

< br/>

10.5 CoS Implementation


Agreement - MEF 23

10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

MEF 17
Service OAM Requirements & Framework - Phase 1

MEF 17 is a specification document developed by the Technical Committee of the MEF.

Abstract:

"OAM (Operations, Administration and Maintenance) can be used to manage network infrastructures and services
provided across these network infrastructures. This document provides requirements and framework for Service OAM
within MEF compliant Metro Ethernet Networks (MENs). Service OAM requirements represent expectations of Service
Providers in managing Ethernet Services within the MENs and Subscribers in managing Ethernet Services across the MENs.
Service OAM framework describes the high-level constructs used to model different MEN and Service components that are
relevant for OAM. The framework also describes the relationship between Service OAM and the architectural constructs
of Ethernet Services (ETH), Transport Service (TRAN) and Application Service (APP) Layers as identified in [MEF 4]."
Download

Reference Presentation

The MEF has prepared an overview presentation which explains the MEF 17 specification.

Download

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

MEF Reference Presentation


Carrier Ethernet Interconnect

This presentation provides an overview of the work of the MEF relating to the interconnection of Carrier Ethernet
networks from more than one service provider/operator to create an end-to-end Carrier Ethernet service.

Download

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

ITU-T Y.1731
OAM Functions and Mechanisms

The Y.1731 recommendation developed by ITU-T is a useful reference for understanding Service OAM in the context of
Carrier Ethernet networks. The document can be downloaded here.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Test Objectives 10 1 In this Section


Service Operations, Administration and Maintenance (SOAM) 10 Carrier Ethernet Service
Operations, Administration and
10.1 Describe the various partitioning of responsibilities for Service Operations Maintenance
Administration and Maintenance (SOAM).
10.1 Relevant Standards

10.2 Describe the basic mechanisms for fault management. 10.1.1 IEEE 802.1ag Overview

10.1.2 Y.1731 Overview


10.3Describe the basic mechanisms for performance management.
< br/>
10.4 Describe the basic metrics for performance management.
10.2 Framework

10.2.0 Domains

10.2.1 Constructs

10.2.1.1 MEP, MIP, MEG, MEG


Level

10.2.2 MEF 17

10.2.2.1 Model

10.2.2.2 Maintenance Entities

< br/>

10.3 Fault Management

10.3.1 Definition

10.3.2 Procedures

10.3.2.1 Continuity Check


Message

10.3.2.2 Loopback Message

10.3.2.3 Link Trace Message

< br/>
10.4 Performance Management

10.4.1 Definition

10.4.2 Procedures

10.4.2.0 Frame Delay

10.4.2.1 Delay Measurement


Message

10.4.2.2 Loss Measurement


Message

10.4.3 Computation Methods

10.4.3.0 Frame Delay

10.4.3.1 Inter-Frame Delay


Variation

10.4.3.2 Frame Loss Ratio

10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


LAN, E-Tree

< br/>

10.5 CoS Implementation


Agreement - MEF 23

10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

IEEE 802.1AX
Link Aggregation
Specification

MEF 6.1 is a specification document developed by the Technical Committee of the MEF.

Abstract:

"This document uses the service attributes and parameters that are defined in the MEF Technical Specification Ethernet
Services Attributes Phase 2 [2] and applies them to create different Ethernet services. This document defines three
generic service constructs called Ethernet Service types and specifies their associated service attributes and parameters
used to create Point-to-Point, Multipoint-to-Multipoint, and Rooted-Multipoint Ethernet services. This document also
defines the requirements for several Ethernet services that use these generic Ethernet Service types. In addition, an
informative appendix is provided showing examples of some of the defined services. This document supersedes and
replaces MEF 6, Ethernet Services Definitions - Phase 1 [1]."
Download

Reference Presentation

The MEF has prepared an overview presentation which explains the MEF 6.1 specification.

Download

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

IEEE 802.1AX
Link Aggregation
Specification

MEF 6.1 is a specification document developed by the Technical Committee of the MEF.

Abstract:

"This document uses the service attributes and parameters that are defined in the MEF Technical Specification Ethernet
Services Attributes Phase 2 [2] and applies them to create different Ethernet services. This document defines three
generic service constructs called Ethernet Service types and specifies their associated service attributes and parameters
used to create Point-to-Point, Multipoint-to-Multipoint, and Rooted-Multipoint Ethernet services. This document also
defines the requirements for several Ethernet services that use these generic Ethernet Service types. In addition, an
informative appendix is provided showing examples of some of the defined services. This document supersedes and
replaces MEF 6, Ethernet Services Definitions - Phase 1 [1]."
Download

Reference Presentation

The MEF has prepared an overview presentation which explains the MEF 6.1 specification.

Download

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

MEF 9
Abstract Test Suite for Ethernet Services at the UNI

MEF 9 is a specification document developed by the Technical Committee of the MEF that provides an Abstract Test Suite
for testing Ethernet Services at the UNI.

Abstract:

"This document defines the requirements and corresponding test procedures that determine the readiness of a Metro
Ethernet Network (MEN) to deliver various Ethernet Services, such as Ethernet Line (E-Line) and Ethernet LAN (E-LAN)
services. Requirements are derived from Metro Ethernet Forum Technical Committee documents."

Download

Reference Presentation
The MEF has prepared an overview presentation which explains the MEF 9 ATS.

Download

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

MEF 14
Abstract Test Suite for Traffic Management Phase 1

MEF 14 is a specification document developed by the Technical Committee of the MEF that provides an Abstract Test Suite
for testing traffic management at the UNI.

Abstract:

"This document defines the requirements and corresponding test procedures for Service Performance and Bandwidth
Profile Service Attributes that may be specified as part of a Service Level Specification (SLS) for an Ethernet Service.
Requirements are derived from Metro Ethernet Forum Technical Committee documents."

Download

Reference Presentation
The MEF has prepared an overview presentation which explains the MEF 14 Abstract Test Suite.

Download

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

MEF 18
Abstract Test Suite for Circuit Emulation Services over Ethernet

MEF 18 is a specification document developed by the Technical Committee of the MEF that provides an Abstract Test Suite
for testing circuit emulation services over Ethernet based on MEF 8.

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."

Download

Reference Presentation

The MEF has prepared an overview presentation which explains the MEF 6.1 specification.

Download
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

MEF Reference Presentation


Global Interconnect

Download

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Diagrams: Fundamentals of Carrier Ethernet

Figure 1.1.F1: 5 Attributes of Carrier Figure 1.1.F2: Typical Carrier Figure 1.2.F1: E-Line Carrier
Ethernet Ethernet Network Ethernet service type

Figure 1.2.F2: E-LAN Carrier Ethernet Figure 1.2.F3: E-Tree Carrier Ethernet Figure 1.3.F1: Example EVP-Tree
service type service type

Figure 1.3.F2: Multiple Carrier


Ethernet services using single UNI

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Diagrams: Carrier Ethernet Services over Transport Technologies

2.1.1.1.F2 - C-Tag Format

2.1.1.1.T1 - Bridging support for


2.1.1.1.F1 - C-Tag Frame Format Carrier Ethernet Services

2.1.1.2.F1 - Double Tag Frame Format

2.1.1.2.F2 - S-Tag Format


2.1.1.2.T1 - Provider Bridging Support
for Carrier Ethernet Services

2.1.1.3.F1 - Evolving Frame Format

2.1.1.4.T1 - PBB-TE Support for


2.1.1.3.T1 - Provider Backbone Carrier Ethernet Services
Bridging Support for Carrier Ethernet
Services

2.1.2.1.F1 - VPWS 2.1.2.1.F1 - VPLS


2.1.2.1.T1 - VPWS Support for Carrier
Ethernet Services

2.1.3.1.F1 - Network Architecture

2.1.2.2.T1 - VPWS Support for Carrier 2.1.2.3.T1 - MPLS-TP Support for


Ethernet Services Carrier Ethernet Services

2.1.3.1.F2 -
Encapsulation of an
Ethernet frame inside
GFP-F frame
2.1.3.1.T1 - SONET/SDH Support for 2.1.3.2.T1 - OTN Support for Carrier
Carrier Ethernet Services Ethernet Services

2.1.3.3.F1 - WDM

2.1.3.3.T1 - WDM
Support for Carrier
Ethernet Services

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Diagrams: Carrier Ethernet Services over Access Technologies

3.1.F1 - Carrier Ethernet Services 3.1.1.F1 - Carrier Ethernet and HFC


over Access Infrastructures 3.1.2.F1 - Carrier Ethernet Services
over PON Infrastructures

3.1.3.F1 - Carrier Ethernet over 3.1.3.F2 - Access Technologies for 3.1.4.F1 - Carrier Ethernet over
Packet Wireless Carrier Ethernet Mobile Backhaul DS3/E3

3.1.4.T1 Summary Table for Carrier


Ethernet over PDH
3.1.6.F1 Carrier
Ethernet over Bonded
Copper

3.1.5.F1 Carrier Ethernet over Fiber

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Diagrams: Key Components of Carrier Ethernet

Figure 4.1.F1 - Subscribers, Service Figure 4.2.F1 - Basic Service Model Figure 4.2.F2 - UNI-C and UNI-N
Providers and Operators per MEF 10.2

Figure 4.2.F3 - EPL EVC Figure 4.2.F4 - ENNI Figure 4.2.F5 - EVC and multiple OVCs

Figure 4.2.F7 - UNI Entities Figure 4.2.F6 - ENNI-Ns Figure 4.3.F1 - MEF 26 Model


Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Diagrams: Attributes of Carrier Ethernet Services

Figure 5.F1 - Type-Attribute-Attribute Figure 5.2.T2 - Attribute


Parameter Combinations

Figure 5.2.T1 - UNI Service


Attributes

Figure 5.2.T3 - MACs for Bridge and


GARP Table 5.2.T5 - MACs for Bridge and
GARP

Figure 5.2.T4 - Untagged frame at


the UNI
Figure 5.2.F1 - 'Peer' action Figure 5.2.F2 - 'Pass to EVC' action
Table 5.2.T6 - L2CP Protocols and
Associated Ethertypes and Subtypes

Figure 5.3.F1 - Mapping CE-VLAN IDs to Figure 5.3.T1 - Mapping CE-VLAN IDs
EVCs to EVCs

Figure 5.3.F2 - Mapping CE-VLAN IDs to Figure 5.4.F1 - Preserving Customer Figure 5.4.F2 - CE-VLAN ID
EVCs VLAN-IDs Preservation Example

Figure 5.4.T1 - Protocols Figure 5.4.T2 - EVCs and CoS ID Figure 5.5.F1 - Operator to Operator
example ENNI

Figure 5.5.T1 - ENNI Frame Tags Figure 5.6.1.F2 - Service Frame in Figure 5.6.T1 - Correspondence
Hairpin Switching between Ingress and Egress
Figure 5.6.T2 - Correspondence Ingress Figure 5.6.T3 - CE-VLAN CoS Figure 5.7.T1 - H, M, L - Green Color
to Egress 2 Preservation

Figure 5.7.T2 - H, M, L - Yellow Color Figure 5.7.T3 - Ingress Bandwidth Figure 5.7.F1 Bandwidth Profile per
Profile Compliance OVC

Figure 5.8.F1 - Ingress Bandwidth Profile Figure 5.8.F2 - Ingress Bandwidth Figure 5.8.F3 - Ingress Bandwidth
Per Ingress UNI Per EVC Profile Per CoS ID

Figure 5.8.F4 - Total Bandwidth at UNI Figure 5.8.F5 - Egress Bandwidth


Profile per EVC Figure 5.8.F6 - C-Bucket and E-
Bucket

Figure 5.8.F7 - Burst Threshold Figure 5.8.F8 - EP-LAN Application Figure 5.8.T1 - Example EP-LAN
Attributes

Figure 5.10.F1. - One way frame delay Figure 5.10.F2 - Inter frame delay Figure 5.10.F3 - Frame loss ratio
variation

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Diagrams: MEF Certification of Carrier Ethernet Services

Currently, there are no diagrams in section 6.


Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Diagrams: Typical Target Applications for Carrier Ethernet Services

Figure 7.1.F1: Example - Turbo 2000 Table 7.1.T1: Example - UNI Service Table 7.1.T2: Example - EVC Service
Attributes
Internet Access, Inc. Attributes

Table 7.1.T3: Example - EVC per UNI Figure 7.2.F1 Figure 7.2.F3
Service Attributes

Table 7.2.T1 Table 7.2.T2 Figure: 7.3.F1


Figure: 7.3.F2 Figure: 7.3.F3 Table: 7.3.T1

Table 7.3.1.T1 - EVC per EVP-Line Table 7.3.1.T2 - EVC ID at RAN NC Figure 1 (7.3.2.F1) - Generic
UNI-NI Interworking Function with Legacy
MBH Network

Figure 2 (7.3.2.F2) - Generic Figure 3 (7.3.2.F3) - UNI with MBH Figure 4 (7.3.2.F4) - UNI without
Legacy Network Legacy MBH Network
Interworking Function without Legacy
Network

Figure 7.4.F1 - Example Business Figure 7.4.T1 Figure 7.4.T2


Services Application

Figure 7.4.T3 Figure 7.4.F2 - Operators and Service Figure: 7.4.T4


Providers for Business Services
Applications
Figure 7.5.F1 - PBX over legacy PDH Figure 7.5.F2 - PBX over Carrier Figure 7.6.F1 - Legacy ATM-FR
and SONET Ethernet

Figure 7.6.F2 - Carrier Ethernet Figure 7.6.T1 - Table of CE-VLAN ID Figure 7.7.F1 - 3 E-Lines replace WDM
replacing ATM-FR per EVC

Figure 7.7.F2 1 E-LAN replaces WDM

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Diagrams: Positioning of Carrier Ethernet with other Technologies

Figure 8.2.F1: Carrier Ethernet and


IP/MPLS Core Network

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Diagrams: Synchronization over Carrier Ethernet & Circuit Emulation

Figure 9.1.1.F1 - CESoETH

Figure 9.1.2.F1

Figure 9.1.2.F1

Figure 9.3.1.F1 - Mobile Backhaul

Figure 9.4.1.F1 - Packet Based


Methods

Figure 9.4.F1 - Sync Parameters


Figure 9.4.1.1.F1 - Adaptive Clock
Recovery
Figure 9.4.1.1.F2 - Adaptive Clock
Recovery
Figure 9.4.1.3.F1 - PTP
Synchronization Network Topology

Figure 9.4.1.3.F2 - Network Topology


with Boundary Clocks
Figure 9.4.1.3.F3 - Transparent Figure 9.4.1.3.F4 -Peer to Peer
Clocks

Figure 9.4.2.F1 - Synchronization using


Synchronous Ethernet

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Diagrams: Carrier Ethernet Service Operations, Administration & Maintenance

10.1.F1 - SOAM relationship


between standards
10.2.0.F1 - SOAM Domain

10.2.1.1.F1 - Default MEG Levels

10.2.1.F2 - SOAM Maintenance 10.2.2.1.F2 - SOAM Maintenance Entities


Entities 10.2.2.1.F1 - SOAM Service Scope

10.3.2.1.F1 - Example use of


SOAM CCM
10.3.2.3.F1 - SOAM LTM
10.3.2.2.F1 - Example use of
SOAM LBM

10.4.2.1.F1 - DMM 10.4.2.2.F1 - SOAM Loss Measurement

10.4.1.F1 - Performance
monitoring definition

10.4.3.3.F1 -Availability for Small Time


10.4.3.1.F1 - Inter-Frame Delay Intervals
Variation Performance

10.4.3.2.F1 - Frame Loss Ratio

10.4.2.0.F1 - Frame Delay for


Service Frame 10.5.F1 Class of Service
Implementation Agreement
10.5.F2 - 3 CoS Model

Figure 10.5.1.F1 - ENS Model


10.5.F3 Mapping CoS
Illustration
IDs 10.5.2.T1 Class of Service Label
Model Table 2

10.5.2.T2 Class of
Service Label Model
10.5.2.T3 Class of
Table 3
Service Label Model
Table 4

Figure 10.5.3.T1 - Table 5: CoS Label H, M


and L Parameter Values

Figure 10.5.3.T4 - Table 8: Continental PT


Figure 10.5.3.T2 - Table 6: Metro CPOs
PT CPOs
Figure 10.5.3.T3 - Table 7:
Regional PT CPOs

10.6.1.T1 - Example CoS 10.6.3.F1 - E-Line


Performance Objectives

Figure 10.5.3.T5 - Table 9: Global


PT CPOs

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

MEF 33
Ethernet Access Services Definition

MEF 33 is a specification document developed by the Technical Committee of the MEF that defines Ethernet Access
Services.

Abstract:

"This document defines Ethernet Access Services, which are OVC-based Ethernet services in contrast to the EVC-based
services which are defined in MEF 6.1 Technical Specification Ethernet Services Definitions[1]. This document uses the
UNI service attributes and parameters options defined in the MEF 6.1 and ENNI and OVC service attributes defined in
MEF 26 Technical Specification External Network Network Interface (ENNI) Phase 1 [8] and applies them to create new
Ethernet access services between a UNI and an ENNI. These new carrier-to-carrier Ethernet access services enable
Ethernet Service Providers to reach out-of- franchise customer locations through an Ethernet Access Provider's network,
and deliver E-Line and E-LAN service types end to end. This document defines the UNI, OVC, OVC per UNI, OVC End Point
per ENNI, and ENNI requirements for point-to-point OVC-based Ethernet services. In addition, an informative appendix is
provided showing use cases of some of the defined services."

Download

Reference Presentation

Currently, there is no MEF reference presentation available for MEF 33.

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Technical Specification

MEF 6.1

Ethernet Services Definitions - Phase 2

April, 2008

MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

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 2008. All Rights Reserved.

MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

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

2. TERMINOLOGY......................................................................................................................................................1

3. SCOPE........................................................................................................................................................................6
3.1 SCOPE OF FUTURE PHASES ...................................................................................................................................6
4. COMPLIANCE LEVELS.........................................................................................................................................7

5. INTRODUCTION .....................................................................................................................................................7

6. ETHERNET SERVICE DEFINITION FRAMEWORK (NORMATIVE) ..........................................................7


6.1 ETHERNET LINE (E-LINE) PHASE 2 SERVICE TYPE ...............................................................................................9
6.2 ETHERNET LAN (E-LAN) SERVICE TYPE ..........................................................................................................11
6.3 ETHERNET TREE (E-TREE) SERVICE TYPE ..........................................................................................................14
7. SERVICE DEFINITIONS (NORMATIVE) .........................................................................................................16
7.1 ETHERNET PRIVATE LINE SERVICE.....................................................................................................................17
7.2 ETHERNET VIRTUAL PRIVATE LINE SERVICE .....................................................................................................19
7.3 ETHERNET PRIVATE LAN SERVICE ....................................................................................................................22
7.4 ETHERNET VIRTUAL PRIVATE LAN SERVICE .....................................................................................................25
7.5 ETHERNET PRIVATE TREE SERVICE ....................................................................................................................28
7.6 ETHERNET VIRTUAL PRIVATE TREE SERVICE.....................................................................................................31
8. LAYER 2 CONTROL PROTOCOL PROCESSING REQUIREMENTS (NORMATIVE) ............................33
8.1 L2CP REQUIREMENTS FOR ETHERNET PRIVATE LINE (EPL) SERVICE ...............................................................34
8.2 L2CP REQUIREMENTS FOR ETHERNET VIRTUAL PRIVATE LINE (EVPL) SERVICE .............................................35
8.3 L2CP REQUIREMENTS FOR ETHERNET PRIVATE LAN (EP-LAN) SERVICE ........................................................35
8.4 L2CP REQUIREMENTS FOR ETHERNET VIRTUAL PRIVATE LAN (EVP-LAN) SERVICE......................................36
8.5 L2CP REQUIREMENTS FOR ETHERNET PRIVATE TREE (EP-TREE) SERVICE .......................................................36
8.6 L2CP REQUIREMENTS FOR ETHERNET VIRTUAL PRIVATE TREE (EVP-TREE) SERVICE .....................................37
9. SERVICE OAM REQUIREMENTS (NORMATIVE) ........................................................................................38
9.1.1 Subscriber MD, Continuity Check .............................................................................................................39
9.1.2 Subscriber MD, Link Trace .......................................................................................................................39
9.1.3 Subscriber MD, Loopback .........................................................................................................................40

10. REFERENCES ........................................................................................................................................................41

11. APPENDIX A: MEF AND IEEE 802.1 TERMINOLOGY (INFORMATIVE)................................................42

12. APPENDIX B: PRACTICAL EXAMPLES OF ETHERNET SERVICES (INFORMATIVE).......................42


12.1 EXAMPLE: A TRANSPORT-ORIENTED ETHERNET PRIVATE LINE (EPL) SERVICE FOR PRIVATE DATA
NETWORKING APPLICATIONS. ............................................................................................................................................44
12.2 EXAMPLE OF A PACKET-ORIENTED ETHERNET PRIVATE LINE SERVICE FOR PUBLIC DATA NETWORKING
APPLICATIONS ....................................................................................................................................................................47
12.3 EXAMPLE: ETHERNET PRIVATE TREE (EP-TREE) SERVICE FOR VIDEO BROADCAST ..........................................49
12.4 EXAMPLE: DISTANCE LEARNING (EVP-TREE) AND BUSINESS DATA (EVP-LAN).............................................51

MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page i
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.
Ethernet Services Definitions, Phase 2 MEF 6.1

List of Figures
Figure 1: Ethernet Service Definition Framework........................................................................................................8
Figure 2: E-Line Service type using Point-to-Point EVC...........................................................................................10
Figure 3: E-LAN Service type using Multipoint-to-Multipoint EVC.........................................................................12
Figure 4: E-Tree Service type using Rooted-Multipoint EVC....................................................................................14
Figure 5: E-Tree Service type using Multiple Roots ..................................................................................................15
Figure 6: Ethernet Private Line (EPL) Service ...........................................................................................................17
Figure 7: Ethernet Virtual Private Line (EVPL) Service............................................................................................20
Figure 8: Ethernet Private LAN (EP-LAN) Service ...................................................................................................23
Figure 9: Ethernet Virtual Private LAN (EVP-LAN) Service ....................................................................................26
Figure 10: Ethernet Private Tree (EP-Tree) Service...................................................................................................28
Figure 11: Ethernet Virtual Private Tree (EVP-Tree) Service....................................................................................31
Figure 12: Example of Transport-Oriented Private Data Network Interconnect Using the EPL Service...................45
Figure 13: Example of Transport-Oriented Public Data Network Interconnect Using the EPL Service. ...................47
Figure 14: Example of Video Broadcast Delivery Using the EP-Tree Service ..........................................................50
Figure 15: Example of Distance Learning and Business Data Using EVP-LAN and EVP-Tree Services .................52

List of Tables
Table 1: Terminology and Definitions Table................................................................................................................6
Table 2: Ethernet Services ............................................................................................................................................8
Table 3: UNI service attributes and parameter values for all service types ..................................................................9
Table 4: E-Line Service type EVC per UNI service attributes and parameter values ................................................11
Table 5: E-Line Service type EVC service attributes and parameter values ..............................................................11
Table 6 : E-LAN Service type EVC per UNI service attributes and parameter values................................................13
Table 7: E-LAN Service type EVC service attributes and parameter values..............................................................14
Table 8 : E-Tree Service type EVC per UNI service attributes and parameter values ................................................16
Table 9: E-Tree Service type EVC service attributes and parameter values ..............................................................16
Table 10: UNI service attributes and parameters for the EPL service ........................................................................18
Table 11: EVC per UNI service attributes and parameters for the EPL service .........................................................18
Table 12: EVC service attributes and parameters for the EPL service .......................................................................19
Table 13: Differences in EPL from EPL in MEF 6 ....................................................................................................19
Table 14: UNI service attributes and parameters for EVPL service ...........................................................................21
Table 15: EVC per UNI service attributes and parameters for EVPL service ............................................................21
Table 16: EVC service attributes and parameters for the EVPL service ....................................................................22
Table 17: Differences in EVPL from EVPL in MEF 6...............................................................................................22
Table 18: UNI service attributes and parameters for the EP-LAN service .................................................................24
Table 19: EVC per UNI service attributes and parameters for the EP-LAN service..................................................24
Table 20: EVC service attributes and parameters for the EP-LAN service ................................................................25
Table 21: UNI service attributes and parameters for the EVP-LAN service ..............................................................26
Table 22: EVC per UNI service attributes and parameters for the EVP-LAN service ...............................................27
Table 23: EVC service attributes and parameters for the EVP-LAN service .............................................................28
Table 24: UNI service attributes and parameters for the EP-Tree service..................................................................29
Table 25: EVC per UNI service attributes and parameters for the EP-Tree service...................................................30
Table 26: EVC service attributes and parameters for the EP-Tree service.................................................................31

MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page ii
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.
Ethernet Services Definitions, Phase 2 MEF 6.1

Table 27: UNI service attributes and parameters for the EVP-Tree service...............................................................32
Table 28: EVC per UNI service attributes and parameters for the EVP-Tree service................................................32
Table 29: EVC service attributes and parameters for the EVP-Tree service ..............................................................33
Table 30: List of Standardized Layer 2 Control Protocols .........................................................................................33
Table 31: L2CP Processing Requirements for the EPL Service .................................................................................35
Table 32: L2CP Processing Requirements for the EVPL Service ..............................................................................35
Table 33: L2CP Processing Requirements for the EP-LAN Service ..........................................................................36
Table 34: L2CP Processing Requirements for the EVP-LAN Service .......................................................................36
Table 35: L2CP Processing Requirements for the EP-Tree Service...........................................................................37
Table 36: L2CP Processing Requirements for the EVP-Tree Service ........................................................................37
Table 37: MEF and IEEE 802.1 terms for L2CP Processing Options ........................................................................42
Table 38: EVC Performance Attributes and Parameters per CoS Offering................................................................43
Table 39: L2CP Attribute and Parameters per Service Offering ................................................................................44
Table 40: UNI attributes for the Private Data Networking example using EPL Service ............................................45
Table 41: EVC per UNI attributes for the private data networking example using EPL Service ...............................46
Table 42: EVC service attributes for the private data networking example using the EPL Service ...........................46
Table 43: UNI attributes for the Private Data Networking example using EPL Service ............................................48
Table 44: EVC per UNI attributes for the public data networking example using EPL Service ................................48
Table 45: EVC service attributes for the public data networking example using the EPL Service ............................49
Table 46: UNI attributes for the video broadcast example using EP-Tree Service ....................................................50
Table 47: EVC per UNI attributes for the video broadcast example using EP-Tree Service .....................................51
Table 48: EVC service attributes for the video broadcast example using EP-Tree Service .......................................51
Table 49: UNI attributes for the distance learning, business data example ................................................................52
Table 50: EVC per UNI attributes for the distance learning, business data example .................................................53
Table 51: EVC attributes for the distance learning, business data example ...............................................................54

MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page iii
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.
Ethernet Services Definitions, Phase 2 MEF 6.1

1. Abstract
This document uses the service attributes and parameters that are defined in the MEF Technical
Specification Ethernet Services Attributes Phase 2 [2] and applies them to create different
Ethernet services. This document defines three generic service constructs called Ethernet
Service types and specifies their associated service attributes and parameters used to create
Point-to-Point, Multipoint-to-Multipoint, and Rooted-Multipoint Ethernet services. This
document also defines the requirements for several Ethernet services that use these generic
Ethernet Service types. In addition, an informative appendix is provided showing examples of
some of the defined services. This document supersedes and replaces MEF 6, Ethernet Services
Definitions - Phase 1 [1].

2. Terminology
This section defines the terms used in this document. In many cases, the normative definitions to
terms are found in other documents. In these cases, the third column is used to provide the
reference that is controlling.
Term Definition Reference
All to One A UNI attribute in which all CE-VLAN IDs are associated [2]
Bundling with a single EVC.
Availability A measure of the percentage of time that a service is useable. [2]
Performance
A characterization of Service Frame arrival times and [2]
lengths at a reference point and a specification of the
Bandwidth Profile disposition of each Service Frame based on its level of
compliance with the Bandwidth Profile. In this document
the reference point is the UNI.
Bandwidth profile [2]
A bandwidth profile applied on a per-Class of Service basis.
per CoS ID
Bandwidth profile [2]
A bandwidth profile applied on a per-EVC basis.
per EVC
Bandwidth profile [2]
A bandwidth profile applied on a per-UNI basis.
per UNI
Broadcast Service A Service Frame that has the broadcast destination MAC [2]
Frame address.
A UNI attribute in which more than one CE-VLAN ID can [2]
Bundling
be associated with an EVC.
CBS Committed Burst Size [2]
CE Customer Edge [2]
CE-VLAN CoS Customer Edge VLAN CoS [2]

MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

Term Definition Reference


An EVC attribute in which the CE-VLAN CoS of an egress [2]
CE-VLAN CoS
Service Frame is identical in value to the CE-VLAN CoS of
Preservation
the corresponding ingress Service Frame.
CE-VLAN ID Customer Edge VLAN ID [2]
An EVC attribute in which the CE-VLAN ID of an egress [2]
CE-VLAN ID
Service Frame is identical in value to the CE-VLAN ID of
Preservation
the corresponding ingress Service Frame.
CE-VLAN ID / [2]
An association of CE-VLAN IDs with EVCs at a UNI.
EVC Map
CE-VLAN Tag Customer Edge VLAN Tag [2]
CF Coupling Flag [2]
CIR Committed Information Rate [2]
A set of Service Frames that have a commitment from the [2]
Class of Service
Service Provider to receive a particular level of performance.
An indicator for a particular CoS instance. Information [2]
derivable from a) the EVC to which the Service Frame is
mapped, b) the combination of the EVC to which the Service
Frame is mapped and a set of one or more than one CE-
Class of Service
VLAN CoS values, c) the combination of the EVC to which
Identifier
the Service Frame is mapped and a set of one or more than
one DSCP values, or d) the combination of the EVC to
which the Service Frame is mapped and a set of one or more
than one tunneled Layer 2 Control Protocols.
CM Color Mode [2]
CM is a Bandwidth Profile parameter. The Color Mode [2]
parameter indicates whether the color-aware or color-blind
Color Mode
property is employed by the Bandwidth Profile. It takes a
value of color-blind or color-aware only.
Color-aware A Bandwidth Profile property where a pre-determined level [2]
of Bandwidth Profile compliance for each Service Frame is
taken into account when determining the level of compliance
for each Service Frame.
Color-blind A Bandwidth Profile property where a pre-determined level [2]
of Bandwidth Profile compliance for each Service Frame, if
present, is ignored when determining the level of compliance
for each Service Frame.
CBS is a Bandwidth Profile parameter. It limits the [2]
Committed Burst
maximum number of bytes available for a burst of Service
Size
Frames sent at the UNI speed to remain CIR-conformant.

MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

Term Definition Reference


CIR is a Bandwidth Profile parameter. It defines the average [2]
rate in bits/s of Service Frames up to which the network
Committed
delivers Service Frames and is committed to meeting the
Information Rate
performance objectives defined by the CoS Service
Attribute.
CoS Class of Service [2]
CF is a Bandwidth Profile parameter. The Coupling Flag [2]
Coupling Flag allows the choice between two modes of operation of the
rate enforcement algorithm. It takes a value of 0 or 1 only.
Customer Edge Equipment on the Subscriber side of the UNI. [2]
The Priority Code Point bits in the IEEE 802.1Q Customer [2]
Customer Edge
VLAN Tag in a Service Frame that is either tagged or
VLAN CoS
priority tagged.
The identifier derivable from the content of a Service Frame [2]
Customer Edge
that allows the Service Frame to be associated with an EVC
VLAN ID
at the UNI.
Customer Edge The IEEE 802.1Q Customer VLAN Tag in a tagged Service [2]
VLAN Tag Frame.
EBS Excess Burst Size [2]
Egress Bandwidth A service attribute that specifies the length and arrival time [2]
Profile characteristics of egress Service Frames at the egress UNI.
Egress Service A Service Frame sent from the Service Provider network to [2]
Frame the CE.
EIR Excess Information Rate [2]
An Ethernet service type that is based on a Multipoint-to- This
E-LAN Service
Multipoint EVC. Document
An Ethernet service type that is based on a Point-to-Point This
E-Line Service
EVC. Document
This
EPL Ethernet Private Line
Document
An Ethernet service type that is based on a Rooted- This
E-Tree Service
Multipoint EVC. Document
An association of two or more UNIs that limits the exchange [2]
Ethernet Virtual
of Service Frames to UNIs in the Ethernet Virtual
Connection
Connection.
EVC Ethernet Virtual Connection [2]
EVC MTU Size The maximum sized Service Frame allowed for an EVC. [2]
This
EVPL Ethernet Virtual Private Line
Document

MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

Term Definition Reference


EBS is a Bandwidth Profile parameter. It limits the [2]
Excess Burst Size maximum number of bytes available for a burst of Service
Frames sent at the UNI speed to remain EIR-conformant.
EIR is a Bandwidth Profile parameter. It defines the average [2]
Excess rate in bits/s of Service Frames up to which the network may
Information Rate deliver Service Frames but without any performance
objectives.
FDX Full Duplex [5]
FD Frame Delay [2]
FDV Frame Delay Variation [2]
FLR Frame Loss Ratio [2]
Frame Short for Ethernet Frame [2]
The time required to transmit a Service Frame from ingress [2]
Frame Delay
UNI to egress UNI.
Frame Delay A measure of the delays experienced by different Service [2]
Performance Frames belonging to the same CoS instance.
Frame Delay [2]
The difference in delay of two Service Frames.
Variation
Frame Delay A measure of the variation in the delays experienced by [2]
Variation different Service Frames belonging to the same CoS
Performance instance.
Frame Loss Ratio is a measure of the number of lost frames [2]
Frame Loss Ratio
between the ingress UNI and the egress UNI. Frame Loss
Performance
Ratio is expressed as a percentage.
A characterization of ingress Service Frame arrival times [2]
Ingress and lengths at the ingress UNI and a specification of
Bandwidth Profile disposition of each Service Frame based on its level of
compliance with the characterization.
Ingress Service A Service Frame sent from the CE into the Service Provider [2]
Frame network.
Layer 2 Control [2]
A Service Frame that is used for Layer 2 control, e.g.,
Protocol Service
Spanning Tree Protocol.
Frame
The process by which a Layer 2 Control Protocol Service [2]
Layer 2 Control
Frame is passed through the Service Provider network
Protocol
without being processed and is delivered unchanged to the
Tunneling
proper UNI(s).
Maximum The maximum number of EVCs that may be on a UNI. [2]
Number of EVCs

MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

Term Definition Reference


Maximum The maximum number of UNIs that may be in an EVC. [2]
number of UNIs
MEN Metro Ethernet Network [12]
Metro Ethernet [12]
The Service Providers network providing Ethernet services.
Network
MNU Maximum Number of UNIs [2]
This
MTU Maximum Transmission Unit
Document
The maximum sized Service Frame allowed for an Ethernet [2]
MTU size
service.
Multicast Service A Service Frame that has a multicast destination MAC [2]
Frame address.
An EVC with two or more UNIs. A Multipoint-to-Multipoint [2]
Multipoint-to-
EVC with two UNIs is different from a Point-to-Point EVC
Multipoint EVC
because one or more additional UNIs can be added to it.
N/A Not Applicable
N/S Not Specified
Point-to-Point [2]
An EVC with exactly 2 UNIs.
EVC
A multipoint EVC in which each UNI is designated as either [2]
a Root or a Leaf. Ingress Service Frames at a Root UNI can
Rooted-Multipoint
be delivered to one or more of any of the other UNIs in the
EVC
EVC. Ingress Service Frames at a Leaf UNI can only be
delivered to one or more Root UNIs in the EVC.
An Ethernet frame transmitted across the UNI toward the [2]
Service Frame Service Provider or an Ethernet frame transmitted across the
UNI toward the Subscriber.
Service Frame [2]
An EVC service attribute defined in [2]
Delivery
The contract between the Subscriber and Service Provider [2]
Service Level
specifying the agreed to service level commitments and
Agreement
related business agreements.
Service Level The technical specification of the service level being offered [2]
Specification by the Service Provider to the Subscriber.
Service A UNI service attribute in which the UNI can be in more [2]
Multiplexing than one EVC instance.
Service Provider The organization providing Ethernet Service(s). [2]
SLA Service Level Agreement [2]
SLS Service Level Specification [2]

MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

Term Definition Reference


Subscriber The organization purchasing and/or using Ethernet Services. [2]
UNI User Network Interface [2]
UNI MTU Size The maximum sized Service Frame allowed at the UNI. [2]
Unicast Service A Service Frame that has a unicast destination MAC [2]
Frame address.
User Network The physical demarcation point between the responsibility of [2]
Interface the Service Provider and the responsibility of the Subscriber.
VLAN Virtual LAN [4]
Table 1: Terminology and Definitions Table
3. Scope
This document defines Phase 2 Ethernet services. It supersedes and replaces MEF 6 [1],
Ethernet Services Definitions Phase 1. This document defines a third service type: E-Tree,
based on a Rooted-Multipoint Ethernet Virtual Connection (EVC). It also updates service
attributes and requirements for the existing defined service types E-Line (based on a Point-to-
Point EVC) and E-LAN (based on a Multipoint-to-Multipoint EVC). These updated service
attributes are those defined in Ethernet Services Attributes - Phase 2 [2].

This document defines generic service constructs called Ethernet Service types used to create
Ethernet services over a Metro Ethernet Network (MEN). It specifies the Ethernet service
attributes and parameters that are used with the different Ethernet Service types, but does not
define how the service attributes may be implemented.

This document also defines the service attribute requirements for several Ethernet Services that
use the generic Ethernet Service type constructs. Where possible, recommendations for the
service attributes and associated parameters are made for these particular Ethernet Services. All
services in this document provide for connectivity among User Network Interfaces (UNIs).

This document does not define application-based services that may be offered using these
Ethernet Service types, e.g., IP Telephony service, nor does it define non-Ethernet-based services
that may be offered over the MEN, e.g., Circuit Emulation Services over a TDM (e.g., T1) UNI.
This document does not define how the services may be supported in the MEN using different
transport and switching technologies.

3.1 SCOPE OF FUTURE PHASES


Subsequent phases of this specification may add additional services or augment existing services
with newly defined service attributes or parameters defined in other MEF Technical Committee
specifications.

MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

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 [6]. All key words use upper case, bold
text.

5. Introduction
Ethernet has its origins in providing network connectivity and was not originally used to provide
wide area services. With the introduction of Metro Ethernet services, Service Providers started
using this Ethernet connectivity technology to provide Ethernet services. While the IEEE
802.3 Ethernet protocol is still used, service-related attributes and parameters need to be added in
order to create an Ethernet service.

This document uses the service attributes and parameters that are defined in the MEF Technical
Specification Ethernet Services Attributes Phase 2 [2] and applies them to create different
Ethernet services. This document defines three generic service constructs called Ethernet
Service types and specifies their associated service attributes and parameters used to create
Point-to-Point, Multipoint-to-Multipoint, and Rooted-Multipoint Ethernet services. This
document also defines the requirements for several Ethernet services that use these generic
Ethernet Service types.

The Phase 2 Ethernet services described in this document are from a Subscriber perspective and
are defined based on the service attributes that might appear in a Service Level Agreement
(SLA) or Service Level Specification (SLS). The services are instantiated at an UNI with IEEE
compliant Ethernet interfaces interconnecting the customer equipment to the Service Provider
network. These services, however, are agnostic of the underlying network infrastructure within
the Metro Ethernet Network (MEN) and may be supported over a combination of network
technologies in the Service Providers network that could include: MPLS, RPR, SONET, VLAN
switching, WDM, etc.

6. Ethernet Service Definition Framework (Normative)


The Ethernet Service Definition Framework provides a model for specifying Ethernet services.
Ethernet Service types are generic constructs used to create a broad range of services. Each
Ethernet Service type has a set of Ethernet service attributes that define the service
characteristics. These Ethernet Service Attributes in turn have a set of parameters associated
with them that provide various options for the different service attributes. Refer to Figure 1.

MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

Figure 1: Ethernet Service Definition Framework


This document defines three Ethernet Service type generic constructs, namely, Ethernet Line (E-
Line) Service type (refer to Section 6.1), Ethernet LAN (E-LAN) Service type (refer to Section
6.2) and Ethernet Tree (E-Tree) Service type (refer to Section 6.3), and their associated service
attributes and parameters. The key differentiator is the type of connectivity provided, as
indicated by the EVC Type service attribute. The UNI and EVC service attributes and
parameters are normatively defined in [2].

More than one Ethernet Service is defined for each of the three Ethernet Service types. These
are differentiated by the method for service identification used at the UNIs. Services using All to
One Bundling UNIs (port-based) are referred to as Private, while services using UNIs that are
that are Service Multiplexed (VLAN-based), are referred to as Virtual Private. This
relationship is shown in Table 2 below.

Port-Based VLAN-Based
Service Type
(All to One Bundling) (EVC identified by VLAN ID)
E-Line Ethernet Private Line Ethernet Virtual Private Line
(point-to-point EVC) (EPL) (EVPL) 1
E-LAN Ethernet Private LAN Ethernet Virtual Private LAN
(multipoint-to-multipoint EVC) (EP-LAN) (EVP-LAN)
E-Tree Ethernet Private Tree Ethernet Virtual Private Tree
(rooted multipoint EVC) (EP-Tree) (EVP-Tree)
Table 2: Ethernet Services
Please note that although some of the service names used in Table 2 and throughout this
document are the same as names used in ITU-T G.8011.1 [13] and G.8011.2 [14], namely EPL
and EVPL, the definitions of those services are different due to the fact that the ITU
recommendations take a network view instead of the services view used in this document.

Table 3 below specifies the UNI service attributes, parameters, and values that are common for
all Ethernet service types. The first column of this table identifies the UNI service attributes, as
defined in [2]. The entries in the second column specify the UNI requirements, regardless of the
1
EVPL as specified in this document is different from EVPL as was specified in [1]. In this document, EVPL cannot
have All to One Bundling at the UNIs while in [1] All to One Bundling was allowed at the UNIs in EVPL.
MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

number of EVCs present on the UNI. These requirements allow for options for certain UNI
attributes, e.g., physical medium, speed, maximum number of EVCs, application of ingress and
egress bandwidth profiles, and layer 2 control protocol processing. Please note that such options
may be different at each UNI in the EVC.
UNI Service Attribute Requirement
UNI Identifier Arbitrary text string to identify the UNI.
Physical Medium UNI Type 2 Physical Interface [5] except for PON interfaces 2
10 Mbps, 100 Mbps, 10/100 Mbps Auto-negotiation, 10/100/1000
Speed
Mbps Auto-negotiation, 1 Gbps, or 10 Gbps.
Mode Full Duplex
MAC Layer IEEE 802.3-2005 [5]
UNI MTU Size MUST be 1522.
Service Multiplexing Yes or No. MUST be No if All to One Bundling is Yes.
Bundling Yes or No. MUST be No if All to One Bundling is Yes.
Yes or No. MUST be No if Bundling or Service Multiplexing is
All to One Bundling
Yes.
CE-VLAN ID for untagged MUST specify CE-VLAN ID for untagged and priority tagged
and priority tagged Service Service Frames in the range of 1-4094. This requirement does not
Frames apply for services with all to one bundling at the UNI.
Maximum number of
MUST be an integer 1.
EVCs
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR,
Ingress Bandwidth Profile
EBS, CM, CF>. MUST NOT be combined with any other type of
Per UNI
ingress bandwidth profile.
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR,
Egress Bandwidth Profile
EBS, CM, CF>. MUST NOT be combined with any other type of
Per UNI
egress bandwidth profile.
Layer 2 Control Protocols For each protocol, MUST specify one of: Peer, Discard, Pass to
Processing EVC, or Peer and Pass to EVC.
Table 3: UNI service attributes and parameter values for all service types
The following subsections define each of the three service types. Section 7 normatively defines
the Ethernet services.

6.1 ETHERNET LINE (E-LINE) PHASE 2 SERVICE TYPE


Any Ethernet service that is based on a Point-to-Point Ethernet Virtual Connection (EVC)
SHALL be designated as an Ethernet Line (E-Line) Service type. The E-Line Service is
illustrated in Figure 2. An E-Line Service type can be used to create a broad range of Point-to-
Point services.

2
MEF does not support Ethernet services over PON interfaces.
MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

Point-to-Point EVC

UNI UNI
Metro Ethernet
Network

Figure 2: E-Line Service type using Point-to-Point EVC


In its simplest form, an E-Line Service type can provide symmetrical bandwidth for data sent in
either direction with no performance assurances, e.g., best effort service between two 10Mbps
UNIs. In more sophisticated forms, an E-Line Service type may be between two UNIs with
different line rates and may be defined with performance assurances such as CIR with an
associated CBS, EIR with an associated EBS, delay, delay variation, loss, and availability for a
given Class of Service (CoS) instance. Service Multiplexing may occur at one or both UNIs in
the EVC. For example, more than one Point-to-Point EVC may be offered on the same physical
port at one or both of the UNIs.

The E-Line Service type UNI service attributes, parameters, and values can be found in Table 3.

The E-Line Service type EVC per UNI service attributes, parameters, and values can be found in
Table 4 below. The first column of this table comes from [2]. The entries in the second column
define the E-Line Service type.
EVC per UNI Service
E-Line Service type Requirement
Attribute
A string formed by the concatenation of the UNI ID and the EVC
UNI EVC ID
ID.
MUST specify the mapping table of CE-VLAN IDs to the EVC at
CE-VLAN ID / EVC Map
the UNI.
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR,
Ingress Bandwidth Profile
EBS, CM, CF>. MUST NOT be combined with any other type of
Per EVC
ingress bandwidth profile.
OPTIONAL. If supported, MUST specify CoS ID per [2],
Ingress Bandwidth Profile section 6.8, and MUST specify <CIR, CBS, EIR, EBS, CM, CF>
Per CoS Identifier for each CoS. MUST NOT be combined with any other type of
ingress bandwidth profile.
Egress Bandwidth Profile
MUST NOT specify 3 .
Per EVC

3
For E-Line services, it is expected that an Ingress Bandwidth Profile will be applied at the ingress UNI such that
traffic on the EVC is already controlled; therefore, there is no need to apply an Egress Bandwidth Profile per EVC
or CoS at the egress UNI.
MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

EVC per UNI Service


E-Line Service type Requirement
Attribute
Egress Bandwidth Profile
MUST NOT specify.
Per CoS Identifier
Table 4: E-Line Service type EVC per UNI service attributes and parameter values
The E-Line Service type EVC service attributes, parameters, and values can be found in Table 5
below. The first column of this table comes from [2]. The entries in the second column define
the E-Line Service type.
EVC Service Attribute E-Line Service type Requirement
EVC Type MUST be Point-to-Point.
An arbitrary string, unique across the MEN, for the EVC
EVC ID
supporting the service instance.
MUST provide the list of UNI Identifiers and type for each UNI
UNI List
associated with the EVC. UNI Type must be Root for each UNI.
Maximum Number of
MUST be 2.
UNIs
EVC MTU size MUST be minimum of UNI MTU sizes.
CE-VLAN ID Preservation MUST be either Yes or No
CE-VLAN CoS
MUST be either Yes or No
Preservation
Unicast Service Frame Deliver Unconditionally or Deliver Conditionally. If Delivered
Delivery Conditionally, MUST specify the delivery criteria.
Multicast Service Frame Deliver Unconditionally or Deliver Conditionally. If Delivered
Delivery Conditionally, MUST specify the delivery criteria.
Broadcast Service Frame Deliver Unconditionally or Deliver Conditionally. If Delivered
Delivery Conditionally, MUST specify the delivery criteria.
Layer 2 Control Protocol
Processing (only applies For each protocol passed to the EVC, MUST specify one of:
for L2CPs passed to the Tunnel or Discard.
EVC)
At least one CoS is REQUIRED. MUST specify CoS ID, per
section 6.8 of [2]. MUST list values for each of the following
EVC Performance attributes {Frame Delay, Frame Delay Variation, Frame Loss
Ratio, and Availability} for each CoS, where Not Specified (N/S)
is an acceptable value.
Table 5: E-Line Service type EVC service attributes and parameter values
6.2 ETHERNET LAN (E-LAN) SERVICE TYPE

MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

Any Ethernet Service that is based upon a Multipoint-to-Multipoint EVC SHALL be designated
as an Ethernet LAN (E-LAN) Service type. The E-LAN service type is illustrated in Figure 3
below.
Multipoint-to-Multipoint EVC

UNI
UNI

UNI
UNI
Metro Ethernet
Network

Figure 3: E-LAN Service type using Multipoint-to-Multipoint EVC


An E-LAN Service type can be used to create a broad range of services. In its simplest form, an
E-LAN Service type can provide a best effort service with no performance assurances between
the UNIs. In more sophisticated forms, an E-LAN Service type may be defined with
performance assurances such as CIR with an associated CBS, EIR with an associated EBS,
delay, delay variation, loss, and availability for a given CoS instance.

For an E-LAN service type, service multiplexing may occur at none, one, or more than one of the
UNIs in the EVC. For example, an E-LAN Service type (Multipoint-to-Multipoint EVC) and an
E-Line service type (Point-to-Point EVC) may be service multiplexed at the same UNI. In this
example, the E-LAN service type may be used to interconnect other Subscriber sites while the E-
Line service type is used to connect to the Internet with both services offered via service
multiplexing at the same UNI.

The E-LAN service type UNI Service Attributes and requirements can be found in Table 3.

The E-LAN service type EVC per UNI Service Attributes and requirements can be found in
Table 6 below. The first column of this table comes from [2]. The entries in the second column
define the E-LAN Service type.

EVC per UNI Service


E-LAN Service type Requirement
Attribute
A string formed by the concatenation of the UNI ID and the EVC
UNI EVC ID
ID.
MUST specify the mapping table of CE-VLAN IDs to the EVC at
CE-VLAN ID / EVC Map
the UNI.
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR, EBS,
Ingress Bandwidth Profile
CM, CF> [2]. MUST NOT be combined with any other type of
Per EVC
ingress bandwidth profile.
MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

EVC per UNI Service


E-LAN Service type Requirement
Attribute
OPTIONAL. If supported, MUST specify CoS ID per [2], section
Ingress Bandwidth Profile 6.8, and MUST specify <CIR, CBS, EIR, EBS, CM, CF> for each
Per CoS Identifier CoS. MUST NOT be combined with any other type of ingress
bandwidth profile.
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR, EBS,
Egress Bandwidth Profile
CM, CF> [2]. MUST NOT be combined with any other type of
Per EVC
egress bandwidth profile.
OPTIONAL. If supported, MUST specify CoS ID per [2], section
Egress Bandwidth Profile 6.8, and MUST specify <CIR, CBS, EIR, EBS, CM, CF> for each
Per CoS Identifier CoS. MUST NOT be combined with any other type of egress
bandwidth profile.
Table 6 : E-LAN Service type EVC per UNI service attributes and parameter values
The E-LAN service type EVC service attributes, parameters, and values can be found in Table 7
below. The first column of this table comes from [2]. The entries in the second column define
the E-LAN Service type.

EVC Service Attribute E-LAN Service type Requirement


EVC Type MUST be Multipoint-to-Multipoint.
An arbitrary string, unique across the MEN, for the EVC
EVC ID
supporting the service instance.
MUST provide the list of UNI Identifiers and type for each UNI
UNI List
associated with the EVC. UNI Type must be Root for each UNI
Maximum Number of UNIs MUST be 2.
EVC MTU size MUST be minimum of UNI MTU sizes.
CE-VLAN ID Preservation MUST be either Yes or No
CE-VLAN CoS
MUST be either Yes or No
Preservation
Unicast Service Frame Deliver Unconditionally or Deliver Conditionally. If Delivered
Delivery Conditionally, MUST specify the delivery criteria.
Multicast Service Frame Deliver Unconditionally or Deliver Conditionally. If Delivered
Delivery Conditionally, MUST specify the delivery criteria.
Broadcast Service Frame Deliver Unconditionally or Deliver Conditionally. If Delivered
Delivery Conditionally, MUST specify the delivery criteria.

MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

EVC Service Attribute E-LAN Service type Requirement


Layer 2 Control Protocol
For each protocol passed to the EVC, MUST specify one of:
Processing (only applies for
Tunnel or Discard.
L2CPs passed to the EVC)
At least one CoS is REQUIRED. MUST specify CoS ID, per
section 6.8 of [2]. MUST list values for each of the following
EVC Performance attributes {Frame Delay, Frame Delay Variation, Frame Loss
Ratio, and Availability} for each CoS, where Not Specified (N/S)
is an acceptable value.
Table 7: E-LAN Service type EVC service attributes and parameter values
6.3 ETHERNET TREE (E-TREE) SERVICE TYPE
Any Ethernet Service that is based upon a Rooted-Multipoint Ethernet Virtual Connection, as
defined in MEF 10.1, SHALL be designated as an Ethernet Tree (E-Tree) Service type. The E-
Tree service type with a single Root is illustrated in Figure 4.
Rooted
Multipoint EVC Root UNI

Root UNI

Leaf UNI
Leaf UNI

Leaf UNI Metro Ethernet Leaf UNI


Network

Figure 4: E-Tree Service type using Rooted-Multipoint EVC


In its simplest form, an E-Tree Service type can provide a single Root for multiple Leaf UNIs.
Each Leaf UNI can exchange data with only the Root UNI. A service frame sent from one Leaf
UNI with a destination address for another Leaf UNI is not delivered. This service could be
useful for Internet Access or Video over IP applications, such as multicast/broadcast packet
video. One or more than one CoS may be associated with this service.

In more sophisticated forms, an E-Tree Service type may support two or more Root UNIs. In
this scenario, each Leaf UNI can exchange data only with the Root UNIs. As well, the Roots can
communicate with each other. In such a service, redundant access to the Root can also be
provided, effectively allowing for enhanced service reliability and flexibility. This service is
depicted in Figure 5 below.

MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

Root UNI Root UNI

Rooted-
Multipoint EVC

To Leaf UNIs

Figure 5: E-Tree Service type using Multiple Roots


For an E-Tree service type, service multiplexing may occur at none, one, or more than one of the
UNIs in the EVC. For example, an E-Tree service type, using a Rooted-Multipoint EVC, and an
E-Line service type, using a Point-to-Point EVC, may be service multiplexed at the same UNI.
In this example, the E-Tree service type may be used to support a specific application at the
Subscriber UNI, e.g., ISP access to redundant PoPs (multiple Roots at ISP PoPs), while the E-
Line Service type is used to connect to another enterprise site with a Point-to-Point EVC.

The E-Tree service type UNI Service Attributes and requirements can be found in Table 3.

The E-Tree service type EVC per UNI service attributes and requirements can be found in Table
8 below. The first column of this table comes from [2]. The entries in the second column define
the E-Tree Service type.
EVC per UNI
E-Tree EVC per UNI Service type Requirement
Service Attribute
UNI EVC ID A string formed by the concatenation of the UNI ID and the EVC ID.
CE-VLAN ID / EVC MUST specify the mapping table of CE-VLAN IDs to the EVC at the
Map UNI.
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR, EBS, CM,
Ingress Bandwidth
CF> [2]. MUST NOT be allowed if any other ingress bandwidth
Profile Per EVC
profile is applied at this UNI for this EVC.
OPTIONAL. If supported, MUST specify CoS ID per [2], section 6.8,
Ingress Bandwidth
and MUST specify <CIR, CBS, EIR, EBS, CM, CF> for each CoS.
Profile Per CoS
MUST NOT be combined with any other type of ingress bandwidth
Identifier
profile.
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR, EBS, CM,
Egress Bandwidth
CF> [2]. MUST NOT be combined with any other type of egress
Profile Per EVC
bandwidth profile.
OPTIONAL. If supported, MUST specify CoS ID per [2], section 6.8,
Egress Bandwidth
and MUST specify <CIR, CBS, EIR, EBS, CM, CF> for each CoS.
Profile Per CoS
MUST NOT be combined with any other type of egress bandwidth
Identifier
profile.

MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

Table 8 : E-Tree Service type EVC per UNI service attributes and parameter values
The E-Tree service type EVC service attributes, parameters, and values can be found in Table 9
below. The first column of this table comes from [2]. The entries in the second column define
the E-Tree Service type.
EVC Service Attribute E-Tree EVC Service type Requirement
EVC Type MUST be Rooted-Multipoint
An arbitrary string, unique across the MEN, for the EVC supporting
EVC ID
the service instance.
MUST provide the list of UNI Identifiers and type for each UNI
UNI List associated with the EVC. The number of Root UNIs in the list
MUST be 1. The number of Leaf UNIs in the list MUST be 0 4 .
Maximum Number of
MUST be 2
UNIs
EVC MTU size MUST be minimum of UNI MTU sizes.
CE-VLAN ID
MUST be either Yes or No
Preservation
CE-VLAN CoS
MUST be either Yes or No
Preservation
Unicast Service Frame Deliver Unconditionally or Deliver Conditionally. If Delivered
Delivery Conditionally, MUST specify the delivery criteria.
Multicast Service Frame Deliver Unconditionally or Deliver Conditionally. If Delivered
Delivery Conditionally, MUST specify the delivery criteria.
Broadcast Service Frame Deliver Unconditionally or Deliver Conditionally. If Delivered
Delivery Conditionally, MUST specify the delivery criteria.
Layer 2 Control Protocol
Processing (only applies For each protocol passed to the EVC, MUST specify one of: Tunnel
for L2CPs passed to the or Discard
EVC)
At least one CoS is REQUIRED. MUST specify CoS ID, per
section 6.8 of [2]. MUST list values for each of the following
EVC Performance attributes {Frame Delay, Frame Delay Variation, Frame Loss Ratio,
and Availability} for each CoS, where Not Specified (N/S) is an
acceptable value.
Table 9: E-Tree Service type EVC service attributes and parameter values
7. Service Definitions (Normative)
An Ethernet service is defined by specifying service attribute parameter values for a given
Ethernet Service type. This section defines the required service attributes and related parameter
values for the Ethernet services specified in this Technical Specification. If any of the Ethernet

4
An E-Tree service may have no leaves, for example, during times when leaf UNIs are being added or removed.
MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

services in this section are offered, the normative text for each service attribute is applied. Note
that other variations of these Ethernet services are also possible.

7.1 ETHERNET PRIVATE LINE SERVICE


An Ethernet Private Line (EPL) service is specified using an E-Line Service type. An EPL
service uses a Point-to-Point EVC between two UNIs and provides a high degree of transparency
for Service Frames between the UNIs it interconnects such that the Service Frames header and
payload are identical at both the source and destination UNI when a Service Frame is delivered.
Figure 6 below shows the basic structure of EPL service.
Metro Ethernet Network
CE CE
P2P EVC

UNI UNI

Figure 6: Ethernet Private Line (EPL) Service


EPL service does not allow for Service Multiplexing, i.e., a dedicated UNI (physical interface) is
used for the service. Because of the high degree of transparency of this service, there is no need
for coordination between the Subscriber and Service Provider on a detailed CE-VLAN ID/EVC
Map for each UNI because all Service Frames are mapped to a single EVC at the UNI. Refer to
[2] for more information on CE-VLAN ID/EVC Map attribute.

For cases where EVC speed is less than the UNI speed, the CE is expected to shape traffic to the
Ingress Bandwidth Profile of the service such that all of its traffic, including certain L2CPs that
require delivery for proper operation, is not discarded by the service.

Table 10 provides the UNI service attributes, parameters, and values for the Ethernet Private
Line.
UNI Service Attribute Service Attribute Parameters and Values
UNI Identifier Arbitrary text string to identify the UNI.
Physical Medium UNI Type 2 Physical Interface [5] except for PON interfaces
10 Mbps, 100 Mbps, 10/100 Mbps Auto-negotiation,
Speed
10/100/1000 Mbps Auto-negotiation, 1 Gbps, or 10 Gbps
Mode MUST be Full Duplex
MAC Layer IEEE 802.3-2005 [5]
UNI MTU Size MUST be 1522
Service Multiplexing MUST be No
Bundling MUST be No
All to One Bundling MUST be Yes

MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

UNI Service Attribute Service Attribute Parameters and Values


CE-VLAN ID for untagged All untagged and priority tagged Service Frames at the UNI
and priority tagged Service MUST map to the same EVC as is used for all other Service
Frames Frames.
Maximum number of EVCs MUST be 1
Ingress Bandwidth Profile Per
MUST NOT specify 5
UNI
Egress Bandwidth Profile Per
MUST NOT specify
UNI
Layer 2 Control Protocol
MUST specify in accordance with Section 8.1 of this document.
Processing
Table 10: UNI service attributes and parameters for the EPL service
Table 11 provides the EVC per UNI service attributes, parameters, and values for the Ethernet
Private Line (EPL) service.
EVC per UNI Service
Service Attribute Parameters and Values
Attribute
A string formed by the concatenation of the UNI ID and the
UNI EVC ID
EVC ID.
All Service Frames at the UNI MUST map to a single Point-to-
CE-VLAN ID / EVC Map
Point EVC.
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR,
Ingress Bandwidth Profile Per
EBS, CM, CF>. MUST NOT be combined with any other type
EVC
of ingress bandwidth profile.
OPTIONAL. If supported, MUST specify CoS ID per [2],
Ingress Bandwidth Profile Per section 6.8, and MUST specify <CIR, CBS, EIR, EBS, CM,
CoS ID CF> for each CoS. MUST NOT be combined with any other
type of ingress bandwidth profile
Egress Bandwidth Profile Per
MUST NOT specify
EVC
Egress Bandwidth Profile Per
MUST NOT specify
CoS ID
Table 11: EVC per UNI service attributes and parameters for the EPL service
Table 12 provides the EVC service attributes, parameters, and values for the Ethernet Private
Line (EPL) service.
EVC Service Attribute Service Attribute Parameters and Values
EVC Type MUST be Point-to-Point
An arbitrary string, unique across the MEN, for the EVC
EVC ID
supporting the service instance.

5
See Ingress Bandwidth Profile per EVC service attribute in Table 11.
MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

EVC Service Attribute Service Attribute Parameters and Values


MUST list the two UNIs associated with the EVC. The UNI
UNI List
type MUST be Root for each UNI.
Maximum Number of UNIs MUST be 2
EVC MTU size MUST be 1522
CE-VLAN ID Preservation MUST be Yes
CE-VLAN CoS Preservation MUST be Yes
Unicast Service Frame
MUST Deliver Unconditionally
Delivery
Multicast Service Frame
MUST Deliver Unconditionally
Delivery
Broadcast Service Frame
MUST Deliver Unconditionally
Delivery
Layer 2 Control Protocols
Processing (only applies for MUST specify in accordance with Section 8.1 of this document.
L2CPs passed to the EVC)
At least one CoS is REQUIRED. MUST specify CoS ID, per
section 6.8 of [2]. MUST list values for each of the following
EVC Performance attributes {Frame Delay, Frame Delay Variation, Frame Loss
Ratio, and Availability} for each CoS, where Not Specified
(N/S) is an acceptable value.
Table 12: EVC service attributes and parameters for the EPL service
The definition of EPL in this document is somewhat different than the superseded definition of
EPL that was given in MEF 6 [1]. In addition to changes to the Layer 2 Control Protocol
processing requirements (see Section 8), the other key differences are captured in Table 13.
Attribute EPL in this Document EPL in MEF 6 [1]
Bandwidth Profile Parameter Values EIR 0, EBS 0 EIR = 0, EBS = 0
Classes of Service Multiple allowed One allowed
Table 13: Differences in EPL from EPL in MEF 6
7.2 ETHERNET VIRTUAL PRIVATE LINE SERVICE

MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

An Ethernet Virtual Private Line (EVPL) is created using an E-Line Service type. An EVPL can
be used to create services similar to the Ethernet Private Line (EPL) with some notable exceptions.
First, an EVPL allows for service multiplexing at the UNI. This capability allows more than one
EVC to be supported at the UNI where the EPL does not allow this. Second, an EVPL need not
provide as much transparency of Service Frames as with an EPL. Because service multiplexing is
permitted, some Service Frames may be sent to one EVC while other Service Frames may be sent to
other EVCs.
Service
Multiplexing

Blue
EVC
Yellow Green
EVC EVC
Metro Ethernet
Network

Figure 7 below shows the basic structure of EVPL service.

Service
Multiplexing

Blue
EVC
Yellow Green
EVC EVC
Metro Ethernet
Network

Figure 7: Ethernet Virtual Private Line (EVPL) Service


Table 14 provides the UNI service attributes, parameters, and values for the Ethernet Virtual
Private Line (EVPL) using the E-Line Service type.
UNI Service Attribute Service Attribute Parameters and Values
UNI Identifier Arbitrary text string to identify the UNI.
Physical Medium UNI Type 2 Physical Interface [5] except for PON interfaces
10 Mbps, 100 Mbps, 10/100 Mbps Auto-negotiation,
Speed
10/100/1000 Mbps Auto-negotiation, 1 Gbps, or 10 Gbps
Mode MUST be Full Duplex
MAC Layer IEEE 802.3-2005 [5]
UNI MTU Size MUST be 1522
Service Multiplexing SHOULD be supported at one or more UNIs.
Yes or No. If Yes, then CE-VLAN ID Preservation MUST be
Bundling
Yes.
All to One Bundling MUST be No

MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

UNI Service Attribute Service Attribute Parameters and Values


CE-VLAN ID for untagged MUST specify CE-VLAN ID for untagged and priority tagged
and priority tagged Service Service Frames in the range of 1-4094.
Frames
Maximum number of EVCs MUST be 1
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR,
Ingress Bandwidth Profile Per
EBS, CM, CF>. MUST NOT be combined with any other type
UNI
of ingress bandwidth profile.
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR,
Egress Bandwidth Profile Per
EBS, CM, CF>. MUST NOT be combined with any other type
UNI
of egress bandwidth profile.
Layer 2 Control Protocol
MUST specify in accordance with Section 8.2 of this document.
Processing
Table 14: UNI service attributes and parameters for EVPL service
Table 15 provides the EVC per UNI service attributes, parameters, and values for the Ethernet
Virtual Private Line (EVPL) using the E-Line Service type.
EVC per UNI Service
Service Attribute Parameters and Values
Attribute
A string formed by the concatenation of the UNI ID and the
UNI EVC ID
EVC ID.
CE-VLAN ID / EVC Map MUST specify mapping table of CE-VLAN IDs to the EVC ID.
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR,
Ingress Bandwidth Profile Per
EBS, CM, CF>. MUST NOT be combined with any other type
EVC
of ingress bandwidth profile.
OPTIONAL. If supported, MUST specify CoS ID per [2],
Ingress Bandwidth Profile Per section 6.8, and MUST specify <CIR, CBS, EIR, EBS, CM,
CoS ID CF> for each CoS. MUST NOT be combined with any other
type of ingress bandwidth profile.
Egress Bandwidth Profile Per
MUST be No
EVC
Egress Bandwidth Profile Per
MUST be No
CoS ID
Table 15: EVC per UNI service attributes and parameters for EVPL service
Table 16 provides the EVC service attributes, parameters, and values for the Ethernet Virtual
Private Line (EVPL) using the E-Line Service type.
EVC Service Attribute Service Attribute Parameters and Values
EVC Type MUST be Point-to-Point
An arbitrary string, unique across the MEN, for the EVC
EVC ID
supporting the service instance.

MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

EVC Service Attribute Service Attribute Parameters and Values


MUST list the two UNIs associated with the EVC. The UNI
UNI List
type MUST be Root for each UNI.
Maximum Number of UNIs MUST be 2
EVC MTU size MUST be 1522
CE-VLAN ID Preservation MUST be either Yes or No
CE-VLAN CoS Preservation MUST be either Yes or No
Unicast Service Frame Deliver Unconditionally or Deliver Conditionally. If Delivered
Delivery Conditionally, MUST specify the delivery criteria.
Multicast Service Frame Deliver Unconditionally or Deliver Conditionally. If Delivered
Delivery Conditionally, MUST specify the delivery criteria.
Broadcast Service Frame Deliver Unconditionally or Deliver Conditionally. If Delivered
Delivery Conditionally, MUST specify the delivery criteria.
Layer 2 Control Protocols
Processing (only applies for MUST specify in accordance with Section 8.2 of this document.
L2CPs passed to the EVC)
At least one CoS is REQUIRED. MUST specify CoS ID, per
section 6.8 of [2]. MUST list values for each of the following
EVC Performance attributes {Frame Delay, Frame Delay Variation, Frame Loss
Ratio, and Availability} for each CoS, where Not Specified
(N/S) is an acceptable value.
Table 16: EVC service attributes and parameters for the EVPL service
The definition of EVPL in this document is somewhat different than the definition of EVPL used
in MEF 6 [1]. The key differences are captured in Table 17.
Attribute EVPL in this Document EVPL in MEF 6 [1]
All to One Bundling Must be No May be Yes or No
Table 17: Differences in EVPL from EVPL in MEF 6
7.3 ETHERNET PRIVATE LAN SERVICE
Subscribers with multiple sites often want to interconnect them at high speeds so all sites appear
to be on the same Local Area Network (LAN) and have equivalent performance and access to
resources such as servers and storage. Subscribers commonly desire a highly transparent service
that connects multiple UNIs. To this end, the Ethernet Private LAN (EP-LAN) service is defined
in this subsection, using the E-LAN service type.
The EP-LAN service is defined to provide CE-VLAN tag preservation and tunneling of key Layer 2
Control Protocols. A key advantage of this approach is that the Subscriber can configure VLANs
across the sites without any need to coordinate with the Service Provider. Each interface is
configured for All to One Bundling and, therefore, EP-LAN service supports CE-VLAN ID

MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

preservation. In addition, EP-LAN supports CE-VLAN CoS preservation.

MP2MP EVC

Metro Ethernet
Network

Figure 8 below shows the basic structure of EP-LAN service.

MP2MP EVC

Metro Ethernet
Network

Figure 8: Ethernet Private LAN (EP-LAN) Service


Table 18 provides the UNI service attributes, parameters, and values for the EP-LAN service.
UNI Service Attribute Service Attribute Parameters and Values
UNI Identifier Arbitrary text string to identify the UNI.
Physical Medium UNI Type 2 Physical Interface [5] except for PON interfaces
10 Mbps, 100 Mbps, 10/100 Mbps Auto-negotiation,
Speed
10/100/1000 Mbps Auto-negotiation, 1 Gbps, or 10 Gbps
Mode MUST be Full Duplex
MAC Layer IEEE 802.3-2005 [5]
UNI MTU Size MUST be 1522
Service Multiplexing MUST be No
Bundling MUST be No
All to One Bundling MUST be Yes
CE-VLAN ID for untagged All untagged and priority tagged Service Frames at the UNI
and priority tagged Service MUST map to the same EVC as is used for all other Service
Frames Frames.
Maximum number of EVCs MUST be 1
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR,
Ingress Bandwidth Profile Per
EBS, CM, CF>. MUST NOT be combined with any other type
UNI
of ingress bandwidth profile.

MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

UNI Service Attribute Service Attribute Parameters and Values


OPTIONAL. If supported, MUST specify <CIR, CBS, EIR,
Egress Bandwidth Profile Per
EBS, CM, CF>. MUST NOT be combined with any other type
UNI
of egress bandwidth profile.
Layer 2 Control Protocol MUST specify in accordance with Section 8.3 of this
Processing document.
Table 18: UNI service attributes and parameters for the EP-LAN service
Table 19 provides the EVC per UNI service attributes, parameters, and values for the EP-LAN
service.
EVC per UNI Service
Service Attribute Parameters and Values
Attribute
A string formed by the concatenation of the UNI ID and the
UNI EVC ID
EVC ID.
All Service Frames at the UNI MUST map to a single
CE-VLAN ID / EVC Map
Multipoint-to-Multipoint EVC.
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR,
Ingress Bandwidth Profile Per
EBS, CM, CF>. MUST NOT be combined with any other type
EVC
of ingress bandwidth profile.
OPTIONAL. If supported, MUST specify CoS ID per [2],
Ingress Bandwidth Profile Per section 6.8, and MUST specify <CIR, CBS, EIR, EBS, CM,
CoS ID CF> for each CoS. MUST NOT be combined with any other
type of ingress bandwidth profile.
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR,
Egress Bandwidth Profile Per
EBS, CM, CF>. MUST NOT be combined with any other type
EVC
of egress bandwidth profile.
OPTIONAL. If supported, MUST specify CoS ID per [2],
Egress Bandwidth Profile Per section 6.8, and MUST specify <CIR, CBS, EIR, EBS, CM,
CoS ID CF> for each CoS. MUST NOT be combined with any other
type of egress bandwidth profile.
Table 19: EVC per UNI service attributes and parameters for the EP-LAN service
Table 20 provides the EVC service attributes, parameters, and values for the EP-LAN service.
EVC Service Attribute Service Attribute Parameters and Values
EVC Type MUST be Multipoint-to-Multipoint
An arbitrary string, unique across the MEN, for the EVC
EVC ID
supporting the service instance.
MUST list the UNIs associated with the EVC. The UNI type
UNI List
MUST be Root for each UNI.
Maximum Number of UNIs MUST be 2
EVC MTU size MUST be 1522.

MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

EVC Service Attribute Service Attribute Parameters and Values


CE-VLAN ID Preservation MUST be Yes
CE-VLAN CoS Preservation MUST be Yes
Unicast Service Frame Deliver Unconditionally or Deliver Conditionally. If Delivered
Delivery Conditionally, MUST specify the delivery criteria.
Multicast Service Frame Deliver Unconditionally or Deliver Conditionally. If Delivered
Delivery Conditionally, MUST specify the delivery criteria.
Broadcast Service Frame Deliver Unconditionally or Deliver Conditionally. If Delivered
Delivery Conditionally, MUST specify the delivery criteria.
Layer 2 Control Protocols
Processing (only applies for MUST specify in accordance with Section 8.3 of this document.
L2CPs passed to the EVC)
At least one CoS is REQUIRED. MUST specify CoS ID, per
section 6.8 of [2]. For each CoS, MUST list values for each of
the following attributes {Frame Delay, Frame Delay Variation,
EVC Performance Frame Loss Ratio, and Availability}, where Not Specified (N/S)
is an acceptable value, for one or more sets of ordered UNI
pairs. Each ordered UNI pair in the EVC MUST be mapped to
at least one CoS.
Table 20: EVC service attributes and parameters for the EP-LAN service
7.4 ETHERNET VIRTUAL PRIVATE LAN SERVICE
Some Subscribers commonly desire an E-LAN service type to connect their UNIs in a metro
network, while at the same time accessing other services from one or more of those UNIs. An
example of such a UNI is a Subscriber site that wants to access a public or private IP service
from a UNI that is also used to for E-LAN service among the Subscribers several metro
locations. We define the Ethernet Virtual Private LAN (EVP-LAN) service in this subsection to
address this need.

Bundling may or may not be used on the UNIs in the Multipoint-to-Multipoint EVC. As such,
CE-VLAN tag preservation and tunneling of certain Layer 2 Control Protocols may or may not
be provided. Figure 9 below shows the basic structure of EVP-LAN service. In this example,
the customer uses an EVP-LAN Service (red EVC) for providing multipoint data connectivity,
and an EVPL Service (blue EVC) for accessing value-add services from one of the UNIs.

MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

Value-add
Service
P2P EVC

MP2MP EVC

Metro Ethernet
Network

Figure 9: Ethernet Virtual Private LAN (EVP-LAN) Service


Table 21 provides the UNI service attributes, parameters, and values for the EVP-LAN service.
UNI Service Attribute Service Attribute Parameters and Values
UNI Identifier Arbitrary text string to identify the UNI.
Physical Medium UNI Type 2 Physical Interface [5] except for PON interfaces
10 Mbps, 100 Mbps, 10/100 Mbps Auto-negotiation,
Speed
10/100/1000 Mbps Auto-negotiation, 1 Gbps, or 10 Gbps
Mode MUST be Full Duplex
MAC Layer IEEE 802.3-2005 [5]
UNI MTU Size MUST be 1522
Service Multiplexing SHOULD be supported at one or more UNIs.
Yes or No. If Yes, then CE-VLAN ID Preservation MUST be
Bundling
Yes.
All to One Bundling MUST be No
CE-VLAN ID for untagged MUST specify CE-VLAN ID for untagged and priority tagged
and priority tagged Service Service Frames in the range of 1-4094.
Frames
Maximum number of EVCs MUST be 1
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR,
Ingress Bandwidth Profile Per
EBS, CM, CF>. MUST NOT be combined with any other type
UNI
of ingress bandwidth profile.
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR,
Egress Bandwidth Profile Per
EBS, CM, CF>. MUST NOT be combined with any other type
UNI
of egress bandwidth profile.
Layer 2 Control Protocol
MUST specify in accordance with Section 8.4 of this document.
Processing
Table 21: UNI service attributes and parameters for the EVP-LAN service
Table 22 provides the EVC per UNI service attributes, parameters, and values for the EVP-LAN
service.

MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

EVC per UNI Service


Service Attribute Parameters and Values
Attribute
A string formed by the concatenation of the UNI ID and the
UNI EVC ID
EVC ID.
CE-VLAN ID / EVC Map MUST specify mapping table of CE-VLAN IDs to the EVC ID.
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR,
Ingress Bandwidth Profile Per
EBS, CM, CF>. MUST NOT be combined with any other
EVC
ingress bandwidth profile is applied at this UNI for this EVC.
OPTIONAL. If supported, MUST specify CoS ID per [2],
Ingress Bandwidth Profile Per section 6.8, and MUST specify <CIR, CBS, EIR, EBS, CM,
CoS ID CF> for each CoS. MUST NOT be combined with any other
type of Ingress Bandwidth Profile.
OPTIONAL. MUST specify <CIR, CBS, EIR, EBS, CM, CF>
Egress Bandwidth Profile Per
for each CoS. MUST NOT be combined with any other type of
EVC
egress bandwidth profile.
OPTIONAL. If supported, MUST specify CoS ID per [2],
Egress Bandwidth Profile Per section 6.8, and MUST specify <CIR, CBS, EIR, EBS, CM,
CoS ID CF>. MUST NOT be combined with any other type of egress
bandwidth profile.
Table 22: EVC per UNI service attributes and parameters for the EVP-LAN service
Table 23 provides the EVC service attributes, parameters, and values for the EVP-LAN service.
EVC Service Attribute Service Attribute Parameters and Values
EVC Type MUST be Multipoint-to-Multipoint
An arbitrary string, unique across the MEN, for the EVC
EVC ID
supporting the service instance.
MUST list the UNIs associated with the EVC. The UNI type
UNI List
MUST be Root for each UNI.
Maximum Number of UNIs MUST be 2
EVC MTU size MUST be 1522
CE-VLAN ID Preservation MUST be either Yes or No
CE-VLAN CoS Preservation MUST be either Yes or No
Unicast Service Frame Deliver Unconditionally or Deliver Conditionally. If Delivered
Delivery Conditionally, MUST specify the delivery criteria.
Multicast Service Frame Deliver Unconditionally or Deliver Conditionally. If Delivered
Delivery Conditionally, MUST specify the delivery criteria.
Broadcast Service Frame Deliver Unconditionally or Deliver Conditionally. If Delivered
Delivery Conditionally, MUST specify the delivery criteria.

MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

EVC Service Attribute Service Attribute Parameters and Values


Layer 2 Control Protocols
Processing (only applies for MUST specify in accordance with Section 8.4 of this document.
L2CPs passed to the EVC)
At least one CoS is REQUIRED. MUST specify CoS ID, per
section 6.8 of [2]. For each CoS, MUST list values for each of
the following attributes {Frame Delay, Frame Delay Variation,
EVC Performance Frame Loss Ratio, and Availability}, where Not Specified (N/S)
is an acceptable value, for one or more sets of ordered UNI
pairs. Each ordered UNI pair in the EVC MUST be mapped to
at least one CoS.
Table 23: EVC service attributes and parameters for the EVP-LAN service
7.5 ETHERNET PRIVATE TREE SERVICE
Subscribers with multiple sites may want to interconnect them to provide services other than
those that resemble a LAN. These services may be distributed from a centralized site (or few
such sites) where the distribution site is designated as a Root and all the remaining sites are
designated as leaves.
The EP-Tree service is defined to provide CE-VLAN tag preservation and tunneling of key Layer 2
Control Protocols. A key advantage of this approach is that the Subscriber can configure VLANs
across the sites without any need to coordinate with the Service Provider. Each interface is
configured for All to One Bundling and, therefore, EP-Tree service supports CE-VLAN ID
preservation. In addition, EP-Tree supports CE-VLAN CoS preservation.

RMP EVC

Metro Ethernet
Network

Figure 10 below shows the basic structure of EP-Tree service.

RMP EVC

Metro Ethernet
Network

Figure 10: Ethernet Private Tree (EP-Tree) Service


Table 24 provides the UNI service attributes, parameters, and values for the EP- Tree service.

MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

UNI Service Attribute Service Attribute Parameters and Values


UNI Identifier Arbitrary text string to identify the UNI.
Physical Medium UNI Type 2 Physical Interface [5] except for PON interfaces
10 Mbps, 100 Mbps, 10/100 Mbps Auto-negotiation,
Speed
10/100/1000 Mbps Auto-negotiation, 1 Gbps, or 10 Gbps
Mode MUST be Full Duplex
MAC Layer IEEE 802.3-2005 [5]
UNI MTU Size MUST be 1522
Service Multiplexing MUST be No
Bundling MUST be No
All to One Bundling MUST be Yes
CE-VLAN ID for untagged All untagged and priority tagged Service Frames at the UNI
and priority tagged Service MUST map to the same EVC as is used for all other Service
Frames Frames.
Maximum number of EVCs MUST be 1
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR,
Ingress Bandwidth Profile Per
EBS, CM, CF>. MUST NOT combined with any other type of
UNI
ingress bandwidth profile.
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR,
Egress Bandwidth Profile Per
EBS, CM, CF>. MUST NOT be combined with any other type
UNI
of egress bandwidth profile.
Layer 2 Control Protocol
MUST specify in accordance with Section 8.5 of this document.
Processing
Table 24: UNI service attributes and parameters for the EP-Tree service
Table 25 provides the EVC per UNI service attributes, parameters, and values for the EP- Tree
service.
EVC per UNI Service
Service Attribute Parameters and Values
Attribute
A string formed by the concatenation of the UNI ID and the
UNI EVC ID
EVC ID.
All Service Frames at the UNI MUST map to the Rooted-
CE-VLAN ID / EVC Map
Multipoint EVC.
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR,
Ingress Bandwidth Profile Per
EBS, CM, CF>. MUST NOT be combined with any other type
EVC
of ingress bandwidth profile.
OPTIONAL. If supported, MUST specify CoS ID per [2],
Ingress Bandwidth Profile Per section 6.8, and MUST specify <CIR, CBS, EIR, EBS, CM,
CoS ID CF> for each CoS. MUST NOT be combined with any other
type of ingress bandwidth profile.

MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

EVC per UNI Service


Service Attribute Parameters and Values
Attribute
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR,
Egress Bandwidth Profile Per
EBS, CM, CF>. MUST NOT be combined with any other type
EVC
of egress bandwidth profile.
OPTIONAL. If supported, MUST specify CoS ID per [2],
Egress Bandwidth Profile Per section 6.8, and MUST specify <CIR, CBS, EIR, EBS, CM,
CoS ID CF> for each CoS. MUST NOT be combined with any other
type of egress bandwidth profile.
Table 25: EVC per UNI service attributes and parameters for the EP-Tree service
Table 26 provides the EVC service attributes, parameters, and values for the EP-Tree service.
EVC Service Attribute Service Attribute Parameters and Values
EVC Type MUST be Rooted-Multipoint
An arbitrary string, unique across the MEN, for the EVC
EVC ID
supporting the service instance.
MUST list the UNIs associated with the EVC. The UNI Type
UNI List for at least 1 UNI MUST be Root. All UNIs that are not UNI
Type Root MUST be UNI Type Leaf.
Maximum Number of UNIs MUST be 2
EVC MTU size MUST be 1522
CE-VLAN ID Preservation MUST be Yes
CE-VLAN CoS Preservation MUST be Yes
Unicast Service Frame Deliver Unconditionally or Deliver Conditionally. If Delivered
Delivery Conditionally, MUST specify the delivery criteria.
Multicast Service Frame Deliver Unconditionally or Deliver Conditionally. If Delivered
Delivery Conditionally, MUST specify the delivery criteria.
Broadcast Service Frame Deliver Unconditionally or Deliver Conditionally. If Delivered
Delivery Conditionally, MUST specify the delivery criteria.
Layer 2 Control Protocols
Processing (only applies for MUST specify in accordance with Section 8.5 of this document.
L2CP frames passed to the EVC)
At least one CoS is REQUIRED. MUST specify CoS ID, per
section 6.8 of [2]. For each CoS, MUST list values for each of
the following attributes {Frame Delay, Frame Delay Variation,
Frame Loss Ratio, and Availability}, where Not Specified (N/S)
EVC Performance
is an acceptable value, for one or more sets of ordered UNI pairs
where each ordered pair contains at least one Root UNI. Each
ordered UNI pair containing at least one Root UNI in the EVC
MUST be mapped to at least one CoS.

MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

Table 26: EVC service attributes and parameters for the EP-Tree service
7.6 ETHERNET VIRTUAL PRIVATE TREE SERVICE
Some subscribers desire access to certain applications or content services from well-defined
access points within their own (or an external) network. In this case it is necessary to
interconnect the participating UNIs in a Rooted-Multipoint connection to the well-defined access
(or root) point. One or more of the Subscribers UNIs may also support other services, e.g.,
EVPL or EVP-LAN. For such cases, the EVP-Tree service is used.

Bundling may or may not be used on the UNIs in the Rooted-Multipoint EVC. As such, CE-
VLAN tag preservation and tunneling of certain Layer 2 Control Protocols may or may not be
provided. Figure 11 below shows the basic structure of EVP-Tree service. In this example, a
customer has EVP-LAN service (red EVC) providing data connectivity among three UNIs, while
using EVP-Tree service (green EVC) for providing video broadcast from a video hub location.

RMP EVC MP2MP EVC

Metro Ethernet
Network

Figure 11: Ethernet Virtual Private Tree (EVP-Tree) Service


Table 27 provides the UNI service attributes, parameters, and values for the EVP-Tree service.
UNI Service Attribute Service Attribute Parameters and Values
UNI Identifier Arbitrary text string to identify the UNI.
Physical Medium UNI Type 2 Physical Interface [5] except for PON interfaces
10 Mbps, 100 Mbps, 10/100 Mbps Auto-negotiation,
Speed
10/100/1000 Mbps Auto-negotiation, 1 Gbps, or 10 Gbps
Mode MUST be Full Duplex
MAC Layer IEEE 802.3-2005 [5]
UNI MTU Size MUST be 1522
Service Multiplexing SHOULD be supported at one or more UNIs.
Yes or No. If Yes, then CE-VLAN ID Preservation MUST be
Bundling
Yes.
All to One Bundling MUST be No
CE-VLAN ID for untagged MUST specify CE-VLAN ID for untagged and priority tagged
and priority tagged Service Service Frames in the range of 1-4094.
Frames
Maximum number of EVCs MUST be 1

MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

UNI Service Attribute Service Attribute Parameters and Values


OPTIONAL. If supported, MUST specify <CIR, CBS, EIR,
Ingress Bandwidth Profile Per
EBS, CM, CF>. MUST NOT be combined with any other type
UNI
of ingress bandwidth profile.
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR,
Egress Bandwidth Profile Per
EBS, CM, CF>. MUST NOT be combined with any other type
UNI
of egress bandwidth profile.
Layer 2 Control Protocol
MUST specify in accordance with Section 8.6 of this document.
Processing
Table 27: UNI service attributes and parameters for the EVP-Tree service
Table 28 provides the EVC per UNI service attributes, parameters, and values for the EVP-Tree service.
EVC per UNI Service
Service Attribute Parameters and Values
Attribute
A string formed by the concatenation of the UNI ID and the
UNI EVC ID
EVC ID.
CE-VLAN ID / EVC Map MUST specify mapping table of CE-VLAN IDs to the EVC ID.
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR,
Ingress Bandwidth Profile Per
EBS, CM, CF>. MUST NOT be combined with any other type
EVC
of ingress bandwidth profile.
OPTIONAL. If supported, MUST specify CoS ID per [2],
Ingress Bandwidth Profile Per section 6.8, and MUST specify <CIR, CBS, EIR, EBS, CM,
CoS ID CF> for each CoS. MUST NOT be combined with any other
type of ingress bandwidth profile.
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR,
Egress Bandwidth Profile Per
EBS, CM, CF>. MUST NOT be combined with any other type
EVC
of egress bandwidth profile.
OPTIONAL. If supported, MUST specify CoS ID per [2],
Egress Bandwidth Profile Per section 6.8, and MUST specify <CIR, CBS, EIR, EBS, CM,
CoS ID CF> for each CoS. MUST NOT be combined with any other
type of egress bandwidth profile.
Table 28: EVC per UNI service attributes and parameters for the EVP-Tree service
Table 29 provides the EVC service attributes, parameters, and values for the EVP-Tree service.
EVC Service Attribute Service Attribute Parameters and Values
EVC Type MUST be Rooted-Multipoint
An arbitrary string, unique across the MEN, for the EVC
EVC ID
supporting the service instance.
MUST list the UNIs associated with the EVC. The UNI Type
UNI List for at least 1 UNI MUST be Root. All UNIs that are not UNI
Type Root MUST be UNI Type Leaf.
Maximum Number of UNIs MUST be 2
EVC MTU size MUST be 1522
MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

EVC Service Attribute Service Attribute Parameters and Values


CE-VLAN ID Preservation MUST be either Yes or No
CE-VLAN CoS Preservation MUST be either Yes or No
Deliver Unconditionally or Deliver Conditionally. If Delivered
Unicast Service Frame Delivery
Conditionally, MUST specify the delivery criteria.
Multicast Service Frame Deliver Unconditionally or Deliver Conditionally. If Delivered
Delivery Conditionally, MUST specify the delivery criteria.
Broadcast Service Frame Deliver Unconditionally or Deliver Conditionally. If Delivered
Delivery Conditionally, MUST specify the delivery criteria.
Layer 2 Control Protocols
Processing (only applies for MUST specify in accordance with Section 8.6 of this document.
L2CP frame passed to the EVC)
At least one CoS is REQUIRED. MUST specify CoS ID, per
section 6.8 of [2]. For each CoS, MUST list values for each of
the following attributes {Frame Delay, Frame Delay Variation,
Frame Loss Ratio, and Availability}, where Not Specified (N/S)
EVC Performance
is an acceptable value, for one or more sets of ordered UNI pairs
where each ordered pair contains at least one Root UNI. Each
ordered UNI pair containing at least one Root UNI in the EVC
MUST be mapped to at least one CoS.
Table 29: EVC service attributes and parameters for the EVP-Tree service
8. Layer 2 Control Protocol Processing Requirements (Normative)
This section provides requirements for the processing of a Subscribers Layer 2 Control Protocol
(L2CP) frames on a given UNI for the services defined in this document. The requirements are
intended to provide guidance for actual deployments of the Ethernet services defined in this
document, while at the same time allowing for flexibility among the Service Provider offerings.

Within the context of this document, a Layer 2 Control Protocol is identified by one of the
following MAC Destination Addresses:
MAC DAs Layer 2 Control Protocol
01-80-C2-00-00-00 through 01-80-C2-00-00-0F Bridge Block of protocols
01-80-C2-00-00-20 through 01-80-C2-00-00-2F GARP Block of protocols
Table 30: List of Standardized Layer 2 Control Protocols
For each service, protocols are configured to tunnel, peer, or discard at the UNI.
Classification of which L2CP frames to tunnel will examine only the MAC Destination Address
(DA) of the Service Frame. Note that for cases in which more than one protocol uses the same
MAC DA (e.g., LACP and Link OAM), then the required action related to tunneling is the same.
Since multiple protocols may share the same MAC DA, classification of which L2CP frames to
peer will examine both the MAC DA and the protocol identifiers (e.g. Ethertype, Slow-protocol
sub-type).
MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

In this section, Discard means that the MEN will discard ingress L2CP frames of a given
<protocol, DA> pair and will not generate that <protocol, DA> pair on egress from the MEN.
Peer means that the MEN will actively participate with the protocol if the DA is as specified.
These L2CPs are: LACP/LAMP, Link OAM, Port Authentication, and E-LMI,. Tunnel means
that frames are transparently passed to a given EVC for transport across the MEN to the
destination UNI(s).

If a given protocol uses a MAC Destination Address (DA) other than that specified in the
following subsections, and outside the block of the reserved MAC DAs (16 bridge block, 16
GARP block), then it SHOULD be treated as normal data.

If a given protocol uses a MAC DA other than that specified in the following subsections, but
within the block of the reserved MAC DAs (16 bridge block, 16 GARP block), then the
requirements are left for further study.

These recommendations are designed to be consistent with a standard Provider Bridge [10]
implementation. The Provider Bridge specification allows for subscribers that may want to
deviate from these recommendations by providing a default set of standard destination MAC
addresses that could be used to determine either peering or tunneling for a specific L2CP. See
Section 11, for more discussion of how the MEF terminology maps to IEEE 802.1 terminology
with respect to L2CP processing.

The tables in the following subsections summarize the Layer 2 Control Protocol (L2CP)
Processing requirements for the indicated services. For an ingress Service Frame with the given
destination MAC address and the given protocol, the required actions for the service are
specified together with the applicability of the requirement, i.e., whether it applies to all UNIs in
the EVC or is applied on a per-UNI basis.

Please note that while [1] included requirements for All Bridges, requirements for this protocol
are not included in this document. The All LANs Bridge Management Group Address (01-80-
C2-00-00-10) has been officially deprecated in 802.1Q-2005, subclause 8.13.7. In the unlikely
event that a customer may use this MAC DA, MEF services are expected to treat them as normal
service frames.

8.1 L2CP REQUIREMENTS FOR ETHERNET PRIVATE LINE (EPL) SERVICE


Table 31 specifies the L2CP processing requirements for EPL service. The first column
identifies the standard protocol, and the second column identifies the MAC DA used to carry that
protocol data unit. The third column specifies the required action, and the fourth column
specifies the applicability, i.e., whether the action taken must be the same at all UNIs in the
EVC, or the action taken can be different on different UNIs in the EVC.
L2CP Requirement
Protocol MAC DA Applicability
Option 1 Option 2
STP[3]/RSTP[3]/MSTP[4] 01-80-C2-00-00-00 MUST Tunnel MUST Tunnel All UNIs in the EVC

MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

SHOULD SHOULD
PAUSE[5] 01-80-C2-00-00-01 All UNIs in the EVC
Discard Discard
Option 1: Per UNI
SHOULD Peer SHOULD
LACP/LAMP[5] 01-80-C2-00-00-02 Option 2: All UNIs in
or Discard Tunnel
the EVC
Option 1: Per UNI
SHOULD Peer SHOULD
Link OAM[5] 01-80-C2-00-00-02 Option 2: All UNIs in
or Discard Tunnel
the EVC
Option 1: Per UNI
SHOULD Peer SHOULD
Port Authentication[7] 01-80-C2-00-00-03 Option 2: All UNIs in
or Discard Tunnel
the EVC
Option 1: Per UNI
SHOULD Peer
E-LMI[9] 01-80-C2-00-00-07 MUST Tunnel Option 2: All UNIs in
or Discard
the EVC
SHOULD
LLDP[8] 01-80-C2-00-00-0E MUST Tunnel All UNIs in the EVC
Discard
01-80-C2-00-00-20
MUST Discard
GARP[4]/MRP[17] Block through MUST Tunnel All UNIs in the EVC
or Tunnel
01-80-C2-00-00-2F
Table 31: L2CP Processing Requirements for the EPL Service
8.2 L2CP REQUIREMENTS FOR ETHERNET VIRTUAL PRIVATE LINE (EVPL) SERVICE
Table 32 specifies the L2CP processing requirements for EVPL service. The first column
identifies the standard protocol, and the second column identifies the MAC DA used to carry that
protocol data unit. The third column specifies the required action, and the fourth column
specifies the applicability, i.e., whether the action taken must be the same at all UNIs in the
EVC, or the action taken can be different on different UNIs in the EVC.
Protocol MAC DA L2CP Requirement Applicability
STP[3]/RSTP[3]/MSTP[4] 01-80-C2-00-00-00 MUST Peer or Discard All UNIs in the EVC
PAUSE[5] 01-80-C2-00-00-01 MUST Discard All UNIs in the EVC
LACP/LAMP[5] 01-80-C2-00-00-02 MUST Peer or Discard Per UNI
Link OAM[5] 01-80-C2-00-00-02 MUST Peer or Discard Per UNI
Port Authentication[7] 01-80-C2-00-00-03 MUST Peer or Discard Per UNI
E-LMI[9] 01-80-C2-00-00-07 MUST Peer or Discard Per UNI
LLDP[8] 01-80-C2-00-00-0E MUST Discard All UNIs in the EVC
01-80-C2-00-00-20
MUST Peer, Tunnel or
GARP[4]/MRP[17] Block through Per UNI
Discard
01-80-C2-00-00-2F
Table 32: L2CP Processing Requirements for the EVPL Service
8.3 L2CP REQUIREMENTS FOR ETHERNET PRIVATE LAN (EP-LAN) SERVICE
Table 33 specifies the L2CP processing requirements for EP-LAN service. The first column
identifies the standard protocol, and the second column identifies the MAC DA used to carry that
MEF 6.1 The Metro Ethernet Forum 2008. 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.
Ethernet Services Definitions, Phase 2 MEF 6.1

protocol data unit. The third column specifies the required action, and the fourth column
specifies the applicability, i.e., whether the action taken must be the same at all UNIs in the
EVC, or the action taken can be different on different UNIs in the EVC.
Protocol MAC DA L2CP Requirement Applicability
SHOULD Tunnel
STP[3]/RSTP[3]/MSTP[4] 01-80-C2-00-00-00 All UNIs in the EVC
MAY Discard
PAUSE[5] 01-80-C2-00-00-01 MUST Discard All UNIs in the EVC
LACP/LAMP[5] 01-80-C2-00-00-02 MUST Peer or Discard Per UNI
Link OAM[5] 01-80-C2-00-00-02 MUST Peer or Discard Per UNI
Port Authentication[7] 01-80-C2-00-00-03 MUST Peer or Discard Per UNI
E-LMI[9] 01-80-C2-00-00-07 MUST Peer or Discard Per UNI
LLDP[8] 01-80-C2-00-00-0E MUST Discard All UNIs in the EVC
01-80-C2-00-00-20
MUST Peer, Tunnel or
GARP[4]/MRP[17] Block through Per UNI
Discard
01-80-C2-00-00-2F
Table 33: L2CP Processing Requirements for the EP-LAN Service
8.4 L2CP REQUIREMENTS FOR ETHERNET VIRTUAL PRIVATE LAN (EVP-LAN) SERVICE
Table 34 specifies the L2CP processing requirements for EVP-LAN service. The first column
identifies the standard protocol, and the second column identifies the MAC DA used to carry that
protocol data unit. The third column specifies the required action, and the fourth column
specifies the applicability, i.e., whether the action taken must be the same at all UNIs in the
EVC, or the action taken can be different on different UNIs in the EVC.
Protocol MAC DA L2CP Requirement Applicability
STP[3]/RSTP[3]/MSTP[4] 01-80-C2-00-00-00 MUST Peer or Discard All UNIs in the EVC
PAUSE[5] 01-80-C2-00-00-01 MUST Discard All UNIs in the EVC
LACP/LAMP[5] 01-80-C2-00-00-02 MUST Peer or Discard Per UNI
Link OAM[5] 01-80-C2-00-00-02 MUST Peer or Discard Per UNI
Port Authentication[7] 01-80-C2-00-00-03 MUST Peer or Discard Per UNI
E-LMI[9] 01-80-C2-00-00-07 MUST Peer or Discard Per UNI
LLDP[8] 01-80-C2-00-00-0E MUST Discard All UNIs in the EVC
01-80-C2-00-00-20
MUST Peer, Tunnel or
GARP[4]/MRP[17] Block through Per UNI
Discard
01-80-C2-00-00-2F
Table 34: L2CP Processing Requirements for the EVP-LAN Service
8.5 L2CP REQUIREMENTS FOR ETHERNET PRIVATE TREE (EP-TREE) SERVICE
Table 35 specifies the L2CP processing requirements for EP-Tree service. The first column
identifies the standard protocol, and the second column identifies the MAC DA used to carry that
protocol data unit. The third column specifies the required action, and the fourth column
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 36
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.
Ethernet Services Definitions, Phase 2 MEF 6.1

specifies the applicability, i.e., whether the action taken must be the same at all UNIs in the
EVC, or the action taken can be different on different UNIs in the EVC.
Protocol MAC DA L2CP Requirement Applicability
SHOULD Tunnel 6
STP[3]/RSTP[3]/MSTP[4] 01-80-C2-00-00-00 All UNIs in the EVC
MAY Discard
PAUSE[5] 01-80-C2-00-00-01 MUST Discard All UNIs in the EVC
LACP/LAMP[5] 01-80-C2-00-00-02 MUST Peer or Discard Per UNI
Link OAM[5] 01-80-C2-00-00-02 MUST Peer or Discard Per UNI
Port Authentication[7] 01-80-C2-00-00-03 MUST Peer or Discard Per UNI
E-LMI[9] 01-80-C2-00-00-07 MUST Peer or Discard Per UNI
LLDP[8] 01-80-C2-00-00-0E MUST Discard All UNIs in the EVC
01-80-C2-00-00-20
MUST Peer, Tunnel or
GARP[4]/MRP[17] Block through Per UNI
Discard
01-80-C2-00-00-2F
Table 35: L2CP Processing Requirements for the EP-Tree Service
8.6 L2CP REQUIREMENTS FOR ETHERNET VIRTUAL PRIVATE TREE (EVP-TREE) SERVICE
Table 36 specifies the L2CP processing requirements for EVP-Tree service. The first column
identifies the standard protocol, and the second column identifies the MAC DA used to carry that
protocol data unit. The third column specifies the required action, and the fourth column
specifies the applicability, i.e., whether the action taken must be the same at all UNIs in the
EVC, or the action taken can be different on different UNIs in the EVC.
Protocol MAC DA L2CP Requirement Applicability
STP[3]/RSTP[3]/MSTP[4] 01-80-C2-00-00-00 MUST Peer or Discard All UNIs in the EVC
PAUSE[5] 01-80-C2-00-00-01 MUST Discard All UNIs in the EVC
LACP/LAMP[5] 01-80-C2-00-00-02 MUST Peer or Discard Per UNI
Link OAM[5] 01-80-C2-00-00-02 MUST Peer or Discard Per UNI
Port Authentication[7] 01-80-C2-00-00-03 MUST Peer or Discard Per UNI
E-LMI[9] 01-80-C2-00-00-07 MUST Peer or Discard Per UNI
LLDP[8] 01-80-C2-00-00-0E MUST Discard All UNIs in the EVC
01-80-C2-00-00-20
MUST Peer, Tunnel or
GARP[4]/MRP[17] Block through Per UNI
Discard
01-80-C2-00-00-2F
Table 36: L2CP Processing Requirements for the EVP-Tree Service

6
Since not all CEs in an E-Tree service will see all BPDUs, undesirable behavior can ensue. Service Providers
should be careful to warn Subscribers about attaching bridges to such a service and expecting STP work properly.
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 37
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.
Ethernet Services Definitions, Phase 2 MEF 6.1

9. Service OAM Requirements (Normative)


Service OAM requirements in this section are in alignment with MEF Service OAM Require-
ments & Framework - Phase 1 [16], and are based on protocols specified in IEEE 802.1ag [11]
and ITU-T Y.1731 [15]. This is a set of protocols that allow for two types of maintenance points
and up to eight Maintenance Domains (MDs) associated with a given service.

A Maintenance End Point (MEP) is used at the edge of a domain to control management of a
given service. A Maintenance Intermediate Point (MIP) is used within the domain, between
MEPs, to aid in operating and maintaining the service.

The eight Maintenance Domain (MD) levels are grouped, as follows:

Subscriber MD: The Subscriber MD, typically at levels 5-7, are allocated for the Subscriber
to use for managing the service within the Subscribers domain, e.g., from CE to CE.

Service Provider MD: The Service Provider MD, typically at levels 3-4, are allocated for the
Service Provider to use for managing the service within the Service Providers domain, e.g.,
from UNI-to-UNI.

Operator MD: The Operator MD, typically at levels 1-2, are allocated for the Operator to use
for managing the service from within the Operators domain.

UNI Maintenance Entity (UNI ME): The UNI ME, typically at level 0, is allocated for
managing the UNI link.

For the purpose of this section, only the Subscriber MD is considered. The Service Provider and
Operator MDs do not cross the UNI, hence are not involved in the definitions of the Ethernet
Services. In addition, requirements for the UNI ME will be addressed in future MEF
Implementation Agreements.

The Service Provider and Subscriber SHOULD agree on the allocation of one or more
Subscriber MD levels for a given Ethernet service.

Since the higher MD levels have wider scope, the agreed Subscriber MD levels MUST be higher
than any MD-levels used by the Service Provider to monitor that EVC.

For example, a Service Provider and Subscriber could agree on two Subscriber MD levels and,
therefore, agree on MD levels 6 and 7 for use by the Subscriber. This would leave MD level 5
for possible use by the Service Provider, in addition to the Service Provider MD levels outlined
before.

Also, a Service Provider MAY configure MIPs in the MEN at the lowest agreed Subscriber MD
level.

MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 38
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.
Ethernet Services Definitions, Phase 2 MEF 6.1

Requirements for the agreed upon Subscriber MD levels are specified in the following
subsections for each of three protocols: Continuity Check, Link Trace, and Loopback.

9.1.1 Subscriber MD, Continuity Check

The Subscriber MD Continuity Check (CC) function allows the Subscriber to check continuity
for a given EVC across the entire service using a CC Message (CCM), sent from one MEP to
another MEP. For services with more than two MEPs, CCMs would be enabled on all MEPs,
such that each MEP would send CCMs to all of its peers.

A Subscriber could send CCMs at a fast rate to quickly detect service failures, and perhaps
switch the service to a back-up protected path. Another use case could be to use CCMs at a
slower rate, and use the results to track the service performance. A third use case is to use CCMs
for basic fault management, i.e., detecting loss of continuity or unintended connectivity among
MEPs.

The MAC Destination Addresses reserved for CCMs at MD levels 0-7 are specified in IEEE
802.1ag [11].

Since MIPs are not involved in processing the Subscriber MD CCMs, the Service Provider can
play no role in this protocol, other than tunneling it. Thus, for any of the Ethernet services
defined in this document, a CCM at an agreed upon Subscriber MD level with the corresponding
MAC Destination Address MUST be tunneled.

The following requirements are specified to determine the CoS of a tunneled Subscriber MD
level CCM.

For an EVC with a single CoS, the tunneled CCM frame MUST use the CoS of the EVC.

For an EVC with multiple CoS, the requirements are dependent on the Class of Service
Identification (CoS ID) used for a given EVC.

Where PCP is used for CoS ID, the CoS for a tunneled CCM frame MUST be determined
solely by the PCP field of the CCM frame. The Subscriber SHOULD map Subscriber MD
level CCMs to a PCP value that results in a CoS with the lowest loss.

Where DSCP is used for CoS ID, the CoS ID for a tunneled CCM frame SHOULD be agreed
upon by the Subscriber and Service Provider (the same CoS ID for all non-IP packets).

9.1.2 Subscriber MD, Link Trace

The Subscriber MD Link Trace (LT) function allows the Subscriber to trace the path for a given
EVC across the entire service using a LT Message (LTM), which is sent on demand from one
MEP towards a target MEP (or a target MIP). If a MIP is configured inside the MEN at the same
MD level as set in the LTM, the MIP would respond with a LT Response (LTR) to the source

MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 39
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.
Ethernet Services Definitions, Phase 2 MEF 6.1

MEP, and relay the original LTM towards the target, with the TTL field decremented. We refer
to this process as peering. If there is no MIP configured inside the MEN, then the LTM is
expected to be tunneled through the service.

The MAC Destination Addresses reserved for LTs at MD levels 0-7 are specified in IEEE
802.1ag [11].

There are two sets of requirements for LT. The first scenario is where one or more MIPs are
configured in the MEN at an agreed Subscriber MD level. The other is the case where a MIP is
not configured in the MEN at an agreed Subscriber MD level.

For any of the Ethernet services defined in this document where at least one MIP is configured
inside the MEN at an agreed Subscriber MD level, a LT message at an agreed upon Subscriber
MD level with the corresponding MAC Destination Address MUST be peered or discarded. For
link trace, peering means that the MIP responds and the LT message is forwarded per the Service
OAM standards.

For any of the Ethernet services defined in this document where a MIP is not configured in the
MEN at an agreed Subscriber MD level, a LT message at an agreed upon Subscriber MD level
with the corresponding MAC Destination Address MUST be tunneled.

9.1.3 Subscriber MD, Loopback

The Subscriber MD Loopback (LB) function allows the Subscriber to ping a target MEP or MIP
using an LB Message (LBM), which is sent on demand from one MEP towards the target MEP
or MIP. If a MIP is configured inside the MEN at the same MD level as set in the LBM, and if
the target for the LBM is the MIP itself, then the MIP would respond with a LB Response (LBR)
to the source MEP. We refer to this process as peering. If there is no MIP configured inside the
MEN, or if the target for the LBM is not any of the MIPs inside the MEN, then the LBM is
expected to be tunneled through the service.

An LBM may be sent with a unicast or multicast DA. In the case of multicast LBM, the MAC
DA values are the same as those for CCM. An LBR always uses a unicast DA. For cases where
a multicast DA is used in the LBM frame, the target is all MEPs in the MD. Any MIP along the
path is expected to ignore (relay) such a frame.

There are three sets of requirements for LB. The first scenario is where the Subscriber uses a
unicast MAC DA for the target and one or more MIPs are configured in the MEN at an agreed
Subscriber MD level. The second case is where the Subscriber uses a unicast MAC DA for the
target and a MIP is not configured in the MEN at an agreed Subscriber MD level. The third case
is where the Subscriber uses a multicast MAC DA for the target, regardless of whether there is a
MIP at an agreed Subscriber MD level or not configured in the MEN.

For any of the Ethernet services defined in this document where the Subscriber uses a unicast
MAC DA for the target and at least one MIP is configured inside the MEN at an agreed
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 40
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.
Ethernet Services Definitions, Phase 2 MEF 6.1

Subscriber MD level, a LB message at an agreed upon Subscriber MD level with a target unicast
DA equal to the MAC address of a MIP in the MEN MUST be peered or discarded. Such a
control mechanism could be used by a Service Provider to minimize the impact of LBMs on the
MEN. A LB message at an agreed upon Subscriber MD level with a target unicast DA not equal
to the MAC address of any MIP inside the MEN MUST be tunneled.

For any of the Ethernet services defined in this document where the Subscriber uses a unicast
MAC DA for the target and a MIP is not configured inside the MEN at an agreed Subscriber MD
level, a LB message at an agreed upon Subscriber MD level MUST be tunneled.

For any of the Ethernet services defined in this document where the Subscriber uses a multicast
MAC DA for the target, a LB message at an agreed upon Subscriber MD level with the
corresponding MAC DA MUST be tunneled.

10. References
[1] MEF Technical Specification MEF 6, Ethernet Services Definitions - Phase I, June 2004
[2] MEF Technical Specification, MEF 10.1, Ethernet Services Attributes - Phase 2,
November 2006
[3] IEEE 802.1D-2004, Part 3: Media Access Control (MAC) Bridges
[4] IEEE 802.1Q 2005, Virtual Bridged Local Area Networks
[5] IEEE 802.3-2005, Part 3: Carrier sense multiple access with collision detection
(CSMA/CD) access method and physical layer specifications
[6] RFC 2119, Key words for use in RFCs to Indicate Requirement Levels, S. Bradner
[7] IEEE 802.1X 2004, Port-Based Network Access Control
[8] IEEE 802.1AB-2005, Station and Media Access Control, Connectivity Discovery
[9] MEF Technical Specification MEF 16, Ethernet Local Management Interface, January
2006
[10] IEEE 802.1ad-2005, Virtual Bridged Local Area Networks Amendment 4: Provider
Bridges
[11] IEEE 802.1ag-2007, Virtual Bridged Local Area Networks Amendment 5: Connectivity
Fault Management
[12] MEF Technical Specification MEF 4, Metro Ethernet Network Architecture Framework -
Part 1: Generic Framework, May 2004
[13] ITU-T Recommendation G.8011.1/Y.1307.1, Ethernet Private Line
[14] ITU-T Recommendation G.8011.2/Y.1307.2, Ethernet Virtual Private Line Service
[15] ITU-T Recommendation Y.1731, OAM functions and mechanisms for Ethernet based
networks
[16] MEF Technical Specification MEF 17, Service OAM Requirements & Framework
Phase 1, April 2007
[17] IEEE 802.1ak-2007, Virtual Bridged Local Area Networks, Amendment 07: Multiple
Registration Protocol

MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 41
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.
Ethernet Services Definitions, Phase 2 MEF 6.1

11. Appendix A: MEF and IEEE 802.1 Terminology (Informative)


There are many cases where some protocols need to be tunneled. One example is when a
Subscriber has bridge CEs at various sites that are connected via an Ethernet service, with back
door connections among the sites. In this case, the service needs to tunnel the Subscriber
spanning tree BPDUs so the Subscriber can ensure a loop free topology among his CEs. Other
L2CPs may need to be handled differently, e.g., PAUSE frames may need to be discarded.

MEF defines these options in terms of service attributes, i.e., what the Subscriber can expect
end-to-end across the network. On the other hand, IEEE 802.1 defines terms local to a bridge
function, e.g., a Provider Bridge S-VLAN component must forward (relay) Subscriber spanning
tree frames. Since networks can be composed of different types of network elements, some of
which may be bridges and some not, there is a need for MEF terms to characterize the service
attributes, while understanding the Provider Bridge terms.

Some of the requirements in Section 8 of this document assume alignment with the IEEE
802.1ad, Provider Bridges [10] specification. This subsection is intended to provide a mapping
of MEF L2CP terms to IEEE 802.1 bridge terminology with respect to Layer 2 Control Protocol
(L2CP) processing options for the various L2CPs identified in this specification.

As defined in [2], MEF allows for three L2CP processing options for each L2CP. These are
briefly described below:
Peer means that the MEN will participate in the protocol.
Tunnel means that an ingress L2CP frame at a given UNI gets delivered unchanged to
each of the destination UNIs. The requirement is that all UNIs in the EVC must tunnel
the same protocols. In 802.1 terms, the L2CP is forwarded through the bridge relay.
Discard means that the MEN will ignore the L2CP frame, i.e., it will not participate in
the protocol and it will not forward the frame.
Table 37 summarizes the correlation of terms:
MEF Term IEEE 802.1 Term
Peer Participate
Tunnel Forward (relay)
Discard Not forward, Not participate
Table 37: MEF and IEEE 802.1 terms for L2CP Processing Options

12. Appendix B: Practical Examples of Ethernet Services (Informative)


This appendix provides service instance examples of the E-Line, E-LAN, and E-Tree Service
Types defined in Section 6. These service examples are assumed to be offered by a hypothetical
metro Service Provider, ACME, offering a portfolio of turbo-charged Ethernet services.

MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 42
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.
Ethernet Services Definitions, Phase 2 MEF 6.1

Table 38 is used for defining an example of the EVC performance attributes, parameters, and
values associated with each of the Classes of Service offered by ACME. For simplicity, it is
assumed that the values for the performance parameters shown below apply to all Ethernet
services, i.e., E-Line, E-LAN, and E-Tree services. In actuality, Service Providers may offer
different CoS and associated performance attribute objectives for the three service types. Also,
since the objective values can be controversial and have wide variance among Service Providers,
actual numbers are not used for the objective values.

Table 38 is used as a reference for Ethernet Services in each of the examples in the following
subsections.
Example of Turbo-Charged Ethernet Services offered by the ACME Service Provider
EVC Performance Class of Service Offering
Parameters
Attribute Krypton Argon Neon
CoS ID (Priority Code Point
N/A PCP=5 PCP=4 PCP=0
value)
Subset of ordered UNI
All All All
pairs (S)
Frame Delay (FD) FD Objective X ms Y ms (Y>X) Z ms (Z>Y)
Percentile (P) 95% 95% 95%
Time interval (T) 1 hour 1 hour 1 hour
Subset of ordered UNI
All All All
pairs (S)
FDV objective Q ms N/S N/S
Frame Delay Variation (FDV)
Percentile (P) 95% N/S N/S
Time interval (T) 1 hour N/S N/S
Pair interval (t) 100 ms N/S N/S
Subset of ordered UNI
All All All
pairs (S)
Frame Loss Ratio (FLR)
FLR Objective A% B% (B>A) C% (C>B)
Time interval (T) 1 hour 1 hour 1 hour
Subset of UNI pairs (S) All All All
Availability Objective % % (< ) % (< )
Time interval (T) 1 month 1 month 1 month
Number of consecutive
1 1 1
small time intervals (n)
Availability
Small time interval (t) 2 minutes 2 minutes 2 minutes
Unavailability frame loss
50% 75% 100%
ratio threshold (Cu)
Availability frame loss
0% 25% 50%
ratio threshold (Ca)
Table 38: EVC Performance Attributes and Parameters per CoS Offering

MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 43
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.
Ethernet Services Definitions, Phase 2 MEF 6.1

In Table 38, the value All in the Subset of ordered UNI pairs entries, means that all possible
ordered pairs of UNIs are included in the offering. The reader is directed to [2] for precise
definitions of the CoS attributes and parameters.

Table 39 is used for defining the Layer 2 Control Protocol (L2CP) processing options used by a
given Service Provider at a UNI. Different L2CP processing options are used for All-to-One
Bundled (port-based services) and Service Multiplexed (VLAN-based services) UNIs. This table
is used as a reference for each of the examples in the following subsections. It is assumed that
the L2CP protocol and MAC address pair specified in Section 8 of this document is the one used
for the indicated protocol.
Port-based Services
Layer 2 Control Protocol VLAN-based Services
PB1 PB2
Spanning Tree Protocols Tunnel Tunnel Discard
PAUSE (802.3x) Discard Discard Discard
Discard (unprotected Tunnel
Discard (unprotected UNI)
LACP/LAMP UNI)
Peer (protected UNI)
Peer (protected UNI)
Link OAM Peer Tunnel Peer
Port Authentication (802.1x) Discard Tunnel Discard
E-LMI Peer Tunnel Peer
LLDP Discard Tunnel Discard
GARP/MRP Tunnel Tunnel Discard
Table 39: L2CP Attribute and Parameters per Service Offering

12.1 EXAMPLE: A TRANSPORT-ORIENTED ETHERNET PRIVATE LINE (EPL) SERVICE FOR


PRIVATE DATA NETWORKING APPLICATIONS.
A popular application of transport-oriented (or circuit-like) EPL services is to provide an
interconnect service between routing or switching equipment in an enterprises private data
network. This need may arise when a subscriber wishes to manage its own networking
infrastructure and desires a transport service that emulates as close as possible a dedicated
circuit. In such scenario, the MEN provides point-to-point interconnect services between 2
designated UNI-N ports at a given POP(s) and allocates transport resources according to the
desired circuit rate (typically the UNI port speed).

Since the subscriber wishes to manage its own packet network infrastructure the EPL service
must be configured to be highly transparent to the subscriber traffic. Transparency here implies
expectations for minimal interaction with clients data frames, including associated management
and control traffic between the subscribers routers and switches. It also implies expectations for
minimal flow variability to be introduced into the clients data stream (i.e., circuit-like
forwarding).

MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 44
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.
Ethernet Services Definitions, Phase 2 MEF 6.1

The service architecture is illustrated in Figure 12 below. The red dots represent the MEN UNIs
and the red dash represents the EVC instance that realizes the EPL service.

Site A
U1
EPL1 EVC
Capacity = CIR Site B
Port Rate = CIR
U2

Metro Ethernet
Port Rate = CIR
Network

Figure 12: Example of Transport-Oriented Private Data Network Interconnect Using the EPL
Service
The traffic pattern is that the subscriber data, management and control frames are sent from UNI
to UNI over a symmetric path. Routing/switching equipment on the subscriber side may send
their own L2 control messages without interference from the MEN.

In the case where the Service Provider wishes to have redundancy, a back-up EVC may be used
with some redundancy protocol to ensured that only one of the EVCs is active at any time.
Alternatively, two similar EPL services may be instantiated between Sites A and B and allow for
client-side protection (e.g., via LAG directly between switches on the subscriber site). For this
case the suggested UNI attributes are depicted in Table 40.
UNI Service Attribute UNI 1 UNI 2
UNI Identifier U1 U2
Physical Medium 1000BASE-SX 1000BASE-LX
Speed 1 Gbps 1 Gbps
Mode FDX FDX
MAC Layer IEEE 802.3-2005 IEEE 802.3-2005
UNI MTU Size 1522 1522
Service Multiplexing No No
Bundling No No
All to One Bundling Yes Yes
CE-VLAN ID for untagged and priority
NA NA
tagged Service Frames
Maximum number of EVCs 1 1
Ingress Bandwidth Profile Per UNI N/A N/A
Egress Bandwidth Profile Per UNI N/A N/A
L2CP Processing Table 39, PB2 Table 39, PB2
Table 40: UNI attributes for the Private Data Networking example using EPL Service

MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 45
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.
Ethernet Services Definitions, Phase 2 MEF 6.1

Table 41 provides the EVC per UNI attributes for the Private Data Networking example.
UNI Service Attribute UNIs 1 UNI 2
UNI EVC ID U1_EPL1 U2_EPL1
All Service Frames at the UNI All Service Frames at the UNI
CE-VLAN ID / EVC Map
map to a single EPL EVC map to a single EPL EVC
Ingress Bandwidth Profile Per EVC N/A N/A
CoS ID = EVC CoS ID = EVC
Ingress Bandwidth Profile Per CoS ID CIR=1Gbps, CBS=1522, EIR=0, CIR=1Gbps, CBS=1522, EIR=0,
EBS=0, color blind, CF=0 EBS=0, color blind, CF=0
Egress Bandwidth Profile Per EVC N/A N/A
Egress Bandwidth Profile Per CoS ID N/A N/A
Table 41: EVC per UNI attributes for the private data networking example using EPL Service

Table 42 provides the EVC attributes for the private data networking example.
EVC Service Attribute EVC_1
EVC Type Point-to-Point
EVC ID EPL1
UNI List {U1, U2}
Maximum Number of UNIs 2
EVC MTU size 1522
CE-VLAN ID Preservation Yes
CE-VLAN CoS Preservation Yes
Unicast Service Frame Delivery Deliver Unconditionally
Multicast Service Frame Delivery Deliver Unconditionally
Broadcast Service Frame Delivery Deliver Unconditionally
Layer 2 Control Protocols Processing Table 39, PB2
Service Performance Krypton CoS
Table 42: EVC service attributes for the private data networking example using the EPL Service

MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 46
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.
Ethernet Services Definitions, Phase 2 MEF 6.1

12.2 EXAMPLE OF A PACKET-ORIENTED ETHERNET PRIVATE LINE SERVICE FOR PUBLIC


DATA NETWORKING APPLICATIONS
A popular application of packet-oriented (or statistical) EPL services is to provide an
interconnect service between routing or switching equipment in an enterprise via a public data
networking service. This need arises when a subscriber wishes to interconnect multiple sites but
does not wish to manage the intermediate datacom facilities. In such scenario, the MEN provides
point-to-point interconnect services between 2 designated UNI-N ports at a given POP(s) and
allocates transport resources according to the anticipate traffic volume between the sites
(typically less than the UNI port speed).

Since the subscriber does not wish to manage its own packet network infrastructure there is little
expectation for data flow symmetry or transparency. The service interfaces at the UNIs may
operate at different rates, bandwidth allocation traffic at each UNI may also be asymmetric. Non-
essential traffic may be forwarded according to resource availability (i.e., statistical
multiplexing).

The service architecture is illustrated in Figure 13 below. The red dots represent the MEN UNIs
and the red dash represents the EVC instance that realizes the EPL service.

Site A
U3
EPL2 EVC
Capacity = X Site B
Port Rate = Y
U4

Carrier Ethernet Port Rate = Z


Network

Figure 13: Example of Transport-Oriented Public Data Network Interconnect Using the EPL
Service.
The traffic pattern is that the subscriber data, management and control frames are sent from UNI
to UNI over a potentially asymmetric path. Different levels of performance applicable depending
on the traffic type (potentially indicated via PCP marking). Non-essential L2 control messages
are typically discarded.

In the case where the Service Provider wishes to have redundancy, a back-up EVC may be used
with some redundancy protocol to ensure that only one of the EVCs is active at any time. The
UNI link may also be protected via link aggregation. For this case the suggested UNI attributes
are depicted in Table 43.

MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 47
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.
Ethernet Services Definitions, Phase 2 MEF 6.1

UNI Service Attribute UNI 3 UNI 4


UNI Identifier U3 U4
Physical Medium 1000BASE-SX 100BASE-TX
Speed 1 Gbps 100 Mbps
Mode FDX FDX
MAC Layer IEEE 802.3-2005 IEEE 802.3-2005
UNI MTU Size 1522 1522
Service Multiplexing No No
Bundling No No
All to One Bundling Yes Yes
CE-VLAN ID for untagged and priority
NA NA
tagged Service Frames
Maximum number of EVCs 1 1
Ingress Bandwidth Profile UNI N/A N/A
Egress Bandwidth Profile Per UNI N/A N/A
L2CP Processing Table 39, PB1 Table 39, PB1
Table 43: UNI attributes for the Private Data Networking example using EPL Service

Table 44 provides the EVC per UNI attributes for the Private Data Networking example.
UNI Service Attribute UNI 3 UNI 4
UNI EVC ID U3_EPL2 U4_EPL2
All Service Frames at the UNI All Service Frames at the UNI
CE-VLAN ID / EVC Map
map to a single EPL EVC map to a single EPL EVC
Ingress Bandwidth Profile Per EVC N/A N/A
PCP = 5: PCP = 5:
CIR=20Mbps, CBS=10k, CIR=30 Mbps, CBS=10k,
EIR=0, EBS=0, color blind, EIR=0, EBS=0, color blind,
CF=0 CF=0
Ingress Bandwidth Profile Per CoS ID
PCP = 0: PCP = 0:
CIR=10Mbps, CBS=50k, CIR=5 Mbps, CBS=10k,
EIR=0, EBS=0, color blind, EIR=10 Mbps, EBS=50K, color
CF=0 blind, CF=0
Egress Bandwidth Profile Per EVC N/A N/A
Egress Bandwidth Profile Per CoS ID N/A N/A
Table 44: EVC per UNI attributes for the public data networking example using EPL Service

MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 48
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.
Ethernet Services Definitions, Phase 2 MEF 6.1

Table 45 provides the EVC attributes for the public data networking example.
EVC Service Attribute EVC_1
EVC Type Point-to-Point
EVC ID EPL2
UNI List {U3, U4}
Maximum Number of UNIs 2
EVC MTU size 1522
CE-VLAN ID Preservation Yes
CE-VLAN CoS Preservation Yes
Unicast Service Frame Delivery Deliver Unconditionally
Multicast Service Frame Delivery Deliver Unconditionally
Broadcast Service Frame Delivery Deliver Unconditionally
Layer 2 Control Protocols Processing Table 39, PB1
CoS ID=5: Krypton CoS
Service Performance
CoS ID=0: Neon CoS
Table 45: EVC service attributes for the public data networking example using the EPL Service

12.3 EXAMPLE: ETHERNET PRIVATE TREE (EP-TREE) SERVICE FOR VIDEO BROADCAST
One example of using the EP-Tree service is for a video broadcast application. In this scenario,
a video head-end is located in a POP (this UNI is designated as a Root) providing a service to
multiple subscribers (each connected to a UNI designated as a Leaf). The service might offer
multiple broadcast channels.

In the case where all channels are to be delivered to each of the subscribers, this service is uni-
directional (no traffic from Leaf to Root). In this mode, scalability is enhanced compared to E-
Line services.

However, if each subscriber needs just a subset of the available channels, then each location
(connected to a Leaf UNI) may receive a specific channel. The signaling of the desired channel
could be done via a standard multicast protocol (IGMPv3 for example).

We denote these cases as A and B, respectively. The service architecture is illustrated in Figure
14 below. The blue dots represent Root UNIs and the red dots represent Leaf UNIs for this
EVC.

MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 49
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.
Ethernet Services Definitions, Phase 2 MEF 6.1

U1 (Root )
U2 (Root )

RMP_123
(EVC)
U3 (Leaf)

Metro Ethernet
U4 (Leaf) Network U502 (Leaf)

Figure 14: Example of Video Broadcast Delivery Using the EP-Tree Service
The traffic pattern is that the video content is sent from the video head-end towards the receiving
subscribers, while each such subscriber may send control messages to the video head-end.

In the case where the Service Provider wishes to have redundancy, two Root UNIs may be used
with some redundancy protocol ensuring that only one of them transmits data into the EVC.

For this case the suggested UNI attributes are depicted in Table 46.
UNI Service Attribute Root UNIs Leaf UNIs
U1 (primary),
UNI Identifier U3 U502
U2 (back-up)
Physical Medium 1000BASE-LX 100BASE-TX
Speed 1 Gbps 100 Mbps
Mode FDX FDX
MAC Layer IEEE 802.3-2005 IEEE 802.3-2005
UNI MTU Size 1522 1522
Service Multiplexing No No
Bundling No No
All to One Bundling Yes Yes
CE-VLAN ID for untagged and priority
1 (but not significant) 1 (but not significant
tagged Service Frames
Maximum number of EVCs 1 1
7 CIR=1 Mbps, CBS=10KB, EIR=0,
Ingress Bandwidth Profile Per UNI N/A 8
EBS=0, color blind, CF=0
Egress Bandwidth Profile Per UNI N/A N/A
L2CP Processing Table 39, PB1 Table 39, PB1
Table 46: UNI attributes for the video broadcast example using EP-Tree Service

7
Video source may be considered trusted and constant bit rate.
8
Minimal traffic from Leaf to Root.
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 50
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.
Ethernet Services Definitions, Phase 2 MEF 6.1

Table 47 provides the EVC per UNI attributes for the video broadcast example.
UNI Service Attribute UNIs 1 & 2 UNIs 3 502
UNI EVC ID U1_RMP123, U2_RMP123 U1_RMP123, ... U502_RMP123
All Service Frames at the UNI All Service Frames at the UNI
CE-VLAN ID / EVC Map map to a single Rooted- map to a single Rooted-
Multipoint EVC Multipoint EVC
Ingress Bandwidth Profile Per EVC N/A N/A
Ingress Bandwidth Profile Per CoS ID N/A N/A
Egress Bandwidth Profile Per EVC N/A N/A
Egress Bandwidth Profile Per CoS ID N/A N/A
Table 47: EVC per UNI attributes for the video broadcast example using EP-Tree Service
Table 48 provides the EVC attributes for the video broadcast example.
EVC Service Attribute EVC_1
EVC Type Rooted-Multipoint
EVC ID RMP_123
UNI List {U1, Root/U2, Root/U3, Leaf/U4, Leaf/.../U502, Leaf}
9
Maximum Number of UNIs 502
EVC MTU size 1522
CE-VLAN ID Preservation Yes
CE-VLAN CoS Preservation Yes
Unicast Service Frame Delivery Deliver Unconditionally
Deliver Conditionally: only deliver content subscribed to on a given Leaf
Multicast Service Frame Delivery
UNI
Broadcast Service Frame Delivery Deliver Unconditionally
Layer 2 Control Protocols Processing Table 39, PB1
EVC Performance (for all ordered
UNI pairs where at least one UNI in Krypton CoS
each pair is of type Root).
Table 48: EVC service attributes for the video broadcast example using EP-Tree Service

12.4 EXAMPLE: DISTANCE LEARNING (EVP-TREE) AND BUSINESS DATA (EVP-LAN)


In this example, we build a more complex scenario for an E-Tree type of service and overlay it
with an E-LAN type of service. All Subscriber locations are connected with two EVCs: EVP-
LAN service is used for a business data application, and EVP-tree service is used for a distance
learning application, which is based on IP video.

9
502 allows for up to 500 video receivers (Leaf UNIs) in this service instance
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 51
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.
Ethernet Services Definitions, Phase 2 MEF 6.1

Since the same UNIs are used for both services, service multiplexing is required at each UNI,
and separate bandwidth profiles are needed to ensure that the services do not adversely affect
each other. For the E-LAN service, bundling is required to ensure CE-VLAN ID transparency in
the range indicated in Table 50. For the E-Tree service, bundling is not required. Figure 15
below shows this example. The blue dots represent Root UNIs and the red dots represent Leaf
UNIs for the two EVCs. Each EVC has a single Class of Service, Neon for MP_111 and
Krypton for RMP_333.
U1
U2

RMP_333
U3
EVP-Tree Service

U4 U50
MEN
MP_111
EVP-LAN Service

Figure 15: Example of Distance Learning and Business Data Using EVP-LAN and EVP-Tree
Services
The suggested UNI attributes are shown in Table 49 below.
UNI Service Attribute UNIs 1 & 2 UNIs 3 50
UNI Identifier U1, U2 U3 U50
Physical Medium 1000BASE-LX 100BASE-TX
Speed 1 Gbps 100 Mbps
Mode FDX FDX
MAC Layer IEEE 802.3-2005 IEEE 802.3-2005
UNI MTU Size 1522 1522
Service Multiplexing Yes Yes
Bundling Yes Yes
All to One Bundling No No
CE-VLAN ID for untagged and priority
1 1
tagged Service Frames
Maximum number of EVCs 10 5
Ingress Bandwidth Profile Per UNI N/A N/A
Egress Bandwidth Profile Per UNI N/A N/A
L2CP Processing Table 39, VLAN-based Table 39, VLAN-based
Table 49: UNI attributes for the distance learning, business data example

MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 52
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.
Ethernet Services Definitions, Phase 2 MEF 6.1

The suggested EVC per UNI attributes are shown in Table 50 below. For table simplicity, only
UNI 1 and UNI 50 are shown. It is expected that attributes for UNI 1 and 2 are similar and that
UNIs 3-50 are similar to each other.
UNIs 1 & 2 UNIs 3-50
EVC per UNI Service Attribute
EVC_1 EVC_2 EVC_1 EVC_2
UNI EVC ID U1_MP111 U1_RMP333 U50_MP111 U50_RMP333
CE-VLAN ID / EVC Map 11-3999 4000 11-3999 4000
CIR (Mbps) 20 N/A 20 N/A
CBS (KB) 50 N/A 50 N/A
Ingress Bandwidth
Profile Per CoS ID of EIR (Mbps) 20 N/A 20 N/A
EVC for Neon CoS EBS (KB) 50 N/A 50 N/A
on EVC_1
CM Color Blind N/A Color Blind N/A
CF 0 N/A 0 N/A
CIR (Mbps) N/A 10 N/A 10
CBS (KB) N/A 20 N/A 20
Ingress Bandwidth
Profile Per CoS ID of EIR (Mbps) N/A 0 N/A 0
EVC for Krypton EBS (KB) N/A 0 N/A 0
CoS on EVC_2
CM N/A Color Blind N/A Color Blind
CF N/A 0 N/A 0
CIR (Mbps) 20 N/A 20 N/A
CBS (KB) 70 N/A 70 N/A
Egress Bandwidth EIR (Mbps) 20 N/A 20 N/A
Profile Per CoS ID of
EVC for Neon CoS EBS (KB) 70 N/A 70 N/A
CM Color Blind N/A Color Blind N/A
CF 1 N/A 1 N/A
CIR (Mbps) N/A 10 N/A 1
CBS (KB) N/A 20 N/A 15
Egress Bandwidth
Profile Per CoS ID of EIR (Mbps) N/A 0 N/A 0
EVC for Krypton EBS (KB) N/A 0 N/A 0
CoS
CM N/A Color Blind N/A Color Blind
CF N/A 0 N/A 0
Table 50: EVC per UNI attributes for the distance learning, business data example

MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 53
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.
Ethernet Services Definitions, Phase 2 MEF 6.1

The suggested EVC service attributes and parameter values are shown in Table 51 below for
each of the EVCs in this example.
EVC Service Attribute EVC-1 EVC_2
EVC Type Multipoint-to-Multipoint Rooted-Multipoint
EVC ID MP_111 RMP_333
{U1, Root/U2, Root/U3,
UNI List {U1, Root/U2, Root/.../U50, Root}
Leaf/.../U50, Leaf}
Maximum Number of UNIs 100 50
EVC MTU size 1522 1522
CE-VLAN ID Preservation Yes No
CE-VLAN CoS Preservation Yes No
Deliver Conditionally: for known D-
MACs only to destination UNI; for
Unicast Service Frame Delivery unknown D-MACs, deliver Deliver Unconditionally
unconditionally to all destination
UNIs
Deliver Conditionally: only deliver
Multicast Service Frame Delivery Deliver Unconditionally content subscribed to on a given Leaf
UNI
Broadcast Service Frame Delivery Deliver Unconditionally Deliver Unconditionally
Layer 2 Control Protocols
Table 39, VLAN-based Table 39, VLAN-based
Processing
Neon CoS (for all ordered UNI pairs) Krypton CoS (for all ordered UNI
EVC Performance pairs where at least one UNI in each
pair is of type Root)
Table 51: EVC attributes for the distance learning, business data example

MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 54
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.
RFC 4448
"Encapsulation Methods for Transport of Ethernet over MPLS
Networks", April 2006
Canonical URL:
http://www.rfc-editor.org/rfc/rfc4448.txt
This document is also available in this non-normative format: TXT.PDF.
Status:
PROPOSED STANDARD
Updated by:
RFC 5462
Authors:
L. Martini, Ed.
E. Rosen
N. El-Aawar
G. Heron
Stream:
IETF
Source:
pwe3 (int)

Please refer here for any errata for this document. To submit a new errata report, go to the main errata
page.

Abstract
An Ethernet pseudowire (PW) is used to carry Ethernet/802.3 Protocol Data Units (PDUs) over an
MPLS network. This enables service providers to offer "emulated" Ethernet services over existing
MPLS networks. This document specifies the encapsulation of Ethernet/802.3 PDUs within a
pseudowire. It also specifies the procedures for using a PW to provide a "point-to-point Ethernet"
service. [STANDARDS-TRACK]

For the definition of Status, see RFC 2026.

For the definition of Stream, see RFC 4844.

Go to the RFC Editor Homepage.


RFC 4761
"Virtual Private LAN Service (VPLS) Using BGP for Auto-
Discovery and Signaling", January 2007
Canonical URL:
http://www.rfc-editor.org/rfc/rfc4761.txt
This document is also available in this non-normative format: TXT.PDF.
Status:
PROPOSED STANDARD
Updated by:
RFC 5462
Authors:
K. Kompella, Ed.
Y. Rekhter, Ed.
Stream:
IETF
Source:
l2vpn (int)

Please refer here for any errata for this document. To submit a new errata report, go to the main errata
page.

Abstract
Virtual Private LAN Service (VPLS), also known as Transparent LAN Service and Virtual Private
Switched Network service, is a useful Service Provider offering. The service offers a Layer 2 Virtual
Private Network (VPN); however, in the case of VPLS, the customers in the VPN are connected by a
multipoint Ethernet LAN, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature.

This document describes the functions required to offer VPLS, a mechanism for signaling a VPLS, and
rules for forwarding VPLS frames across a packet switched network. [STANDARDS-TRACK]

For the definition of Status, see RFC 2026.

For the definition of Stream, see RFC 4844.

Go to the RFC Editor Homepage.


RFC 5921
"A Framework for MPLS in Transport Networks", July 2010
Canonical URL:
http://www.rfc-editor.org/rfc/rfc5921.txt
This document is also available in this non-normative format: TXT.PDF.
Status:
INFORMATIONAL
Updated by:
RFC 6215
Authors:
M. Bocci, Ed.
S. Bryant, Ed.
D. Frost, Ed.
L. Levrau
L. Berger
Stream:
IETF
Source:
mpls (rtg)

Please refer here for any errata for this document. To submit a new errata report, go to the main errata
page.

Abstract
This document specifies an architectural framework for the application of Multiprotocol Label
Switching (MPLS) to the construction of packet-switched transport networks. It describes a common set
of protocol functions -- the MPLS Transport Profile (MPLS-TP) -- that supports the operational models
and capabilities typical of such networks, including signaled or explicitly provisioned bidirectional
connection-oriented paths, protection and restoration mechanisms, comprehensive Operations,
Administration, and Maintenance (OAM) functions, and network operation in the absence of a dynamic
control plane or IP forwarding support. Some of these functions are defined in existing MPLS
specifications, while others require extensions to existing specifications to meet the requirements of the
MPLS-TP.

This document defines the subset of the MPLS-TP applicable in general and to point-to-point transport
paths. The remaining subset, applicable specifically to point-to-multipoint transport paths, is outside the
scope of this document.

This document is a product of a joint Internet Engineering Task Force (IETF) / International
Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an
MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3)
architectures to support the capabilities and functionalities of a packet transport network as defined by
the ITU-T. This document is not an Internet Standards Track specification; it is published for
informational purposes.

For the definition of Status, see RFC 2026.

For the definition of Stream, see RFC 4844.

Go to the RFC Editor Homepage.


RFC 5960
"MPLS Transport Profile Data Plane Architecture", August
2010
Canonical URL:
http://www.rfc-editor.org/rfc/rfc5960.txt
This document is also available in this non-normative format: TXT.PDF.
Status:
PROPOSED STANDARD
Authors:
D. Frost, Ed.
S. Bryant, Ed.
M. Bocci, Ed.
Stream:
IETF
Source:
mpls (rtg)

Please refer here for any errata for this document. To submit a new errata report, go to the main errata
page.

Abstract
The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the set of MPLS protocol functions
applicable to the construction and operation of packet-switched transport networks. This document
specifies the subset of these functions that comprises the MPLS-TP data plane: the architectural layer
concerned with the encapsulation and forwarding of packets within an MPLS-TP network.

This document is a product of a joint Internet Engineering Task Force (IETF) / International
Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an
MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3)
architectures to support the capabilities and functionalities of a packet transport network.
[STANDARDS-TRACK]

For the definition of Status, see RFC 2026.

For the definition of Stream, see RFC 4844.

Go to the RFC Editor Homepage.


MEF White Paper: Delivering Ubiquitous Ethernet Services using the Worlds Access Technologies

Delivering Ubiquitous Ethernet Services


using an Array of Access Technologies
Abstract
This MEF white paper provides an overview of the various access technologies (also referred to as first-mile or
last-mile technologies) that are used to deliver MEF-compliant Carrier Ethernet services. The goal of this
white paper is to illustrate the fact that Service Providers who wish to deliver a ubiquitous Carrier Ethernet
service can and should deploy a number of available access technologies to ensure they can reach all of their
business customers locations.

Carrier Ethernet and MEF Ethernet Services


The MEF has defined Carrier Ethernet as a ubiquitous, standardized, carrier-class service and network with five
attributes that distinguish it from familiar LAN-based Ethernet. These attributes are standardized services,
scalability, reliability, management and quality of service.

The basic Carrier Ethernet service building blocks are E-Line (Ethernet Private Line and Ethernet Virtual Private
Line), E-LAN and E-Tree. This white paper discusses their deployment in the access network.

Ethernet Virtual Private Line (EVPL)


UNI
UNI
CE
CE

Carrier Ethernet Network


UNI
UNI
CE
CE
UNI
UNI
Point-to-Point Ethernet Virtual Connections CE
CE

Introduction
Industry forums and standards bodies like the MEF,
Corporate IT managers are exploring ways to add
IEEE, ITU-T and IETF have developed the necessary
network capacity while maintaining or reducing their
extensions to the original Ethernet protocol, making it
recurring operating expenses. Increasingly,
suitable for service provider applications. For its part,
businesses are moving away from traditional TDM,
the MEF has documented numerous technical
Frame Relay or ATM circuits and turning to Carrier
requirements for building and managing feature-rich
Ethernet Services to address these apparently
business-class Ethernet services. In addition, the
conflicting needs. Service providers have responded
MEF has developed a successful certification program
with rich offerings that combine heretofore unmatched
to verify that equipment and services satisfy these
scalability and flexible bandwidth options with reliability
requirements.
and quality of service previously only available with
old-school telecom circuits.
MEF 2009. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with
permission of the MEF." No user of this document is authorized to modify any of the information contained herein. 4/09 v1 1 of 11
MEF White Paper: Delivering Ubiquitous Ethernet Services using the Worlds Access Technologies

The Carrier Ethernet technology and market have Ubiquity Requires Multiple Access Technology
evolved to the point where purpose-built hardened Solutions
equipment is now used to deliver MEF-certified
services. The MEF technical work resulted in the With the evolution from best-effort Ethernet services
formal definition of the carrier-class Ethernet that has to higher-performing MEF-certified services, the
come to be known simply as Carrier Ethernet. The primary obstacle confronting Ethernet service delivery
customer base for Ethernet services has also evolved is the difficulty expanding the Ethernet service footprint
from large Enterprises located in fiber-rich and making it available ubiquitously. Or, at a
metropolitan centers to those with globally distributed minimum, making it available to the locations where
operations and mid-sized businesses in suburban and business users want to purchase it.
rural settings.
The need for ubiquitous Ethernet service delivery has
This last point is critical: this shift in the market has driven the development and deployment of a variety of
created opportunities and advantages for service access technologies, each optimized for different
providers who can offer ubiquitous coverage in a cost- access situations. Rarely can carriers find a single
effective and timely manner. access technology that can address all the access
requirements of their region. This problem is even
This paper focuses on informing the reader about the more pronounced when carriers follow customers out-
applications and individual advantages of currently of-region into other carriers territories.
available access technologies. The primary audience
of this paper is the service provider who is interested Fortunately, it is now possible to deliver a consistent
in delivering an Ethernet service without boundaries. MEF-certified Ethernet service over a variety of access
However, businesses who are consumers of Carrier architectures using MEF-certified equipment from
Ethernet services may also find it informative. multiple vendors. Some of the technologies used to
deliver MEF-certified services include the following
A Growing Opportunity with Real-World access alternatives:
Challenges
Ethernet over Fiber (Active Fiber, PON,
According to data from Vertical Systems, Carrier SONET/SDH)
Ethernet Services grew 41% in 2008 and will be a 31 Ethernet over PDH (T1/E1, DS3/E3)
billion dollar worldwide market by 2012. Carrier Ethernet over Copper (EFMCu)
Ethernet has been globally embraced by more than 50 Wireless Ethernet (WiMAX, Broadband Wireless,
service providers and 100 equipment manufacturers. Microwave)
This figure is growing at an annual rate of 40%. Ethernet over HFC/DOCSIS
The number one challenge facing service providers The network drawing on the following page illustrates
today is the difficulty of providing access to all their an access architecture that uses several of these
customer locations. While tremendous investments technologies. When properly deployed, the only
have been made to build out their fiber plant, no single difference among the Ethernet services delivered
provider can deliver on-net access to wide area across this variety of access technologies is the
Ethernet services with the same coverage as their maximum bandwidth that can be transported over
traditional services. The good news is that service each technology. The underlying service definitions
providers and equipment vendors have been actively and SLAs can be identical, providing the end user with
working together to tackle these challenges. a seamless Ethernet experience even while a variety
of different access technologies are in play.

MEF 2009. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with
permission of the MEF." No user of this document is authorized to modify any of the information contained herein. 4/09 v1 2 of 11
MEF White Paper: Delivering Ubiquitous Ethernet Services using the Worlds Access Technologies

Each of the access technologies illustrated above have their strengths in certain applications. The table below
describes these applications at an introductory level. The sections that follow will provide greater detail on the
advantages of each individual technology.

Summary of Carrier Ethernet Access Technologies


Carrier
Ethernet Technology Deployment Scenarios
Advantages
Access Alternatives (When to use the technology)
Method
- On-net buildings - Highest bandwidth
- Active Ethernet
- Greenfield - Noise immunity
- Ethernet over
Ethernet - Dense Metro area - Security
SONET/SDH
over Fiber - 1Gbit/s or greater bandwidth - Long reach
- Passive Optical
requirements - SONET/SDH leverage existing
Network
- Growth potential via xWDM
- Remote branch offices - Leverage existing transport
- Off-net customer locations (out - Universally deployable
- Bonded T1/E1
Ethernet of region, type 2) - Lower CAPEX
- DS3/E3 and bonded
over PDH - SMB - No reach limitations
DS3/E3
- Well understood provisioning
- Resiliency through bonding
- Remote branch offices - Ubiquitous copper availability
- On-net or off-net - Rapid deployment
Ethernet - 2BASE-TL
- SMB - Low cost unbundled local loop
over Copper - 10PASS-TS
- Campus settings - Resiliency through bonding
- Traffic monitoring
- Terrestrial - Remote branch office - Installation requires no trenching
microwave - Campus setting - Rapid deployment
Wireless - WiMAX - No fiber or copper available - Some alternatives offer mobility
Ethernet - Broadband wireless - Mobility required
- Free space optics
- WiFi
- Work at home - Extensive coverage
Hybrid Fiber - SOHO/SMB - High performance options
DOCSIS 2.x/3.x
Coax - Remote branch office - Deep penetration into residential
and suburban geographies
MEF 2009. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with
permission of the MEF." No user of this document is authorized to modify any of the information contained herein. 4/09 v1 3 of 11
MEF White Paper: Delivering Ubiquitous Ethernet Services using the Worlds Access Technologies

Ethernet over Fiber


For applications where it is available or where the of approximately 40 km. PON supports from 1 to 128
bandwidth requirements dictate it, delivering Ethernet users per single strand of fiber.
over optical fiber is an excellent choice. With virtually
unlimited bandwidth support, noise immunity and the PON is a cost-effective access method because it
ability to traverse long distances, optical fiber can conserves fiber for service providers offering high
provide the performance for the applications of today bandwidth business and residential access
and those envisioned for tomorrow. applications, green field deployments, mobile
backhaul and any upgrade from twisted pair or
Active Ethernet coaxial copper networks.
One of the most common Ethernet over Fiber
architectures is point-to-point, where the connection is Benefits of PON
from the Service Providers aggregation switch to a PONs most obvious benefit is the increase in the
Network Interface Device (NID) located at the bandwidth delivered to the subscriber compared to
customer premises. legacy copper technologies. Using PON, service
providers can launch new bandwidth-intensive
Active fiber deployments are an excellent choice for applications. Other benefits of PON are: 1)
service providers when the customer is in an on-net significant reductions in fiber infrastructure, 2) large
building in a dense metropolitan area or in a new reductions in electrical cost and 3) reduced
infrastructure build-out. Fiber optics as an access maintenance requirements.
medium is also needed when Ethernet speeds are 1
Gbps or higher. The Ethernet Passive Optical Network (EPON)
standard was developed by the IEEE and the Gigabit
Benefits of Active Ethernet Passive Optical Network (GPON) by the ITU-T.
One major benefit of using fiber optic access EPON supports symmetrical 1 Gbps
technology is its ability to future-proof bandwidth and communications. GPON provides 1.25 Gbps
distance requirements. Fiber offers easy scalability to upstream and 2.5 Gbps downstream. MEF services
meet and adapt to the increasing customer needs, are supported on both platforms. Standards are also
which results in customer satisfaction and service underway at CableLabs for translation of DOCSIS
differentiation that enables profitability and customer management commands into Ethernet formats to
retention. Beyond its bandwidth capacity, fiber also manage EPON fiber access equipment. An upgrade
offers additional benefits such as being able to path to 10 Gbps exists for both PON types with work
transmit over greater distances and its inherent being done by the IEEE and ITU-T.
immunity to noise and interference.
Ethernet over SONET/SDH (EoS)
Often the best way to deliver Ethernet service is to
The CAPEX investment in fiber optic infrastructure is a
use what you have available period. With SONET
one-time investment with minimal recurring operational
and SDH equipment deployed nearly everywhere
cost. Fibers ability to service 100 Mbps, Gigabit and 10
fiber is, using this existing and highly reliable
Gigabit data rates as well as multiplex multiple channels
transport technology can be an obvious decision.
using Wavelength Division Multiplexing (WDM) enable it
While early implementations from equipment
to support any foreseeable future data rates.
vendors were lacking support for service
The distances that can be supported by a fiber differentiation and granular QoS, newer products are
infrastructure are limited only by the active interface MEF-certified and deliver a variety of sophisticated
hardware. Using standard optics, 2 km-150 km distances services from 1 Mbps up to over 1 Gbps. Ethernet
can be easily achieved. interface cards are available for modern
SONET/SDH transport equipment and low-cost
external devices are available for use when leasing
Ethernet over Passive Optical Networking (xPON) transport or when the existing SONET/SDH
PON is a point-to-multipoint optical access architecture
equipment cant support the services the carrier
that facilitates broadband communications between an
wishes to offer.
optical line terminal (OLT) at the central office and
multiple remote optical network units (ONUs) over a
purely passive optical-distribution network with a reach
MEF 2009. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with
permission of the MEF." No user of this document is authorized to modify any of the information contained herein. 4/09 v1 4 of 11
MEF White Paper: Delivering Ubiquitous Ethernet Services using the Worlds Access Technologies

Benefits of Ethernet over SONET/SDH (EoS) wherever fiber has been pulled. In addition, modern
Delivering Ethernet services over SONET/SDH allows circuit bonding protocols, such as virtual
the service provider to leverage infrastructure that is concatenation (VCAT), have helped make Ethernet
already in place using familiar transport technology. services over SONET/SDH available at fractions of
SONET/SDH networks have traditionally been the line rate, eliminating stranded capacity and
regarded as the gold standard for resiliency. This further driving down costs.
well-understood technology is widely available

Ethernet over PDH


If neither SONET/SDH nor Dark Fiber facilities are strengths, they all deliver comparable performance
available, service providers have found that the and are available from multiple equipment vendors.
existing PDH network, consisting of traditional
DS1/E1, DS3 and E3 standards enable them to Benefits of Bonded T1/E1
deliver Carrier Ethernet to locations that would The number one benefit that comes from using
otherwise be unreachable. bonded T1/E1 for delivering Ethernet services is
that service providers are able to reach all of their
Ethernet over Bonded T1/E1 customer locations, regardless of geography and
T1 at 1.544 Mbps and E1 at 2.048 Mbps have been proximity to their facilities. In addition, the
the dominant access technologies for business familiarity and turnkey nature of T1/E1 circuits
voice and data services for decades. From their means services can be turned up quickly, whether
humble beginnings as voice trunk line technologies access is on net or off net, allowing the service
to their more recent achievement as the gold provider to recognize revenue sooner and to
standard of Internet access for small and medium- decouple sales efforts from the infrastructure build
sized businesses, T1s and E1s have proven to be outs associated with many alternative technologies.
well-understood and versatile last-mile
technologies. Ethernet over DS3/E3
Just as T1/E1 is a desirable access technology for
These lines reach nearly every business in the delivering Ethernet service, DS3 and E3 circuits
modern world. Ethernet can be transported over provide another alternative using readily available
T1 and E1 as a single link or bonded group of links transport technology. Using DS3 and E3 circuits
allowing service providers to deliver Ethernet at and circuit bonding, the service provider can offer
rates from 1 Mbps up to 16 Mbps. Bonding brings Carrier Ethernet services at flexible rates from 1
with it the additional benefit of resiliency a feature Mbps 130 Mbps. Ethernet over DS3/E3 is not
demanded by many enterprise customers. only used as a retail service access technology, but
Because there are multiple links involved in the is often used as a low-cost infrastructure alternative
access method, it is inherently protected against for backhaul between remote co-location facilities
interruptions of one or more of those links for and points of presence.
example by a backhoe or an excavator.
Benefits of DS3/E3
There are three standardized methods for delivering The primary benefit of using DS3/E3 is to deliver
Ethernet over T1/E1 lines. These are: multilink Ethernet at rates greater than 3 Mbps over the
point to point protocol (MLPPP), GFP/VCAT and existing transport infrastructure. Rapid service turn-
G.bond or EFM. While each technology has its up and revenue recognition are additional side
benefits of leveraging this infrastructure.

Ethernet over Copper


Ethernet in the First Mile over Copper (EFMCu) Long reach 2BASE-TL, delivering a minimum of
allows fast deployment of resilient symmetrical 2 Mbit/s and a maximum of 5.69 Mbit/s over
Ethernet Access/Backhaul links over existing voice- distances of at least 2700 m, using standard
grade copper infrastructure, providing a very G.SHDSL.bis technology over a single copper
economical alternative to fiber. There are two pair.
standardized EFMCu technologies: Short reach 10PASS-TS, delivering a minimum
of 10 Mbit/s over distances of at least 750 m

MEF 2009. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with
permission of the MEF." No user of this document is authorized to modify any of the information contained herein. 4/09 v1 5 of 11
MEF White Paper: Delivering Ubiquitous Ethernet Services using the Worlds Access Technologies

(2460 ft), using VDSL technology over a single With Ethernet over Copper, service providers,
copper pair. governments and private enterprises have a cost-
effective solution for extending their Ethernet
Extensions to these standard technologies networks without having to deploy fiber.
developed by some equipment vendors have
enabled some service providers to improve on the Eliminating the need to install fiber optic cable
rate/reach curves provided by the standard removes a fundamental barrier that has inhibited
implementations. the adoption of Ethernet in the public network.
Using the multi-pair bonding service providers can
Both EFMCu technologies support an optional offer high performance (10-100 Mbps) service over
aggregation or bonding of multiple copper pairs (up a reliable infrastructure with resiliency built right in.
to 32), providing higher bandwidth, longer reach EFMCu using multi-pair bonding provides the
and improved resiliency. The aggregate bandwidth, subscriber with a fiber-like experience and gives the
in excess of 100 Mbps, offered by copper bonding service provider the ability to universally offer
solutions meet the needs of most bandwidth- Ethernet services over both fiber and copper media.
intensive Metro Ethernet applications.
Ethernet over Copper can also lower recurring
Benefits of Ethernet over Copper operational costs for CLECs or ILECs who are
Using the existing voice-grade copper infrastructure operating as CLECs in out-of-region territories.
keeps deployment costs to a minimum, as there is Using EFMCu, carriers can deliver Ethernet
no requirement for new cabling inside or outside the services over leased dry copper, which is typically
residence or business. much less expensive than alternatives.

By reducing service provider capital expenditures EFMCu is an attractive access solution for both
for implementation, EFMCu serves as the easiest, residential and business users and is spectrally
lowest-cost, and immediately deployable solution compatible with other legacy PSTN/ISDN, T1/E1
for providing feature-rich, high-speed access and and DSL services so they can co-exist in the same
services to subscribers. cables.

Wireless Ethernet
Where wireline services are not available or Microwave links may be licensed (filed and
practical, delivering Ethernet over a point-to-point protected by government agencies) or may be
wireless access network can make a previously unlicensed (through the use of low power within
infeasible connection practical. Also, where unlicensed regulatory limits).
mobility is required, broadband wireless services
from mobile service providers may provide an Broadband Wireless
excellent connectivity option. EVDO (Evolution of Existing Systems for Data
Only) is a common upgraded service of cellular
Terrestrial Microwave providers with CDMA (Code Division Multiple
A microwave link uses microwave frequencies Access) systems. EVDO Rev. A allows for a
(above 1 GHz) for line of sight radio maximum data transmission rate of approximately
communications (20 to 30 miles) between two 3.1 Mbps on the forward (downstream) channel.
directional antennas. Microwave link transceivers The EVDO Rev. A system uses the same reverse
are now available with standard Ethernet interfaces channel which limits the uplink data transmission
that can be used to deliver carrier Ethernet rate to approximately 1.8 Mbps. The EVDO system
services. The distance and throughput that can be has an upgraded packet data transmission control
achieved is a function of frequency and antenna system that allows for bursty data transmission
size. For example, 100 Mbps Fast Ethernet can be rather than for more continuous voice data
achieved reliably over 8 miles at 11 GHz but will transmission.
perform poorly over 15 miles due to rain fade at that
frequency. 100 Mbps Fast Ethernet can be GSM (Global System for Mobile) is the most
achieved reliably up to 30 miles at 6 GHz. popular standard for mobile phones in the world. Its
promoter, the GSM Association, estimates that 80%
The use of microwave links avoids the need to of the global mobile market uses the standard.
install cables between communication equipment. Release '97 of the standard added packet data
MEF 2009. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with
permission of the MEF." No user of this document is authorized to modify any of the information contained herein. 4/09 v1 6 of 11
MEF White Paper: Delivering Ubiquitous Ethernet Services using the Worlds Access Technologies

capabilities, by means of General Packet Radio WiMax was created by the WiMAX Forum and is a
Service (GPRS). The latest version of packet data wireless point-to-multi-point data transmission
communications are UMTS (Universal Mobile technology that is based on the IEEE 802.16
Telecommunications System) and HSDPA/HSPA+ standards. With its latest version, 802.16e adds
(High-Speed Downlink Packet Access/ High-Speed mobility and better support for quality of service as
Packet Access). These technologies enable well as symmetrical transmission capability of
download speeds of up to 42 Mbps (22 Mbps in typically 40 Mbps for fixed and 15 Mbps for mobile
upload). One of the main advantages of HSPA+ is implementation. As a "last mile" broadband wireless
its optional all-IP capability that is using native access, WiMAX can be used in the following
Ethernet connection to the base station. applications: replacement to legacy T1/E1, delivery
of triple-play services, backhaul technology for Wi-
LTE (Long Term Evolution or 3GPP) is the name Fi hotspots and mobile backhaul and for mobile
given to a project within the Third Generation emergency response services.
Partnership Project to improve the UMTS mobile
phone standard to cope with future technology Free Space Optics (FSO)
evolutions. Goals include improving spectral FSO is an alternative to the radio frequency
efficiency, lowering costs, improving services, wireless technologies previously described. While
making use of new spectrum and re-farmed the most common use of optical transmission is
spectrum opportunities, and better integration with through fiber optic cable, FSO enables service
other open standards. Being based on an all-IP providers to connect two points at a medium to long
infrastructure and native Ethernet connectivity, LTE distance (from an access perspective) through the
should provide 100 Mbps peak download rates. air and provide Gigabit Ethernet speeds. As light is
used instead of electro-magnetic signal, there is no
WiMAX (Worldwide Interoperability for need to purchase expensive radio spectrum,
Microwave Access). making FSO a complement to copper and fiber
communications.

Ethernet over HFC/DOCSIS


Hybrid fiber-coaxial (HFC) is an industry term for analog TV, digital TV (standard definition and
a broadband network which combines optical fiber HDTV), VoD, telephony, and high-speed data.
and coaxial cable. It has been commonly employed
by MSO/cable TV operators since the early 1990s. Data over Cable Service Interface Specification
(DOCSIS) is an international standard developed by
The fiber optic network extends from the cable CableLabs and contributing companies. DOCSIS
operators' master/regional head-end, to a defines the communications and operation support
neighborhoods hub site, and finally to a fiber optic interface requirements for a data over cable
node which serves anywhere from 25 to 2000 system. It permits the addition of high-speed data
homes. A master head-end will usually have transfer to an existing Cable TV (CATV) system. It
satellite dishes for reception of distant video signals is employed by many cable television operators to
as well as IP aggregation routers. Some master provide Internet access and Business Services over
head-ends also house telephony equipment for their existing (HFC) infrastructure.
providing telecommunications services to the
community. With its large coverage and available performance,
HFC/DOCSIS technology is a valuable asset for
By using frequency division multiplexing, an HFC Cable TV/MSO providers to deliver Ethernet-based
network may carry a variety of services, including services to the SOHO/SMB and high-speed Internet
access to residential customers.

MEF 2009. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with
permission of the MEF." No user of this document is authorized to modify any of the information contained herein. 4/09 v1 7 of 11
MEF White Paper: Delivering Ubiquitous Ethernet Services using the Worlds Access Technologies

Case Study Ubiquitous Ethernet Services in Action


Rexon Massey, Inc. is an environmental science company located in Florida. They specialize in data collection
and analysis. Their instruments measure hydrology, chemistry, strain, pressure, chromatography, vibration,
temperature, particulates, aerosols, and other critical variables of interest to business, industry and government.
Monitoring services are provided for clients large and small throughout the southeast in both urban and rural
areas. Data throughput requirements range from a few hundred kbps to 500Mbps depending on the application.
They also have truck-based mobile facilities used for temporary installations.

A ubiquitous, flexible, secure and diverse network is required to support all of Rexon Masseys customers. IT
Director Osvaldo Cardoso, working with the local cable operator in northern Florida created a network that
meets his challenging requirements. Because most of the Rexon Massey equipment has Ethernet ports, over
time he has created a large Ethernet WAN to collect data from remote locations.

The local cable company manages the primary network. It was able to reach many of the customer monitoring
locations with an EPON network that supports business and residential subscribers in the region. In some
cases the MSO contracts with the local ILEC or CLEC to reach locations using bonded T1s and SONET and in
some cases mid-band Ethernet over bonded copper pairs. To meet the needs of extremely remote off-net
locations, Cardoso created a wireless system for the mobile facilities that can be connected to most service
providers facilities. The core regional network aggregates these signals for transmission over the MSO fiber on
dedicated CWDM wavelengths.

Sample Access Connections into Rexon Masseys E-LAN Service


Access Service
B/W Access Media Application
Technology Provider
500kbps Wireless Wifi CLEC Hydrological pressure measurement
100Mbps Fiber Ethernet MSO Remote imaging and chemical analysis
4Mbps Copper - Twisted Pair EFMCu ILEC Water, air, wind, temperature
50Mbps Fiber Ethernet MSO Motion and air quality measurement
10Mbps Fiber Ethernet MSO Motion and air quality measurement
Broadband Wireless
500kbps Wireless Wireless Operator Hydrological pressure measurement
Ethernet over
10Mbps Copper T1 Bonded T1 ILEC Air quality measurement
Ethernet over
150Mbps Fiber SONET CLEC Remote imaging and chemical analysis
2Mbps Copper - Coaxial HFC/DOCSIS MSO Chemical analysis
Direct Fiber
500Mbps Fiber Ethernet MSO Remote imaging and chemical analysis
6Mbps Wireless Microwave MSO Solar, humidity, wind and other
3Mbps Copper - Coaxial HFC/DOCSIS MSO Chemical analysis

Integrating diverse access media and protocols into a seamless Ethernet services network is facilitated by work
at the MEF. MEF specifications on UNI Type 1 and Ethernet service definitions ensure that there are
commonly accepted service parameters and hardware interfaces to connect Ethernet ports anywhere on the
network. OAMP work by the MEF ensures that Cardoso has the management tools necessary to monitor
network performance and diagnose network issues. Cardoso uses E-LAN configurations to separate traffic into
VLANS to ensure data integrity.

Rexon Masseys work is only possible with high-speed, real-time data input and analysis. Ethernet services
provide the necessary platform for gathering this data on a cost-effective heterogeneous network. Cooperation
among Masseys service providers ensures they can collect data wherever they have customers.

MEF 2009. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with
permission of the MEF." No user of this document is authorized to modify any of the information contained herein. 4/09 v1 8 of 11
MEF White Paper: Delivering Ubiquitous Ethernet Services using the Worlds Access Technologies

Summary
In conclusion, in order to realize the full potential of an Ethernet service offering, and in order to maximize the
revenue from these services, delivering ubiquitous Ethernet is critical. Only by doing so can service providers
deliver services everywhere, to all customer locations, using the technology that is best suited for each
application.

Follow up or Questions
Please send any question or comment to the following email address: access@metroethernetforum.net.
Your email will be treated confidentially within the Access Technologies Working group. We will respond within
one cycle of our bi-weekly working group meetings.

MEF Specifications and Access Technology Standards


The table below summarizes the various standards used to deliver Ethernet over the access technologies
discussed in this paper.

Carrier Ethernet MEF Specification

E-Line, E-LAN and MEF 6.1 Metro Ethernet Services Definitions Phase 2
E-Tree Services MEF 10.1 Ethernet Services Attributes Phase 2
PDH/Circuit MEF 3: Circuit Emulation Service Definitions, Framework and Requirements
emulation MEF 8: Implementation Agreement for the Emulation of PDH Circuits
Mobile Backhaul MEF 22: Carrier Ethernet for Mobile Backhaul Implementation Agreement
MEF 9: Ethernet Services at the UNI
Test/Certification
MEF 14: Traffic Management
Carrier Ethernet
Technology Alternatives Applicable Standards
Access Method
Active Fiber - IEEE 802.3-2005
- ITU-T X.86 encapsulation
Ethernet over SONET/SDH
Ethernet over - ITU-T G.707 and G.7043 (GFP-VCAT)
Fiber - IEEE 802.3-2005 (EPON)
Passive Optical Network - IEEE 802.3av (10GEPON)
- ITU-T G.984 (GPON)
- RFC1990 (Multilink PPP) and RFC3518 (BCP)
Bonded T1/E1 - ITU-T G.7041 and G.7043 (GFP-VCAT)
Ethernet over - ITU-T G.998.2 (G.bond)
PDH - ITU-T X.86 encapsulation with optional link aggregation
DS3/E3 and bonded
- ITU-T G.7041 and G.7043 (GFP-VCAT)
DS3/E3
- ITU-T G.998.2 (G.bond)
- IEEE 802.3-2005 2BASE-TL using ITU-T G.991.2
2BASE-TL
Ethernet over (G.SHDSL.bis)
Copper - IEEE 802.3-2005 10PASS-TS using ITU-T G.993.1
10PASS-TS
(VDSL)
Terrestrial microwave - IEEE 802.3-2005 user interface
WiMAX - IEEE 802.16
- 3GPP Rel. 7 (HSDPA/HSPA+)
Wireless Ethernet Broadband wireless - 3GPP Rel. 8 (LTE)
- CDMA2000 EV-DO rev.A TIA-856 (EVDO)
Free space optics - IEEE 802.3-2005 user interface
WiFi - IEEE 802.11
Hybrid Fiber Coax DOCSIS - DOCSIS 1.x, 2.x, 3.0, EuroDOCSIS

MEF 2009. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with
permission of the MEF." No user of this document is authorized to modify any of the information contained herein. 4/09 v1 9 of 11
MEF White Paper: Delivering Ubiquitous Ethernet Services using the Worlds Access Technologies

Glossary of Abbreviations
3GPP Third Generation Partnership Project ITU-T International Telecommunication Union
(Standardization body developing GSM Telecommunication Standardization
technologies) Sector
3GPP2 Third Generation Partnership Project 2 LAN Local Area Network
(Standardization body developing LLDP Link Layer Discovery Protocol
CDMA technologies) LTE Long Term Evolution
ADM Add Drop Multiplexer MEF New name for entity formerly known as
ARP Address Resolution Protocol Metro Ethernet Forum
ATM Asynchronous Transfer Mode MLPPP Multi-Link Point-To-Point Protocol
BCP Bridging Control Protocol MSO Multiple Service Operator (Comcast,
BPDU Bridge Protocol Data Unit COX, Time Warner Cable, etc)
BWA Broadband Wireless Access NID Network Interface Device
CDMA Code Division Multiple Access OAM Operations, Administration and
CFM Connectivity Fault Management Maintenance
CLEC Competitive Local Exchange Carrier OLO Other Licensed Operator
CWDM Coarse Wave Division Multiplexing OLT Optical Line Termination
DOCSIS Data over Cable Service Interface PDH Plesiochronous Digital Hierarchy
Specification QoS Quality of service
DS3 Digital Signal level 3 RFI Request for Information
DSL Digital Subscriber Line (as in xDSL) RFP Request for Proposal
E1 European PDH signal level 1 RFQ Request for Quotation
E3 European PDH signal level 3 SDH Synchronous Digital Hierarchy
EFM Ethernet in the First Mile SHDSL Single-Pair High-Speed Digital
EFMCu Ethernet in the First Mile Copper Subscriber Line
E-LAN Ethernet-LAN Service SLA Service Level Agreement
E-Line Ethernet Point-to-Point SLO Service Level Objectives
EoS Ethernet over SONET/SDH SLS Service Level Specifications
EPL Ethernet Private Line SMB Small and Medium Business
EPON Ethernet Passive Optical Network SOHO Small Office, Home Office
EVC Ethernet Virtual Connection SONET Synchronous Optical NETwork
EVDO Evolution of Existing Systems for Data T1 Telecommunications level 1
Only TDM Time Division Multiplexing
EVPL Ethernet Virtual Private Line UMTS Universal Mobile Telecommunications
FSO Free Space Optics System
GFP Generic Framing Protocol UNI User to Network Interface
GPRS General Packet Radio Service VCAT Virtual Concatenation
GSM Global System for Mobile VDSL Very High Speed Digital Subscriber Line
HFC Hybrid Fiber Coax VLAN Virtual LAN
HSDPA High-Speed Downlink Packet Access VoD Video on Demand
HSPA High-Speed Packet Access WiMAX Worldwide Interoperability for Microwave
IEEE Institute of Electrical & Electronics Access
Engineers WDM Wave Division Multiplexing
IETF Internet Engineering Task Force
ILEC Incumbent Local Exchange Carrier

MEF 2009. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with
permission of the MEF." No user of this document is authorized to modify any of the information contained herein. 4/09 v1 10 of 11
MEF White Paper: Delivering Ubiquitous Ethernet Services using the Worlds Access Technologies

Disclaimer
The information in this publication is believed to be accurate as of its publication date. Such information is
subject to change without notice and the MEF is not responsible for any errors. The MEF does not assume any
responsibility to update or correct any information in this publication. Notwithstanding anything to the contrary,
neither The MEF nor the publisher make any representation or warranty, expressed or implied, concerning the
completeness, accuracy, or applicability of any information contained in this publication. No liability of any kind
shall be assumed by the MEF or the publisher as a result of reliance upon any information contained in this
publication.
About the Metro Ethernet Forum
The MEF is a non-profit organization dedicated to accelerating the worldwide adoption of Carrier Ethernet. The
MEF comprises leading service providers, local exchange carriers, cable operators, network equipment
manufacturers and other prominent networking companies that share an interest in Carrier Ethernet. As of
March 2009, the MEF has 154 members.

Contributors
Contributor Company
Jon Collins Transition Networks
Eric Doricko Calix
D. Mark Durrett Overture Networks
Fred Ellefson ADVA Optical Networking
Bruno Giguere EXFO
Craig Goodwin Adtran
Richard Goss Verizon
Mannix OConnor Hitachi
Eric Vallone Actelis Networks

MEF 2009. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with
permission of the MEF." No user of this document is authorized to modify any of the information contained herein. 4/09 v1 11 of 11
Technical Specification
MEF 10.2

Ethernet Services Attributes Phase 2

27 October 2009

MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, 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.
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 2009. All Rights Reserved.

MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, 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.
Ethernet Services Attributes Phase 2

Table of Contents
1. Abstract................................................................................................................................ 1

2. Terminology......................................................................................................................... 1

3. Scope..................................................................................................................................... 5

4. Compliance Levels .............................................................................................................. 6

5. Introduction ......................................................................................................................... 6

6. Ethernet Virtual Connection Service Attributes ............................................................. 7


6.1 Ethernet Virtual Connection Type Service Attribute ........................................................ 8
6.1.1 Point-to-Point EVC ................................................................................................................. 8
6.1.2 Multipoint EVCs ..................................................................................................................... 8
6.1.2.1 Multipoint-to-Multipoint EVC ............................................................................................. 8
6.1.2.2 Rooted-Multipoint EVC ....................................................................................................... 9
6.2 EVC ID Service Attribute.................................................................................................. 9
6.3 UNI List Service Attribute .............................................................................................. 10
6.4 Maximum Number of UNIs Service Attribute ................................................................ 10
6.5 Service Frame Delivery Service Attributes ..................................................................... 10
6.5.1 Types of Service Frame ........................................................................................................ 10
6.5.1.1 Unicast Service Frame ...................................................................................................... 10
6.5.1.2 Multicast Service Frame .................................................................................................... 10
6.5.1.3 Broadcast Service Frame .................................................................................................. 10
6.5.1.4 Layer 2 Control Protocol Service Frame .......................................................................... 10
6.5.1.5 Data Service Frame ........................................................................................................... 11
6.5.2 Service Frame Disposition .................................................................................................... 11
6.5.3 Service Frame Transparency ................................................................................................. 12
6.6 CE-VLAN Tag Preservation Service Attributes ............................................................. 12
6.6.1 CE-VLAN ID Preservation Service Attribute ....................................................................... 12
6.6.2 CE-VLAN CoS Preservation Service Attribute .................................................................... 13
6.7 EVC Layer 2 Control Protocol Processing Service Attribute ......................................... 13
6.8 Class of Service Identifier Service Attribute ................................................................... 14
6.8.1 Class of Service Identifier Based on EVC ............................................................................ 14
6.8.2 Class of Service Identifier Based on Priority Code Point Field ............................................ 15
6.8.3 Class of Service Identifier Based on DSCP .......................................................................... 15
6.8.4 Class of Service Identifier Based on Layer 2 Control Protocol ............................................ 15
6.9 EVC Related Performance Service Attributes................................................................. 15
6.9.1 Frame Delay Performance for a Point-to-Point EVC ............................................................ 16
6.9.2 One-way Frame Delay Performance for an EVC .................................................................. 17
6.9.3 Inter-Frame Delay Variation Performance for a Point-to-Point EVC ................................... 20
6.9.4 Inter-Frame Delay Variation Performance for an EVC ........................................................ 21
6.9.5 One-way Frame Loss Ratio Performance for a Point-to-Point EVC .................................... 24
6.9.6 One-way Frame Loss Ratio Performance for an EVC .......................................................... 24
6.9.7 Availability Performance for a Point-to-Point EVC ............................................................. 25
6.9.8 Availability Performance for a Multipoint EVC ................................................................... 28
6.10 EVC Maximum Transmission Unit Size Service Attribute............................................. 29

MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page i
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.
Ethernet Services Attributes Phase 2

7. UNI and EVC per UNI Service Attributes ..................................................................... 29


7.1 UNI Identifier Service Attribute ...................................................................................... 30
7.2 Physical Layer Service Attribute ..................................................................................... 30
7.3 MAC Layer Service Attribute ......................................................................................... 30
7.4 UNI Maximum Transmission Unit Size Service Attribute ............................................. 31
7.5 Service Multiplexing Service Attribute ........................................................................... 31
7.6 Identifying an EVC at the UNI ........................................................................................ 31
7.6.1 Customer Edge VLAN ID ..................................................................................................... 31
7.6.2 UNI EVC ID Service Attribute ............................................................................................. 32
7.7 CE-VLAN ID/EVC Map Service Attribute..................................................................... 32
7.7.1 Basic Concept........................................................................................................................ 32
7.7.2 CE-VLAN ID Significance ................................................................................................... 33
7.7.3 Describing the Contents of the CE-VLAN ID/EVC Map ..................................................... 34
7.8 Maximum Number of EVCs Service Attribute ............................................................... 34
7.9 Bundling Service Attribute .............................................................................................. 34
7.10 All to One Bundling Service Attribute ............................................................................ 35
7.11 Bandwidth Profiles Service Attributes ............................................................................ 36
7.11.1 Standard Bandwidth Profile Parameters and Algorithm ....................................................... 36
7.11.2 Ingress Bandwidth Profiles Service Attributes ..................................................................... 39
7.11.2.1 Ingress Bandwidth Profile per Ingress UNI Service Attribute .......................................... 39
7.11.2.2 Ingress Bandwidth Profile per EVC Service Attribute ...................................................... 39
7.11.2.3 Ingress Bandwidth Profile per Class of Service Identifier Service Attribute .................... 40
7.11.2.4 Simultaneous Application of the Ingress Bandwidth Profile Application Models............. 40
7.11.2.5 Service Frame Disposition ................................................................................................ 41
7.11.3 Egress Bandwidth Profiles Service Attributes ...................................................................... 41
7.11.3.1 Egress Bandwidth Profile per Egress UNI Service Attribute ............................................ 42
7.11.3.2 Egress Bandwidth Profile per EVC Service Attribute ....................................................... 43
7.11.3.3 Egress Bandwidth Profile per Class of Service Identifier Service Attribute ..................... 44
7.11.3.4 Simultaneous Application of the Egress Bandwidth Profile Application Models.............. 44
7.12 Security ............................................................................................................................ 44
7.13 UNI Layer 2 Control Protocol Processing Service Attribute .......................................... 44
7.13.1 Discard .................................................................................................................................. 44
7.13.2 Peer........................................................................................................................................ 45
7.13.3 Pass to EVC........................................................................................................................... 45
7.13.4 Peer and Pass to EVC ............................................................................................................ 45
8. Ethernet Service Framework ........................................................................................... 45
8.1 Ethernet Service Types .................................................................................................... 46
8.2 Service Attributes ............................................................................................................ 46
8.3 Service Attribute Parameters ........................................................................................... 46
8.4 Ethernet Service Framework Summary........................................................................... 47
9. References .......................................................................................................................... 49

10. Appendix (Informative) .................................................................................................... 50


10.1 CE-VLAN ID Preservation Service Attribute ................................................................. 51
10.1.1 CE-VLAN ID Preservation = Yes ......................................................................................... 51
10.1.2 CE-VLAN ID Preservation = No .......................................................................................... 52
10.2 Examples of the Use of the CE-VLAN ID/EVC Map and EVCs ................................... 53
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page ii
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.
Ethernet Services Attributes Phase 2
10.2.1 Untagged UNIs...................................................................................................................... 53
10.2.2 Use of Rooted-Multipoint EVC ............................................................................................ 54
10.2.3 Redundant Higher Layer Service Access .............................................................................. 55
10.3 Traffic Shaping ................................................................................................................ 55
10.4 Examples of Availability Metrics for Multipoint EVCs ................................................. 57
10.4.1 UNI-oriented Availability Example ...................................................................................... 58
10.4.2 EVC-oriented Availability Example ..................................................................................... 59

List of Figures
Figure 1 Ethernet Services Model................................................................................................ 7
Figure 2 Point-to-Point EVCs ...................................................................................................... 8
Figure 3 Multipoint-to-Multipoint EVC ...................................................................................... 9
Figure 4 Rooted-Multipoint EVC ................................................................................................ 9
Figure 5 - Frame Delay for Service Frame ................................................................................... 17
Figure 6 Inter-Frame Delay Variation Definition ...................................................................... 22
Figure 7 Examples of the Calculation of I (S k ) ........................................................................ 27
Figure 8 Example of Service Multiplexing on UNI A ............................................................... 31
Figure 9 Example of a CE-VLAN ID/EVC Map....................................................................... 33
Figure 10 Example of CE-VLAN ID/EVC Maps at Two UNIs ................................................ 34
Figure 11 Example of Bundling................................................................................................. 35
Figure 12 Example of a Simple Description of Bundling.......................................................... 35
Figure 13 The Bandwidth Profile Algorithm ............................................................................. 38
Figure 14 Ingress Bandwidth Profile per Ingress UNI .............................................................. 39
Figure 15 Ingress Bandwidth Profile per EVC .......................................................................... 40
Figure 16 Ingress Bandwidth Profile per Class of Service Identifier ........................................ 40
Figure 17 Egress Bandwidth Profile per Egress UNI ................................................................ 43
Figure 18 Egress Bandwidth Profile per EVC ........................................................................... 43
Figure 19 Ethernet Service Framework ..................................................................................... 46
Figure 20 CE-VLAN ID/EVC Map Notation ............................................................................ 51
Figure 21 Example 1: CE-VLAN ID Preservation = Yes with All to One Bundling................ 51
Figure 22 Example 2: CE-VLAN ID Preservation = Yes with Bundling on EVC2.................. 51
Figure 23 CE-VLAN ID/EVC Map Notation ............................................................................ 52
Figure 24 Example 3: CE-VLAN ID Preservation = No ........................................................... 53
Figure 25 Untagged UNIs .......................................................................................................... 54
Figure 26 Use of a Rooted-Multipoint EVC .............................................................................. 55
Figure 27 Redundant Higher Layer Service Access .................................................................. 55
Figure 28 Periodic Algorithm .................................................................................................... 56
Figure 29 New Frame Algorithm............................................................................................... 57
Figure 30 Multipoint EVC Example .......................................................................................... 58

List of Tables
Table 1 List of Standardized Layer 2 Control Protocols ........................................................... 11
Table 2 CE-VLAN ID Preservation for a Service Frame .......................................................... 13
Table 3 CE-VLAN ID Preservation Service Attribute for an EVC ........................................... 13
Table 4 One-way Frame Delay Performance Parameters .......................................................... 20
Table 5 Inter-Frame Delay Variation Parameters ...................................................................... 23
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page iii
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.
Ethernet Services Attributes Phase 2

Table 6 One-way Frame Loss Ratio Performance Parameters .................................................. 25


Table 7 Availability Performance Parameters for a Point-to-Pointe EVC ................................ 28
Table 8 Availability Performance Parameters for a Multipoint EVC........................................ 29
Table 9 Possible Physical Layer Characteristics ....................................................................... 30
Table 10 Valid Combinations of Service Multiplexing, Bundling, and All to One Bundling .. 36
Table 11 Service Frame Disposition for Each Egress UNI ........................................................ 41
Table 12 UNI and EVC per UNI Service Attributes ................................................................. 48
Table 13 EVC Service Attributes .............................................................................................. 49

MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page iv
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.
Ethernet Services Attributes Phase 2

1. Abstract

The attributes of Ethernet Services observable at a User Network Interface (UNI) and from User
Network Interface to User Network Interface (UNI to UNI) are defined. In addition, a framework
for defining specific instances of Ethernet Services is described. This document supersedes and
replaces MEF 10 [7].

2. Terminology
All to One Bundling A UNI attribute in which all CE-VLAN IDs are associated with
a single EVC.
Availability Performance A measure of the percentage of time that a service is useable.

Broadcast Service Frame A Service Frame that has the broadcast destination MAC
address.
Bundling A UNI attribute in which more than one CE-VLAN ID can be
associated with an EVC.
CBS Committed Burst Size
CE Customer Edge
CE-VLAN CoS Customer Edge VLAN CoS
CE-VLAN ID Customer Edge VLAN ID
CE-VLAN ID Preservation An EVC attribute in which the CE-VLAN ID of an egress
Service Frame is identical in value to the CE-VLAN ID of the
corresponding ingress Service Frame.
CE-VLAN ID/EVC Map An association of CE-VLAN IDs with EVCs at a UNI.
CE-VLAN Tag Customer Edge VLAN Tag
CF Coupling Flag
CIR Committed Information Rate
Class of Service A set of Service Frames that have a commitment from the
Service Provider to receive a particular level of performance.
Class of Service Identifier Information derivable from a) the EVC to which the Service
Frame is mapped, b) the combination of the EVC to which the
Service Frame is mapped and a set of one or more CE-VLAN
CoS values, c) the combination of the EVC to which the
Service Frame is mapped and a set of one or more DSCP
values, or d) the combination of the EVC to which the Service
Frame is mapped and a set of one or more tunneled Layer 2
Control Protocols.

MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

CM Color Mode
Color Mode CM is a Bandwidth Profile parameter. The Color Mode
parameter indicates whether the color-aware or color-blind
property is employed by the Bandwidth Profile. It takes a value
of color-blind or color-aware only.
Color-aware A Bandwidth Profile property where a pre-determined level of
Bandwidth Profile compliance for each Service Frame is taken
into account when determining the level of compliance for each
Service Frame.
Color-blind A Bandwidth Profile property where a pre-determined level of
Bandwidth Profile compliance for each Service Frame, if
present, is ignored when determining the level of compliance
for each Service Frame.
Committed Burst Size CBS is a Bandwidth Profile parameter. It limits the maximum
number of bytes available for a burst of Service Frames sent at
the UNI speed to remain CIR-conformant.
Committed Information CIR is a Bandwidth Profile parameter. It defines the average
Rate rate in bits/s of Service Frames up to which the network
delivers Service Frames and meets the performance objectives
defined by the CoS Service Attribute.
CoS Class of Service
Coupling Flag CF is a Bandwidth Profile parameter. The Coupling Flag allows
the choice between two modes of operation of the rate
enforcement algorithm. It takes a value of 0 or 1 only.
Customer Edge Equipment on the Subscriber side of the UNI.
Customer Edge VLAN CoS The Priority Code Point bits in the IEEE 802.1Q Customer
VLAN Tag [10] in a Service Frame that is either tagged or
priority tagged.
Customer Edge VLAN ID The identifier derivable from the content of a Service Frame
that allows the Service Frame to be associated with an EVC at
the UNI.
Customer Edge VLAN Tag The IEEE 802.1Q Customer VLAN Tag [10] in a tagged
Service Frame.
Data Service Frame A Service Frame that is Unicast, Multicast, or Broadcast.
EBS Excess Burst Size
Egress Bandwidth Profile A service attribute that specifies the length and arrival time
characteristics of egress Service Frames at the egress UNI.

MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

Egress Service Frame A Service Frame sent from the Service Provider network to the
CE.
EIR Excess Information Rate
E-LAN Service Ethernet LAN Service
E-Line Service Ethernet Line Service
Ethernet LAN Service An Ethernet Service Type distinguished by its use of a
Multipoint-to-Multipoint EVC.
Ethernet Line Service An Ethernet Service Type distinguished by its use of a Point-to-
Point EVC.
Ethernet Virtual An association of two or more UNIs that limits the exchange of
Connection Service Frames to UNIs in the Ethernet Virtual Connection.
EVC Ethernet Virtual Connection
EVC Maximum The maximum sized Service Frame allowed for an EVC.
Transmission Unit Size
Excess Burst Size EBS is a Bandwidth Profile parameter. It limits the maximum
number of bytes available for a burst of Service Frames sent at
the UNI speed to remain EIR-conformant.
Excess Information Rate EIR is a Bandwidth Profile parameter. It defines the average
rate in bits/s of Service Frames up to which the network may
deliver Service Frames but without any performance objectives.
FD Frame Delay

FLR Frame Loss Ratio


Frame Short for Ethernet frame.
Frame Delay The time required to transmit a Service Frame from ingress
UNI to egress UNI.
Frame Delay Performance A measure of the delays experienced by different Service
Frames belonging to the same CoS instance.
Frame Delay Range The difference between the Frame Delay Performance values
corresponding to two different percentiles.
Frame Delay Range A measure of the extent of delay variability experienced by
Performance different Service Frames belonging to the same CoS instance.
Frame Loss Ratio Frame Loss Ratio is a measure of the number of lost frames
Performance between the ingress UNI and the egress UNI. Frame Loss Ratio
is expressed as a percentage.

MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

Ingress Bandwidth Profile A characterization of ingress Service Frame arrival times and
lengths at the ingress UNI and a specification of disposition of
each Service Frame based on its level of compliance with the
characterization.
Ingress Service Frame A Service Frame sent from the CE into the Service Provider
network.
IFDV Inter-Frame Delay Variation
Inter-Frame Delay The difference in delay of two Service Frames belonging to the
Variation same CoS instance.
Inter-Frame Delay A measure of the variation in the delays experienced by
Variation Performance different Service Frames belonging to the same CoS instance.
Layer 2 Control Protocol A Service Frame that is used for Layer 2 control, e.g., Spanning
Service Frame Tree Protocol.
Layer 2 Control Protocol The process by which a Layer 2 Control Protocol Service
Tunneling Frame is passed through the Service Provider network without
being processed and is delivered unchanged to the proper
UNI(s).
Maximum Number of UNIs The maximum number of UNIs that may be in an EVC.
Mean Frame Delay The arithmetic mean, or average of delays experienced by
Performance different Service Frames belonging to the same CoS instance.
MNU Maximum Number of UNIs
Multicast Service Frame A Service Frame that has a multicast destination MAC address.
Multipoint-to-Multipoint An EVC with two or more UNIs. A Multipoint-to-Multipoint
EVC EVC with two UNIs is different from a Point-to-Point EVC
because one or more additional UNIs can be added to it.
Ordered Pair of UNIs A directional UNI pair of the form <Ingress UNI, Egress UNI>,
selected from the UNI list for the EVC of interest.
Point-to-Point EVC An EVC with exactly 2 UNIs.
Qualified Set of Service The set of frames that comply with specific criteria, such as the
Frames arrival time at the Ingress UNI and Bandwidth Profile
compliance, on which a performance attribute is based.
Rooted-Multipoint EVC A multipoint EVC in which each UNI is designated as either a
Root or a Leaf. Ingress Service Frames at a Root UNI can be
delivered to one or more of any of the other UNIs in the EVC.
Ingress Service Frames at a Leaf UNI can only be delivered to
one or more Root UNIs in the EVC.

MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

Scheduled Downtime A time interval agreed upon by both the Subscriber and Service
Provider during which a service may be disabled by the Service
Provider.
Service Frame An Ethernet frame transmitted across the UNI toward the
Service Provider or an Ethernet frame transmitted across the
UNI toward the Subscriber.
Service Level Agreement The contract between the Subscriber and Service Provider
specifying the agreed to service level commitments and related
business agreements.
Service Level Specification The technical specification of the service level being offered by
the Service Provider to the Subscriber.
Service Multiplexing A UNI service attribute in which the UNI can be in more than
one EVC instance.
Service Provider The organization providing Ethernet Service(s).
SLA Service Level Agreement
SLS Service Level Specification
Subscriber The organization purchasing and/or using Ethernet Services.
UNI User Network Interface
Unicast Service Frame A Service Frame that has a unicast destination MAC address.
UNI Maximum The maximum sized Service Frame allowed at the UNI.
Transmission Unit Size
Unscheduled Downtime A time interval not agreed upon by both the Subscriber and
Service Provider during which the Service Provider determines
that the service is not usable.
User Network Interface The physical demarcation point between the responsibility of
the Service Provider and the responsibility of the Subscriber.

3. Scope

This document describes Ethernet Service attributes. The Ethernet Services are modeled from the
point of view of the Subscribers equipment referred to as the Customer Edge (CE) that is used
to access the service. The basic elements of Ethernet Services are defined. In addition, a number
of Service Attributes are defined that may be offered as part of an Ethernet Service including the
definition of Service Level Specification. This document supersedes and replaces MEF 10,
Ethernet Services Attributes Phase 1 [7].

The goals of this Technical Specification are two-fold. The first goal is to provide sufficient
technical specificity to allow a Subscriber to successfully plan and integrate Ethernet Services
into his or her overall networking infrastructure. The second goal is to provide enough detail so

MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

that Customer Edge equipment vendors can implement capabilities into their products so that
they can be used to successfully access Ethernet Services. It follows as a corollary that vendors
of Service Provider network equipment will make use of this information for implementing
functions that complement the functions in the CE.

This specification includes the following topics that are in addition or changes to the material of
[7]:

A new type of EVC, the Rooted-Multipoint EVC is defined (Section 6.1.2.2).

Performance metrics for Multipoint EVCs are defined (Sections 6.9.2, 6.9.4, 6.9.6, and
6.9.8).

An Availability Performance metric is defined for EVCs (Sections 6.9.7 and 6.9.8).

A new Class of Service Identifier based on DSCP is defined (Section 6.8.3).

The Egress Bandwidth Profile is defined (Section 7.11.3).

The definition of CE-VLAN ID Preservation has been slightly modified in the interest of
aligning with the emerging Provider Bridges Standard of IEEE 802.1ad 2005 [10]
(Section 6.6.1).

The maximum transmission unit size at the UNI is defined (Section 7.4).

The maximum transmission unit size for an EVC is defined (Section 6.10).

Maximum number of UNIs in a multipoint EVC is defined (Section 6.4).

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[1]. All key words must be in upper
case, bold text.

5. Introduction

This document provides the model and framework for Ethernet Services. The model is built on
the reference model as shown in Figure 1.

MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

Customer User Network User Network Customer


Edge Interface Interface Edge
(CE) (UNI) (UNI) (CE)

Service Provider Metro


Ethernet Network

Figure 1 Ethernet Services Model

The technical definition of a service is in terms of what is seen by each Customer Edge (CE).
This includes the User Network Interface (UNI), which is the physical demarcation point
between the responsibility of the Service Provider and the responsibility of the Subscriber. A
UNI MUST be dedicated to a single Subscriber. 1

The CE and MEN exchange Service Frames across the UNI. A Service Frame is an Ethernet [2]
frame transmitted across the UNI toward the Service Provider (called an ingress Service Frame)
or an Ethernet [2] frame transmitted across the UNI toward the Subscriber (called an egress
Service Frame). The Service Frame consists of the first bit of the Destination MAC Address
through the last bit of the Frame Check Sequence. The protocol as seen by the CE operating at
the UNI MUST be standard Ethernet [2] with the exception that may have a length greater than
that specified in [2]. (See Section 6.10 and Section 7.4.) There are no assumptions about the
details of the Metro Ethernet Network. It could consist of a single switch or an agglomeration of
networks based on many different technologies. Management of the services is not addressed in
this document. See MEF 7, EMS-NMS Information Model [12], for the management perspective
of the Ethernet Phase 1 service attributes.

Connectivity between UNIs is specified by the Ethernet Virtual Connection (EVC). There are a
number of types of EVC and a number of service attributes that an EVC can have. These are
described in Section 6.

There are a number of different service attributes for a UNI. These are described in Section 7.

Section 8 contains a framework for defining a service. Attributes used in this framework include
Ethernet Virtual Connection type, traffic parameters, Service Frame delivery, and performance.

6. Ethernet Virtual Connection Service Attributes

A fundamental aspect of Ethernet Services is the Ethernet Virtual Connection (EVC). An EVC is
an association of two or more UNIs. These UNIs are said to be in the EVC. A given UNI can
support more than one EVC via the Service Multiplexing attribute as described in Section 7.4.

1
Multiplexing traffic from multiple Subscribers onto a single link can be a valuable function but is an internal MEN
function and is not visible at the UNI.
MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

An ingress Service Frame that is mapped to the EVC (see Section 7.6) can be delivered to one or
more of the UNIs in the EVC other than the ingress UNI. It MUST NOT be delivered back to
the ingress UNI. 2 It MUST NOT be delivered to a UNI not in the EVC. An EVC is always bi-
directional in the sense that ingress Service Frames can originate at any UNI in an EVC.

6.1 Ethernet Virtual Connection Type Service Attribute

There are three types of EVC. They are as described in Sections 6.1.1, 6.1.2.1, and 6.1.2.2.

6.1.1 Point-to-Point EVC

In a Point-to-Point EVC, exactly two UNIs MUST be associated with one another. An ingress
Service Frame mapped (see Section 7.7) to the EVC at one UNI MUST NOT result in an egress
Service Frame at a UNI other than the other UNI in the EVC. The rules under which a Service
Frame is delivered to the destination UNI are specific to the particular service definition. Figure
2 illustrates two Point-to-Point EVCs.

EVC1

EVC2

Figure 2 Point-to-Point EVCs

6.1.2 Multipoint EVCs

In a Multipoint EVC, two 3 or more UNIs MUST be associated with one another. An ingress
Service Frame mapped to the EVC at one of the UNIs MUST NOT result in an egress Service
Frame at a UNI that is not in the EVC.

6.1.2.1 Multipoint-to-Multipoint EVC

In a Multipoint-to-Multipoint EVC, the rules under which a frame is delivered to a UNI in the
EVC are specific to the particular service definition. Typically, a single broadcast or multicast
ingress Service Frame (as determined from the destination MAC address) at a given UNI would
be replicated in the Metro Ethernet Network and a single copy would be delivered to each of the
other UNIs in the EVC. This kind of delivery would also typically apply to a Service Frame for
which the MEN has not yet learned an association of the destination MAC address with an EVC,
UNI pair. Figure 3 illustrates a Multipoint-to-Multipoint EVC.

2
There may be frames that are not Service Frames that should be delivered back to the ingress UNI. An example
might be a loop-back frame. These kinds of frames are beyond the scope of this Technical Specification.
3
A Multipoint-to-Multipoint EVC with two UNIs is different from a Point-to-Point EVC because one or more
additional UNIs can be added to the Multipoint-to-Multipoint EVC.
MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

Figure 3 Multipoint-to-Multipoint EVC

6.1.2.2 Rooted-Multipoint EVC

In a Rooted-Multipoint EVC, one or more of the UNIs MUST be designated as a Root and each
of the other UNIs MUST be designated as a Leaf. An ingress Service Frame mapped to the EVC
at a Root UNI MAY be delivered to one or more of the other UNIs in the EVC. An ingress
Service Frame mapped to the EVC at a Leaf UNI MUST NOT result in an egress Service Frame
at another Leaf UNI but MAY result in an egress Service Frame at some or all of the Root UNIs.
The rules under which a frame is delivered to a UNI in the EVC are specific to the particular
service definition. Typically, a single broadcast or multicast ingress Service Frame (as
determined from the destination MAC address) at a Root UNI would be replicated in the Metro
Ethernet Network and a single copy would be delivered to each of the other UNIs in the EVC.
This kind of delivery would also typically apply to a Service Frame for which the MEN has not
yet learned an association of the destination MAC address with an EVC, UNI pair. Figure 4
illustrates a Rooted-Multipoint EVC with one Root UNI.
Leaf
Root

Leaf

Broadcast, multicast and unicast unknown

Known unicast

Broadcast, multicast and unicast

Figure 4 Rooted-Multipoint EVC

6.2 EVC ID Service Attribute

The EVC ID is an arbitrary string administered by the Service Provider that is used to identify an
EVC within the MEN. The EVC ID MUST be unique across all EVCs in the MEN. It is intended
for management and control purposes. The EVC ID is not carried in any field in the Service
Frame. As an example, the Acme Service Provider might use EVC-0001898-ACME-
MEGAMART to represent the 1898th EVC in the MEN and the customer for the EVC is
MegaMart.

MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

6.3 UNI List Service Attribute

The UNI List for an EVC is a list of pairs of the form <UNI Identifier (see Section 7.1), UNI
Type>. The list MUST have exactly one such pair for each UNI in the EVC. The UNI Type
MUST have the value either Root or Leaf. If the type of EVC is Point-to-Point or
Multipoint-to-Multipoint, then the UNI Type MUST equal Root.

6.4 Maximum Number of UNIs Service Attribute

The Maximum Number of UNIs (MNU) service attribute specifies the maximum number of
UNIs allowed in the UNI List service attribute. For a Point-to-Point EVC, MNU MUST be two.
For a Multipoint EVC, MNU MUST be two or greater.

6.5 Service Frame Delivery Service Attributes

6.5.1 Types of Service Frame

There are several types of Service Frame.

6.5.1.1 Unicast Service Frame

This is a Service Frame that has a unicast destination MAC address.

6.5.1.2 Multicast Service Frame

This is a Service Frame that has a multicast destination MAC address.

6.5.1.3 Broadcast Service Frame

This is a Service Frame with the broadcast destination MAC address.

6.5.1.4 Layer 2 Control Protocol Service Frame

Given that there are several Layer 2 protocols used for various control purposes, it is important
that Metro Ethernet Networks be able to process such information effectively. 4 A Service Frame
whose destination MAC address is one of the addresses listed in Table 1, MUST be treated as
Layer 2 Control Protocol Service Frame.

Some Layer 2 Control protocols share the same destination MAC address and are identified by
additional fields such as the Ethertype and a protocol identifier. Therefore, disposition of Service
Frames carrying Layer 2 Control Protocols MAY be different for different protocols that use the

4
This capability will be especially important for Subscribers who choose to deploy IEEE 802.1D [8] or IEEE
802.1Q [9] bridges (as opposed to routers) as CEs.
MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

same destination MAC address. [5] contains some recommendations for the delivery of specific
Layer 2 Control protocols.

MAC Addresses 5 Description


01-80-C2-00-00-00 through 01-80-C2-00-00-0F Bridge Block of protocols
01-80-C2-00-00-20 through 01-80-C2-00-00-2F GARP Block of protocols
01-80-C2-00-00-10 All Bridges Protocol
Table 1 List of Standardized Layer 2 Control Protocols

A Service Provider MAY define additional addresses for identifying Layer 2 Control protocols
in addition to those in Table 1.

6.5.1.5 Data Service Frame

A Service Frame that is either Unicast, Multicast, or Broadcast is referred to as a Data Service
Frame. Thus, Service Frames are divided into two groups, Data Service Frames and Layer 2
Control Protocol Frames.

6.5.2 Service Frame Disposition

The disposition of an ingress Service Frame is described by one of the following:

Discard: The Service Frame is discarded. An example is a Service Frame containing a


particular Layer 2 Control protocol, (e.g., IEEE 802.3x), that is always discarded at the
UNI. (See Section 7.13.) All ingress Service Frames with an invalid FCS MUST be
discarded by the MEN.

Deliver Unconditionally: No matter what the content (assuming correct FCS) of the
Service Frame, it is delivered across the other (egress) UNI(s). This might be the
behavior of a Point-to-Point EVC.

Deliver Conditionally: The Service Frame is delivered across an egress UNI if certain
conditions are met. An example of such a condition is that the destination MAC address
is known by the Metro Ethernet Network to be at the destination UNI. Another
example is broadcast throttling where some Service Frames with the broadcast
destination MAC address are dropped to limit the amount of such traffic. When this
option is in force the conditions MUST be specified.

Tunnel: This applies only to Layer 2 Control Protocol Service Frames. See Section 6.7.

More details about the disposition of Layer 2 Control Protocol Service Frames are presented in
Sections 6.7 and 7.13.

5
Hexadecimal canonical format
MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

Note that this is a description of the ideal service. Service Frames that should be delivered might
be discarded due to network failure or congestion conditions. See the EVC Related Performance
Service Attributes in Section 6.8.

6.5.3 Service Frame Transparency

All fields of each egress Service Frame MUST be identical to the same fields of the
corresponding ingress Service Frame except as follows:

The egress Service Frame MAY have an IEEE 802.1Q Customer VLAN Tag [10] while
the corresponding ingress Service Frame does not. In this case the egress Service Frame
MUST have a recalculated FCS.

The egress Service Frame MAY not have an IEEE 802.1Q Customer VLAN Tag [10]
while the corresponding ingress Service Frame does have a Tag. In this case the egress
Service Frame MUST have a recalculated FCS.

If both the egress Service frame and corresponding ingress Service Frame have an IEEE
802.1Q Customer VLAN Tag [10], the contents of the Tag in the egress Service Frame
MAY be different from the contents of the Tag in the corresponding ingress Service
Frame. If the contents of the ingress and egress tags are different, the egress Service
Frame MUST have a recalculated FCS.

However, specific attributes of an EVC MAY enforce the condition that additional fields must
be identical at ingress and egress. See Section 6.6.

6.6 CE-VLAN Tag Preservation Service Attributes

Service Frames at the UNI may contain an IEEE 802.1Q Customer VLAN Tag [10]. Such a Tag
is referred to as a Customer Edge VLAN Tag (CE-VLAN Tag). The portion of the CE-VLAN
Tag that identifies a VLAN indicates the Customer Edge VLAN ID (CE-VLAN ID). (See
Section 7.6.) The portion of the CE-VLAN Tag that contains the Priority Code Point bits is
called the Customer Edge VLAN CoS (CE-VLAN CoS). An EVC MAY have two attributes
related to CE-VLAN Tag Preservation as described in the following two subsections.

6.6.1 CE-VLAN ID Preservation Service Attribute

A Service Frame is defined to have its CE-VLAN ID Preserved when the relationship between
the ingress Service Frame and its corresponding egress Service Frame(s) is as described in Table
2.

MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

Ingress Service Frame Egress Service Frame(s) 6


No IEEE 802.1Q Customer No IEEE 802.1Q Customer VLAN Tag [10]
VLAN Tag [10]
Contains IEEE 802.1Q Contains IEEE 802.1Q Customer VLAN Tag [10] with VLAN ID
Customer VLAN Tag [10] equal to the VLAN ID of the Tag on the ingress Service Frame
Table 2 CE-VLAN ID Preservation for a Service Frame

An EVC with the CE-VLAN ID Preservation Service Attribute MUST preserve the CE-VLAN
ID for Service Frames as described in Table 3.

CE-VLAN ID/EVC Map Service Frames with CE-VLAN ID Preserved


Characteristic
All to One Bundling at all UNIs All Data Service Frames
All other cases All tagged Data Service Frames with VLAN ID in the
range 1 4094
Table 3 CE-VLAN ID Preservation Service Attribute for an EVC

When an EVC includes a UNI at which more than one CE-VLAN ID is mapped to the EVC by
the CE-VLAN ID/EVC Map (see Sections 7.9 and 7.10), the EVC MUST have the CE-VLAN
ID Preservation Service Attribute.

Note that when the CE-VLAN ID configured for untagged and priority tagged Service Frames
(see Section 7.6.1) is mapped to an EVC with the CE-VLAN ID Preservation Service Attribute,
ingress untagged and priority tagged Service Frames at this UNI are not mandated to have their
CE-VLAN ID preserved except in the case of All to One Bundling.

An obvious benefit of the CE-VLAN ID Preservation feature is enhanced operational simplicity.


For example, for a Subscriber connecting multiple campuses using IEEE 802.1Q bridges, the
feature obviates the task of renumbering VLANs in different corporate campuses.

6.6.2 CE-VLAN CoS Preservation Service Attribute

In an EVC with CE-VLAN CoS Preservation, an egress Service Frame resulting from an ingress
Service Frame that contains a CE-VLAN CoS MUST have the identical CE-VLAN CoS.

6.7 EVC Layer 2 Control Protocol Processing Service Attribute

In some cases, it is desirable to carry Layer 2 Control Protocols across the Service Provider
network. This is called Layer 2 Control Protocol tunneling because the frame MUST be passed
through the Service Provider network without being processed 7 and delivered to the proper UNI

6
Note that in the case of a Multipoint EVC, a single ingress Service Frame can result in more than one egress
Service Frame.
7
For example, the Subscribers Ethernet information can be encapsulated in another frame separate from the control
protocol frame.
MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

or UNIs. The tunneling capability can be extremely useful, for example, when the Subscriber
chooses to attach bridges to all UNIs and thus BPDUs need to be carried across the Network.
When a Layer 2 Control Protocol is tunneled, the Service Frame at each egress UNI MUST be
identical to the corresponding ingress Service Frame.

For a given EVC at a given UNI, the Service Provider defines which Layer 2 Control Protocols
will be tunneled via the EVC and which will be discarded. If a Service Frame carrying a Layer 2
Control Protocol is tunneled, it MUST be tunneled on the EVC that is identified by the CE-
VLAN/EVC Map for the CE-VLAN ID indicated by the Service Frame carrying the Layer 2
Control Protocol. 8 See Section 7.7.

Note that if a Layer 2 Control Protocol is to be tunneled, then all UNIs in the EVC MUST be
configured to pass the Layer 2 Control Protocol to the EVC. See Section 7.13.3.

6.8 Class of Service Identifier Service Attribute

Service Frame delivery performance is specified for all Service Frames transported within an
EVC with a particular Class of Service instance. The Class of Service instance for a given
Service Frame is identified by a Class of Service Identifier that is indicated by content in one or
more fields in the Service Frame. For example, suppose that three Classes of Service are offered
called silver, gold, and platinum and, at a given UNI, there are three instances of silver service,
two instances of gold service and one instance of platinum service. Then there would be six
Class of Service Identifiers, one for each Class of Service instance.

A Service Frame delivery performance MAY be to discard the Service Frame. Thus a Class of
Service Identifier may be specified for Service Frame discard.

Service Frames mapped to different EVCs MUST have different Class of Service Identifiers.
There SHALL be three mutually exclusive ways to determine the Class of Service Identifier
from the content of a given Service Frame as described in Sections 6.8.1, 6.8.2, and 6.8.3.

6.8.1 Class of Service Identifier Based on EVC

In this case, all ingress Data Service Frames mapped to the EVC SHALL have the same Class of
Service Identifier.

As an example, consider EVC 1 and EVC 2 at a UNI. Data Service Frames on EVC 1 have a first
Class of Service Identifier that indicates gold service. Data Service Frames on EVC 2 have a
second Class of Service Identifier that indicates silver service. All tunneled Layer 2 Control
Protocols on EVC 1 also have the first Class of Service Identifier thus indicating gold service.
All tunneled Layer 2 Control Protocols on EVC 2 have a third Class of Service Identifier that
indicates platinum service.

8
Tunneling of BPDUs when Service Multiplexing is in effect at a UNI can lead to undesirable behavior. For
example, if bridges are attached to all UNIs, then tunneled BPDUs will not reach all of the bridges and the Spanning
Tree Protocol will not operate properly.
MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

6.8.2 Class of Service Identifier Based on Priority Code Point Field

In this case, the Class of Service Identifier for an ingress Data Service Frame SHALL be
determined by the EVC and non-overlapping sets of values of the CE-VLAN CoS. If the ingress
Data Service Frame is untagged, it SHALL have the same Class of Service Identifier as an
ingress Data Service Frame with Priority Code Point field = 0. The union of the sets of CE-
VLAN CoS values MUST contain all of the possible CE-VLAN CoS values.

As an example, consider EVC 1 and EVC 2 at a UNI. Tagged and priority tagged Data Service
Frames on EVC 1 with Priority Code Point values 4, 5, 6, and 7 have a first Class of Service
Identifier that indicates gold service. Tagged and priority tagged Data Service Frames on EVC 1
with Priority Code Point values 0 and 3 have a second Class of Service Identifier that indicates
silver service. Tagged and priority tagged Data Service Frames on EVC 1 with Priority Code
Point values 1 and 2 have a third Class of Service Identifier that indicates Service Frame discard.
Untagged Data Service Frames on EVC 1 also have the second Class of Service Identifier that
indicates silver service. Tagged Data Service Frames on EVC 2 with Priority Code Point value 7
have a third Class of Service Identifier that indicates platinum service. All other Data Service
Frames on EVC 2 have a fourth Class of Service Identifier that indicates gold service.

6.8.3 Class of Service Identifier Based on DSCP

In this case, the Class of Service Identifier for an ingress Data Service Frame containing an IP
packet SHALL be determined by the EVC and non-overlapping sets of values of the DSCP. 9
The union of the sets of DSCP values MUST contain all of the possible DSCP values. All
ingress Data Service Frames not containing an IP packet and mapped to a given EVC SHALL
have the same Class of Service Identifier with a value agreed upon by the Subscriber and the
Service Provider.

6.8.4 Class of Service Identifier Based on Layer 2 Control Protocol

In each method for determining the Class of Service Identifier described in Sections 6.8.1, 6.8.2,
and 6.8.3, in addition Layer 2 Control Protocols that are tunneled on the EVC MAY be divided
up into subsets and each subset MAY have a Class of Service Identifier. 10

6.9 EVC Related Performance Service Attributes

The EVC Related Performance Service Attributes specify the Service Frame delivery
performance. Four performance attributes are considered in this specification. These are Frame
Delay Performance, Inter-Frame Delay Variation Performance, Frame Loss Ratio Performance,
and Availability Performance.

9
In IP version 4, the DSCP is contained in the TOS field. In IP version 6, the DSCP is contained in the Traffic Class
Octet.
10
For example, Service Frames carrying a BPDU could be assigned one Class of Service Identifier while Service
Frames carrying a GARP protocol message could be assigned a different Class of Service Identifier.
MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

Performance Attributes apply to Qualified Service Frames, which are frames that meet the
following criteria for a given ordered pair of UNIs and a given Class of Service:

Each Service Frame MUST be the first egress Service Frame at the same UNI j resulting
from an ingress Service Frame at the other UNI i of the ordered pair. The Service Frame
MAY be a Unicast (see Section 6.5.1.1), Multicast (see Section 6.5.1.2), Broadcast (see
Section 6.5.1.3), or Layer 2 Control Protocol (see Section 6.5.1.4) Service Frame. Note
that a single ingress Service Frame can result in multiple egress Service Frames, e.g., a
Multicast Service Frame.

The first bit of each Service Frame MUST arrive at the ingress UNI within the time
interval T,

Each Service Frame MUST have the Class of Service Identifier for the Class of Service
instance in question, and

Each ingress Service Frame MUST have an Ingress Bandwidth Profile compliance of
Green.

Such Service Frames are elements of the set of Qualified Service Frames for an Ordered Pair of
UNIs and a given Class of Service on an EVC.

Performance Attributes MUST NOT apply to Service Frames with the level of conformance
determined to be Yellow or Red. Typically, the Frame Loss Ratio Performance will be degraded
for Service Frames determined to be Yellow. Service Frames determined to be Red will be
discarded. (See Section 7.11.2.5.)

For a given EVC and Class of Service instance, Performance Objectives MAY be specified over
any given subset of the Ordered Pairs of UNIs (describing transmission direction) on the EVC.
Once a subset of UNI pairs is defined, then all attributes in this section SHALL have
performance objectives applying to that subset. Section 10.4 provides examples on how to
structure these metrics to be UNI-oriented and EVC-oriented.

Values of the Service Frame delay, delay variation, and loss performance during periods of
unavailable time MUST NOT be used to determine Service Frame delivery compliance. A
process MUST be established to exclude all performance during unavailable periods from
comparison with Service Frame performance objectives.

The assessment of all performance attributes SHOULD account for unexpected arrival
phenomena, such as frame duplication, or frames arriving in a different order from that observed
on ingress, and the presence of these phenomena alone do not necessarily exclude a Service
Frame from the set of Qualified Service Frames.

6.9.1 Frame Delay Performance for a Point-to-Point EVC

NOTE The contents of this section in [13] have been deleted, and the scope of Section 6.9.2
has been broadened to cover the Point-to-Point EVC case.

MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

6.9.2 One-way Frame Delay Performance for an EVC

This section defines three performance attributes: the One-way Frame Delay Performance
corresponding to a percentile of the distribution, the One-way Mean Frame Delay, and the One-
way Frame Delay Range.

The One-way Frame Delay for an egress Service Frame at a given UNI in the EVC is defined as
the time elapsed from the reception at the ingress UNI of the first bit of the corresponding
ingress Service Frame until the transmission of the last bit of the Service Frame at the given
UNI. This delay definition is illustrated in Figure 5.

CE CE
Metro Ethernet
time Network
first bit in
UNI to UNI

Frame
Delay
last bit out

Figure 5 - Frame Delay for Service Frame

Note that this definition of Frame Delay for a Service Frame is the one-way 11 delay that includes
the delays encountered as a result of transmission across the ingress and egress UNIs as well as
that introduced by the MEN.

There MAY be multiple Frame Delay Performance Objectives defined for a particular Class of
Service instance on an EVC. Each such metric is based on a subset of the ordered pairs of UNIs
in the EVC for a time interval T. Each Frame Delay Performance metric SHALL be defined as
follows:

Let the UNIs in the EVC be numbered from 1 to m. And let S be a subset of the ordered
UNI pairs in the EVC. That is S { i, j | i = 1,..., m, j = 1,..., m, i j}.


i, j
Let dT represent the P-Percentile of one-way delay for all Qualified Service Frames
delivered to UNI j resulting from an ingress Service Frame at UNI i. If there are no such
egress Service Frames at UNI j resulting from ingress Service Frames at UNI i, then
d T = Undefined.
i, j

11
One-way delay is difficult to measure and therefore one way delay may be approximated from two way
measurements. However these techniques are beyond the scope of this document.
MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

Then the One-way Frame Delay Performance metric SHALL be defined as the maximum
value of all of the values dT for i, j S , unless all dT are Undefined in which case
i, j i, j

the performance is Undefined.

Let d Tyx = d Ty d Tx
i, j i, j i, j
represent the difference between Percentiles Py and Px (where
Py > Px and i and j are the same pair in each term) of one-way delay for all Qualified
Service Frames delivered to UNI j resulting from an ingress Service Frame at UNI i. If
there are no such egress Service Frames at UNI j resulting from ingress Service Frames at
UNI i, then d Txy = Undefined.
i, j

Then the One-way Frame Delay Range Performance metric SHALL be defined as the
maximum value of all of the values of the difference d Tyx = d Ty d Tx for i, j S ,
i, j i, j i, j

i, j
unless all dTxy are Undefined in which case the performance is Undefined.

Let T
i, j
represent the arithmetic mean of one-way delay for all Qualified Service
Frames delivered to UNI j resulting from an ingress Service Frame at UNI i. If there are
no such egress Service Frames at UNI j resulting from ingress Service Frames at UNI i,
then T = Undefined.
i, j

Then the One-way Mean Frame Delay Performance metric SHALL be defined as the
maximum value of all of the values T for i, j S , unless all T are Undefined in
i, j i, j

which case the performance is Undefined.

To restate the Frame Delay definition mathematically, let the UNIs in the EVC be numbered
i, j
from 1 to m and let DT be the set of one-way Frame Delay values for all Qualified Service
i, j
Frames at UNI j resulting from an ingress Service Frame at UNI i. DT can be expressed as
DT
i, j
{
= d1
i, j
, d2
i, j i, j
}
,..., d N i , j , where d k
i, j
is the one-way Frame Delay of the kth Service Frame.
i, j
Define dT for P > 0 as


( ) if N
N i, j
100
min d | P I d, dk
i, j
1
=
i, j
dT N i, j k =1
i, j


Undefined otherwise

where,

1 if d d k
I (d , d k ) = .
0 otherwise

MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2
i, j
dT is the minimal delay during the time internal T that P percent of the frames do not exceed.
i, j
Note that when P>0, only values of d within DT will satisfy P(100/N<i,k>)I(d,dk).

Then a one-way Frame Delay Performance metric for an EVC can be expressed as

d T ,S =
{
max d T i , j | i, j S and where N i , j > 0
.
}
Undefined when all N i , j = 0 | i, j S

The One-way Frame Delay attribute permits specification of multiple values for P, (P0, P1, P2,
) and corresponding objectives ( d0 , d1 , d2 , ). Another parameter is the objective
i, j i, j i, j

for the difference between the delay performance of two selected percentiles, Px and Py ,
expressed as

(d d Tx ) if N i , j > 0
i, j i, j

d Tyx = Ty
i, j

Undefined if N i , j = 0

Then a one-way Frame Delay Range Performance metric for an EVC can be expressed as

d TyxS =
{
max d Tyxi , j | i, j S and where N i , j > 0
.
}
Undefined when all N i , j = 0 | i, j S

DT , where d min d k (for all


i, j i, j i, j
The minimum one-way delay is an element of
k = 1,2,..., N i , j ), and is a possible selection as one of the percentiles. The minimum delay
represents the N<i,j>-1th percentile and all lower values of P as P 0 .
i, j
Another One-way Frame Delay attribute is the arithmetic mean of DT , which can be expressed
as

T i , j
( )
1 N i, j i, j
d if N i, j > 0
= N i , j k =1 k
Undefined if N =0
i, j

Then a One-way Mean Frame Delay Performance metric for an EVC can be expressed as

TS =
{
max T i , j | i, j S and T i , j where N i , j > 0
.
}
Undefined when all N i , j = 0 | i, j S

The parameters of a One-way Frame Delay Performance metric are given in Table 4.

MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

Parameter Description
T The time interval
S Subset of the ordered UNI pairs of the EVC
Px A specific percentile of the Frame Delay Performance, Px > 0
Py Another specific percentile of the Frame Delay Performance, where Py > Px
d x One-way Frame Delay Performance Objective corresponding to Px
d y
One-way Frame Delay Performance Objective corresponding to Py
One-way Frame Delay Range Objective corresponding to the Frame Delay
d yx
Performance at Px and Py d Tyx = (d Ty d Tx ) where Py > Px
i, j i, j i, j

One-way Mean Frame Delay Performance Objective


Table 4 One-way Frame Delay Performance Parameters

Given T, S, Px , and a one-way Frame Delay Performance objective d x , expressed in time units,
the one-way Frame Delay Performance SHALL be defined as met over the time interval T for
the subset S if and only if d T ,S d x . Further, given Py and a One-way Frame Delay Performance
objective d y , expressed in time units, the objective for one-way Frame Delay Range between Px
and Py SHALL be defined as met over the time interval T for the subset S if and only if
d d . Finally, given a One-way Mean Frame Delay Performance objective , expressed in
TyxS yx

time units, the Frame Delay Performance SHALL be defined as met over the time interval T if
and only if TS .

Recall that if any of the above Service Frame Performance attributes are Undefined for time
interval T and ordered pair i, j , then the performance for that ordered pair SHALL be
excluded from calculations on the performance of pairs in S. For a given set S, if the Service
Performance is Undefined for all ordered pairs, then the performance for S SHALL be defined
as compliant.

For a Point-to-Point EVC, S MAY include one or both of the ordered pairs of UNIs in the EVC.

For a Multipoint-to-Multipoint EVC, S MAY be any subset of the ordered pairs of UNIs in the
EVC.

For a Rooted-Multipoint EVC, S MUST be such that all ordered pairs in S contain at least one
UNI that is designated as a Root.

6.9.3 Inter-Frame Delay Variation Performance for a Point-to-Point EVC

NOTE The contents of this section in [13] have been deleted, and the scope of Section 6.9.4
has been broadened to cover the Point-to-Point EVC case.

MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

6.9.4 Inter-Frame Delay Variation Performance for an EVC

Inter-Frame Delay Variation (IFDV) is the difference between the one-way delays of a pair of
selected Service Frames. This definition is borrowed from RFC3393 [6] where IP packet delay
variation is defined. For a particular Class of Service Identifier and an ordered pair of UNIs in
the EVC, IFDV Performance is applicable to Qualified Service Frames.

NOTE Earlier documents refer to Inter-Frame Delay Variation as Frame Delay Variation.

The Inter-Frame Delay Variation Performance SHALL be defined as the P-percentile of the
absolute values of the difference between the Frame delays of all Qualified Service Frame pairs
that satisfy the following conditions:

The difference in the arrival times of the first bit of each Service Frame at the ingress
UNI was exactly t.

This definition is in agreement with the IP packet delay variation definition given in [6] where
the delay variation is defined as the difference between the one-way delay of two packets
selected according to some selection function and are within a given interval [T1, T2].

Inter-Frame Delay Variation Performance depends on the choice of the value for t. Values for
both t and T typically should be chosen to achieve a reasonable level of statistical accuracy.

The choice of the value for t can be related to the application timing information. As an
example for voice applications where voice frames are generated at regular intervals, t may be
chosen to be few multiples of the inter-frame time.

Let ai be the time of the arrival of the first bit of the ith Service Frame at the ingress UNI, then
the two frames i and j are selected according to the selection criterion:

{a j ai = t and j > i}

Let ri be the time frame i is successfully received (last bit of the frame) at the egress UNI, then
the difference in the delays encountered by frame i and frame j is given by d i d j . Define

d ij = d i d j = (ri ai ) (rj a j ) = (a j ai ) (rj ri )

With d j being the delay of the jth frame, a positive value for d i d j implies that the two frames
are closer together at the egress UNI while a negative value implies that the two frames are
further apart at the egress UNI. If either or both frames are lost or not delivered due to, for
example, FCS violation, then the value d ij is not defined and does not contribute to the
evaluation of the Inter-Frame Delay Variation.

MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

Figure 6 shows a depiction of the different times that are related to Inter-Frame Delay Variation
Performance.
i i+1 j j+1

ai aj
Ingress

t Time

ri rj
Egress

di dj

Figure 6 Inter-Frame Delay Variation Definition

For a particular Class of Service instance, Inter-Frame Delay Variation Performance metrics
MAY be specified over any given subset of two or more UNIs on an EVC. Each such metric is
based on a subset of the ordered pairs of UNIs in the EVC for a time interval T. Each Inter-
Frame Delay Variation Performance metric SHALL be defined as follows:

Let the UNIs in the EVC be numbered from 1 to m. And let S be a subset of the ordered
UNI pairs in the EVC. That is S { i, j | i = 1,..., m, j = 1,..., m, i j}.

~ i, j
Let dT be the P-percentile of the absolute value of the difference between the Frame
Delays of all Qualified Service Frame pairs whose difference in the arrival times of the
first bit of each Service Frame in the pair at UNI i was exactly t .

If there are no such pairs of Service Frames for UNI i and UNI j, then
~ i, j
d T = Undefined .

Then the Inter-Frame Delay Variation Performance metric SHALL be the maximum of
~ i, j ~ i, j
the values dT for i, j S , unless all dT are Undefined in which case the
performance is Undefined.

To restate the definition mathematically, let the UNIs in the EVC be numbered from 1 to m. And
let S be a subset of the ordered UNI pairs in the EVC. That is

S { i, j | i = 1,..., m, j = 1,..., m, i j}.

Let

= {d1 , d 2 ,..., d N i , j }
i, j i, j i, j i, j
VT

MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

be the set of all absolute value of delay variations for all eligible pairs of Qualified Service
Frames from UNI i to UNI j where the difference in the arrival times of the first bit of each
Service Frame at the ingress UNI was exactly t. Define

N
100 i , j
~ i, j
d T
min d | P
= I (d , d k
i, j
) if N i , j 1
N i , j k =1

Undefined otherwise

where;

1 if d d
I (d , d ) = .
0 otherwise

Then an Inter-Frame Delay Variation Performance metric for an EVC can be expressed as

~
d T , S =
{
max d~T i , j | i, j S and where N i , j 1
.
}
Undefined when all N i , j = 0 | i, j S

For the SLS, an Inter-Frame Delay Variation metric MUST specify a set of parameters and an
objective. The parameters and objective for an Inter-Frame Delay Variation Performance metric
are given in Table 5.

Parameter Description
T The interval
S Subset of the ordered UNI pairs of the EVC
P Inter-Frame Delay Variation Performance percentile
The separation between frame pairs for which Inter-Frame Delay
t
Variation Performance is defined

d Inter-Frame Delay Variation Performance Objective

Table 5 Inter-Frame Delay Variation Parameters


Given T, S, P, t, and d , the Inter-Frame Delay Variation Performance SHALL be defined as
~
met over the time interval T for the subset S if and only if dT , S d .

Recall that if the Inter-Frame Delay Variation is Undefined for time interval T and ordered pair
i, j , then the performance for that ordered pair SHALL be excluded from calculations on the
performance of pairs in S. For a given set S, if the Service Performance is Undefined for all
ordered pairs, then the performance for S SHALL be defined as compliant.

For a Point-to-Point EVC, S MAY be include one or both of the ordered pairs of UNIs in the
EVC.

MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

For a Multipoint-to-Multipoint EVC, S MAY be any subset of the ordered pairs of UNIs in the
EVC.

For a Rooted-Multipoint EVC, S MUST be such that all ordered pairs in S contain at least one
UNI that is designated as a Root.

6.9.5 One-way Frame Loss Ratio Performance for a Point-to-Point EVC

NOTE Section 6.9.7 refers to this section for the definition of the frame loss ratio flr (ti ) of a
Point-to-Point EVC. For the purposes of the Availability Performance, the Frame Loss Ratio
Performance (defined in detail in Section 6.9.6) SHALL be defined as follows:

flr (t i ) = FLRti ,S =
{
max FLRt | i, j S and where I t 1
i
i, j
i
i, j
}
0 when all I ti = 0 | i, j S
i, j

where the set of ordered pairs, S, contains both ordered pairs of UNIs in the Point-to-Point EVC.

NOTE The contents of this section in [13] have been deleted, and the scope of Section 6.9.6
has been broadened to cover the Point-to-Point EVC case.

6.9.6 One-way Frame Loss Ratio Performance for an EVC

There MAY be multiple One-way Frame Loss Ratio Performance metrics defined for a
particular Class of Service instance on an EVC. Each such metric is based on a subset of the
ordered pairs of UNIs in the EVC for a time interval T. Each One-way Frame Loss Ratio
Performance metric SHALL be defined as follows:

Let the UNIs in the EVC be numbered from 1 to m. And let S be a subset of the ordered
UNI pairs in the EVC. That is S { i, j | i = 1,..., m, j = 1,..., m, i j}.


i, j
Let I T denote the number of ingress Service Frames at UNI i whose first bit arrived at
UNI i during the time interval T, whose Ingress Bandwidth Profile compliance was
Green, and that should have been delivered to UNI j according to the Service Frame
Delivery service attributes (see Sections 6.5.2, 6.7, and 7.13). Each Service Frame can be
a Unicast (see Section 6.5.1.1), Multicast (see Section 6.5.1.2), Broadcast (see Section
6.5.1.3), or Layer 2 Control Protocol (see Section 6.5.1.4) Service Frame.


i, j
Let ET denote the number of such Service Frames delivered to UNI j.

I Ti , j ETi , j
100 if I Ti , j 1

=
i, j
Define FLRT i
IT , j .

Undefined otherwise

MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

Then the One-way Frame Loss Ratio Performance metric SHALL be defined as
{
max FLRTi , j | i, j S and where I Ti , j 1
FLRT ,S = .
}
Undefined when all I T = 0 | i, j S
i, j

For the SLS, a One-way Frame Loss Ratio Performance metric entry MUST specify a set of
parameters and an objective. The parameters and objective of a One-way Frame Loss Ratio
Performance metric are given in Table 6.

Parameter Description
T The time interval
S Subset of the ordered UNI pairs
L One-way Frame Loss Ratio Performance
objective
Table 6 One-way Frame Loss Ratio Performance Parameters

Given T, S, and a One-way Frame Loss Ratio Performance objective, the One-way Frame Loss
Performance SHALL be defined as met over the time interval T for the subset S if and only if
FLRT , S L .

Recall that if the One-way Frame Loss Ratio Performance is Undefined for time interval T and
ordered pair i, j , then the performance for that ordered pair SHALL be excluded from
calculations on the performance of pairs in S. For a given set S, if the Service Performance is
Undefined for all ordered pairs, then the performance for S SHALL be defined as compliant.

For a Point-to-Point EVC, S MAY include one or both of the ordered pairs of UNIs in the EVC.

For a Multipoint-to-Multipoint EVC, S MAY be any subset of the ordered pairs of UNIs in the
EVC.

For a Rooted-Multipoint EVC, S MUST be such that all ordered pairs in S contain at least one
UNI that is designated as a Root.

6.9.7 Availability Performance for a Point-to-Point EVC

Availability Performance is the percentage of time within a specified time interval during which
the Frame Loss Ratio Performance (Section 6.9.5) is small. (The precise definition is presented
in the following paragraphs.) As an example, a service provider can define the availability
performance to be measured over a month and the value for the Availability Performance
objective to be 99.9%. In a month with 30 days and no scheduled downtime this parameter will
allow the service to be unavailable for approximately 43 minutes out of the whole month.

Informally, Availability Performance is based on Service Frame loss during a sequence of


consecutive small time intervals. If the previous sequence was defined as available, and if the
frame loss is high for each small time interval in the current sequence, then the current sequence

MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

is defined as unavailable. Otherwise the current sequence is defined as available. On the other
hand, if the previous sequence was defined as unavailable, and if frame loss is low for each small
time interval in the current sequence, then the current sequence is defined as available.
Otherwise, the current sequence is defined as unavailable. The formal definition follows.

The Availability for a particular Class of Service instance on a Point-to-Point EVC for a time
interval T is based on the following four parameters:

t , a time interval much smaller than T,

Cu , a loss ratio threshold which if equaled or exceeded suggests unavailability,

Ca , a loss ratio threshold which if not exceeded suggests availability with Ca Cu , and

n , the number of consecutive small time intervals, t , over which to assess availability.

Suppose the time interval T = [t0 ,t1 ] and define ti = [t0 + (i 1)t , t0 + it ], for i = 1,2,..., n .
Define sets of n consecutive small time intervals as S k = {t(k 1)n +1 , t(k 1)n + 2 ,..., t kn }. Also define
flr (ti ) to be the Frame Loss Ratio defined in Section 6.9.5 with ti replacing T. Let
T = {ti | ti T } . Let K be the largest integer such that ti T , ti S K . In other words, S K
~ ~

is the last sequence of small time intervals completely contained in T.

Define the function Ds (k ) to indicate if a sequence of small time intervals includes Scheduled
Downtime:

1 if there is any Scheduled Downtime during S k


Ds (k ) = .
0 otherwise

Scheduled Downtime is a time interval agreed upon by both the Subscriber and Service Provider
during which a service may be disabled by the Service Provider.

Define the function Du (k ) to indicate if a sequence of small time intervals includes Unscheduled
Downtime:

1 if there is any Unscheduled Downtime during S k


Du (k ) = .
0 otherwise

Unscheduled Downtime is a time interval not agreed upon by both the Subscriber and Service
Provider during which the Service Provider determines that the service is not usable. The method
by which the Service Provider determines that Unscheduled Downtime is occurring is beyond
the scope of this document. When Unscheduled Downtime is occurring, the Service Provider
may notify the Subscriber via the Ethernet Local Management Interface.[11]

MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

Let M be the number of sequences that contain Scheduled Downtime and no Unscheduled
Downtime. These sequences are excluded when considering availability.

For notation simplicity define

0 if flr (ti ) Cu , ti S k 1 if flr (ti ) Ca , ti S k


U (k ) = and A(k ) = .
1 otherwise 0 otherwise

Finally define an indicator function I (S k ) as follows whose value is 1 if the service is available
during S k and 0 otherwise:

0 if Du (1) = 1
I (S1 ) =
1 otherwise

0 if Du (k ) = 1
1 if (Du (k ) = 0 ) and (Ds (k ) = 1)

I (S k ) = for k = 2,..., K .
U (k ) if ( Du (k ) = 0 ) and ( Ds (k ) = 0 ) and ( I (S k 1 ) = 1)
A(k ) otherwise

Note that any S k that has Unscheduled Downtime is defined as unavailable and thus
Unscheduled Downtime overrides Scheduled Downtime during an interval S k .

Figure 7 illustrates four examples of calculating I (S k ) when there is no Scheduled Downtime


and no Unscheduled Downtime. In this example, n = 4 .
Sk-1 Sk

I(Sk-1) = 1 (available) I(Sk) = 0 (unavailable)


flrCu flrCu flrCu flrCu
t t t t t t t t

I(Sk-1) = 1 (available) I(Sk) = 1 (available)


flrCu flr<Cu flrCu flrCu
t t t t t t t t

I(Sk-1) = 0 (unavailable) I(Sk) = 1 (available)


flrCa flrCa flrCa flrCa
t t t t t t t t

I(Sk-1) = 0 (unavailable) I(Sk) = 0 (unavailable)


flrCa flr>Ca flrCa flrCa
t t t t t t t t

Figure 7 Examples of the Calculation of I (S k )

MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

Then the Availability Performance metric SHALL be defined as

100 K

AT = K M I ( S k ) M if M < K .
k =1

100 otherwise

For the SLS, an Availability Performance metric MUST specify a set of parameters and an
objective as shown in Table 7.

Parameter Description
T The time interval
t A time interval much smaller than T
Cu Unavailability frame loss ratio threshold
Ca Availability frame loss ratio threshold with Ca Cu
n Number of consecutive small time intervals for assessing availability
A Availability Performance objective
Table 7 Availability Performance Parameters for a Point-to-Pointe EVC

Given T, t , Cu , Ca , n, and an Availability Performance objective, A , the Availability


Performance SHALL be defined as met over the time interval T if and only if A A . T

6.9.8 Availability Performance for a Multipoint EVC

There MAY be multiple Availability Performance metrics specified for a particular Class of
Service instance on a Multipoint EVC. Each such metric is based on a subset of the pairs of
UNIs in the Multipoint EVC and for a time interval T. Each Availability Performance metric
SHALL be defined as follows: Let the UNIs in the EVC be numbered from 1 to m. And let S be
a subset of the UNI pairs in the EVC. That is S { i, j | i = 1,..., m, j = 1,...m, j > i}.

Let t be a time interval much smaller than T.

Let Cu be a loss ratio threshold which if equaled or exceeded suggests unavailability.

Let Ca be a loss ratio threshold which if not exceeded suggests availability with Ca Cu .

Let n be the number of small time intervals, t , over which to assess availability.


i, j
Let AT be denote the availability between UNI i and UNI j defined in Section 6.9.7 as
if there was a Point-to-Point EVC between UNI i and UNI j.

MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

Then the Availability Performance metric SHALL be defined as


{
AT , S = min AT | i, j S .
i, j
}
For the SLS, an Availability Performance metric MUST specify a set of parameters and an
objective as shown in Table 8.

Parameter Description
T The time interval
S Subset of the UNI pairs
t A time interval much smaller than T
Cu Unavailability frame loss ratio threshold
Ca Availability frame loss ratio threshold with Ca Cu
n Number of consecutive small time intervals for assessing availability
A Availability Performance objective
Table 8 Availability Performance Parameters for a Multipoint EVC

Given T, S, t , Cu , Ca , n, and an Availability Performance objective, A , the Availability


Performance SHALL be defined as met over the time interval T if and only if A A . T ,S

For a Multipoint-to-Multipoint EVC, S MAY be any subset of the pairs of UNIs in the EVC.

For a Rooted-Multipoint EVC, S MUST be such that all pairs in S contain at least one UNI that
is designated as a Root.

6.10 EVC Maximum Transmission Unit Size Service Attribute

The EVC Maximum Transmission Unit Size service attribute specifies the maximum Service
Frame size (in Bytes) allowed on the EVC. Every UNI in the EVC MUST be capable of
supporting this Service Frame size. 12 (See Section 7.4.) The MTU MUST be specified to have a
value greater than or equal to 1522.

When an ingress Service Frame has length greater than the EVC Maximum Transmission Unit
Size, the SLS, if any, for this frame SHALL not apply to its delivery performance and the result
of a Bandwidth Profile that applies to this Service Frame is not defined.

7. UNI and EVC per UNI Service Attributes

This section describes attributes at each UNI. These attributes fall into two types:

Attributes independent of the EVCs at the UNI and

12
The MTU Size for an EVC will be constrained by the MTU size of the network equipment used to carry the frame
including the network equipment supporting each UNI. The method of calculating the MTU Size is beyond the
scope of this specification.
MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

Attributes associated with an EVC at the UNI.

When each attribute is described, its type is noted.

A UNI can have a number of characteristics that will be important to the way that the CE sees a
service. One of the key aspects of a service description will be the allowable mix of UNIs with
different characteristics in an EVC. For example, a specific (simple) service might require all
UNIs to have the same speed at the physical layer. A more sophisticated service may allow a
wide variety of speeds.

7.1 UNI Identifier Service Attribute

The UNI Identifier attribute is independent of the EVCs at the UNI. It is assigned to the UNI by
the Service Provider. It MUST be a string and the string MAY have any value. The UNI
Identifier MUST be unique among all UNIs for the MEN. As an example, the Service Provider
might use SCPOP1-Node3-Slot2-Port1" as a UNI Identifier and this could signify Port 1 in Slot
2 of Node 3 in Santa Clara POP1.

7.2 Physical Layer Service Attribute

For a UNI, the Speed (in bits per second), Mode, and Physical Medium MUST be one of the
combinations shown in Table 9. Typically there are no constraints in mixing UNIs with different
physical media in the same EVC. 13 Constraints on the mix of speeds and modes MAY be
imposed for some services.

Speed Mode Physical Medium


10 Mbps Full duplex
100 Mbps Full duplex
10/100 Mbps Full duplex
All Ethernet physical media compatible with
Auto-
Speed and Mode specified in [2] or [3].
Negotiation
1 Gbps Full duplex
10 Gbps Full duplex
Table 9 Possible Physical Layer Characteristics

This attribute is independent of the EVCs at the UNI.

7.3 MAC Layer Service Attribute

The protocols running at the UNI MUST support the IEEE 802.3 2005 [2] frame formats with
the possible exception that the information field MAY be larger than 1500 bytes. (See Sections
6.10 and 7.4.) This attribute is independent of the EVCs at the UNI.

13
An exception might be wireless when the service requires stringent requirements on packet loss.
MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

7.4 UNI Maximum Transmission Unit Size Service Attribute

The UNI Maximum Transmission Unit Size service attribute specifies the maximum Service
Frame size (in Bytes) allowed at the UNI. The UNI MTU Size MUST be specified to have a
value greater than or equal to 1522. This attribute is independent of the EVCs at the UNI.

The EVC MTU Size for each EVC (see Section 6.10) at the UNI MUST be less than or equal to
the UNI MTU Size.

7.5 Service Multiplexing Service Attribute

A UNI with the Service Multiplexing attribute MUST be configurable to support multiple
EVCs. 14 Point-to-Point EVCs and Multipoint EVCs MAY be multiplexed in any combination at
a UNI. Figure 8 shows an example of Service Multiplexing. In this example, CE A is attached to
the MEN via a Gigabit Ethernet UNI. CEs B, C, and D are attached via 100 Mbps Ethernet
UNIs. Using Service Multiplexing, instances of Point-to-Point EVCs to each of B, C, and D can
be implemented at A without requiring 3 physical ports on the CE at A.

Figure 8 Example of Service Multiplexing on UNI A

This attribute is independent of the EVCs at the UNI.

7.6 Identifying an EVC at the UNI

7.6.1 Customer Edge VLAN ID

At the given UNI, the EVC for a Service Frame MUST be identified by the Customer Edge
VLAN ID (CE-VLAN ID). There are 4095 CE-VLAN IDs numbered 1 through 4095. The CE-
VLAN ID for a Service Frame with an IEEE 802.1Q Customer VLAN Tag [10] MUST be the

14
Since the UNI is dedicated to a single Subscriber, only one Subscriber can access the EVCs at the UNI.
MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

value of the VLAN ID, if not 0, in the tag. Untagged and priority tagged 15 Service Frames
MUST have the same CE-VLAN ID and that value MUST be configurable to any value in the
range 1, 2, , 4094. When the CE-VLAN ID Preservation Service Attribute is not in force for
an EVC to which the CE-VLAN ID for untagged and priority tagged Service Frames is mapped,
egress Service Frames for this EVC at the given UNI MUST be untagged. When CE-VLAN ID
Preservation Service Attribute is in force for an EVC to which the CE-VLAN ID for untagged
and priority tagged Service Frames is mapped, the format of an egress Service Frame for this
EVC at the given UNI depends on the format of the corresponding ingress Service Frame at a
UNI other than the given UNI in the EVC as described in Section 6.6.1.

More than one CE-VLAN ID MAY point to the same EVC as described in Section 7.9.

Note that certain of the VLAN ID values in IEEE 802.1Q Customer VLAN Tags [10] are
reserved for special purposes in IEEE 802.1Q bridges and thus the number of VLANs in a
subscriber network is less than 4095. Nevertheless, Service Frames with any VLAN ID value as
well as untagged Service Frames can exist at the UNI. Consequently the CE-VLAN ID can have
4095 values. However, less than 4095 EVCs MAY be supported at a UNI. See Section 7.7.

The 4095 CE-VLAN IDs always exist at each UNI and are independent of the EVCs at the UNI.
The CE-VLAN ID configured for untagged and priority tagged Service Frames is also
independent of the EVCs at the UNI.

7.6.2 UNI EVC ID Service Attribute

The UNI EVC ID is a string formed by the concatenation of the UNI ID (Section 7.1) and the
EVC ID (Section 6.2) that is used to identify an EVC at the UNI. It is intended for management
and control purposes. This attribute is associated with each EVC at the UNI.

7.7 CE-VLAN ID/EVC Map Service Attribute

7.7.1 Basic Concept

At each UNI there MUST be a mapping of each CE-VLAN ID to at most one EVC. The
mapping of one or more CE-VLAN IDs to an EVC is an attribute associated with the EVC at the
UNI. The collection of all of these mappings is called the CE-VLAN ID/EVC Map. Note that a
given CE-VLAN ID MAY not be mapped to any EVC. In the simple case, when the Bundling
and All to One Bundling attributes (as defined in Sections 7.9 and 7.10) are not invoked, exactly
one CE-VLAN ID MUST be mapped to at most one EVC. Figure 9 is an example of a CE-
VLAN ID/EVC Map. In this example and all of the following examples, the entry in the EVC
column can be any suitable identifier for the EVC, e.g., the EVC ID (Section 6.1.2.2) or the UNI
EVC ID (Section 7.6.2).

15
A priority tagged Service Frame is a Service Frame with an IEEE 802.1Q [9] tag in which the VLAN ID in the tag
equals 0.
MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

CE-VLAN ID EVC
47 EVC1
1343 EVC2
17 16 EVC3

47 EVC1
EVC2
1343
untagged and EVC3
priority tagged, 17 UNI

Figure 9 Example of a CE-VLAN ID/EVC Map

In this example, an ingress Service Frame with CE-VLAN ID 47 is transported according to the
properties and attributes of EVC1. An untagged or priority tagged ingress Service Frame is
transported according to the properties and attributes of EVC3. An egress frame coming from
EVC2 is given CE-VLAN ID 1343.

When an instance of the CE-VLAN ID/EVC Map does not contain an entry for a given CE-
VLAN ID, any ingress Service Frame at the UNI with this CE-VLAN ID MUST be discarded by
the MEN. Also, an egress Service Frame MUST NOT have a CE-VLAN ID with this value at
the UNI while using this instance of the CE-VLAN ID/EVC Map.

In some scenarios, it may be necessary for the Subscriber and the Service Provider to agree upon
the CE-VLAN ID/EVC Map at the UNI. One way to implement this is to have the Service
Provider dictate the mapping. This is what is frequently done with the mapping between DLCIs
and permanent virtual connections for Frame Relay. Also note that for a given UNI, the CE-
VLAN ID/EVC Map may be constrained by the range of CE-VLAN ID values that can be
supported by the CE and the range of CE-VLAN ID values that can be supported by the Service
Provider. 17

7.7.2 CE-VLAN ID Significance

CE-VLAN ID values MAY only be significant at a given UNI. Restated, the CE-VLAN
ID/EVC mapping for a given EVC at a UNI MAY be different from the mapping at another UNI
in the EVC. Figure 10 shows valid CE-VLAN ID/EVC Maps for three EVCs between two UNIs.
Note that when the CE-VLAN ID Preservation attribute (Section 6.6.1) applies to an EVC, the

16
In this example, the CE-VLAN ID for untagged and priority tagged Service Frames is configured to 17.
17
In a future Technical Specification, dynamic EVC setup via a signaling protocol across the UNI may be specified.
In that case, it may be desirable to specify the range of CE-VLAN ID values supported by the Service Provider as a
UNI attribute. In this phase of this Technical Specification, resolving the CE-VLAN ID/EVC Map is assumed to be
done administratively and thus this specifying of a CE-VLAN ID range is not needed.
MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

mappings for the EVC are identical as is the case for EVC1 in Figure 10. (Otherwise the CE-
VLAN ID cannot be preserved).

UNI A UNI B
CE-VLAN ID EVC CE-VLAN ID EVC
47 EVC1 47 EVC1
1343 EVC2 1716 EVC2
187 EVC3 1343 EVC3

47 EVC2
EVC1 47
1343 untagged and priority tagged, 17
187 EVC3 1343
UNI A UNI B

Figure 10 Example of CE-VLAN ID/EVC Maps at Two UNIs

7.7.3 Describing the Contents of the CE-VLAN ID/EVC Map

The CE-VLAN ID/EVC Map described here is an abstraction. This description does not
constrain how the contents can be described in a protocol, database, service order form, etc. For
example, shorthand descriptions such as the example of Section 7.9 or the protocol optimizations
of the Ethernet Local Management Interface [11] are allowed.

7.8 Maximum Number of EVCs Service Attribute

This attribute defines the maximum number of EVCs that the UNI can support. It MUST have a
value of at least one. This attribute is independent of the EVCs at the UNI.

7.9 Bundling Service Attribute

When a UNI has the Bundling attribute, it MUST be configurable so that more than one CE-
VLAN ID can map to a particular EVC at the UNI. The Bundling service attribute is independent
of the EVCs at the UNI. An EVC with more than one CE-VLAN ID mapping to it MUST have
the CE-VLAN ID Preservation Service Attribute (see Section 6.6.1) and the list of CE-VLAN
IDs mapped to the EVC MUST be the same at each UNI in the EVC. Figure 11 shows an
example of Bundling. In this example, UNI A and UNI B have the bundling attribute as seen
from the mapping for EVC1. (EVC1 has the CE-VLAN ID Preservation attribute.). Note that
Bundling is compatible with Service Multiplexing. In Figure 11, UNI A and UNI B are examples
of Service Multiplexing and Bundling on the same UNI.

MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2

UNI A UNI B UNI C


CE-VLAN ID EVC CE-VLAN ID EVC CE-VLAN ID EVC
47,48,49 EVC1 47,48,49 EVC1 1 EVC2
113 EVC3 1 EVC2 47 EVC3
47,48,49
1

UNI B

47,48,49
EVC1 EVC2 1

113 EVC3 47
UNI A UNI C

Figure 11 Example of Bundling

This model does not constrain the way that the Service Provider and Subscriber communicate the
contents of the CE-VLAN ID/EVC map. For example, a Service Provider could simply describe
bundling as shown in Figure 12.

Description Actual Map


CE-VLAN ID EVC CE-VLAN ID EVC
2000 EVC1 2000 EVC1
2001 EVC3 2001 EVC3
All others EVC4 1, , 1999, 2002, , 4095 EVC4
Figure 12 Example of a Simple Description of Bundling

7.10 All to One Bundling Service Attribute

When a UNI has the All to One Bundling attribute set to TRUE, all CE-VLAN IDs MUST map
to a single EVC at the UNI. The All to One Bundling service attribute is independent of the
EVCs at the UNI. The EVC at the UNI MUST have the CE-VLAN ID Preservation Service
Attribute (see Section 6.6.1) and the list of CE-VLAN IDs mapped to the EVC MUST include all
CE-VLAN IDs and be the same at each UNI in the EVC. This means that:

Such a UNI cannot have Service Multiplexing and

All UNIs in the EVC must have the All to One Bundling Service Attribute

All to One Bundling is a special case of Bundling but it is sufficiently important to be called out
as a separate attribute.

Table 10 shows the valid combinations of the bundling and Service Multiplexing attributes.

MEF 10.2 The Metro Ethernet Forum 2009. 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.
Ethernet Services Attributes Phase 2
Valid Valid Valid Valid Valid
Combination Combination Combination Combination Combination
1 2 3 4 5
Service Multiplexing
Bundling
All to One Bundling
Table 10 Valid Combinations of Service Multiplexing, Bundling, and All to One Bundling

7.11 Bandwidth Profiles Service Attributes

A Bandwidth Profile is a method characterizing Service Frames for the purpose of rate
enforcement or policing. There are two types of Bandwidth Profile. An Ingress Bandwidth
Profile is used to regulate the amount of ingress traffic at a particular UNI, while an Egress
Bandwidth Profile is used to regulate the amount of egress traffic at a particular UNI. The
Ingress Bandwidth Profile is described in Section 7.11.2. The Egress Bandwidth Profile is
described in Section 7.11.3.

A Bandwidth Profile is a characterization of the lengths and arrival times for Service Frames at a
reference point. For the Ingress Bandwidth Profile, this reference point is the ingress UNI. For
the Egress Bandwidth Profile, this reference point is the egress UNI.

A Bandwidth Profile, if present, SHOULD be enforced by the providers network since it is part
of the Service Level Specification (SLS) and is agreed upon between the Subscriber and the
Service Provider.

Typically a Bandwidth Profile defines Service Frame traffic that is less than the full bandwidth
of the UNI. Thus the Bandwidth Profile can be considered to be analogous to the traffic policing
of Frame Relay.[4]

Bandwidth Profiles are associated with the UNI. This allows different Bandwidth Profiles at each
UNI in an EVC as in Section 7.11.2.2. For example, on a Multipoint-to-Multipoint EVC, a
different Bandwidth Profile could apply at each UNI in the EVC. To describe this situation on an
EVC basis would require the specification of a vector of Bandwidth Profiles, one for each UNI.
Thus, to simplify the description, Bandwidth Profiles are specified as a UNI service attribute.

The Bandwidth Profile defines the set of traffic parameters applicable to a sequence of Service
Frames. Associated with the Bandwidth Profile is an algorithm to determine Service Frame
compliance with the specified parameters. In the case of an Ingress Bandwidth Profile, rate
enforcement is accomplished via the disposition of non-compliant Service Frames.

All Bandwidth Profiles in this Technical Specification are based on the parameters and algorithm
described in this section. New algorithms, such as additional algorithms based on Class of
Service, are for further study.

7.11.1 Standard Bandwidth Profile Parameters and Algorithm

The parameters comprising the Bandwidth Profile parameters are:


MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 36
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.
Ethernet Services Attributes Phase 2

Committed Information Rate (CIR) expressed as bits per second. CIR MUST be 0.

Committed Burst Size (CBS) expressed as bytes. When CIR > 0, CBS MUST be greater
than or equal to the largest Maximum Transmission Unit size among all of the EVCs that
the Bandwidth Profile applies to. See Section 6.10.

Excess Information Rate (EIR) expressed as bits per second. EIR MUST be 0.

Excess Burst Size (EBS) expressed as bytes. When EIR > 0, EBS MUST be greater than
or equal to the largest Maximum Transmission Unit size among all of the EVCs that the
Bandwidth Profile applies to. See Section 6.10.

Coupling Flag (CF) MUST have only one of two possible values, 0 or 1.

Color Mode (CM) MUST have only one of two possible values, color-blind and
color-aware.

Each Service Frame is classified to determine which, if any, Bandwidth Profile is applicable to
the Service Frame. 18 Operation of the Bandwidth Profile algorithm is governed by the six
parameters, <CIR, CBS, EIR, EBS, CF, CM>. The algorithm declares each Service Frame to be
compliant or non-compliant relative to the Bandwidth Profile. The level of compliance is
expressed as one of three colors, Green, Yellow, or Red. 19

The Bandwidth Profile algorithm is said to be in color aware mode when each Service Frame
already has a level of compliance (i.e., a color) associated with it and that color is taken into
account in determining the level of compliance by the Bandwidth Profile algorithm. The
Bandwidth Profile algorithm is said to be in color blind mode when the color (if any) already
associated with each Service Frame is ignored by the Bandwidth Profile Algorithm. Color blind
mode support is REQUIRED for Bandwidth Profiles. Color aware mode is OPTIONAL for
Bandwidth Profiles. The color mode of operation MUST be determined using the parameter CM.

Since the coupling Flag has negligible effect in color blind mode (CM = color-blind), a service
definition that uses color blind operation MAY be defined without specifying the value of the
coupling flag.

The Bandwidth Profile algorithm is shown in Figure 13. For a sequence of Service Frames,
{t j , l j }, j 0, t j +1 t j , with arrival times at the reference point t j and lengths l j , the level of
compliance color assigned to each Service Frame MUST be defined according to the algorithm
in Figure 13. For this algorithm, Bc (t0 ) = CBS and Be (t0 ) = EBS . Bc (t ) and Be (t ) can be viewed
as the number of bytes in the Committed and Excess token buckets respectively at a given time t.

18
Recall that a Service Frame is defined as any Ethernet Frame transmitted across the UNI and thus a Layer 2
Control Protocol Ethernet frame is a Service Frame and thus can be subject to a Bandwidth Profile.
19
The categorization of a Service Frame does not imply any change to the content of the frame. Certain approaches
to network implementation may mark frames internal to the MEN but such procedures are beyond the scope of
this Technical Specification.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 37
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.
Ethernet Services Attributes Phase 2
Service Frame of length l j arrives at time t j ( j 1)

Bc (t j ) = min CBS , Bc (t j 1 ) + (t j t j 1 )
CIR
8
O (t j ) = max 0, Bc (t j 1 ) + (t j t j 1 ) CBS
CIR
8
Be (t j ) = min EBS , Be (t j 1 ) + (t j t j 1 ) + CF O(t j )
EIR
8

[(CM == color - blind ) Yes


OR (Service Frame == Green )]
Declare Service Frame Green
Bc (t j ) = Bc (t j ) l j
AND (l j Bc (t j ))
No

[(CM == color - blind ) Yes


OR (Service Frame != Red )]
Declare Service Frame Yellow
Be (t j ) = Be (t j ) l j
AND (l j Be (t j ))
No

Declare Service Frame Red

Figure 13 The Bandwidth Profile Algorithm

Note that the algorithm in Figure 13 does not define an implementation of any network
equipment. In fact, since the behavior is described with real numbers for representing time,
exactly implementing the behavior is theoretically impossible. However, an implementation
should be such that over any time interval [t j , t k ] the amount of traffic declared green, WG and
the amount of traffic declared yellow, WY are lower bounded below by the values:

WG Bc (t j ) + (t k t j )
CIR
8

WY Be (t j ) + (t k t j )
EIR
8

provided that the traffic is greater than these values.

The Coupling Flag CF is set to either 0 or 1. The choice of the value for CF has the effect of
controlling the volume of the Service Frames that are declared Yellow. When CF is set to 0, the
long term average bit rate of Service Frames that are declared Yellow is bounded by EIR. When
CF is set to 1, the long term average bit rate of Service Frames that are declared Yellow is
bounded by CIR + EIR depending on volume of the offered Service Frames that are declared
Green. In both cases the burst size of the Service Frames that are declared Yellow is bounded by
EBS.

MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 38
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.
Ethernet Services Attributes Phase 2

7.11.2 Ingress Bandwidth Profiles Service Attributes

The Ingress Bandwidth Profile is used to regulate the amount of ingress traffic at a particular
UNI. An Ingress Bandwidth Profile is defined for ingress Service Frames at the particular UNI.
In other words, the sequence {t j , l j }, j 0, to which the algorithm of Section 7.11.1 is applied is
based on ingress Service Frames at a UNI. There are three Ingress Bandwidth Profile models as
described in Sections 7.11.2.1, 7.11.2.2, and 7.11.2.3.

7.11.2.1 Ingress Bandwidth Profile per Ingress UNI Service Attribute

In this model, a single Ingress Bandwidth Profile MUST be applied to all ingress Service Frames
at the UNI. Figure 14 illustrates an example of the application of ingress policing with an Ingress
Bandwidth Profile per ingress UNI. In the example of Figure 14, ingress Service Frames for the
three EVCs would all be subject to a single Ingress Bandwidth Profile. The Ingress Bandwidth
Profile per Ingress UNI manages bandwidth non-discriminately for all EVCs at the UNI, i.e.
some EVCs may get more bandwidth while others may get less.

The Ingress Bandwidth Profile per Ingress UNI service attribute is independent of the EVCs at
the UNI.

EVC1

Bandwidth Profile
UNI EVC2 per Ingress UNI

EVC3

Figure 14 Ingress Bandwidth Profile per Ingress UNI

7.11.2.2 Ingress Bandwidth Profile per EVC Service Attribute

In this model, a single Ingress Bandwidth Profile MUST be applied to all ingress Service Frames
for an instance of an EVC at the UNI. Thus, if a UNI has 3 Ethernet Virtual Connections, there
could be 3 Ingress Bandwidth Profiles, one for each EVC. Figure 15 illustrates an example of the
application of Ingress Bandwidth Profiles per EVC. In this example, EVC1 could have CIR=15
Mbps, EVC2 could have CIR = 10 Mbps, and EVC3 could have CIR = 20 Mbps.

The Ingress Bandwidth Profile per EVC service attribute is associated with each EVC at the
UNI.

MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 39
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.
Ethernet Services Attributes Phase 2

EVC1 Bandwidth Profileper EVC1

UNI EVC2 Bandwidth Profile per EVC2

EVC3 Bandwidth Profile per EVC3

Figure 15 Ingress Bandwidth Profile per EVC

7.11.2.3 Ingress Bandwidth Profile per Class of Service Identifier Service Attribute

In this model, a single Ingress Bandwidth Profile MUST be applied to all ingress Service Frames
with a specific Class of Service Identifier. Class of Service Identifiers are specified in Section
6.8. Refer to the example in Figure 16. In this example, there are three Class of Service
Identifiers within EVC1, each with a separate Ingress Bandwidth Profile.

The Ingress Bandwidth Profile per Class of Service Identifier service attribute is associated with
each EVC at the UNI.

CE-
CE-VLAN CoS 0,1,2,3 Ingress Bandwidth Profile per CoS ID

EVC1 CE-
CE-VLAN CoS 4,5 Ingress Bandwidth Profile per CoS ID
CE-
CE-VLAN CoS 6,7
Ingress Bandwidth Profile per CoS ID

UNI

EVC2

Figure 16 Ingress Bandwidth Profile per Class of Service Identifier

7.11.2.4 Simultaneous Application of the Ingress Bandwidth Profile Application Models

Multiple models of Ingress Bandwidth Profile application MAY exist simultaneously at a UNI.
However, a UNI MUST be configured such that only a single Ingress Bandwidth Profile applies
to any given ingress Service Frame. This means that:

MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 40
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.
Ethernet Services Attributes Phase 2

If there is a per UNI Ingress Bandwidth Profile, then there cannot be any other Ingress
Bandwidth Profiles at that UNI.

If there is a per EVC Ingress Bandwidth Profile on an EVC, then there cannot be any per
Class of Service Ingress Bandwidth Profiles for instances of CoS on that EVC.

For example, in the configuration of Figure 16, there cannot be an Ingress Bandwidth Profile for
EVC1. Note also for the configuration in Figure 16, that it is possible to configure a per-EVC
Ingress Bandwidth Profile for EVC2 but there happens to not be an Ingress Bandwidth Profile for
EVC2 in this example.

7.11.2.5 Service Frame Disposition

The disposition of a given Service Frame with respect to delivery to an egress UNI is dependent
on the Service Frames level of compliance to the Ingress Bandwidth Profile that is applied to it.
This is called the Ingress Bandwidth Profile compliance level and it has three possible values:
Green, Yellow, or Red. Table 11 defines how the Ingress Bandwidth Profile compliance is
related to the disposition of the Service Frame. In this table, Not Applied identifies the case
where no Ingress Bandwidth Profile was applied to the Service Frame in question.

The disposition of each Service Frame for delivery to each egress UNI MUST be as described in
Table 11.

Ingress Bandwidth
Service Frame Disposition
Profile Compliance
Red Discard
Deliver to the egress UNI according to the Service Attributes of the
Yellow
service instance but SLS performance objectives do not apply.
Green Deliver to the egress UNI according to the Service Attributes of the
Not Applied service instance and SLS performance objectives apply.
Table 11 Service Frame Disposition for Each Egress UNI

The behavior described in Table 11 is based on the arrival of the Service Frame at its ingress
UNI. It does not mandate or constrain in any way the implementation within the Service Provider
network.

From Table 11 it is clear that the better the level of Ingress Bandwidth Profile compliance the
better the performance of the service. In order to increase the level of Ingress Bandwidth Profile
compliance a Subscriber may choose to shape traffic in the CE (see Section 10.3).

7.11.3 Egress Bandwidth Profiles Service Attributes

An Egress Bandwidth Profile is used to regulate the amount of egress traffic at a particular UNI.
An Egress Bandwidth Profile is defined for a particular UNI and applies to all or a subset of all
egress Service Frames at the UNI in question.

MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 41
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.
Ethernet Services Attributes Phase 2

The reference point for an Egress Bandwidth Profile is the egress UNI. An Egress Bandwidth
Profile describes arrival times and lengths of Service Frames that will be observed at the egress
UNI when an Egress Bandwidth Profile is in operation in the Service Provider network. This
description is given in terms of what would happen if an observer at the egress UNI applied the
algorithm of Section 7.11.1 to egress Service Frames. This observer would see traffic after it had
been subject to rate limiting and/or shaping in the Service Provider network and thus would have
certain characteristics. These characteristics are described in terms of the behavior of the
algorithm of Section 7.11.1 when run by the observer.

Consider a sequence of egress Service Frames subject to an Egress Bandwidth Profile with
parameters <CIR, CBS, EIR, EBS, CF, CM> and with arrival times and lengths at the egress
UNI, {t j , l j }, j 0 . If the algorithm of Section 7.11.1 is applied to these Service Frames, the
result for each Service Frame SHALL be to declare the Service Frame either Green or Yellow.

The implication is that the regulation of the Service Frames in the Service Provider network is
such that all Service Frames that would determined to be Red by the observer are discarded
before reaching the egress UNI. It is important to reiterate that this description of Egress
Bandwidth Profile does not mandate or constrain in any way the implementation in the Service
Provider network.

There are three Egress Bandwidth Profile models as described in Sections 7.11.3.1, 7.11.3.2, and
7.11.3.3.

7.11.3.1 Egress Bandwidth Profile per Egress UNI Service Attribute

In this model, a single Egress Bandwidth Profile MUST be applied to the sequence consisting of
all egress Service Frames at the UNI. The Egress Bandwidth Profile per Egress UNI manages
bandwidth non-discriminately for all EVCs at the egress UNI, i.e. some EVCs may get more
bandwidth while others may get less. Figure 17 portrays this model of Egress Bandwidth Profile.

The Egress Bandwidth Profile per Egress UNI service attribute is independent of the EVCs at the
UNI.

MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 42
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.
Ethernet Services Attributes Phase 2

Figure 17 Egress Bandwidth Profile per Egress UNI

7.11.3.2 Egress Bandwidth Profile per EVC Service Attribute

In this model, a single Egress Bandwidth Profile is defined for an EVC at the egress UNI. It
MUST be applied to the egress Service Frames that are mapped to the EVC in question. Figure
18 illustrates an Egress Bandwidth Profile for EVC1.

The Egress Bandwidth Profile per EVC service attribute is associated with each EVC at the UNI.

Figure 18 Egress Bandwidth Profile per EVC

MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 43
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.
Ethernet Services Attributes Phase 2

7.11.3.3 Egress Bandwidth Profile per Class of Service Identifier Service Attribute

In this model, a single Egress Bandwidth Profile is defined for a specific Class of Service
Identifier that is defined at the egress UNI. It MUST be applied to the egress Service Frames
with the Class of Service Identifier in question. As an example, consider an Egress UNI with two
EVCs with each EVC having 3 Class of Service Identifiers. With this model, there can be up to
six Egress Bandwidth Profiles.

The Egress Bandwidth Profile per Class of Service Identifier service attribute is associated with
each EVC at the UNI.

7.11.3.4 Simultaneous Application of the Egress Bandwidth Profile Application Models

Multiple models of Egress Bandwidth Profile application MAY exist simultaneously for an
egress UNI. However, an egress Service Frame MUST be subject to at most one Egress
Bandwidth Profile. This means that:

If there is a per UNI Egress Bandwidth Profile, then there cannot be any other Egress
Bandwidth Profiles at that UNI.

If there is a per EVC Egress Bandwidth Profile on an EVC, then there cannot be any per
Class of Service Egress Bandwidth Profiles for instances of CoS on that EVC.

7.12 Security

The Ethernet Virtual Connection is the fundamental service construct that defines how the
separation between Subscribers traffic is maintained. Additional security constructs and service
attributes may be addressed in subsequent phases of this Technical Specification.

7.13 UNI Layer 2 Control Protocol Processing Service Attribute

There are four alternatives for processing a given Layer 2 Control Protocol (see Table 1) at a
UNI as described in the following subsections. The UNI Layer 2 Control Protocol Processing
service attribute is independent of the EVCs at the UNI.

7.13.1 Discard

When this alternative is in force, the MEN MUST discard all ingress Service Frames carrying
the Layer 2 Control Protocol and the MEN MUST NOT generate any egress Service Frames
carrying the Layer 2 Control Protocol. Note that when this alternative is in force for the Layer 2
Control Protocol, the Layer 2 Control Protocol cannot be processed by an EVC. See Section 6.7.

MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 44
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.
Ethernet Services Attributes Phase 2

7.13.2 Peer

When this alternative is in force, the MEN MUST act as a peer of the CE in the operation of the
Layer 2 Control Protocol. From the CE point of view, the MEN is a single device that is running
the Layer 2 Control Protocol.

7.13.3 Pass to EVC

When this alternative is in force, the disposition of the Layer 2 Control Protocol MUST be
determined by the Layer 2 Control Protocol Processing attribute of the EVC (tunneled or
discarded). The EVC associated with Layer 2 Control Protocol is determined by the CE-VLAN
ID of the Service Frame and CE-VLAN ID/EVC Map. See Section 6.7.

7.13.4 Peer and Pass to EVC


When this alternative is in force, some Service Frames carrying the Layer 2 Control Protocol are
processed by the MEN as a peer while other Service Frames carrying the Layer 2 Control
Protocol are passed to the EVC. The method for identifying that a Service Frame is to be peered
or passed to the EVC MUST be specified for each service. As an example, different destination
MAC addresses might be used to indicate the handling of a Service Frame carrying the Layer 2
Control Protocol.

8. Ethernet Service Framework

The Ethernet service framework provides the definition and relationship between attributes and
their associated parameters used to create an Ethernet Service. An Ethernet Service consists of
(Refer to Figure 19):

One Ethernet Service Type,

One or more Ethernet Service Attributes and

One or more parameter values associated with each Ethernet Service Attribute.

The Service Framework associates a service with the UNI characteristics at which the Service is
offered to the Subscriber and with the EVC supporting the service. The Ethernet Service
Attributes are what define the UNI and EVC characteristics.

MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 45
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.
Ethernet Services Attributes Phase 2

Figure 19 Ethernet Service Framework

8.1 Ethernet Service Types

Ethernet Service Types can be used to create a broad range of services. Each Ethernet Service
Type has a set of Ethernet Service Attributes that define the service characteristics. These
Ethernet Service Attributes in turn have a set of parameters associated with them that provide
various options for the different Service Attributes. Refer to Figure 19. Two Ethernet Service
Types have been defined in [5]. The first, Ethernet Line Service (E-Line Service), uses a Point-
to-Point EVC. The second, Ethernet LAN Service (E-LAN Service), uses a Multipoint-to-
Multipoint EVC.

8.2 Service Attributes

The Service Attributes define the capabilities of the Ethernet Service Type. Some or all of the
Service Attributes may apply to an Ethernet Service Type. Service Attributes are described in
Section 6 and Section 7.

8.3 Service Attribute Parameters

For each Service Attribute there can be one or more parameters that specify the attribute.
Parameters can have various types of values including:

Logical (true or false)

Integer

Bandwidth

Protocol

Vector of values of multiple types

Character String.

MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 46
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.
Ethernet Services Attributes Phase 2

8.4 Ethernet Service Framework Summary

For a particular Ethernet Service Type, there are two types of Service Attributes, those that apply
to a UNI as described in Section 7 and those that apply to an EVC as described in Section 6. The
UNI and EVC per UNI Service Attributes are listed in Table 12 along with the type of parameter
value for the attribute. For a given instance of a service, a table like that of Table 12 MUST be
specified for each UNI in the EVC associated with the service.

MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 47
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.
Ethernet Services Attributes Phase 2

Attribute Type of Parameter Value


UNI Identifier (Section 7.1) Any string
Physical Medium (Section 7.2) A Standard Ethernet PHY ([2] or [3]) 20
Speed (Section 7.2) 10 Mbps, 100 Mbps, 10/100 Mbps Auto-
Negotiation, 1 Gbps, or 10 Gbps20
Mode (Section 7.2) Full Duplex
MAC Layer (Section 7.3) IEEE 802.3 2005 [2]
UNI Maximum Transmission Unit Size Integer 1522.
(Section 7.4)
Service Multiplexing (Section 7.5) Yes or No 21
UNI EVC ID (Section 7.6.2) A string formed by the concatenation of the UNI
ID and the EVC ID
CE-VLAN ID for untagged and priority A number in 1, 2, , 4094.
tagged Service Frames (Section 7.6)
CE-VLAN ID/EVC Map (Section 7.7) Map as per Section 7.7
Maximum Number of EVCs (Section 7.8) Integer 1
Bundling (Section 7.9) Yes or No21
All to One Bundling (Section 7.10) Yes or No 22
Ingress Bandwidth Profile Per Ingress UNI No or parameters as defined in Section 7.11.1
(Section 7.11.2.1)
Ingress Bandwidth Profile Per EVC No or parameters as defined in Section 7.11.1 for
(Section 7.11.2.2) each EVC 23
Ingress Bandwidth Profile Per Class of No or parameters as defined in Section 7.11.1 for
Service Identifier (Section 7.11.2.3) each Class of Service Identifier 24
Egress Bandwidth Profile Per Egress UNI No or parameters as defined in Section 7.11.1
(Section 7.11.3.1)
Egress Bandwidth Profile Per EVC No or parameters as defined in Section 7.11.1 for
(Section 7.11.3.2) each EVC 25
Egress Bandwidth Profile Per Class of No or parameters as defined in Section 7.11.1 for
Service Identifier (Section 7.11.3.3) each Class of Service Identifier 26
Layer 2 Control Protocols Processing A list of Layer 2 Control Protocols with each
(Section 7.13) being labeled with one of Discard, Peer, Pass to
EVC, Peer and Pass to EVC 27
Table 12 UNI and EVC per UNI Service Attributes

20
There are interdependencies among the values of these parameters as per the IEEE 802.3 Standard.[2]
21
Must be No if All to One Bundling is Yes.
22
Must be No if Bundling is Yes or Service Multiplexing is Yes.
23
Must be No if Ingress Bandwidth Profile Per Ingress UNI is not No.
24
Must be No if Ingress Bandwidth Profile Per EVC is not No.
25
Must be No if Egress Bandwidth Profile Per Egress UNI is not No.
26
Must be No if Egress Bandwidth Profile Per EVC is not No.
27
If Peer and Pass to EVC, the method for identifying that a Service Frame is to be peered or passed to the EVC
must be specified.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 48
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.
Ethernet Services Attributes Phase 2

The EVC Service Attributes are listed in Table 13 along with the type of parameter value for the
attribute. For a given instance of a service, a table like that of Table 13 MUST be specified for
the EVC associated with the service.

Attribute Type of Parameter Value


EVC Type (Section 6.1) Point-to-Point, Multipoint-to-Multipoint, or Rooted-Multipoint
EVC ID (Section An arbitrary string, unique across the MEN, for the EVC supporting
6.1.2.2) the service instance
UNI List (Section 6.3) A list of <UNI Identifier, UNI Type> pairs
Maximum Number of Integer. MUST be 2 if EVC Type is Point-to-Point. MUST be
UNIs (Section 6.4) greater than or equal to 2 otherwise.
EVC Maximum Integer 1522.
Transmission Unit Size
(Section 6.10)
CE-VLAN ID Yes or No
Preservation (6.6.1)
CE-VLAN CoS Yes or No
Preservation (Section
6.6.2)
Unicast Service Frame Discard, Deliver Unconditionally, or Deliver Conditionally. If
Delivery (6.5.1.1) Deliver Conditionally is used, then the conditions MUST be
specified.
Multicast Service Frame Discard, Deliver Unconditionally, or Deliver Conditionally. If
Delivery (Section Deliver Conditionally is used, then the conditions MUST be
6.5.1.2) specified.
Broadcast Service Frame Discard, Deliver Unconditionally, or Deliver Conditionally. If
Delivery (Section Deliver Conditionally is used, then the conditions MUST be
6.5.1.3) specified.
Layer 2 Control A list of Layer 2 Control Protocols labeled Tunnel or Discard.
Protocols Processing
(Section 6.7)
EVC Performance Performance objectives for One-way Frame Delay Performance,
(Sections 6.8 and 6.9) One-way Frame Delay Range Performance, One-way Mean Frame
Delay Performance, Inter-Frame Delay Variation Performance, One-
way Frame Loss Ratio Performance, and Availability Performance
and associated Class of Service Identifier(s) as defined in Section 6.8.
Table 13 EVC Service Attributes

9. References

[1] Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, RFC 2119,
March 1997. (Normative)

[2] IEEE Std 802.3 2005, Information technology Telecommunications and


information exchange between systems Local and metropolitan area networks

MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 49
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.
Ethernet Services Attributes Phase 2

Specific requirements Part 3: Carrier sense multiple access with collision detection
(CSMA/CD) access method and physical layer specifications, 9 December 2005.
(Normative)

[3] IEEE Std 802.3ae 2002, IEEE Standard for Information technology
Telecommunications and information exchange between systems Local and
metropolitan area networks Specific requirements Part 3: Carrier Sense Multiple
Access with Collision Detection (CSMA/CD) Access Method and Physical Layer
Specifications Amendment: Media Access Control (MAC) Parameters, Physical
Layers, and Management Parameters for 10 Gb/s Operation, 13 June 2002. (Normative)

[4] International Telecommunication Union, Recommendation I.370, Integrated Services


Digital Network (ISDN), Overall Network Aspects And Functions, ISDN User-
Network Interfaces, Congestion Management For The ISDN Frame Relaying Bearer
Service, 1991.

[5] Metro Ethernet Forum, MEF 6, Ethernet Services Definitions - Phase 1, June 2004.

[6] C. Demichelis and P. Chimento, IP Packet Delay Variation Metric for IP Performance
Metric (IPPM), RFC 3393, November 2002.

[7] Metro Ethernet Forum MEF 10, Ethernet Services Attributes Phase 1, November 2004.

[8] IEEE Std 802.1D 2004, IEEE Standard for Local and Metropolitan Area Networks:
Media Access Control (MAC) Bridges, June 2004.

[9] IEEE Std 802.1Q 2003, IEEE Standards for Local and metropolitan area networks
Virtual Bridged Local Area Networks, 7 May 2003.

[10] IEEE Std 802.1ad 2005, IEEE Standard for Local and Metropolitan Area Networks
Virtual Bridged Local Area Networks Amendment 4: Provider Bridges, May 2006.

[11] Metro Ethernet Forum MEF 16, Ethernet Local Management Interface (E-LMI),
January 2006.

[12] Metro Ethernet Forum MEF 7, EMS-NMS Information Model, October 2004.

[13] Metro Ethernet Forum MEF 10.1, Ethernet Services Attributes Phase 2, November
2006.

10. Appendix (Informative)

This appendix contains examples of some of the attributes specified in this Technical
Specification. They are for illustrative purposes only. In the event of a conflict between the
material in this appendix and the main body of this text, the material in the main body is
controlling.

MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 50
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.
Ethernet Services Attributes Phase 2

10.1 CE-VLAN ID Preservation Service Attribute

The following is a list of examples covering the CE-VLAN ID Preservation Service Attribute for
both CE-VLAN ID Preservation = Yes and CE-VLAN ID Preservation = No. See Section 6.6.1.

10.1.1 CE-VLAN ID Preservation = Yes

Figure shows the notation used for the CE-VLAN ID/EVC Maps in the examples in this sub-
section.

INGRESS EGRESS INGRESS SERVICE FRAME EGRESS SERVICE FRAME


MAP MAP FORMAT FORMAT
Untagged Untagged
A* A* Priority Tagged Priority Tagged
Tagged Tagged

B B Tagged Tagged

Scenario A*: Untagged/Priority Tagged Service Frames are mapped to the EVC
Scenario B : Untagged/Priority Tagged Service Frames are not mapped to the EVC

Figure 20 CE-VLAN ID/EVC Map Notation

INGRESS FRAMES (UNI A) INGRESS FRAMES (UNI B)


Frame A - Untagged Frame E - Untagged
Frame B - Priority Tagged EVC1 Frame F - Priority Tagged
Frame C - Tagged 10 Frame G - Tagged 10
Frame D - Tagged 12 Frame H - Tagged 12

EGRESS FRAMES (UNI A) EGRESS FRAMES (UNI B)


Frame E - Untagged UNI A UNI B Frame A - Untagged
Frame F - Priority Tagged Frame B - Priority Tagged
Frame G - Tagged 10 CE-VLAN ID EVC CE-VLAN ID EVC Frame C - Tagged 10
Frame H - Tagged 12 Frame D - Tagged 12
1, ..., 4095 EVC1 1, ..., 4095 EVC1

Figure 21 Example 1: CE-VLAN ID Preservation = Yes with All to One Bundling 28

INGRESS FRAMES (UNI C) INGRESS FRAMES (UNI D)


EVC2
Frame A - Untagged Frame F - Untagged
Frame B - Priority Tagged Frame G - Priority Tagged
Frame C - Tagged 20 EVC3 Frame H - Tagged 20
Frame D - Tagged 22 Frame I - Tagged 22
Frame E - Tagged 30 Frame J - Tagged 30

EGRESS FRAMES (UNI C) UNI C UNI D EGRESS FRAMES (UNI D)


Frame F - ? Frame A - ?
Frame G - ? CE-VLAN ID EVC CE-VLAN ID EVC Frame B - ?
Frame H - Tagged 20 Frame C - Tagged 20
Frame I - Tagged 22 20*, 22 EVC2 20*, 22 EVC2 Frame D - Tagged 22
Frame J - Tagged 30 Frame E - Tagged 30
? means format not mandated 30 EVC3 30 EVC3 ? means format not mandated

Figure 22 Example 2: CE-VLAN ID Preservation = Yes with Bundling on EVC228

28
When a UNI has the All to One Bundling or Bundling Attribute set to TRUE, CE-VLAN ID Preservation is
mandated to be yes.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 51
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.
Ethernet Services Attributes Phase 2

10.1.2 CE-VLAN ID Preservation = No


Figure shows the notation used for the CE-VLAN ID/EVC Maps in the examples in this sub-
section.
INGRESS EGRESS INGRESS SERVICE FRAME EGRESS SERVICE FRAME
MAP MAP FORMAT FORMAT
Untagged Untagged
A* A* Priority Tagged Untagged
Tagged Untagged
Untagged Tagged
A* B Priority Tagged Tagged
Tagged Tagged
B A* Tagged Untagged

B B Tagged Tagged
Scenario A*: Untagged/Priority Tagged Service Frames are mapped to the EVC
Scenario B : Untagged/Priority Tagged Service Frames are not mapped to the EVC

Figure 23 CE-VLAN ID/EVC Map Notation

MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 52
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.
Ethernet Services Attributes Phase 2
INGRESS FRAMES (UNI E) INGRESS FRAMES (UNI F)
Frame A - Untagged Frame E - Untagged
Frame B - Priority Tagged EVC4 Frame F - Priority Tagged
Frame C - Tagged 40 Frame G - Tagged 44
Frame D - Tagged 42 Frame H - Tagged 46
UNI E UNI F
EGRESS FRAMES (UNI E) EGRESS FRAMES (UNI F)
Frame E - Untagged EVC Frame A - Untagged
CE-VLAN ID EVC CE-VLAN ID
Frame F - Untagged Frame B - Untagged
Frame G - Untagged Frame C - Untagged
40* EVC4 44* EVC4

INGRESS FRAMES (UNI G) INGRESS FRAMES (UNI H)


Frame A - Untagged Frame E - Untagged
Frame B - Priority Tagged EVC5 Frame F - Priority Tagged
Frame C - Tagged 50 Frame G - Tagged 54
Frame D - Tagged 52 Frame H - Tagged 56
UNI G UNI H
EGRESS FRAMES (UNI G) EGRESS FRAMES (UNI H)
Frame H - Untagged Frame A - Tagged 56
CE-VLAN ID EVC CE-VLAN ID EVC
Frame B - Tagged 56
Frame C - Tagged 56
50* EVC5 56 EVC5

INGRESS FRAMES (UNI I) INGRESS FRAMES (UNI J)


Frame A - Untagged Frame E - Untagged
Frame B - Priority Tagged EVC6 Frame F - Priority Tagged
Frame C - Tagged 60 Frame G - Tagged 64
Frame D - Tagged 62 Frame H - Tagged 60
UNI I UNI J
EGRESS FRAMES (UNI I) EGRESS FRAMES (UNI J)
Frame H - Untagged EVC Frame A - Tagged 60
CE-VLAN ID EVC CE-VLAN ID
Frame B - Tagged 60
Frame C - Tagged 60
60* EVC6 60 EVC6

INGRESS FRAMES (UNI K) INGRESS FRAMES (UNI L)


Frame A - Untagged Frame E - Untagged
Frame B - Priority Tagged EVC7 Frame F - Priority Tagged
Frame C - Tagged 70 Frame G - Tagged 74
Frame D - Tagged 72 Frame H - Tagged 76
UNI K UNI L
EGRESS FRAMES (UNI K) EGRESS FRAMES (UNI L)
Frame H - Tagged 72 Frame D - Tagged 76
CE-VLAN ID EVC CE-VLAN ID EVC

72 EVC7 76 EVC7

Figure 24 Example 3: CE-VLAN ID Preservation = No 29

10.2 Examples of the Use of the CE-VLAN ID/EVC Map and EVCs

This section presents examples of the use of EVCs and the CE-VLAN ID/EVC Map. It is
intended to clarify the concepts and present likely deployment scenarios.

10.2.1 Untagged UNIs

In connecting branch enterprise locations to a hub enterprise location, it is desirable to make the
configuration of the branch CEs simple. A similar objective applies to providing access to higher
layer services, e.g., Internet Access, where the configuration of the CE at the sites accessing the
29
Note that many L2CP Service Frames cannot be tunneled on EVC5 and EVC6 since Untagged/Priority Tagged
Service Frames are not mapped to the EVCs at UNIs H and J. See Section 6.7.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 53
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.
Ethernet Services Attributes Phase 2

service should be kept simple. Figure 25 shows an example of 3 UNIs (A, B, and C) where CEs
only capable of handling untagged Ethernet frames are attached. The CE-VLAN ID/EVC maps
are shown for each UNI. The asterisk indicates the CE-VLAN ID assigned to untagged/priority
tagged Service Frames.
A
EVC1
D
EVC2 B
C
EVC3

EVCs UNI A UNI B UNI C UNI D


EVC UNIs CE-VLAN EVC CE-VLAN EVC CE-VLAN EVC CE-VLAN EVC
ID ID ID ID
EVC1 A,D *17 EVC1 2065 EVC1
EVC2 B,D *337 EVC2 2066 EVC2
EVC3 C,D *1023 EVC3 2067 EVC3
Figure 25 Untagged UNIs

Consider an untagged ingress Service Frame at UNI A. It will be mapped to EVC1 and delivered
to UNI D. At UNI D, it will become a tagged egress Service Frame with VLAN ID 2065. A
tagged ingress Service Frame at UNI D with VLAN ID 2065 will be mapped to EVC1 and
delivered to UNI A. At UNI A, it will become an untagged (see Section 7.6.1) egress Service
Frame.

10.2.2 Use of Rooted-Multipoint EVC

An example of the use of the Rooted-Multipoint EVC is shown in Figure 26. A higher layer
service is being provided via UNI D to three different customers at UNIs A, B, and C. By using a
Rooted-Multipoint EVC, all three customers can be reached by the higher layer service provider
at UNI D using a single EVC. Each customers CE can only send to the higher layer service CE
thus keeping each customer from seeing other customers traffic. Compared with the example
shown in Figure 25, this can save a large number of Point-to-Point EVCs when there are a large
number of customers. Note that the CEs do not necessarily have to send and receive tagged
Service Frames. In particular, the CEs at UNIs A and C do not need to send or receive tagged
Service Frames in this example.

A
Higher
Higher D
B Layer
Layer
EVC1 Service
Service C
Customers

MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 54
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.
Ethernet Services Attributes Phase 2
EVCs UNI A UNI B UNI C UNI D
EVC UNIs CE-VLAN ID EVC CE-VLAN ID EVC CE-VLAN ID EVC CE-VLAN ID EVC
EVC1 A (Leaf) *17 EVC1 3379 EVC1 *1023 EVC1 2065 EVC1
B (Leaf)
C (Leaf)
D (Root)

Figure 26 Use of a Rooted-Multipoint EVC

10.2.3 Redundant Higher Layer Service Access

The example shown in Figure 27 illustrates the use of service multiplexing and Multipoint-to-
Multipoint EVCs to provide redundant access to higher layer services. A Multipoint-to-
Multipoint EVC is used for each customer of the higher layer service. Higher layer service
routers are attached to two UNIs (C and D in the example) in each such EVC. Routing protocols
running among the two higher layer service routers and the customer router allow the customer
to access the higher layer service in a redundant fashion.

A
C Higher
Higher EVC1
Layer
Layer D Service
Service EVC2 B
Customers

EVCs UNI A UNI B UNI C UNI D


EVC UNIs CE-VLAN ID EVC CE-VLAN ID EVC CE-VLAN ID EVC CE-VLAN ID EVC
EVC1 A,C,D 2881 EVC1 124 EVC1 2065 EVC1
EVC2 B,C,D 3379 EVC2 125 EVC2 2066 EVC2

Figure 27 Redundant Higher Layer Service Access

10.3 Traffic Shaping

Shaping is a procedure to reduce the burstiness of traffic. When done in the CE it is meant to
increase the level of Ingress Bandwidth Profile compliance (see Section 7.11.2.5). A shaper is
defined by a set of parameters. Those parameters should be chosen to ensure that the delay
introduced by shaping function is bounded within the acceptable limits and that the traffic
dropped at the shaper is kept to a minimum.

A shaper could be a single rate or a double rate shaper. A single rate shaper could consist of three
parameters CIR, CBS*, and CBS, in which:

CIR = the shaping rate of Green packets (average output rate of the shaper),

CBS = the shaping burst of Green packets (maximum output burst of the shaper)

CBS* = the accepted burst of Green packets (maximum buffer size for Green packets)

MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 55
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.
Ethernet Services Attributes Phase 2

CBS* CBS, which means the shaper accepts larger burst at its input and generates
smaller bursts at its output.

A double rate shaper could consist of parameters CIR, CBS*, CBS, EIR, EBS*, and EBS, in
which, CIR, CBS*, and CBS are as defined above, and EIR, EBS*, and EBS are:

EIR = the shaping rate of Yellow packets (average output rate of the shaper),

EBS = the shaping burst of Yellow packets (maximum output burst of the shaper)

EBS* = the accepted burst of Yellow packets (maximum buffer size for Yellow packets)

EBS* EBS, which means the shaper accepts larger burst at its input and generates
smaller bursts at its output.

It is recommended that the CE shape the traffic it sends into the MEN, so that the output of the
shaper matches the CIR, CBS, EIR, and EBS parameters of the appropriate Bandwidth Profile.

For example, the CE could shape with a dual rate token bucket shaper using parameters CIR,
CBS*, CBS, EIR, EBS*, and EBS where EBS* = 0 and CBS* is the shapers buffer size. Define
the following notation:

B(t) = the instantaneous buffer occupancy in bytes,

C(t) = the instantaneous value of the tokens in the Committed token bucket,

E(t) = the instantaneous value of the tokens in the Excess token bucket,

L = the length of the frame at the head of the buffer, and

THS = a configured buffer threshold such that the difference between THS and the
shapers buffer size, CBS*, is large enough to hold a maximum sized frame.

Example shaping algorithms are presented below. The algorithm in Figure 28 is run every t
seconds where t is the period between updating the token bucket values C(t) and E(t), i.e., C(t)
= C(t) + CIRt and E(t) = E(t) + EIRt. Service Frames sent by the CE using this algorithm
should always have an Ingress Bandwidth Profile compliance of Green.

while((L <= C(t)) && (B(t) > 0))


{
C(t) = C(t) L;
transmit the frame at the head of the buffer; //Should be declared green
}

Figure 28 Periodic Algorithm

The algorithm of Figure 29 is run every time a new frame is given to the shaper to process. This
algorithm will send Service Frames with an Ingress Bandwidth Profile compliance of Yellow if
necessary to try to make room in the buffer for the new frame.

MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 56
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.
Ethernet Services Attributes Phase 2

if(B(t) == 0) // If buffer is empty


{
if(length of new frame <= C(t))
{
C(t) = C(t) length of new frame;
transmit new frame; // Should be declared green
}
else
{
place new frame in buffer;
}
}
else
{
while(L <= C(t))
{
C(t) = C(t) L;
transmit the frame at the head of the buffer; //Should be declared green
}
if(B(t) <= THS)
{
place new frame in buffer;
}
else
{
while((L <= E(t) && (B(t) > THS))
{
E(t) = E(t) L;
transmit the frame at the head of the buffer; //Should be declared yellow
}
if(B(t) <= THS)
{
place new frame in buffer;
}
else
{
discard new frame;
}
}
}

Figure 29 New Frame Algorithm

Shaping can also be used within the MEN to implement a low loss but higher delay SLS and/or
to smooth traffic for more efficient use of network buffers.

10.4 Examples of Availability Metrics for Multipoint EVCs

The performance metric definitions for Multipoint EVCs provide a great deal of flexibility. This
section provides examples on how the subset of UNIs in the EVC can be used to define UNI-
oriented metrics (Section 10.4.1) and EVC-oriented metrics (Section 10.4.2). The Availability
Performance metric is used for these examples.

Both examples use the Multipoint EVC depicted in Figure 30. There are Classes of Service, 1
and 2 on the EVC. The important traffic paths for each CoS have been agreed to by Subscriber
and the Service Provider as shown in the figure.

MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 57
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.
Ethernet Services Attributes Phase 2

UNI A UNI C UNI E

Important paths for CoS 1

Important paths for CoS 2

Multipoint EVC

UNI B UNI D

Figure 30 Multipoint EVC Example

10.4.1 UNI-oriented Availability Example

In this case, an Availability Performance metric is defined for each UNI for each Class of
Service. The metric is based on the ability to communicate between the UNI in question and the
other UNIs identified by the important traffic flows. Define the following subsets of UNI pairs:

S A,1 = { A, B , A, C , A, D , A, E }
S B ,1 = { B, A , B, C , B, D , B, E }
SC ,1 = { C , A , C , B }
S D ,1 = { D, A , D, B }
S E ,1 = { E , A , E , B }
S A, 2 = { A, C , A, E }
SC , 2 = { C , A , C , E }
S E ,2 = { E, C , E, A }

For this example, assume that T, t , Cu , Ca , and n, are used for all availability definitions.
Then using the definition in Section 6.9.8, AT , S A ,1 can be viewed as the availability of UNI A for
Class of Service 1 and this reflects the availability of the important point to point paths that UNI
A is a part of. Similarly, AT , SC , 2 can be viewed as the availability of UNI C for Class of Service 2.
Thus, the availability for each UNI for each Class of Service can be defined by selecting the
appropriate subset of UNI pairs.

MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 58
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.
Ethernet Services Attributes Phase 2

10.4.2 EVC-oriented Availability Example

In this case an Availability Performance metric is defined for each Class of Service supported by
the EVC. Define the following subsets of UNI pairs:

S1 = { A, B , A, C , A, D , A, E , B, C , B, D , B, E }
S 2 = { A, C , A, E , C , E }
For this example, assume that T, t , Cu , Ca , and n, are used for both availability definitions.
Then using the definition in Section 6.9.8, AT ,S1 can be viewed as the availability of Class of
Service 1 on the EVC and AT ,S can be viewed as the availability of Class of Service 2 on the
2

EVC.

MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 59
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.
Technical Specification
MEF 13

User Network Interface (UNI) Type 1


Implementation Agreement

November, 2005

MEF 13 The Metro Ethernet Forum 2005. Any reproduction of this document, or any portion thereof, 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.
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 re-
presentation or warranty, expressed or implied, is made by the MEF concerning the complete-
ness, 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 docu-
ment 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 prod-
uct(s) and/or service(s) related thereto, or if such announcements are made, that such an-
nounced product(s) and/or service(s) embody any or all of the ideas, technologies, or con-
cepts 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 speci-
fications will be voluntary, and no company shall be obliged to implement them by virtue of par-
ticipation in the Metro Ethernet Forum. The MEF is a non-profit international organization acce-
lerating 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 2005. All Rights Reserved.

MEF 13 The Metro Ethernet Forum 2005. Any reproduction of this document, or any portion thereof, 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.
User Network Interface (UNI) Type 1 Implementation Agreement

Table of Contents
1. Abstract ................................................................................................................................ 1

2. Terminology......................................................................................................................... 1

3. Scope..................................................................................................................................... 2
3.1 Purpose .............................................................................................................................. 2
3.2 UNI Modes ........................................................................................................................ 2
3.2.1 Type 1 Manual Configuration .............................................................................................. 2
3.2.2 Type 2 Static Service Discovery .......................................................................................... 2
4. Compliance Levels .............................................................................................................. 2

5. Common Characteristics .................................................................................................... 3


5.1 Physical Medium ............................................................................................................... 3
5.2 Ethernet Frame Format ...................................................................................................... 3
6. Service Specific Characteristics ......................................................................................... 4
6.1 UNI Type 1.1 ..................................................................................................................... 4
6.1.1 CE-VLAN ID .......................................................................................................................... 4
6.1.2 CE-VLAN ID/EVC Map......................................................................................................... 4
6.1.3 Traffic Management ................................................................................................................ 4
6.1.4 L2 Control Processing ............................................................................................................. 5
6.1.5 EVC Type................................................................................................................................ 5
6.1.6 CE-VLAN ID Processing ........................................................................................................ 5
6.1.7 CE-VLAN CoS Preservation .................................................................................................. 5
6.1.8 Service Frame Delivery........................................................................................................... 5
6.2 UNI Type 1.2 ..................................................................................................................... 6
6.2.1 Service Multiplexing ............................................................................................................... 6
6.2.2 CE-VLAN ID .......................................................................................................................... 6
6.2.3 CE-VLAN ID/EVC Map......................................................................................................... 6
6.2.4 Bundling .................................................................................................................................. 6
6.2.5 Traffic Management ................................................................................................................ 6
6.2.6 L2 Control Processing ............................................................................................................. 7
6.2.7 EVC Type................................................................................................................................ 8
6.2.8 CE-VLAN ID Processing ........................................................................................................ 8
6.2.9 CE-VLAN CoS Preservation .................................................................................................. 8
6.2.10 Service Frame Delivery........................................................................................................... 8
7. References ............................................................................................................................ 9

MEF 13 The Metro Ethernet Forum 2005. Any reproduction of this document, or any portion thereof, shall Page i
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.
User Network Interface (UNI) Type 1Implementation Agreement

1. Abstract

This document specifies an implementation agreement for MEF User to Network Interface (UNI)
Type 1. The main objective of this version is to specify the MEF UNI characteristics and opera-
tion in manual configuration mode. This allows existing Ethernet devices (switch, router,
workstation, etc) acting as CEs to be instantly compliant to this IA with no additional software or
hardware upgrades. The main functionality of this version is to allow data-plane Ethernet con-
nectivity between the UNI-C and UNI-N. This document references MEF UNI Requirements
and Framework [4] for all concepts, constructs and terminology. The UNI Type 1 mode pro-
vides bare minimum data-plane connectivity services with no control-plane or management-
plane capabilities..

2. Terminology
Term Definition
The user-priority bits of the IEEE 802.1Q Tag in a tagged Service Frame over
CE-VLAN CoS
UNI.
The identifier derivable from the content of a Service Frame that allows the
CE-VLAN ID
Service Frame to be associated with an EVC at the UNI.
CBS Committed Burst Size
CIR committed Information Rate
Ethernet Virtual Connection. An association of two or more UNIs that limits
EVC
the exchange of frames to UNIs in the Ethernet Virtual Connection
Frame Short for Ethernet frame.
Ingress The direction from the CE into the Service Provider network.
Layer 2 Control
A Service Frame that is used for Layer 2 control, e.g., Spanning Tree Proto-
Protocol Service
col.
Frame
Multicast Service
A Service Frame that has a multicast destination MAC address.
Frame
Multipoint EVC An EVC with two or more UNIs.
EBS Excess Burst Size
EIR Excess Information Rate
Point-to-Point
An EVC with exactly 2 UNIs.
EVC
An Ethernet frame transmitted across the UNI toward the Service Provider or
Service Frame
an Ethernet frame transmitted across the UNI toward the Subscriber.
Service Multip-
A UNI attribute in which the UNI can be in more than one EVC instance.
lexing
Service Provider The organization providing Ethernet Service(s).
Subscriber The organization purchasing and/or using Ethernet Services.
User Network Interface. The physical demarcation point between the respon-
UNI
sibility of the Service Provider and the responsibility of the Subscriber
Unicast Service
A Service Frame that has a unicast destination MAC address.
Frame

MEF 13 The Metro Ethernet Forum 2005. 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.
User Network Interface (UNI) Type 1Implementation Agreement

3. Scope

3.1 Purpose

The purpose of this document is an Implementation Agreement for a manually configured Ether-
net UNI. This document is based on the MEF UNI Framework [4].

3.2 UNI Modes

3.2.1 Type 1 Manual Configuration

The manual configuration mode provides data-plane connectivity services with no control-plane
and management plane capability. The scope of this Implementation Agreement is UNI Type 1.

3.2.2 Type 2 Static Service Discovery

This mode is out of the scope of this implementation agreement

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

MEF 13 The Metro Ethernet Forum 2005. 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.
User Network Interface (UNI) Type 1Implementation Agreement

5. Common Characteristics

5.1 Physical Medium

1. A Type 1 UNI-C MUST support at least one of the following IEEE 802.3 Ethernet
PHYs:
10BASE-T in Full-duplex mode [1].
100BASE-T including 100BASE-TX and 100BASE-FX in Full-duplex mode [1].
1000BASE-X including 1000BASE-SX, 1000BASE-LX, and 1000BASE-T in Full-
duplex mode [1].
10GBASE-SR, 10GBASE-LX4, 10GBASE-LR, 10GBASE-ER, 10GBASE-SW,
10GBASE-LW, and 10GBASE-EW in Full-duplex mode [1].

2. A Type 1 UNI-N MUST support at least one of the following IEEE 802.3 Ethernet
PHYs:
10BASE-T in Full-duplex mode [1].
100BASE-T including 100BASE-TX and 100BASE-FX in Full-duplex mode [1].
1000BASE-X including 1000BASE-SX, 1000BASE-LX, and 1000BASE-T in Full-
duplex mode [1].
10GBASE-SR, 10GBASE-LX4, 10GBASE-LR, 10GBASE-ER, 10GBASE-SW,
10GBASE-LW, and 10GBASE-EW in Full-duplex mode [1].

5.2 Ethernet Frame Format

3. A Type 1 UNI-C MUST support transmission and reception of Untagged Ethernet frames
according to IEEE 802.3-2002 [1]. In addition it MAY support transmission and recep-
tion of Priority-tagged and/or VLAN Tagged service frames in compliance to 802.3-
2002.
4. A Type 1 UNI-N MUST support transmission and reception of Untagged, VLAN-tagged
and Priority-tagged Ethernet frames according to IEEE 802.3-2002 [1].
5. A Type 1 UNI-C MUST support transmission and reception of Ethernet frames that have
a minimum and maximum size as specified in IEEE 802.3-2002 [1].
6. A Type 1 UNI-N MUST support transmission and reception of Ethernet frames that have
a minimum and maximum size as specified in IEEE 802.3-2002 [1].

MEF 13 The Metro Ethernet Forum 2005. 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.
User Network Interface (UNI) Type 1Implementation Agreement

6. Service Specific Characteristics

6.1 UNI Type 1.1

UNI Type 1.1 is a subset of UNI Type 1 that is meant to support non-service multiplexed UNIs,
such as those required to support the EPL service [5].

6.1.1 CE-VLAN ID

7. A Type 1.1 UNI-N MUST be able to accept any CE-VLAN ID received from UNI-C,
meaning that it shouldnt discard any CE-VLAN ID.

6.1.2 CE-VLAN ID/EVC Map

8. A Type 1.1 UNI-N MUST be able to support a single EVC.


9. A Type 1.1 UNI-N MUST be configurable to either map all CE-VLAN IDs to an EVC or
dont map any CE-VLAN ID to any EVC.

Note: This requirement is needed for temporary disconnection of customer service, without tear-
ing down the EVC.

6.1.3 Traffic Management

10. A Type 1.1 UNI-N MUST be able to support per-UNI Ingress BW profiling based on [6].
11. A Type 1.1 UNI-C SHOULD be able to shape its traffic to the contracted BWP in order
to receive the contracted QoS commitments.
12. A Type 1.1 UNI-N MUST be able to support color-blind BW profiling in which
EIR=EBS=0 and CIR and CBS are non-zero.
13. A Type 1.1 UNI-N MUST allow configuration to modify CIR in the following granulari-
ties:
1Mbps steps up to 10Mpbs
5 Mbps steps beyond 10Mbps and up to 100Mbps
50 Mbps steps beyond 100Mpbs and up to 1Gbps
500 Mbps steps beyond 1Gbps
14. A Type 1.1 UNI-N SHOULD allow configuration to modify CIR in the following granu-
larities:
64 Kbps (DS0 rate) steps up to 1.422 Mbps (VC11 rate) or 1.932 Mbps (VC12 rate)
1.422 Mbps (VC11 rate) or 1.932 Mbps (VC12 rate) steps up to 50 Mbps
43.008 Mbps (VC3 rate) steps beyond 50 Mbps and up to 150 Mbps
133.12 Mbps (VC4 rate) steps beyond 150 Mbps
15. A Type 1.1 UNI-N MUST be able to at least support CBS values that are equal to or
greater than the 8xMTU = 8x1522 bytes =12176 bytes
MEF 13 The Metro Ethernet Forum 2005. 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.
User Network Interface (UNI) Type 1Implementation Agreement

6.1.4 L2 Control Processing

16. A Type 1.1 UNI-N MUST be able to pass the following L2 Control Protocols to the
EVC:
Spanning Tree Protocol (STP),
Rapid Spanning Tree Protocol (RSTP),
Multiple Spanning Tree Protocol (MSTP)
All LANs Bridge Management Group Block of Protocol
Generic Attribute Registration Protocol (GARP)

17. A Type 1.1 UNI-N SHOULD be able to pass the following L2 Control Protocols to the
EVC:
Link Aggregation Control Protocol (LACP)
Marker Protocol
Authentication (802.1x)
18. A Type 1.1 UNI-N SHOULD be able to discard 802.3x PAUSE frames

6.1.5 EVC Type

19. A Type 1.1 UNI-N MUST be able to support point-to-point EVCs.

6.1.6 CE-VLAN ID Processing

20. A Type 1.1 UNI-N MUST be able to support CE-VLAN ID preservation.

6.1.7 CE-VLAN CoS Preservation

21. A Type 1.1 UNI-N MUST be able to support CE-VLAN CoS preservation.

6.1.8 Service Frame Delivery

22. A Type 1.1 UNI-N MUST be able to Tunnel Unicast, Multicast and Broadcast service
frames, except 802.3x PAUSE frames unconditionally.

MEF 13 The Metro Ethernet Forum 2005. 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.
User Network Interface (UNI) Type 1Implementation Agreement

6.2 UNI Type 1.2

UNI Type 1.2 is a subset of UNI Type 1 that is meant to support service multiplexed UNIs, such
as those required to support the EVPL service [5].

6.2.1 Service Multiplexing

23. A Type 1.2 UNI-N MUST be able to support Service Multiplexing as defined in
[MEF10].
24. A Type 1.2 UNI-N SHOULD at least be able to support a minimum number of EVCs as
per following table.

Link Speed 10/100 M bits/s 1 G bit/s 10 G bit/s


Minimum number of 8 64 512
EVCs

6.2.2 CE-VLAN ID

25. A Type 1.2 UNI-N SHOULD be able to support at least a minimum number of CE-
VLAN IDs as per following table, which SHOULD be configurable in the range of 1-
4095 [MEF10].

Link Speed 10/100 M bits/s 1 G bit/s 10 G bit/s


Minimum number of 8 64 512
CE-VLANs

6.2.3 CE-VLAN ID/EVC Map

26. A Type 1.2 UNI-N MUST have a configurable CE-VLAN/EVC mapping table.
27. A Type 1.2 UNI-N MUST be able to drop the frames if a match in the CE-VLAN/EVC
map table cannot be found.

6.2.4 Bundling

28. A Type 1.2 UNI-N MUST be able to support All-to-one bundling.

6.2.5 Traffic Management

29. A Type 1.2 UNI-N MUST be able to support per-UNI Ingress BW profiling [6].
30. A Type 1.2 UNI-N MUST be able support Per-EVC BW profiling [6].

MEF 13 The Metro Ethernet Forum 2005. 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.
User Network Interface (UNI) Type 1Implementation Agreement

31. A Type 1.2 UNI-N SHOULD be able to support Per-CoS BW profiling [6].

Note1: Multiple models of BW profile may exist at a UNI Type 1.2. However, a UNI Type 1.2
is not required to apply more than one BW profile to each service frame.
Note 2: Best Effort service is also considered to need CIR and CBS, in which CIR=CBS=0.
32. A Type 1.2 UNI-C SHOULD be able to shape its traffic to the contracted BWP in order
to received the contracted QoS commitments
33. A Type 1.2 UNI-N MUST be able to support color-blind BW profiling to enforce CIR,
CBS, EIR and EBS.
34. A Type 1.2 UNI-N MUST allow configuration to modify CIR and EIR in the following
granularities:
1Mbps steps up to 10Mpbs
5 Mbps steps beyond 10Mbps and up to 100Mbps
50 Mbps steps beyond 100Mpbs and up to 1Gbps
500 Mbps steps beyond 1Gbps
35. A Type 1.2 UNI-N SHOULD allow configuration to modify CIR and EIR in the follow-
ing granularities:
64 Kbps (DS0 rate) steps up to 1.422 Mbps (VC11 rate) or 1.932 Mbps (VC12 rate)
1.422 Mbps (VC11 rate) or 1.932 Mbps (VC12 rate) steps up to 50 Mbps
43.008 Mbps (VC3 rate) steps beyond 50 Mbps and up to 150 Mbps
133.12 Mbps (VC4 rate) steps beyond 150 Mbps
36. A Type 1.2 UNI-N MUST be able to at least support CBS and EBS values that are equal
or greater than 8xMTU = 8x1522 bytes = 12176 bytes.

6.2.6 L2 Control Processing

37. A Type 1.2 UNI-N SHOULD be able to discard the following L2 Control Protocols:
Spanning Tree Protocol (STP),
Rapid Spanning Tree Protocol (RSTP),
Multiple Spanning Tree Protocol (MSTP)
All LANs Bridge Management Group Block of Protocol
Generic Attribute Registration Protocol (GARP)
Link Aggregation Control Protocol (LACP)
Marker Protocol
Authentication (802.1x)
802.3x (PAUSE) frames
38. A type 1.2 UNI-N SHOULD not generate 802.3x (PAUSE) frames.
39. A Type 1.2 UNI-N SHOULD be configurable to peer the following L2 Control Protocols
Link Aggregation Control Protocol (LACP)
Marker Protocol
Authentication (802.1x)

MEF 13 The Metro Ethernet Forum 2005. 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.
User Network Interface (UNI) Type 1Implementation Agreement

6.2.7 EVC Type

40. A Type 1.2 UNI-N MUST be able to support Point-to-point and Multipoint EVCs con-
currently.

6.2.8 CE-VLAN ID Processing

41. A Type 1.2 UNI-N MUST be able to support CE-VLAN ID preservation.

6.2.9 CE-VLAN CoS Preservation

42. A Type 1.2 UNI-N MUST be able to support CE-VLAN CoS preservation.

6.2.10 Service Frame Delivery

43. A Type 1.2 UNI-N MUST be able to Tunnel Multicast and Broadcast service frames that
are not listed in section 6.2.6 unconditionally.
44. A Type 1.2 UNI-N MUST be able to Tunnel all other Unicast service frames uncondi-
tionally

MEF 13 The Metro Ethernet Forum 2005. 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.
User Network Interface (UNI) Type 1Implementation Agreement

7. References
Reference Reference Details
[1] IEEE 802.3 IEEE P 802.3 2002, Information technology Telecommunications
and information exchange between systems Local and metropolitan
area networks Specific requirements Part 3: Carrier sense multiple
access with collision detection (CSMA/CD) access method and physical
layer specifications, 8 March 2002. (Normative)
[2] IEEE 802.3ae IEEE 802.3ae-2002Information Technology - Local & Metropolitan
Area Networks - Part 3: Carrier Sense Multiple Access with Collision
Detection (CSMA/CD) Access Method and Physical Layer Specifica-
tions - Media Access Control Parameters, Physical Layers and Manage-
ment Parameters for 10 Gb/s Operation
[3]IEEE 802.1Q IEEE 802.1Q, 2003 Edition, IEEE Standards for Local and metropolitan
area networksVirtual Bridged Local Area Networks
[4]UNI-REQ-FRMK Metro Ethernet Forum, MEF 11, User Network Interface (UNI) Re-
quirements and Framework, November 2004
[5] MEF 6 Metro Ethernet Forum MEF 6, Ethernet Service Definition, June 2004.
[6] MEF 10 Metro Ethernet Forum MEF 10, Ethernet Services Attributes Phase 1,
November 2004.

MEF 13 The Metro Ethernet Forum 2005. 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.
Technical Specification
MEF 26.1

External Network Network Interface (ENNI)


Phase 2

January 2012

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, 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.
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 rep-
resentation 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 docu-
ment 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, tech-
nologies, 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 speci-
fications will be voluntary, and no company shall be obliged to implement them by virtue of par-
ticipation in the Metro Ethernet Forum. The MEF is a non-profit international organization ac-
celerating industry cooperation on Metro Ethernet technology. The MEF does not, expressly or
otherwise, endorse or promote any specific products or services.
(C) 2012. The Metro Ethernet Forum. All Rights Reserved.

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, 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.
External Network Network Interface (ENNI) Phase 2

Table of Contents
1 Abstract ................................................................................................................................... 1
2 Terminology............................................................................................................................ 1
3 Scope....................................................................................................................................... 3
4 Key Concepts .......................................................................................................................... 4
4.1 Motivation and Service Model........................................................................................ 4
4.2 Design Goals................................................................................................................... 6
4.3 ENNI Reference Model .................................................................................................. 6
4.4 ENNI Frame.................................................................................................................... 7
4.5 Operator Virtual Connection........................................................................................... 7
4.6 Relationship between OVCs and EVC ........................................................................... 8
5 Compliance Levels.................................................................................................................. 9
6 Requirements for the ENNI .................................................................................................... 9
7 Operator Services Attributes................................................................................................. 10
7.1 ENNI Service Attributes ............................................................................................... 11
7.1.1 Operator ENNI Identifier...................................................................................... 12
7.1.2 Physical Layer....................................................................................................... 12
7.1.3 Frame Format........................................................................................................ 13
7.1.4 Number of Links ................................................................................................... 13
7.1.5 ENNI Resiliency Mechanisms.............................................................................. 14
7.1.6 ENNI Maximum Transmission Unit Size............................................................. 14
7.1.7 End Point Map ...................................................................................................... 15
7.1.7.1 Basic End Point Map ........................................................................................ 15
7.1.7.2 End Point Map Bundling .................................................................................. 17
7.1.8 Maximum Number of OVCs ................................................................................ 18
7.1.9 Maximum Number of OVC End Points per OVC ................................................ 18
7.2 OVC Service Attributes ................................................................................................ 18
7.2.1 OVC End Points.................................................................................................... 18
7.2.2 OVC End Point Roles and Forwarding Constraints ............................................. 18
7.2.3 Hairpin Switching ................................................................................................. 20
7.2.4 OVC Service Attributes ........................................................................................ 20
7.2.5 OVC Identifier ...................................................................................................... 22
7.2.6 OVC Type............................................................................................................. 22
7.2.7 OVC End Point List .............................................................................................. 23
7.2.8 Maximum Number of UNI OVC End Points ....................................................... 23
7.2.9 Maximum Number of ENNI OVC End Points ..................................................... 23
7.2.10 OVC Maximum Transmission Unit Size.............................................................. 23
7.2.11 CE-VLAN ID Preservation................................................................................... 24
7.2.12 CE-VLAN CoS Preservation ................................................................................ 27
7.2.13 S-VLAN ID Preservation...................................................................................... 27
7.2.14 S-VLAN CoS Preservation ................................................................................... 28
7.2.15 Color Forwarding.................................................................................................. 28
7.2.16 Service Level Specification .................................................................................. 29
7.2.16.1 One-way Frame Delay Performance for an OVC......................................... 31
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page i
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.
External Network Network Interface (ENNI) Phase 2

7.2.16.2 Inter-Frame Delay Variation Performance for an OVC ............................... 35


7.2.16.3 One-way Frame Loss Ratio Performance for an OVC ................................. 38
7.2.16.4 One-way Availability Performance for an OVC .......................................... 40
7.2.16.5 One-way Resiliency Performance for an OVC............................................. 45
7.2.17 Unicast Frame Delivery ........................................................................................ 49
7.2.18 Multicast Frame Delivery ..................................................................................... 49
7.2.19 Broadcast Frame Delivery .................................................................................... 50
7.2.20 Layer 2 Control Protocol Tunneling ..................................................................... 50
7.3 OVC End Point per ENNI Service Attributes............................................................... 51
7.3.1 OVC End Point Identifier ..................................................................................... 52
7.3.2 Trunk Identifiers ................................................................................................... 53
7.3.3 Class of Service Identifiers ................................................................................... 53
7.3.3.1 Class of Service Identifiers for Egress ENNI Frames ...................................... 54
7.3.4 Ingress Bandwidth Profile per OVC End Point .................................................... 55
7.3.5 Egress Bandwidth Profile per OVC End Point ..................................................... 55
7.3.6 Ingress Bandwidth Profile per Class of Service Identifier.................................... 55
7.3.7 Egress Bandwidth Profile per Class of Service Identifier .................................... 56
7.4 UNI Attributes .............................................................................................................. 56
7.5 OVC per UNI Service Attributes.................................................................................. 56
7.5.1 UNI OVC Identifier .............................................................................................. 57
7.5.2 OVC End Point Map at the UNI ........................................................................... 57
7.5.3 Class of Service Identifiers ................................................................................... 58
7.5.3.1 Class of Service Identifier Based on OVC End Point....................................... 58
7.5.3.2 Class of Service Identifier Based on Priority Code Point Field........................ 58
7.5.3.3 Class of Service Identifier Based on DSCP...................................................... 59
7.5.4 Ingress Bandwidth Profile per OVC End Point at a UNI ..................................... 59
7.5.5 Ingress Bandwidth Profile per Class of Service Identifier at a UNI..................... 60
7.5.6 Egress Bandwidth Profile per OVC End Point at a UNI ...................................... 60
7.5.7 Egress Bandwidth Profile per Class of Service Identifier at a UNI...................... 60
7.6 Bandwidth Profile at the ENNI..................................................................................... 61
7.6.1 Bandwidth Profile Parameters and Algorithm...................................................... 61
7.6.2 Ingress Bandwidth Profiles Service Attributes ..................................................... 63
7.6.2.1 Simultaneous Application of the Ingress Bandwidth Profile Application Models
63
7.6.2.2 ENNI Frame Disposition .................................................................................. 63
7.6.3 Egress Bandwidth Profiles Service Attributes ...................................................... 64
7.6.3.1 Simultaneous Application of the Egress Bandwidth Profile Application Models
65
8 Link OAM Function Support for the ENNI.......................................................................... 65
9 Maximum Transmission Unit Size ....................................................................................... 65
10 Appendix A: Examples ..................................................................................................... 66
10.1 Notation and Conventions............................................................................................. 66
10.2 Example 1: Ethernet Virtual Private Lines to a Hub Location ..................................... 67
10.3 Example 2: Ethernet Private LAN ................................................................................ 68
10.4 Example 3: Hairpin Switching...................................................................................... 70
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page ii
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.
External Network Network Interface (ENNI) Phase 2

10.5 Example 4: Data Loop at an ENNI with Hairpin Switching ........................................ 71


10.6 Example 5: Ethernet Private LAN with Hairpin Switching.......................................... 71
10.7 Example 6: End Point Map Bundling ........................................................................... 72
10.8 Example 7: CoS Identifiers at the ENNI....................................................................... 73
11 Appendix B: Rooted-Multipoint Examples ...................................................................... 75
11.1 Example Using Trunk OVC End Points ....................................................................... 75
11.2 Example Using a Rooted-Multipoint OVC in One Operator MEN.............................. 76
11.3 Example with All Root UNIs in One Operator MEN................................................... 77
11.4 Example Using a Bundled OVC ................................................................................... 78
11.5 Example Using Hairpin Switching with Trunk OVC End Points................................. 79
12 References......................................................................................................................... 80

List of Figures
Figure 1 Example of Multiple MEN Operators Supporting Ethernet Services ........................... 5
Figure 2 MEF external reference model ...................................................................................... 7
Figure 3 Examples of OVCs ........................................................................................................ 8
Figure 4 Example Relationship of OVCs to EVCs...................................................................... 9
Figure 5 Representation of ENNI-Ni ......................................................................................... 10
Figure 6 ENNI Ethernet Services Model ................................................................................... 11
Figure 7 End Point Map Example.............................................................................................. 15
Figure 8 Example of the two End Point Maps for a Given ENNI ............................................. 16
Figure 9 Inter-Frame Delay Variation Definition...................................................................... 36
Figure 10 Flowchart Definition of A i , j (t k ) ........................................................................... 42
Figure 11 Example of the Determination of A i , j (t k ) ............................................................ 43
Figure 12 Example of the Impact of a Maintenance Interval .................................................... 44
Figure 13 Hierarchy of Time Showing the Resiliency Attributes ............................................. 46
Figure 14 Determining and Counting Consecutive High Loss Intervals over T........................ 47
Figure 15 Example of Counting High Loss Intervals and Consecutive High Loss Intervals .... 48
Figure 16 Ingress Bandwidth Profile per OVC End Point......................................................... 55
Figure 17 The Bandwidth Profile Algorithm............................................................................. 62
Figure 18 Key to the Icons Used in the Examples..................................................................... 67
Figure 19 EVCs to the Hub Location ........................................................................................ 67
Figure 20 Details of the Operator Services Attributes for Example 1 ....................................... 68
Figure 21 EPLAN Connecting Four UNIs................................................................................. 69
Figure 22 Details of the Operator Services Attributes for Example 2 ....................................... 69
Figure 23 Example of Hairpin Switching .................................................................................. 71
Figure 24 Example of a Data Loop with Hairpin Switching ..................................................... 71
Figure 25 Details of the Operator Services Attributes for Example 3 ....................................... 72
Figure 26 Example of Using End Point Map Bundling............................................................. 73
Figure 27 CoS Identifiers for MEF 23.1 Conforming Operator MENs..................................... 74
Figure 28 CoS Identifiers for Square and Paper in Scenario Two............................................. 75
Figure 29 Subscriber View of the Rooted-Multipoint EVC ...................................................... 76
Figure 30 Rooted-Multipoint EVC using Trunk OVC End Points............................................ 76
Figure 31 Example End Point Maps .......................................................................................... 76
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page iii
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.
External Network Network Interface (ENNI) Phase 2

Figure 32 Rooted-Multipoint EVC with a Rooted-Multipoint OVC in One Operator MEN.... 77


Figure 33 Subscriber View of the Rooted-Multipoint EVC with all Root UNIs in one Operator
MEN...................................................................................................................................... 77
Figure 34 Rooted-Multipoint EVC with all Root UNIs in one Operator MEN......................... 78
Figure 35 Subscriber View of the Rooted-Multipoint EVC ...................................................... 78
Figure 36 Rooted-Multipoint EVC using a Bundled OVC........................................................ 79
Figure 37 Subscriber View of the Rooted-Multipoint EVC ...................................................... 79
Figure 38 Hairpin Switching with Trunk OVC End Points....................................................... 80

List of Tables
Table 1 Acronyms and definitions............................................................................................... 3
Table 2 ENNI Service Attributes............................................................................................... 12
Table 3 ENNI Frame Formats.................................................................................................... 13
Table 4 Allowed Connectivity Between OVC End Point Roles................................................ 20
Table 5 OVC Service Attributes ................................................................................................ 22
Table 6 OVC CE-VLAN ID Preservation when All CE-VLAN IDs Map to the OVC at all of
the UNIs Associated by the OVC ......................................................................................... 25
Table 7 OVC CE-VLAN ID Preservation when not All CE-VLAN IDs Map to the OVC at all
of the UNIs Associated by the OVC..................................................................................... 26
Table 8 OVC CE-VLAN ID Preservation when none of the OVC End Points are at UNIs ..... 26
Table 9 OVC CE-VLAN CoS Preservation............................................................................... 27
Table 10 One-way Frame Delay Performance Parameters........................................................ 34
Table 11 Inter-Frame Delay Variation Parameters .................................................................... 38
Table 12 One-way Frame Loss Ratio Performance Parameters ................................................ 39
Table 13 Availability Performance Parameters for an OVC ..................................................... 45
Table 14 Resiliency Performance Parameters for an OVC ....................................................... 48
Table 15 MAC Addresses that Identify a Layer 2 Control Protocol ENNI Frame.................... 50
Table 16 Format Relationships for Tunneled L2CP Service and ENNI Frames ....................... 51
Table 17 OVC End Point per ENNI Service Attributes ............................................................ 52
Table 18 OVC per UNI Service Attributes................................................................................ 57
Table 19 ENNI Frame Disposition for Each Egress External Interface .................................... 64
Table 20 Abbreviations Used in the Examples.......................................................................... 66
Table 21 MEF 23.1 CoS Identifiers........................................................................................... 74
Table 22 CoS Identifiers for Scenario Two ............................................................................... 74

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page iv
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.
External Network Network Interface (ENNI) Phase 2

1 Abstract
The Metro Ethernet Network Architecture Framework specifies a reference point that is the in-
terface between two Metro Ethernet Networks (MENs), where each Operator MEN is under the
control of a distinct administrative authority. This reference point is termed the External Network
Network Interface or ENNI.1 The ENNI is intended to support the extension of Ethernet services
across multiple Operator MENs. This Technical Specification specifies:

The requirements at the ENNI reference point as well as the interface functional-
ity in sufficient detail to ensure interoperability between two Operator MENs in-
cluding Link OAM.

The connectivity attributes UNI to UNI, UNI to ENNI, and ENNI to ENNI such
that multiple Operator MENs can be interconnected and the Ethernet services and
attributes in MEF 6.1 [9] and MEF 10.2 [5] can be realized.

2 Terminology

Term Definition Source


Bundled A non-Rooted Multipoint OVC that associates an OVC End This docu-
OVC Point that has more than one S-VLAN ID value that maps to it. ment
CE Customer Edge MEF 10.2[5]
CHLI Consecutive High Loss Interval This docu-
ment
Color For- An OVC attribute defining the relationship between the Color of This docu-
warding an egress ENNI Frame and the Color of the corresponding in- ment
gress ENNI Frame or Service Frame
Consecutive A sequence of small time intervals, each with a high frame loss This docu-
High Loss ratio ment
Interval
C-Tag Subscriber VLAN Tag IEEE Std
802.1ad[4]
DSCP Diff-Serve Code Point RFC
2474[14]
End Point A mapping of specified S-Tag VLAN ID values to specified This docu-
Map OVC End Point Identifiers ment
End Point When multiple S-VLAN ID values map to a single OVC End This docu-
Map Bun- Point in the End Point Map, and the OVC associating that OVC ment
dling End Point is not a Rooted-Multipoint OVC
End Point A parameter in the End Point Map (In this specification the End This docu-
Type Point Type is always OVC End Point.) ment
ENNI A reference point representing the boundary between two Opera- MEF 4[1]
tor MENs that are operated as separate administrative domains
1
MEF 4 [1] hyphenates the acronym but this document does not.
MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

Term Definition Source


ENNI Frame The first bit of the Destination Address to the last bit of the This docu-
Frame Check Sequence of the Ethernet Frame transmitted across ment
the ENNI
ENNI MTU MTU of an ENNI frame at the ENNI This docu-
ment
ENNI-Ni The functional element administered by the Operator of the ith This docu-
Operator MEN that supports the protocols and procedures re- ment
quired in this document
EVC An association of two or more UNIs MEF 10.2[5]
E-WAN An MEF defined ETH services aware network that provides con- MEF 4[1]
nectivity between two or more MENs via ENNIs
External In- Either a UNI or an ENNI2 MEF 4[1]
terface
High Loss A small time interval with a high frame loss ratio This docu-
Interval ment
HLI High Loss Interval This docu-
ment
L2CP Tun- The process by which a frame containing a Layer 2 Control Pro- This docu-
neling tocol is transferred between External Interfaces. ment
Leaf OVC An OVC End Point that has the role of Leaf This docu-
End Point ment
MEN A Metro Ethernet Network comprising a single administrative MEF 10.2[5]
domain
MTU Maximum Transmission Unit This docu-
ment
Multipoint- An OVC that can associate two or more Root OVC End Points This docu-
to-Multipoint ment
OVC
Network Op- The Administrative Entity of a MEN MEF 4[1]
erator
Operator Vir- An association of OVC End Points This docu-
tual Connec- ment
tion
OVC Operator Virtual Connection This docu-
ment
OVC End An association of an OVC with a specific External Interface i.e., This docu-
Point UNI, ENNI ment
OVC End A property of an OVC End Point that determines the forwarding This docu-
Point Role behavior between it and other OVC End Points that are associ- ment
ated with the OVC End Point by an OVC

2
MEF 4 considers several types of External Interfaces. This document is limited to consideration of the UNI and
ENNI.
MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

Term Definition Source


OVC Identi- string that is unique among all OVCs in the Operator MEN This docu-
fier ment
Point-to- An OVC that associates exactly two Root OVC End Points This docu-
Point OVC ment
Resiliency The number of High Loss Intervals and Consecutive High Loss This docu-
Performance Intervals in a time interval T ment
Root OVC An OVC End Point that has the role of Root This docu-
End Point ment
Rooted- An OVC that can associate at least one Leaf or Trunk OVC End This docu-
Multipoint Point ment
OVC
Service An Ethernet frame transmitted across the UNI toward the Ser- MEF 10.2[5]
Frame vice Provider or an Ethernet frame transmitted across the UNI
toward the Subscriber
Service Pro- The organization responsible for the UNI to UNI Ethernet ser- MEF 10.2[5]
vider vice
S-Tag Service VLAN Tag. IEEE Std
802.1ad[4]
Subscriber The organization purchasing and/or using Ethernet Services MEF 10.2[5]
S-VLAN ID The 12 bit VLAN ID field in the S-Tag of an ENNI Frame This docu-
ment
Tag An optional field in a frame header. In this document it is the 4- IEEE Std
byte field that, when present in an Ethernet frame, appears im- 802.1ad[4]
mediately after the Source Address, or another tag in an Ethernet
frame header and which consists of the 2-byte Tag Protocol
Identification Field (TPID) which indicates S-Tag or C-Tag, and
the 2-byte Tag Control Information field (TCI) which contains
the 3-bit Priority Code Point, and the 12-bit VLAN ID field
Trunk OVC An OVC End Point that has the role of Trunk This docu-
End Point ment
UNI The physical demarcation point between the responsibility of the MEF 10.2[5]
Service Provider and the responsibility of the Subscriber
Table 1 Acronyms and definitions

Note that throughout this specification, UNI means a demarcation point and ENNI means a de-
marcation point. Functionality associated with an interface at the ENNI is denoted by ENNI-Ni.

3 Scope
This document is a revision of MEF 26 [16]. MEF 26 was the first phase of specifications for
interconnecting Operator MENs in order to support MEF Ethernet Services. MEF 26 includes:

Support for Point-to-Point and Multipoint-to-Multipoint EVCs spanning an arbi-


trary number of Operator MENs and ENNIs.
MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

Ethernet frames at the ENNI with formats according to the Provider Bridges
specification IEEE Std 802.1ad [4].

Gigabit Ethernet or 10-Gigabit physical links according to IEEE Std 802.3 [3].

Color aware Bandwidth Profiles at the ENNI.

Hairpin switching, where ENNI Frames associated with an EVC may be sent back
across an ENNI from which they were received by the Operator.

Link protection based on IEEE Std 802.3-2005 Clause 43, Link Aggregation [3].

Link OAM based on IEEE Std 802.3 [3].

This document represents the second phase. It consolidates MEF 26.0.1 [17], MEF 26.0.2 [18],
and MEF 26.0.3 [19]. In addition it introduces specifications for the support of Rooted-
Multipoint EVCs as defined in MEF 10.2 [5]. As such it adds the following to MEF 26:

The definition and requirements for tunneling frames containing a Layer 2 Con-
trol Protocol on an Operator Virtual Connection.

Service Level Specification definitions and related requirements.

Support for Rooted Multipoint EVCs spanning an arbitrary number of Operator


MENs.

This document supersedes MEF 26.

4 Key Concepts

4.1 Motivation and Service Model


It is likely that a potential Subscriber for Ethernet Services will have locations that are not all
served by a single MEN Operator. Put another way, in order for such a Subscriber to obtain ser-
vices, multiple MEN Operators will need to be used to support all of the Subscribers User Net-
work Interfaces (UNIs). A further potential complication is that the MEN Operators supporting
the UNIs may not all interconnect with each other necessitating the use of transit MEN Opera-
tors. Figure 1 shows an example where there are four Subscriber UNIs supported by three MEN
Operators where Operator A does not directly connect with Operator C necessitating the use of
Operator D as an intermediary. The goal of this Technical Specification is to enable configura-
tions like that of Figure 1 to support the service attributes defined in MEF 10.2 [5] and service
definitions in MEF 6.1 [9].

MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

UNI 2
ENNI
UNI 1
Operator B UNI 3
Operator A

ENNI
ENNI Operator D

Operator C

UNI 4

Figure 1 Example of Multiple MEN Operators Supporting Ethernet Services

This document uses the following Service Model. For a given EVC, the Subscriber contracts
with a Service Provider to be responsible for delivering Ethernet Services among the UNIs in the
EVC. The Service Provider, in turn, selects and contracts with various MEN Operators to deliver
the UNI-to-UNI services. It is the responsibility of the Service Provider to ensure that the appro-
priate service and interface attribute values from each Operator are such that the UNI to UNI ser-
vice features purchased by the Subscriber can be delivered. There is no constraint on the type of
organization that can act as the Service Provider. Examples include:

One of the Operators involved in instantiating the Services, e.g., Operator D in


Figure 1

A third party such as a systems integrator

An enterprise IT department (acting as both Service Provider and Subscriber)

Note that the role of an organization can be different for different EVC instances. For example,
an organization can act as an Operator for one EVC and as Service Provider and an Operator for
another EVC.

There are two types of technical requirements needed to support this Service Model and covered
in this Technical Specification:

Interconnection Interface: These requirements detail the method of interconnection between


two Operator MENs including the protocols that support the exchange of the information needed
to support the UNI to UNI Ethernet Services. This interface is called the External Network Net-
work Interface (ENNI). The Protocol Data Units exchanged at the ENNI are called ENNI
Frames. In this Technical Specification these Protocol Data Units are Ethernet Frames as speci-
fied in IEEE Std 802.1ad [4].

Operator Services Attributes: These requirements detail the connectivity attributes that are
supported by an Operator MEN. Such attributes can exist between UNIs as described in MEF
MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

10.2 (Operator A in Figure 1), between ENNIs (Operators A and D in Figure 1), and between a
UNI and an ENNI (Operators A, B, and C in Figure 1). These attributes can be thought of as the
menu from which the Service Provider purchases, from each Operator, what is needed to instan-
tiate the UNI to UNI services purchased by the Subscriber.

It is highly desirable that the UNI to UNI service observed by the Subscriber, when multiple Op-
erator MENs are involved, be indistinguishable from the services that are obtained via a single
Operator MEN. However, practical considerations might prevent this.

MEF 10.2 specifies multiple UNI to UNI service attributes, e.g., EVC type, service multiplexing.
The Operator Service Attributes detailed in this document are intended to support most of these
attributes (see Section 3). Furthermore it is desirable that a given instance of an ENNI simultane-
ously supports all of the Operator Service Attributes but this capability is not mandated.

4.2 Design Goals


This specification is driven by two main goals:

Rapid deployment: In order to meet Subscriber demand for interconnection of sites served by
more than one Operator MEN, it is important that these requirements be amenable to rapid de-
velopment and deployment. In practical terms, this means restricting the specification to existing
Ethernet technology to the extent possible. It is desirable that the ENNI and Operator Service
Attributes become available as quickly as possible to satisfy the overall market for Metro
Ethernet Services, both on the demand and supply sides. Note that this does not preclude the sub-
sequent development of extensions to this specification to support, for example, additional
physical layers and protocol encapsulations, as well as automated provisioning and management
functionality.

Minimization of global knowledge: The Service Provider has global knowledge of the sites as-
sociated with a particular service, what services have been subscribed to, etc. Coordination will
have to occur with all of the MEN Operators involved. However, there is considerable motiva-
tion to limit the information that a particular Operator MEN requires to that needed to deploy
services within that Operator MEN, and to information amenable to bilateral agreement at each
ENNI. Partitioning the required information in this manner will greatly expedite the process of
deploying services via multiple Operator MENs.

4.3 ENNI Reference Model


Formally, the Metro Ethernet Network Architecture Framework [1] specifies a reference point
that is the interface between two Metro Ethernet Networks (MENs), where each MEN is under
the control of a distinct administrative authority. This reference point is termed the External
Network Network Interface or ENNI. The MEF external reference point model is displayed in
Figure 2 which is derived from Figure 3 in [1]. An Ethernet-aware Wide Area Network (E-
WAN) is functionally equivalent to a MEN but is given a distinct name to suggest that an E-
WAN may have a larger geographical extent than a typical MEN. In this specification, MEN in-
cludes E-WAN.
MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

Public Service Networks


(Internet, PPP, FR, ATM)
External NNIs
Service Interworking NNI

UNI Metro Ethernet Network Metro Ethernet Network


Subscriber
Admin Domain X Admin Domain Y

Network Interworking NNI


Ethernet-aware Wide
External Transport Area Network (E-WAN)
Networks Admin Domain Z

Network Interworking NNI External NNI

Metro Ethernet Network


Metro Ethernet Network Admin Domain W
Admin Domain X

Figure 2 MEF external reference model

4.4 ENNI Frame


Two Operator MENs exchange ENNI Frames across the ENNI. An ENNI Frame is an Ethernet
[3] frame transmitted from an Operator MEN, across the ENNI toward the other Operator MEN.
When an ENNI Frame is transmitted by an Operator MEN, from the perspective of this Operator
MEN, it is called an egress ENNI Frame. When the ENNI Frame is received by an Operator
MEN, from the perspective of this MEN, it is called an ingress ENNI Frame. The ENNI Frame
consists of the first bit of the Destination MAC Address through the last bit of the Frame Check
Sequence. The protocol, as seen by the network elements operating at the ENNI, complies to the
standard Ethernet [3] frame with the exception that may have a length greater than that specified
in [3] (see Section 7.1.6). There are no assumptions about the details of the Operator Metro
Ethernet Network. It could consist of a single switch or an agglomeration of networks based on
many different technologies.

4.5 Operator Virtual Connection


An Operator Virtual Connection (OVC) is the building block for constructing an EVC spanning
multiple Operator MENs.

An OVC can informally be thought of as an association of External Interfaces within the same
Operator MEN. This association constrains the delivery of frames in the sense that an egress
Service Frame or ENNI Frame mapped to a given OVC can only be the result of an ingress Ser-
vice Frame or ENNI Frame mapped to the given OVC.

In the case of an ENNI, an egress ENNI Frame with identical MAC and payload information can
result from an ingress ENNI Frame at the same interface. (This behavior is not allowed at a UNI
as specified in MEF 10.2 [5].) To describe this behavior, the OVC End Point is used which al-
lows multiple, mutually exclusive ways that an ENNI Frame can be mapped to a single OVC at
MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

an ENNI. Section 7.2 defines the OVC as an association of OVC End Points. In turn each OVC
End Point is associated with either a UNI or an ENNI. For the scope of this document, at least
one OVC End Point associated by an OVC is at an ENNI.

Figure 3 shows an example of two OVCs. One OVC connects UNI A, UNI B, and the ENNI.
The other OVC connects UNI A and the ENNI but allows what is called Hairpin Switching (see
Section 7.2.3) via OVC Endpoints a and b at the ENNI.
UNI A Operator
d e MEN

a OVC End Point


ENNI
a OVC
b
c

f
UNI B

Figure 3 Examples of OVCs

The formal definition and requirements that apply to OVCs are detailed in Section 7.2.

4.6 Relationship between OVCs and EVC


An Ethernet Virtual Connection (EVC) is an association of two or more UNIs. [5] When an EVC
associates UNIs attached to more than one Operator MEN, the EVC is realized by concatenating
OVCs. Figure 4 illustrates how this is done with an example.

In this example, there is an EVC associating UNI Q and UNI S and it is constructed by concate-
nating OVC A2 in MEN A with OVC B2 in MEN B. The concatenation is achieved by properly
configuring the End Point Map attribute for ENNI AB in MEN A and the End Point Map attrib-
ute for ENNI AB in MEN B. (See Section 7.1.7 for the definitions and requirements for the End
Point Map.) These map attributes are configured such that an ENNI Frame at ENNI AB that is
mapped to OVC End Point x by MEN A is mapped to OVC End Point y by MEN B and vice
versa. An ingress Service Frame at UNI Q that is destined for UNI S will result in an egress
ENNI Frame at ENNI AB mapped to OVC End Point x in MEN A. When this frame is received
by MEN B as an ingress ENNI Frame, it will be mapped to OVC End Point y and then result in
an egress Service Frame at UNI S. The other EVCs in the example can be similarly instantiated
by configuring the End Point Maps as shown in the table. It is the responsibility of the Service
Provider responsible for an EVC to insure that the OVCs are correctly concatenated for the cor-
responding EVC.

MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

Operator Operator Operator


UNI P MEN A UNI R MEN B UNI T MEN C

B3 B1
A1 A3 ENNI AB C1

A2
C4
B4
B2 ENNI BC

UNI Q OVC End UNI S UNI V


Point x OVC End
Point y

EVC UNIs OVCs


1 (red) UNI P, UNI R, UNI T A1, B1, C1
2 (blue) UNI Q, UNI S A2, B2
3 (black) UNI P, UNI R A3, B3
4 (green) UNI S, UNI V B4, C4

Figure 4 Example Relationship of OVCs to EVCs

The example of Figure 4 illustrates one possible configuration. In this example, each Operator
MEN has only one OVC for each EVC that it is supporting. However, it is possible to use multi-
ple OVCs in a single Operator MEN to build an EVC. Section 10.4 contains an example. It is
also possible that a single OVC in an Operator MEN can support more than one EVC. This can
occur when an End Point Map attribute has Bundling as described in Section 7.1.7.

The Operator Service Attributes contained in this document are sufficient to support Point-to-
Point, Multipoint-to-Multipoint, and Rooted-Multipoint EVCs.

5 Compliance Levels
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in RFC 2119 [2].

Items that are REQUIRED (contain the words MUST or MUST NOT) will be labeled as [Rx]
for required. Items that are RECOMMENDED (contain the words SHOULD or SHOULD
NOT) will be labeled as [Dx] for desirable. Items that are OPTIONAL (contain the words MAY
or OPTIONAL) will be labeled as [Ox] for optional.

6 Requirements for the ENNI


The ENNI is defined as a reference point representing the boundary between two Operator
MENs that are operated as separate administrative domains.
Similar to the concept of the UNI-C and UNI-N functional components of the UNI [7], it is use-
ful to identify ENNI-N1 and ENNI-N2 as the separately administered functional components that
support the ENNI between MEN 1 and MEN 2. Figure 5 illustrates this concept. Each ENNI-Ni
is an entity that represents those functions necessary to implement the protocols and procedures
specified in this document.
MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

ENNI-N1 ENNI-N2

Operator MEN 1 Operator MEN 2

ENNI

Figure 5 Representation of ENNI-Ni

An ENNI can be implemented with one or more physical links. However, when there is no pro-
tection mechanism among multiple links connecting two Operator MENs, each link represents a
distinct ENNI. The following requirements apply.

[R1] When there are two physical links in the ENNI, an ENNI-Ni MUST be capable of
implementing Link Aggregation as in Clause 43.6.1 of [3] with one Link Aggre-
gation Group (LAG) across the ports supporting an instance of ENNI and with
one link in active mode and the other in standby mode.

Note that an Operator that is capable of supporting LAG as described in [R1] but elects to use an
alternative protection mechanism at a given ENNI by mutual agreement with the connecting Op-
erator is compliant with [R1].

[R2] When Link Aggregation is used at the ENNI, LACP MUST be used by each
ENNI-Ni per [3].

The choice of which link to use for active or standby is to be decided on an Operator-to-Operator
basis.

Note that the above requirements mean that if one link becomes inactive, Link Aggregation is to
continue to operate on the remaining active link.

Requirements for a two-link LAG in active/active mode or for a LAG with more than two physi-
cal links in the ENNI may be addressed in a later phase of this specification.

7 Operator Services Attributes


The Service Model for the use of the ENNI involves the purchase of services from one or more
Operators. These services are the exchange of traffic among ENNIs and UNIs that are supported
by each Operator MEN. The purchaser of these services from the Operators is referred to as the
Service Provider. Therefore it is important that the attributes of these services be described pre-
cisely. The basic model is shown in Figure 6. Operator Service Attributes describe the possible
behaviors seen by an observer (the Service Provider) external to the Operator MEN at and be-
tween the external interfaces (UNI and ENNI).
MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

UNI

UNI
Operator MEN

ENNI

ENNI

Figure 6 ENNI Ethernet Services Model

The implementation of the Operator Metro Ethernet Network is opaque to the Service Provider.
What is important is the observed behavior among the UNIs and ENNIs in Figure 6. These be-
haviors can be described by the following sets of attributes:

ENNI Service Attributes are presented in Section 7.1.

OVC Service Attributes are presented in Section 7.2.

OVC End Point per ENNI Service Attributes are presented in Section 7.3.

UNI Service Attributes are presented in Section 7.4.

OVC per UNI Service Attributes are presented in Section 7.5.

In the following sections, the term External Interface is used to denote either an ENNI or a
UNI.

7.1 ENNI Service Attributes


The ENNI is the point of demarcation between the responsibilities of two Operators. For each
instance of an ENNI, there are two sets of ENNI Service Attributes, one for each Operator. A
given attribute in the set can have an identical value for each Operator while another attribute can
have a different value for each Operator. It is expected that many if not all of the ENNI Service
Attribute values for each Operator will be known to the Service Provider. In some cases, some of
the ENNI Service Attribute values of one Operator will not be known to the other Operator and
vice versa.

The ENNI Service Attributes are summarized in Table 2 and described in detail in the following
sub-sections.

MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

Attribute Name Summary Description Possible Values


Operator ENNI Identi- An identifier for the ENNI intended A string that is unique across the
fier for management purposes Operator MEN.
Physical Layer The physical layer of the links sup- One of the PHYs listed in [R5]
porting the ENNI
Frame Format The format of the PDUs at the Frame formats as specified in
ENNI Section 7.1.3
Number of Links The number of physical links in the An integer with value 1 or 2
ENNI
Protection Mechanism The method for protection, if any, Link Aggregation, none, or other
against a failure
ENNI Maximum The maximum length ENNI Frame An integer number of bytes
Transmission Unit in bytes allowed at the ENNI greater than or equal to 1526
Size
End Point Map The map that associates each S- A table with rows of the form
Tagged ENNI Frame with an End <S-VLAN ID value, End Point
Point Identifier, End Point Type>
Maximum Number of The maximum number of OVCs An integer greater than or equal
OVCs that the Operator can support at the to 1
ENNI
Maximum Number of The maximum number of OVC An integer greater than or equal
OVC End Points per End Points that the Operator can to 1
OVC support at the ENNI for an OVC.
Table 2 ENNI Service Attributes

7.1.1 Operator ENNI Identifier

The Operator ENNI Identifier is a string administered by the Operator. It is intended for man-
agement and control purposes. An Operator can manage multiple ENNIs.

[R3] The Operator ENNI Identifier MUST be unique among all such identifiers for
ENNIs supported by the Operator MEN.

[R4] The Operator ENNI Identifier MUST contain no more than 45 bytes.

7.1.2 Physical Layer

[R5] Each link in an ENNI MUST be one of the following physical layers in full du-
plex mode as defined in IEEE Std 802.3 2005[3]: 1000Base-SX, 1000Base-LX,
1000Base T, 10GBASE-SR, 10GBASE-LX4, 10GBASE-LR, 10GBASE-ER,
10GBASE-SW, 10GBASE-LW, 10GBASE-EW.

Note that the physical layer at one ENNI supported by the Operator MEN can be different than
the physical layer at another ENNI supported by the Operator MEN.

MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

7.1.3 Frame Format

The ENNI Frame is an Ethernet frame and is defined to consist of the first bit of the Destination
MAC Address through the last bit of the Frame Check Sequence. ENNI Frames use Service
VLAN tags (S-tags), as defined in IEEE Std 802.1ad-2005[4], to map frames to End Points as
described in Section 7.1.7. An ENNI Frame can have zero or more VLAN tags. When there is a
single tag, that tag is an S-Tag. When there are two tags, the outer tag is an S-Tag and the next
tag is a C-Tag as defined in IEEE Std 802.1ad-2005[4].

[R6] Each ENNI Frame MUST have the standard Ethernet format with one of the tag
configurations specified in Table 3. [DA = Destination Address, SA = Source
Address, ET = Ethertype/Length, S-Tag with Tag Protocol Identification Field
(TPID) = 0x88A8, C-Tag with TPID = 0x8100.]

DA (6 bytes) : SA (6 bytes) : ET (2 bytes): payload and FCS (no VLAN tags)


DA(6) : SA(6) : S-Tag (4) : ET (2) : payload and FCS
DA(6) : SA(6) : S-Tag (4) : C-Tag (4) : ET (2) : payload and FCS
Table 3 ENNI Frame Formats

[R7] An S-Tag MUST have the format specified in Sections 9.5 and 9.7 of [IEEE Std
802.1ad]. [4]

[R8] A C-Tag MUST have the format specified in Sections 9.5 and 9.6 of [IEEE Std
802.1ad]. [4]

[R9] An ingress ENNI Frame that is invalid as defined in Clause 3.4 of [3] MUST be
discarded by the receiving Operator MEN.

The length of an ENNI frame is defined as the number of bytes beginning with the first bit of the
Destination Address through the last bit of the Frame Check Sequence.

[R10] An ingress ENNI Frame whose length is less than 64 octets MUST be discarded
by the receiving Operator MEN as per Clause 4.2.4.2.2 of [3].

Note that this specification provides for ENNI Frames that are longer than the maximum speci-
fied in [3]. See Section 7.1.6.

When an ENNI Frame contains an S-Tag, the value of the 12 bit VID field in the S-Tag is de-
fined as the S-VLAN ID Value.

7.1.4 Number of Links

An ENNI can be implemented with one or more physical links. This attribute specifies the num-
ber of such links. When there are two links, protection mechanisms are required, see Section 6.
Protection mechanisms for more than two links are beyond the scope of this specification.

MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

7.1.5 ENNI Resiliency Mechanisms

[R11] If the Number of Links is one, then the Protection Mechanism attribute MUST be
set to none.

[R12] If the Number of Links is 2 and LAG as specified in [R1] is implemented, then
the Protection Mechanism attribute MUST be set to Link Aggregation.

[R13] If the conditions specified [R11] and [R12] are not met, then the Protection
Mechanism attribute MUST be set to other.

As a consequence of these requirements, unprotected links between two Operator MENs repre-
sent distinct ENNIs.

Note that MEN Operators are allowed to decide whether to configure Link Aggregation by
agreement between themselves.

The current scope of this document is restricted to the cases of the Gigabit Ethernet or the 10 Gi-
gabit PHY layer, and therefore the discussions of protection and fault recovery mechanisms are
directed at these PHYs. It is fully expected that later versions of this document will discuss other
PHY layers, and they may contain their own protection and fault recovery mechanisms. Also,
this phase of the specification addresses link or port protection only. The protection mechanism
is Link Aggregation Protocol (802.3-2005). Similarly, later versions may specify other aspects of
protection mechanisms from MEF 2. [13]

7.1.6 ENNI Maximum Transmission Unit Size

The ENNI Maximum Transmission Unit Size specifies the maximum length ENNI Frame in
bytes allowed at the ENNI.

[R14] The ENNI Maximum Transmission Unit Size MUST be at least 1526 bytes.

[D1] The ENNI Maximum Transmission Unit Size SHOULD be at least 2000 bytes.

[R15] When an ENNI Frame is larger than the MTU Size, the receiving Operator MEN
for this frame MUST discard it, and the operation of a Bandwidth Profile that ap-
plies to this is not defined.

The undefined operation of the Bandwidth Profile referred to in [R15] means that an ENNI
Frame discarded because it is larger than the OVC MTU Size can result in either a change or no
change in the state of the Bandwidth Profile algorithm.

The MTU is part of several attribute specifications. For example, UNI, ENNI, and OVC will
have MTU attributes. Please refer to Section 9 for global MTU requirements.

MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

7.1.7 End Point Map

The End Point Map specifies how each S-Tagged ENNI Frame is associated with an OVC End
Point within an Operator MEN. (See Section 7.2.1 for the definition of OVC End Point.) As de-
scribed in the following sub-sections, an End Point Map may or may not have what is called
Bundling.

7.1.7.1 Basic End Point Map

The End Point Map can be represented by a three column table. Column 1 contains S-VLAN ID
values. Column 2 contains End Point Identifiers. Column 3 contains End Point types. Each row
in this table maps the S-VLAN ID value to the End Point Identifier and End Point Type.

Such a table is illustrated by the example in Figure 7. In this example, it is assumed that each
End Point Identifier is formed by appending a four digit number to the ENNI Identifier (Gotham
Central Exchange_12) and there are two types of End Point, OVC and Type X. Per this example,
an S-Tagged ENNI Frame with S-VLAN ID value 189 is mapped to the OVC End Point,
Gotham Central Exchange_12-1589. Note that the End Point Map applies to both ingress and
egress S-Tagged ENNI Frames.

S-VLAN ID Value End Point Identifier End Point Type


158 Gotham Central Exchange_12-1224 OVC End Point
166 Gotham Central Exchange_12-1224 OVC End Point
189 Gotham Central Exchange_12-1589 OVC End Point
3502 Gotham Central Exchange_12-0587 Type X
Figure 7 End Point Map Example

The following requirements apply to the End Point Map.

[R16] For a given S-Tagged ENNI Frame, the End Point to which it is mapped MUST
be determined by the S-VLAN ID value in the S-Tag.

[R17] An S-VLAN ID value MUST be used in no more than one row of the map.

[R18] The End Point Type MUST be OVC End Point or VUNI End Point.3

As per the following requirement, an ingress S-Tagged ENNI Frame whose S-VLAN ID value is
not in the map is not to be forwarded by the receiving Operator MEN.

[R19] An ingress S-Tagged ENNI Frame that is not mapped to an existing End Point
MUST NOT be forwarded to an External Interface by the receiving Operator
MEN.

3
The definition of VUNI End Point and related requirements are in MEF 28 [20].
MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

Note that [R19] does not preclude the receiving Operator MEN from acting as a peer for a L2CP
protocol carried in an S-Tagged ENNI Frame. For example, S-Tagged ENNI Frames could be
used for the ENNI Maintenance Entity Service OAM protocol.

In general the S-VLAN ID values in the End Point Map are local to an ENNI, e.g., OVC End
Points associated by the same OVC at different ENNIs within an Operator MEN may be identi-
fied by different S-VLAN ID values. In cases where it is desirable to constrain each OVC End
Point to be identified by the same S-VLAN ID value for a given OVC, the OVC is specified to
have S-VLAN ID Preservation with value yes (see Section 7.2.13).

[R20] An ENNI Frame without an S-Tag MUST NOT be mapped to an OVC End
Point.

[R20] does not necessarily mean that an untagged ENNI is to be discarded by the receiving Op-
erator MEN. For example, an untagged ENNI Frame carrying a Layer 2 Control Protocol might
be processed.

Note that at a given ENNI, each Operator MEN will have an End Point Map and these maps will
typically have differences. Figure 8 shows an example for two Operator MENs, A and B. In this
example, each Operator MEN is using a different scheme for identifying OVC End Points and
thus the maps differ in column 2. More examples of End Point Maps are in Section 10.

Operator MEN A End Point Map


S-VLAN ID Value End Point Identifier End Point Type
158 Gotham Central Exchange_12-1224 OVC
189 Gotham Central Exchange_12-1589 OVC

Operator MEN B End Point Map


S-VLAN ID Value End Point Identifier End Point Type
158 Switch-103-Port-4-038 OVC
189 Switch-103-Port-4-344 OVC
Figure 8 Example of the two End Point Maps for a Given ENNI

As described in Section 7.2.2, an OVC End Point always has one of three roles; Root, Leaf, or
Trunk. When an OVC End Point at an ENNI has the role of Trunk, two S-VLAN ID values map
to that OVC End Point in the End Point Map. One S-VLAN ID value identifies ENNI frames
that result from Service Frames that originated at a Root UNI, and the other S-VLAN ID value
identifies ENNI frames that result from Service Frames that originated at a Leaf UNI. (See Sec-
tion 6.1.2.2 of MEF 10.2 [5] for descriptions of Root UNI and Leaf UNI.) The Trunk Identifiers
attribute (see Section 7.3.2) specifies these S-VLAN ID values.

[R21] When the End Point Map contains an OVC End Point that has the OVC End Point
Role of Trunk, the End Point MAP MUST contain exactly one Root S-VLAN ID
value and one Leaf S-VLAN ID value that map to the OVC End Point.
MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

Note that [R21] is only relevant at an ENNI.

7.1.7.2 End Point Map Bundling

When multiple S-VLAN ID values map to a single OVC End Point in the End Point Map, and
the OVC associating that OVC End Point is not a Rooted-Multipoint OVC, the End Point Map is
said to have Bundling and the OVC is said to be Bundled. (See Section 7.2.6 for the definition of
Rooted-Multipoint OVC.) Note that these definitions are only relevant at an ENNI. When the
End Point Map has Bundling, any OVC (that is not a Rooted-Multipoint OVC) that associates an
OVC End Point for which the bundling applies has to have S-VLAN ID Preservation = Yes,
cannot have Hairpin Switching (see Section 7.2.2), and can only associate OVC End Points that
are at two ENNIs. The following requirements detail these properties.

[R22] A Bundled OVC MUST associate exactly two OVC End Points.

When there is Bundling, it is possible that frames originated by more than one Subscriber will be
carried by the OVC and thus there may be duplicate MAC addresses being used by multiple Sub-
scribers. To avoid the problems in the Operator MEN that can result from this duplication, MAC
Address learning can be disabled on the OVC. However, disabling MAC Address learning can
lead to poor efficiency when the OVC associates OVC End Points at more than two ENNIs. This
is the motivation for [R22]. Future phases of this specification may relax [R22].

[R23] A Bundled OVC MUST have its S-VLAN ID Preservation attribute set to Yes.
(See Section 7.2.13.)

Note that [R23] and [R47] mean that a Bundled OVC can associate at most one OVC End Point
at an ENNI.

[R24] A Bundled OVC MUST have its CE-VLAN ID Preservation attribute set to Yes.
(See Section 7.2.11.)

[R25] A Bundled OVC MUST have its CE-VLAN CoS Preservation attribute set to
Yes. (See Section 7.2.12.)

[R26] Each OVC End Point associated by a Bundled OVC MUST be at an ENNI.

[R27] Each End Point Map at the ENNIs where there is an OVC End Point associated
by a Bundled OVC MUST map the same list of S-VLAN ID values to the OVC
End Point associated by the Bundled OVC.

As an example of [R27], consider the End Point Map shown in Figure 7. S-VLAN ID values 158
and 166 both map to the OVC End Point, Gotham Central Exchange_12-1224. If the OVC as-
sociating this OVC End Point also associates an OVC End Point at another ENNI, call it Me-
tropolis East Exchange_08-1328, then the End Point Map at this other ENNI must map exactly
158 and 166 to Metropolis East Exchange_08-1328.

MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

7.1.8 Maximum Number of OVCs

The Maximum Number of OVCs provides an upper bound on the number of OVCs that the Op-
erator will support at the ENNI.

7.1.9 Maximum Number of OVC End Points per OVC

The Maximum Number of OVC End Points per OVC provides an upper bound on the number of
OVC End Points that are associated by an OVC that the Operator can support at the ENNI.

Note that if the Maximum Number of OVC End Points per OVC is one, then hairpin switching
cannot be supported at the ENNI. See Section 7.2.3.

7.2 OVC Service Attributes


7.2.1 OVC End Points

In the same way that an EVC defines an association of UNIs, an OVC is an association of OVC
End Points. An OVC End Point represents the logical attachment of an OVC to an External In-
terface (a UNI or ENNI in the context of this document). At each External Interface, there must
be a way to map each frame to at most one OVC End Point. Sections 7.1.7 and 7.4 describe the
mapping method for an ENNI and a UNI respectively.

[R28] A given OVC MUST associate at most one OVC End Point at a given UNI.

[O1] A given OVC MAY associate more than one OVC End Point at a given ENNI.

[R29] If an egress frame mapped to an OVC End Point results from an ingress frame
mapped to an OVC End Point, there MUST be an OVC that associates the two
OVC End Points. And, the two OVC End Points MUST be different from each
other.

[R29] means that, at a given ENNI, an ingress ENNI Frame mapped to a OVC End Point cannot
result in an egress ENNI Frame at the given ENNI that is also mapped to that OVC End Point.

[R30] At least one of the OVC End Points associated by an OVC MUST be at an ENNI.

Note that if an OVC was allowed to associate End Points that were only at UNIs, then the OVC
would not be distinguishable from an EVC as defined in MEF 10.2 [5].

7.2.2 OVC End Point Roles and Forwarding Constraints

An OVC End Point has one of three possible Roles; Root, Leaf, or Trunk.

[R31] The OVC End Point Role of an OVC End Point at a UNI MUST have the value
either Root or Leaf.

MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

[R32] The OVC End Point Role of an OVC End Point at an ENNI MUST have the
value Root, Trunk, or Leaf.

Note that the OVC End Role will always have the value Root when the associating OVC is not
of the type Rooted-Multipoint. See Section 7.2.6 for the definition of OVC Type.

For ease of exposition:

An OVC End Point with the role of Root is called a Root OVC End Point,

An OVC End Point with the role of Leaf is called a Leaf OVC End Point, and

An OVC End Point with the role of Trunk is called a Trunk OVC End Point.

The following requirements constrain the forwarding behavior of an OVC based on the roles of
the OVC End Points associated by the OVC. (See Section 7.3.2 for the definition of Root S-
VLAN ID value and Leaf S-VLAN ID value.)

[R33] An egress frame at an EI that is mapped to a Root OVC End Point MUST be the
result of an ingress frame at an EI that was mapped to a Root, Trunk, or Leaf
OVC End Point.

[R34] An egress frame at an EI that is mapped to a Leaf OVC End Point MUST be the
result of an ingress frame at an EI that was mapped to a Root OVC End Point or
mapped to a Trunk OVC End Point via the Root S-VLAN ID value.

[R35] An egress frame at an EI that is mapped to a Trunk OVC End Point MUST con-
tain the Root S-VLAN ID value when it is the result of an ingress frame at an EI
that was mapped to a Root OVC End Point or mapped to a Trunk OVC End Point
via the Root S-VLAN ID value.

[R36] An egress frame at an EI that is mapped to a Trunk OVC End Point MUST con-
tain the Leaf S-VLAN ID value when it is the result of an ingress frame at an EI
that was mapped to a Leaf OVC End Point or mapped to a Trunk OVC End Point
via the Leaf S-VLAN ID value.

These forwarding requirements are summarized in Table 4.

MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

Ingress OVC End Point Role


Root Leaf Trunk Trunk
(Leaf S-VID) (Root S-VID)
Root    
Egress OVC Leaf    
End Point Trunk
   
Role (Leaf S-VID)
Trunk
   
(Root S-VID)
Table 4 Allowed Connectivity Between OVC End Point Roles

By correct use of OVC End Point Roles and S-VLAN ID values, each Operator MEN can deter-
mine for each ingress frame that it receives whether the frame is the result of an ingress Service
Frame at a Root UNI or a Leaf UNI. This information is necessary to implement a Rooted-
Multipoint EVC that spans multiple Operator MENs. Section 11 contains examples of the sup-
port of Rooted-Multipoint EVCs.

When doing MAC address learning it is useful to do shared VLAN learning. This means that the
source address of an ingress ENNI Frame mapped to a Trunk OVC End Point should be learned
for both the Root S-VLAN ID value and the Leaf S-VLAN ID value. See Annex F of IEEE Std
802.1Q-2011 [21] for information on shared VLAN learning, and specifically F.1.3.2 for
Rooted-Multipoint.

7.2.3 Hairpin Switching

Hairpin Switching occurs when an ingress S-Tagged ENNI Frame at a given ENNI results in an
egress S-Tagged ENNI Frame with a different S-VLAN ID value at the given ENNI. This behav-
ior is possible when an OVC associates two or more OVC End Points at a given ENNI. Sections
10.4 and 10.6 show examples of the use of Hairpin Switching.

Note that this configuration of OVC End Points is allowed by [O1]. Also note that [R28] pre-
cludes Hairpin Switching at a UNI.

Improper use of Hairpin Switching can result in a data loop between two Operator MENs at a
single ENNI. Section 10.5 shows an example of how this can happen. It is up to the Service Pro-
vider and Operators to ensure that such loops do not occur. Automated methods for detecting
and/or preventing such loops are beyond the scope of this document.

7.2.4 OVC Service Attributes

The OVC Service Attributes are summarized in Table 5 and described in detail in the following
sub-sections.

Attribute Name Summary Description Possible Values

MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

Attribute Name Summary Description Possible Values


OVC Identifier An identifier for the OVC intended for management A string that is
purposes unique across the
Operator MEN
OVC Type An indication of the number and roles of the OVC End Point-to-Point,
Points associated by the OVC. Multipoint-to-
Multipoint, or
Rooted-Multipoint
OVC End Point A list of OVC End Points associated by the OVC and A list of <OVC
List the OVC End Point Role of each OVC End Point asso- End Point Identi-
ciated by the OVC fier, OVC End
Point Role> pairs
Maximum Num- The bound on the number of OVC End Points at differ- An integer greater
ber of UNI OVC ent UNIs that can be associated by the OVC than or equal to 04
End Points
Maximum Num- The bound on the number of OVC End Points at ENNIs An integer greater
ber ENNI OVC that can be associated by the OVC than or equal to 14
End Points
OVC Maximum The maximum length in bytes allowed in a frame An integer number
Transmission mapped to the an OVC End Point that is associated by of bytes greater
Unit Size the OVC than or equal to
1526
CE-VLAN ID A relationship between the format and certain field val- Yes or No
Preservation ues of the frame at one External Interface and the for-
mat and certain field values of the corresponding frame
at another External Interface that allows the CE-VLAN
ID value of the UNI Service Frame to be derived from
the ENNI Frame and vice versa
CE-VLAN CoS A relationship between the format and certain field val- Yes or No
Preservation ues of the frame at one External Interface and the for-
mat and certain field values of the corresponding frame
at another External Interface that allows the CE-VLAN
CoS value of the UNI Service Frame to be derived from
the ENNI Frame and vice versa
S-VLAN ID A relationship between the S-VLAN ID value of a Yes or No
Preservation frame at one ENNI and the S-VLAN ID value of the
corresponding frame at another ENNI
S-VLAN CoS A relationship between the S-VLAN PCP value of a Yes or No
Preservation frame at one ENNI and the S-VLAN PCP value of the
corresponding frame at another ENNI

4
Note that if the "Maximum Number of UNI OVC End Points" plus the "Maximum Number ENNI OVC End
Points" is less than 2, then the OVC is not capable of conveying frames across the Operator MEN.
MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

Attribute Name Summary Description Possible Values


Color Forward- The relationship between the Color of an egress ENNI Yes or No
ing Frame and the Color of the corresponding ingress
ENNI Frame or Service Frame
Service Level Frame delivery performance definitions and objectives See Section 7.2.16
Specification for frames between External Interfaces
Unicast Service This attribute describes how ingress frames mapped to Deliver Uncondi-
Frame Delivery an OVC End Point with a unicast destination MAC ad- tionally or Deliver
dress are delivered to the other External Interfaces with Conditionally
OVC End Points associated by the OVC
Multicast Service This attribute describes how ingress frames mapped to Deliver Uncondi-
Frame Delivery an OVC End Point with a multicast destination MAC tionally or Deliver
address are delivered to the other External Interfaces Conditionally
with OVC End Points associated by the OVC
Broadcast Ser- This attribute describes how ingress frames mapped to Deliver Uncondi-
vice Frame De- an OVC End Point with the broadcast destination MAC tionally or Deliver
livery address are delivered to the other External Interfaces Conditionally
with OVC End Points associated by the OVC
Layer 2 Control The Layer 2 Control Protocols that are tunneled by the A list on Layer 2
Protocol Tunnel- OVC Control Protocols
ing
Table 5 OVC Service Attributes

7.2.5 OVC Identifier

The OVC Identifier is a string administered by the Operator that is used to identify an OVC
within the Operator MEN. It is intended for management and control purposes. The OVC Identi-
fier is not carried in any field in the ENNI Frame.

[R37] The OVC Identifier MUST be unique among all such identifiers for OVCs sup-
ported by the Operator MEN.

[R38] The OVC Identifier MUST contain no more than 45 bytes.

Note that the EVC Identifier described in MEF 10.2 [5] is known to the Subscriber and Service
Provider. The degree to which the EVC Identifier is made known to the Operators is up to the
Service Provider.

7.2.6 OVC Type

There are three types of OVC: Point-to-Point, Multipoint-to-Multipoint, and Rooted-Multipoint.

An OVC that can only associate two or more Root OVC End Points is defined to have OVC
Type of Multipoint-to-Multipoint.

MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

An OVC that associates exactly two Root OVC End Points is defined to have OVC Type of
Point-to-Point, and can be considered a special case of the Multipoint-to-Multipoint OVC Type.

Note that a Multipoint-to-Multipoint OVC that associates two Root OVC End Points differs from
a Point-to-Point OVC in that additional Root OVC End Points can be added to the OVC.

An OVC that can associate at least one Leaf or Trunk OVC End Point is defined to have OVC
Type of Rooted-Multipoint. Note that an OVC that associates only Leaf OVC End Points is not
useful since it cannot forward frames between External Interfaces. See Section 7.2.2.

The distinction between a Point-to-Point OVC or Multipoint-to-Multipoint OVC and a Rooted-


Multipoint OVC with only Root OVC End Points is that a Leaf or Trunk OVC End Point can be
added to such a Rooted-Multipoint OVC.

Note that because an OVC can associate more than one OVC End Point at a given ENNI, the
type of an OVC is not determined by the number of External Interfaces supported by the OVC.

7.2.7 OVC End Point List

The OVC End Point List is a list of pairs of the form <OVC Point Identifier, OVC End Point
Role>. Note that when the OVC type is not Rooted-Multipoint, the list can be simplified to a list
of OVC End Point Identifiers since the OVC End Role is always Root. The list contains one item
for each OVC End Point associated by the OVC. Section 7.3.1 describes OVC End Point Identi-
fier. Section 7.2.2 describes the OVC End Point Role.

7.2.8 Maximum Number of UNI OVC End Points

The Maximum Number of UNI OVC End Points is the upper bound on the number of OVC End
Points that are at different UNIs that can be associated by an OVC.

7.2.9 Maximum Number of ENNI OVC End Points

The Maximum Number of ENNI OVC End Points is the upper bound on the number of OVC
End Points that are at an ENNI that can be associated by an OVC.

7.2.10 OVC Maximum Transmission Unit Size

The OVC Maximum Transmission Unit Size specifies the maximum length frame in bytes al-
lowed on the OVC.

[R39] The OVC Maximum Transmission Unit Size MUST be at least 1526 bytes.

[D2] The OVC Maximum Transmission Unit Size SHOULD be at least 2000 bytes.

[R40] When an ENNI Frame or a Service Frame is larger than the OVC MTU Size for
the OVC associating the OVC End Point to which it is mapped, the receiving Op-

MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

erator for this frame MUST discard it, and the operation of a Bandwidth Profile,
if any, that applies to this frame is not defined.

The undefined operation of the Bandwidth Profile referred to in [R40] means that frame dis-
carded because it is larger than the OVC MTU Size can result in either a change or no change in
the state of the Bandwidth Profile algorithm.

[R41] The OVC Maximum Transmission Unit Size MUST be less than or equal to the
MTU Size of each External Interface where an OVC End Point exists that is asso-
ciated by the OVC.

The MTU is part of several attribute specifications. For example, UNI, ENNI, and OVC will
have MTU attributes. Please refer to Section 9 for global MTU requirements.

7.2.11 CE-VLAN ID Preservation

CE-VLAN ID Preservation describes a relationship between the format and certain field values
of the frame at one External Interface and the format and certain field values of the correspond-
ing frame at another External Interface. This relationship allows the CE-VLAN ID value of the
UNI Service Frame to be derived from the ENNI Frame and vice versa. OVC CE-VLAN ID
Preservation is used to achieve EVC CE-VLAN ID Preservation that is a key property of the
EPL and EP-LAN Service Types specified in MEF 6.1 [9]. See Sections 10.3 and 10.4 for exam-
ples of its use.

[R42] When an OVC has the CE-VLAN ID Preservation attribute with a value of Yes
and all of the UNIs with an OVC End Point associated by the OVC are such that
all CE-VLAN IDs map to the OVC End Point (see Section 7.5.2), then the rela-
tionship between the format of the frame at the ingress External Interface and the
corresponding frame at the egress External Interface MUST be as specified in
Table 6.

MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

Ingress
Ingress Egress
Frame For- Egress Frame Format
Interface Interface
mat
UNI Untagged UNI Untagged
UNI Untagged ENNI S-Tag only
C-Tagged with VLAN ID value equal to that of in-
UNI C-Tagged UNI
gress Service Frame at the UNI
S-Tag and C-Tag with the VLAN ID value in the C-
UNI C-Tagged ENNI Tag equal to the VLAN ID value in the C-Tag at the
UNI
C-Tagged with the VLAN ID value of the C-Tag
S-Tag and C-
ENNI UNI equal to that of the VLAN ID value in the C-Tag of
Tag
the ingress frame at the ENNI
ENNI S-Tag only UNI Untagged
S-Tag and C-Tag with the VLAN ID value in the C-
S-Tag and C-
ENNI ENNI Tag equal to the VLAN ID value in the C-Tag at the
Tag
ingress ENNI.
ENNI S-Tag only ENNI S-Tag only
Table 6 OVC CE-VLAN ID Preservation when All CE-VLAN IDs
Map to the OVC at all of the UNIs Associated by the OVC

[R43] When an OVC has the CE-VLAN ID Preservation attribute with a value of Yes
and not all of the UNIs with an OVC End Point associated by the OVC are such
that all CE-VLAN IDs map to the OVC End Point (see Section 7.5.2), then the re-
lationships between the format of the frame at the ingress External Interface and
the corresponding frame at the egress External Interface MUST be as specified in
Table 7.

MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

Ingress Egress
Ingress Frame Format Egress Frame Format
Interface Interface
C-Tagged with VLAN ID C-Tagged with VLAN ID value equal to
UNI value in the range 1, , UNI that of the ingress Service Frame at the
4094 UNI
C-Tagged with VLAN ID S-Tag and C-Tag with the VLAN ID
UNI value in the range 1, , ENNI value in the C-Tag equal to the VLAN
4094 ID value in the C-Tag at the UNI
S-Tag and C-Tag with
Tagged with the VLAN ID value of the
VLAN ID value in the C-
ENNI UNI C-Tag equal to that of the C-Tag of the
Tag in the range 1, ,
ingress frame at the ENNI
4094
S-Tag and C-Tag with S-Tag and C-Tag with the VLAN ID
VLAN ID value in the C- value in the C-Tag equal to the VLAN
ENNI ENNI
Tag in the range 1, , ID value in the C-Tag at the ingress
4094 ENNI.
Table 7 OVC CE-VLAN ID Preservation when not All CE-VLAN IDs Map to the OVC at
all of the UNIs Associated by the OVC

[R44] When an OVC has the CE-VLAN ID Preservation attribute with a value of Yes
and none of the End Points associated by the OVC are at UNIs, then the relation-
ships between the format of the frame at the ingress ENNI and the corresponding
frame at the egress ENNI MUST be as specified in Table 8.

Ingress Frame
Egress Frame Format
Format
S and C-Tag with the VLAN ID value in the C-Tag equal to the VLAN ID
S-Tag and C-Tag
value in the C-Tag at the ingress ENNI.
S-Tag only S-Tag only
Table 8 OVC CE-VLAN ID Preservation when none of the OVC End Points are at UNIs

Note that when a Service Frame is delivered from a UNI in one Operator MEN to a UNI in an-
other Operator MEN via an EVC supported by two or more OVCs with all OVCs having CE-
VLAN ID Preservation attribute = Yes, then the Service Frame will have CE-VLAN ID Preser-
vation as defined in Section 6.6.1 in MEF 10.2 [5]. Thus, the EVC that associates these two
UNIs will have the CE-VLAN ID Preservation Service Attribute = Yes as defined in Section
6.6.1 in [5]. Also note that CE_VLAN ID Preservation as defined in Section 6.6.1 in MEF 10.2
[5] only applies to tagged Service Frames when there is not All to One Bundling at the UNI and
thus Table 7 does not include the cases for untagged Service Frames at the UNI. See Table 2 and
Table 3 in Section 6.6.1 of MEF 10.2 [5]. Section 10 shows some examples of the use of CE-
VLAN ID Preservation in the construction of Ethernet Services.

MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

7.2.12 CE-VLAN CoS Preservation

CE-VLAN CoS Preservation describes a relationship between the format and certain field values
of the frame at one External Interface and the format and certain field values of the correspond-
ing frame at another External Interface. This relationship allows the CE-VLAN CoS value of the
UNI Service Frame to be derived from the ENNI Frame and vice versa. OVC CE-VLAN CoS
Preservation is used to achieve EVC CE-VLAN CoS Preservation that is a key property of the
EPL and EP-LAN Service Types specified in MEF 6.1 [9] See Sections 10.3 and 10.4 for exam-
ples of its use.

[R45] When an OVC has the CE-VLAN CoS Preservation attribute with a value of Yes
the relationship between the format of the frame at the ingress External Interface
and the corresponding frame at the egress External Interface MUST be as speci-
fied in Table 9.

Ingress
Ingress Egress
Frame For- Egress Frame Format
Interface Interface
mat
C-Tagged with PCP value equal to that of ingress
UNI C-Tagged UNI
Service Frame
S-Tag and C-Tag with the PCP value in the C-Tag
UNI C-Tagged ENNI
equal to the PCP value in the C-Tag at the UNI
S-Tag and C- C-Tagged with the PCP value of the tag equal to that
ENNI UNI
Tag of the C-Tag of the ingress frame at the ENNI
S-Tag and C-Tag with the PCP value in the C-Tag
S-Tag and C-
ENNI ENNI equal to the PCP value in the C-Tag of the ingress
Tag
frame at the ingress ENNI
Table 9 OVC CE-VLAN CoS Preservation

Note that when a Service Frame is delivered from a UNI in one Operator MEN to a UNI in an-
other Operator MEN via two or more OVCs with CE-VLAN CoS Preservation, then the EVC
that associates these two UNIs will have the CE-VLAN CoS Preservation Service Attribute as
defined in Section 6.6.2 in [5].

7.2.13 S-VLAN ID Preservation

S-VLAN ID Preservation describes a relationship between the S-VLAN ID value of a frame at


one ENNI and the S-VLAN ID value of the corresponding frame at another ENNI supported by
the Operator MEN where each ENNI has an OVC End Point that is associated by the OVC. The
possible values of the S-VLAN ID Preservation attribute are Yes or No.

[R46] When an OVC has the S-VLAN ID Preservation attribute with a value of Yes, an
egress ENNI Frame at an ENNI resulting from an ingress ENNI Frame at a differ-
ent ENNI MUST have an S-VLAN ID value identical to the S-VLAN ID value of
the ingress ENNI Frame.
MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

[R47] When an OVC has the S-VLAN ID Preservation attribute with a value of Yes, it
MUST associate at most one OVC End Point located at a given ENNI.

[R48] When an OVC has the S-VLAN ID Preservation attribute with a value of No, an
egress ENNI Frame mapped to an OVC End Point resulting from an ingress
ENNI Frame mapped to a different OVC End Point MUST have an S-VLAN ID
value that has a one-to-one association with the S-VLAN ID of the ingress service
frame.

Note that the S-VLAN ID Preservation attribute does not apply to frames exchanged between an
ENNI and a UNI.

7.2.14 S-VLAN CoS Preservation

S-VLAN CoS Preservation describes a relationship between the S-VLAN PCP value of a frame
at one ENNI and the S-VLAN ID of the corresponding frame at another ENNI supported by the
Operator MEN where each ENNI has an OVC End Point that is associated by the OVC. The pos-
sible values of the S-VLAN CoS Preservation attribute are Yes or No.

[R49] When an OVC has the S-VLAN CoS Preservation attribute with a value of Yes,
an egress ENNI Frame at an ENNI resulting from an ingress ENNI Frame at a dif-
ferent ENNI MUST have an S-VLAN PCP value identical to the S-VLAN PCP
value of the ingress ENNI Frame.

Note that when the S-VLAN PCP is used to indicate the color for an ENNI Frame, see [R85]
and [R86], it could be undesirable to have S-VLAN CoS Preservation = Yes because an ingress
ENNI Frame marked Green could never be marked Yellow on egress. An attribute that preserves
Class of Service indication between ENNIs while allowing for changing the color marking using
the S-Tag PCP may be addressed in a future phase of this document.

7.2.15 Color Forwarding

Color Forwarding describes the relationship between the color on an ingress frame into the Op-
erator Network and the color of the resulting egress ENNI Frame. When Color Forwarding is
Yes, the OVC cannot promote a frame from Yellow to Green. Promoting a frame from Yellow
to Green could have an undesired impact on the EVC performance. The newly promoted Green
frames are now competing with equal rights for resources as frames marked Green at the ingress
UNI. For this reason, this attribute is useful to prevent this behavior.

[R50] When the Color Forwarding attribute is Yes for an OVC, each egress ENNI
Frame mapped to an OVC End Point that is associated by the OVC MUST be
marked Yellow using one of the formats specified in Section 7.3.3 if the corre-
sponding ingress frame into the Operator MEN satisfied one or more of the fol-
lowing:

MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

The corresponding ingress frame was a Service Frame that was declared
Yellow by an Ingress Bandwidth Profile and the Service Frame was mapped
to an OVC End Point at the UNI that is associated by the OVC,

The corresponding ingress frame was a Service Frame with a frame header
indicating Yellow as specified in MEF 23.1 [10] and the Service Frame was
mapped to an OVC End Point at the UNI that is associated by the OVC,

The corresponding ingress frame was an ENNI Frame that was declared
Yellow by an Ingress Bandwidth Profile and the ENNI Frame was mapped
to an OVC End Point at the ENNI that is associated by the OVC,

The corresponding ingress frame was an ENNI Frame with a frame header
indicating Yellow using one of the formats specified in Section 7.3.3 and the
ENNI Frame was mapped to an OVC End Point at the ENNI that is associ-
ated by the OVC.

[O2] When the Color Forwarding attribute is No, the Color marking of each egress
ENNI Frame mapped to an OVC End Point that is associated by the OVC MAY
be related to the Color of the corresponding ingress frame into the Operator Net-
work in any way.

Note that this attribute does not describe Color marking of an egress Service Frame at a UNI be-
cause a method for such marking is not specified in MEF 23.1 [10].

7.2.16 Service Level Specification

The OVC Related Performance Service Attributes specify the frame delivery performance be-
tween External Interfaces (EI). Eight performance metrics are detailed in this specification:

1. One-way Frame Delay,

2. One-way Frame Delay Range,

3. One-way Mean Frame Delay,

4. Inter-Frame Delay Variation,

5. One-way Frame Loss Ratio,

6. One-way Availability,

7. One-way High Loss Intervals, and

8. One-way Consecutive High Loss Intervals.

MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

These are similar to the performance attributes for an EVC described in MEF 10.2 [5] and MEF
10.2.1[22] but more general because both the UNI and ENNI are covered in this document.

These Performance Service Attributes describe the performance experienced by the Service Pro-
vider who is the user of the OVC. Methods for the Operator and the Service Provider to monitor
the OVC performance to estimate this user experience are beyond the scope of this document.

An SLS can specify objectives for all or any subset of the OVC Performance Service Attributes.

[R51] If an SLS contains an objective for a given OVC Related Performance Service At-
tribute, then the SLS MUST specify the related parameters for that objective.

OVC Related Performance Service Attributes, with the exception of Availability5, apply to
Qualified Service Frames and Qualified ENNI Frames, called Qualified Frames.

[R52] An SLS MUST define Qualified Frames as follows for a given ordered pair of
OVC End Points <i,j>, a given time interval T, and a given Class of Service Iden-
tifier:

1. Each frame MUST ingress at the EI where OVC End Point i is located.

2. Each frame MUST map to OVC End Point i via the End Point Map. (See Section
7.1.7 for the descriptions of the End Point Map at the ENNI and Section 7.5.2 for
the description of the OVC End Point Map at the UNI.)

3. The first bit of each frame MUST arrive at the ingress EI within the time interval
T, and within a time interval t smaller than T that has been designated as part of
Available time (see Section 7.2.16.4),

4. Each frame MUST have the given Class of Service Identifier,

5. Each ingress frame that is subject to an ingress Bandwidth Profile MUST have an
Ingress Bandwidth Profile compliance of Green, and

6. Each ingress frame that is not subject to an ingress Bandwidth Profile MUST
meet one of the following two conditions:

The frame has no color identifier6, or

The frame has a color identifier that indicates Green per the color indication
requirements of MEF 23[10].

Such frames are referred to as Qualified Frames.

5
Availability is used to define Qualified Frames via item 3 in the list.
6
When there is no color identifier, this bullet means that the Service Frame is treated as if it were declared Green.
An example is the use of the H Label as defined in MEF 23 [10] where a color identifier is not specified per Table 2
of [10] .
MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

Recall that both OVC End Points in the ordered pair can be located at the same ENNI. See [O1]
and Section 7.2.3.

The assessment of all performance attributes needs to account for unexpected arrival phenomena,
such as frame duplication, or frames arriving in a different order from that observed on ingress,
and the presence of these phenomena alone do not necessarily exclude a frame from the set of
Qualified Frames. Details on how to monitor performance in the face of unexpected arrival phe-
nomena are beyond the scope of this document.

7.2.16.1 One-way Frame Delay Performance for an OVC

This section defines three performance attributes: the One-way Frame Delay Performance corre-
sponding to a percentile of the distribution, the One-way Mean Frame Delay, and the One-way
Frame Delay Range.

The One-way Frame delay for a frame that ingresses at EI1 and results in a frame that egresses at
EI2 is defined as the time elapsed from the reception of the first bit of the ingress frame at EI1
until the transmission of the last bit of the first corresponding egress frame at EI2. If the frame is
erroneously duplicated in the Operator MEN and multiple copies delivered to EI2, the delay is
based on the first such copy delivered.

Note that this definition of One-way Frame Delay for a frame is the one-way7 delay that includes
the delays encountered as a result of transmission across the ingress and egress EIs as well as
that introduced by the Operator MEN.

Note that when the path between two UNIs crosses one or more ENNIs, the UNI to UNI One-
way Frame Delay, as defined in MEF 10.2 does not equal the sum of the One-way Frame Delay
between each pair of EIs. This is because the sum will double count the time to transmit a frame
across each ENNI. To see this, note that the definition of delay, DO , between a UNI and an
ENNI on single Operator MEN can be expressed as DO = dU + d E + d M were d U is the time to
transmit the frame across the UNI, d E is the time to transmit the frame across the ENNI, and d M
is the queuing and transmission delay introduced by the Operator MEN. Now consider the case
where Operator MEN 1 and Operator MEN 2 are connected via an ENNI to affect an EVC be-
tween two UNIs, one on each Operator MEN. The delay between the UNIs is
dU 1 + d M 1 + d E + d M 2 + dU 2 . But

DO1 + DO 2 = dU 1 + d M 1 + dU 2 + d M 2 + 2d E dU 1 + d M 1 + d E + d M 2 + dU 2 .

Adding the two OVC delays overstates the UNI to UNI delay by d E .

7
One-way delay is difficult to measure and therefore one way delay may be approximated from two way measure-
ments. However these techniques are beyond the scope of this document.
MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

This effect will need to be taken into account when deriving the UNI to UNI delay performance
from the delay performance of each Operator MEN in the path of the frame. This derivation is
beyond the scope of this document.

[R53] For a given non-empty set of ordered pairs of OVC End Points, a time interval T,
and a given Class of Service Identifier, the SLS MUST define each Frame Delay
Performance metric as follows:

Let the OVC End Points associated by the OVC be numbered from 1 to m. And
let S be a non-empty subset of the ordered pairs of OVC End Points associated by
the OVC. That is S { i, j | i = 1,..., m, j = 1,..., m, i j}, S .

i, j
Let d Td represent the Pd -Percentile of one-way delay for all Qualified Frames
delivered to the egress EI where OVC End Point j is located resulting from an in-
gress frame at the EI where OVC End Point i is located. If there are no such
i, j
egress frames, then dTd = Undefined.

Then the One-way Frame Delay Performance metric MUST be defined as the
i, j i, j
maximum value of all of the defined values d Td for i, j S , unless all d Td
are Undefined in which case the performance is Undefined.
i, j i, j i, j i, j
Let dTR = dTr d min . dTr represents the Pr -Percentile of the one-way delay
for all Qualified Frames delivered to the egress EI where OVC End Point j is lo-
cated resulting from an ingress frame at the EI where OVC End Point i is located.
i, j
d min is the minimum of the one-way delays for all Qualified Frames delivered to
the EI where OVC End Point j is located resulting from an ingress frame at the EI
where OVC End Point i is located. If there are no such egress frames, then
i, j
dTR = Undefined.

Then the One-way Frame Delay Range Performance metric MUST be defined as
i, j
the maximum value of all of the defined values of dTR for i, j S , unless all
i, j
d TR are Undefined in which case the performance is Undefined.

i, j
Let T represent the arithmetic mean of one-way delay for all Qualified
Frames delivered to the EI where OVC End Point j is located resulting from an
ingress frame at the EI where OVC End Point i is located. If there are no such
i, j
egress frames, then T = Undefined.

MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

Then the One-way Mean Frame Delay Performance metric MUST be defined as
i, j
the maximum value of all of the defined values T for i, j S , unless all
T i , j are Undefined in which case the performance is Undefined.

To restate the Frame Delay definition mathematically, let the OVC End Points associated by the
i, j
OVC be numbered from 1 to m and let DT be the set of one-way Frame Delay values for all
Qualified Frames at the EI where OVC End Point j is located resulting from an ingress frame at
i, j i, j i, j i, j i, j
the EI where OVC End Point i is located. DT can be expressed as DT = d1 , d 2 ,..., d N i , j , { }
is the one-way Frame Delay of the kth frame. Define d Td
i, j i, j
where d k for Pd > 0 as

N

d
i, j min d | Pd
=
100 i , j
I d , dk (
i, j
) if N i, j
1
Td N i , j k =1

Undefined otherwise

where I (, d k ) is an indicator function defined by

1 if d d k
I (d , d k ) .
0 otherwise
i, j
d Td is the minimal delay during the time internal T that Pd percent of the frames do not ex-
ceed.

Then a One-way Frame Delay Performance metric for an OVC can be expressed as

{
max dTdi , j | i, j S and where N i , j > 0
dT , S = .
}
Undefined when all N i , j = 0 for all i, j S

The One-way Frame Delay attribute permits specification of multiple values for Pd , (P0, P1, P2,
) and corresponding objectives ( d , d , d
i, j i, j i, j
0 , ). 1 2

Another parameter is the objective for the difference between the delay Pr percentile delay and
i, j
d min = min d DT { i, j
} , expressed as
i, j
(d i , j d min
i, j
) if N i , j > 0
dTR = Tr
Undefined if N i , j = 0

where
MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

N

d
i, j min d | Pr
=
100 i , j
(
I d , dk
i, j
) if N i, j
1
.
Tr N i , j k =1

Undefined otherwise

Then a One-way Frame Delay Range Performance metric for an OVC can be expressed as

dTR , S =
{
max dTRi , j | i, j S and where N i , j > 0
.
}
Undefined when all N i , j = 0 for all i, j S

i, j
Another One-way Frame Delay attribute is the arithmetic mean of DT , which can be expressed
as

1 N i, j i, j
T i , j

= N i , j k =1
( )
d k if N i , j > 0
Undefined if N =0
i, j

Then a One-way Mean Frame Delay Performance metric for an OVC can be expressed as

T , S =
{
max T i , j | i, j S and where N i , j > 0
.
}
Undefined when all N i , j = 0 for all i, j S

The parameters of a One-way Frame Delay Performance metric are given in Table 10.

Parameter Description
T The time interval
S Non-empty subset of the ordered pairs of OVC End Points associated by the OVC
COS ID The Class of Service Identifier
Pd A specific percentile for the Frame Delay Performance, Pd > 0
Pr A specific percentile for the Frame Delay Range Performance, Pr > 0
d One-way Frame Delay Performance Objective corresponding to Pd
d R
One-way Frame Delay Range Objective corresponding to Pr
One-way Mean Frame Delay Performance Objective
Table 10 One-way Frame Delay Performance Parameters

[R54] Given T, S, COS ID, Pd , and a one-way Frame Delay Performance objective d ,
expressed in time units, an SLS MUST define the one-way Frame Delay Per-
formance objective as met over the time interval T for the subset S if and only if
dT , S d or d T , S is Undefined.
MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

[R55] Given T, S, COS ID, Pr , and a One-way Frame Delay Range Performance objec-
tive d , expressed in time units, an SLS MUST define the one-way Frame Delay
R
Range Performance objective as met over the time interval T for the subset S if
and only if dTR , S dR or dTR , S is Undefined.

[R56] Given T, S, COS ID, a One-way Mean Frame Delay Performance objective ,
expressed in time units, the Frame Delay Performance MUST be defined by an
SLS as met over the time interval T if and only if T , S or T , S is Undefined.

Recall that if any of the above performance attributes are Undefined for time interval T and or-
dered pair i, j , then the performance for that ordered pair is to be excluded from calculations
on the performance of pairs in S.

[O3] For a Point-to-Point OVC, S MAY include one or both of the ordered pairs of
OVC End Points associated by the OVC.

[O4] For a Multipoint-to-Multipoint OVC, S MAY be any non-empty subset of the or-
dered pairs of OVC End Points associated by the OVC.

[R57] For a Rooted-Multipoint OVC, S MUST be a non-empty subset of the ordered


pairs of OVC End Points associated by the OVC such that each ordered pair in S
contains at least one Root OVC End Point.

7.2.16.2 Inter-Frame Delay Variation Performance for an OVC

Inter-Frame Delay Variation (IFDV) is the difference between the one-way delays of a pair of
selected frames. This definition is borrowed from RFC33938 where IP packet delay variation is
defined.

Let ai be the time of the arrival of the first bit of the ith frame at the ingress EI, then the two
frames i and j are selected according to the selection criterion:

{a j ai = and j > i}

Let ri be the time frame i is successfully received (last bit of the frame) at the egress EI, then the
difference in the delays encountered by frame i and frame j is given by d i d j . Define

d ij = d i d j = (ri ai ) (r j a j ) = (a j ai ) (rj ri )

8
C. Demichelis and P. Chimento, IP Packet Delay Variation Metric for IP Performance Metric (IPPM), RFC 3393,
November 2002.
MEF 26.1 The Metro Ethernet Forum 2012. 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.
External Network Network Interface (ENNI) Phase 2

With d j being the delay of the jth frame, a positive value for d i d j implies that the two frames
are closer together at the egress EI while a negative value implies that the two frames are further
apart at the egress EI. If either or both frames are lost or not delivered due to, for example, FCS
violation, then the value d ij is not defined and does not contribute to the evaluation of the Inter-
Frame Delay Variation.

Figure 9 shows a depiction of the different times that are related to Inter-Frame Delay Variation
Performance.
i i+1 j j+1

ai aj
Ingress

Time

ri rj
Egress

di dj

Figure 9 Inter-Frame Delay Variation Definition

[R58] For a given non-empty set of ordered pairs of OVC End Points, a time interval T,
and a given Class of Service Identifier, the SLS MUST define the Inter-Frame
Delay Variation Performance metric as follows:

Let the OVC End Points associated by the OVC be numbered from 1 to m. And
let S be a non-empty subset of the ordered pairs of OVC End Points associated by
the OVC. That is S { i, j | i = 1,..., m, j = 1,..., m, i j}, S .

~ i, j
Let d T be the Pv -percentile of the absolute value of the difference between
the Frame Delays of all Qualified Frame pairs whose difference in the arrival
times of the first bit of each frame in the pair at EI where the OVC End Point i is
located was exactly .

If there are no such pairs of frames for OVC End Point i and OVC End Point j,
~ i, j
then d T = Undefined .

Then the Inter-Frame Delay Variation Performance metric MUST be the maxi-
~ i, j ~ i, j
mum of the defined values d T for i, j S , unless all d T are Undefined
in which case the performance is Undefined.

This definition is in agreement with the IP packet delay variation definition given in RFC3393
where the delay variation is defined as the difference between the one-way delay of two packets
selected according to some selection function and are within a given interval [T1, T2].
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 36
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.
External Network Network Interface (ENNI) Phase 2

The choice of the value for can be related to the application timing information. As an ex-
ample for voice applications where voice frames are generated at regular intervals, may be
chosen to be few multiples of the inter-frame time.

To restate the definition mathematically, let the OVC End Points associated by the OVC be
numbered from 1 to m. And let S be a non-empty subset of the ordered pairs of the OVC End
Points associated by the OVC. That is

S { i, j | i = 1,..., m, j = 1,..., m, i j}, S .

Let
i, j i, j i, j i, j
VT = {d1 , d 2 ,..., d N i , j }

be the set of all absolute value of delay variations for all eligible pairs of Qualified Frames from
the EI where OVC End Point i is located to the EI where OVC End Point j is located where the
difference in the arrival times of the first bit of each Service Frame at the ingress EI was exactly
. Define

N
100 i , j
~ i, j
d T
min d | Pv
= I ( d , d k
i, j
) if N i , j 1
N i , j k =1

Undefined otherwise

where I (, d ) is an indicator function defined by

1 if d d
I (d , d ) .
0 otherwise

Then an Inter-Frame Delay Variation Performance metric for an OVC can be expressed as

~
dT , S =
{
max d~T i , j | i, j S and where N i , j 1
.
}
Undefined when all N i , j = 0 for all i, j S

The parameters of an Inter-Frame Delay Variation performance metric are given in Table 11.

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 37
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.
External Network Network Interface (ENNI) Phase 2

Parameter Description
T The time interval
S Non-empty subset of the ordered pairs of OVC End Points associated by the OVC
COS ID The Class of Service Identifier
Pv Inter-Frame Delay Variation Performance percentile, Pv > 0
The separation between frame pairs for which Inter-Frame Delay Variation Per-

formance is defined
(
d Inter-Frame Delay Variation Performance Objective

Table 11 Inter-Frame Delay Variation Parameters


(
[R59] Given T, S, COS ID, Pv , , and d , the Inter-Frame Delay Variation Perform-
ance objective MUST be defined by an SLS as met over the time interval T for
~ ( ~
the subset S if and only if dT , S d or d T , S is Undefined.

Recall that if the Inter-Frame Delay Variation is Undefined for time interval T and ordered pair
i, j , then the performance for that ordered pair is excluded from calculations on the perform-
ance of pairs in S.

[O5] For a Point-to-Point OVC, S MAY include one or both of the ordered pairs of
OVC End Points associated by the OVC.

[O6] For a Multipoint-to-Multipoint OVC, S MAY be any non-empty subset of the or-
dered pairs of OVC End Points associated by the OVC.

[R60] For a Rooted-Multipoint OVC, S MUST be a non-empty subset of the ordered


pairs of OVC End Points associated by the OVC such that each ordered pair in S
contains at least one Root OVC End Point.

7.2.16.3 One-way Frame Loss Ratio Performance for an OVC

[R61] For a given non-empty set of ordered pairs of OVC End Points, a time interval T,
and a given Class of Service Identifier, the SLS MUST define the One-way
Frame Loss Ratio Performance metric as follows:

Let the OVC End Points associated by the OVC be numbered from 1 to m. And
let S be a non-empty subset of the ordered pairs of OVC End Points associated by
the OVC. That is S { i, j | i = 1,..., m, j = 1,..., m, i j}, S .

i, j
Let I T denote the number of ingress Qualified Frames at the EI where OVC
End Point i is located that should have been delivered to the EI where OVC End
Point j is located according to the frame Delivery service attributes (see Sections

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 38
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.
External Network Network Interface (ENNI) Phase 2

7.2.17, 7.2.18, and 7.2.19). Each frame can be a Unicast, Multicast, or Broadcast
frame.
i, j
Let ET be the number of unique (not duplicate) egress frames where each frame
is the first egress frame at the EI where OVC End Point j is located that results
i, j
from a frame counted in I T .

I Ti , j ETi , j
100 if I Ti , j 1
=
i, j
Define FLRT IT
i, j .

Undefined otherwise

Then the One-way Frame Loss Ratio Performance metric MUST be defined as
{
max FLRTi , j | i, j S and where I Ti , j 1
FLRT , S = .
}
i, j
Undefined when all I T = 0 for all i, j S

The parameters of a One-way Frame Loss Ratio Performance metric are given in Table 12.

Parameter Description
T The time interval
S Non-empty subset of the ordered pairs of OVC End Points associated by the OVC
COS ID The Class of Service Identifier
L One-way Frame Loss Ratio Performance objective
Table 12 One-way Frame Loss Ratio Performance Parameters

[R62] Given T, S, COS ID, and a One-way Frame Loss Ratio Performance objective, the
One-way Frame Loss Performance objective MUST be defined by an SLS as met
over the time interval T for the subset S if and only if FLRT , S L or FLRT , S is
Undefined.

Recall that if the One-way Frame Loss Ratio Performance is Undefined for time interval T and
ordered pair i, j , then the performance for that ordered pair is to be excluded from calculations
on the performance of pairs in S.

[O7] For a Point-to-Point OVC, S MAY include one or both of the ordered pairs of
OVC End Points associated by the OVC.

[O8] For a Multipoint-to-Multipoint OVC, S MAY be any non-empty subset of the or-
dered pairs of OVC End Points associated by the OVC.

[R63] For a Rooted-Multipoint OVC, S MUST be a non-empty subset of the ordered


pairs of OVC End Points associated by the OVC such that each ordered pair in S
contains at least one Root OVC End Point.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 39
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.
External Network Network Interface (ENNI) Phase 2

7.2.16.4 One-way Availability Performance for an OVC

Availability Performance is the percentage of time within a specified time interval during which
frame loss is small. (The precise definition is presented in the following paragraphs.) As an ex-
ample, an Operator can define the availability performance to be measured over a month and the
value for the Availability Performance objective to be 99.9%. In a month with 30 days and no
Maintenance Interval (defined below) this objective will allow the service to be unavailable for
approximately 43 minutes out of the whole month.

Informally, Availability Performance is based on frame loss during a sequence of consecutive


small time intervals. When the previous sequence was defined as available, if the frame loss is
high for each small time interval in the current sequence, then the small time interval at the be-
ginning of the current sequence is defined as unavailable; otherwise it is defined as available. On
the other hand, when the previous sequence was defined as unavailable, if frame loss is low for
each small time interval in the current sequence, then the small time interval at the beginning of
the current sequence is defined as available; otherwise, it is defined as unavailable. The formal
definition follows.

For a time interval T, and a given Class of Service Identifier, Availability from OVC End Point i
to OVC End Point j is based on the following three parameters:

t , a time interval much smaller than T,

C, a loss ratio threshold which if equaled or exceeded suggests unavailability,

n , the number of consecutive small time intervals, t , over which to assess


availability.

Each t k in T is defined to be either Available or Unavailable and this is represented by


A i , j (t k ) where A i , j (t k ) = 1 means that t k is Available and A i , j (t k ) = 0 means that t k
is Unavailable.

The definition of A i , j (t k ) is based on the frame loss ratio function flr i , j (t k ) which is de-
fined as follows.
i, j
Let I t be the number of ingress frames that meet the following conditions:

The first bit of each frame arrives at the EI where OVC End Point i is located within
the time interval t ,

Each frame should be delivered to the EI where OVC End Point j is located according
to the frame delivery service attributes (see Sections 7.2.17, 7.2.18, and 7.2.19). Each
frame can be a Unicast, Multicast, or Broadcast frame,

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 40
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.
External Network Network Interface (ENNI) Phase 2

Each frame has the given Class of Service Identifier,

Each frame that is subject to an ingress Bandwidth Profile has an Ingress Bandwidth
Profile compliance of Green, and

Each frame that is not subject to an ingress Bandwidth Profile either has no color
identifier or a color identifier that corresponds to Green per the color indication re-
quirements of MEF 23 [10]
i, j
Let Et be the number of unique (not duplicate) egress frames where each frame is the first,
unerrored egress frame at the EI where OVC End Point j is located that results from a frame
i, j
counted in I t .

I it, j Eit, j
if I it, j 1
Then flr i , j (t ) = I it, j

.
0 otherwise

In the case of a Multipoint-to-Multipoint OVC or a Rooted-Multipoint OVC, the Service Pro-


vider and the Operator can agree to define flr i , j (t ) as

I~ i , j E i , j ~ i, j
t if I t 1
(t ) = I~ti , j
t
flr i , j

0 otherwise

~ i, j i, j
where I t = I t the number of frames discarded by the Service Provider, in order to con-
form to either the line rate of the EI where OVC End Point j is located or an egress Bandwidth
Profile (if one is used) at the EI where OVC End Point j is located. Such frame drops may occur
anywhere in the network, not just near the egress EI. One example of this could be where an
egress Bandwidth Profile is applied on a link within the network. Another example of this could
be where Green frames for this OVC and Class of Service Identifier that should be delivered to
the EI with OVC End Point j exceed the line rate on a link within the network, provided the line
rate of that link is greater than or equal to the line rate of the EI. Good traffic engineering princi-
ples would suggest dropping such excessive frames as close to the ingress as possible. This ad-
justment is meant to account for a focused overload of traffic sent to the EI where OVC End
Point j is located. The details of such an adjustment are beyond the scope of this document.

t 0 is the first short time interval agreed by Service Provider and the Operator at or after turning
up the association of OVC End Point i and OVC End Point j. A i , j (t k ) is defined in Figure 10
for k = 0,1,2,... .

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 41
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.
External Network Network Interface (ENNI) Phase 2

Begin

No A i , j ( tk 1 ) = 1 Yes
or k = 0
/ *Tran siti on to Avai labl e if /* Chec k ava ilab ili ty o f pre vio us in terval* / /* Tran sitio n t o Unavai lab le
n ext n in terval s have low if ne xt n in tervals h ave hig h
l oss*/ lo ss* /

flr i, j (tm ) C, flr i, j (tm ) > C ,


Ye s No
m = k , k +1,..., k + n 1 m = k , k + 1,..., k + n 1

No Ye s
A i , j ( tk ) = 1

A i, j (tk ) = 0

Figure 10 Flowchart Definition of A i , j (t k )

An alternative way of expressing A i , j (t k ) for k = 0 is

0 if flr i , j (t m ) > C for all m = 0,1,...n 1


A i , j (t0 ) =
1 otherwise

and for k = 1,2,... is

0 if A i,j (t k 1 ) = 1 and flr i , j (t m ) > C for all m = k , k + 1,..., k + n 1



A i, j (t k ) = 1 if A i,j (t k 1 ) = 0 and flr i , j (tm ) C for all m = k , k + 1,..., k + n 1 .
A (t ) otherwise
i,j k 1

In the event of a conflict between the above equations and Figure 10, the content of Figure 10 is
controlling.

The availability for t k is based on the frame loss ratio during the short interval and each of the
following n 1 short intervals and the availability of the previous short time interval. In other
words, a sliding window of width nt is used to define availability. This use of a sliding win-
dow is similar to that of ITU-T Y.1563. [23]

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 42
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.
External Network Network Interface (ENNI) Phase 2

Figure 11 presents an example of the determination of the availability for the small time intervals
with a sliding window of 10 small time intervals.
t 0
nt nt
1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 11 1 1 1 1 1 1 1

Time
A i , j ( tk ) = 1 A i, j (t k ) = 0 A i , j ( tk ) = 1

n = 10

flr i , j ( t m ) > C

flr i , j (t m ) C

Figure 11 Example of the Determination of A i , j (t k )

The Availability for a particular Class of Service Identifier from OVC End Point i to OVC End
Point j for a time interval T is based on the percentage of small time intervals that are Available.
However, the small time intervals that occur during a Maintenance Interval are not included in
the calculation of this percentage. A Maintenance Interval is a time interval agreed to by the Ser-
vice Provider and Operator during which the service may not perform well or at all. Examples of
a Maintenance Interval include:

A time interval during which the Operator may disable the service for network main-
tenance such as equipment replacement,

A time interval during which the Service Provider and Operator may perform joint
fault isolation testing, and

A time interval during which the Operator may change service features and making
the changes may disrupt the service.

Figure 12 shows an example of the elimination of short time intervals for a Maintenance Interval.

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 43
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.
External Network Network Interface (ENNI) Phase 2

Mai ntena nce Interval


t 0
nt nt
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
11 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Time
A i , j (tk ) = 1 A i , j ( tk ) = 0 A i, j (t k ) = 1

n = 10
flr i, j (tm )> C

flr i , j (t m ) C

X Excluded from Availability calculation for T

Figure 12 Example of the Impact of a Maintenance Interval

Let WT = {k | t k T and t k does not intersect a Maintenance Interval} and let WT represent the
number of elements in the set WT . Then the Availability for a particular Class of Service Identi-
fier from OVC End Point i to OVC End Point j for a time interval T, expressed as percentage, is
defined by

100
= WT k
i, j A i , j (t k ) if WT > 0
AT WT .
100 otherwise

Note that the definition of WT means that the boundaries of T and the boundaries of a Mainte-
nance Interval do not have to align with the boundary of a t k . A t k that straddles the bound-
ary between two Ts is excluded from the definition of Availability Performance for each interval
T. A t k that straddles the boundary of a Maintenance Interval is also excluded from the defini-
tion of Availability Performance.

Let the OVC End Points associated by the OVC be numbered 1,2,..., m and let S be a non-empty
subset of the ordered pairs of OVC End Points, i.e.,

S { i, j | i = 1,2,...m, j = 1,2,..., m, i j}, S .

Then the Availability for a particular Class of Service Identifier for the set S is defined by

ATS = min AT { i, j
| i, j S . }
The parameters of a One-Way Availability Performance Metric are given in Table 13.

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 44
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.
External Network Network Interface (ENNI) Phase 2

Parameter Description
T The time interval
S Non-empty subset of the ordered OVC End Point pairs
COS ID The Class of Service Identifier
t A time interval much smaller than T
C Unavailability frame loss ratio threshold
n Number of consecutive small time intervals for assessing availability
A Availability Performance Objective expressed as a percentage
Table 13 Availability Performance Parameters for an OVC

[R64] Given T, S, COS ID, t , C, n, and A , the SLS MUST define the Availability
Performance objective as being met if and only if ATS A .

[O9] For a Point-to-Point OVC, S MAY include one or both of the ordered pairs of
OVC End Points associated by the OVC.

[O10] For a Multipoint-to-Multipoint OVC, S MAY be any non-empty subset of the or-
dered pairs of OVC End Points associated the OVC.

[R65] For a Rooted-Multipoint OVC, S MUST be a non-empty subset of the ordered


pairs of OVC End Points associated by the OVC such that each ordered pair in S
contains at least one Root OVC End Point.

7.2.16.5 One-way Resiliency Performance for an OVC

This section defines attributes for the Resiliency performance of an ordered pair of OVC End
Points, <i,j>. The definitions depend on the availability status of each t to determine whether
performance counts toward objectives. The Resiliency attributes are similar to the definitions of
Severely Errored Seconds (SES) and Consecutive SES in Section 9 and Annex B (respectively)
of ITU-T Recommendation Y.1563 [23], when t = 1 second.

Figure 13 illustrates how the two resiliency attributes, counts of High Loss Intervals and counts
of Consecutive High Loss Intervals fit into the hierarchy of time and other attributes.

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 45
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.
External Network Network Interface (ENNI) Phase 2

SLS Interval, T

Maintenance Interval
Unavailable Time Available Time
Time

Non-High Loss
High Loss Intervals
Intervals

Consecutive Hi gh Loss Non-Consecutive


Intervals High Loss Intervals

Figure 13 Hierarchy of Time Showing the Resiliency Attributes

A High Loss Interval (HLI) is a small time interval (having the same duration as the interval, t ,
defined in Section 7.2.16.4) with a high frame loss ratio. When sufficient HLIs are adjacent, the
interval is designated a Consecutive High Loss Interval (CHLI). Section 7.2.16.4 defines termi-
nology for Availability. This section re-uses that terminology and defines the following terms:

H i, j
(t k ) : the high loss state of t k ,

 equal to 1 when flr i , j (t ) > C and A i , j (t k ) = 1 , equal to 0 otherwise,


including any t k that intersects a Maintenance Interval

i, j
LT : Count of High Loss Intervals over T

L : HLI Count Objective for S, T, and a given Class of Service Identifier

p: the minimum integer number of t s in the consecutive (sliding) window (with


0 < p < n) to qualify as a CHLI
i, j
BT : Count of p or more consecutive High Loss Intervals occurring in T

B : CHLI Count Objective for S, T, and a given Class of Service Identifier

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 46
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.
External Network Network Interface (ENNI) Phase 2

For every t in T that does not intersect a Maintenance Interval, the frame loss ratio and Avail-
ability state determine the value of H i , j (t k ) , either 1 or 0 as defined above.

[R66] For the SLS, the count of High Loss Intervals over T MUST be determined by
LT = H i , j (t ) .
i, j

tT

Note that the counter for H may be implemented in post processing (e.g., in a Management Sys-
tem), outside the Network Element that is monitoring the frame loss rate of each t . This could
be necessary to correlate with t s in a Maintenance Interval (MI).

When counting CHLI, the threshold p is used similarly to the variable n for the window size in
the Availability attribute, and p < n.

[R67] For the SLS, the Consecutive High Loss Intervals over T MUST be determined
according to the flow chart in Figure 14.

Begin

i, j
BT = 0 /*C oun ter = 0 at st art of T*/
k = min{in teger | tk T }

No
H i, j
( tm ) = 1, m = k p + 1,..., k /*p consecutive High Loss
intervals?*/
Yes
Yes
H i, j
(t ) = 1,
k p
/*Exist ing cons ecutive run?*/
No

i, j i, j
BT = BT +1 /*Increm ent counter*/

k = k +1

No Yes
End t k T

Figure 14 Determining and Counting Consecutive High Loss Intervals over T

Figure 15 shows an example that depicts the HLI and CHLI counting processes.

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 47
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.
External Network Network Interface (ENNI) Phase 2

t0 nt nt
A i , j ( tk ) 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 11 1 1 1 1 1 1 1

H i, j
(t k ) 0 0 0 1 1 1 1 0 1 1 1 0 1 0 0 0 10 0 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 0 10 1 0 0 0 0 Time

i,j 0 0 0 1 2 1
3 4 4 5 6 7 7 8 8 8 8 1
8 8 8 8 8 8 8 8 8 8 8 1
8 8 8 8 8 8 8 8 88 8 1
8 9 9 9 9 9
LT
i, j
BT 0 0 0 0 0 1 1 1 1 1 2 2 2 2 2 2 1
2 2 2 2 2 2 2 2 2 2 2 1
2 2 2 2 2 2 2 2 22 2 1
2 2 2 2 2 2

n = 10, p = 3
flr i , j ( t m ) > C

f lr i , j ( tm ) C

Figure 15 Example of Counting High Loss Intervals and Consecutive High Loss Intervals

Let the OVC End Points associated by the OVC be numbered 1,2,..., m and let S be a non-empty
subset of the ordered pairs of OVC End Points, i.e.,

S { i, j | i = 1,2,...m, j = 1,2,..., m, i j}, S .

Then the HLI and CHLI performance attributes for a particular Class of Service Identifier for the
set S and time interval T are defined by

LTS = max LT { i, j
}
| i, j S and BTS = max BT { i, j
| i, j S . }
The parameters of the One-Way Resiliency Performance metrics are given in Table 14.

Parameter Description
T The time interval
S Non-empty subset of the ordered OVC End Point pairs associated by the OVC
COS ID The Class of Service Identifier
t A time interval much smaller than T
C Unavailability frame loss ratio threshold
p Number of consecutive small time intervals for assessing CHLI where p < n
L HLI Performance Objective expressed as an integer
B Consecutive HLI Performance Objective expressed as an integer
Table 14 Resiliency Performance Parameters for an OVC

[R68] t MUST have the same value as t in Section 7.2.16.4.

[R69] C MUST have the same value as C in Section 7.2.16.4.

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 48
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.
External Network Network Interface (ENNI) Phase 2

[R70] Given T, S, COS ID, t , C, p, L , and B , the SLS MUST define the HLI Per-
formance objective as being met if and only if LST L , and the CHLI Perform-
ance objective as being met if and only if B S B . T

[O11] For a Point-to-Point OVC, S MAY include one or both of the ordered pairs of
OVC End Points associated by the OVC.

[O12] For a Multipoint-to-Multipoint OVC, S MAY be any non-empty subset of the or-
dered pairs of OVC End Points associated the OVC so long as it is non-empty.

[R71] For a Rooted-Multipoint OVC, S MUST be a non-empty subset of the ordered


pairs of OVC End Points associated by the OVC such that each ordered pair in S
contains at least one Root OVC End Point.

7.2.17 Unicast Frame Delivery

This attribute describes how ingress frames mapped to an OVC End Point at an External Inter-
face with a unicast destination MAC address are delivered to the other OVC End Points associ-
ated by the OVC9.

[R72] When the Unicast Frame Delivery is unconditional, all properly formatted in-
gress frames mapped to an OVC End Point at an External Interface with a unicast
destination MAC address MUST be delivered to all of the other OVC End Points
associated by the OVC provided [R33],[R34], [R35], and [R36] are satisfied.

[R73] When the Unicast Frame Delivery is conditional, a properly formatted ingress
frame mapped to an OVC End Point at an External Interface with a unicast desti-
nation MAC address is delivered to all or a subset of all of the other OVC End
Points associated by the OVC depending on certain conditions being met. When
conditional is in force, the conditions for delivery MUST be specified and such
conditions MUST satisfy [R33],[R34], [R35], and [R36].

An example of such a condition is that the destination MAC address is known by the Operator
MEN to be at the OVC End Point.

7.2.18 Multicast Frame Delivery

This attribute describes how ingress frames mapped to an OVC End Point at an External Inter-
face with a multicast destination MAC address are delivered to the other OVC End Points asso-
ciated by the OVC.9

[R74] When the Multicast Frame Delivery is unconditional, all properly formatted in-
gress frames mapped to an OVC End Point at an External Interface with a multi-

9
Assuming normal operation, e.g., valid FCS, no network congestion, and assuming that the frames comply with the
Bandwidth Profile if any.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 49
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.
External Network Network Interface (ENNI) Phase 2

cast destination MAC address MUST be delivered to all of the other End Points
associated by the OVC provided [R33],[R34], [R35], and [R36] are satisfied.

[R75] When the Multicast Frame Delivery is conditional, a properly formatted ingress
frame mapped to an OVC End Point at an External Interface with a multicast des-
tination MAC address is delivered to all or a subset of all of the other OVC End
Points associated by the OVC depending on certain conditions being met. When
conditional is in force, the conditions for delivery MUST be specified and such
conditions MUST satisfy [R33],[R34], [R35], and [R36].

7.2.19 Broadcast Frame Delivery

This attribute describes how ingress frames mapped to an OVC End Point at an External Inter-
face with the broadcast destination MAC address are delivered to the other End Points associated
by the OVC.9

[R76] When the Broadcast Frame Delivery is unconditional, all properly formatted
ingress frames mapped to an OVC End Point at an External Interface with the
broadcast destination MAC address MUST be delivered to all of the other OVC
End Points associated by the OVC provided [R33],[R34], [R35], and [R36] are
satisfied.

[R77] When the Broadcast Frame Delivery is conditional, a properly formatted in-
gress frame mapped to an OVC End Point at an External Interface with the broad-
cast destination MAC address is delivered to all or a subset of all of the other
OVC End Points associated by the OVC depending on certain conditions being
met. When conditional is in force, the conditions for delivery MUST be speci-
fied and such conditions MUST satisfy [R33],[R34], [R35], and [R36].

7.2.20 Layer 2 Control Protocol Tunneling

The Layer 2 Control Protocol Service Frame is described in MEF 10.2. [5]. An ENNI Frame
with a Destination MAC Address shown in Table 15 is defined to be a Layer 2 Control Protocol
ENNI Frame. Additional ways of denoting a Layer 2 Control Protocol ENNI Frame at a given
ENNI can be agreed to by the two Operators involved in the given ENNI.

MAC Addresses10
01-80-C2-00-00-00 through 01-80-C2-00-00-0F
01-80-C2-00-00-20 through 01-80-C2-00-00-2F
01-80-C2-00-00-10
Table 15 MAC Addresses that Identify a Layer 2 Control Protocol ENNI Frame

[R78] When a L2CP Service Frame or L2CP ENNI Frame is tunneled, the frame MUST
be delivered to all OVC End Points, other than the ingress OVC End Point, that

10
Hexadecimal canonical format
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 50
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.
External Network Network Interface (ENNI) Phase 2

are associated by the OVC and the format relationships detailed in Table 16
MUST be maintained.

Note that [R98] mandates that an ingress Service Frame that is not mapped to an existing OVC
End Point is not to be tunneled.

Note that [R19] mandates that an ingress ENNI Frame that is not mapped to an existing OVC
End Point is not to be tunneled. In view of [R20], this means that an ingress L2CP ENNI Frame
that does not have an S-Tag is not to be tunneled because the Operator has no information on
which OVC to use to tunnel the frame.

Ingress In- Egress Inter- Egress Frame Format11


terface face
UNI (L2CP UNI (L2CP Identical to the ingress frame.
Service Service
Frame) Frame)
UNI (L2CP ENNI (L2CP All fields from the Destination Address through the Payload of
Service ENNI Frame) the ingress Service Frame present and unchanged. S-Tag added
Frame) in after the Source Address.
ENNI (L2CP UNI (L2CP All fields from the Destination Address through the Payload ex-
ENNI Frame) Service cept the S-Tag of the ingress ENNI Frame present and un-
Frame) changed. No S-Tag is present.
ENNI (L2CP ENNI (L2CP All fields from the Destination Address through the Payload of
ENNI Frame) ENNI Frame) the ingress ENNI Frame present. The content of the S-Tag can
be changed while all other fields are unchanged.
Table 16 Format Relationships for Tunneled L2CP Service and ENNI Frames

7.3 OVC End Point per ENNI Service Attributes


There are service attributes for each instance of an OVC End Point at a given ENNI. These are
summarized in Table 17 and described in detail in the following sub-sections.

11
The Frame Check Sequence in the egress frame might need to be recalculated.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 51
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.
External Network Network Interface (ENNI) Phase 2

Attribute Name Summary Description Possible Values


OVC End Point An identifier for the OVC End Point A string that is unique across the
Identifier intended for management purposes Operator MEN

Trunk Identifiers For a Trunk OVC End Point, specifies <Root S-VLAN ID value, Leaf
the S-VLAN ID values used on the S-VLAN ID value> for Trunk
ENNI to distinguish frames originating OVC End Points; Not Applica-
at a Root UNI and frames originating at ble to Root or Leaf OVC End
a Leaf UNI Points
Class of Service The way that a Class of Service is de- The OVC associating the End
Identifiers termined for an ENNI Frame at each Point and non-overlapping sets
ENNI of values of the S-Tag Priority
Code Point
Ingress Bandwidth Ingress policing by the Operator MEN No or parameters as defined in
Profile Per OVC on all ingress ENNI Frames mapped to Section 7.6.1
End Point the OVC End Point
Ingress Bandwidth Ingress policing by the Operator MEN No or parameters as defined in
Profile Per ENNI on all ingress ENNI Frames with the Section 7.6.1
Class of Service Class of Service Identifier for the re-
Identifier ceiving Operator MEN
Egress Bandwidth Egress policing by the Operator MEN No or parameters as defined in
Profile Per End on all egress ENNI Frames mapped to Section 7.6.1
Point the OVC End Point
Egress Bandwidth Egress policing by the Operator MEN No or parameters as defined in
Profile Per ENNI on all egress ENNI Frames with the Section 7.6.1
Class of Service Class of Service Identifier for the re-
Identifier ceiving MEN
Table 17 OVC End Point per ENNI Service Attributes

7.3.1 OVC End Point Identifier

The OVC End Point Identifier is a string administered by the Operator that is used to identify an
OVC End Point within the Operator MEN. It is intended for management and control purposes.
The OVC End Point Identifier is not carried in any field in the ENNI Frame.

[R79] The OVC End Point Identifier MUST be unique among all such identifiers for
OVC End Points supported by the Operator MEN.

[R80] The OVC End Point Identifier MUST contain no more than 45 bytes.

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 52
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.
External Network Network Interface (ENNI) Phase 2

7.3.2 Trunk Identifiers

When the OVC End Point Role is Trunk, the End Point Map at the ENNI contains two S-VLAN
ID values that map to the OVC End Point as mandated by [R21]. One value is the Root S-
VLANI ID value and the other is the Leaf S-VLAN ID value.

[R81] The S-VLAN ID field of each ENNI Frame that is the result of an ingress Service
Frame at a Root UNI MUST contain the Root S-VLAN ID value.

[R82] The S-VLAN ID field of each ENNI Frame that is the result of an ingress Service
Frame at a Leaf UNI MUST contain the Leaf S-VLAN ID value.

The requirements regarding OVC End Points associated by a Rooted-Multipoint OVC are speci-
fied in Section 7.2.2.

7.3.3 Class of Service Identifiers

The delivery performance for an ingress ENNI Frame is dependent on the particular Class of
Service Identifier that applies to it. A Class of Service Identifier is a set of one or more S-Tag
PCP values.12 Each Class of Service Identifier indicates a single Class of Service Name as de-
fined in MEF 23.1[10]. The Class of Service Name that applies to an ingress S-Tagged ENNI
Frame that is mapped to the OVC End Point is the Class of Service identified by the Class of
Service Identifier that contains the S-Tag PCP value in the frame.

For example, the S-Tag PCP values 0, 1, 2, and 3 could constitute a Class of Service Identifier
that indicates the silver service while the S-Tag PCP values 4, 5, 6, and 7 could constitute a dif-
ferent Class of Service Identifier that indicates the gold service. In this example, an S-Tagged
ENNI Frame with S-Tag PCP value = 3 would be given the silver service.

Note that when multiple S-VLAN ID values are mapped to the same OVC End Point as with End
Point Map Bundling (see Section 7.1.7.2), the CoS Identifier for each ingress S-Tagged ENNI
Frame mapped to the given OVC End Point is independent of the S-VLAN ID value in the ENNI
Frame.

In general, at a given ENNI, each OVC End Point can have a different Class of Service Identifi-
ers attribute but the following requirements apply.

[R83] For each OVC End Point at an ENNI, each possible S-Tag PCP value MUST be
included in exactly one Class of Service Identifier.

[R83] means that the sets of S-Tag PCP values for the Class of Service Identifiers are disjoint
and their union equals the set of all S-Tag PCP values.

[O13] One of the Class of Service Identifiers MAY indicate 100% discard.

12
MEF 28 [20] introduces additional Class of Service Identifiers at the ENNI..
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 53
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.
External Network Network Interface (ENNI) Phase 2

[O13] means that the Operator MEN can discard all S-Tagged Frames whose S-Tag PCP value
belongs to one of the Class of Service Identifiers.

[R84] At a given ENNI, all OVC End Points associated by the same OVC MUST have
the same Class of Service Identifiers.

[R84] means that if an OVC associates multiple OVC End Points at an ENNI, the Class of Ser-
vice Identifier for an ENNI Frame at this ENNI is independent of the particular OVC End Point
to which it is mapped. Instead the Class of Service Identifier is based on the OVC and the S-Tag
PCP value.

[D3] An Operator MEN SHOULD support the use of different Class of Service Identi-
fiers attributes for OVC End Points at an ENNI that are associated by different
OVCs.

[D3] means that it is recommended that an Operator MEN be able to map a given S-Tag PCP
value to a different class of service for OVC End Points at an ENNI that are associated by differ-
ent OVCs.

Either the Drop Eligible Indicator (DEI) bit or the S-Tag PCP can be used to indicate the ENNI
Frame Color and the following requirements apply.

[R85] Color indication for each ENNI Frame MUST conform to requirements [R4] and
[R5] of MEF 23.1 [10].

[R86] If the S-Tag PCP field is used to indicate Color for the ENNI Frame, then the
Class of Service Identifiers MUST map S-Tag PCP values to L, M, and H as per
[R10] of MEF 23.1 [10].

[R87] If the DEI bit is used to indicate Color for the ENNI Frame, then the Class of Ser-
vice Identifiers MUST map S-Tag PCP values to L, M, and H as per [R10] of
MEF 23.1 [10].

7.3.3.1 Class of Service Identifiers for Egress ENNI Frames

An egress ENNI Frame does not specify a Class of Service Identifier for the Operator MEN from
which it is being transmitted. The S-Tag PCP value for an egress ENNI Frame only indicates the
Class of Service Identifier for the frame with respect to the Operator MEN that is receiving it.
Thus it is the responsibility of the transmitting Operator MEN to set the appropriate S-Tag PCP
value such that the frame is given the appropriate Class of Service by the receiving Operator
MEN. Section 10.8 presents an example of setting Class of Service Identifiers at an ENNI.

Note that MEF 23.1 [10] contains additional requirements on Classes of Service and S-Tag PCP
values.

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 54
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.
External Network Network Interface (ENNI) Phase 2

7.3.4 Ingress Bandwidth Profile per OVC End Point

The Ingress Bandwidth Profile per OVC End Point describes ingress policing by the Operator
MEN on all ingress ENNI Frames mapped to a given OVC End Point.

[R88] When the Ingress Bandwidth Profile per OVC End Point is in force for a given
OVC End Point, suitable parameters <CIR, CBS, EIR, EBS, CF, CM> as defined
in Section 7.6.1 MUST be specified and the algorithm of Section 7.6.1 MUST be
applied to all ingress ENNI Frames that are mapped to the given OVC End Point.

[R89] The Color Mode for the Bandwidth Profile Algorithm MUST be color-aware.

Figure 16 illustrates an example of the application of Ingress Bandwidth Profiles per OVC End
Point. In this example, OVC End Point1 could have CIR=15 Mbps, OVC End Point2 could have
CIR = 10 Mbps, and OVC End Point3 could have CIR = 20 Mbps.

OVC EP1 Bandwidth Profile per OVC EP1

ENNI OVC EP2 Bandwidth Profile per OVC EP2

OVC EP3 Bandwidth Profile per OVC EP3

Figure 16 Ingress Bandwidth Profile per OVC End Point

7.3.5 Egress Bandwidth Profile per OVC End Point

The Egress Bandwidth Profile per OVC End Point describes egress policing by the Operator on
all egress ENNI Frames that are mapped to a given OVC End Point.

[R90] When the Egress Bandwidth Profile per OVC End Point is in force for a given
OVC End Point, suitable parameters <CIR, CBS, EIR, EBS, CF, CM> as defined
in Section 7.6.1 MUST be specified and all egress ENNI Frames mapped to the
given OVC End Point MUST have the property defined in 7.6.3.

[R91] The Color Mode for the Bandwidth Profile Algorithm MUST be color-aware.

7.3.6 Ingress Bandwidth Profile per Class of Service Identifier

The Ingress Bandwidth Profile per Class of Service Identifier describes ingress policing by the
Operator MEN on all ingress ENNI Frames with a given Class of Service Identifier.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 55
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.
External Network Network Interface (ENNI) Phase 2

[R92] When the Ingress Bandwidth Profile per Class of Service Identifier is in force for
a given ENNI Class of Service Identifier, suitable parameters <CIR, CBS, EIR,
EBS, CF, CM> as defined in Section 7.6.1 MUST be specified and the algorithm
of Section 7.6.1 MUST be applied to all ingress ENNI Frames mapped to the
OVC End Point that have the given ENNI Class of Service Identifier.

[R93] The Bandwidth Profile Algorithm MUST be color-aware.

7.3.7 Egress Bandwidth Profile per Class of Service Identifier

The Egress Bandwidth Profile per Class of Service Identifier describes egress policing by the
Operator MEN on all egress ENNI Frames with a given Class of Service Identifier.

[R94] When the Egress Bandwidth Profile per Class of Service Identifier is in force for a
given ENNI Class of Service Identifier, suitable parameters <CIR, CBS, EIR,
EBS, CF, CM> as defined in Section 7.6.1 MUST be specified and all egress
ENNI Frames mapped to the OVC End Point with the given Class of Service
Identifier MUST have the property defined in Section 7.6.3.

[R95] The Color Mode for the Bandwidth Profile Algorithm MUST be color-aware.

7.4 UNI Attributes


These are identical to the UNI attributes specified in Sections 7.1, 7.2, 7.3, 7.4, 7.5, 7.6.1, 7.7,
7.8, 7.9, 7.10, 7.11.2.1, 7.11.3.1, and 7.12 of MEF 10.2 [5]. Note that the details of the UNI at-
tributes as agreed by the Service Provider and Operator may be different than the details of the
UNI attributes as agreed by the Service Provider and the Subscriber. See the discussion follow-
ing [R99].

7.5 OVC per UNI Service Attributes


There are service attributes for each instance of an OVC at a specific UNI. Since an OVC can
only associate one OVC End Point that it is at a UNI ([R28]), these service attributes can be
equivalently viewed as OVC End Point per UNI service attributes. These service attributes are
summarized in Table 18 and described in detail in the following sub-sections.

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 56
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.
External Network Network Interface (ENNI) Phase 2

Attribute Name Summary Description Possible Values


UNI OVC Identifier An identifier for the instance of A string formed by the concatena-
the OVC at a UNI intended for tion of the UNI Identifier and the
management purposes OVC Identifier

OVC End Point Map The CE-VLAN ID(s) that map to A list of one or more CE-VLAN
the OVC End Point at the UNI ID values
Class of Service Identi- The way that a Class of Service Non-overlapping sets of values of
fiers is determined for a frame at each C-Tag Priority Code Point values
UNI or DSCP values as specified in
Section 7.5.3
Ingress Bandwidth Pro- Ingress policing by the Operator No or parameters as defined in
file Per OVC End Point MEN on all ingress Service Section 7.11.1 in MEF 10.2 [5]
at a UNI Frames mapped to the OVC End
Point
Ingress Bandwidth Pro- Ingress policing by the Operator No or parameters as defined in
file Per Class of Ser- on all ingress Service Frames Section 7.11.1 in MEF 10.2 [5]
vice Identifier at a UNI with a given Class of Service
Identifier
Egress Bandwidth Pro- Egress policing by the Operator No or parameters as defined in
file Per OVC End Point on all egress Service Frames Section 7.11.1 in MEF 10.2 [5]
at a UNI mapped to the OVC End Point
Egress Bandwidth Pro- Egress policing by the Operator No or parameters as defined in
file Per Class of Ser- on all egress Service Frames Section 7.11.1 in MEF 10.2 [5]
vice Identifier at a UNI with a given Class of Service
Identifier
Table 18 OVC per UNI Service Attributes

7.5.1 UNI OVC Identifier

The OVC Identifier is a string that is used to identify an OVC at the UNI. It is intended for man-
agement and control purposes.

[R96] The UNI OVC Identifier MUST be the concatenation of the UNI Identifier and
the OVC Identifier.

7.5.2 OVC End Point Map at the UNI

A Service Frame is mapped to the OVC End Point via the CE-VLAN ID of the Service Frame as
defined in Section 7.6.1 of MEF 10.2. [5]

[R97] The OVC End Point at the UNI for a Service Frame MUST be identified by the
value of CE-VLAN ID of the Service Frame.

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 57
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.
External Network Network Interface (ENNI) Phase 2

[R98] An ingress Service Frame that is not mapped to an existing OVC End Point or
EVC at the UNI MUST be discarded.

[O14] Multiple CE-VLAN IDs MAY map to a single OVC End Point.

[R99] Each CE-VLAN ID MUST have one of the following mutually exclusive proper-
ties; 1) it maps to one OVC End Point, 2) it maps to one EVC that associates
UNIs within the Operator MEN, 3) it does not map to either such an EVC or an
OVC End Point.

Note that this document is describing the attributes as agreed to by the Service Provider and Op-
erator and therefore there is awareness of an OVC End Point at a UNI. MEF 10.2 [5] describes
attributes as agreed to by the Subscriber and Service Provider for which OVC End Points are in-
visible. From the Subscribers viewpoint, at a UNI, each CE-VLAN ID either maps to an EVC or
it does not map to an EVC.

[R100] When an OVC associating the OVC End Point to which the CE-VLAN ID for
untagged and priority tagged Service Frames is mapped does not have the CE-
VLAN ID Preservation attribute in force, egress Service Frames mapped to this
OVC End Point at the given UNI MUST be untagged.

7.5.3 Class of Service Identifiers

[R101] There MUST be three mutually exclusive ways to determine the Class of Service
Identifier from the content of a given Data Service Frame at UNI as described in
Sections 7.5.3.1, 7.5.3.2, and 7.5.3.3.

Note that Sections 7.5.3.1, 7.5.3.2, and 7.5.3.3 describe Class of Service Identifiers for ingress
Data Service Frames. A Data Service Frame is a Service Frame that is not carrying a Layer 2
Control Protocol. (See Section 6.5.1 of MEF 10.2[5].)

7.5.3.1 Class of Service Identifier Based on OVC End Point

[R102] When the Class of Service Identifier is based on OVC End Point, all ingress Data
Service Frames mapped to the same OVC End Point at the UNI MUST have the
same Class of Service Identifier.

As an example, consider OVC End Point 1 and OVC End Point 2 at a UNI. Data Service Frames
mapped to OVC End Point 1 have a first Class of Service Identifier that indicates gold service.
Data Service Frames mapped to OVC End Point 2 have a second Class of Service Identifier that
indicates silver service.

7.5.3.2 Class of Service Identifier Based on Priority Code Point Field

[R103] When the Class of Service Identifier is based on Priority Code Point field, the
Class of Service Identifier for an ingress Data Service Frame at the UNI MUST

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 58
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.
External Network Network Interface (ENNI) Phase 2

be determined by the OVC End Point and non-overlapping sets of values of the
PCP field in the C-Tag.

[R104] When the Class of Service Identifier is based on Priority Code Point field, if the
ingress frame does not contain a C-Tag, it MUST have the same Class of Service
Identifier as an ingress frame with Priority Code Point field = 0 in the C-Tag.

[R105] When the Class of Service Identifier is based on Priority Code Point field, the un-
ion of the sets of PCP field values MUST contain all of the possible values.

As an example, consider OVC End Point 1 and OVC End Point 2 at a UNI. C-Tagged Data Ser-
vice Frames mapped to OVC End Point 1 with Priority Code Point values 4, 5, 6, and 7 have a
first Class of Service Identifier that indicates gold service. C-Tagged Data Service Frames
mapped to OVC End Point 1 with Priority Code Point values 0 and 3 have a second Class of
Service Identifier that indicates silver service. C-Tagged Data Service Frames mapped to OVC
End Point 1 with Priority Code Point values 1 and 2 have a third Class of Service Identifier that
indicates Service Frame discard. Data Service Frames without a C-Tag mapped to OVC End
Point 1 also have the second Class of Service Identifier that indicates silver service. C-Tagged
Data Service Frames mapped to OVC End Point 2 with Priority Code Point value 7 have a fourth
Class of Service Identifier that indicates platinum service. All other Data Service Frames mapped
to OVC End Point 2 have a fifth Class of Service Identifier that indicates gold service.

7.5.3.3 Class of Service Identifier Based on DSCP

[R106] When the Class of Service Identifier is based on DSCP, the Class of Service Iden-
tifier for an ingress Data Service Frame at the UNI containing an IP packet
MUST be determined by the OVC End Point and non-overlapping sets of values
of the DSCP.

[R107] When the Class of Service Identifier is based on DSCP, the union of the sets of
DSCP values MUST contain all of the possible DSCP values.

[R108] When the Class of Service Identifier is based on DSCP, each ingress Data Service
Frame at the UNI not containing an IP packet and mapped to a given OVC End
Point MUST have the same Class of Service Identifier with a value agreed upon
by the Operator and the Service Provider.

7.5.4 Ingress Bandwidth Profile per OVC End Point at a UNI

The Ingress Bandwidth Profile per OVC End Point at a UNI describes ingress policing by the
Operator MEN on all ingress Service Frames mapped to a given OVC End Point at a UNI.

[R109] When the Ingress Bandwidth Profile per OVC End Point at a UNI is in force for a
given OVC End Point, suitable parameters <CIR, CBS, EIR, EBS, CF, CM> as de-
fined in Section 7.11.1 of [5] MUST be specified and the algorithm of Section
7.11.1 of [5] MUST be applied to all ingress Service Frames that are mapped to
the given OVC End Point.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 59
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.
External Network Network Interface (ENNI) Phase 2

Note that the algorithm and parameters defined in Section 7.6.1 are identical to the algorithm and
parameters defined in 7.11.1 of [5] with the exception of the value of the CM parameter. At the
ENNI, CM is mandated to be color-aware by requirements [R89], [R91], [R93], and [R95]
while color awareness is optional at the UNI.

7.5.5 Ingress Bandwidth Profile per Class of Service Identifier at a UNI

The Ingress Bandwidth Profile per Class of Service Identifier at a UNI describes ingress policing
by the Operator MEN on all ingress Service Frames with a given Class of Service Identifier at a
UNI.

[R110] When the Ingress Bandwidth Profile per Class of Service Identifier at a UNI is in
force for a given Class of Service Identifier, suitable parameters <CIR, CBS, EIR,
EBS, CF, CM> as defined in Section 7.11.1 of [5] MUST be specified and the al-
gorithm of Section 7.11.1 of [5] MUST be applied to all ingress Service Frames
with the given Class of Service Identifier.

Note that the algorithm and parameters defined in Section 7.6.1 are identical to the algorithm and
parameters defined in 7.11.1 of [5] with the exception of the value of the CM parameter. At the
ENNI, CM is mandated to be color-aware by requirements [R89], [R91], [R93], and [R95]
while color awareness is optional at the UNI.

7.5.6 Egress Bandwidth Profile per OVC End Point at a UNI

The Egress Bandwidth Profile per OVC End Point at a UNI describes egress policing by the Op-
erator MEN on all egress Service Frames mapped to a given OVC End Point at a UNI.

[R111] When the Egress Bandwidth Profile per OVC End Point at a UNI is in force for a
given OVC End Point, suitable parameters <CIR, CBS, EIR, EBS, CF, CM> as de-
fined in Section 7.11.1 of [5] MUST be specified and when the algorithm of Sec-
tion 7.11.1 of [5] using these parameters is applied to these egress Service
Frames, the result for each Service Frame MUST be to declare the Service Frame
either Green or Yellow.

Note that the algorithm and parameters defined in Section 7.6.1 are identical to the algorithm and
parameters defined in 7.11.1 of [5] with the exception of the value of the CM parameter. At the
ENNI, CM is mandated to be color-aware by requirements [R89], [R91], [R93], and [R95]
while color awareness is optional at the UNI.

7.5.7 Egress Bandwidth Profile per Class of Service Identifier at a UNI

The Egress Bandwidth Profile per Class of Service Identifier at a UNI describes egress policing
by the Operator MEN on all egress Service Frames with a given Class of Service Identifier at a
UNI.

[R112] When the Egress Bandwidth Profile per Class of Service Identifier at a UNI is in
force for a given Class of Service Identifier, suitable parameters <CIR, CBS, EIR,
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 60
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.
External Network Network Interface (ENNI) Phase 2

EBS, CF, CM> as defined in Section 7.11.1 of [5] MUST be specified and when
the algorithm of Section 7.11.1 of [5] using these parameters is applied to these
egress Service Frames, the result for each Service Frame MUST be to declare the
Service Frame either Green or Yellow.

Note that the algorithm and parameters defined in Section 7.6.1 are identical to the algorithm and
parameters defined in 7.11.1 of [5] with the exception of the value of the CM parameter. At the
ENNI, CM is mandated to be color-aware by requirements [R89], [R91], [R93], and [R95]
while this is not mandated at the UNI.

7.6 Bandwidth Profile at the ENNI


The Bandwidth Profile defines the set of traffic parameters applicable to a sequence of ENNI
Frames. Associated with the Bandwidth Profile is an algorithm to determine ENNI Frame com-
pliance with the specified parameters. In the case of an Ingress Bandwidth Profile, rate enforce-
ment is accomplished via the disposition of non-compliant ENNI Frames.

Many of the Bandwidth Profiles in this Technical Specification are based on the parameters and
algorithm described in Section 7.6.1.

7.6.1 Bandwidth Profile Parameters and Algorithm

The parameters comprising the Bandwidth Profile are:

Committed Information Rate (CIR) expressed as bits per second.

[R113] CIR MUST be 0.

Committed Burst Size (CBS) expressed as bytes.

[R114] When CIR > 0, CBS MUST be greater than or equal to the largest Maximum
Transmission Unit size allowed for the ENNI Frames that the Bandwidth Profile
applies to.

Excess Information Rate (EIR) expressed as bits per second.

[R115] EIR MUST be 0.

Excess Burst Size (EBS) expressed as bytes.

[R116] When EIR > 0, EBS MUST be greater than or equal to the largest Maximum
Transmission Unit size allowed for the ENNI Frames that the Bandwidth Profile
applies to.

Coupling Flag (CF) has value 0 or 1.

Color Mode (CM) has value color-blind or color-aware.


MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 61
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.
External Network Network Interface (ENNI) Phase 2

Each ENNI Frame is classified to determine which, if any, Bandwidth Profile is applicable to the
ENNI Frame. Operation of the Bandwidth Profile algorithm is governed by the six parameters,
<CIR, CBS, EIR, EBS, CF, CM>. The algorithm declares each ENNI Frame to be compliant or
non-compliant relative to the Bandwidth Profile. The level of compliance is expressed as one of
three colors, Green, Yellow, or Red.

The Bandwidth Profile algorithm is in color aware mode when each ENNI Frame already has a
level of compliance (i.e., a color) associated with it and that color is taken into account in deter-
mining the level of compliance by the Bandwidth Profile algorithm.

The Bandwidth Profile algorithm is shown in Figure 17. For this algorithm, Bc (t0 ) = CBS and
Be (t 0 ) = EBS . Bc (t ) and Be (t ) can be viewed as the number of bytes in the Committed and Ex-
cess token buckets respectively at a given time t.

[R117] For a sequence of ENNI Frames, {t j , l j }, j 0, t j +1 t j , with arrival times at the


reference point t j and lengths l j , the level of compliance color assigned to each
ENNI Frame MUST be defined according to the algorithm in Figure 17.

EN NI Frame of length l j arrives at time t j (j 1)

Bc t j = minCBS, Bc t j1 + t j t j1
CIR
( ) ( ) ( )
8
CIR
( ) ( )
O t j = max0, B c t j 1 + ( )
t j t j1 CBS
8
( ) ( ) EIR ( ) ( )
Be t j = minEBS, Be t j1 + t j t j 1 + CF O t j
8

[(CM = = color-blind) Y es Declare ENN I F rame G reen


O R (ENN I Frame == G reen)]
(
A ND l j Bc t j ( )) () ()
Bc t j = Bc t j l j

No

[(CM = = color-blind) Y es Declare EN NI Frame Yellow


OR (EN NI Frame != Red)]
(
A ND l j Be t j ( )) () ()
Be t j = Be t j l j

No

Declare EN NI Frame Red

Figure 17 The Bandwidth Profile Algorithm

The Coupling Flag CF is set to either 0 or 1. The choice of the value for CF has the effect of con-
trolling the volume of the ENNI Frames that are declared Yellow. When CF is set to 0, the long
term average bit rate of ENNI Frames that are declared Yellow is bounded by EIR. When CF is
set to 1, the long term average bit rate of ENNI Frames that are declared Yellow is bounded by
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 62
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.
External Network Network Interface (ENNI) Phase 2

CIR + EIR depending on volume of the offered ENNI Frames that are declared Green. In both
cases the burst size of the ENNI Frames that are declared Yellow is bounded by EBS.

7.6.2 Ingress Bandwidth Profiles Service Attributes

The Ingress Bandwidth Profile is used to regulate the amount of ingress traffic at a particular
ENNI. An Ingress Bandwidth Profile is defined for ingress ENNI Frames at the particular ENNI.
In other words, the sequence {t j , l j }, j 0, to which the algorithm of Section 7.6.1 is applied is
based on ingress ENNI Frames at an ENNI. There are two Ingress Bandwidth Profile attributes
as described in Sections 7.3.4, and 7.3.6.

7.6.2.1 Simultaneous Application of the Ingress Bandwidth Profile Application


Models

[O15] Multiple models of Ingress Bandwidth Profile application MAY exist simultane-
ously at an ENNI.

[R118] An ENNI MUST be configured such that at most a single Ingress Bandwidth Pro-
file applies to any given ingress ENNI Frame.

[R118] means that if there is a per OVC End Point Ingress Bandwidth Profile, then there cannot
be any per Class of Service Ingress Bandwidth Profiles on the OVC that associates the OVC End
Point.

7.6.2.2 ENNI Frame Disposition

The disposition of a given ENNI Frame with respect to delivery to an egress External Interface is
dependent on the ENNI Frames level of compliance to the Ingress Bandwidth Profile that is ap-
plied to it. This is called the Ingress Bandwidth Profile compliance level and it has three possible
values: Green, Yellow, or Red. Table 19 defines how the Ingress Bandwidth Profile compliance
is related to the disposition of the ENNI Frame. In this table, Not Applied identifies the case
where no Ingress Bandwidth Profile was applied to the ENNI Frame in question.

[R119] The disposition of each ENNI Frame for delivery to each egress External Inter-
face MUST be as described in Table 19.

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 63
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.
External Network Network Interface (ENNI) Phase 2

Ingress Bandwidth
ENNI Frame Disposition
Profile Compliance
Red Discard
Deliver to the egress External Interface according to the Service Attrib-
Yellow utes of the OVC associating the OVC End Point to which the frame is
mapped but SLS performance objectives do not apply.
Green Deliver to the egress External Interface according to the Service Attrib-
utes of the OVC associating the OVC End Point to which the frame is
Not Applied mapped and SLS performance objectives apply.
Table 19 ENNI Frame Disposition for Each Egress External Interface

The behavior described in Table 19 is based on the arrival of the ENNI Frame at its ingress
ENNI. It does not mandate or constrain in any way the implementation within the Operator
MEN.

7.6.3 Egress Bandwidth Profiles Service Attributes

An Egress Bandwidth Profile is used to regulate the amount of egress traffic at a particular
ENNI. An Egress Bandwidth Profile is defined for a particular ENNI and applies to all or a sub-
set of all egress ENNI Frames at the ENNI in question.

The reference point for an Egress Bandwidth Profile is the ENNI. An Egress Bandwidth Profile
describes arrival times and lengths of ENNI Frames that will be observed at the ENNI when an
Egress Bandwidth Profile is in operation in the Operator MEN. This description is given in terms
of what would happen if an observer at the ENNI applied the algorithm of Section 7.6.1 to egress
ENNI Frames. This observer would see traffic after it had been subject to rate limiting and/or
shaping in the Operator network and thus would have certain characteristics.

[R120] When a sequence of egress ENNI Frames with arrival times and lengths at the
ENNI, {t j , l j }, j 0 are subjected to an Egress Bandwidth Profile with parameters
<CIR, CBS, EIR, EBS, CF, CM>, the result of applying the algorithm of Section
7.6.1 to these frames MUST be to declare each ENNI Frame either Green or Yel-
low.

The implication is that the regulation of the ENNI Frames in the Operator MEN is such that all
ENNI Frames that would be determined to be Red by the observer are discarded before reaching
the egress ENNI. It is important to reiterate that this description of Egress Bandwidth Profile
does not mandate or constrain in any way the implementation in the Operator network.

There are two Egress Bandwidth Profile attributes (one per OVC End Point and one per CoS
Identifier) as described in Sections 7.3.5 and 7.3.7.

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 64
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.
External Network Network Interface (ENNI) Phase 2

7.6.3.1 Simultaneous Application of the Egress Bandwidth Profile Application


Models

[O16] Multiple models of Egress Bandwidth Profile application MAY exist simultane-
ously for an egress ENNI.

[R121] However, an egress ENNI Frame MUST be subject to at most one Egress Band-
width Profile.

[R121] means that if there is a per OVC End Point Egress Bandwidth Profile, then there cannot
be any per Class of Service Egress Bandwidth Profiles on the OVC that associates that OVC End
Point.

8 Link OAM Function Support for the ENNI


The ENNI has requirements for Link OAM support based on IEEE Std 802.3 [3].

[R122] For each physical link in the ENNI, an ENNI-N MUST be capable of supporting
Active DTE mode capabilities as specified in clause 57.2.9 of IEEE Std 802.3 [3].

[R123] For each physical link in the ENNI, an ENNI-N MUST be capable of supporting
Passive DTE mode capabilities as specified in clause 57.2.9 of IEEE Std 802.3
[3].

[R122] and [R123] do not mandate that Link OAM be run on a given link. [R122] and [R123]
mean that when the two Operators agree to support Link OAM on a given link, they will also
need to negotiate which sides of the ENNI will function in Active DTE mode with at least one
side functioning in Active DTE mode.

Operators using Link OAM on the ENNI could receive unwanted loopback messages which
could cause an interruption of traffic using the ENNI. The following two requirements are meant
to prevent this situation:

[D4] When Link OAM is enabled on an ENNI-N, the loopback capability SHOULD
be disabled.

[D5] When Link OAM is enabled on an ENNI-N, it SHOULD not advertise its loop-
back capability, as defined in Clause 57.2.11 of IEEE Std 802.3 [3], during the
discovery phase if Loopback is not enabled.

9 Maximum Transmission Unit Size


The Maximum Transmission Unit Size specifies the maximum frame length in bytes allowed at
an External Interface.

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 65
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.
External Network Network Interface (ENNI) Phase 2

The MTU is part of several attribute specifications. For example, the UNI (defined in [5]), the
EVC (defined in [5]), the ENNI (defined in 7.1.6), and the OVC (defined in 7.2.10) all have an
MTU attribute.

In order for an EVC to operate properly with respect to its MTU Size, the Service Provider has to
ensure that EVC MTU Size is less than or equal to the MTU Size of each OVC used to imple-
ment the EVC.

When provisioning a new ENNI or adding an EVC using an existing ENNI, the ENNI Operators
and the Service Provider for the new EVC need to agree on MTU sizes which comply with the
following requirements:

[D6] The ENNI MTU size SHOULD be greater or equal to the MTU size of :

Each EVC MTU size crossing the ENNI plus 4 bytes (to accommodate the
potential addition, at the ENNI, of an S-TAG), and

Each OVC associating an OVC End Point at this ENNI.

[R124] The OVC MTU size MUST be greater or equal to the EVC MTU size of each
EVC supported by this OVC plus 4 bytes (to accommodate the potential addition,
at the ENNI, of an S-TAG).

10 Appendix A: Examples
This section presents several examples of the use of the Operator Services Attributes described in
Section 7 to achieve UNI to UNI Ethernet Services. The first sub-section establishes the conven-
tions and notation used in the examples. The remaining sub-sections present the examples.

10.1 Notation and Conventions


A number of abbreviations are used in the figures to avoid clutter. These are shown in Table 20.

Abbreviation Object
C-VID C-VLAN ID value
S-VID S-VLAN ID value
OEP OVC End Point Identifier value
Table 20 Abbreviations Used in the Examples

In addition, the figures accompanying the examples use the icons as shown in Figure 18.

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 66
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.
External Network Network Interface (ENNI) Phase 2

Operator MEN
1 Root OVC End Point
ENNI
UNI
OVC

Figure 18 Key to the Icons Used in the Examples

In the examples, the Service Provider is not explicitly shown. The Service Provider could be any
of the Operators or some other organization. The examples are valid no matter who is the Service
Provider.

10.2 Example 1: Ethernet Virtual Private Lines to a Hub Location


In this example, four Operator MENs are used by the Service Provider to provide three EVCs,
each from a branch location to a hub location. Figure 19 shows the EVCs for this example as
perceived by the Subscriber. UNI 1 is the hub location and the other UNIs are the branch loca-
tions. The CE-VLAN ID/EVC Maps as agreed to by the Subscriber and the Service Provider for
each UNI are included in the figure. From these maps it can be seen that none of the EVCs have
CE-VLAN ID Preservation in force as defined in MEF 10.2. [5]

UNI 2

EVC 1-2 CE-VLAN ID EVC


33 EVC 1-2

UNI 1

CE-VLAN ID EVC
EVC 1-3
45 EVC 1-2
765 EVC 1-3
37 EVC 1-4 UNI 3

EVC 1-4

CE-VLAN ID EVC

UNI 4 28 EVC 1-3

CE-VLAN ID EVC
33 EVC 1-4

Figure 19 EVCs to the Hub Location

Figure 20 shows Operator Services Attributes values that instantiate the EVPLs for this example
using four Operator MENs. The various ENNI End Point Maps are shown in the figure. To see
how this configuration works, consider a Service Frame that ingresses at UNI 1 and is destined
for UNI 4 via EVC 1-4. Such a Service Frame will have a CE-VLAN ID value = 37. Operator A
maps this frame to OVC End Point 11 and thus transmits a corresponding ENNI Frame with S-
VLAN ID value = 1024 across the ENNI with Operator D. Operator D maps this ENNI Frame to
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 67
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.
External Network Network Interface (ENNI) Phase 2

OVC End Point 13 and thus transmits a corresponding ENNI Frame with S-VLAN ID value =
2022 across the ENNI with Operator C. Operator C maps this ENNI Frame to OVC End Point 15
and thus transmits a corresponding Service Frame with CE-VLAN ID value = 33 across UNI 4.
A similar sequence of events ensues for the other direction for EVC 1-4 and for the other EVCs
in this example.

S-VID O EP B
114 4 UNI 2

S-VID O EP 5
114 3

4
UNI 1
A 3
C-VID O EP
1 33 5
2 C-VID O EP
11 28 10
6
12 7 D C
UNI 3
13
C-VID O EP 9
8
45 1 10
765 2 14 15
37 11
S-VID O EP
1023 6
16 C-VID O EP
1024 12 UNI 4 33 16
S-VID O EP S-VID O EP S-VID O EP
1023 7 2023 8 2023 9
1024 13 2022 14 2022 15

Figure 20 Details of the Operator Services Attributes for Example 1

This example shows that EVC 1-4 is supported by three OVCs, one in each Operator MEN. The
way that these OVCs are connected at each ENNI is via the End Point Maps on each side of
the ENNI. By using S-VLAN ID value = 1024 to map to OVC End Point 12 in the Operator A
MEN and also to map to OVC End Point 13 in the Operator D MEN, the appropriate OVCs in
each Operator MEN are connected.

10.3 Example 2: Ethernet Private LAN


In this example, the Service Provider provides a single Ethernet Private LAN connecting four
UNIs. Figure 21 shows the EVC for this example as perceived by the Subscriber. Note that
EPLAN requires that the EVC have CE-VLAN ID Preservation and CE-CoS Preservation in
force as per MEF 6.1. [9] Note also that the CE-VLAN ID/EVC Map at each UNI is All to One
as prescribed by [9].

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 68
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.
External Network Network Interface (ENNI) Phase 2

UNI 2

EVC 1-2-3-4 CE-VLAN ID EVC


All EVC 1-2-3-4

UNI 1

CE-VLAN ID EVC
All EVC 1-2-3-4

UNI 3

CE-VLAN ID EVC

UNI 4 All EVC 1-2-3-4

CE-VLAN ID EVC
All EVC 1-2-3-4

Figure 21 EPLAN Connecting Four UNIs

Figure 22 shows Operator Services Attributes values that instantiate the EPLAN for this example
using four Operator MENs. In order to support All to One Bundling, the OVC End Point Map at
each UNI maps all Service Frames to the OVC End Point, e.g., OVC End Point 5 at UNI 2. Each
OVC End Point Map at each ENNI maps to the OVC End Point with one S-VLAN ID value as
was the case with Example 1.

S-VID O EP B
114 4 UNI 2 Each OVC has CE-VLAN ID
Preservation and CE-CoS
S-VID O EP 5 Preservation in force.
114 3

A 4
UNI 1 3
C-VID O EP
1 All 5
C-VID O EP
All 10
6
7 D C
UNI 3

C-VID O EP
All 1 8 9 10

S-VID O EP
1023 6 16 C-VID O EP
UNI 4 All 16
S-VID O EP S-VID O EP S-VID O EP
1023 7 2023 8 2023 9

Figure 22 Details of the Operator Services Attributes for Example 2

The OVC in the Operator MEN A has three OVC End Points as does the OVC in the Operator
MEN C. Consequently, if MAC address learning is done in the Operator MEN A, a unicast Ser-
vice Frame between UNI 1 and UNI 2 need not enter the Operator D and Operator C MENs.

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 69
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.
External Network Network Interface (ENNI) Phase 2

Similarly, if MAC address learning is done in Operator MEN C, a unicast Service Frame be-
tween UNI 3 and UNI 4 need not leave the Operator C MEN.

Each OVC has CE-VLAN ID Preservation and CE-CoS Preservation in force as specified in Sec-
tion 7.2.11 and Section 7.2.12. As an example to see how this works, consider an ingress Service
Frame at UNI 1 that has a C-Tag and is destined for UNI 4.

The resulting ENNI Frame at the ENNI between Operator MENs A and D will
have both an S-Tag (with S-VLAN ID value = 1023) and a C-Tag and that C-Tag
will have the same C-VLAN ID value and the same C-Tag PCP value as the
original C-Tag of the Service Frame.

The corresponding ENNI Frame at the ENNI between Operator MENs D and C
will have both an S-Tag (with S-VLAN ID value = 2023) and a C-Tag and that C-
Tag will have the same C-VLAN ID value and the same C-Tag PCP value as the
original C-Tag of the ENNI Frame at the ENNI between Operator MENs A and
D.

Finally, the corresponding egress Service Frame at UNI 4 will have just a C-Tag
and that C-Tag will have the same C-VLAN ID value and the same C-Tag PCP
value as the original C-Tag of the ENNI Frame at the ENNI between Operator
MENs C and D.

The result is that the C-VLAN ID values and C-Tag PCP values are the same for both ingress
and egress Service Frame. Using the tables in Section 7.2.11, it can be seen that an untagged in-
gress Service Frame results in an untagged egress Service Frame. (Note that MEF 10.2 [5] speci-
fies that CE-CoS Preservation does not apply to untagged Service Frames.) Consequently, the
EVC has CE-VLAN ID Preservation and CE-CoS Preservation in force.

10.4 Example 3: Hairpin Switching


Figure 23 shows an example of the use of OVC End Points for Hairpin Switching. In this exam-
ple, there is one multipoint EVC that associates UNI Aa, UNI Ab, and UNI B. Operator A has
two OVCs. One associates the OVC End Point A4 at UNI Aa and the OVC End Point A1 at the
ENNI. The other OVC associates the OVC End Point A3 at UNI Ab and the OVC End Point A2
at the ENNI. Operator B has one OVC that associates the OVC End Points B1 and B2 at the
ENNI and the OVC End Point B3 at UNI B. At the ENNI, the End Point Maps, as described in
Section 7.1.7, are such that ENNI frames mapped to A1 by Operator A are mapped to B1 by Op-
erator B and similarly for A2 and B2. With this configuration, a Service Frame sent from UNI
Aa to UNI Ab will pass through the Operator B MEN where it will be hairpin switched from B1
to B2. And a similar path will be followed by a Service Frame sent from UNI Ab to UNI Aa.

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 70
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.
External Network Network Interface (ENNI) Phase 2

UNI Aa

A4
B
UNI B

A1 B1
A B3
A2 B2

A3

UNI Ab
S-VID O EP
S-VID O EP 2023 B1
2023 A1 1028 B2
1028 A2

Figure 23 Example of Hairpin Switching

Note that in this example, two OVCs are used in Operator MEN A to implement the single EVC.

10.5 Example 4: Data Loop at an ENNI with Hairpin Switching


The improper use of Hairpin Switching can lead to data loops at an ENNI. An example of such a
improper configuration is shown in Figure 24. In this example, a broadcast frame will pass back
and forth across the ENNI following the loop formed by the OVC End Points and Hairpin
Switching.
UNI Aa

A4
B
UNI B

A1 B1
A B3
A2 B2

A3

UNI Ab
S-VID O EP
S-VID O EP 2023 B1
2023 A1 1028 B2
1028 A2

Figure 24 Example of a Data Loop with Hairpin Switching

10.6 Example 5: Ethernet Private LAN with Hairpin Switching


In this example, the Service Provider provides a single Ethernet Private LAN connecting four
UNIs just as was done in the example of Section 10.3. Figure 21 shows the EVC for this example
as perceived by the Subscriber.

Figure 25 shows Operator Services Attributes values that instantiate the EPLAN for this example
using four Operator MENs. As in the example of Section 10.3, the OVC End Point Map at each
UNI maps all Service Frames to the OVC End Point and each OVC has CE-VLAN ID Preserva-
tion and CE-CoS Preservation in force as specified in Section 7.2.11 and Section 7.2.12.

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 71
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.
External Network Network Interface (ENNI) Phase 2

S-VID O EP B
114 4 UNI 2 Each OVC has CE-VLAN ID
Preservation and CE-CoS
S-VID O EP 5 Preservation in force.
114 3

A 4
UNI 1 3
C-VID O EP
1 All 5
C-VID O EP
All 10
6
12 7 D C
UNI 3
13
C-VID O EP
All 1 8 9 10
14 15

S-VID O EP
1023 6
16 C-VID O EP
1024 12 UNI 4 All 16
S-VID O EP S-VID O EP S-VID O EP
1023 7 2023 8 2023 9
1024 13 2022 14 2022 15

Figure 25 Details of the Operator Services Attributes for Example 3

The key difference between this example and the example of Section 10.3 is the use of Hairpin
Switching in Operator MEN A. The OVC in Operator MEN A has two OVC End Points, 6 and
12, at the ENNI between Operator MENs A and D. In addition, Operator MENs C and D each
have two OVCs in support of the EPLAN. As a result, traffic from UNI 3 to UNI 4 will pass
through Operator MENs A, C, and D and would follow the path of OVC End Points {10, 9, 8, 7,
6, 12, 13, 14, 15, 16}.

10.7 Example 6: End Point Map Bundling


Consider the EVCs to a hub location in Figure 19. Figure 26 shows the details of the Operator
Services Attributes when Bundling is used in Operator MEN D.

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 72
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.
External Network Network Interface (ENNI) Phase 2

S-VID O EP B
114 4 UNI 2

S-VID O EP 5 The OVC in Operator MEN


114 3 D has S-VLAN ID
Preservation = Yes.
4
UNI 1
A 3
C-VID O EP
1 33 5
2 C-VID O EP
11 28 10
6
12 D C
7 UNI 3

C-VID O EP 9
45 1 8 10
765 2 15
37 11
S-VID O EP
1023 6 16 C-VID O EP
1024 12 UNI 4 33 16
S-VID O EP S-VID O EP S-VID O EP
1023 7 1023 8 1023 9
1024 7 1024 8 1024 15
Bundling Bundling

Figure 26 Example of Using End Point Map Bundling

Figure 26 differs from Figure 20 as follows:

There is only one OVC in Operator MEN D. Thus, this is a case where more than
one EVC is supported by an OVC.

The End Point Maps in the Operator MEN D have bundling with S-VLAN ID
values 1023 and 1024 both mapped to a single OVC End Point at each ENNI.

The OVC in Operator MEN D has S-VLAN ID Preservation = Yes.

The End Point Map in Operator MEN C is changed to map each S-VLAN ID
value 1023 and 1024 to an OVC End Point.

10.8 Example 7: CoS Identifiers at the ENNI


This example concerns the setting of the Class of Service Identifier in each ENNI Frame at an
ENNI. Two scenarios are considered. The first scenario is when both Operator MENs conform to
MEF 23.1 [10]. The second scenario is when MEF 23.1 is not conformed to by the Operator
MENs.

In the first scenario, both Operator MENs abide by Table 4 in MEF 23.1 [10] which means that
they would use the CoS Identifiers shown in Table 21. In this case, H in Operator MEN A would
map to H in Operator MEN B and vice versa. In the same way, M would map to M and L would
map to L. The result is that ENNI Frames would have the CoS Identifiers shown in Figure 27
where the arrows indicate the direction of flow at the ENNI.

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 73
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.
External Network Network Interface (ENNI) Phase 2

CoS Label CoS Identifier (S-Tag PCP Value)


H 5
M 3
L 1
Table 21 MEF 23.1 CoS Identifiers

A B

S-Tag
CoS in A PCP Value CoS in B

5
H 5 H

3
M 3 M

1
L 1 L

Figure 27 CoS Identifiers for MEF 23.1 Conforming Operator MENs

In the second scenario, suppose that the Operator MENs had CoS Names and CoS Identifiers as
shown in Table 22.

Operator MEN A Operator MEN B


CoS Name CoS ID (S-Tag PCP Value) CoS Nmae CoS ID (S-Tag PCP Value)
Plus 6 Rock 6
Square 4 Paper 3
Heart 2 Scissors 1
Coal 1
Table 22 CoS Identifiers for Scenario Two

In this case, the mappings between the CoS instances in each Operator MEN will determine the
use of CoS Identifiers at the ENNI. To see this, suppose that Square and Paper are mapped to-
gether. Then the ENNI Frames for Square and Paper would have the CoS Identifiers shown in
Figure 28. Because the CoS Identifier is set according to the CoS of the receiving Operator
MEN, the CoS Identifier in the ENNI Frame is different and depends on the direction of the
frame flow.

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 74
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.
External Network Network Interface (ENNI) Phase 2

A B

S-Tag
CoS in A PCP Value CoS in B

3
Square 4 Paper

Figure 28 CoS Identifiers for Square and Paper in Scenario Two

11 Appendix B: Rooted-Multipoint Examples


The forwarding behavior of a Rooted-Multipoint (RMP) EVC is specified in MEF10.2 [9] as any
ingress Service Frames at a Root UNI may be forwarded to any other Root UNIs or Leaf UNIs of
the same EVC, and any ingress Service Frames at a Leaf UNI may be forwarded to any Root
UNIs of the same EVC. This forwarding behavior can be extended to a RMP EVC that spans one
or more ENNIs by introducing a RMP OVC and OVC End Point Role designations of Root,
Leaf, and Trunk.

The forwarding behavior of a Rooted-Multipoint EVC requires being able to determine whether
any given frame originated as an ingress Service Frame at a Root UNI or as an ingress Service
Frame at a Leaf UNI. The method of preserving this information for each frame within an Opera-
tor MEN depends upon the technology used within the MEN and is beyond the scope of this
document. Preserving this information at an ENNI can require using two S-VLAN ID values: the
Root S-VLAN ID value identifies frames that originated at a Root UNI, and the Leaf S-VLAN
ID value identifies frames that originated at a Leaf UNI. When a Rooted-Multipoint OVC asso-
ciates a Trunk OVC End Point at an ENNI, both S-VLAN IDs are mapped to the Trunk OVC
End Point by the End Point Map.

The examples in this section illustrate the use of these concepts to instantiate a Rooted-
Multipoint OVC across multiple Operator MENs.

11.1 Example Using Trunk OVC End Points


Figure 29 shows a Rooted-Multipoint connecting 6 UNIs as seen by the Subscriber.

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 75
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.
External Network Network Interface (ENNI) Phase 2

Root UNI S Leaf UNI W Root UNI T

Leaf UNI X Leaf UNI Y Leaf UNI Z

Figure 29 Subscriber View of the Rooted-Multipoint EVC

Figure 30 shows an example of supporting this Rooted-Multipoint EVC using Trunk OVC End
Points at the ENNIs that connect three Operator MENs. Note that each Operator MEN can re-
ceive ENNI Frames that originated at a Root UNI or a Leaf UNI. The use of Trunk OVC End
Points and Trunk Identifiers at the ENNIs allows the Operator MEN to determine the type of in-
gress UNI and thus properly forward each ENNI Frame. Figure 31 shows example mappings us-
ing Root and Leaf S-VLAN ID values.

Root UNI S Leaf UNI W Root UNI T

MEN A MEN B MEN C

Leaf UNI X Leaf UNI Y Leaf UNI Z

Rooted-Multipoint OVC Path for frames


originating at a Root UNI
Trunk OVC End Point Path for frames
originating at a Leaf UNI
Root OVC End Point UNI

Leaf OVC End Point ENNI

Figure 30 Rooted-Multipoint EVC using Trunk OVC End Points


MEN A MEN B
OVC End Point Root S-VLAN Leaf S-VLAN OVC End Point Root S-VLAN Leaf S-VLAN
Identifier ID value ID value Identifier ID value ID value
PAIX A32 1065 1066 PAIX B12 1065 1066

MEN B MEN C
OVC End Point Root S-VLAN Leaf S-VLAN OVC End Point Root S-VLAN Leaf S-VLAN
Identifier ID value ID value Identifier ID value ID value
ChinaBasin B123 56 57 China Basin C19 56 57

Figure 31 Example End Point Maps

11.2 Example Using a Rooted-Multipoint OVC in One Operator MEN


Figure 32 shows an example of supporting the Rooted-Multipoint EVC in Figure 29 using a
Rooted-Multipoint OVC in just Operator MEN A along with Hairpin Switching in Operator
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 76
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.
External Network Network Interface (ENNI) Phase 2

MEN A. The Hairpin Switching has the effect of including the UNIs in Operator MEN B and
Operator MEN C in the Rooted-Multipoint EVC. Note that Operator B and Operator C see only
Point-to-Point OVCs with Root OVC End Points at the UNIs and ENNIs. However, the Sub-
scriber and Service Provider recognize the role of each UNI in Operator MEN B and Operator
MEN C as either a Root UNI or a Leaf UNI.
Root UNI S Leaf UNI W Root UNI T

MEN B MEN C
MEN A

Leaf UNI X Leaf UNI Y Leaf UNI Z

Path for frames


Rooted-Multipoint OVC originating at a Root UNI
Path for frames
Trunk OVC End Point originating at a Leaf UNI
UNI
Root OVC End Point
ENNI
Leaf OVC End Point Point-to-Point OVC

Figure 32 Rooted-Multipoint EVC with a Rooted-Multipoint OVC in One Operator MEN

11.3 Example with All Root UNIs in One Operator MEN


Trunk OVC End Points are not always necessary to implement a Rooted-Multipoint EVC. Con-
sider the Rooted-Multipoint EVC shown in Figure 33. In this example, Root UNI S and Root
UNI T happen to be in Operator MEN A.

Root UNI S Leaf UNI W


Root UNI T

Leaf UNI X Leaf UNI Y Leaf UNI Z

Figure 33 Subscriber View of the Rooted-Multipoint EVC with all Root UNIs in one Op-
erator MEN

Figure 34 shows an example of supporting the Rooted-Multipoint EVC of Figure 33 using just
Root and Leaf OVC End Points. All Root UNIs are in the Operator MEN A, and the other Op-
erator MENs have only Leaf UNIs. At each ENNI, all ENNI Frames going left to right originated
at a Root UNI and all ENNI Frames going right to left originated at a Leaf UNI. This allows the
use of Root and Leaf OVC End Points at the ENNIs, and a single S-VLAN ID value at the EN-
NIs. For example at ENNI AB, MEN A maps this single S-VLAN ID value to its Leaf OVC End
Point while MEN B maps this same S-VLAN ID value to its Root OVC End Point.

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 77
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.
External Network Network Interface (ENNI) Phase 2

In this figure, MEN A has a Leaf OVC End Point at ENNI AB because any ingress ENNI Frame
mapped to this OVC End Point is the result of an ingress Service Frame at a Leaf UNI. For the
same reason, MEN B has a Leaf OVC End Point at ENNI BC. MEN B has a Root OVC End
Point at ENNI AB because any ingress ENNI Frame mapped to this OVC End Point is the result
of an ingress Service Frame at a Root UNI. For the same reason, MEN C has Root OVC End
Point at ENNI BC.
Root UNI S Leaf UNI W

Root UNI T
MEN A MEN B MEN C

ENNI AB ENNI BC

Leaf UNI X Leaf UNI Y Leaf UNI Z

Rooted-Multipoint OVC Path for frames


originating at a Root UNI
Trunk OVC End Point Path for frames
originating at a Leaf UNI
Root OVC End Point UNI

Leaf OVC End Point ENNI

Figure 34 Rooted-Multipoint EVC with all Root UNIs in one Operator MEN

11.4 Example Using a Bundled OVC


Figure 35 shows a Rooted-Multipoint EVC connecting 4 UNIs as seen by the Subscriber.

Root UNI S Root UNI T

Leaf UNI X Leaf UNI Z

Figure 35 Subscriber View of the Rooted-Multipoint EVC

Figure 36 shows an example of supporting this Rooted-Multipoint EVC using Trunk OVC End
Points at the ENNIs in Operator MEN A and Operator MEN C. Operator MEN B uses a Point-
to-Point Bundled OVC in this example. At each ENNI, MEN B maps the two Trunk Identifiers
values to the OVC End Point. In this case, Operator MEN B need not be aware of which S-
VLAN ID value represents frames originated at a Root UNI and which S-VLAN ID value repre-
sents frame originated at a Leaf UNI. Instead, MEN B simply passes the S-VLAN ID values un-
changed between the two ENNIs as mandated by [R23]. MEN A and MEN C need to understand
the significance of each Trunk Identifiers value.

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 78
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.
External Network Network Interface (ENNI) Phase 2

Root UNI S Root UNI T

MEN A MEN B MEN C

Leaf UNI X Leaf UNI Z

Path for frames


Rooted-Multipoint OVC originating at a Root UNI
Path for frames
Trunk OVC End Point originating at a Leaf UNI
UNI
Root OVC End Point
ENNI
Leaf OVC End Point
Bundled OVC (S-VLAN ID
Preservation = Yes)

Figure 36 Rooted-Multipoint EVC using a Bundled OVC

11.5 Example Using Hairpin Switching with Trunk OVC End Points
Figure 37 shows a Rooted-Multipoint EVC with 6 UNIs as seen by the Subscriber.

Root UNI S Root UNI T Leaf UNI Y

Leaf UNI X Leaf UNI Z Root UNI U

Figure 37 Subscriber View of the Rooted-Multipoint EVC

Figure 38 shows and example of supporting this Rooted-Multipoint EVC using Hairpin Switch-
ing among the Trunk OVC End Points in MEN A. The configuration of this example would be
useful if MEN B could only support Point-to-Point OVCs. The Hairpin Switching in MEN A
provides the connectivity between the UNIs in MEN C and MEN D that MEN B is unable to
provide.

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 79
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.
External Network Network Interface (ENNI) Phase 2

Root UNI T

MEN C
Leaf UNI Y
ENNI BC
Root UNI S

MEN B
MEN A

ENNI AB
MEN D
Leaf UNI X ENNI BD
Leaf UNI Z

Root UNI U

Path for frames


Rooted-Multipoint OVC originating at a Root UNI
Path for frames
Trunk OVC End Point originating at a Leaf UNI
UNI
Root OVC End Point
ENNI
Leaf OVC End Point Bundled OVC

Figure 38 Hairpin Switching with Trunk OVC End Points

12 References
[1] Metro Ethernet Forum, MEF 4, Metro Ethernet Network Architecture Framework
Part 1: Generic Framework, May 2004.

[2] S. Bradner, RFC 2119, Key words for use in RFCs to Indicate Requirement Lev-
els, March 1997.

[3] IEEE Std 802.3 2005, Information technology Telecommunications and in-
formation exchange between systems Local and metropolitan area networks
Specific requirements Part 3: Carrier sense multiple access with collision de-
tection (CSMA/CD) access method and physical layer specifications, 9 December
2005.

[4] IEEE Std 802.1ad 2005, IEEE Standard for Local and metropolitan Area Net-
works Virtual Bridged Local Area Networks Amendment 4: Provider Bridges,
May 2006.

[5] Metro Ethernet Forum, MEF 10.2, Ethernet Services Attributes Phase 2, October
2009.

[6] International Telecommunication Union, Recommendation Y.1731, OAM func-


tions and mechanisms for Ethernet based Networks, February 2008.

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 80
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.
External Network Network Interface (ENNI) Phase 2

[7] Metro Ethernet Forum, MEF 11, User Network Interface (UNI) Requirements and
Framework, November 2004.

[8] Metro Ethernet Forum, MEF 20, User Network Interface (UNI) Type 2 Implemen-
tation Agreement, July 2008.

[9] Metro Ethernet Forum, MEF 6.1, Ethernet Services Definitions - Phase 2, April
2008.

[10] Metro Ethernet Forum, MEF 23.1, Carrier Ethernet Class of Service Phase 2,
January 2012.

[11] Metro Ethernet Forum, MEF 17, Metro Ethernet Forum, Service OAM Require-
ments & Framework Phase 1, April 2007.

[12] IEEE Std 802.1ag 2007, IEEE Standard for Local and metropolitan Area Net-
works Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault
Management, December 2007.

[13] Metro Ethernet Forum, MEF 2, Metro Ethernet Forum, Requirements and
Framework for Ethernet Service Protection in Metro Ethernet Networks, February
2004.

[14] K. Nichols, S. Blake, F. Baker, and D. Black, RFC2474, Definition of the Differ-
entiated Services Field (DS Field) in the IPv4 and IPv6 Headers, December 1998.

[15] IEEE Std 802.1ah 2008, IEEE Standard for Local and metropolitan Area Net-
works Virtual Bridged Local Area Networks Amendment 7: Provider Backbone
Bridges, August 2008.

[16] Metro Ethernet Forum, MEF 26, External Network Network Interface (ENNI)
Phase 1, January 2010.

[17] Metro Ethernet Forum, MEF 26.0.1, Corrected Figure 10 for MEF 26, July 2010.

[18] Metro Ethernet Forum, MEF 26.0.2, OVC Layer 2 Control Protocol Tunneling
Amendment to MEF 26, July 2011.

[19] Metro Ethernet Forum, MEF 26.0.3, Service Level Specification Amendment to
MEF 26, October 2011.

[20] Metro Ethernet Forum, MEF 28, External Network Network Interface (ENNI)
Support for UNI Tunnel Access and Virtual UNI, October 2010.

[21] IEEE Std 802.1Q 2011, IEEE Standard for Local and metropolitan area net-
works--Media Access Control (MAC) Bridges and Virtual Bridged Local Area
Networks, 2011.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 81
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.
External Network Network Interface (ENNI) Phase 2

[22] Metro Ethernet Forum, MEF 10.2.1, Performance Attributes Amendment to MEF
10.2, January 2011.

[23] International Telecommunication Union, Recommendation Y.1563, Global in-


formation infrastructure, internet protocol aspects and next-generation networks,
Internet protocol aspects Quality of service and network performance, Ethernet
frame transfer and availability performance, 2009.

MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 82
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.
Technical Specification

MEF 20
User Network Interface (UNI) Type 2
Implementation Agreement

July, 2008
UNI Type 2 Implementation Agreement

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 MEF (Metro Ethernet Forum) 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 MEF. The MEF is a non-profit international organization whose mission is
to accelerate the worldwide adoption of Carrier-class Ethernet networks and services. The MEF
does not, expressly or otherwise, endorse or promote any specific products or services.

The Metro Ethernet Forum 2008. All Rights Reserved.

MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page ii
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.
UNI Type 2 Implementation Agreement

Table of Contents
1. ABSTRACT .....................................................................................................................................................2
2. TERMINOLOGY ............................................................................................................................................2
3. SCOPE..............................................................................................................................................................3
3.1 Purpose .............................................................................................................................................................3
3.2 UNI Types.........................................................................................................................................................3
3.2.1 UNI Type 1 ................................................................................................................................................3
3.2.2 UNI Type 2 ................................................................................................................................................4
3.2.3 UNI Type 3 ................................................................................................................................................4
4. COMPLIANCE LEVELS...............................................................................................................................4
5. CONVENTION................................................................................................................................................4
6. BACKWARD COMPATIBILITY .................................................................................................................4
7. SUPPORTING UNI TYPE 2 FUNCTIONALITIES ....................................................................................5
7.1 Supporting UNI Type 2.1 ................................................................................................................................5
7.2 Supporting UNI Type 2.2 ................................................................................................................................5
7.3 Supporting Subsets of UNI Type 2 Functionalities.......................................................................................5
8. UNI TYPE 2 DISCOVERY & CONFIGURATION.....................................................................................6
9. SUPPORTING E-LMI ....................................................................................................................................7
10. SUPPORTING ETHERNET OAM ...............................................................................................................8
10.1 Link OAM ........................................................................................................................................................8
10.2 Service OAM ....................................................................................................................................................9
10.2.1 Maintenance Entity Requirements ...........................................................................................................10
10.2.2 MEP Requirements..................................................................................................................................11
10.2.3 Continuity Check Requirements ..............................................................................................................12
10.2.4 Loopback Requirements ..........................................................................................................................13
11. SUPPORTING PROTECTION ...................................................................................................................15
12. SUPPORTING ENHANCED UNI ATTRIBUTES ....................................................................................16
13. L2CP AND SERVICE OAM HANDLING .................................................................................................17
14. APPENDIX A (TEST-MEG DEFINITION) ...............................................................................................19
15. APPENDIX B (UP-MEP AND DOWN-MEP DEFINITION) ...................................................................20
REFERENCES ..........................................................................................................................................................21

MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 1
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.
UNI Type 2 Implementation Agreement

1. Abstract
This document specifies an Implementation Agreement (IA) for MEF User to Network Interface
(UNI) Type 2. This Implementation Agreement adds new functionalities to MEF UNI Type 1
[MEF13], such as E-LMI based on [MEF16], Link OAM based on clause 57 of [IEEE 802.3],
Service OAM based on [ITU-T Y.1731] and [IEEE 802.1ag] and Protection using Link
Aggregation based on clause 43 of [IEEE 802.3].

2. Terminology
Term Definition
AIS Alarm Indication Signal
BW Bandwidth
CCM Connectivity Check Message
CE Customer Equipment
CFM Connectivity Fault Management
CoS Class of Service
CoS ID Class of Service Identifier
DA Destination Address
A MEP in an 802.1 Bridge that sends frames away from the Bridge Relay Entity; see
Down-MEP
[IEEE 802.1ag]
E-LAN MEF Multipoint to Multipoint service; see [MEF 10.1]
E-LINE MEF Point-to-Point service; see [MEF 10.1]
E-LMI Ethernet Local Management Interface [MEF16]
Ethernet Virtual Connection: an association between two or more UNIs for the purpose
EVC
of delivering Ethernet services.
EVC ID The Identifier for an EVC
IA Implementation Agreement
GARP Generic Attribute Registration protocol
LACP Link Aggregation Control Protocol
LAG Link Aggregation Group
LB Loop Back
LBM Loopback Message
LBR Loopback Reply
Link OAM OAM specific to a single link as per clause 57 of [IEEE 802.3]
L2CP Layer 2 Control Protocols
MD Maintenance Domain
ME Maintenance Entity
MEG Maintenance Entity Group
MEG-Level Maintenance Entity Group Level
MEP MEG End Point
MEP ID Maintenance Entity End Point Identification
MIP Maintenance Entity Intermediate Point

MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 2
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.
UNI Type 2 Implementation Agreement

Term Definition
MTU Maximum Transfer Unit
NE Network Element
OAM Operation Administration and Management
PDU Protocol Data Unit
RDI Remote Defect Indication
Rooted-Multipoint 'MEF Point to Multipoint service; see [MEF 10.1]
Service OAM
Service OAM is OAM used to monitor an individual Service; see [ITU-T Y.1731]
and [IEEE 802.1ag]
Subscriber-MEG The MEG at Subscriber Level
Test-MEG The MEG used by Service provider to test the connectivity to UNI-C.
TLV Type, Length, Value
User Network Interface. The UNI is a demarcation point between the responsibility
UNI
of the Service Provider and the responsibility of the Subscriber.
UNI ID The Identifier for a UNI
UNI-C Part of the UNI that is located at Customer Equipment
UNI-MEG UNI Maintenance Entity Group
UNI-N Part of the UNI that is located at Service Provider Equipment
A MEP in an IEEE 802.1 Bridge that sends frames toward the Bridge Relay Entity; see
Up-MEP
[IEEE 802.1ag]

3. Scope
3.1 PURPOSE
This document is an Implementation Agreement that defines the requirements for UNI Type 2.
UNI Type 2 is an enhancement to UNI Type 1 as defined in [MEF13], with added
functionalities. The new functionalities include capability for UNI-C to retrieve EVC status and
configuration information including associated service attributes from UNI-N via E-LMI as per
[MEF16]; capability for customer and service provider to check and diagnose the UNI
connectivity via Link OAM as per clause 57 of [802.3] and Service OAM as per [ITU-T Y.1731]
and [IEEE 802.1ag], and capability to protect UNI against port failure via Link Aggregation as
per clause 43 of [IEEE 802.3].

3.2 UNI TYPES


[MEF 11] introduces 3 types of UNIs: UNI Type 1, UNI Type 2, and UNI Type 3. Each
successive type specifies increased capabilities while at the same time retaining backward
compatibility with the earlier types. The following sections describe the main operational aspects
of these three UNI types:

3.2.1 UNI Type 1


The UNI Type 1 operates in manual configuration mode in which the Service Provider and
Customer will have to manually configure the UNI-N and UNI-C for services. UNI Type 1 is
described in [MEF13].

MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 3
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.
UNI Type 2 Implementation Agreement

3.2.2 UNI Type 2


The UNI Type 2 mode of operation allows UNI-C to retrieve EVC status and configuration
information from UNI-N. In addition UNI Type 2 adds fault management and protection
functionalities beyond those specified in UNI Type 1. UNI Type 2 is the subject of this IA.

3.2.3 UNI Type 3

The UNI Type 3 mode of operation allows the UNI-C to request, signal and negotiate EVCs and
its associated Service Attributes to the UNI-N. UNI Type 3 is out of the scope of this
Implementation Agreement and is for further study.

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 IETF RFC 2119. All key words must be use
upper case, bold text.

5. Convention
UNI Type 2 is divided to two categories called UNI Type 2.1 and UNI Type 2.2. Throughout this
document the term UNI Type 2 applies to both UNI Type 2.1 and 2.2.

6. Backward Compatibility

[R1] A UNI-N Type 2 MUST support all the mandatory requirements of UNI-N Type 1.1 and
UNI-N Type 1.2 as per [MEF13], except for the mandatory requirements in Section 5.1 of
[MEF 13].

Note: Section 5.1 of [MEF 13] contains UNI Type 1.1 and UNI Type 1.2 PHYs that are only a
subset of the UNI Type 2.1 and UNI Type 2.2 PHYs described in this specification under [R78].

[R2] A UNI-N Type 2 SHOULD support all the optional requirements of UNI-N Type 1.1 and
UNI-N Type 1.2 as per [MEF13]

[R3] A UNI-C Type 2 MUST support all the mandatory requirements of UNI-C Type 1.1 and
UNI-C Type 1.2 as per [MEF13], except for the mandatory requirements in Section 5.1 of
[MEF 13].

MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 4
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.
UNI Type 2 Implementation Agreement

Note: Section 5.1 of [MEF 13] contains UNI Type 1.1 and UNI Type 1.2 PHYs that are only a
subset of the UNI Type 2.1 and UNI Type 2.2 PHYs described in this specification under [R78].

[R4] A UNI-C Type 2 SHOULD support all the optional requirements of UNI-C Type 1.1 and
UNI-C Type 1.2 as per [MEF13]

7. Supporting UNI Type 2 Functionalities


7.1 SUPPORTING UNI TYPE 2.1

[R5] A UNI-N and UNI-C Type 2.1 MUST support the following functionalities:

1) Service OAM, as per section 10.2


2) Enhanced UNI Attributes, as per section 12
3) L2CP Handling as per section 13

And MAY support the following functionality:

4) E-LMI, as per section 9


5) Link OAM, as per section 10.1
6) Protection, as per section 11

7.2 SUPPORTING UNI TYPE 2.2

[R6] A UNI-N and UNI-C Type 2.2 MUST support the following functionalities:

1) E-LMI, as per section 9


2) Link OAM, as per section 10.1
3) Service OAM, as per section 10.2
4) Protection, as per section 11
5) Enhanced UNI Attributes, as per section 12
6) L2CP Handling as per section 13

7.3 SUPPORTING SUBSETS OF UNI TYPE 2 FUNCTIONALITIES

[R7] A UNI-N Type 2 MUST be able to interoperate with each of the functionalities listed in
section 7.1 and 7.2 that is fully implemented by the UNI-C as per this Implementation
Agreement.

MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 5
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.
UNI Type 2 Implementation Agreement

Note: A UNI-N Type 2 is not required to interoperate with any UNI-C Type 2 functionality listed
in 7.1 and 7.2, which is not fully implemented by UNI-C. For example UNI-N is not required to
interoperate the E-LMI protocol with a UNI-C that implements only a subset of the mandatory
UNI-C aspects of the E-LMI functionalities.

[R8] A UNI-C Type 2 MUST be able to interoperate with each of the functionalities listed in
section 7.1 and 7.2 that is fully implemented by the UNI-N as per this Implementation
Agreement.

Note: A UNI-C Type 2 is not required to interoperate with any individual UNI-N Type 2
functionality listed in section 7.1 and 7.2, which is not fully implemented by UNI-N. For
example UNI-C is not required to interoperate the E-LMI protocol with a UNI-N that
implements only a subset of the mandatory UNI-N aspects of the E-LMI functionalities.

8. UNI Type 2 Discovery & Configuration


[R9] A UNI-N Type 2 that supports E-LMI, MUST use the procedures outlined in section
5.6.11.2 of [MEF16] to determine whether E-LMI is operational at UNI-C or not.

[R10] A UNI-C Type 2 that supports E-LMI, MUST use the procedures outlined in section
5.6.11.1 of [MEF16] to determine whether E-LMI is operational at UNI-N or not.

[R11] A UNI-N Type 2 that supports Link OAM MUST use the Link OAM Discovery process
as outlined in clause 57.3.2.1 of [IEEE 802.3] to determine the peer UNI-C support of Link
OAM.

[R12] A UNI-C Type 2 that supports Link OAM MUST use the Link OAM Discovery process
as outlined in clause 57.3.2.1 of [IEEE 802.3] to determine the UNI-N support of Link OAM.

[R13] A UNI-N Type 2 that supports Link Aggregation MUST use LACP as defined in clause
43.3 of [IEEE 802.3] to agree with UNI-C on a Link Aggregation group.

[R14] A UNI-C Type 2 that supports Link Aggregation MUST use LACP as defined in 43.3 of
[IEEE 802.3] to agree with UNI-N on a Link Aggregation group.

[R15] A UNI-N Type 2 MUST be administratively configurable with the UNI-C MEP ID and
the MEG-Level corresponding to the UNI-MEG.

[R16] A UNI-C Type 2 MUST be administratively configurable with the UNI-N MEP ID and
MEG-Level corresponding to the UNI-MEG.

[R17] A UNI-C Type 2 MUST be administratively configurable with the MEG-Level for the
Test-MEG.

MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 6
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.
UNI Type 2 Implementation Agreement

9. Supporting E-LMI
E-LMI is the Ethernet Local Management Interface, based on [MEF 16]. E-LMI support is
mandatory for UNI Type 2.2 and optional for UNI Type 2.1. The detail requirements are listed in
this section.

[R18] A UNI-N Type 2.1 that supports E-LMI and a UNI-N Type 2.2 MUST support all
mandatory UNI-N aspects of E-LMI as specified in [MEF 16].

[R19] A UNI-N Type 2.1 that supports E-LMI and a UNI-N Type 2.2 SHOULD support all
optional UNI-N aspects of E-LMI as specified in [MEF 16].

[R20] A UNI-C Type 2.1 that supports E-LMI and a UNI-C Type 2.2 MUST support all
mandatory UNI-C aspects of E-LMI as specified in [MEF 16].

[R21] A UNI-C Type 2.1 that supports E-LMI and a UNI-C Type 2.2 SHOULD support all
optional UNI-C aspects of E-LMI as specified in [MEF 16].

[R22] A UNI-N Type 2.1 that supports E-LMI and a UNI-N Type 2.2 SHOULD allow the
configuration of the Minimum Asynchronous Message Interval [MEF16] in the range from
0.5 to 3 seconds with the default of 1 second.

Note: Minimum Asynchronous Message Interval is used to specify minimum time interval
between asynchronous messages. Generally this interval is set to 1/10th of the UNI-Cs T391
in seconds.

[R23] A UNI-N Type 2.1 that supports E-LMI and a UNI-N Type 2.2 SHOULD allow the
configuration of the N393 Status Counter Parameter Threshold [MEF16] in the range from 2
to 10, with the default of 4.

Note: The N393 Status Counter Parameter Threshold is used to determine if E-LMI is
operational or not. This configurable parameter is a Threshold for the Count of Consecutive
Errors.

[R24] A UNI-N Type 2.1 that supports E-LMI and a UNI-N Type 2.2 SHOULD allow the
configuration of the T392 Polling Verification Timer (PVT) limit [MEF16] in the range from
5 to 30, with the default of 15. A UNI-N Type 2 SHOULD allow disabling the Polling
Verification Timer.

MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 7
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.
UNI Type 2 Implementation Agreement

10. Supporting Ethernet OAM


10.1 LINK OAM
Link OAM is based on clause 57 of [IEEE 802.3]. Link OAM monitors UNIs Physical Layer
operation and health and improves fault isolation. Link OAM frames run between UNI-C and
UNI-N. This section lists the Link OAM requirements for UNI-N and UNI-C.

Link OAM support is Mandatory for UNI Type 2.2 and is optional for UNI Type 2.1. The detail
requirements are listed in this section.

[R25] For each physical link in the UNI, a UNI-N Type 2.1 that supports Link OAM and a UNI
Type 2.2 MUST support Active DTE mode capabilities as specified in clause 57.2.9 of
[IEEE 802.3].

[R26] For each physical link in the UNI, a UNI-C Type 2.1 that supports Link OAM and a UNI
Type 2.2 MUST support Passive DTE mode capabilities as specified in clause 57.2.9 of
[IEEE 802.3].

[R27] For each physical link in the UNI, a UNI-C Type 2.1 that supports Link OAM and a UNI
Type 2.2 MAY support Active DTE mode capabilities as specified in clause 57.2.9 of [IEEE
802.3].

[R28] For each physical link in the UNI, a UNI-N Type 2.1 that supports Link OAM and a UNI
Type 2.2 SHOULD support unidirectional OAM operation as per clause 57.2.12 of [IEEE
802.3], when the UNI is one of the 100BASE-X, 1000BASE-X (excluding 1000BASE-PX-D
and 1000BASE-PX-U), 10GBASE-R, 10GBASE-W and 10GBASE-X physical layers as
specified in clause 66 of [IEEE 802.3].

[R29] For each physical link in the UNI, a UNI-C Type 2.1 that supports Link OAM and a UNI
Type 2.2 SHOULD support unidirectional OAM operation as per clause 57.2.12 of [IEEE
802.3], when the UNI is one of the 100BASE-X, 1000BASE-X (excluding 1000BASE-PX-D
and 1000BASE-PX-U), 10GBASE-R, 10GBASE-W and 10GBASE-X physical layers as
specified in clause 66 of [IEEE 802.3].

[R30] For each physical link in the UNI, a UNI-N Type 2.1 that supports Link OAM and a UNI
Type 2.2 MUST be able to turn off the 802.3x (PAUSE) frame generation to enable proper
Link OAM operation over the UNI as per clause 57.1.5.3 of [IEEE 802.3].

[R31] For each physical link in the UNI, a UNI-C Type 2.1 that supports Link OAM and a UNI
Type 2.2 MUST be able to turn off the 802.3x (PAUSE) frame generation to enable proper
Link OAM operation over the UNI as per clause 57.1.5.3 of [IEEE 802.3].

MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 8
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.
UNI Type 2 Implementation Agreement

10.2 SERVICE OAM


UNI Type 2 Service OAM is specified to be a minimal, but useful, set of capabilities based on
[ITU-T Y.1731] and [IEEE 802.1ag] and is focused on fault management for the Maintenance
Entity Groups (MEGs) crossing the UNI for all service types. A UNI may span one or multiple
Ethernet Links.

Service OAM support is Mandatory for UNI Type 2.1 and 2.2. The detail requirements are listed
in this section.

A Maintenance Entity (ME) is a point-to-point relationship between two MEPs within a single
MEG. Note that a MEG includes all unique pairs of MEPs (MEs) in a Maintenance Domain. In
a point-to-point EVC, there is just one ME, while in a multi-point EVC, there is more than one
MEs.

Service OAM occurs at different MEG-Levels (the MEG-level is specified within Service OAM
frames). The following MEGs are functionally equivalent, but are defined at different MEG-
Levels:

UNI-MEG. The UNI-MEG runs between the UNI-N and the UNI-C at one specific
UNI, and the MEG is always point-to-point. This ME monitors the connectivity between
the Service Provider and the Subscriber.
Test-MEG. The Test-MEG runs between two or more UNI-Cs and is defined such that
the Service Provider can (temporarily or permanently) insert a Test-MEP on an existing
UNI-C or another location on an EVC as a test point from which the Service Provider
can test connectivity all of the way to any other UNI-C in the EVC. This MEG is for
Service Provider or Network Operator testing. For more details and explanation of Test-
MEG please refer to Appendix A.
Subscriber-MEG. The Subscriber-MEG runs between two or more UNI-Cs and provides
Subscriber monitoring for an end-to-end service between subscriber endpoints.

These MEGs are illustrated by Figure 1. Each MEG is an association of two or more provisioned
maintenance points that require management. The maintenance points are shown as triangles in
Figure 1 and are referred to as MEG End Points (MEPs). A Test-MEG, for example, could
consist of two Test MEPs as shown in Figure 1, but would generally consist of at least three
MEPs (the third being the Service Providers Test MEP).

MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 9
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.
UNI Type 2 Implementation Agreement

Subscriber Subscriber
Equipment Operator A NEs Service Provider Operator B NEs Equipment

1 2 3 4 5 6 7 8

Subscriber MEG
Test MEG
EVC ME
Operator A Operator B MEG
UNI MEG E-NNI ME UNI ME

MEP (up orientation)


MEP (down orientation) Logical path of SOAM PDUs

Figure1. UNI Type 2 MEGs

10.2.1 Maintenance Entity Requirements

This section discusses the requirements where Service OAM entities are required to be
implemented. In this version of UNI Type 2 IA, the requirements focus on the MEPs that must
be implemented on the UNI-C and UNI-N.

This section uses the terms Up-MEP and Down-MEP. Up-MEP and Down-MEP are IEEE terms
that are described in [IEEE 802.1ag]. An Up-MEP is a MEP residing in an IEEE 802.1 Ethernet
Bridge that transmits CFM PDUs towards, and receives them from, the direction of the Bridge
Relay Entity. A Down-MEP is A MEP residing in an IEEE 802.1 Bridge that receives CFM
PDUs from, and transmits them towards, the direction of the LAN.

For a more detailed description of Up-MEP and Down-MEP, refer to Appendix B.

[R32] A UNI-C Type 2 MUST be able to support a MEP instance on the Subscriber-MEG for
each configured EVC. The OAM frames on the Subscriber-MEG SHOULD be tagged and
use the smallest CE-VLAN ID mapped into that EVC.

[R33] A UNI-C Type 2 SHOULD be able to support a MEP instance on the Test-MEG for each
configured EVC. The OAM frames on the Test-MEG SHOULD be tagged and use the
smallest CE-VLAN ID mapped into that EVC.

MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 10
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.
UNI Type 2 Implementation Agreement

[R34] A UNI-C Type 2 MUST be able to support a single MEP instance on the UNI-MEG,
regardless of whether any EVC is configured for that UNI or not. This UNI-MEG is called
the default UNI-MEG and MUST use Untagged OAM frames.

[R35] When the CE is an IEEE 802.1 Bridge, the MEPs corresponding to UNI-MEG and Test-
MEG on a UNI-C Type 2 SHOULD be Down-MEPs.

[R36] When the CE is an IEEE 802.1 Bridge, the MEPs corresponding to Subscriber-MEG on a
UNI-C Type 2 MAY either be Up-MEP or Down-MEP.

[R37] A UNI-N Type 2 MUST be able to support a single MEP instance on the UNI-MEG,
regardless of whether any EVC is configured for that UNI or not. This UNI-MEG, called the
default UNI-MEG MUST use Untagged OAM frames.

[R38] When the Service Provider equipment is an IEEE 802.1 Bridge, the MEP corresponding
to UNI-MEG on UNI-N Type 2 SHOULD be a Down-MEP.

These required MEP instances are illustrated by the Figure 2.

UNI-C
Default UNI-C MEPs Default UNI-N MEPs

MEPss
Up or Down MEP Per EVC Subscriber ME
Subscriber-MEPs

Down MEPs Per EVC Test ME


Test-MEPs

Down MEPs
Down UNI ME
UNI-MEP

Figure2. UNI Type 2 MEP Instances

10.2.2 MEP Requirements

[R39] A UNI-C and UNI-N Type 2 MUST support a configurable MEG-Level for the MEPs.
The default MEG-Level values for the various MEGs SHOULD be "1" for the UNI-MEG,
5 for the Test-MEG, and 6 for the Subscriber-MEG.

MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 11
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.
UNI Type 2 Implementation Agreement

[R40] A UNI-C and UNI-N Type 2 MEP implementation MUST be able to process received
Multicast CCM frames for each required MEG.

[R41] A UNI-C and UNI-N Type 2 MEP implementation MUST be able to process and
respond to both Unicast and Multicast LBM frames for each required MEG.

[R42] When CCM transmission is enabled for a MEP in a UNI-C and/or UNI-N Type 2
implementation, the MEP MUST be able to generate Multicast CCM frames.

[R43] A UNI-C and UNI-N Type 2 MEP implementation MUST be able to generate Unicast
LBM frames, and MAY be able to generate Multicast LBM frames.

Additional CCM and LBM requirements are covered in later sections.

10.2.3 Continuity Check Requirements

The following requirements apply to the implementation of the continuity check (CC) function
as an operation that, when enabled, runs continuously on a MEP for service monitoring. These
requirements define default protocol values and the protocol options that are required for UNI
Type 2 implementations.

[R44] A UNI-C and UNI-N Type 2 MUST have the capability to administratively enable and
disable CCM transmission on all local MEPs.

The following requirements define the parameters that control CCM transmission behavior.

[R45] A UNI-C and UNI-N Type 2 MUST support a CCM frame rate of 1 frame per second
and MAY support other values specified in section 7.1.1 of [ITU-T Y.1731]. The default
rate SHOULD be set to 1 frame per second.

[R46] CCM transmission SHOULD be disabled by default on Subscriber-MEG and Test-MEG,


and SHOULD be enabled by default on the UNI-MEG.

[R47] A UNI-C and UNI-N Type 2 MUST support a configurable priority for transmitted CCM
frames for Test-MEG and subscriber-MEG. The default value SHOULD be the CoS ID
supported by the EVC, which yields the lowest frame loss performance. Untagged UNI-MEG
CCM frames SHOULD be transmitted with the highest priority supported by the UNI.

The MEF has defined EVC ID and UNI ID attributes that are unique across the MEN, but has
not defined a maximum length or format. Therefore a limited length identifier is needed for each.
This identifier is referred to as the Representative Value. The Representative Value for each
EVC ID must be no more than 45 ASCII characters and it must have a one to one relationship
with the EVC ID. The Representative Value for each UNI ID must be no more than 45 ASCII
characters and it must have a one to one relationship with the UNI ID.
MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 12
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.
UNI Type 2 Implementation Agreement

[R48] The Maintenance Association Identifier (MAID) is used by the CC function, and is
required to be unique across MEGs at the same MEG-Level. The MAID has two
components consisting of the MD Name and the Short MA Name. The MD Name SHOULD
use the "null" format and the Short MA Name SHOULD use the "text" format, allowing for
a maximum length of 45 ASCII characters for the Short MA Name. The Short MA Name is
provisioned and SHOULD default to a the Representative Value that is uniquely related, but
not necessarily equal, to the EVC ID or UNI ID as following:

a. The Representative Value of the UNI ID for the default UNI-MEG (i.e., the default
UNI-MEG using untagged OAM frames)

b. The Representative Value of the EVC ID for the Test-MEG

c. The Representative Value of the EVC ID for the Subscriber-MEG

Note: Since the EVC ID or UNI ID may exceed the maximum length of the Short MA Name, an
abbreviated form may be required. Note that a Maintenance Domain (MD) is associated with a
single MEG-Level.

[R49] A UNI-N and UNI-C Type 2 SHOULD support counters for each MEP that counts the
number of CCM frames transmitted.

[R50] A UNI-N and UNI-C Type 2 SHOULD support the CC defect and fault alarm hierarchy
per clause 20.1.2 of [IEEE 802.1ag]. If this is supported, the highest priority alarm MUST be
made available to management and SHOULD mask lower priority alarms.

[R51] A UNI-N and UN-C Type 2 MEP MUST support the minimum CC fault priority level
[IEEE 802.1ag] for which a CC alarm will be generated. An alarm will be generated only if
the fault has equal or greater priority than this minimum fault level. The default value
SHOULD be set to "RDI".

[R52] A UNI-N and UNI-C Type 2 MEP MUST support a CC fault Alarm time and a CC fault
Reset time. The default CC fault Alarm time SHOULD be set to 2.5 seconds and the default
CC fault reset time SHOULD be set to 10 seconds.

Note: CC Alarm time is the time that a defect must be present before a fault Alarm is issued. CC
Reset time is the time that a defect must be absents before resetting a fault Alarm.

10.2.4 Loopback Requirements

MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 13
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.
UNI Type 2 Implementation Agreement

The following requirements apply to the implementation of the loopback (LB) function as an
operation that runs on-demand on a MEP for service troubleshooting. These requirements define
default protocol values and the protocol options that are required for UNI Type 2
implementations.

For the purposes of this section, a loopback (LB) session is defined as a sequence that begins
with management initiating the transmission of N periodic loopback frames from a local-MEP
to a remote-MEP in the same MEG. The session ends normally when the last loopback response
is received or incurs a timeout. The session may be aborted by management.

[R53] Each LB session MUST have the ability to be administratively initiated and stopped.

The following requirements define the parameters that must be provided when initiating a LB
session.

[R54] For each LB session, the destination address MUST be configurable to any Unicast MAC
DA. Multicast destinations MAY be supported using the reserved CCM multicast MAC DA
in the range of 01-80-C2-00-00-30 to 01-80-C2-00-00-37 that corresponds to the MEG-Level
of the MEP.

[R55] For each LB session, the priority of LBM frames MUST be configurable. The default
priority value SHOULD be the CoS ID supported by the EVC, which yields the lowest frame
loss performance.

[R56] For each LB session, the number of LBM transmissions MUST be configurable. The
default value SHOULD be 3.

[R57] For each LB session, the interval between LBM transmissions MUST be configurable.
The default value SHOULD be 1 second.

[R58] For each LB session, the timeout after a LBM transmission, for an expected LBR result
MAY be configurable. The default value SHOULD be 5 seconds.

[R59] For each LB session, the size of the LBM frame MUST be configurable. This requires
that the optional Data TLV MUST be supported to allow for frames up to the maximum
MTU size. The default LBM frame size SHOULD be 64 bytes.

[R60] For each LB session, the following information MUST be maintained: counters for LBM
frames transmitted, LBR frames received (i.e., requests and responses), the percentage of lost
LBM or LBR frames (i.e., unanswered requests), the minimum, maximum, and average
round-trip latency.

MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 14
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.
UNI Type 2 Implementation Agreement

11. Supporting Protection


This section specifies requirements for UNI-N and UNI-C to enable UNI protection, in case of a
failure. Link Aggregation support is mandatory for UNI Type 2.2 and is Optional for UNI Type
2.1. The detailed requirements are listed in this section.

[R61] A UNI-N Type 2.1 that supports UNI protection and a UNI-N Type 2.2 MUST support
Link Aggregation as specified in clause 43 of [IEEE 802.3], for UNI protection.

[R62] A UNI-C Type 2.1 that supports UNI protection and a UNI-C Type 2.2 MUST support
Link Aggregation.

[R63] A UNI-N Type 2.1 that supports Link Aggregation and a UNI Type 2.2 MUST support at
least two (2) links in the Link Aggregation group (LAG).

[R64] A UNI-C Type 2.1 that supports Link Aggregation and a UNI-C Type 2.2 MUST support
at least two (2) links in the Link Aggregation group (LAG).

[R65] A UNI-N Type 2.1 that supports Link Aggregation and a UNI-N Type 2.2 SHOULD
support Link Aggregation across multiple line cards.

Note: A line card can be defined as a field replaceable sub-unit of a larger modular system that
supports ports serving service frames, designed to be replaced without affecting the operation of
other sub-units. This would include a conventional line card, but would exclude, for example,
a daughter card which could not be replaced without removing the carrier card it is on. The
above requirement intends to enhance the protection level of the Network Element implementing
the UNI-N. Note that some NE might not have multiple line-cards.

[R66] When Link Aggregation of exactly two (2) links is implemented across line cards, one of
the links MAY be set to Active while the other be set to Standby using LACP, as per clause
43.4 of [IEEE 802.3], to simplify the bandwidth profile enforcement.

Note: Link OAM or Link level Service OAM should be used for the Standby link. To ensure
availability of the Standby link in case of failure of the Active link,

[R67] A UNI-N and UNI-C Type 2.1 that support Link Aggregation and a UNI-N and UNI-C
Type 2.2 SHOULD support LACP as per [IEEE 802.3]. When LACP is not supported other
methods such as shutting down the PHY laser MAY be supported to signal LAG change.

[R68] A UNI-N Type 2.1 that supports Link Aggregation and LACP and a UNI-N Type 2.2 that
supports LACP MUST have its LACP_Activity set to Active mode, to prevent the scenario
when both UNI-C and UNI-N are passive waiting for each other to initiate the
communication

MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 15
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.
UNI Type 2 Implementation Agreement

[R69] A UNI-C Type 2.1 that supports Link Aggregation and LACP and a UNI-C Type 2.2 that
supports LACP MUST have its LACP_Activity set to Passive mode as default.

12. Supporting Enhanced UNI Attributes


This section list some enhanced UNI features for UNI Type 2 that were not supported in UNI
Type 1 [MEF13].

[R70] A UNI-N Type 2 MUST be able to support Per-UNI egress BW profiling of CIR as
specified in [MEF10.1], in the following granularities:
1Mbps steps up to 10Mpbs
5 Mbps steps beyond 10Mbps and up to 100Mbps
50 Mbps steps beyond 100Mpbs and up to 1Gbps
500 Mbps steps beyond 1Gbps

[R71] A UNI-N Type 2 MUST be able to support Per-EVC egress BW profiling of CIR as
specified in [MEF10.1], in the following granularities:
1Mbps steps up to 10Mpbs
5 Mbps steps beyond 10Mbps and up to 100Mbps
50 Mbps steps beyond 100Mpbs and up to 1Gbps
500 Mbps steps beyond 1Gbps

[R72] A UNI-N Type 2 MUST be able to support Per-CoS ID egress BW profiling of CIR as
specified in [MEF10.1], in the following granularities:
1Mbps steps up to 10Mpbs
5 Mbps steps beyond 10Mbps and up to 100Mbps
50 Mbps steps beyond 100Mpbs and up to 1Gbps
500 Mbps steps beyond 1Gbps

[R73] A UNI-N Type 2 MUST support an MTU size of 1522 Bytes as per [IEEE 802.3] and
SHOULD support an MTU size of 2000 Bytes as per [IEEE 802.3as]. It MAY support 9600
byte jumbo frames.

[R74] A UNI-C Type 2 MUST support an MTU size of 1522 Bytes as per [IEEE 802.3] and
SHOULD support an MTU size of 2000 Bytes as per [IEEE 802.3as]. It MAY support 9600
byte jumbo frames.

[R75] A UNI-N Type 2 MUST be able to support Point-to-point, Multipoint-to-Multipoint


EVC, and SHOULD be able to support Rooted-Multipoint EVCs.

[R76] A UNI-N Type 2 SHOULD be able to take on the role of a "root" or "leaf" for each
Rooted-Multipoint EVC it supports.

MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 16
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.
UNI Type 2 Implementation Agreement

[R77] A UNI-N Type 2 SHOULD be capable of operating as a "root" on one Rooted-


Multipoint EVC and a "leaf" on another Rooted-Multipoint EVC concurrently.

[R78] A UNI-N and UNI-C Type 2 MUST support at least one of the PHYs listed in [IEEE
802.3], excluding 1000BASE-PX-D and 1000BASE-PX-U.

Note: 1000BASE-PX-D and 1000BASE-PX-U are excluded since Link OAM is not supported
on these PHYs.

[R79] A UNI-N and UNI-C Type 2 MUST support Auto-negotiation for 10/100 and
10/100/1000 UNI rates for the PHYs that support Auto-negotiation.

[R80] A UNI-N and UNI-C Type 2 MUST support the capability to disable the Auto-
negotiation function.

Note: The Auto-negotiation function may need to be disabled for unidirectional link operation.

13. L2CP and Service OAM Handling


This section provides requirements for the processing of a customers Layer 2 Control Protocol
(L2CP) and Service OAM frames at UNI-N. Since UNI-N Type 2 is designed to simultaneously
support currently defined MEF services (MEF10.1), as well as all future MEF services, the L2CP
and OAM processing requirements herein are generic and service agnostic. Specific L2CP and
OAM handling rules for each Service should be taken from the MEFs Ethernet Service
Definition Implementation Agreements..

For a given L2 Control Protocol or OAM there are four possibilities for processing:

1. Pass to an EVC for tunneling


2. Peer at the UNI
3. Peer and pass to an EVC for tunneling
4. Discard at the UNI

This IA however, only specifies two possible processing at UNI-N:

1. Pass to EVC
2. Not pass to EVC (Filter)

Pass to EVC means the L2CP or OAM frames could be either Tunneled or Discarded by the
EVC depending on the service type. Filter means the L2CP or OAM frames could be either
Peered or Discarded depending on the service type. The decision to whether Discard or Peer
or Tunnel any L2CP or OAM is Service type dependent and orthogonal to the decision to
Pass to EVC or Filter, and is outside of the scope of this Implementation Agreement.

MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 17
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.
UNI Type 2 Implementation Agreement

Specific L2CP and OAM handling rules for each Service should be taken from the MEFs
Ethernet Service Definition Implementation Agreements such as MEF6.1.

[R81] A UNI-N Type 2 MUST Filter all L2CP packets with the following Multicast MAC
DA:

01-80-C2-00-00-02 to 01-80-C2-00-00-0A
01-80-C2-00-00-0D
01-80-C2-00-00-0E

[R82] A UNI-N Type 2 SHOULD Filter PAUSE frames with the following Multicast MAC
DA:

01-80-C2-00-00-01

[R83] A UNI-N Type 2 MUST have the capability to be configured to either Pass to EVC or
Filter all packets with the following Multicast MAC DA:

01-80-C2-00-00-00
01-80-C2-00-00-0B
01-80-C2-00-00-0C
01-80-C2-00-00-0F
01-80-C2-00-00-20 to 01-80-C2-00-00-2F
01-80-C2-00-00-30 to 01-80-C2-00-00-3F

Several protocols may use the same Multicast MAC DA, for example, multiple protocols use the
slow multicast protocol address 01-08-C2-00-00-02. For decision to Peer or Discard,
additional fields within the service frame may be uses such as Ethertype, Subtype, code, etc.

MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 18
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.
UNI Type 2 Implementation Agreement

14. Appendix A (Test-MEG Definition)


Carriers have expressed the need to test connectivity all the way to customer equipment using
OAM protocols, and to do so in a way that is segmented from a subscriber's self use of OAM
protocols. This requirement has created the need to utilize a subscriber level OAM for carrier
testing purposes. This use is completely conformant with the definition of [ITU-T Y.1731] and
[IEEE 802.1ag], and places no new requirements on those protocols.

To accomplish this testing, the UNI-C is required to implement two subscriber level MEPs - one
for actual customer testing, and another one for carrier testing to customer equipment. The MEP
dedicated to carrier testing at the UNI-C is referred to as the UNI-C Test MEP, and the group of
MEs between these UNI-C Test MEPs is referred to as the Test-MEG (made up of one or more
Test MEs, as in the standard MEG/ME relationship).

By default, the CC function is disabled on the UNI-C Test MEP. In order to test connectivity
and performance to such UNI-C Test MEP, the carrier must have access to an equivalent MEP,
referred to as the Carrier Test MEP, from which to source the OAM frames. Where and how to
place and utilize a MEP for testing is at the carrier's discretion.

This specification simply requires that the UNI-C implement the responder functionality in the
UNI-C Test MEP so the carrier has the option to utilize it for test functions.

The Carrier Test MEP may be a permanent or temporary creation depending upon the needs of
the carrier. It may utilize an existing UNI-C to perform these tests, or the Carrier Test MEP may
be placed at another location. This specification does not define or limit the placement or utility
of a Carrier Test MEP.

It is important to realize that the Carrier Test MEP utilized must obey the rules and procedures of
the OAM protocols. This Carrier Test MEP behaves no differently than any other MEP. In
particular, the Carrier Test MEP must have access to the data plane that is being measured (for
example, the EVC), and the MEP must provide filtering based on the MEG-Level to form a
boundary of the domain. It is therefore recommended that the carrier should take care in the
placement of Carrier Test MEP because if placed improperly it may have unintended
consequences - such as providing a barrier to other OAM domains.

MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 19
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.
UNI Type 2 Implementation Agreement

15. Appendix B (Up-MEP and Down-MEP Definition)


Up-MEP and Down-MEPs are defined in [IEEE 802.1ag] for an IEEE 802.1 bridge. This
appendix provides a brief description of Up-MEP and Down-MEP.

An Up-MEP is a MEP that monitors the forwarding path internal to an IEEE 802.1 bridge node
(CE or PE), while a Down-MEP is a MEP that only monitors the forwarding path external to an
IEEE 802.1 bridge node. An Up- MEP is implemented on the ingress port, while a Down-MEP
is implemented on the egress port. The ingress port is the port that sends traffic toward the bridge
relay, while egress port is the port that sends traffic away from the bridge relay. For example in
an IEEE 802.1 bridge, an Up-MEP is a MEP that is implemented on one of the ports and is
facing the bridge (sends OAM messages toward the bridge relay), while a Down-MEP is a MEP
that is implemented on one of the ports and is facing the MAC on the same port (sends OAM
messages toward the MAC and away from the bridge relay).

An Up-MEP may also, via continuity check, convey its port and interface status to its peers. An
Up-MEP can only be applied if the CE is a L2 forwarding device (bridge). A CE that is a station
such as a router should use a Down-MEP because stations can not forward OAM frames.

These MEP directions are illustrated in Figure 3.

UNI-C UNI-N

1 2

Subscriber ME
Up MEP Test ME
UNI ME

Down MEP

Figure 3 - UNI Type 2 MEP Directions

MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 20
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.
UNI Type 2 Implementation Agreement

References
Reference Reference Details
MEF 11 Metro Ethernet Forum UNI Requirements and Frame work, Nov 2004
MEF 13 Metro Ethernet Forum, UNI Type 1, Nov 2005
MEF 16 Metro Ethernet Forum, Ethernet Local Management Interface (E-LMI), Jan 2006
IEEE 802.1ag IEEE Virtual Bridged Local Area Networks, Amendment 5:Connectivity Fault
Management, 2007
IEEE 802.3 IEEE, Carrier sense multiple access with collision detection (CSMA/CD) access method
and physical layer specifications, Dec 2005
IEEE 802.3as IEEE, IEEE, Carrier sense multiple access with collision detection (CSMA/CD) access
method and physical layer specifications Amendment: frame format extensions, 2006
MEF 10.1 Metro Ethernet Forum, Ethernet Service Attributes, Phase 2
ITU-T Y.1731 ITU-T, OAM Functions and Mechanisms for Ethernet based networks, 2006

MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 21
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 8

Implementation Agreement for the Emulation of


PDH Circuits over Metro Ethernet Networks

October 2004

MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, 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.
Implementation Agreement for the Emulation of
PDH Circuits over 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
(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 2004. All Rights Reserved.

MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page i
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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

Table of Contents
1. ABSTRACT .......................................................................................................................................................... 1
2. TERMINOLOGY .................................................................................................................................................. 1
3. SCOPE ................................................................................................................................................................... 3
4. COMPLIANCE LEVELS ..................................................................................................................................... 3
5. SERVICE DESCRIPTION .................................................................................................................................... 3
6. INTERWORKING FUNCTION ........................................................................................................................... 3
6.1 ARCHITECTURE .............................................................................................................................................. 3
6.1.1 Functional Layering .............................................................................................................................. 3
6.1.2 Direction terminology ............................................................................................................................ 4
6.1.3 Functional Components and Interfaces ................................................................................................. 4
6.1.4 TDM Service Processor (TSP) ............................................................................................................... 5
6.1.5 Circuit Emulation Inter-working Function (CES IWF) ......................................................................... 6
6.1.6 Emulated Circuit De/Multiplexing Function (ECDX) ........................................................................... 6
6.1.7 Ethernet Flow Termination Function (EFTF) ....................................................................................... 6
6.2 ENCAPSULATION ............................................................................................................................................ 7
6.2.1 Ethernet Services Layer ......................................................................................................................... 7
6.2.2 Adaptation Function Headers ................................................................................................................ 7
6.3 PAYLOAD FORMATS ...................................................................................................................................... 13
6.3.1 Structure-Agnostic Emulation.............................................................................................................. 13
6.3.2 Structure-Aware Emulation using Structure-Locked Encapsulation ................................................... 14
6.3.3 Structure-Aware Emulation using Structure-Indicated Encapsulation................................................ 15
6.4 SYNCHRONIZATION ...................................................................................................................................... 15
6.5 TDM APPLICATION SIGNALING.................................................................................................................... 17
6.5.1 CE Signaling Frames ........................................................................................................................... 17
6.5.2 Channel Associated Signaling (CAS) Frames ..................................................................................... 17
6.5.3 Common Channel Signaling (CCS) Frames ........................................................................................ 18
6.6 CESOETH DEFECTS ..................................................................................................................................... 18
6.6.1 Misconnection ...................................................................................................................................... 19
6.6.2 Reordering and Loss of Frames ........................................................................................................... 19
6.6.3 Late Arriving Frames........................................................................................................................... 20
6.6.4 Malformed CESoETH Frames ............................................................................................................. 20
6.6.5 Jitter Buffer Overrun and Underrun Defects ...................................................................................... 20
6.7 PERFORMANCE MONITORING ....................................................................................................................... 21
6.7.1 Facility Data Link ................................................................................................................................ 21
6.7.2 Errored Data ....................................................................................................................................... 21
7. SERVICE INITIATION AND OPERATION ..................................................................................................... 22

MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page ii
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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

7.1 COMMON CONSIDERATIONS ......................................................................................................................... 22


7.2 CESOETH SERVICE PARAMETERS ............................................................................................................... 22
7.3 CESOETH LOCAL CONFIGURATION PARAMETERS ...................................................................................... 24
8. MEN REQUIREMENTS..................................................................................................................................... 25
8.1 MEN SERVICE TYPE..................................................................................................................................... 25
8.2 SERVICE ATTRIBUTES ................................................................................................................................... 25
8.2.1 Bandwidth Provisioning ...................................................................................................................... 26
8.3 COS PERFORMANCE PARAMETERS ............................................................................................................... 26
8.3.1 Ethernet Frame delay .......................................................................................................................... 27
8.3.2 Ethernet Frame Delay Variation ......................................................................................................... 27
8.3.3 Ethernet Frame Loss ............................................................................................................................ 27
8.3.4 Network Availability ............................................................................................................................ 27
9. MANAGEMENT ................................................................................................................................................ 28
9.1 ALARMS ....................................................................................................................................................... 28
9.2 STATISTICS COUNTERS ................................................................................................................................. 28
10. REFERENCES .................................................................................................................................................... 29

List of Figures
Figure 6-1: Functional Layering, and mapping onto encapsulation headers .................................................................4
Figure 6-2: Interworking function direction ..................................................................................................................4
Figure 6-3: Functional Components and Interface Types..............................................................................................5
Figure 6-4: Emulated Circuit Identifier (ECID) ............................................................................................................8
Figure 6-5: Structure of the CESoETH control word ....................................................................................................8
Figure 6-6: RTP Header Structure [RFC 3550] ........................................................................................................... 11
Figure 6-7: Synchronization Options for the TDM-bound IWF .................................................................................. 16
Figure 6-8: Encoding Format for CAS ABCD values from [RFC 2833] ................................................................. 18
Figure 8-1: Example TDM Virtual Private Line Configurations ................................................................................. 25

List of Tables
Table 6-1: Meaning of the Local TDM Failure Modification bits.................................................................................9
Table 6-2: Meaning of the Fragmentation bits ..............................................................................................................9
Table 8-1: Example Service Attributes for an EVPL or EPL service carrying CESoETH traffic ............................... 26

MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page iii
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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

1. Abstract
This document provides an implementation agreement for the emulation of TDM services belonging to the
Plesiochronous Digital Hierarchy (PDH) across a Metro Ethernet Network. Specifically it covers emulation of
Nx64 kbit/s, DS1, E1, DS3 and E3 circuits. Generically this is referred to as Circuit Emulation Services over
Ethernet (CESoETH).

2. Terminology
Term Definition
AAL1 ATM Adaptation Layer 1
AIS Alarm Indication Signal
ANSI American National Standards Institute
ATM Asynchronous Transfer Mode
CAS Channel Associated Signaling
CBS Committed Burst Size
CCS Common Channel Signaling
CE Customer Equipment
CES Circuit Emulation Services
CESoETH Circuit Emulation Services over Ethernet
CF Coupling Flag
CIR Committed Information Rate
CoS Class of Service
CRC Cyclic Redundancy Check (e.g. the 4-bit CRC-4 used to check data integrity of E1 circuits)
E-Line Ethernet Line Service
EBS Excess Burst Size
ECDX Emulated Circuit De/Multiplexing Function
ECID Emulated Circuit Identifier
EIR Excess Information Rate
EFTF Ethernet Flow Termination Function
EPL Ethernet Private Line
EVPL Ethernet Virtual Private Line
ES Errored Second
ESR Errored Second Ratio
ESF Extended Super Frame
EVC Ethernet Virtual Connection
FCS Frame Check Sequence
FDL Facility Data Link
FER Frame Error Ratio

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

Term Definition
IA Implementation Agreement
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
ITU-T International Telecommunication Union Telecommunication standardization sector
IWF Inter-Working Function
LOS Loss Of Signal
LOF Loss of Frame Alignment
LOFS Loss of Frames State
MAC Medium Access Control
MIB Management Information Base
MEN Metro Ethernet Network
MEN-bound The IWF receiving TDM data from the customers TDM-based equipment, and forwarding this
IWF data in the form of Ethernet frames into the MEN.
PDH Plesiochronous Digital Hierarchy.
PDH refers to the DS1/DS2/DS3 and E1/E3/E4 family of signals as defined by ITU-T and ATIS.
PDU Protocol Data Unit
PWE3 Pseudo-Wire Emulation Edge to Edge (an IETF working group)
RDI Reverse Defect Indication
RTP Real-time Transport Protocol (an IETF protocol, described in RFC 3550)
SF Super Frame
SSRC Synchronization Source (a field within the RTP protocol, RFC 3550)
Structure- Structure-agnostic emulation is the transport of unstructured TDM, or of structured TDM when
agnostic the structure is completely disregarded by the transport mechanism.
Structure- Structure-aware emulation is the transport of structured TDM taking at least some level of the
aware structure into account.
Structure- Encapsulation utilized for Structure-Aware TDM transport where TDM structure boundaries are
locked indicated by packet payload boundaries
Structure- Encapsulation utilized for Structure-Aware TDM transport where TDM structure boundaries are
indicated indicated by pointers
TALS TDM Access Line Service
TDM Time Division Multiplexing
(examples of TDM services include Nx64 kbit/s, DS1, DS3, E1, E3, OC3, STM1, OC12, STM3)
TDM-bound The direction of travel of CESoETH frames within the IWF receiving frames containing
emulated circuit data from the MEN, and forwarding TDM data to the customers TDM-based
equipment.
T-Line TDM Line Service
TSP TDM Service Processing
UNI User Network Interface
VLAN Virtual Local Area Network

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

3. Scope
The scope of this document is to address the transport of circuits carrying time division multiplexed (TDM) digital
signals over the MEN. It makes references to requirements and specifications produced by other standards
organizations (notably the ITU-T, 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 scope of this document is limited to:
1. the essential agreements needed to create inter-operable equipment to reliably transport these TDM circuits
across Metro Ethernet Networks
2. the required performance of the underlying MEN to enable the provision of circuit emulated TDM services that
meet the existing TDM standards, as defined by ITU-T and ANSI

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.

5. Service Description
This implementation agreement describes the detailed methods for transporting TDM circuits over the MEN, in
support of inter-operable implementations of the services described in section 6 of [MEF 3].
[MEF 3] described two main services:
the point-to-point T-Line service
the multi-point to point TALS (TDM Access Line Service).
Both of these services may be implemented using the methods described in this Implementation Agreement.

6. Interworking Function
6.1 ARCHITECTURE

6.1.1 Functional Layering


Circuit Emulation Services over Ethernet (CESoETH) uses a point-to-point connection between two CES
interworking functions. Essentially it uses the MEN as an intermediate network (or virtual wire) between two
TDM networks. This is handled as an application layer function in terms of layered network model defined in [MEF
4]. The CES IWF provides the adaptation of the CES application to the Ethernet services layer. The use of a VLAN
tag is optional, and is restricted to the underlying MEN transport functions.
This functional layering is shown in Figure 6-1, with mapping onto the various encapsulation headers:

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

Destination Address
Ethernet Services Layer Source Address
VLAN tags (optional)
Ethertype
Emulated Circuit Identifier (ECID)
Adaptation Function CESoETH Control Word
RTP (optional)

CES Application Data TDM Payload

Figure 6-1: Functional Layering, and mapping onto encapsulation headers

6.1.2 Direction terminology


A circuit emulation service is a bidirectional service consisting of two symmetrical data flows in opposite directions.
For each direction of the emulated circuit, there is a pair of CES interworking functions, as shown in Figure 6-2.
The MEN-bound IWF handles the packetization of the TDM data, encapsulation into Ethernet frames and
forwarding into the Ethernet network. The corresponding TDM-bound IWF extracts the TDM data from the
Ethernet frames, and recreates the TDM service.

Figure 6-2: Interworking function direction

6.1.3 Functional Components and Interfaces


There are two basic service interfaces in the TDM domain. These are shown in Figure 6-3, 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 may be transported in two ways, structure-agnostic (where any underlying structure is ignored by the
transport mechanism) and structure-aware (where the underlying structure is exploited by the transport
mechanism).
2) Circuit Emulation Service TDM Interface (CES TDM Interface): The actual circuit service that is emulated
between interworking functions through the MEN. This document covers emulation of the following CES
TDM Interface types:

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

DS1 at 1.544 Mbit/s as defined in ANSI [T1.102] and [T1.107]


E1 at 2.048 Mbit/s as defined in ITU-T Recommendations [G.702] and [G.704]
N x 64kbit/s data (i.e. 64 kbit/s, 128 kbit/s, 192 kbit/s) such as defined in ITU-T Recommendation [I.231.1]
DS3 at 44.736 Mbit/s as defined in ANSI [T1.107]
E3 at 34.368 Mbit/s as defined in ITU-T Recommendation [G.751]
For the structure-agnostic emulation of TDM service, the CES TDM 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 the structure-aware emulation of 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 be combined to
create a single CES flow.
Multiple CES IWFs may use one Ethernet interface, and the flows are multiplexed and demultiplexed using the
ECDX (Emulated Circuit De/Multiplexing Function). This functions in the packet domain, and interfaces the CES
payload with the EFTF (Ethernet Flow Termination Function), which handles the MAC layer information.

TDM Service CES TDM CES IWF Type CES Payload Adapted Ethernet
Interface Interface Payload Interface
TSP
Customer (optional) CES IWF
TDM IWF ECDX EFTF
Service (e.g. framing,
mux/demux) IWF

DS1 (T1), E1, CES Control Word Ethertype Destination Addr.


DS3 (T3), E3, RTP (optional) ECID Source Address
Nx64 CES Control Word Ethertype
TDM Payload RTP (optional) ECID
CES Control Word
TDM Payload RTP (optional)

TDM Payload

FCS

Figure 6-3: Functional Components and Interface Types

6.1.4 TDM Service Processor (TSP)


The TDM Service Processor is an optional component that operates on the TDM Service Interface to produce the
service that is to be emulated across the MEN (and vice versa). For example, it may terminate framing overhead, or
multiplex several customer TDM services into a single service to be emulated. It operates in the TDM domain, and
may make use of standard or proprietary techniques. The TSP is considered part of an equipment vendors own
value added function, and its operation is not covered by this implementation agreement.
The interfaces to the TSP consist of the following:
TDM Service Interface (the TDM service handed off to the customer)
CES TDM Interface (i.e. DS1, E1, DS3, E3, or N x 64 kbit/s)

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

6.1.5 Circuit Emulation Inter-working Function (CES IWF)


As noted above, the Circuit Emulation Interworking Function is defined as the adaptation function that interfaces the
CES application to the Ethernet layer. In terms of the diagram in Figure 6-3, it handles the emulation of the service
presented at the CES TDM Interface. The CES IWF is responsible for all the functions required for the emulated
service to function. This includes the following:
Encapsulation and decapsulation (see section 6.2)
Payload formation and extraction (see section 6.3)
Synchronization (see section 6.4)
Carriage of TDM signaling and alarms (see section 6.5)
Error Response and Defect Behaviour (see section 6.6)
TDM performance monitoring (see section 6.7)
The interfaces to the CES IWF consist of the following:
CES TDM Interface (i.e. DS1, E1, DS3, E3, or N x 64 kbit/s)
CES Payload (i.e. packetised TDM payload, CES control word, optional RTP header (see RFC 3550)

6.1.6 Emulated Circuit De/Multiplexing Function (ECDX)


The Emulated Circuit De-multiplexer (ECDX) is a function, operating in the packet domain, that in the MEN-bound
direction:
a. Prepends to every Ethernet frame sent to the MEN an Emulated Circuit Identifier (ECID) attribute that is unique
to the TDM-bound CES IWF.
b. Assigns the Ethertype field to each Ethernet frame sent to the MEN.
In the TDM-bound direction, the ECDX:
a. Determines the destination CES IWF of each Ethernet frame from the ECID value
b. Strips the Ethertype and ECID fields, before handing off the CES Payload to the CES IWF.
The interfaces to the ECDX consist of the following:
CES Payload (i.e. packetised TDM payload, CES control word, optional RTP header (see RFC 3550)
Adapted Payload (i.e. the CES Payload, plus the ECID and Etherype fields)

6.1.7 Ethernet Flow Termination Function (EFTF)


In the context used here, an Ethernet Flow Termination function takes an adapted payload from the ECDX (the
MAC client information field), along with an Ethertype attribute describing it as CES payload. It then adds:
a. the MAC Destination and Source addresses
b. optional VLAN tag (if required) and associated Tag ID and User Priority information
c. any padding required to meet the minimum Ethernet frame size
d. the frame check sequence (FCS).

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

In the TDM-bound direction, the EFTF takes in an Ethernet frame from the MEN, and checks the FCS, discarding
the frame if it is incorrect. It determines whether it contains CES payload from the Ethertype field, and forwards it
to its associated ECDX function, for passing to the appropriate CES IWF.
The interfaces to the EFTF consist of the following:
Adapted Payload (i.e. the CES Payload, plus the ECID and Etherype fields)
Ethernet Interface (standard IEEE 802.3 interface)

6.2 ENCAPSULATION
In common with IETF practice, the protocol descriptions in the following sections are in network byte order,
where bit 0 is the most significant bit, and the bytes are transmitted most significant byte first (i.e. left to right in the
figures shown in this document).

6.2.1 Ethernet Services Layer


This consists of a standard layer 2 [IEEE 802.3]-compliant Ethernet MAC header, added by the EFTF (Ethernet
Flow Termination component).
The assignment of the Ethernet source address is a matter of local policy. It is permitted for several IWFs to share a
single Ethernet MAC sub-layer, or for each IWF to operate its own MAC sub-layer. The Ethernet destination
address is set to the MAC address of the destination IWF.
Since the CESoETH adaptation function operates directly on top of the Ethernet layer without any intervening
protocols, a separate Ethertype value must be allocated for CESoETH, in order to identify the protocol to a
receiving device. The IEEE has assigned Ethertype 0x88d8 to identify Ethernet frames performing this CESoETH
adaptation function.

6.2.2 Adaptation Function Headers


There are three components to the adaptation function header:
1. Emulated Circuit Identifier identifies the emulated circuit being carried. This separates the identification of
the emulated circuit from the Ethernet layer, allowing the MEN operator to multiplex several emulated circuits
across a single EVC where required.
This is added by the ECDX.
2. CESoETH control word provides sequencing and signaling of defects such as AIS of the TDM circuit, or
packet loss detected in the MEN.
This is added by the CES IWF.
3. Optional RTP header Where appropriate, timing and sequencing may be provided by using the Real-time
Transport Protocol, RTP [RFC 3550]. The default case is not to use RTP.
This is added by the CES IWF.

6.2.2.1 Emulated Circuit Identifier


The emulated circuit identifier (ECID) consists of a single, 20-bit unsigned binary field containing an identifier for
the circuit being emulated. This is added by the ECDX, and shown in Figure 6-4 below.
0 19 20 31

Emulated Circuit Identifier (ECID) (20 bits) Reserved (set to 0x102)

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

Figure 6-4: Emulated Circuit Identifier (ECID)


Emulated circuit identifiers have local significance only, and are associated with a specific MAC address.
Therefore, an emulated circuit may be given different ECIDs for each direction of the circuit. ECIDs are selected
during the creation of an emulated circuit.
The following requirements apply to the Emulated Circuit Identifier (ECID):
R1. Each TDM-bound IWF at a given MAC address MUST have a unique ECID value.
R2. The reserved bit field (bits 20 to 31) SHOULD be set to the value 0x102 by the MEN-bound ECDX
Note: This is to ease interworking with an MPLS-based circuit emulation service should this be required. If
this field was to be interpreted as an MPLS label, this value ensures that bit 23 (stacking bit) is set to 1,
indicating this label is at the bottom of the stack, and that bit field 24 to 31 (time to live field) is set to 2 (as
recommended for pseudo-wire services).
R3. The reserved bit field (bits 20 to 31) SHOULD be ignored on reception by the TDM-bound ECDX.

6.2.2.2 CESoETH Control Word and its Usage


The CESoETH control word is added by the TDM-bound IWF. Its structure follows that described for the common
interworking indicators in [Y.1413], and is shown in Figure 6-5 below.
0 1 2 3 4 5 6 7 8 9 10 15 16 31
Reserved M FRG LEN (Length)
L R (2 bits) (2 bits) SN (Sequence Number) (16 bits)
set to zero (6 bits)

Figure 6-5: Structure of the CESoETH control word


In this diagram:
L Local TDM failure: when set, indicates that the MEN-bound IWF has detected or has been informed of a
TDM defect impacting the TDM data. When the L bit is set the contents of the frame may not be
meaningful, and the payload may be suppressed in order to conserve bandwidth.
R Remote Loss of Frames indication: when set by a MEN-bound IWF, the R bit indicates that its local
TDM-bound IWF is not receiving frames from the MEN, and consequently has entered a Loss of Frames
State (LOFS). Thus the setting of the R bit indicates failure of the connection in the opposite direction.
This may indicate MEN congestion or other network related faults.
M Modifier bits: set by the MEN-bound IWF to supplement the meaning of the L bit, as shown in Table 6-1
below:

L M
Interpretation
bit 4 bit 6 bit 7

0 0 0 Indicates no local TDM defect detected.


0 0 1 Reserved.
0 1 0 Reports the receipt of RDI at the TDM input to the MEN-bound IWF.
When this indication is received, a TDM-bound IWF may generate RDI in the local
TDM trunk, depending on local configuration options.
This is only applicable to structure-aware emulation.
0 1 1 CESoETH frames containing non-TDM data (e.g. signaling frames, see section 6.5).
1 0 0 Indicates a TDM defect that should trigger AIS generation at the TDM-bound IWF,
(e.g. LOS, AIS, or LOF in structure-aware operation), as specified in [G.705].

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

L M
Interpretation
bit 4 bit 6 bit 7

1 0 1 Reserved.
1 1 0 Reserved.
1 1 1 Reserved.

Table 6-1: Meaning of the Local TDM Failure Modification bits


FRG Fragmentation bits This field is used for fragmenting multiframe structures into multiple CESoETH
frames. The field is used as shown in Table 6-2 following:

FRG
Interpretation
bit 8 bit 9

0 0 Indicates that the entire multiframe structure is carried in a single CESoETH frame, or that
no multiframe structure is being indicated (e.g. for structure-agnostic emulation, or
structure-aware emulation without CAS or with CAS carried in separate signaling frames)
0 1 indicates the packet carrying the first fragment of the multiframe structure
1 0 indicates the packet carrying the last fragment of the multiframe structure
1 1 indicates a packet carrying an intermediate fragment of the multiframe structure

Table 6-2: Meaning of the Fragmentation bits


LEN Length This is an unsigned binary number indicating the length of the payload, should the CESoETH
frame require padding to meet the minimum frame size of 64 octets. The length of the payload is defined
as the sum in octets of the following quantities:
a. size of the CESoETH control word (4 octets)
b. size of the optional RTP header (12 octets, if present)
c. size of the TDM payload;
Where the length equals or exceeds 42 octets, the Length field shall be set to zero. Therefore a non-zero
length field indicates the presence of padding. (Note: the payload length does not include the size of the
ECID defined in section 6.2.2.1)
SN Sequence number a 16 bit unsigned binary number which increments by one for each frame sent. It
wraps to zero, in common with the behavior of the RTP sequence number. The receiving IWF uses it
primarily to detect frame loss and to restore frame sequence.
The following requirements apply to the CESoETH Control Word:
Requirements relating to the R bit:
R4. A TDM-bound IWF SHALL enter a Loss of Frames State (LOFS) following detection of a locally pre-
configured 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 pre-
configured 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.
Requirements relating to the L bit:

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

R8. For structure-agnostic emulation, an MEN-bound IWF MUST set the L bit to one when loss of signal
(LOS) is detected on the TDM service interface
R9. For structure-aware emulation, an MEN-bound IWF SHOULD set the L bit to one where the TDM circuit
indicates any of the following conditions:
a. Loss of Signal (LOS)
b. Alarm Indication Signal (AIS)
c. Loss of frame alignment (LOF)
R10. An MEN-bound IWF MUST clear the L bit as soon as the defect condition is rectified.
R11. A CESoETH frame with the L bit set to one MAY contain no TDM payload.
R12. For structure-agnostic emulation, on reception of CESoETH frames marked with the L bit set to one, the
TDM-bound IWF:
a. SHOULD discard the payload, and play out AIS code for the scheduled duration of the CESoETH
frame.
b. Depending on the application, and where the TDM payload has not been suppressed it MAY play out
the payload.
R13. For structure-aware emulation, on reception of CESoETH frames marked with the L bit set to one, the
TDM-bound IWF:
a. SHOULD discard the payload, and play out AIS for the scheduled duration of the CESoETH frame.
b. Depending on the application, it MAY generate trunk conditioning on the affected channels according
to [TR-NWT-000170].
c. Depending on the application, and where the TDM payload has not been suppressed it MAY play out
the payload.
Requirements relating to the M field:
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.
R15. Where an MEN-bound IWF is not capable of detecting the conditions described in Table 6-1, it MUST clear
the M field to zero on frames to be transmitted into the MEN.
R16. A TDM-bound IWF MUST silently discard a CESoETH frame where the M field is set to a value it does
not support.
Requirements relating to the Sequence Number field:
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.

6.2.2.3 Optional RTP Header


Where RTP is used, CESoETH uses the fields of the RTP header [RFC 3550] in the following way:

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

0 1 2 3 4 7 8 9 15 16 31

V=2 P X CC (4 bits) M PT (7 bits) SN (Sequence Number) (16 bits)

TS (Timestamp) (32 bits)

SSRC (Synchronization Source) (32 bits)

Figure 6-6: RTP Header Structure [RFC 3550]


The RTP header in CESoETH can be used in conjunction with at least the following modes of timestamp
generation:
Absolute mode: the MEN-bound IWF sets timestamps using the clock recovered from the incoming TDM
circuit. As a consequence, the timestamps are closely correlated with the sequence numbers. All CESoETH
implementations that support RTP must support this mode
Differential mode: The two IWFs at either end of the emulated circuit have access to the same high-quality
synchronization source, and this synchronization source is used for timestamp generation. As a consequence,
the second derivative of the timestamp series represents the difference between the common timing source and
the clock of the incoming TDM circuit. Support of this mode is optional.
R19. The support of RTP by a CESoETH implementation is OPTIONAL.

Where used, the following requirements apply to the RTP header:


R20. The following fields in the RTP header MUST always be set to fixed, pre-determined values:
a. The version number (V) field MUST always be set to 2.
b. The padding field (P) MUST always be set to 0.
c. The header extension (X) field MUST always be set to 0.
d. The CSRC count (CC) field MUST always be set to 0.
e. The marker field (M) MUST always be set to 0.
R21. The payload type (PT) field is determined as follows:
a. One PT value MUST be allocated from the range of dynamic values (see [RTP TYPES]) for each
direction of the emulated circuit. The same PT value MAY be reused for both directions of the
emulated circuit, and also reused between different emulated circuits
b. The MEN-bound IWF MUST set the PT field in the RTP header to the allocated value
c. The TDM-bound IWF MAY use the received value to detect malformed packets
R22. The Sequence number (SN) MUST be identical to the sequence number in the control word.
R23. The Timestamp (TS) field MUST be generated and processed in accordance with the rules established in
[RFC 3550].
R24. CESoETH implementations supporting RTP MUST support the use of absolute mode timestamps, where
the clock used to generate the timestamp is that recovered from the incoming TDM circuit.
R25. CESoETH implementations supporting RTP MAY support the use of differential mode timestamps where
the clock used to generate the timestamp is derived from a common timing source.

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

R26. CESoETH implementations supporting RTP MUST support the use of absolute mode timestamps
generated using an 8 kHz clock. Other frequencies that are integer multiples of 8 kHz MAY be used.
R27. CESoETH implementations supporting differential mode MUST support the use of timestamps generated
using a 25 MHz clock. Other frequencies MAY be used providing they are:
a. Integer multiples of 8 kHz
b. Not an integer multiple of the clock frequency of the TDM circuit
R28. The synchronization source (SSRC) field MUST be generated and processed in accordance with the rules
established in [RFC 3550].
R29. The SSRC field MAY be used by the TDM-bound IWF for the detection of misconnections.

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

6.3 PAYLOAD FORMATS


This Implementation Agreement covers four payload formats:
1. Structure-agnostic emulation (section 6.3.1)
2. Octet-aligned payload for structure-agnostic emulation of DS1 circuits (section 6.3.1.1)
3. Structure-aware emulation using structure-locked encapsulation (section 6.3.2)
4. Structure-aware emulation using structure-indicated encapsulation (section 6.3.3)
Structure-agnostic emulation is the transport of unstructured TDM, or of structured TDM when the structure is
completely disregarded by the transport mechanism. It maintains the precise bit sequence of data and any structure
overhead that may be present, and provides no mechanisms for the location or utilization of a Frame Alignment
Signal (FAS).
Structure-aware emulation is the transport of structured TDM taking at least some level of the structure into account.
It is not required to carry all bits of the TDM bit-stream over the MEN; specifically, the FAS may be stripped at
ingress and regenerated at egress.
R30. A CES IWF MUST support structure-agnostic emulation, as defined in section 6.3.1. The use of the octet-
aligned payload format for DS1, or either of the structure-aware encapsulation formats is OPTIONAL.

6.3.1 Structure-Agnostic Emulation


This implementation agreement defines the structure-agnostic emulation of the following TDM services:
DS1, as defined in [G.702, T1.102]
E1, as defined in [G.702]
DS3, as defined in [G.702, T1.102]
E3, as defined in [G.751]
The payload format is as described in [Y.1413], sub-clause 9.1. The following additional requirements also apply:
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.

6.3.1.1 Octet-aligned Payload for Structure-Agnostic Emulation of DS1 Circuits


DS1 circuits may be delivered to the ingress IWF padded to an integer number of octets, as described in [G.802]
Annex B. This padded data may be transported directly over the MEN using a payload format that consists of an
integer number of 25-octet sub-frames, each sub-frame consisting of 193 bits of TDM data and 7 bits of padding.
This is described in [Y.1413], sub-clause 9.1.1.
The following additional requirements apply:
R32. The TDM-bound IWF MUST NOT assume any alignment with the underlying DS1 framing structure

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

R33. CESoETH implementations supporting octet aligned DS1 MUST support a TDM payload size of 200 octets
(including padding). The use of any other payload size is OPTIONAL.

6.3.2 Structure-Aware Emulation using Structure-Locked Encapsulation


This implementation agreement defines the structure-aware emulation of the following TDM services using a
structure-locked encapsulation, as described in [Y.1413], sub-clause 9.2.1:
N x 64kbit/s basic service
N x 64kbit/s service with Channel Associated Signaling (CAS) for the following specific TDM trunk types:
DS1 with framing according to the Extended Super Frame (ESF) format, as described in [T1.107]; or 24
frame multiframe as described in [G.704]
DS1 with framing according to the Super Frame (SF) format, as described in [T1.107]; or 12 frame
multiframe as described in [G.704]
E1 with framing according to the CRC-4 Multiframe format, as described in [G.704]
Note that application signaling such as CAS may also be transported using the generic method described in section
6.5.
The following general additional requirements apply:
R34. The timeslots to be placed into the payload need not be contiguous, and the payload MAY 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).
R37. For implementations supporting structure-locked encapsulation, the support of N x 64kbit/s service with CAS
is OPTIONAL.
The following additional requirements apply specifically to the support of N x 64kbit/s basic service using structure-
locked encapsulation:
R38. A CESoETH structure-locked implementation supporting N x 64kbit/s basic service MAY support values of
N larger than 31 (i.e. the implementation may be capable of selecting DS0s off multiple TDM circuits, where
these TDM circuits are synchronous, or from a synchronous TDM bus system).
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 milliseconds (with the corresponding TDM payload size of 32N octets).
c. For N = 1: 8 milliseconds (with the corresponding TDM payload size of 64N octets).
Usage of any other packetization latency (TDM payload size) is OPTIONAL.
Note: these values increase for low values of N to avoid excessive inefficiency in the bandwidth utilisation.
For example, for N=5, the payload size is 40 octets, which results in a bandwidth efficiency of only 60% due
to the size of the header and FCS (26 octets).
The following additional requirements apply specifically to the support of N x 64kbit/s service with CAS using
structure-locked encapsulation:
R40. The payload structure MUST be composed of exactly M TDM frames, plus one signaling sub-structure.
Specifically for each type of TDM trunk:

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

a. For DS1 with ESF multiframes, M = 24 (one ESF, or 24 frame multiframe)


b. For DS1 with SF multiframes, M = 24 (two SFs, or two 12-frame multiframes)
c. For E1 with CRC-4 multiframes, M = 16 (one CRC-4 multiframe)
R41. The format of the signaling sub-structures for each specific TDM trunk MUST be as defined in [ATM-CES],
section 2.3.1.2.
R42. Each CESoETH frame MUST carry the same number of TDM frames of data, regardless of whether it
contains the signaling sub-structure or not.
R43. In case of a DS1 circuit, the signaling bits are carried in the TDM data as well as in the signaling sub-
structure. However, the TDM-bound IWF MUST use the CAS bits carried in the signaling sub-structures.
Note: there is no guarantee of alignment between the 24-frame structure carried in the payload, and the
multiframe structure of the DS1 circuit. Hence there is no way of determining which are the signaling bits.
R44. All CESoETH structure-locked implementations supporting trunk-specific Nx64kbit/s with CAS MUST
support the default mode where a single CESoETH packet carries exactly one payload structure, with one
signaling sub-structure.

6.3.3 Structure-Aware Emulation using Structure-Indicated Encapsulation


This implementation agreement defines the structure-aware emulation of the following TDM services using a
structure-indicated encapsulation, as described in [Y.1413], sub-clause 9.2.2:
N x 64kbit/s basic service
N x 64kbit/s service with Channel Associated Signaling (CAS) for the following specific TDM trunk types:
DS1 with framing according to the Extended Super Frame (ESF) format, as described in [T1.107]; or 24
frame multiframe as described in [G.704]
DS1 with framing according to the Super Frame (SF) format, as described in [T1.107]; or 12 frame
multiframe as described in [G.704]
E1 with framing according to the CRC-4 Multiframe format, as described in [G.704]
This encapsulation first adapts the TDM bit stream using AAL Type 1, as defined in [I.363.1] and [ATM-CES].
The following additional requirements apply:
R45. All compliant implementations that support structure-indicated encapsulation for DS1 and E1 service MUST
support 1 AAL1 PDU per frame, and SHOULD support from 2 to 8 AAL1 PDUs per frame.
Support for more PDUs per frame is OPTIONAL.
R46. For implementations supporting structure-indicated encapsulation, the support of N x 64kbit/s service with
CAS is OPTIONAL.
Note: the AAL type 1 adaptation described here may also be used for structure-agnostic transport. Examples
where this may be beneficial are when interworking with ATM-based circuit emulation systems, or when
SRTS-based clock recovery is used. When this is used for DS3 or E3 service, it is recommended that
implementations support from 4 to 15 AAL1 PDUs per frame.

6.4 SYNCHRONIZATION
Synchronization is an important consideration in any circuit emulation scheme. Put simply, the clock used to play
out the data at the TDM-bound IWF must be the same frequency as the clock used to input the data at the MEN-
bound IWF, otherwise frame slips will occur over time. Architectures for synchronization and clock recovery are
discussed in more detail in [MEF 3].

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

Summarized, there are four basic options for the TDM clock to the TDM-bound IWF, shown in Figure 6-7::
use the clock from the incoming TDM line (TDM line timing)
use an external reference clock source (External timing)
use a free-running oscillator (Free run timing)
recovering the clock from the Ethernet interface (Ethernet line timing)
The last option, Ethernet line timing, covers all methods where information is extracted from the Ethernet,
including:
adaptive timing, where the clock is recovered from data in the CESoETH frames, and the arrival time of the
frames
differential timing, where the clock is recovered from a combination of data contained in the CESoETH
frames, and knowledge of a reference clock common to both the MEN-bound and TDM-bound IWFs. Such a
reference may be distributed by a variety of means.
For maximum applicability, it is recommended that CESoETH implementations should support at least TDM line,
external and adaptive timing. This will enable the implementation to be used in the majority of timing scenarios.
However, not every combination of timing options for the TDM-bound IWFs on either side of the MEN will yield
performance capable of meeting R47, so care must be taken to ensure the combinations chosen are appropriate.
External Timing
Reference

CESoETH IWF

Clock
MEN-bound
Data
IWF TDM Ext.
To TDM Line To MEN
(or TSP) Clock Clock Eth.
TDM-bound Line Clock
Data Recovery
IWF Data

Free
Run

Figure 6-7: Synchronization Options for the TDM-bound IWF


The following synchronization requirements are placed on a CESoETH implementation. Certain applications may
require the use of more stringent requirements.
R47. The method of synchronization used MUST be such that the TDM-bound IWF meets the traffic interface
requirements specified in ITU-T recommendations [G.823] for E1 and E3 circuits, and [G.824] for DS1 and
DS3 circuits.
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.
Note: The requirements set forth in [G.824] are consistent with DS1/DS3 interface requirements specified in
Telcordias [GR-253-CORE]. The pertinent traffic interface requirement is R5-237.

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

6.5 TDM APPLICATION SIGNALING


CE applications interconnected over a CESoETH service may exchange signaling in addition to TDM data. The
typical example is telephony applications that exchange their state (e.g. off-hook/on-hook) in addition to TDM data
carrying PCM-encoded voice.
With structure-agnostic emulation, it is not required to intercept or process CE signaling. Signaling is embedded in
the TDM data stream, and hence it is carried end-to-end across the emulated circuit.
With structure-aware emulation, transport of Common Channel Signaling (CCS) may be achieved by carrying the
signaling channel with the emulated service (e.g. channel 23 for DS1, or channel 16 for E1). However, Channel
Associated Signaling (CAS) (e.g. DS1 Robbed Bit Signaling or E1 CAS) requires knowledge of the relationship of
the timeslot to the trunk multi-frame structure. This is indicated by the framing bits, which may not be preserved by
N x 64 kbit/s basic service.
This section describes a generic method for extending the Nx64kbit/s basic service by carrying CE signaling (CAS
or CCS) in separate signaling packets that is independent of the TDM circuit type. It may be used in situations
where the individual 64kbit/s channels are selected from multiple TDM circuits, or picked off a TDM bus rather
than from a specific TDM circuit. It also saves MEN bandwidth, since only changes in the CE application state are
carried.

6.5.1 CE Signaling Frames


The generic format of the CE signaling frames corresponds to the format shown in Figure 6-1 and the requirements
expressed in section 6.2. The following additional requirements apply:
R49. CESoETH data frames and their associated signaling frames MUST have the same:
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.
Note: Establishment of correspondence between the ECIDs used by the matching data and signaling frames
is outside the scope of this Implementation Agreement.
R51. CESoETH data frames and their associated signaling frames MUST use a separate sequence number space.
R52. If the RTP header is used:
a. Data frames and associated signaling frames MUST use a different payload type value (both allocated
from the range of dynamically allocated RTP payload types).
b. Data frames and associated signaling frames MUST use a different SSRC value.
c. The timestamp values for the data and associated signaling frames MUST be identical at any given
time.
Note: This enables synchronization of the signaling and data information using the standard RT-
based mixing procedures described in [RFC 3550].

6.5.2 Channel Associated Signaling (CAS) Frames


In the case where the CE application interconnected by a basic Nx64kbit/s CESoETH service is a telephony
application using Channel Associated Signaling (CAS), the following additional rules apply to generation and
processing of signaling packets:

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

R53. The payload of each signaling frame MUST comprise N 32-bit words (where N is the 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
6-8, 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)

Figure 6-8: Encoding Format for CAS ABCD values from [RFC 2833]
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
R56. A signaling frame SHOULD be sent every 5s in the absence of any of the events described in R55, except
when there is a failure of the local TDM circuit leading to the L flag being set in the associated data frames
(see R9).

6.5.3 Common Channel Signaling (CCS) Frames


The use of separate signaling frames to carry CE signaling where the application uses Common Channel Signaling
(CCS) is left for further study.

6.6 CESOETH DEFECTS


CESoETH defects may be caused in three ways: the behavior of the TDM service to be emulated, the behavior of
the MEN, and the behavior of the IWF itself. The following defects are considered in this section:
Defects caused by behavior of the TDM service are covered by section 6.2.2.2 describing the control word
(specifically the requirements relating to the L-bit).
Defects caused by MEN behavior:
Misconnection of CESoETH frames (section 6.6.1)
Reordering and Loss of Frames (section 6.6.2)
Late arriving CESoETH frames (section 6.6.3)
Defects caused by IWF behavior:
Malformed Frames (section 6.6.4)
Jitter Buffer Overrun and Underrun Defects (section 6.6.5)

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

6.6.1 Misconnection
Should a frame be wrongly directed to a CES IWF, it is possible for it to be mis-interpreted as a genuine CESoETH
frame, especially if the first word of the payload match a known emulated circuit ID value. In order to detect such
stray frames, the following rules should be applied:
R57. The CES IWF MUST only accept frames that contain the correct Ethernet destination address field and
ECID value for that IWF.
R58. The CES IWF SHOULD provide additional protection by checking the Ethernet source address field against
the known source address of the given emulated circuit ID.
R59. Where RTP is being used, further protection MAY be provided by checking the value of the SSRC field
against the known SSRC value of the given emulated circuit ID.
R60. When a stray frame is detected by a CES IWF, it MUST be discarded.
R61. If the percentage of stray frames persists above a defined level for a configurable period of time (by default,
2.5 seconds), the Misconnection alarm SHOULD be reported to the management system.
R62. The Misconnection alarm SHOULD be cleared if no stray frames have been detected for a configurable
period of time (by default, 10 seconds).
R63. The mechanisms for detection of lost frames (e.g. expected next sequence number) MUST NOT be affected
by reception of stray frames.

6.6.2 Reordering and Loss of Frames


Detection of out-of-sequence or lost CESoETH frames is accomplished by use of the sequence number, either from
the RTP header or the CESoETH control word. The following rules apply to re-ordering and lost frames.
R64. Emulated circuits that use the RTP header MUST use the sequence number from the CESoETH control
word, and ignore the sequence number (if any) in the RTP header.
R65. CESoETH implementations SHOULD attempt to re-order out-of-sequence frames where they arrive in time
to be played out
R66. Out-of-sequence CESoETH frames that cannot be re-ordered MUST be discarded, and considered as lost.
R67. If loss of one or more CESoETH frames is detected by the TDM-bound IWF, it MUST generate exactly one
replacement octet for every lost octet of TDM data.
R68. All CESoETH implementations SHOULD support the following methods of generating replacement data:
a. For structure-agnostic service, generate AIS code for the scheduled duration of the CESoETH frame.
b. For Nx64kbit/s service with and without CAS, generate locally configured idle code for the scheduled
duration of the CESoETH frame.
c. For Nx64kbit/s service with CAS, use either the previous value of the CAS data, or a pre-defined
value for each of the 64kbit/s channels.
Depending on the application, other methods of generating replacement data MAY be used (e.g. frame loss
concealment techniques, or replay of the last received CESoETH frame).
R69. If the Frame Loss Ratio (as defined in [MEF 5]) persists above a defined threshold for a configurable period
of time (by default, 2.5 seconds), a Loss of Frames alarm SHOULD be sent to the management system.
R70. The Loss of Frames alarm SHOULD be cleared if Frame Loss Ratio remains below a defined threshold for a
configurable period of time (by default, 10 seconds).

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

6.6.3 Late Arriving Frames


On occasions, the frame delay variation may be abnormally large, leading to CESoETH frames arriving after their
scheduled playout time, although the jitter buffer may not necessarily be full. These frames are effectively lost, and
may already have been considered as lost frames.
The following requirements apply to late arriving frames:
R71. A CESoETH IWF MUST discard frames that arrive too late to be played out on the TDM interface.
R72. If the percentage of frames arriving too late to be played out exceeds a defined level for a configurable period
of time (by default, 2.5 seconds), a Late Frame alarm SHOULD be sent to the management system.
R73. The Late Frame alarm SHOULD be cleared if the percentage of frames arriving too late to be played out
stays under a defined threshold for a configurable period of time (by default, 10 seconds).

6.6.4 Malformed CESoETH Frames


A malformed CESoETH frame is one that is not a stray frame and either or both of the following conditions apply:
If RTP is used, the PT value in its RTP header does not correspond to one of the PT values allocated for this
direction of the emulated circuit.
For CESoETH frames containing valid TDM data with the defect indicator L=0, and for which the actual
payload size can be unambiguously determined, the payload size does not match the size defined for this flow.
R74. If a malformed frame is received by the TDM-bound IWF in time to be played out to the TDM interface, it
SHOULD:
a. Discard the malformed frame
b. generate exactly one replacement octet for every lost octet of TDM data
R75. All CESoETH implementations SHOULD support the following methods of generating data to replace a
malformed frame:
a. For structure-agnostic service, generate AIS code for the scheduled duration of the CESoETH frame.
b. For Nx64kbit/s service with and without CAS, generate locally configured idle code for the scheduled
duration of the CESoETH frame.
c. For Nx64kbit/s service with CAS, use either the previous value of the CAS data, or a pre-defined
value for each of the 64kbit/s channels
Depending on the application, other methods of generating replacement data MAY be used (e.g. frame loss
concealment techniques, or replay of the last received CESoETH frame).
R76. If the percentage of malformed CESoETH frames persists above a defined level for a configurable period of
time (by default, 2.5 seconds), a Malformed Frames alarm SHOULD be sent to the management system.
R77. The Malformed Frames alarm SHOULD be cleared if no malformed packets have been detected for a
configurable period of time (by default, 10 seconds).

6.6.5 Jitter Buffer Overrun and Underrun Defects


The TDM-bound IWF contains a jitter buffer that accumulates data from incoming CESoETH frames. The main
purpose of this jitter buffer is to smooth out variation in arrival time of the CESoETH frames. Data is played out of
the jitter buffer onto the TDM service at constant rate. The delay through this buffer needs to be as small as
possible, in order to reduce latency of the TDM service, but large enough to absorb known variation in the frame
delay (FDV, sometimes known as frame jitter, see [MEF 5]).

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

However, there may be occasions when the frame delay variation is abnormally large, and either overrun or
underrun conditions may occur. These conditions may also occur when the clock used for playout of the TDM data
from the jitter buffer is not at precisely the same frequency as the original TDM service clock presented to the
MEN-bound IWF.
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. The Jitter Buffer
Underrun condition occurs when there is no correctly received CESoETH payload ready to be played out on the
TDM interface, and replacement data must be played out instead. Primarily this occurs due to frames lost in the
MEN, or discarded due to error conditions, hence this is not usually identified separately.
The following requirements apply to the detection of jitter buffer defects:
R78. A CESoETH IWF MUST detect the Jitter Buffer Overrun conditions.
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.
R80. If the percentage of frames causing Jitter Buffer Overruns persists above a defined level for a configurable
period of time (by default, 2.5 seconds), a Jitter Buffer Overrun alarm SHOULD be sent to the management
system.
R81. The Jitter Buffer Overrun alarm SHOULD be cleared if no cases of jitter buffer overrun have been detected
for a configurable period of time (by default, 10 seconds).

6.7 PERFORMANCE MONITORING

6.7.1 Facility Data Link


R82. CESoETH implementations supporting DS1 circuit using ESF framing MAY monitor messages carried in
the FDL (Facility Data Link). For example, it may be required to monitor Performance Report Messages, as
described in [T1.403].
R83. CESoETH implementations supporting DS1 circuit using ESF framing MUST NOT change messages
carried in the FDL (Facility Data Link), or insert new messages.

6.7.2 Errored Data


References [T1.510] and [G.826] define the concept of an errored second and severely errored second. These
measures are used to monitor the integrity of the TDM connection. All events in the TDM-bound IWF which lead
to replacement data being played out (except when a result of receiving a CESoETH packet with an AIS or Idle
Code indication) give rise to errored seconds (or potentially, severely errored seconds.
The collective sum of all these errors can be aggregated into a single measure termed Frame Error Ratio (FER),
defined in [MEF 3] as the number of errored (i.e. lost or discarded) CESoETH frames, over the total number of
CESoETH frames sent. This is similar to the overall loss ratio defined for voice services over IP networks in
[G.1020]. This includes situations where the CESoETH frame:
a. fails to arrive at the TDM-bound IWF (i.e. is lost in MEN)
b. arrives too late to be played out
c. arrives too early to be accommodated in the jitter buffer
d. arrives with bit errors causing the frame to be discarded
The following requirements apply to monitoring of the FER:

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

R84. A CESoETH implementation SHOULD be capable of monitoring the Frame Error Ratio (FER) performance
of the CESoETH connection.

7. Service Initiation and Operation


7.1 COMMON CONSIDERATIONS
Edge-to-edge service emulation of a TDM service using CESoETH assumes the following elements:
Two end services of the same type and bit rate
Packetizer at the MEN-bound CES IWF
Jitter buffer and de-packetizer at the TDM-bound CES IWF.
Setup and teardown of CESoETH emulated circuits is based on exchange of service parameters between the two
CES IWFs at either end of the emulated circuit. This may be done manually, or using an auto-negotiation process.
The nature of a suitable auto-negotiation process is for further study.

7.2 CESOETH SERVICE PARAMETERS


The following parameters need to be assigned when an emulated circuit is set up.

1) Service Type
The following service types are defined for CESoETH services. The service type must be the same for each
direction of the emulated circuit (i.e. no service interworking is peformed).
Structure-agnostic E1
Structure-agnostic DS1
Structure-agnostic E3
Structure-agnostic DS3
Nx64kbit/s Basic Service using structure-locked encapsulation
Nx64kbit/s Basic Service using structure-indicated encapsulation
E1 Nx64kbit/s with CAS using structure-locked encapsulation
E1 Nx64kbit/s with CAS using structure-indicated encapsulation
DS1 (ESF) Nx64kbit/s with CAS using structure-locked encapsulation
DS1 (ESF) Nx64kbit/s with CAS using structure-indicated encapsulation
DS1 (SF) Nx64kbit/s with CAS using structure-locked encapsulation
DS1 (SF) Nx64kbit/s with CAS using structure-indicated encapsulation

2) TDM Bit Rate


For structure-aware N x 64kbit/s services of any encapsulation type, this is defined as the number of 64 kbit/s
channels carried by the emulated circuit (i.e. the value of N). It is the same for each direction of the emulated
circuit.
This parameter is not applicable for structure-agnostic emulation.

3) Payload size

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

This is defined as the number of octets of TDM payload carried in each CESoETH frame. It is the same for
each direction of the emulated circuit.
For structure-aware, structure-locked encapsulation of N x 64kbit/s service with CAS (section 6.3.2), this
EXCLUDES the CAS sub-structure carried in the last frame of every structure.
For structure-indicated encapsulation (section 6.3.3), this parameter is 48 times the number of AAL1 PDUs per
CESoETH frame.

4) Emulated Circuit Identifier (ECID)


A 20-bit value identifying the emulated circuit being carried. It is defined according to the rules specified in
section 6.2.2.1. A separate ECID is assigned for each direction of the emulated circuit.

5) TDM clock source for the TDM-bound IWF


Section 6.4 describes the various clocking options for the TDM-bound IWF. These may be different for the
IWFs on either side of the MEN. Operators must ensure that the combination of options chosen meets the
synchronization quality target for the application.

6) RTP
This boolean parameter specifies whether the RTP header is to be used or not.

7) Use of Generic TDM Application Signaling Method


Boolean value specifying whether the generic TDM application signaling method described in section 6.5 is to
be used or not.

8) Use of an extended 64-bit control word


Boolean value specifying whether the control word is to be extended from 32 bits to 64. Where an extended
control word is selected, the extension applies to both directions of the emulated circuit, and remains unchanged
throughout the lifetime of the circuit. The definition of the bits in the extended control word is reserved.

The following additional parameters need to be assigned if RTP is used:

9) Payload Type
The value to be used for the Payload Type field, as described in section 6.2.2.3.

10) Timestamp mode


This parameter defines the mode to be used for generation of the RTP timestamp. It may take two values,
absolute or differential, as described in section 6.2.2.3.

11) Timestamp resolution


This parameter encodes the bit rate of the clock used for setting the timestamps in RTP headers as a multiple of
the basic 8kHz rate (e.g. a bit rate clock for an E1 circuit would be encoded as 256).

12) SSRC Value


The value to be used for the SSRC field, as described in section 6.2.2.3.

The following additional parameters need to be assigned if generic TDM signaling (section 6.5) is used:

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

13) Emulated Circuit Identifier (ECID) for signaling frames


A 20-bit value identifying the emulated circuit being carried. It is defined according to the rules specified in
section 6.2.2.1.

14) Payload Type


The value to be used for the Payload Type field in signaling frames, as described in section 6.2.2.3.

15) SSRC Value


The value to be used for the SSRC field in signaling frames, as described in section 6.2.2.3.

7.3 CESOETH LOCAL CONFIGURATION PARAMETERS


The following parameters are configured locally:

1) Control Word Parameters (see Section 6.2.2.2)


Number of consecutive lost frames after which the R flag is set in the control word (see R4)
Number of consecutive received frames after which the R flag is cleared in the control word (see R5)
Action on receipt of frame containing the R flag set (see R6)
Conditions that will cause the L flag to be set in the control word (see R9)
Payload suppression on packets with L bit set (see R11)
Action on receipt of frame containing the L flag set (see R12, R13)
Action on receipt of a packet containing L=0, M=10 (see Table 6-1)

2) Defect and Alarm Parameters


Replacement data for lost or discarded frames (see R68, R75)

The following locally configured parameters are applicable to all defect alarms:
Duration of high defect level after which the relevant alarm is triggered (default is 2.5s)
Duration of low defect level after which the relevant alarm is cleared (default is 10s)

The following locally configured parameters are relevant to the triggering of the individual defect alarms:
Percentage of misconnection occurrences above which the Misconnection alarm is triggered (see R61)
Frame loss ratio above which the Loss of Frames alarm is triggered (see R69)
Percentage of late arriving frame occurrences above which the Late Frame alarm is triggered (see R72)
Percentage of malformed frame occurrences above which the Malformation alarm is triggered (see R76)
Percentage of jitter buffer overrun occurrences above which the Jitter Buffer Overrun alarm is triggered
(see R80)

The following locally configured parameters are relevant to the clearing of the individual defect alarms. The
remainder of the alarms are cleared by a period of absence of the alarm condition.
Frame loss ratio below which the Loss of Frames alarm is cleared (see R70)
Percentage of late arriving frame occurrences below which the Late Frame alarm is cleared (see R73)

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

8. MEN Requirements
8.1 MEN SERVICE TYPE
Both T-Line and TALS versions of the CESoETH service are run across point-to-point EVCs (i.e. across an E-
Line service type). In the simplest case of a pair of IWFs connected by an E-Line service, the Ethernet service
resembles an EPL (Ethernet Private Line). However, in many cases several IWFs may share an Ethernet UNI (and
in fact, several IWFs could also share an EVC). Therefore in general the Ethernet service required more closely
resembles an EVPL (Ethernet Virtual Private Line). Both the EPL and EVPL services are normatively described in
[MEF 6].
Figure 8-1 shows a typical configuration where several small sites may be connected to some larger sites over point-
to-point EVCs. Any service multiplexing is performed in the TDM domain as part of the TSP (TDM Service
Processing) function.

Figure 8-1: Example TDM Virtual Private Line Configurations

8.2 SERVICE ATTRIBUTES


Table 6-1 shows typical values of the service attributes for the underlying Ethernet service used to carry the
CESoETH application (see [MEF 1 and [MEF 6]:

UNI Service Attribute Service Attribute Parameters and Values


UNI Identifier Arbitrary text string to identify the UNI.
Physical Medium IEEE 802.3-2002 Physical Interface
Speed 10 Mbps, 100 Mbps, 1 Gbps or 10 Gbps
Mode Full Duplex
MAC Layer IEEE 802.3-2002
Service Multiplexing Yes (if multiple EVCs are supported on the same UNI)

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

UNI Service Attribute Service Attribute Parameters and Values


UNI EVC ID Arbitrary text string to identify each EVC instance
CE-VLAN ID / EVC Map Mapping table of CE-VLAN IDs to E-Line Service type UNI EVC IDs.
Maximum number of EVCs >= 1
Bundling No
All to One Bundling No (if multiple EVCs are supported on the same UNI)
Ingress Bandwidth Profile Per Ingress
No
UNI
CIR, CBS sufficient to handle the constant bit rate TDM flow
Ingress Bandwidth Profile Per EVC EIR, EBS, set to zero
Coupling flag (CF) set to zero
No (although bandwidth profile could equally well be supported on per
Ingress Bandwidth Profile Per CoS
CoS basis rather than per EVC, e.g. where a subscriber runs both
Identifier
CES and data traffic over the same EVC)
Discard IEEE 802.3x MAC Control (Pause) Frames with a destination
MAC address 0x0180C2000001
Layer 2 Control Protocol Processing (real-time, constant bit rate services cannot be paused)
Peer, Discard or Pass to EVC all remaining protocols

EVC Service Attribute Service Attribute Parameters and Values


EVC Type Point-to-Point
UNI List List the two UNIs associated with the EVC.
CE-VLAN ID Preservation Yes or No
CE-VLAN CoS Preservation Yes or No
Unicast Service Frame Delivery Deliver Unconditionally
Multicast Service Frame Delivery Deliver Unconditionally
Broadcast Service Frame Delivery Deliver Unconditionally
Layer 2 Control Protocols Processing Discard or Tunnel all remaining protocols
Frame Delay as required for application, and to meet TDM standards
Frame Delay Variation as required for application, and to meet TDM
Classes of Service
standards
Frame Loss as required for application, and to meet TDM standards

Table 8-1: Example Service Attributes for an EVPL or EPL service carrying CESoETH traffic

8.2.1 Bandwidth Provisioning


R85. In order to be able to provision bandwidth efficiently for an emulated circuit, the MEN SHOULD be able to
provision bandwidth in increments of 100 kbit/s.

8.3 COS PERFORMANCE PARAMETERS


To ensure proper operation of the CES IWF the MEN will have to provide certain levels of service quality. These
level are defined as follows:

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

8.3.1 Ethernet Frame delay


End-to-end delay requirements are application-specific, and hence beyond the scope of this specification. Delay
sensitive applications include voice services and 2 way video services such as video conferencing. In these cases
delay in a MEN should be kept to a minimum by specifying that Ethernet Virtual Connections that carry delay
sensitive CES traffic be given the highest service priority to avoid queuing of data in intermediary network switches.
It is expected that in most Metro Ethernet Networks, the frame delay will be low enough to allow deployment of
CESoETH without the need for voice echo cancellation, although this should be verified at the time of deployment.
Frame Delay for Metro Ethernet Networks is defined in [MEF 5].

8.3.2 Ethernet Frame Delay Variation


Ethernet frame delay variation (variation in frame inter-arrival time) will hinder the recovery of the clock
synchronization if adaptive clock recovery techniques are used. As well the play-out buffer in the receiver IWF
must be sized to prevent underflow and overflow conditions based on the amount of frame delay variation that is
present.
Frame Delay Variation for Metro Ethernet Networks is defined in [MEF 5].
R86. The CES IWF SHOULD be capable of functioning correctly (i.e. satisfying the requirements in MEF 3)
when used in conjunction with MEN Ethernet Virtual Circuits with a Frame Delay Variation of up to 10 ms
(specified with a percentile, P of 99.9%, t of 900s over a time interval, T of 3600s).

8.3.3 Ethernet Frame Loss


The loss of an Ethernet frame carrying circuit emulation traffic will result in a burst of bit errors in the reconstructed
data stream. However, since circuit emulation traffic is real time data, errors are caused not only by lost frames, but
also by frames arriving too late to be played out onto the TDM interface. Similarly, corrupted frames may also
cause burst errors if they are discarded due to a bad Ethernet frame check sequence.
The collective sum of all the above errors (frame loss, excess frame delay and bit errors) can be aggregated into a
single measure termed Frame Error Ratio (FER) (see section 6.7.2). The relationship between FER and the TDM
performance metrics, ESR (errored seconds ratio) and SESR (severely errored seconds ratio) is discussed in section
7.5 of [MEF 3]. Performance objectives for ESR and SESR in TDM networks are given in [T1.510] for DS1 and
DS3, and in [G.826] for E1 and E3.
Operators should therefore ensure that an EVC has sufficient quality to support an ESR (errored seconds ratio) and
an SESR (severely errored seconds ratio) on the TDM service that meets the relevant TDM standards.

8.3.4 Network Availability


Section 7.5.6 of [MEF 3] gives guidance as to the Frame Error Ratio that may cause a TDM service to become
unavailable according to the availability definitions in the relevant TDM standards. Network availability objectives
for TDM circuits are specified in [T1.510] for DS1 and DS3, and in [G.827] for E1 and E3. Typically these are
99.95% for the access segment of the network.
Operators should therefore ensure that an EVC has sufficient quality to support an availability ratio on the TDM
service of 99.95% or better when used to carry emulated TDM services.

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

9. Management
9.1 ALARMS
Alarms relating to TDM defects must be raised by the first network element that detects the defect. For example, in
the case of loss of signal (LOS), this should be raised by the TDM service processor or physical layer device
connected to the TDM circuit. Hence the IWF is not required to generate alarms for TDM defects.
Alarms relating to defects in the MEN are specified in the relevant sections of this document (see section 6.6).
These include:
Misconnection alarm (section 6.6.1)
Loss of Frames alarm (section 6.6.2)
Late Frames alarm (section 6.6.3)
Malformed Frames alarm (section 6.6.4)
Jitter buffer overrun alarm (section 6.6.5)

9.2 STATISTICS COUNTERS


This section describes the statistics that should be maintained. This list has been based on a set of MIBs currently
under development within the IETFs PWE3 working group.
R87. An MEN-bound CES IWF SHOULD maintain the following statistics:
a. number of CESoETH frames transmitted
b. number of payload octets transmitted
R88. A TDM-bound CES IWF SHOULD maintain the following statistics:
a. number of CESoETH frames received
b. number of payload octets received
c. number of lost frames detected (see section 6.6.2)
d. number of frames received that are out-of-sequence, but successfully re-ordered (see section 6.6.2)
e. number of transitions from the normal to the loss of frames state (LOFS) (see R4)
f. number of malformed frames received (see section 6.6.3)
g. number of jitter buffer overruns (section 6.6.5)
h. number of jitter buffer underruns (section 6.6.5)

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

10. 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, May 2000, http://www.ietf.org/rfc/rfc2833.txt
RFC 3550 RTP: A Transport Protocol for Real-Time Applications, RFC3550, H. Schulzrinne et al,
September 2003, http://www.ietf.org/rfc/rfc3550.txt
RTP TYPES RTP Payload types (PT) for standard audio and video encodings Closed,
http://www.iana.org/assignments/rtp-parameters
G.702 Digital hierarchy bit rates, ITU-T Recommendation G.702, November 1988
G.704 Synchronous Frame Structures used at 1544, 6312, 2048, 8448 and 44736 Hierarchical Levels,
ITU-T Recommendation G.704, October 1998
G.705 Characteristics of plesiochronous digital hierarchy (PDH) equipment functional blocks, ITU-T
Recommendation G.705, October 2000
G.751 Digital multiplex equipments operating at the third order bit rate of 34 368 kbit/s and the fourth
order bit rate of 139 264 kbit/s and using positive justification, ITU-T Recommendation G.751,
November 1988
G.802 Interworking between networks based on different digital hierarchies and speech encoding
laws, ITU-T Recommendation G.802, November 1988
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.826 Error performance parameters and objectives for international, constant bit rate digital paths at
or above the primary rate, ITU-T Recommendation G.826, February 1999
G.827 Availability performance parameters and objectives for international, constant bit rate digital
paths at or above the primary rate, ITU-T Recommendation G.827, September 2003
G.1020 Performance Parameter Definitions for Quality of Speech and other Voiceband Applications
Utilising IP Networks, ITU-T Recommendation G.1020, November 2002
I.231.1 Circuit-mode 64 kbit/s unrestricted, 8 kHz structured bearer service, ITU-T Recommendation
I.231.1, November 1988
I.363.1 B-ISDN ATM Adaptation Layer specification: Type I AAL, ITU-T Recommendation I.363.1,
August 1996
Y.1413 TDM-MPLS Network Interworking User Plane Interworking, ITU-T Recommendation
Y.1413, March 2004
T1.102 Digital Hierarchy Electrical Interfaces, ANSI T1.102-1993
T1.107 Digital Hierarchy Formats Specifications, ANSI T1.107-2002
T1.403 Network and Customer Installation Interfaces DS1 Electrical Interface, ANSI T1.403-1999
T1.510 Network Performance Parameters for Dedicated Digital Services for Rates up to and including
DS3, ANSI T1.510-1999

MEF 8 The Metro Ethernet Forum 2004. 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.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

Reference Reference Details


GR-253-CORE Synchronous Optical Network (SONET) Transport Systems: Common Generic Criteria
Telcordia Generic Requirements GR-253-CORE, Issue 3, September 2000
TR-NWT- Digital Cross-Connect System (DSC 1/0) Generic Criteria, Telcordia Technical Reference TR-
000170 NWT-000170, January 1993
MEF 1 Ethernet Services Model Phase 1, MEF 1, November 2003,
http://www.metroethernetforum.org/PDFs/Standards/MEF1.pdf
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 4 Metro Ethernet Network Architecture Framework Part 1: Generic Framework, MEF 4, May
2004, http://www.metroethernetforum.org/PDFs/Standards/MEF4.pdf.
MEF 5 Traffic Management Specification Phase 1, MEF 5, May 2004,
http://www.metroethernetforum.org/PDFs/Standards/MEF5.pdf
MEF 6 Ethernet Services Definitions Phase 1, MEF 6, June 2004,
http://www.metroethernetforum.org/PDFs/Standards/MEF6.pdf
ATM-CES Circuit Emulation Services Interoperability Specification, Version 2.0, ATM Forum af-vtoa-
0078.000, January 1997,
ftp://ftp.atmforum.com/pub/approved-specs/af-vtoa-0078.000.pdf
IEEE 802.3 Information technology Telecommunications and information exchange between systems
Local and metropolitan area networks Specific requirements Part 3: Carrier sense multiple
access with collision detection (CSMA/CD) access method and physical layer specifications,
IEEE 802.3-2002

MEF 8 The Metro Ethernet Forum 2004. 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.
Technical Specification
MEF 28

External Network Network Interface (ENNI)


Support for UNI Tunnel Access and Virtual UNI

October 2010

MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, 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.
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.

(C) 2010. The Metro Ethernet Forum. All Rights Reserved.

MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, 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.
External Network Network Interface Support for UTA and VUNI

Table of Contents
1 Abstract ................................................................................................................................... 1
2 Terminology............................................................................................................................ 1
3 Scope and Key Concepts ........................................................................................................ 2
3.1 UTA Components ........................................................................................................... 5
3.1.1 UTA OVC Component ............................................................................................... 5
3.1.2 Remote UNI Component ............................................................................................ 5
3.1.3 VUNI Component ....................................................................................................... 5
4 Compliance Levels.................................................................................................................. 5
5 Requirements for the UTA OVC Component ........................................................................ 6
5.1 UTA OVC ....................................................................................................................... 6
5.2 UTA OVC End Point at the Remote UNI ....................................................................... 7
5.3 UTA OVC End Point at the ENNI in the Network Operators MEN ............................. 8
5.3.1 Color Marking at the UTA OVC End Point at the ENNI in the Network Operators
MEN............................................................................................................................ 9
5.4 ENNI Service Attributes Supporting the UTA OVC .................................................... 10
6 Requirements for the Remote UNI Component.................................................................... 11
7 Requirements for the VUNI Component .............................................................................. 12
7.1 Virtual UNI (VUNI) Service Attributes ....................................................................... 12
7.2 ENNI Service Attributes Supporting the VUNI ........................................................... 13
7.3 Service Attributes for an OVC End Point associated by the VUNI ............................. 14
7.3.1 VUNI Class of Service Identifiers ............................................................................ 15
7.4 Bandwidth Profiles at the VUNI ................................................................................... 17
7.4.1 Ingress Bandwidth Profile per VUNI End Point Service Attribute .......................... 17
7.4.2 Egress Bandwidth Profile per VUNI End Point Service Attribute ........................... 17
7.4.3 Ingress Bandwidth Profile per OVC End Point associated by a VUNI Service
Attribute .................................................................................................................... 18
7.4.4 Ingress Bandwidth Profile per Class of Service Identifier per OVC End Point
associated by a VUNI Service Attribute ................................................................... 18
7.4.5 Egress Bandwidth Profile per OVC End Point associated by a VUNI Service
Attribute .................................................................................................................... 18
7.4.6 Egress Bandwidth Profile per Class of Service Identifier per OVC End Point
associated by a VUNI Service Attribute ................................................................... 18
7.4.7 Color Awareness at the VUNI .................................................................................. 19
8 Appendix A: Example: Multiple EVCs ................................................................................ 20
9 Appendix B: Multi-MEN UTA............................................................................................. 22
10 Appendix C: VUNI Implementation Example ..................................................................... 24
11 References ............................................................................................................................. 26

MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page i
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.
External Network Network Interface Support for UTA and VUNI

List of Figures
FIGURE 1 UNI TUNNEL ACCESS MODEL ......................................................................................................................2
FIGURE 2 EVCS IMPLEMENTED USING VUNI, UTA OVC, AND REMOTE UNI ...............................................................3
FIGURE 3 EXAMPLE WITH MULTIPLE VUNIS ASSOCIATED WITH A SINGLE ENNI .......................................................4
FIGURE 4 KEY TO THE ICONS USED IN THE EXAMPLES .............................................................................................20
FIGURE 5 EXAMPLE OF THE REMOTE UNI IN MULTIPLE EVCS ..................................................................................20
FIGURE 6 EXAMPLE MULTIPLE EVCS SUPPORTED BY UTA AND VUNI ......................................................................21
FIGURE 7 MULTI-MEN UNI TUNNEL ACCESS MODEL................................................................................................22
FIGURE 8 EXAMPLE MULTIPLE EVCS SUPPORTED BY A MULTI-MEN UTA ................................................................23
FIGURE 9 VUNI USING IEEE 802.1 C AND S COMPONENTS MODEL..........................................................................24

List of Tables
TABLE 1: ACRONYMS AND DEFINITIONS ......................................................................................................................2
TABLE 2: OVC SERVICE ATTRIBUTES CONSTRAINTS FOR UTA OVC ...............................................................................7
TABLE 3: OVC END POINT PER UNI SERVICE ATTRIBUTE CONSTRAINTS FOR UTA OVC END POINT AT THE REMOTE
UNI .................................................................................................................................................................8
TABLE 4: OVC END POINT PER ENNI SERVICE ATTRIBUTE CONSTRAINTS FOR AN OVC SUPPORTING UTA ..................9
TABLE 5: ENNI SERVICE ATTRIBUTE CONSTRAINTS FOR THE UTA NETWORK OPERATOR ..........................................10
TABLE 6: VUNI SERVICE ATTRIBUTE CONSTRAINTS FOR UTA .....................................................................................13
TABLE 7: ENNI SERVICE ATTRIBUTE CONSTRAINTS FOR VUNI PROVIDER ..................................................................14
TABLE 8: SERVICE ATTRIBUTES FOR OVC END POINTS ASSOCIATED BY THE VUNI.....................................................15
TABLE 9: ABBREVIATIONS USED IN THE EXAMPLES....................................................................................................20

MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page ii
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.
External Network Network Interface Support for UTA and VUNI

1 Abstract
The External Network Network Interface (ENNI) is a reference point that describes the interface
between two Metro Ethernet Networks (MENs) and is intended to support the transparent
extension of Ethernet services across multiple Network Operator MENs, where each Network
Operator MEN is under the control of a distinct administrative authority. This Technical
Specification extends the ENNI by defining the UNI Tunnel Access (UTA) which associates a
Virtual UNI (VUNI), a remote UNI, and at least one supporting OVC.

This Technical Specification specifies:

The requirements for the UNI Tunnel Access (UTA) in sufficient detail to ensure
interoperability between MENs.

The service attributes necessary to realize UTA.

The Virtual UNI (VUNI), remote UNI constraints, and related service attributes.

2 Terminology
Note: Terms defined in the ENNI document [MEF 26] are not repeated here.

Term Definition Source


Remote UNI Remote UNI is a UNI serving as the UTA component This document
consisting of a collection of service attributes in the UNI
within an Operators MEN. The remote UNI is paired with
a VUNI in a VUNI Providers MEN. At the remote UNI,
Service Frames are exchanged between the Subscriber and
the Network Operator MEN.1
UTA The UNI Tunnel Access (UTA) associates a VUNI and This document
remote UNI and is composed of VUNI and remote UNI
Components and at least one supporting OVC2.
UTA Component A specific set of capabilities which may be used as part of This document
UTA.
UTA OVC An OVC in the Network Operators MEN that provides an This document
association of a remote UNI with an ENNI in support of
UTA.

1
For this initial phase, the remote UNI is supported by a Network Operator MEN as a UNI with specific attribute
constraints (as described in this document) that is not aware of the EVC services. For future phases, an EVC service
aware remote UNI may be considered.
2
UTA is minimally supported by the UTA OVC within the Network Operator MEN that provides the remote UNI.
Future versions of UTA may additionally be supported by OVCs traversing intermediate providers in order to
extend the tunnel. See Appendix B.

MEF 28 The Metro Ethernet Forum 2011. 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.
External Network Network Interface Support for UTA and VUNI

Term Definition Source


VUNI Virtual UNI (VUNI) is the component consisting of a This document
collection of service attributes in the VUNI Providers
MEN. The VUNI is paired with a remote UNI in a Network
Operators MEN. The main function of the VUNI is to map
frames between a set of one or more OVCs present in the
VUNI Provider domain and a single UTA.
VUNI End Point An End Point at the VUNI Providers side of a specific This document
ENNI that associates the ENNI with a VUNI in support of
UTA.
VUNI Provider The Operator MEN providing the VUNI. This document
Table 1: Acronyms and Definitions

3 Scope and Key Concepts


Service providers need a way to extend their reach to subscribers outside of their immediate
serving area. The UNI Tunnel Access (UTA) provides a means for the Service Frames of EVCs
associated with a remote subscribers UNI to be tunneled through a Network Operators MEN to
an ENNI connecting a Network Operators MEN with the VUNI Providers MEN. With this
arrangement, the Network Operator provides the OVC for transfer of Service Frames between
the remote UNI and the ENNI. In addition, the service attributes related to the Subscriber
service are distributed between the remote UNI and the Virtual UNI (VUNI). Figure 1 provides
a model showing the context for the UTA between a Network Operator and the VUNI Provider.

Figure 1 - UNI Tunnel Access Model3

The VUNI in the VUNI Providers MEN has service attributes similar to those of a UNI, and is
paired with a remote UNI in the Network Operators MEN. The VUNI is associated with a
VUNI End Point at the VUNI Providers side of an ENNI. Its main function is to specify the
processing rules applicable to ENNI frames present in the VUNI Provider domain and associate
them with a given UTA instance.

3
While the remote UNI is shown in Figure 1 is adjacent to the CE, UTA also allows (but does not require) a
Service Provider to support UNI-UNI service level monitoring by placing a capability between the Remote UNI and
the CE (e.g., implemented within a network interface device) for Service Level verification.
MEF 28 The Metro Ethernet Forum 2011. 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.
External Network Network Interface Support for UTA and VUNI

Figure 2 below shows an example of a UTA between a VUNI and remote UNI (UNI Y). In this
figure, EVC1, EVC2, and EVC3 are available to the Subscriber at the remote UNI. However, the
Network Operator supporting the remote UNI is not responsible for the management of the
EVCs across the Network Operators MEN. The Network Operator is responsible for
management of the UTA OVC between its side of the ENNI and the remote UNI, including the
service attributes of the remote UNI. For this initial phase, the remote UNI supports only very
basic service attributes and is not aware of the details of the services for the Subscriber, e.g., the
number of EVCs seen by the Subscriber.

Figure 2 EVCs Implemented Using VUNI, UTA OVC, and remote UNI4

In Figure 2, the CE at UNI Y participates in EVCs 1, 2, and 3. These EVCs have the Service
Provider agreed Bandwidth Profile Attributes, and CoS markings. At the remote UNI, Service
Frames of EVC 1, 2, and 3 are exchanged with the CE. Such frames may be C-tagged, priority
tagged, or untagged. The remote UNI is instantiated by the Network Operator as a UNI where
the Network Operator maps all Service Frames to the single OVC End Point supporting the UTA
OVC. A single bandwidth profile and CoS may be applied at this remote UNI OVC End Point.
At the UTA OVC End Point at the Network Operators side of the ENNI, an S-VLAN ID is used
to map ENNI Frames to the OVC End Point supporting the UTA, and applies a UTA specific
single bandwidth profile and CoS.

4
The OVC End Points associated by a VUNI in this figure represent the association of OVC A1, A2, and A3 with
the ENNI as specified in [MEF 26].
MEF 28 The Metro Ethernet Forum 2011. 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.
External Network Network Interface Support for UTA and VUNI

In the VUNI Providers network, the relationship between the UTA OVC and the VUNI is
realized by an S-VLAN ID present at the ENNI, whose value is negotiated between the VUNI
Provider and the Network Operator. At the ENNI, when receiving an ENNI Frame, the VUNI
Provider maps (using the End Point Map) a single S-VLAN ID to a VUNI End Point associated
with a VUNI. The VUNI then maps frames based on their CE-VLAN ID to the appropriate OVC
End Point for OVCs A1, A2 and A3. In the reverse direction, the VUNI multiplexes frames from
OVCs A1, A2, and A3 into a tunnel denoted by a unique S-VLAN ID, which is associated with
the Network Operators UTA OVC. Note that A1, A2 and A3 have non-overlapping CE-VLAN
IDs at the VUNI.

An ENNI can support more than one VUNI.

Figure 3 provides an example that shows multiple VUNIs associated with a single ENNI.

Figure 3 Example with Multiple VUNIs Associated with a Single ENNI5

This technical specification assumes the following business model: The Subscriber contracts
with a Service Provider (who either acts as the VUNI Provider, or contracts with the VUNI
Provider) to provide Ethernet Services among UNIs, including those UNIs outside of the Service
Providers serving area. That is, the EVC Service Level Specification (SLS) remains UNI to
UNI. The Service Provider, in turn, selects and contracts with one or more Network Operators to
provide one UTA OVC to reach each remote UNI. It is the responsibility of the Service Provider
to ensure the appropriate connectivity properties for each UTA such that the UNI-to-UNI service
features purchased by the Subscriber can be delivered.

A service arrangement involving one or more Intermediate Network Operators between the
VUNI Provider MEN and the Network Operator MEN supporting the remote UNI is a possible
extension to the service model; however, details around this Use Case are left as a For Future
Study (FFS) item. Appendix B provides a model along with some examples of how the multi-
MEN extensions may be realized.

5
The OVC End Points associated by each VUNI in this figure represent the association of OVCs with the ENNI as
specified in [MEF 26].
MEF 28 The Metro Ethernet Forum 2011. 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.
External Network Network Interface Support for UTA and VUNI

3.1 UTA Components


The UTA, defined in this technical specification, is composed of a UTA OVC Component (in the
Network Operator MEN) and associated VUNI (in the VUNI Provider MEN) and remote UNI
(in the Network Operator MEN) Components. The UTA OVC and remote UNI components may
be provided as a service offered by the Network Operator to a Service Provider.

3.1.1 UTA OVC Component

This Technical Specification defines requirements that detail the attributes that are supported by
a Network Operator MEN providing the UTA OVC.

The UTA OVC associates the remote UNI with an ENNI (connecting the Network Operator and
the VUNI Provider in Figure 1). The UTA OVC service attributes represent the service
capabilities that the Service Provider purchases from a Network Operator, and describe what is
needed to instantiate the UTA OVC supporting the Subscriber services of a distant UNI (UNI Y
in Figure 1).

3.1.2 Remote UNI Component

The remote UNI requirements detail the behavior of the remote UNI at the Network Operator
side of the UNI that is attached to the Subscriber (remote UNI attributes at UNI Y in Figure 1).
The remote UNI supports a portion of the UNI service attributes. This Specification addresses
remote UNI service attributes in a manner that is not aware of Subscriber service details. That is,
it is assumed that the remote UNI has no knowledge of the individual Subscribers EVCs. Note
that from the Subscribers perspective, the UNI can be perceived as a service multiplexed UNI.

3.1.3 VUNI Component

This Specification details the behavior of the VUNI that is associated with the ENNI related to
the UTA at the Network Operators side of an ENNI (VUNI at the ENNI in Figure 1). The
VUNI attributes include: mapping of the VUNI to the End Point associated with the UTA OVC
at the opposite side of the ENNI; and mapping of ENNI Frames to one or more VUNI Provider
OVC End Points in support of Subscriber services.

4 Compliance Levels
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in RFC 2119.

Items that are REQUIRED (contain the words MUST or MUST NOT) will be labeled as [Rx]
for required. Items that are RECOMMENDED (contain the words SHOULD or SHOULD
NOT) will be labeled as [Dx] for desirable. Items that are OPTIONAL (contain the words MAY
or OPTIONAL) will be labeled as [Ox] for optional.

MEF 28 The Metro Ethernet Forum 2011. 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.
External Network Network Interface Support for UTA and VUNI

5 Requirements for the UTA OVC Component


The UTA OVC is an OVC in the Network Operators MEN that associates a remote UNI with an
ENNI in support of the UTA. The UTA OVC Service Attributes describe the possible behaviors
seen by an observer (e.g., the VUNI Provider) external to the Network Operator MEN at and
between the external interfaces (remote UNI and ENNI).

The implementation of a UTA OVC within the Network Operator MEN is opaque to the VUNI
Provider and the Subscriber. What is important is the observed behavior of the UTA OVC
between the remote UNI and ENNI. These behaviors can be described by the following sets of
service attribute constraints:

UTA OVC service attributes constraints are presented in Section 5.1.

OVC End Point at the remote UNI service attribute constraints for the UTA OVC
are presented in Section 5.2.

OVC End Point at the ENNI service attribute constraints for the UTA OVC are
presented in Section 5.3.

Service attribute constraints for the ENNI participating in the UTA OVC are
presented in Section 5.4.

5.1 UTA OVC


The UTA OVC applies the OVC Service Attributes and Requirements as defined in Section 7.2
of [MEF 26]. However some specific service attributes have been further constrained and are
described in the requirements below.

[R1] A UTA OVC MUST assign OVC service attributes and values according to
Table 2.

OVC Service Attribute Name Additional Constraints for UTA OVC


OVC Identifier No additional constraints
OVC Type MUST be Point-to-Point
OVC End Point List The list MUST identify exactly two OVC End Points:
Exactly one of the OVC End Points MUST be at a remote UNI;
and
Exactly one of the OVC End Points MUST be at the Network
Operator side of an ENNI.
Maximum Number of UNI MUST be 1
OVC End Points
Maximum Number ENNI MUST be 1
OVC End Points
MEF 28 The Metro Ethernet Forum 2011. 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.
External Network Network Interface Support for UTA and VUNI

OVC Service Attribute Name Additional Constraints for UTA OVC


OVC Maximum Transmission No additional constraints
Unit Size
S-VLAN ID Preservation No additional constraints6
S-VLAN CoS Preservation No additional constraints7
CE-VLAN ID Preservation MUST be Yes
CE-VLAN CoS Preservation MUST be Yes
Color Forwarding MUST be No8
SLS No additional constraints
Unicast Service Frame MUST Deliver Unconditionally
Delivery
Multicast Service Frame MUST Deliver Unconditionally
Delivery
Broadcast Service Frame MUST Deliver Unconditionally
Delivery
Table 2: OVC Service Attributes Constraints for UTA OVC

5.2 UTA OVC End Point at the Remote UNI


The UTA OVC applies the OVC End Point per UNI Service Attributes and Requirements as
defined in Section 7.5 of [MEF 26]. However some specific service attributes have been further
constrained and are described in the requirements below.

[R2] An OVC End Point supporting the UTA at a remote UNI MUST assign
service attributes and values according to Table 3.

Note that because the OVC End Point at the remote UNI is a special constrained case of an OVC
End Point at a UNI, the UNI terminology of [MEF 26] refers to remote UNI in Table 3.

6
The value of the S-VLAN ID Preservation attribute does not affect the behavior of the UTA OVC.
7
The value of the S-VLAN ID COS Preservation attribute does not affect the behavior of the UTA OVC.
8
Color Forwarding is replaced by the color marking behavior for egress ENNI Frames as described in Section 5.3.1
MEF 28 The Metro Ethernet Forum 2011. 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.
External Network Network Interface Support for UTA and VUNI

OVC End Point per UNI Service Additional Constraints for the UTA OVC End Point at the Remote
Attribute UNI
UNI OVC Identifier No additional constraints
OVC End Point Map All CE-VLAN ID values at the remote UNI MUST map to the
single OVC End Point
Class of Service Identifiers MUST provide only a single Class of Service Identifier9
Ingress Bandwidth Profile Per If an Ingress Bandwidth Profile per OVC End Point at a remote
OVC End Point at a UNI UNI is supported, it MUST be configured as color blind and
(remote UNI) MUST specify either CIR as ZERO or EIR as ZERO10. For
more information on this Bandwidth Profile, please see [MEF
10.2]
Ingress Bandwidth Profile Per MUST NOT specify
Class of Service Identifier at a
UNI (remote UNI)
Egress Bandwidth Profile Per MUST NOT specify
OVC End Point at a UNI
(remote UNI)
Egress Bandwidth Profile Per MUST NOT specify
Class of Service Identifier at a
UNI (remote UNI)
Table 3: OVC End Point per UNI Service Attribute Constraints for UTA OVC End Point
at the Remote UNI
As indicated in Table 3, all frames transported by the UTA OVC are mapped to a single class of
service. Therefore, if a service provider wants to support multiple EVCs with different
performance objectives on a single UTA OVC, then the service provider should select UTA
OVC performance objectives such that the UNI to UNI performance objectives of the most
demanding EVCs can be achieved.

5.3 UTA OVC End Point at the ENNI in the Network Operators MEN
The UTA OVC applies the OVC End Point per ENNI Service Attributes and Requirements as
defined in Section 7.3 of [MEF 26]. However some specific service attributes have been further
constrained and are described in the requirements below.11 In addition, the color marking
behavior for egress ENNI Frames at the UTA OVC End Point at the ENNI in the Network
Operators MEN is described in Section 5.3.1.

[R3] An OVC End Point supporting a UTA at an ENNI MUST assign service
attributes and values according to Table 4.

9
Class of Service Identifier should be based on the OVC End Point as described in Section 7.5.3.1 of [MEF 26]
10
Note, this implies a single color in that either all frames will be declared yellow, or all will be declared green,
respectively.
11
Note, this applies to the OVC End Point on the Network Operators side of the ENNI. The requirements for the
End Point at the VUNI Providers side of the ENNI are provided in Section 7.
MEF 28 The Metro Ethernet Forum 2011. 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.
External Network Network Interface Support for UTA and VUNI

OVC End Point per ENNI


Additional Constraints for the UTA OVC End Point at the ENNI
Service Attribute
OVC End Point Identifier No additional constraints
Class of Service Identifiers MUST provide only a single Class of Service Identifier
Ingress Bandwidth Profile Per MUST be configured as color aware and MUST specify either
OVC End Point CIR as ZERO or EIR as ZERO
Ingress Bandwidth Profile Per MUST NOT specify
ENNI Class of Service
Identifier
Egress Bandwidth Profile Per No additional constraints
End Point
Egress Bandwidth Profile Per MUST NOT specify
ENNI Class of Service
Identifier
Table 4: OVC End Point per ENNI Service Attribute constraints for an OVC supporting
UTA

5.3.1 Color Marking at the UTA OVC End Point at the ENNI in the Network
Operators MEN
Since the Ingress Bandwidth Profile at the UTA OVC End Point at a remote UNI is defined to
declare Service Frames to be either Green/Red (since CIR>0, EIR=0) or Yellow/Red (since
CIR=0, EIR>0) (i.e., all resulting egress ENNI Frames must be the same color), there is no need
for the Network Operator to carry the ingress color marking result across the network to the
ENNI. Proper ENNI Frame color marking may be achieved by examining the Bandwidth Profile
information of the UTA OVC End Point at the remote UNI to identify the appropriate color
marking of each egress ENNI Frame mapped to the UTA OVC End Point at the Network
Operator ENNI. The Bandwidth Profile attribute of the UTA OVC End Point at the remote UNI
describes the color marking of each egress ENNI Frame (i.e. toward the VUNI provider) that is
mapped to the UTA OVC End Point at the ENNI by the ENNI End Point Map.

[R4] When there is an ingress Bandwidth Profile of the UTA OVC End Point at the
remote UNI with CIR > 0 and EIR = 0, each egress ENNI Frame mapped to
the corresponding UTA OVC End Point at the ENNI by the ENNI End Point
Map MUST be marked Green via the S-Tag as per [MEF 23].

[R5] When there is an ingress Bandwidth Profile of the UTA OVC End Point at the
remote UNI with CIR = 0 and EIR > 0, each egress ENNI Frame mapped to
the corresponding UTA OVC End Point at the ENNI by the ENNI End Point
Map MUST be marked Yellow via the S-Tag as per [MEF 23].

[O1] In the case where no ingress Bandwidth Profile is defined for the UTA OVC
End Point at the remote UNI, the Network Operator MAY set the color of the
egress ENNI Frame based on bilateral agreement with the Service Provider.

MEF 28 The Metro Ethernet Forum 2011. 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.
External Network Network Interface Support for UTA and VUNI

5.4 ENNI Service Attributes Supporting the UTA OVC


From the point of view of the UTA, the ENNI is the point of demarcation between the VUNI
Provider MEN and the Network Operator MEN. This section addresses the ENNI service
attribute constraints associated with the Network Operator.

For the UTA Network Operator, the ENNI Attributes as defined in Section 7.1 of [MEF 26] are
applied.

[R6] A Network Operator ENNI supporting the UTA related OVC End Point
MUST assign service attributes and values according to Table 5.

Constraints for the UTA Network Operator ENNI Service Attributes are summarized in Table 5.

ENNI Service Attribute Service Attribute Parameters and Constraints for the
UTA Network Operator
Operator ENNI Identifier No additional constraints
Physical Layer No additional constraints
Frame Format No additional constraints
Number of Links No additional constraints
Protection Mechanism No additional constraints
ENNI Maximum No additional constraints
Transmission Unit Size
End Point Map The End Point Type within an End Point Map for a UTA OVC
Component related OVC End Point at an ENNI MUST take the
value of OVC.
Maximum Number of No additional constraints
OVCs
Maximum Number of OVC No additional constraints
End Points per OVC
Table 5: ENNI Service Attribute Constraints for the UTA Network Operator

MEF 28 The Metro Ethernet Forum 2011. 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.
External Network Network Interface Support for UTA and VUNI

6 Requirements for the Remote UNI Component


This section describes how some of the service attributes associated with the remote UNI are
constrained in support of the UTA. For the UTA, the remote UNI service attributes are
constrained to have the OVC type being Point-to-Point across the Network Operator MEN. MEF
Services like EPLAN can be offered by the Service Provider, because any changes to other end
points in the Service Provider domain (e.g., adding or deleting UNI end points) do not require
coordination with the Network Operator supporting the remote UNI.

The remote UNI reuses the UNI service attributes specified in Section 7.4 of [MEF 26].

As described by the OVC End Point Map attribute in Table 3, the remote UNI supporting the
UTA OVC is configured to support a single OVC End Point to which all CE VLAN IDs are
mapped at the remote UNI. A Bandwidth Profile is specified for the OVC End Point of the UTA
OVC at the remote UNI. For UTA, other Bandwidth Profiles may be configured, for example a
Bandwidth Profile for the VUNI as a whole (see Section 7.4). A separate Bandwidth Profile per
remote UNI is redundant and may cause additional undesired behavior; hence it is not to be
specified.

[R7] The remote UNI supporting the UTA OVC MUST NOT specify an Ingress
Bandwidth Profile per UNI.

[R8] The remote UNI supporting the UTA OVC MUST NOT specify an Egress
Bandwidth Profile per UNI.

MEF 28 The Metro Ethernet Forum 2011. 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.
External Network Network Interface Support for UTA and VUNI

7 Requirements for the VUNI Component


VUNI requirements detail the behavior that is associated with the UTA on the VUNI Providers
side of the ENNI. This is referred to as the VUNI component.

The VUNI components responsibilities include: Mapping of the VUNI End Point to the ENNI;
and Mapping of ENNI Frames between one or more VUNI Provider OVC End Points and the
VUNI End Point for the UTA in support of Subscriber services.

The behavior at the VUNI is specified by the following sets of attributes:

VUNI Service Attributes are presented in Section 7.1.

ENNI Service Attributes for the ENNI supporting the VUNI are presented in
Section 7.2.

Service Attributes for OVC End Points associated by the VUNI are presented in
Section 7.3.

7.1 Virtual UNI (VUNI) Service Attributes


The VUNI Service Attributes are similar to the UNI attributes specified in Section 7.4 of [MEF
26]. This section describes how these VUNI service attributes focus on support of the UTA.

In order to describe the VUNI attributes, the concept of an ENNI CE-VLAN ID is defined for an
ENNI Frame that is mapped to a VUNI End Point as follows:

If an ENNI Frame is mapped to a VUNI End Point and the ENNI Frame has a C-Tag
whose VLAN ID value is not zero, then the ENNI CE-VLAN ID for the ENNI Frame is
the value of VLAN ID in the C-Tag.

If an ENNI Frame is mapped to a VUNI End Point and the ENNI Frame either has no C-
Tag or has a C-Tag whose VLAN ID value is zero, then the ENNI CE-VLAN ID is a
value in the range 1,2,,4094 that is agreed upon by both the Service Provider and the
Operator supporting the VUNI.12

[R9] A VUNI supporting the UTA MUST assign service attributes and values
according to Table 6.

Note, in Table 6, the Ingress Bandwidth Profile is applied to traffic that flows from the
Subscriber at the remote UNI to the VUNI Provider MEN, and the Egress Bandwidth Profile is
applied to traffic that flows from the VUNI Provider MEN to the Subscriber at the remote UNI.

12
The value also needs to be agreed upon between the Service Provider and the Subscriber.
MEF 28 The Metro Ethernet Forum 2011. 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.
External Network Network Interface Support for UTA and VUNI

VUNI Service Attribute Service Attribute Parameters and Constraints for UTA
Arbitrary text string of no more than 45 bytes to identify the
VUNI. The VUNI Identifier MUST be unique among all VUNI
VUNI Identifier
Identifiers within the scope of all ENNIs supported by the VUNI
Provider MEN.
ENNI CE-VLAN ID value for MUST specify CE-VLAN ID value in the range of 1-4094.
ENNI Frames with no C-Tag
or a C-Tag whose VLAN ID
value is 0
Maximum number of related
OVC End Points in the VUNI MUST be an integer 1.
Provider MEN
Ingress Bandwidth Profile Per
(See Section 7.4.1)
VUNI
Egress Bandwidth Profile Per
(See Section 7.4.2)
VUNI
Table 6: VUNI Service Attribute Constraints for UTA

7.2 ENNI Service Attributes Supporting the VUNI


From the point of view of the UTA, the ENNI is the point of demarcation between the VUNI
Provider MEN and the Network Operator MEN13. This section addresses the ENNI attribute
constraints associated with the VUNI Provider.

When VUNI attributes are enabled in support of the UTA, the ENNI Attributes as defined in
Section 7.1 of [MEF 26] are applied to describe the behavior of the ENNI, however a specific
attribute has been extended as described in the requirement below to allow for mapping of an S-
VLAN ID at the ENNI to a specific VUNI End Point.

[R10] A VUNI Provider ENNI supporting the UTA MUST assign service attributes
and values according to Table 7.

Constraints for the VUNI Provider ENNI Service Attributes are specified in Table 7.

13
These service attributes would remain the same in the case where an intermediate operator provides connectivity
to the network operator supporting the remote UNI as described in the Multi-MEN model provided in Appendix B.
MEF 28 The Metro Ethernet Forum 2011. 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.
External Network Network Interface Support for UTA and VUNI

ENNI Service Attribute


Service Attribute Parameters and Constraints for
VUNI Provider

Operator ENNI Identifier No additional constraints


Physical Layer No additional constraints
Frame Format No additional constraints
Number of Links No additional constraints
Protection Mechanism No additional constraints
ENNI Maximum No additional constraints
Transmission Unit Size
End Point Map At an ENNI in the VUNI Provider MEN, the End Point Type
within an End Point Map for ENNI frames mapped to a VUNI
MUST take the value of VUNI14
Maximum Number of No additional constraints
OVCs
Maximum Number of No additional constraints
OVC End Points per OVC
Table 7: ENNI Service Attribute Constraints for VUNI Provider

The VUNI End Point at the VUNI Provider ENNI is associated with a UTA and is indicated with
the End Point Type VUNI in the ENNI Service Attribute End Point Map, see Section 7.1.7.1 of
[MEF 26]. Multiple VUNI End Points can reside at a single ENNI.

[R11] At an ENNI, an End Point Map entry with an End Point Type of VUNI MUST
provide an association to a VUNI End Point by applying the End Point Map
entrys End Point Identifier to map ENNI frames with the given S-VLAN ID
Value to a VUNI End Point.

As per requirement [R16] of [MEF 26], the End Point Map at the ENNI uses the S-VLAN-ID of
a given S-Tagged ENNI Frame to determine the VUNI End Point to which an ENNI Frame is
mapped.

7.3 Service Attributes for an OVC End Point associated by the VUNI
There are attributes for each instance of an OVC End Point associated with a specific VUNI.15
These service attributes are based on the OVC per UNI Attributes as described in Section 7.5 of
[MEF 26].

[R12] A given OVC MUST associate at most one OVC End Point that is associated
by a specific VUNI.

14
This requirement extends the End Point Type as defined in [R18] of [MEF 26].
15
Note that the OVC(s) discussed in this section are in the VUNI Provider MEN, as opposed to the UTA OVC
Service Component that is in the Network Operator MEN.
MEF 28 The Metro Ethernet Forum 2011. 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.
External Network Network Interface Support for UTA and VUNI

[R13] In the VUNI Provider MEN, once an ENNI frame received from the Network
Operators MEN is mapped to a specific VUNI End Point that identifies the
VUNI based on the S-VLAN ID Value in the ENNI End Point Map Service
Attribute, the VUNI OVC End Point Map MUST be applied to determine the
OVC End Point associated with the frames C-VLAN ID Value.

[R14] An OVC End Points service attributes for an OVC End Point that is
associated by a VUNI MUST be configured with values according to Table 8.

Service Attributes for an OVC


End Point associated by the Service Attribute Parameters and Values
VUNI
VUNI OVC Identifier An arbitrary string of no more than 45 bytes formed by the
concatenation of the VUNI Identifier and the OVC Identifier
OVC End Point Map A list of one or more CE-VLAN ID values mapped to the OVC
End Point
Class of Service Identifiers The way that a Class of Service is determined for ingress ENNI
Frames that are mapped to a VUNI (see Section 7.3.1)
Ingress Bandwidth Profile Per (See Section 7.4.3)
OVC End Point associated by
a VUNI
Ingress Bandwidth Profile Per (See Section 7.4.4)
Class of Service Identifier
associated by a VUNI
Egress Bandwidth Profile Per (See Section 7.4.5)
OVC End Point associated by
a VUNI
Egress Bandwidth Profile Per (See Section 7.4.6)
Class of Service Identifier
associated by a VUNI
Table 8: Service Attributes for OVC End Points associated by the VUNI

7.3.1 VUNI Class of Service Identifiers

[R15] There MUST be three mutually exclusive ways to determine the Class of
Service Identifier from the content of a given ENNI Frame mapped to a VUNI
as described in Sections 7.3.1.1, 7.3.1.2, and 7.3.1.3.

Note that Sections 7.3.1.1, 7.3.1.2, and 7.3.1.3 describe Class of Service Identifiers for ingress
ENNI Frames mapped to a VUNI.

MEF 28 The Metro Ethernet Forum 2011. 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.
External Network Network Interface Support for UTA and VUNI

7.3.1.1 VUNI Class of Service Identifier Based on OVC End Point

[R16] When the Class of Service Identifier is based on OVC End Point, all ingress
ENNI Frames mapped to the same OVC End Point at the VUNI MUST have
the same Class of Service Identifier.

As an example, consider OVC End Point 1 and OVC End Point 2 associated by a VUNI. ENNI
Frames mapped to OVC End Point 1 have a first Class of Service Identifier that indicates gold
service. ENNI Frames mapped to OVC End Point 2 have a second Class of Service Identifier
that indicates silver service.

7.3.1.2 VUNI Class of Service Identifier Based on C-Tag Priority Code Point Field

[R17] When the Class of Service Identifier is based on C-Tag Priority Code Point
field, the Class of Service Identifier for an ingress ENNI Frame mapped to a
VUNI MUST be determined by the combination of the OVC End Point and
non-overlapping sets of values of the C-Tag Priority Code Point field.

[R18] When the Class of Service Identifier is based on C-Tag Priority Code Point
field, if the ingress ENNI frame does not contain a C-Tag, it MUST have the
same Class of Service Identifier as an ingress frame with C-Tag Priority Code
Point field = 0 in the C-Tag.

[R19] When the Class of Service Identifier is based on C-Tag Priority Code Point
field, the union of the sets of C-Tag PCP field values MUST contain all of the
possible values.

As an example, consider OVC End Point 1 and OVC End Point 2 associated by a VUNI. The
ENNI Frames mapped to OVC End Point 1 with C-Tag Priority Code Point values 4, 5, 6, and 7
have a first Class of Service Identifier that indicates gold service. The ENNI Frames mapped to
OVC End Point 1 with C-Tag Priority Code Point values 0 and 3 have a second Class of Service
Identifier that indicates silver service. The ENNI Frames mapped to OVC End Point 1 with C-
Tag Priority Code Point values 1 and 2 have a third Class of Service Identifier that indicates
Service Frame discard. VUNI-mapped ENNI Frames without a C-Tag that are mapped to OVC
End Point 1 also have the second Class of Service Identifier that indicates silver service. The
ENNI Frames mapped to OVC End Point 2 with C-Tag Priority Code Point value 7 have a fourth
Class of Service Identifier that indicates platinum service. All other VUNI mapped frames
mapped to OVC End Point 2 have a fifth Class of Service Identifier that indicates gold service.

7.3.1.3 VUNI Class of Service Identifier Based on DSCP

[R20] When the Class of Service Identifier is based on DSCP, the Class of Service
Identifier for an ingress ENNI Frame mapped to a VUNI containing an IP
packet MUST be determined by the combination of the OVC End Point and
non-overlapping sets of values of the DSCP.

MEF 28 The Metro Ethernet Forum 2011. 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.
External Network Network Interface Support for UTA and VUNI

[R21] When the Class of Service Identifier is based on DSCP, the union of the sets
of DSCP values MUST contain all of the possible DSCP values.

[R22] When the Class of Service Identifier is based on DSCP, each ingress ENNI
Frame mapped to a VUNI not containing an IP packet and mapped to a given
OVC End Point MUST have the same Class of Service Identifier with a value
agreed upon by the Subscriber and the Service Provider.

7.4 Bandwidth Profiles at the VUNI


VUNI Bandwidth Profiles in this Technical Specification use the parameters and algorithm
described in Section 7.6.1 of [MEF 26].

7.4.1 Ingress Bandwidth Profile per VUNI End Point Service Attribute

[R23] When an Ingress Bandwidth Profile per VUNI is in force, the algorithm and
parameters described in Section 7.6.1 of [MEF 26] MUST be applied to all
incoming ENNI Frames mapped to the VUNI End Point of the VUNI.

[R24] When an Ingress Bandwidth Profile per VUNI is in force, ingress ENNI
Frames mapped to the VUNI End Point of the VUNI MUST NOT be
subjected to any other type of ingress bandwidth profile.

Per Section 7.6.1 of [MEF 26], each ingress ENNI Frame can be the subject of at most one
ingress Bandwidth Profile. The Ingress Bandwidth Profile per VUNI manages bandwidth non-
discriminately for all OVCs supported by the VUNI.

7.4.2 Egress Bandwidth Profile per VUNI End Point Service Attribute

[R25] When an Egress Bandwidth Profile per VUNI is in force, suitable parameters
<CIR, CBS, EIR, EBS, CF, CM> as defined in Section 7.6.1 of [MEF 26]
MUST be specified and all egress ENNI Frames mapped to the given VUNI
End Point MUST have the property defined in 7.6.3 of [MEF 26].

[R26] When an Egress Bandwidth Profile per VUNI is in force, egress ENNI Frames
mapped to the VUNI End Point of the VUNI MUST NOT be subjected to any
other type of egress bandwidth profile.

The Egress Bandwidth Profile per VUNI, when present, manages bandwidth non-discriminately
for all OVCs supported by the VUNI. Therefore, some OVCs may get more bandwidth while
others may get less.

MEF 28 The Metro Ethernet Forum 2011. 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.
External Network Network Interface Support for UTA and VUNI

7.4.3 Ingress Bandwidth Profile per OVC End Point associated by a VUNI Service
Attribute

The Ingress Bandwidth Profile per OVC End Point associated by a VUNI describes ingress
policing by the VUNI Provider MEN on all ingress ENNI Frames mapped to a given OVC End
Point associated by a VUNI.

[R27] When the Ingress Bandwidth Profile per OVC End Point associated by a
VUNI is in force for a given OVC End Point, suitable parameters <CIR, CBS,
EIR, EBS, CF, CM> as defined in Section 7.6.1 of [MEF 26] MUST be
specified and the algorithm of Section 7.6.1 of [MEF 26] MUST be applied to
all ingress ENNI Frames that are mapped to the given OVC End Point.

7.4.4 Ingress Bandwidth Profile per Class of Service Identifier per OVC End Point
associated by a VUNI Service Attribute

The Ingress Bandwidth Profile per Class of Service Identifier per OVC End Point associated by a
VUNI describes ingress policing by the VUNI Provider MEN on all ingress ENNI Frames with a
given Class of Service Identifier mapped to the OVC End Point associated by a VUNI.

[R28] When the Ingress Bandwidth Profile per Class of Service Identifier per OVC
End Point associated by a VUNI is in force, suitable parameters <CIR, CBS,
EIR, EBS, CF, CM> as defined in Section 7.6.1 of [MEF 26] MUST be
specified and the algorithm of Section 7.6.1 of [MEF 26] MUST be applied to
all ingress ENNI Frames mapped to the OVC End Point that have the given
Class of Service Identifier.

7.4.5 Egress Bandwidth Profile per OVC End Point associated by a VUNI Service
Attribute

The Egress Bandwidth Profile per OVC End Point associated by a VUNI describes egress
shaping by the VUNI Provider MEN on all egress ENNI Frames mapped to a given OVC End
Point associated by a VUNI.

[R29] When the Egress Bandwidth Profile per OVC End Point associated by a
VUNI is in force for a given OVC End Point, suitable parameters <CIR, CBS,
EIR, EBS, CF, CM> as defined in Section 7.6.1 of [MEF 26] MUST be
specified and all egress ENNI Frames mapped to the given OVC End Point
MUST have the property defined in 7.6.3 of [MEF 26].

7.4.6 Egress Bandwidth Profile per Class of Service Identifier per OVC End Point
associated by a VUNI Service Attribute

The Egress Bandwidth Profile per Class of Service Identifier per OVC End Point associated by a
VUNI describes egress shaping by the VUNI Provider MEN on all egress ENNI Frames with a
given Class of Service Identifier mapped to the OVC End Point associated by a VUNI.

MEF 28 The Metro Ethernet Forum 2011. 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.
External Network Network Interface Support for UTA and VUNI

[R30] When the Egress Bandwidth Profile per Class of Service Identifier per OVC
End Point associated by a VUNI is in force, suitable parameters <CIR, CBS,
EIR, EBS, CF, CM> as defined in Section 7.6.1 of [MEF 26] MUST be
specified and all egress ENNI Frames mapped to the given OVC End Point
that have the Class of Service Identifier MUST have the property defined in
7.6.3 of [MEF 26].

7.4.7 Color Awareness at the VUNI

[R31] When CM = "Color-Aware", the color marking for the ENNI frame MUST be
based on the C-Tag PCP or the DSCP as mandated in [MEF 23] for the M and
L CoS labels.

MEF 28 The Metro Ethernet Forum 2011. 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.
External Network Network Interface Support for UTA and VUNI

8 Appendix A: Example: Multiple EVCs


A number of abbreviations are used in the figures to avoid clutter. These are shown in Table 9.

Abbreviation Object
C-VID C-VLAN ID value
S-VID S-VLAN ID value
O EP OVC End Point Identifier value
V EP VUNI End Point Identifier value
Table 9: Abbreviations Used in the Examples

In addition, the figures accompanying the examples use the icons as shown in Figure 4.

Figure 4 Key to the Icons Used in the Examples

Figure 5 shows an example of both a point to point EVC and multipoint EVC in which remote
UNI A participates as seen by the Subscriber. The associated CE VLAN ID mapping to the EVC
is depicted at each UNI.

Figure 5 Example of the remote UNI in multiple EVCs

Figure 6 shows how the UTA and a VUNI may be employed to instantiate the services in Figure
5. Note that the remote UNI A OVC End Point Map Service Attribute maps all CE-VLAN ID

MEF 28 The Metro Ethernet Forum 2011. 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.
External Network Network Interface Support for UTA and VUNI

values to the OVC End Point (see Table 3), and the end point mapping at the VUNI associates
the C-VIDs with the OVCs supporting the Subscriber EVCs (see Table 8).

Figure 6 Example multiple EVCs supported by UTA and VUNI


At the ENNI between MEN B and MEN C, Figure 6 shows the mapping of frames with an S-
VID of 2023 to a VUNI End Point representing VUNI A.

MEF 28 The Metro Ethernet Forum 2011. 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.
External Network Network Interface Support for UTA and VUNI

9 Appendix B: Multi-MEN UTA

This technical specification presented the base concepts behind the UTA model as applicable to
tunnels that traverse a single Network Operator. This appendix illustrates how the UNI tunnel
access model may be generalized to multi-MEN scenarios. Figure 7 provides a model showing
the context for the UTA among two Network Operators and the VUNI Provider. (See 802.1Qbc
for more details.)

UTA
VUNI / RUNI Service
Association Components
CE
UNI W
Virtual Remote
UNI Network Network UNI
Operator B Operator A
VUNI
Provider

CE
(Network Operator C) Tunnel Extension OVC UTA OVC

ENNI UNI Y
ENNI
UNI X CB BA
VUNI OVC CB OVC CB OVC BA OVC BA
CE End Point End Point End Point End Point End Point

Figure 7 - Multi-MEN UNI tunnel access model

As in Figure 1, the VUNI in the VUNI Providers MEN has service attributes similar to those of
a UNI, and is paired with a remote UNI in the Network Operator As MEN. In this scenario,
however, the UTA is realized via two OVCs, one associating the remote UNI in Network
Operator A (UNI Y) with the ENNI with Network Operator B (ENNI BA), and one OVC
(Tunnel Extension OVC) associating ENNI BA with the ENNI for the VUNI Provider (ENNI
CB).

The rules for configuration of the UTA OVC (OVC BA) and the associated OVC End Point
Service Attributes follow the same rules as the UTA OVC specified in Sections 5.1 and 5.3.
Service Attribute constraints related to the Tunnel Extension OVC are for further study.

Figure 8 illustrates the generalization of the multi-EVC scenario in Appendix A, Figure 6, to a


multi-MEN UTA. The scenario in Figure 8 assumes the same EVC configurations as in
Appendix A, Figure 5, however the UTA is now supported by two OVCs: a) one Tunnel
Extension OVC traversing Network Operator C, and b) one UTA OVC between the remote UNI
on Network Operator D and the ENNI between Network Operator D and Network Operator C.
At this ENNI an S-VID of 3456 is used to map the ENNI frames between the two Network
Operators to the OVCs supporting the UTA.

MEF 28 The Metro Ethernet Forum 2011. 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.
External Network Network Interface Support for UTA and VUNI

Figure 8 - Example multiple EVCs supported by a multi-MEN UTA

Note that this extension to the UTA model will work well in conjunction with future definitions
of ENNI-to-ENNI OVC Services.

MEF 28 The Metro Ethernet Forum 2011. 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.
External Network Network Interface Support for UTA and VUNI

10 Appendix C: VUNI Implementation Example


This section describes how a VUNI could be implemented using the IEEE 802.1 Provider Bridge
model as described in [IEEE 802.1ad]. The model uses C-VLAN components and S-VLAN
components. (See 802.1Qbc for more details.)

C-VLAN component: A VLAN-aware bridge component that can recognize, insert, and remove
Customer VLAN tags.

S-VLAN component: A VLAN-aware bridge component that can recognize, insert, and remove
Service VLAN tags.

The example described in this section uses a C-VLAN component per Remote UNI. Figure 9
models the functions of an interface realizing the data path ENNI-N and VUNI functions.

Operator Edge Device Blocked Port Untagged and C-TAG only frames

S-Bridge or
MPLS or other C-Component S-Component
One physical link
SVLAN or Label 1 SVLAN-1
SVLAN or Label 2
or bundle
To Physical ports or switching fabric

SVLAN or Label 4095


C-Bridge #1
UNI Tunnel Access
SVLAN or Label 1 SVLAN-2
SVLAN or Label 2
C-Bridge #2

SVLAN or Label 99 VUNIA

SVLAN or Label 99 C-Bridge #5


S-VLAN 15

SVLAN or Label 100

VUNIB

SVLAN or Label Z S-4094


EVCs
Datapaths
C-Bridge #4094
ENNI
VUNI Untagged
OVC End Points
End Points (Process/peer/disc)

Figure 9 VUNI Using IEEE 802.1 C and S Components Model

The figure shows two VUNIs and 2 EVCs (dashed green and solid blue lines) supported by the
tunnels. The dashed green EVC is a point-to-point EVC sharing a VUNI with the multipoint blue
EVC. The multipoint blue EVC is associated with the two remote UNIs located on the other end
of the two UTA OVCs. In this scenario, a frame in the blue EVC coming from a remote UNI,
could be hairpin switched and sent to the other remote UNI.

Life of a frame:

Ingress direction (going from the right to left in Figure 9):

MEF 28 The Metro Ethernet Forum 2011. 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.
External Network Network Interface Support for UTA and VUNI

An ENNI frame is received at the ENNI from the Network Operator that supports the UTA
OVC. If it is untagged, it is not mapped to a VUNI End Point (or OVC End Point). If there is an
S-TAG, the S-VLAN component maps the frame to the corresponding VUNI End Point based on
the S-VLAN ID value and removes the S-TAG.

The frame is sent to a C-VLAN component associated with the VUNI End Point. The C-VLAN
component will map the frame to one of its 4094 virtual ports based on the C-VLAN ID value.

The frame is received at the OVC End Point associated with the C-VLAN component virtual
port by an entity which performs further encapsulation. The nature of this encapsulation is
dependent on the VUNI Provider MEN and is out of the scope of this specification.

Egress direction (from left to right in Figure 9):

A frame associated with an OVC in the VUNI Provider MEN is received at an OVC End Point
associated by a VUNI. The frame is stripped of the overhead used internally in the VUNI
Provider MEN to identify the OVC End Point.16

The frame is received by C-VLAN Component which maps all the frames to the port connected
to its VUNI End Point.

The frame is sent to the S-VLAN Component which adds the S-TAG and sends the now
complete ENNI frame to the Network Operator MEN.

Note that a C-VLAN component is required to process L2CP PDUs according to the IEEE
802.1Q specifications.

16
It is assumed the VUNI Provider does not transport Service Frames natively in its MEN without encapsulating
them further in order to segregate the traffic from various OVCs.
MEF 28 The Metro Ethernet Forum 2011. 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.
External Network Network Interface Support for UTA and VUNI

11 References
[MEF 10.2] Metro Ethernet Forum, MEF 10.2, Ethernet Services Attributes Phase 2,
October 2009.

[MEF 23] Metro Ethernet Forum, MEF 23, Metro Ethernet Forum, Implementation
Agreement: Carrier Ethernet Class of Service Phase 1, June 2009.

[MEF 26] Metro Ethernet Forum, MEF 26, External Network Network Interface (ENNI)
Phase 1, January 2010.

[IEEE 802.1ad] IEEE Standard 802.1ad Provider Bridges, May 2006.

[IEEE P802.1Qbc] IEEE Draft Standard 802.1Qbc/D1.1 Virtual Bridged Local Area
Network Amendment: Provider Bridging Remote Customer Service
Interfaces, Draft 1.1, February 2010.

MEF 28 The Metro Ethernet Forum 2011. 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.
Embedded Secure Document
The file http://metroethernetforum.org/PDF_Documents/Introduction-to-CESoE.pdf is a secure document
that has been embedded in this document. Double click the pushpin to view.
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Synchronization over Carrier Ethernet & In this Section


Circuit Emulation 9 Synchronization over Carrier
Ethernet & Circuit Emulation
Study Guide Section 9.4.4 < br/>
SyncE 9.1 Purpose and Need

When connecting network elements in order to create a network, it is 9.1.1 What is CESoETH
common practice to consider and provision for various failures. Ideally, the 9.1.2 MEF 8 model
traffic should continue to flow even if a failure of a link or a port occurred. < br/>

There are three types of failures to consider: 9.2 CES Components

9.2.1 Interface to Customer


1. Port Failure
2. Link Failure 9.2.2 Generic Interworking
Function (GIWF)
3. Network Element (NE) Failure
9.2.3 Functional Layering

< br/>

9.3 Service Definitions

9.3.1 E-Line

9.3.2 UNI Attributes
Port protection 9.3.3 EVC Attributes

We focus our discussion on external Interfaces (UNI or ENNI). MEF 20 defined 9.3.4 EVC per UNI Attributes

as mandatory feature ofUNI type 2.2 the capability to protect against a UNI-N < br/>
port failure and / or protecting against a failure of a physical link crossing the
9.4 Synchronization
UNI point.
9.4.1 Packet Based
Synchronization Methods
UNI protection is depicted in the following figure:
9.4.1.1 Adaptive Clock Recovery
Figure: UNI Protection
9.4.1.2 NTP
ENNI protectionis depicted in the following figure: 9.4.1.3 1588 v2

Figure: ENNI Protection 9.4.2 SyncE

It should be noted that some vendors do allow LAG between different line- Download PDF
cards or chassis and thus utilize LAG not only for port & link protection but
also for NE protection. However, there is no industry standard for this
solution. Download a pdf for
offline viewing.
Service protection

Service Protection deals with the need to ensure that the EVC / OVC can carry
provide the service even if specific link or node within the CEN fails.
Reference Documents
Figure: Active StandbyEVC

MEF 8

MEF 22.1

MEF Reference Presentation: Access


Technologies

MEF-CECP Test Objectives

9 CES over Ethernet

Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact

MEF Training Services Ethernet Academy


Studying for MEF-CECP Certification


MEF-CECP Study Guide

Study Guide Test Objectives References MEF Glossary MEF Diagrams


Links to all the topics List of the certification Links to all documents Consolidated list of Gallery of diagrams used
covered by the MEF-CECP test objectives providing referenced by the MEF- primary and equivalent in MEF materials
Study Guide in one easy- the examinee with a CECP certification exam, terms used in the MEF
to-navigate page summary of the topics as well as other useful
covered in the MEF-CECP information
exam

Carrier Ethernet Service Operations, In this Section


Administration and Maintenance 10 Carrier Ethernet Service
Operations, Administration and
Study Guide Section 10.6.1.1 Maintenance

10.1 Relevant Standards


Measurements in E-Line, E-LAN, E-Tree
10.1.1 IEEE 802.1ag Overview
This topic discusses the implementation of the various Performance 10.1.2 Y.1731 Overview
Management attribute computation methods for a given Ethernet Service type.
< br/>
For E-Line services, the one-way performance attributes (Frame Delay, Frame 10.2 Framework
Loss Ratio, etc.) are measured and computed separately in each direction
10.2.0 Domains
(UNI A to UNI B and UNI B to UNI A). A SP may set performance objectives
10.2.1 Constructs
and measure performance for both directions or only one direction.
10.2.1.1 MEP, MIP, MEG, MEG
For E-LAN and E-Tree the computation is more complex. Such a service has N Level
UNIs associated with it. Since measurement is made between pairs of UNIs, 10.2.2 MEF 17
scalability and complexity issues may require monitoring only a sub-set of the 10.2.2.1 Model
UNI pairs. Note that for E-LAN with 6 UNIs, there are 6X5 = 30 UNI pairs. The
10.2.2.2 Maintenance Entities
Service Provider specifies a sub-set (denoted by S) of the UNI pairs for which
to perform performance monitoring. This could be the entire list, an empty < br/>
list or any sub-set of that list. 10.3 Fault Management

10.3.1 Definition
For a Rooted-Multipoint EVC, S must be such that all ordered pairs in S
contain at least one UNI that is designated as a Root. This is required since 10.3.2 Procedures
two leaf UNIs cannot communicate with each other. For each UNI pair within 10.3.2.1 Continuity Check
the sub-set S, the procedures are carried out and summarized every time Message

interval T (T can be different per attribute) 10.3.2.2 Loopback Message

10.3.2.3 Link Trace Message


The value for S is the Max value over all ordered pairs for this time interval T.
For example FLR for an E-LAN or E-Tree is computed after computing the FLR < br/>
for each ordered pair of UNIs within S, as: 10.4 Performance Management

10.4.1 Definition

10.4.2 Procedures

10.4.2.0 Frame Delay

10.4.2.1 Delay Measurement


Message
The only attribute that should be computed differently is One-Way Mean 10.4.2.2 Loss Measurement
Frame Delay. For Mean Frame Delay, the value is calculated as the Arithmetic Message
Mean over all Mean Frame Delays of the ordered UNI pairs. 10.4.3 Computation Methods

10.4.3.0 Frame Delay

10.4.3.1 Inter-Frame Delay


Variation

10.4.3.2 Frame Loss Ratio

10.4.3.3 Availability

10.4.4 Measurement in E-Line, E-


LAN, E-Tree

< br/>

10.5 CoS Implementation


Agreement - MEF 23

10.5.1 Ethernet Network Section

10.5.2 CoS Label Model

10.5.3 Performance Parameters

< br/>

10.6 Performance Management


Implementation

10.6.1 Multi-CoS EVC

10.6.2 Relationship to Bandwidth


Profile

10.6.3 Interconnect via ENNI

Download PDF

Download a pdf for


offline viewing.

Reference Documents

MEF 10.2

MEF 17

MEF Reference Presentation:


Interconnect

ITU-T Y.1731

MEF-CECP Test Objectives

10 Service OAM
Send Feedback

Name:

Email:

Comments

Send Feedback

Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Technical Specification
MEF 17

Service OAM Requirements & Framework


Phase 1

April 2007

MEF 17 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, 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.
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 re-
presentation or warranty, expressed or implied, is made by the MEF concerning the complete-
ness, 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 docu-
ment 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:

any express or implied license or right to or under any patent, copyright, trademark or trade se-
cret 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

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 prod-
uct(s) and/or service(s) embody any or all of the ideas, technologies, or concepts contained here-
in; nor

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 speci-
fications will be voluntary, and no company shall be obliged to implement them by virtue of par-
ticipation in the Metro Ethernet Forum. The MEF is a non-profit international organization acce-
lerating 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 17 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, 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.
Service OAM Requirements & Framework

Table of Contents
1. Abstract ................................................................................................................................ 3

2. Terminology......................................................................................................................... 3

3. Scope..................................................................................................................................... 4

4. Compliance Levels .............................................................................................................. 4

5. Introduction ......................................................................................................................... 5

6. Ethernet Services Layer ..................................................................................................... 6

7. OAM Domains ..................................................................................................................... 7

8. OAM Components .............................................................................................................. 8


8.1 Maintenance Entity (ME) .................................................................................................. 8
8.2 Maintenance Entity Group (MEG) .................................................................................... 9
8.3 MEG End Point (MEP)...................................................................................................... 9
8.4 MEG Intermediate Point (MIP) ......................................................................................... 9
8.5 Traffic Conditioning Point (TrCP) .................................................................................... 9
8.6 MEG Level ........................................................................................................................ 9
8.7 MEG Class of Service (CoS) ........................................................................................... 10
9. Service OAM Requirements ............................................................................................ 10
9.1 Discovery ......................................................................................................................... 10
9.2 Connectivity..................................................................................................................... 11
9.3 Frame Loss Ratio (FLR) Performance ............................................................................ 12
9.4 Frame Delay Performance ............................................................................................... 13
9.5 Frame Delay Variation (FDV) Performance ................................................................... 13
9.6 Availability ...................................................................................................................... 14
9.7 Service OAM Transparency ............................................................................................ 14
9.8 Data Plane Execution....................................................................................................... 15
9.9 TRAN Layer Independence ............................................................................................. 15
9.10 APP Layer Independence ................................................................................................ 15
10. References .......................................................................................................................... 15

Appendix A: Relationship among different OAM Activities .................................................. 17

List of Figures
Figure 1: MEN External Interfaces & Associated Reference Points .............................................. 5
Figure 2: MEN Layer Network Model ........................................................................................... 6
Figure 3: Generic Reference Model for Network/Service Management ........................................ 6
Figure 4: ETH Layer Interfaces and Reference Points ................................................................... 7
MEF 17 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.
Service OAM Requirements & Framework

Figure 5: Point-to-point MEs at ETH Layer ................................................................................... 8


Figure 6: Relationship across different OAM Components ......................................................... 17

MEF 17 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.
Service OAM Requirements & Framework

1. Abstract
OAM (Operations, Administration and Maintenance) can be used to manage network infrastruc-
tures and services provided across these network infrastructures. This document provides re-
quirements and framework for Service OAM within MEF compliant Metro Ethernet Networks
(MENs). Service OAM requirements represent expectations of Service Providers in managing
Ethernet Services within the MENs and Subscribers in managing Ethernet Services across the
MENs. Service OAM framework describes the high-level constructs used to model different
MEN and Service components that are relevant for OAM. The framework also describes the re-
lationship between Service OAM and the architectural constructs of Ethernet Services (ETH),
Transport Service (TRAN) and Application Service (APP) Layers as identified in [MEF 4].

2. Terminology
Term Definition
APP Application Layer
CLE Customer Located Equipment
COS Class of Service
CPE Customer Premise Equipment
E-LMI Ethernet Link Management Interface
EMS Element Management System
E-NNI External NNI
EoSONET Ethernet over SONET
ESCF Ethernet Subscriber Conditioning Function
ETH Ethernet Services Layer
EVC Ethernet Virtual Connection
FDV Frame Delay Variation
FLR Frame Loss Ratio
I-NNI Internal NNI
LANE ATM LAN Emulation
MAC Media Access Control
ME Maintenance Entity
MEG Maintenance Entity Group
MEN Metro Ethernet Networks
MEP MEG End Point
MIP MEG Intermediate Point
MPLS Multi-Protocol Label Switching
NDD Network Demarcation Device
NE Network Element
NI-NNI Network Interworking NNI
NMS Network Management System
NNI Network-Network Interface
OAM Operations, Administration and Maintenance
PW Pseudo Wire

MEF 17 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.
Service OAM Requirements & Framework

Term Definition
SI-NNI Service Interworking NNI
SLA Service Level Agreement
SLS Service Level Specification
SNI Service Node Interface
TRAN Transport Layer
TrCP Traffic Conditioning Point
UNI User-Network Interface
VPLS Virtual Private LAN Service
VPLS Virtual Private LAN Service
VPWS Virtual Private Wire Service
xSTP Spanning Tree Protocol (multiple variations)

3. Scope
The scope of this document is to provide requirements to be satisfied by the Service OAM me-
chanisms in MENs and to provide a framework for discussing and implementing those mechan-
isms. Provisioning aspects of the Ethernet Services and MENs are not considered in this docu-
ment. Also, this document is limited to specifying requirements and framework for OAM me-
chanisms among MEN network elements functioning at ETH Layer and does not account for
OAM interface between MEN network elements and NMS/EMS systems.

The specific functional areas of Services OAM addressed by this document include:
Fault Management (including detection, verification, localization and notification)
Performance Monitoring (including performance parameters measurements)
Auto-discovery (including discovering service aware NE within provider networks)
Intra-provider and inter-provider Service OAM

Service OAM mechanisms include support for OAM across a specific Class of Service (CoS)
instances when multiple CoS instances are supported within an Ethernet service and need to be
managed individually, specifically for the purposes of performance monitoring.

Specific functional areas not addressed by this document include:


Ethernet Service configuration and provisioning
TRAN Layer OAM

Detailed specifications of OAM mechanisms and/or protocols are outside the scope of this doc-
ument.

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 in upper case,
bold text.
MEF 17 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.
Service OAM Requirements & Framework

5. Introduction
[MEF 4] introduces relevant interfaces and reference points that apply to Metro Ethernet Net-
works (MENs), as shown in Figure 1. Subscribers connect to MEN across a User-to-Network
Interface (UNI). Network Elements (NEs) inside MEN are interconnected via Internal Network-
to-Network Interfaces (NNIs) (I-NNIs-not shown in Figure 1). Two autonomous MENs may in-
terconnect at an External NNI (E-NNI). MENs may also interconnect with other transport net-
works via Network Interworking NNI (NI-NNI) or with other service networks via Service In-
terworking NNI (SI-NNI). Figure 5 uses relevant reference points to highlight Service OAM ap-
plicability.

Other L2/L2+
Services Networks
Subscriber
(e.g., ATM, FR, IP)
Service UNI
Interworking
NNI
MEN
UNI
Metro Service Provider Z1
Ethernet Network External
Subscriber (MEN) NNI External
NNI
Service Provider X Ethernet
Wide Area Network MEN
Network (E-WAN)
Interworking Service Provider Z2
Service Provider Y
NNI
Other L1
Transport Networks UNI
(e.g., SONET, SDH, OTN)

Subscriber
Network
Interworking
NNI
MEN
Service Provider X

Figure 1: MEN External Interfaces & Associated Reference Points

Figure 2 introduces the MEN layered network model with the data, control and management
planes. These planes may be present for all three Layers of this model, namely Transport Service
Layer (TRAN Layer), Ethernet Service Layer (ETH Layer) and Application Service Layer (APP
Layer). This document focuses on the management plane of the Ethernet Services Layer.

MEF 17 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.
Service OAM Requirements & Framework

Figure 2: MEN Layer Network Model

Figure 3 highlights a typical arrangement applied by Service Providers to manage their networks
and services offered across these networks. The focus of this document is to address the require-
ments and framework for Service OAM across the NEs. Network/service management using the
NMS-EMS management interface is addressed in [MEF 7] and NE management requirements
are provided in [MEF 15].

NMS
Environment

EMS-NMS Interface

EMS EMS

EMS-NE Interface

NE NE NE NE NE NE

Supplier Flow Domain Supplier Flow Domain

Figure 3: Generic Reference Model for Network/Service Management

6. Ethernet Services Layer


Figure 4 represents the ETH Layer of Figure 2 along with corresponding MEN reference points,
and represents both single and multiple MEN Service Providers.

MEF 17 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.
Service OAM Requirements & Framework

Subscriber

MEN Site B
Service

UNI-N

UNI-C
ETH

ETH
Subscriber Provider
X
Site A UNI
UNI
UNI-C

UNI-N
ETH

ETH
E-NNI
MEN

E-NNI

E-NNI
ETH

ETH
Service
Provider Subscriber
Y UNI Site C

UNI-N

UNI-C
ETH

ETH
Ethernet Services Layer

Figure 4: ETH Layer Interfaces and Reference Points

A Multipoint-to-Multipoint Ethernet service is represented in the above figure across Subscriber


Sites A, B, and C. A similar representation for a Point-to-Point service can be made using either
a single or multiple Service Provider MENs.

From the perspective of the ETH Layer OAM, only those components related to Ethernet ser-
vice-aware functions are relevant. An EVC is a logical construct in the ETH Layer which is used
to enable end-to-end Subscriber service instances across one or more MEN Service Providers
[MEF 12]. Section 8 introduces Maintenance Entity Groups (MEGs) across the Subscriber and
Service Provider networks, with specific focus on Service Provider MEGs that need to be ma-
naged via Services OAM.

7. OAM Domains
An OAM Domain is defined as a network or sub-network, operating at the ETH Layer and be-
longing to the same administrative entity, within which OAM frames can be exchanged.

Each Service Provider and/or Operator network is typically associated with an administrative
boundary. A service may be realized across a single or multiple (sub) network(s). An OAM Do-
main determines the span of an OAM flow across such administration boundaries. OAM Do-
mains can be hierarchical but must not partially overlap. This hierarchical view of OAM Do-
mains allows the following business relationships and accountability. The OAM Framework as
proposed in this document does not address overlapping OAM Domains.

A Subscriber OAM Domain may completely overlap multiple Service Providers OAM Domains
such that Service Providers OAM Domains remain transparent to Subscribers OAM Domain.

MEF 17 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.
Service OAM Requirements & Framework

A Service Provider OAM Domain may completely overlap multiple Network Operators OAM
Domains such that Network Operators OAM Domains remain transparent to Service Providers
OAM Domain.

8. OAM Components

8.1 Maintenance Entity (ME)


To determine the application of OAM flows, an OAM Maintenance Entity (ME) is introduced,
where a ME represents an OAM entity that requires management.

Figure 5 highlights MEs typically involved in different OAM domains. These MEs correspond
purely to the ETH Layer. A ME is essentially an association between two maintenance end
points within an OAM Domain; where each maintenance end point corresponds to a provisioned
reference point that requires management.

The Subscriber OAM Domain consists of the ME marked Subscriber ME. The Service Pro-
vider OAM Domains consists of the ME marked EVC ME. If UNI between Subscriber and
Service Provider needs to be managed, a UNI ME can be realized as shown in the figure. If the
Service Provider utilizes facilities of two different Network Operators, each Network Operator
OAM Domain could consist of MEs marked as Operator A ME and Operator B ME. Simi-
larly, if the NNI between Network Operators needs to be managed, a NNI ME can be realized.

For the purposes of Service OAM, the focus of this framework is on UNI MEs, EVC MEs, and
Subscriber MEs that are associated with services. Other MEs shown in Figure 5 are outside the
scope of this document.

Note: Service OAM framework and requirements associated with E-NNI MEs, SNI MEs, etc. are
expected to be covered in future versions of this document.

Subscriber Subscriber
Equipment Operator A NEs Service Provider Operator B NEs Equipment

1 2 3 4 5 6 7 8

Subscriber ME

TrCP TrCP
ETH EVC ME
Operator A ME Operator B ME
UNI ME NNI ME UNI ME

TRAN

Figure 5: Point-to-point MEs at ETH Layer

MEF 17 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.
Service OAM Requirements & Framework

8.2 Maintenance Entity Group (MEG)


A ME Group (MEG) consists of the MEs that belong to the same service inside a common OAM
domain.

For a Point-to-Point EVC, a MEG contains a single ME. For a Multipoint-to-Multipoint EVC of
n UNIs, a MEG contains n*(n-1)/2 MEs.

It is worth noting that though different OAM MEs have been identified, not all may be used in
all deployment scenarios.

8.3 MEG End Point (MEP)


A MEG End Point (MEP) is a provisioned OAM reference point which can initiate and terminate
proactive OAM frames. A MEP can also initiate and react to diagnostic OAM frames. A MEP is
represented by a triangle symbol as shown in Figure 5.

A Point-to-Point EVC has two MEPs, one on each end point of the ME. A Multipoint-to-
Multipoint EVC of n UNIs has n MEPs, one on each end point.

8.4 MEG Intermediate Point (MIP)


MEG Intermediate Point (MIP) is a provisioned OAM reference point which is capable to react
to diagnostic OAM frames initiated by MEPs. A MIP does not initiate proactive or diagnostic
OAM frames. A MIP is represented by a circle symbol in Figure 5.

The number of MIPs in a Point-to-Point EVC or Multipoint-to-Multipoint EVC is dependent on


the specific deployments.

8.5 Traffic Conditioning Point (TrCP)


A Traffic Conditioning Point (TrCP) corresponds to an ESCF (Ethernet Subscriber Conditioning
Function) as shown in Figure 5 of [MEF 12]. A TrCP is represented by a diamond symbol in
Figure 5. Traffic conditioning may occur at the UNI-C/UNI-N, and/or it may occur at other loca-
tions in the network.

Service OAM occurs between the peer MEP instances of a ME. From a network perspective,
traffic conditioning performed at the TrCPs may occur before or after a given MEP, and may oc-
cur within the same NE as the MEP or in another NE. As such, OAM frames generated by a giv-
en MEP may or may not be subject to traffic conditioning.

8.6 MEG Level


MEG Level is used to distinguish between OAM frames belonging to different nested MEs, as
shown in Figure 5. MEs belonging to the same MEG share a common MEG Level. Eight MEG
Levels have been identified for the purposes of Ethernet OAM [Y.17ethoam] [802.1ag].

MEF 17 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.
Service OAM Requirements & Framework

When Subscriber, Service Providers, and Network Operators share the MEG Levels space, allo-
cation of MEG Levels can be negotiated among the different roles involved. A default allocation
of MEG Levels is such that Service OAM frames for a Subscriber ME use MEG Level 7, 6 or 5;
Service OAM frames for an EVC ME use MEG Level 3 or 4 as EVC ME belongs to a Service
Provider OAM Domain; and Operator MEs use MEG Levels 2, 1, or 0. The MEG Levels used
for UNI ME and NNI ME will default to 0. It may be noted that this default allocation of MEG
Level space between Subscribers, Service Providers and Operators could change based on a mu-
tual agreement among them.

Specific MEG Level assignments are outside the scope of this document.

8.7 MEG Class of Service (CoS)


The MEG CoS represents one or more priorities associated with the OAM frames for a given
ME. All MEs inside a MEG share a common CoS profile.

Since an EVC can be associated with service frames with different CoS levels, an EVC ME can
be associated with OAM frames with multiple priorities.

9. Service OAM Requirements


This section provides requirements for Service OAM.

As stated in Section 8, from a Service perspective, a significant ME of interest is an EVC ME


and correspondingly, a significant MEG of interest is an EVC MEG where an EVC MEG con-
sists of one or more EVC MEs.

The following requirements are specifically stated for EVC MEGs and/or EVC MEs, as applica-
ble.

Note: Though requirements are stated specifically for EVC MEGs and/or EVC MEs, these are
also generally applicable to Subscriber MEGs and/or Subscriber MEs. Though requirements are
stated specifically for EVC MEGs and/or EVC MEs, these are also generally applicable to Sub-
scriber MEGs and/or Subscriber MEs and UNI MEs. Requirements applicable to UNI MEs are
for further study.

9.1 Discovery
Discovery allows a Service OAM capable NE to learn sufficient information (e.g. MAC ad-
dresses etc.) regarding other Service OAM capable NEs so that OAM frames can be exchanged
with those discovered NEs.

In context of EVCs, discovery allows Service OAM capable NEs to learn about other Service
OAM capable NEs that support the same EVCs. These NEs are expected to be at the edges of an
OAM domain within which the discovery is carried out.

MEF 17 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.
Service OAM Requirements & Framework

(R1) Service OAM MUST offer the capability for a service aware NE to discover other service-
aware NEs supporting the same EVC inside a Service Provider OAM Domain.

9.2 Connectivity
A ME can have the following Connectivity Status values:
Active: A ME Connectivity Status of active implies that Service OAM frames can be ex-
changed between the MEPs in both directions.
Not Active: A ME Connectivity Status of not active implies that Service OAM frames
cannot be exchanged in both directions between the MEPs of the ME.

A Multipoint-to-Multipoint MEG can have the following Connectivity Status values:


Active: A MEG Connectivity Status of active implies that each ME in the MEG has a
Connectivity Status of active.
Not Active: A MEG Connectivity Status of not active implies that each ME in the MEG
has a Connectivity Status if not active.
Partially Active: A MEG Connectivity Status of partially active implies that there exist at
least one active ME and one not active ME in the MEG.

(R2a) Service OAM MUST offer the capability to monitor the Connectivity Status of a ME.

(R2b) Service OAM MUST offer the capability to monitor the Connectivity Status of a MEG.

(R2c) Service OAM SHOULD offer the capability to detect a change in Connectivity Status
within a configurable time interval. This configurable time interval SHOULD be more than the
network restoration time, which is dependent on the MEN technology.

As an example of R2c, if a MEN is based on bridging technology and xSTP is used for network
restoration, then the configurable time interval for Connectivity Status monitoring of a ME or a
MEG ought to be more than the xSTP restoration time intervals.

Further, when a Connectivity Status becomes not active or partially active, it may be necessary
to verify and localize the fault. This is needed primarily to reduce operating costs by minimising
operational repair times and operational resources.

(R2d) Service OAM MUST offer the capability to verify the existence of a connectivity fault
inside a Service Provider OAM Domain.

(R2e) Service OAM MUST offer the capability to localize a connectivity fault inside a Service
Provider OAM Domain. Localization is expected to identify the MEP and MIP, or pair of MIPs,
in the Service Provider OAM Domain between which the EVC connectivity fault is present.
The determination of EVC status, as defined in [E-LMI], requires determination of the EVC
ME/MEG Connectivity Status and UNI ME/MEG Connectivity Status. Specific mechanisms
used to correlate the different Connectivity Status values are outside the scope of this document.

MEF 17 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.
Service OAM Requirements & Framework

(R2f) Service OAM frames for connectivity SHOULD be transmitted at the highest priority
permissible for the Service frames. This requirement is meant to ensure that Service OAM
frames for connectivity are less likely to be discarded in comparison to the Service frames upon
congestion.

(R2g) Service OAM SHOULD offer the capability to transmit Service OAM frames at any per-
missible priority.

The MEP Connectivity Status for a MEP in a Multipoint-to-Multipoint MEG can have one the
following values:
Fully Connected: A MEP Connectivity Status of fully connected implies that all MEs to
which the MEP belongs are active.
Isolated: A MEG Connectivity Status of isolated implies that all MEs to which the MEP
belongs are not active.
Partially Connected: A MEP Connectivity Status of partially connected implies that,
among all MEs to which the MEP belongs, at least one is active and at least one is not ac-
tive.

(R2h) Service OAM SHOULD offer capability to monitor the MEP Connectivity Status in a
Multipoint-to-Multipoint MEG.

(R2i) Service OAM SHOULD offer capability to detect a change in the MEP Connectivity Sta-
tus within a configurable time interval. This configurable time interval SHOULD be more than
the network restoration time interval, which is dependent MEN technology.

9.3 Frame Loss Ratio (FLR) Performance


Frame loss Ratio (FLR) Performance is a measure of number of lost frames inside the MEN and
is defined as a percentage in [MEF 10].

FLR Performance is applicable to all Service Frames with the level of Bandwidth Profile con-
formance determined to be Green, and associated with a particular CoS instance on a Point-to-
Point EVC that arrive at the UNI during a time interval T, as defined in [MEF 10].

For a Point-to-Point EVC, estimating FLR Performance is dependent on the ability to measure
Frame Loss between the MEPs of an EVC ME during a time interval T. Such measurements are
based on statistics collected at the TrCP points which determine Green, Yellow and Red service
frames.

For a Multipoint-to-Multipoint EVC, FLR Performance is for further study.

(R3a) Service OAM MUST offer capability to estimate Frame Loss for Service Frames with the
level of Bandwidth Profile conformance determined to be Green and associated with a particular
CoS instance between the UNIs of a Point-to-Point EVC during a time interval T inside a Service
Provider OAM Domain. The level of accuracy is for further study.

MEF 17 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.
Service OAM Requirements & Framework

9.4 Frame Delay Performance


Frame Delay is the time required to transmit a Service Frame from source UNI to destination
UNI across the MEN as defined in [MEF 10]. Frame Delay Performance for a particular CoS
instance on a Point-to-Point EVC is a measure of the delays experienced by different Service
Frames belonging to the same CoS instance.

Frame Delay Performance for a particular CoS instance on a Point-to-Point EVC for a time in-
terval T is defined as P-Percentile of the delay for all Service Frames with the level of Bandwidth
Profile conformance determined to be Green, successfully delivered between the UNI pairs dur-
ing a time interval T, as defined in [MEF 10].

For a Point-to-Point EVC, estimating Frame Delay Performance is dependent on the ability to
measure Frame Delay experienced by Green Service Frames, belonging to a particular CoS in-
stance, between the UNI pairs of a Point-to-Point EVC. Such measurements can be approx-
imated by the Frame Delay experienced by Service OAM Frames belonging to the CoS instance
if the Service OAM Frames receive the same treatment as the Green Service Frames between the
MEPs of a Point-to-Point EVC ME.

For a Multipoint-to-Multipoint EVC, Frame Delay Performance is for further study.

Frame Delay can be of two types: a) one-way Frame Delay, or b) two-way Frame Delay. One-
way Frame Delay is used to characterize various applications and services (e.g. broadcast appli-
cations) and its measurement generally requires synchronization of clocks between the two par-
ticipating NEs. Two-way Frame Delay, in most cases (e.g. voice applications) is considered to be
sufficient metric since it is the one that most influences the application quality e.g. length of si-
lence in IP-phone calls.

(R4a) Service OAM MUST offer the capability to estimate two-way Frame Delay experienced
by Service Frames with the level of Bandwidth Profile conformance determined to be Green and
associated with a particular CoS instance between the UNIs of a Point-to-Point EVC during a
time interval T inside a Service Provider OAM Domain. The level of accuracy is for further
study.

(R4b) Service OAM SHOULD offer the capability to estimate one-way Frame Delay expe-
rienced by Service Frames with the level of Bandwidth Profile conformance determined to be
Green and associated with a particular CoS instance between the UNIs of a Point-to-Point EVC
during a time interval T inside a Service Provider OAM Domain. The level of accuracy is for
further study.

9.5 Frame Delay Variation (FDV) Performance


Frame Delay Variation (FDV) is the difference in delay of two Service Frames, as defined in
[MEF 10]. FDV Performance for a particular CoS instance on a Point-to-Point EVC is a measure
of the variation in the delays experienced by different Service Frames belonging to the same CoS
instance.
MEF 17 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.
Service OAM Requirements & Framework

FDV Performance is applicable to all successfully delivered Service Frames with the level of
Bandwidth Profile conformance determined to be Green for a particular CoS instance on a Point-
to-Point EVC for a time interval T, as defined in [MEF 10].

For a Point-to-Point EVC, estimating FDV Performance is dependent on the ability to measure
difference between the Frame Delays of a pair of Green Service Frames that belong to a CoS in-
stance and arrive at the ingress UNI exactly t time units apart within the time interval T. Such
measurements can be approximated by the difference between the Frame Delays of a pair of Ser-
vice OAM frames belonging to the CoS instance between the MEPs of a Point-to-Point EVC ME
where the pair of Service OAM frames are inserted exactly t time units apart within the time
interval T, where both t and T are configurable, and where the Service OAM frames receive the
same treatment as Green Service frames.

For a Multipoint-to-Multipoint EVC, FDV Performance is for further study.

FDV can be of two types: a) one-way FDV, and b) two-way FDV.

(R5a) Service OAM MAY offer the capability to measure the difference between the two-way
Frame Delay estimates of a pair of Service Frames with the level of Bandwidth Profile confor-
mance determined to be Green and associated with a particular CoS instance between the UNIs
of a Point-to-Point EVC. The pair of Service OAM frames are inserted exactly t time units
apart within the time interval T, where both t and T are configurable.

(R5b) Service OAM MUST offer the capability to measure the difference between the one-way
Frame Delay estimates of a pair of Service Frames with the level of Bandwidth Profile confor-
mance determined to be Green and associated with a particular CoS instance between the UNIs
of a Point-to-Point EVC. The pair of Service OAM frames are inserted exactly t time units
apart within the time interval T, where both t and T are configurable.

9.6 Availability
For further study.

9.7 Service OAM Transparency


Service OAM frames belonging to an OAM Domain originate and terminate within that OAM
Domain. Security implies that an OAM Domain must be capable of filtering Service OAM
frames. The filtering is such that the Service OAM frames are prevented from leaking outside
their OAM Domain. Also, for hierarchical OAM Domains, Service OAM frames from outside an
OAM Domain should be either discarded (when such Service OAM frames belong to same or
lower-level OAM Domains) or transparently passed (when such Service OAM frames belong to
higher-level OAM Domains).

(R7a) In hierarchical OAM Domains, Service OAM MUST offer the capability to prevent OAM
frames belonging to lower OAM Domain from leaking into higher OAM Domain.

MEF 17 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.
Service OAM Requirements & Framework

(R7b) In hierarchical OAM Domains, Service OAM MUST offer the capability to transparently
carry OAM frames belonging to higher OAM Domain across lower OAM Domain.

9.8 Data Plane Execution


(R8a) Service OAM frames MUST follow the same path across the MEN as the Service frames
in an EVC.

9.9 TRAN Layer Independence


The ETH Layer is independent of the TRAN Layer, as shown in Figure 2. The TRAN Layer may
offer its own OAM capabilities; ETH Layer OAM should be independent of underlying TRAN
Layer. However, when a fault is detected in the TRAN Layer, it may be useful to communicate
such a fault to the ETH Layer. For example, a fault in TRAN Layer should not cause multiple
alarm events to be raised and should not result in unnecessary corrective actions to be taken in
ETH Layer, when the fault can be restored in the TRAN Layer.

As a result, though the Service OAM should be independent of the TRAN Layer OAM, it should
allow interworking with TRAN Layer OAM for the purposes of fault notifications.

(R9a) Service OAM MUST offer OAM capabilities without dependency on underlying TRAN
Layer technologies and OAM capabilities.

(R9b) Service OAM SHOULD allow interworking with TRAN Layer OAM for forwarding
TRAN Layer fault conditions to allow alarm suppression at ETH Layer.

9.10 APP Layer Independence


The ETH Layer is independent of the APP Layer, as shown in Figure 2. The APP Layer may of-
fer its own OAM capabilities; but ETH Layer OAM should be independent of APP Layer.

(R10) Service OAM MUST offer OAM capabilities without dependency on APP Layer technol-
ogies and OAM capabilities.

10. References
[802.1D] IEEE standard for local and metropolitan area networks--Media access control (MAC)
Bridges (Incorporates IEEE 802.1t-2001 and IEEE 802.1w), 2004.

[802.3] IEEE Standard 802.3-2002, Carrier sense multiple access with collision detection
(CSMA/CD) access method and physical layer specifications, 2005.

[MEF 4] Metro Ethernet Network Architecture Framework Part 1: Generic Framework, May
2004.

[MEF 7] EMS-NMS Information Model, October 2004.

MEF 17 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.
Service OAM Requirements & Framework

[MEF 10] Ethernet Service Attributes Phase 1, November 2004.

[MEF 12] Metro Ethernet Network Architecture Framework Part 2: Ethernet Services Layer,
April 2005.

[MEF 15] Requirements for Management of Metro Ethernet Phase I Network Elements, No-
vember 2005.

[MEF 16] Ethernet Local Management Interface, January 2006.

[Y.1730] Requirements for OAM functions in Ethernet based networks, 2004.

[Y.1731] OAM Functions and Mechanisms for Ethernet based networks, May 2006.

[802.1ag] Connectivity Fault Management, work in progress.

MEF 17 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.
Service OAM Requirements & Framework

Appendix A: Relationship among different OAM Activities


MEN at ETH Layer is viewed as a multi-hop Ethernet network consisting of a collection of NEs
with Ethernet bridge functionality e.g. Ethernet layer 2 control protocol processing, forwarding
etc. The connectivity between these NEs may be via IEEE 802.3 compliant Ethernet segments or
virtual Ethernet segments, where virtual Ethernet segments are emulated Ethernet Link/LAN
technologies e.g. Ethernet Pseudo Wires (PW), Virtual Private LAN Service (VPLS), Ethernet
over SONET, ATM LAN Emulation etc.

ETH
Layer Services Service OAM

Network Bridged network OAM


TRAN
Layer
Transport Ethernet VPWS/VPLS SO- Other
Links link OAM OAM NET/SDH OAM

Figure 6: Relationship across different OAM Components

Figure 6 highlights the two MEN Layers (i.e. ETH Layer and TRAN Layer) with the correspond-
ing OAM components belonging to Ethernet services and underlying networks. ETH Layer
represents services and is responsible for Service OAM. Ethernet services are carried across sin-
gle or multi-hop Ethernet networks represented by bridged network under TRAN Layer. The
NEs constituting the bridged networks are in turn connecting with transport links e.g. IEEE
802.3 compliant link, Ethernet PW, VPLS, EoSONET, etc.

The Service OAM work in MEF focuses on the ETH Layer, which corresponds to an EVC inside
a Service Provider OAM Domain. Besides MEF, ITU-T Q.5/13 and IEEE 802.1 are also working
on Ethernet OAM in Y.1731 and 802.1ag draft Recommendations respectively. The work in
ITU-T Q.5/13 and IEEE 802.1 is applicable to Subscriber, Service Provider and Network Opera-
tor OAM Domains.

ITU-T Q.5/13 and IEEE 802.1 work is not limited to Service OAM as it also covers Network
OAM for Ethernet based networks. IEEE 802.1ag focuses on a sub-set of Fault Management for
both enterprise and carrier networks. ITU-T Y.1731 accounts for both Fault Management and
Performance Monitoring specifically for carrier networks. ITU-T Q.5/13 and IEEE 802.1 Ether-
net OAM work is closely aligned to avoid duplication.

MEF 17 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.
Service OAM Requirements & Framework

Based on the transport link technology used to connect the NEs supporting bridging functionality
within Ethernet bridged networks, various link OAM techniques can be applied across the TRAN
Layer. E.g. IEEE 802.3ah has defined link level OAM for IEEE 802.3 compliant links. When
transport link emulates Ethernet over MPLS/IP as in IETF VPWS and VPLS, IETFs PW-OAM
and VPLS-OAM and ITU-T Y.1711 kind mechanisms can be applied to manage those emulated
transport links. If SONET/SDH technology is applied, OAM techniques being defined in ITU-T
Q.12/15 can be applied.

MEF 17 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.
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 00on 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
doesnt 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 s. 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.
Ethernet Access Services Definitions

Technical Specification

MEF 33

Ethernet Access Services Definition

January 2012

MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, 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.
Ethernet Access Services Definitions

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 2012. All Rights Reserved.

MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, 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.
Ethernet Access Services Definitions

Table of Contents
1. ABSTRACT ...............................................................................................................................................................1
2. TERMINOLOGY ......................................................................................................................................................1
3. SCOPE ........................................................................................................................................................................6
4. COMPLIANCE LEVELS .........................................................................................................................................6
5. ETHERNET SERVICE DEFINITION FRAMEWORK (NORMATIVE) ..........................................................7
5.1 ETHERNET ACCESS (E-ACCESS) SERVICE TYPE ...................................................................................................8
6. SERVICE DEFINITIONS (NORMATIVE) ...........................................................................................................9
6.1 ACCESS ETHERNET PRIVATE LINE SERVICE (ACCESS EPL) .................................................................................9
6.1.1 UNI Service Attributes and Parameter Values ..........................................................................................10
6.1.2 OVC per UNI Service Attributes and Parameter Values ...........................................................................11
6.1.3 OVC Service Attributes ..............................................................................................................................12
6.1.4 OVC End Point per ENNI Service Attributes.............................................................................................13
6.1.5 ENNI Service Attributes ............................................................................................................................14
6.2 ACCESS ETHERNET VIRTUAL PRIVATE LINE (ACCESS EVPL) SERVICE DEFINITION (NORMATIVE) ...................15
6.2.1 Maximum CE-VLAN IDs per OVC Attribute ............................................................................................16
6.2.2 UNI Service Attributes ...............................................................................................................................17
6.2.3 OVC per UNI Service Attributes and Parameter Values ...........................................................................17
6.2.4 OVC Service Attributes ..............................................................................................................................18
6.2.5 OVC End Point per ENNI Service Attributes.............................................................................................19
6.2.6 ENNI Service Attributes ............................................................................................................................20
6.3 SERVICE OAM FAULT MANAGEMENT (SOAM-FM) REQUIREMENTS FOR ACCESS EPL AND ACCESS EVPL
SERVICE 21
6.4 L2CP REQUIREMENTS FOR ACCESS EPL AND ACCESS EVPL SERVICE.............................................................22
7. REFERENCES ........................................................................................................................................................22
8. APPENDIX A: EFFECT OF INTER-FRAME OVERHEAD ON CIR (INFORMATIVE) ............................24
9. APPENDIX B: USE CASES (INFORMATIVE) ..................................................................................................25
9.1 EPL SERVICE......................................................................................................................................................25
9.2 EP-LAN SERVICE...............................................................................................................................................28
9.3 EP-LAN SERVICE WITH HAIRPIN SWITCHING BY SERVICE PROVIDER ...............................................................29
9.4 EVPL SERVICE ...................................................................................................................................................31
9.5 ACCESS TO LAYER 3 SERVICES...........................................................................................................................32

List of Figures
Figure 1. Scope of the E-Access Services Definition. ...................................................................................................6
Figure 2: Ethernet Service Definition Framework ........................................................................................................7
Figure 3: A point-to-point example of an E-Access Service type using OVC with UNI and ENNI OVC End Points.8
Figure 4: Overview of Access EPL Service ............................................................................................................... 10
Figure 5: Overview of Access EVPL Service............................................................................................................. 16

MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page i
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.
Ethernet Access Services Definitions

Figure 6. Length of an Ethernet frame as measured with and without the 20 byte inter-frame overhead. ................. 24
Figure 7. Resulting Layer 1 bit rates for different MEF CIR measured as Service Frames ........................................ 25
Figure 8. EPL Service as implemented across two networks using Access EPL, showing the Subscriber and Service
Provider POVs. .................................................................................................................................................... 26
Figure 9. EP-LAN Service as implemented across two networks using Access EPL, showing the Subscriber and
Service Provider Points of View. ......................................................................................................................... 28
Figure 10. EP-LAN example illustrating a Service Provider using hairpin switching between UNI A & B............... 30
Figure 11. EVPL Service as implemented across two networks using Access EVPL, showing the Subscriber and
Service Provider POVs. ....................................................................................................................................... 31
Figure 12. Access aggregation to Layer 3 services using Access EPL or Access EVPL. ........................................... 33

List of Tables
Table 1: Terminology and Definitions Table................................................................................................................6
Table 2: Services defined based on E-Access Service type ..........................................................................................8
Table 3. Example of typical pairings of Service Providers end to end services with supporting services from an
Access Provider. ....................................................................................................................................................9
Table 4: UNI service attributes and parameters for the Access EPL service .............................................................. 11
Table 5: OVC per UNI Service Attributes for Access EPL service. ......................................................................... 12
Table 6: OVC service attributes and parameters for the Access EPL service ............................................................ 13
Table 7: ENNI OVC End Point Service Attributes for the Access EPL service......................................................... 14
Table 8: ENNI Service Attributes for Access EPL Service. ........................................................................................ 15
Table 9: UNI service attributes and parameters for the Access EVPL service ........................................................... 17
Table 10: OVC per UNI Service Attributes for Access EVPL service. ..................................................................... 18
Table 11: OVC service attributes and parameters for the Access EVPL service........................................................ 19
Table 12: ENNI OVC End Point Service Attributes for Access EVPL Service. ........................................................ 20
Table 13: ENNI Service Attributes for Access EVPL Service. ................................................................................... 21
Table 14. Sample attributes for an EPL service. .......................................................................................................... 27
Table 15. Sample attributes for an EP-LAN service. ................................................................................................... 29
Table 16. Change in EP-LAN Attributes in hairpin switching example. ..................................................................... 30
Table 17. Sample attributes for an EVPL service. ....................................................................................................... 32

MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page ii
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.
Ethernet Access Services Definitions

1. Abstract
This document defines Ethernet Access Services, which are OVC-based Ethernet services in
contrast to the EVC-based services which are defined in MEF 6.1 Technical Specification
Ethernet Services Definitions[1]. This document uses the UNI service attributes and
parameters options defined in the MEF 6.1 and ENNI and OVC service attributes defined in
MEF 26 Technical Specification External Network Network Interface (ENNI) Phase 1 [8]
and applies them to create new Ethernet access services between a UNI and an ENNI. These new
carrier-to-carrier Ethernet access services enable Ethernet Service Providers to reach out-of-
franchise customer locations through an Ethernet Access Provider's network, and deliver E-Line
and E-LAN service types end to end. This document defines the UNI, OVC, OVC per UNI,
OVC End Point per ENNI, and ENNI requirements for point-to-point OVC-based Ethernet
services. In addition, an informative appendix is provided showing use cases of some of the
defined services.

2. Terminology
This section defines the terms used in this document. In many cases, the normative definitions to
terms are found in other documents. In these cases, the fourth column is used to provide the
reference that is controlling.
Term Abbrev. Definition Ref
Access EPL service uses a Point-to-Point OVC to associate one This
Access Ethernet Access OVC End Point at a UNI and one OVC End Point at an ENNI. document
Private Line EPL One UNI can support only a single instance of the Access EPL
service.
Access EVPL service uses a Point-to-Point OVC to associate one This
Access Ethernet Access
OVC End Point at a UNI and one OVC End Point at an ENNI. document
Virtual Private Line EVPL
One UNI can support one or more Access EVPL instances.
This
Access Provider AP An Operator MEN that offers the Ethernet Access Service type.
document
A Bandwidth Profile is a characterization of the lengths and MEF 10.2
Bandwidth Profile
arrival times for Service Frames at a reference point. [2]
Bandwidth profile per [2]
A bandwidth profile applied on a per-Class of Service basis.
CoS ID
Bandwidth profile per MEF 26
A bandwidth profile applied on a per-OVC Endpoint basis.
OVC Endpoint [8]
Bandwidth profile per [2]
A bandwidth profile applied on a per-UNI basis.
UNI
Broadcast Service A Service Frame that has the broadcast destination MAC [2]
Frame address.
CE-VLAN CoS ID Customer Edge VLAN CoS. Also C-tag PCP. [2]
CE-VLAN CoS ID Value Preservation describes a relationship [8]
CE-VLAN CoS ID
between the format and certain field values of the frame at one
Value Preservation
External Interface and of the corresponding frame at another
(OVC)
External Interface
CE-VLAN ID Customer Edge VLAN ID [2]

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

Term Abbrev. Definition Ref


CE-VLAN ID Preservation describes a relationship between the [8]
CE-VLAN ID format and certain field values of the frame at one External
Preservation (OVC) Interface and of the corresponding frame at another External
Interface
OVC End Point Map [8]
An association of CE-VLAN IDs with OVCs at a UNI.
at the UNI
CE-VLAN Tag Customer Edge VLAN Tag [2]
A set of Service Frames that have a commitment from the MEF 23.1
Class of Service
CoS Service Provider subject to a particular set of performance [16]
Frame Set
objectives.
Class of Service
The mechanism and/or values of the mechanism to be used to
Identifier for Service [8]
identify the CoS Name that applies to the frame at a given UNI.
Frames (UNI)
Class of Service The mechanism and/or values of the parameters in the [16]
Identifier for ENNI mechanism to be used to identify the CoS Name that applies to
Frames (ENNI) the frame at a given ENNI that maps to an OVC End Point.
A set of Service or ENNI Frames that have a commitment from [16]
Class of Service
the Operator or Service Provider subject to a particular set of
Frame Set
performance objectives.
A CoS Name that is standardized in MEF 23.1. Each CoS Label [16]
identifies four Performance Tiers where each Performance Tier
Class of Service Label
contains a set of performance objectives and associated
parameters.
A designation given to one or more sets of performance [16]
Class of Service Name objectives and associated parameters by the Service Provider or
Operator.
CM is a Bandwidth Profile parameter. The Color Mode [2]
parameter indicates whether the color-aware or color-blind
Color Mode CM
property is employed by the Bandwidth Profile. It takes a value
of color-blind or color-aware only.
Color-aware A Bandwidth Profile property where a pre-determined level of [2], [8]
Bandwidth Profile compliance for each Service or ENNI Frame
is taken into account when determining the level of compliance
for each Service Frame.
Color-blind A Bandwidth Profile property where a pre-determined level of [2], [8]
Bandwidth Profile compliance for each Service Frame, if present,
is ignored when determining the level of compliance for each
Service Frame.
The mechanism and/or values of the parameters in the [16]
mechanism used to identify the Color that applies to the frame at
a given UNI. A particular Color ID value may indicate Color
Color Identifier for instance of Green or Yellow for a Service Frame. PCP and
Service Frame (UNI) DSCP may indicate both CoS Name and Color. Information
derivable from a) a set of one or more C-Tag PCP values or b) a
set of one or more DSCP values.

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

Term Abbrev. Definition Ref


The mechanism and/or values of the parameters in the [16]
mechanism used to identify the Color that applies to the frame at
a given ENNI that maps to an OVC End Point. A particular
Color Identifier for
Color ID value may indicate Color instance of Green or Yellow
ENNI Frames (ENNI)
for an ENNI Frame. PCP may indicate both CoS Name and
Color. Information derivable from a) a set of one or more S-Tag
PCP values or b) DEI value.
CBS is a Bandwidth Profile parameter. It limits the maximum [2]
Committed Burst Size CBS number of bytes available for a burst of Frames sent at the EI
speed to remain CIR-conformant.
CIR is a Bandwidth Profile parameter. It defines the average rate [2]
Committed in bits/s of Frames at an EI up to which the network delivers
CIR
Information Rate Frames, and is committed to meeting the performance objectives
defined by the CoS Service Attribute.
CF is a Bandwidth Profile parameter. The Coupling Flag allows [2]
Coupling Flag CF the choice between two modes of operation of the rate
enforcement algorithm. It takes a value of 0 or 1 only.
Customer Edge CE Equipment on the Subscriber side of the UNI. [2]
The Priority Code Point bits in the IEEE 802.1Q Customer [2]
Customer Edge
VLAN Tag in a Service Frame that is either tagged or priority
VLAN CoS
tagged.
The identifier derivable from the content of a Service Frame that [2]
Customer Edge
allows the Service Frame to be associated with an EVC at the
VLAN ID
UNI.
Ethernet services that use an OVC with at least one UNI OVC This
E-Access Service Type
End Point and one ENNI OVC End Point. document
Egress Bandwidth A service attribute that specifies the length and arrival time [2]
Profile characteristics of egress Frames at the egress EI.
Egress Service Frame A Service Frame sent from within a MEN to an EI. [2]
An Ethernet service type that is based on a Multipoint-to- MEF 6.1
E-LAN Service
Multipoint EVC. [1]
E-Line Service An Ethernet service type that is based on a Point-to-Point EVC. [1]
EPL Ethernet Private Line [1]
ENNI A reference point representing the boundary between two MEF 4 [6]
Operator MENs that are operated as separate administrative
domains
ENNI Frame The first bit of the Destination Address to the last bit of the [8]
Frame Check Sequence of the Ethernet Frame transmitted across
the ENNI
ENNI MTU MTU of an ENNI frame at the ENNI [8]

An Ethernet service type that is based on a Rooted-Multipoint [1]


E-Tree Service
EVC.
Ethernet Access Operator of the MEN providing the OVC-based Ethernet service This
Provider between a UNI and an ENNI. document
Ethernet Virtual An association of two or more UNIs that limits the exchange of [2]
EVC
Connection Service Frames to UNIs in the Ethernet Virtual Connection.
EVC MTU Size The maximum sized Service Frame allowed for an EVC. [2]
EVPL Ethernet Virtual Private Line [1]

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

Term Abbrev. Definition Ref


EBS is a Bandwidth Profile parameter. It limits the maximum [2]
Excess Burst Size EBS number of bytes available for a burst of Frames sent at the EI
speed to remain EIR-conformant.
EIR is a Bandwidth Profile parameter. It defines the average rate [2]
Excess Information
EIR in bits/s of Frames up to which the network may deliver Frames
Rate
but without any performance objectives.
External Interface EI Either a UNI or an ENNI [8]
Frame Short for Ethernet Frame [2]
The time elapsed from the reception of the first bit of the ingress MEF
Frame Delay FD frame at EI 1 until the transmission of the last bit of the 26.0.3
corresponding egress frame at EI 2 . [17]
The difference between the observed percentile of delay at a [2]
Frame Delay Range FDR target percentile and the observed minimum delay for the set of
frames in interval T.
Frame Delay A measure of the delays experienced by different Service or [17]
Performance ENNI Frames belonging to the same CoS Frame Set.
Frame Delay Range A measure of the extent of delay variability experienced by [17]
Performance different Service or ENNI Frames belonging to the same CoS
Frame Set.
Frame Loss Ratio is a measure of the number of lost frames [17]
Frame Loss Ratio
FLR between the ingress EI 1 and the egress EI 2 . Frame Loss Ratio is
Performance
expressed as a percentage.
A characterization of ingress Frame arrival times and lengths at [2]
Ingress Bandwidth
the ingress EI and a specification of disposition of each Frame
Profile
based on its level of compliance with the characterization.
A Service Frame sent from an EI into the Service Provider [2]
Ingress Service Frame
network.
Inter-Frame Delay The difference in delay of two Service or ENNI Frames [17]
IFDV
Variation belonging to the same CoS Frame Set.
Inter-Frame Delay A measure of the variation in the delays experienced by different [17]
Variation Service or ENNI Frames belonging to the same CoS Frame Set.
Performance
Layer 2 Control [2]
L2CP A Service Frame that is used for Layer 2 control, e.g., Spanning
Protocol Service
Frame Tree Protocol.
Frame
The process by which a Layer 2 Control Protocol Service Frame [2]
Layer 2 Control
is passed through the Service Provider network without being
Protocol Tunneling
processed and is delivered unchanged to the proper UNI(s).
Maximum Number of The maximum number of OVCs that may be on a UNI. This
OVCs per UNI document
An integer that indicates the quantity of CE-VLANs that can be This
Maximum Number of
mapped to a single OVC at that UNI. A value = 1 indicates that document
CE-VLAN IDs per
UNI can only map single CE-VLANs to an OVC. A value > 1
OVC
indicates that up to that limit can be mapped to a single OVC.
The arithmetic mean, or average of delays experienced by [17]
Mean Frame Delay
MFD different Service or ENNI Frames belonging to the same CoS
Performance
Frame Set.
MEN Metro Ethernet Network [6]

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

Term Abbrev. Definition Ref


Metro Ethernet [6]
MEN The Service Providers network providing Ethernet services.
Network
Maximum The maximum sized Service Frame allowed for an Ethernet [1]
MTU
Transmission Unit service.
Multicast Service [2]
A Service Frame that has a multicast destination MAC address.
Frame
An EVC with two or more UNIs. A Multipoint-to-Multipoint [2]
Multipoint-to-
EVC with two UNIs is different from a Point-to-Point EVC
Multipoint EVC
because one or more additional UNIs can be added to it.
Operator Virtual Operator Virtual Connection, an association of OVC End Points [8]
OVC
Connection
OVC End Point An association of an OVC with a specific External Interface i.e., [8]
UNI, ENNI
OVC Identifier string that is unique among all OVCs in the Operator MEN [8]
N/A Not Applicable
N/S Not Specified
Point-to-Point EVC An EVC with exactly 2 UNIs. [2]
A multipoint EVC in which each UNI is designated as either a [2]
Root or a Leaf. Ingress Service Frames at a Root UNI can be
Rooted-Multipoint
delivered to one or more of any of the other UNIs in the EVC.
EVC
Ingress Service Frames at a Leaf UNI can only be delivered to
one or more Root UNIs in the EVC.
An Ethernet frame transmitted across the UNI toward the Service [2]
Service Frame Provider or an Ethernet frame transmitted across the UNI toward
the Subscriber.
The contract between the Subscriber or Operator and Service Adopted
Service Level
SLA Provider specifying the agreed to service level commitments and from [2]
Agreement
related business agreements. and [8]
Adopted
Service Level The technical specification of the service level being offered by
SLS from [2]
Specification the Service Provider to the Subscriber or Operator.
and [8]
A UNI service attribute in which the UNI can be in more than [2]
Service Multiplexing
one EVC instance.
Service Provider The organization providing UNI to UNI Ethernet Service(s). [2]
Subscriber The organization purchasing and/or using Ethernet Services. [2]
S-Tag Service VLAN Tag. IEEE Std
802.1ad
[5]
S-VLAN ID The 12 bit VLAN ID field in the S-Tag of an ENNI Frame [8]
Tag An optional field in a frame header. In this document it is the 4- IEEE Std
byte field that, when present in an Ethernet frame, appears 802.1ad
immediately after the Source Address, or another tag in an [5]
Ethernet frame header and which consists of the 2-byte Tag
Protocol Identification Field (TPID) which indicates S-Tag or C-
Tag, and the 2-byte Tag Control Information field (TCI) which
contains the 3-bit Priority Code Point, and the 12-bit VLAN ID
field
UNI MTU Size The maximum sized Service Frame allowed at the UNI. [2]

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

Term Abbrev. Definition Ref


Unicast Service [2]
A Service Frame that has a unicast destination MAC address.
Frame
User Network The physical demarcation point between the responsibility of the [2]
UNI
Interface Service Provider and the responsibility of the Subscriber.
Virtual LAN IEEE
VLAN 802.3-
2008 [3]
Table 1: Terminology and Definitions Table

3. Scope
This document defines a new Ethernet Service Type, Ethernet Access, and corresponding OVC-
based Ethernet services between a UNI and an ENNI. These services are typically in the form of
a Ethernet access service offered by an Ethernet Access Provider. The Ethernet Access Provider
operates the access network to reach the Service Providers out-of-franchise Subscriber locations
as part of providing an end to end service to a Subscriber. Figure 1 describes the scope of the
service definitions included in this document.

Figure 1. Scope of the E-Access Services Definition.


This document defines Ethernet Access services using point-to-point OVCs consisting of one
UNI and one ENNI. These services may be augmented in the future by other Ethernet Access
services.

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 [4]. All key words use upper case, bold
text.

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

Items that are REQUIRED (contain the words MUST or MUST NOT) will be labeled as [Rx]
for required. Items that are RECOMMENDED (contain the words SHOULD or SHOULD
NOT) will be labeled as [Dx] for desirable. Items that are OPTIONAL (contain the words MAY
or OPTIONAL) will be labeled as [Ox] for optional.
5. Ethernet Service Definition Framework (Normative)
The Ethernet Service Definition Framework defined in MEF 6.1 [1] provides a model for
specifying Ethernet services. Each Ethernet Service type has a set of Ethernet service attributes
that define the service characteristics. These Ethernet Service Attributes in turn have a set of
parameters associated with them that provide various options for the different service attributes.
Refer to Figure 2.

Figure 2: Ethernet Service Definition Framework


MEF 6.1 defines three generic Ethernet Service type constructs based on EVCs, namely,
Ethernet Line (E-Line) Service type, Ethernet LAN (E-LAN) Service type and Ethernet Tree (E-
Tree) Service type, and their associated service attributes and parameters. The key differentiator
is the type of connectivity provided, as indicated by the EVC Type service attribute. MEF 6.1
provides constraints to the UNI and EVC service attributes and parameters specific to each of
these EVC-based service types.
This document defines a new Ethernet Service type called Ethernet Access (E-Access) and its
associated service attributes and parameters. Ethernet services defined using this general
Ethernet Access service type use an OVC that associates at least one UNI OVC End Point and
one ENNI OVC End Point. This first specification under the Ethernet Access Service Type
defines services that use a point-to-point OVC which has one OVC End Point at an ENNI and
one at a UNI. The service attributes and parameters for the UNI, OVC per UNI, OVC End Point
per ENNI, OVC, and ENNI are normatively defined in Section 6.
Two Ethernet Services are defined in this document for the E-Access Service type. These are
differentiated by the ability to support one or more service instances at the UNI. Services where
Service Frames at the UNI can be mapped to only a single OVC End Point are referred to as
Private or Port-based services. Services where Service Frames at the UNI can be mapped to
one member of a set of OVC End Points, or to one member of a set of OVC End Points and
EVCs, are referred to as Virtual Private or VLAN-based services. This relationship is shown
in Table 2 below.

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

Service Type Port-Based VLAN-Based

E-Access
(point-to-point Access Ethernet Private Line Access Ethernet Virtual Private Line
OVC) (Access EPL) (Access EVPL)
Table 2: Services defined based on E-Access Service type

5.1 Ethernet Access (E-Access) Service Type


Any Ethernet service that is based on a Operator Virtual Connection (OVC) that associates at
least one OVC End Point at a UNI, and at least one OVC End Point at an ENNI, is designated as
an Ethernet Access (E-Access) Service type. The Ethernet services defined in the scope of this
specification use a point-to-point OVC which associates one OVC End Point at an ENNI and one
at a UNI.
A point-to-point example of an E-Access Service type is illustrated in Figure 3. An E-Access
Service type can be used to create a broad range of Ethernet access services.
Point -to-Point OVC

UNI ENNI
Metro Ethernet
Network

Figure 3: A point-to-point example of an E-Access Service type using OVC with UNI and ENNI
OVC End Points
1. The services attributes used in Section 6 to specify the parameters of E-Access
services are taken from the noted sections of the following specifications: UNI
Service Attributes (defined in MEF 10.2 [2], Section 7)
2. OVC per UNI Service Attributes (defined in MEF 26 [8] Section 7.5)
3. OVC End Point per ENNI Service Attributes (defined in MEF 26 [8] Section 7.3)
4. OVC Service Attributes (defined in MEF 26 [8], Section 7.2)
5. ENNI Service Attributes (defined in MEF 26 [8], Section 7.1)
In each of these tables, if that service description makes no restrictions on an attribute it is noted
in the table cell.
An example of how E-Access Service types may be used as a component of a Service Providers
end-to-end service is shown in Table 3 below. The Access Services defined in this document
allow use of S-VLAN multiplexing of multiple E-Access Services at one ENNI, permitting
efficient aggregation while maintaining CE-VLAN ID preservation for all Subscribers traffic.

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

Supported by Access
Providers Wholesale
Service:
Service Provider Access-EPL Access-EVPL
Offers MEF 6.1 (Port-Based) (VLAN-
Service: Based)
EPL X
based based
VLAN- Port-

EP-LAN X

EVPL X
EVP-LAN X

Table 3. Example of typical pairings of Service Providers end to end services with supporting
services from an Access Provider.
Use Cases illustrating more specifically how Access EPL and Access EVPL Services can be
combined to form end to end services are shown in Appendix B.

6. Service Definitions (Normative)


An Ethernet service is defined by specifying service attribute parameter values for a given
Ethernet Access Service type. This section defines the required service attributes and related
parameter values for the Ethernet services specified in this Technical Specification. If any of the
Ethernet services in this section are offered, the normative text for each service attribute is
applied. Note that other variations of these Ethernet services are also possible, but beyond the
scope of this document.

6.1 Access Ethernet Private Line Service (Access EPL)


An Access Ethernet Private Line (Access EPL) service is specified using an E-Access Service
type.

[R1] An Access EPL service MUST use a Point-to-Point OVC that associates one
OVC End Point at a UNI and one OVC End Point at an ENNI
This service can provide a high degree of transparency for Frames between the EIs it
interconnects such that the Frames header and payload upon ingress at the UNI is delivered
unchanged to the ENNI, with the addition of an S-VLAN tag. The Frames header and payload
upon ingress at the ENNI is delivered unchanged to the UNI except for the removal of the S-
VLAN tag. (These actions presume that the FCS for the frame is recalculated when an S-VLAN

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

tag is inserted or removed.) Figure 4 below shows the basic structure and scope of Access EPL
service.

Figure 4: Overview of Access EPL Service


A Service Provider can use the Access EPL service from an Access Provider to deliver the port-
based Ethernet services defined in MEF 6.1 and supported by the ENNI defined in MEF 26:
Ethernet Private Line (EPL), and Ethernet Private LAN (EP-LAN). Ethernet Private Tree (EP-
Tree) services are not supported by MEF 26 (Phase 1), so the suitability of Access EPL to
support EP-Tree is outside the scope of this document.
Because of the high degree of transparency of this service, there is no need for coordination
between the Subscriber and Service Provider on a detailed CE-VLAN ID/EVC Map for each
UNI because all Service Frames at the UNI are mapped to a single OVC End Point, as indicated
by the OVC End Point Map attribute in Table 5 below. However, the Service Provider and
Access Provider need to coordinate the value of the S-VLAN ID at the ENNI and other service
attributes as specified below.
The CE is expected to shape traffic to the Ingress Bandwidth Profile of the service such that all
of its traffic, including certain L2CPs that require delivery for proper operation, is accepted by
the service.
6.1.1 UNI Service Attributes and Parameter Values
Table 4 provides the UNI service attributes, parameters, and values for the Access EPL service.
Note that there are some differences between UNI attributes for OVC-based services and those
for EVC-based services. Some attributes, such as Service Multiplexing, Bundling, and All-to-
One-Bundling, are not relevant to the agreement between the Access Provider and the Service
Provider, and therefore are omitted from this table.

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

[R2] An Access EPL Service instance MUST assign UNI Service Attributes and
values according to Table 4.

UNI Service Attribute Service Attribute Parameters and Values


UNI Identifier No additional constraints from definition in MEF 10.2 [2]
Physical Medium No additional constraints from definition in MEF 10.2 [2]
Speed No additional constraints from definition in MEF 10.2 [2]
Mode No additional constraints from definition in MEF 10.2 [2]
MAC Layer No additional constraints from definition in MEF 10.2 [2]
UNI MTU Size No additional constraints from definition in MEF 10.2 [2]
CE-VLAN ID for untagged MUST be a value from 1 4094.
and priority tagged Frames
Maximum number of OVCs
MUST be 1 [new attribute defined below in Section 6.1.1.1]
per UNI
Ingress Bandwidth Profile Per
MUST NOT specify 1
UNI
Egress Bandwidth Profile Per
MUST NOT specify
UNI
Table 4: UNI service attributes and parameters for the Access EPL service

6.1.1.1 Maximum Number of OVCs per UNI Attribute


This attribute is the maximum number of OVC End Points that can be at the UNI. This is a new
UNI attribute, (see Table 4 above and Table 9) modeled after the similar Maximum Number of
EVCs per UNI, and is used, for example, to differentiate between the Access EPL service where
this must = 1, and the Access EVPL service where this can be 1.
6.1.2 OVC per UNI Service Attributes and Parameter Values
There are service attributes for each instance of an OVC at a specific UNI. Since an OVC can
only associate one OVC End Point that is at a UNI (see MEF 26 [8]), these service attributes can
be equivalently viewed as OVC End Point per UNI service attributes. These service attributes are
presented in Table 5. (Editors Note: Values taken from the MEF 6.1 table for EPL EVC per
UNI were used as starting point)

[R3] An Access EPL Service instance MUST assign OVC per UNI Service
Attributes and values according to Table 5.

1
See Ingress Bandwidth Profile per OVC End Point at a UNI service attribute in Table 5.

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

OVC per UNI Service Possible Values


Attribute
UNI OVC Identifier No additional constraints from definition in MEF 26 [8].
OVC End Point Map MUST contain all CE-VLAN ID values {1, 2, 4095} mapped to a
single OVC End Point.
Class of Service Identifier for The CoS Identifier for Service Frames MUST be the OVC End Point;
Service Frames that OVC MUST have a single CoS Name.
Ingress Bandwidth Profile Per Required, MUST specify <CIR, CBS, EIR, EBS, CM, CF>; MUST
OVC End Point at a UNI allow configuration to support CIR values 2 up to 70% of the UNI speed,
in the following increments:
1 10 Mb/s, increments of 1 Mb/s
10 100 Mb/s, increments of 10 Mb/s
100 1000 Mb/s, increments of 100 Mb/s
1 10 Gb/s, increments of 1 Gb/s.
These required CIR increments are subject to the limit imposed by the
UNI speed. For example, a 100 Mb/s UNI MUST support CIR values of
1 10 Mb/s in increments of 1 Mb/s, and 10 70 Mb/s in increments of
10 Mb/s.
MAY support other values of CIR.
MUST allow configuration of EIR = 0, EBS = 0, CF = 0, Color Mode =
color blind
MAY support other values of EIR, EBS, CF, and Color Mode.
MUST have CBS >= 12176 bytes
MUST NOT be combined with any other type of ingress bandwidth
profile.
When the ingress Bandwidth Profile of the OVC End Point at the UNI
has CIR > 0 and EIR = 0, each egress ENNI Frame MUST be marked
Green via the S-Tag as per [MEF 23].
Ingress Bandwidth Profile Per Not used.
Class of Service Identifier at a
UNI
Egress Bandwidth Profile Per MUST NOT specify
OVC End Point at a UNI
Egress Bandwidth Profile Per MUST NOT specify
Class of Service Identifier at a
UNI
Table 5: OVC per UNI Service Attributes for Access EPL service.
6.1.3 OVC Service Attributes
Table 6 provides the OVC service attributes, parameters, and values for the Access EPL service.

[R4] An Access EPL Service instance MUST assign OVC Service Attributes and
values according to Table 6.

2
MEF Bandwidth Profile traffic parameters such as CIR count only Service Frame bits, not interframe gap or
preamble bits. Setting CIR above 76% of the physical layer speed of the EI has consequences, which are discussed
in more detail in Appendix A.

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

OVC Service Attribute Possible Values


OVC Identifier No additional constraints from definition in MEF 26 [8]
OVC Type MUST be Point-to-Point
OVC End Point List Exactly 2, one OVC End Point at the UNI, one at the ENNI.
Maximum Number of UNI MUST be 1
OVC End Points
Maximum Number ENNI MUST be 1
OVC End Points
OVC Maximum MUST be an integer number of bytes > or = to 1526; see Section 7.2.9 in
Transmission Unit Size [8].
CE-VLAN ID Preservation MUST be Yes
CE-VLAN CoS ID Value MUST be Yes
Preservation
S-VLAN ID Preservation N/A as only one ENNI in the service instance
S-VLAN CoS ID Value N/A as only one ENNI in the service instance
Preservation
Color Forwarding SHOULD be yes. When Ingress BWP at UNI has EIR = 0 frames
egressing at ENNI MUST be marked green.
Service Level MUST list values for each of the following attributes from MEF 26.0.3
Specification [17]: { One-way Frame Delay, One-way Frame Delay Range, One-way
Mean Frame Delay, Inter Frame Delay Variation, One-way Frame Loss
Ratio, One-way Availability, One-way High Loss Intervals, One-way
Consecutive High Loss Intervals} where Not Specified (N/S) is an
acceptable value.
MAY specify additional attributes and values.
Unicast Frame Delivery MUST Deliver Unconditionally
Multicast Frame Delivery MUST Deliver Unconditionally
Broadcast Frame Delivery MUST Deliver Unconditionally
Table 6: OVC service attributes and parameters for the Access EPL service
6.1.4 OVC End Point per ENNI Service Attributes
The OVC End Point per ENNI attribute values associated with the Access EPL service are
shown in Table 7.

[R5] An Access EPL Service instance MUST assign OVC End Point at an ENNI
Service Attributes and values according to Table 7.

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

OVC End Point per ENNI Possible Values


Service Attribute Name
OVC End Point Identifier No additional constraints from definition in MEF 26 [8]
Class of Service Identifier for The CoS Identifier for ENNI Frames MUST be the OVC End Point to
ENNI Frames which the ENNI Frame is mapped; that OVC MUST have a single CoS
Name which is associated with the entire set of S-Tag PCP values {0
7}.
Ingress Bandwidth Profile Per Required, MUST specify <CIR, CBS, EIR, EBS, CM, CF>; MUST
OVC End Point 3 allow configuration to support CIR2 values up to 70% of the ENNI
speed, in the following increments:
1 10 Mb/s, increments of 1 Mb/s
10 100 Mb/s, increments of 10 Mb/s
100 1000 Mb/s, increments of 100 Mb/s
1 10 Gb/s, increments of 1 Gb/s.
These required CIR increments are subject to the limit imposed by the
ENNI speed. For example, a 100 Mb/s ENNI MUST support CIR values
of 1 10 Mb/s in increments of 1 Mb/s, and 10 70 Mb/s in increments
of 10 Mb/s.
MAY support other values of CIR.
MUST allow configuration of EIR = 0, EBS = 0, CF = 0, Color Mode =
color aware
MAY support other values of EIR, EBS, CF, and Color Mode.
MUST have CBS >= 12176 bytes
MUST NOT be combined with any other type of ingress bandwidth
profile.

Ingress Bandwidth Profile Per Not used.


ENNI Class of Service
Identifier
Egress Bandwidth Profile Per MUST NOT specify.
End Point
Egress Bandwidth Profile Per MUST NOT specify.
ENNI Class of Service
Identifier
Table 7: ENNI OVC End Point Service Attributes for the Access EPL service.

6.1.5 ENNI Service Attributes


The following table specifies the ENNI Service Attributes for the Access EPL service. The
Maximum Number of OVC End Points per OVC is required to be exactly 1 for Access EPL as
this service does not support hairpin switching of traffic (see definition and discussion of
hairpin switching in Section 7.2.2 of MEF 26 [8]) by the Operator providing the Access EPL
service.

3
The ingress CIR for an OVC at the ENNI should be greater than the corresponding ingress CIR at the UNI due to
the presence of the added SVLAN tag (4 bytes) at the ENNI. As an example, if the average frame size was 200
bytes, the CIR should be increased by 2%.

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

[R6] An Access EPL Service instance MUST assign ENNI Service Attributes and
values according to Table 8.

ENNI Service Attribute Possible Values


Name
Operator ENNI Identifier No additional constraints from definition in MEF 26 [8]
Physical Layer No additional constraints from definition in MEF 26 [8]
Frame Format No additional constraints from definition in MEF 26 [8]
Number of Links No additional constraints from definition in MEF 26 [8]
Protection Mechanism No additional constraints from definition in MEF 26 [8]
ENNI Maximum No additional constraints from definition in MEF 26 [8]
Transmission Unit Size
End Point Map Each S-VLAN ID value associated with an instance of
Access EPL Service MUST map to a distinct End Point,
of Type = OVC
Maximum Number of No additional constraints from definition in MEF 26 [8]
OVCs
Maximum Number of No additional constraints from definition in MEF 26 [8]
OVC End Points per
OVC
Table 8: ENNI Service Attributes for Access EPL Service.
Note that the combination of the End Point Map attribute constraint above and the requirement
that the Access EPL OVC is point to point only, implies a single Subscriber UNI.

6.2 Access Ethernet Virtual Private Line (Access EVPL) Service Definition
(Normative)
An Access Ethernet Virtual Private Line (Access EVPL) service is specified using an E-Access
Service type.

[R7] An Access EVPL service MUST use a Point-to-Point OVC that associates a
UNI OVC End Point and an ENNI OVC End Point.
An Access EVPL can be used to create services similar to the Ethernet Access Private Line
(Access EPL) with some notable exceptions. First, with Access EVPL a UNI can support
multiple service instances, including a mix of Access and EVC Services (see Figure 5, UNIs A &
B). Such configurations are not possible if Access EPL is offered at the UNI. Second, an Access
EVPL need not provide as much transparency of Service Frames as with an Access EPL, as the
OVC End Point map determines which CE-VLANs are mapped to OVCs or dropped. Because
multiple instances of EVCs and Access EVPLs are permitted, not all ingress Service Frames at
the UNI need be sent to the same destination.
This service can provide a high degree of transparency for Frames between the EIs it
interconnects such that the Frames header and payload upon ingress at the UNI is delivered

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

unchanged to the ENNI, with the addition of an S-VLAN tag. The Frames header and payload
upon ingress at the ENNI is delivered unchanged to the UNI except for the removal of the S-
VLAN tag. These actions presume that the FCS for the frame is recalculated when an S-VLAN
tag is inserted or removed. Figure 5 below shows the basic structure and scope of Access EVPL
service.

Figure 5: Overview of Access EVPL Service


With Access EVPL, the UNI can support multiple service instances, as shown for UNI A in
Figure 5, where CE-VLAN ID 1 is mapped to the EVC that associates UNI A and UNI C. CE-
VLAN IDs 3, 4, 5 are mapped to OVC End Point c, and associated via the Access EVPL with
OVC End Point d at the ENNI. UNI B illustrates two instances of Access EVPL connecting it to
the ENNI. A Service Provider can use the Access EVPL service from an Access Provider to
deliver the two VLAN-based Ethernet services defined in MEF 6.1 and supported by the ENNI
defined in MEF 26: Ethernet Virtual Private Line (EVPL), and Ethernet Virtual Private LAN
(EVP-LAN). Ethernet Virtual Private Tree (EVP-Tree) services are not supported by MEF 26
(Phase 1), so they are not intended for support by Access EVPL in this document.
The CE is expected to shape traffic to the Ingress Bandwidth Profile to minimize frame loss by
the service.
The Subscriber and Service Provider coordinate an OVC End Point Map for each OVC to
specify what Service Frames at the UNI are mapped to each OVC. In addition, the Service
Provider and Access Provider must coordinate the value of the S-VLAN ID value that maps to
each OVC End Point at the ENNI, and other service attributes as specified below.
6.2.1 Maximum CE-VLAN IDs per OVC Attribute
For the Access EVPL Service, a new attribute is defined which indicates how many CE-VLAN
IDs can be mapped into a single OVC at the UNI. By default the value of 1 MUST be supported

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

by any OVC End Point Map, but a value N > 1 indicates that up to N CE-VLAN IDs can be
mapped to an OVC (see Table 9 below).
6.2.2 UNI Service Attributes
Table 9 provides the UNI service attributes, parameters, and values for the Access EVPL
Service. Note that there are some differences between UNI attributes for OVC-based services
and those for EVC-based services. Some attributes, such as Service Multiplexing, Bundling, and
All-to-One-Bundling, are not relevant to the agreement between the Access Provider and the
Service Provider, and therefore are omitted from this table.

[R8] An Access EVPL Service instance MUST assign UNI Service Attributes and
values according to Table 9.

UNI Service Attribute Service Attribute Parameters and Values


UNI Identifier No additional constraints from definition in MEF 10.2 [2]
Physical Medium No additional constraints from definition in MEF 10.2 [2]
Speed No additional constraints from definition in MEF 10.2 [2]
Mode No additional constraints from definition in MEF 10.2 [2]
MAC Layer No additional constraints from definition in MEF 10.2 [2]
UNI MTU Size No additional constraints from definition in MEF 10.2 [2]
CE-VLAN ID for untagged MUST be specified if untagged / priority tagged frames are to
and priority tagged Frames be supported, and that CE-VLAN ID must be included in the
OVC Endpoint Map in Table 10, specifying what OVC these
frames are mapped to.
Maximum number of OVCs
MUST be 1 [attribute defined in Section 6.1.1.1]
per UNI
Maximum number of CE- The OVC Endpoint Map MUST support a value = 1
VLAN IDs per OVC The OVC Endpoint Map SHOULD support a value > 1.
Ingress Bandwidth Profile Per
MUST NOT specify 4
UNI
Egress Bandwidth Profile Per
MUST NOT specify
UNI
Table 9: UNI service attributes and parameters for the Access EVPL service
6.2.3 OVC per UNI Service Attributes and Parameter Values
There are service attributes for each instance of an OVC at a specific UNI. Since an OVC can
only associate one OVC End Point that is at a UNI (see MEF 26 [8]), these service attributes can
be equivalently viewed as OVC End Point per UNI service attributes. These service attributes are
presented in Table 10. (Editors Note: Values taken from the MEF 6.1 table for EVPL Service,
EVC per UNI were used as starting point)

4
See Ingress Bandwidth Profile per OVC End Point at a UNI service attribute in Table 10.

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

[R9] An Access EVPL Service instance MUST assign OVC per UNI Service
Attributes and values according to Table 10.
OVC per UNI Service Possible Values
Attribute
UNI OVC Identifier No additional constraints from definition in MEF 26 [8].
OVC End Point Map MUST specify mapping table of CE-VLAN ID to OVC End Point.
MUST NOT contain all CE-VLAN ID values mapped to a single OVC
End Point. (This configuration is reserved for the Access EPL service)
Class of Service Identifier for The CoS Identifier for Service Frames MUST be the OVC End Point to
Service Frames which the Service Frame is mapped; that OVC MUST have a single CoS
Name.
Ingress Bandwidth Profile Per Required, MUST specify <CIR, CBS, EIR, EBS, CM, CF>; MUST
OVC End Point at a UNI allow configuration to support CIR values up to 70% of the UNI speed 5,
in the following increments:
1 10 Mb/s, increments of 1 Mb/s
10 100 Mb/s, increments of 10 Mb/s
100 1000 Mb/s, increments of 100 Mb/s
1 10 Gb/s, increments of 1 Gb/s.
These required CIR increments are subject to the limit imposed by the
UNI speed. For example, a 100 Mb/s UNI MUST support CIR values of
1 10 Mb/s in increments of 1 Mb/s, and 10 70 Mb/s in increments of
10 Mb/s.
MAY support other values of CIR.
MUST allow configuration of EIR = 0, EBS = 0, CF = 0, Color Mode =
color blind
MAY support other values of EIR, EBS, CF, and Color Mode.
MUST have CBS >= 12176 bytes
MUST NOT be combined with any other type of ingress bandwidth
profile.
When the ingress Bandwidth Profile of the OVC End Point at the UNI
has CIR > 0 and EIR = 0, each egress ENNI Frame MUST be marked
Green via the S-Tag as per [MEF 23].
Ingress Bandwidth Profile Per Not used.
Class of Service Identifier at a
UNI
Egress Bandwidth Profile Per MUST NOT specify
OVC End Point at a UNI
Egress Bandwidth Profile Per MUST NOT specify
Class of Service Identifier at a
UNI
Table 10: OVC per UNI Service Attributes for Access EVPL service.
6.2.4 OVC Service Attributes
Table 11 provides the OVC service attributes, parameters, and values for the Access EVPL
service.
5
MEF Bandwidth Profile traffic parameters such as CIR count only Service Frame bits, not interframe gap or
preamble bits. Setting CIR above 76% of the physical layer speed of the EI has consequences, which are discussed
in more detail in Appendix A.

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

[R10] An Access EVPL Service instance MUST assign OVC Service Attributes and
values according to Table 11.

OVC Service Attribute Possible Values


OVC Identifier No additional constraints from definition in MEF 26 [8]
OVC Type MUST be Point-to-Point
OVC End Point List A list of OVC End Point Identifiers, exactly 2, one OVC End Point
at the UNI, one at the ENNI.
Maximum Number of UNI OVC MUST be 1
End Points
Maximum Number ENNI OVC MUST be 1
End Points
OVC Maximum Transmission MUST be an integer number of bytes > or = to 1526; see Section
Unit Size 7.2.9 in [8].
CE-VLAN ID Preservation MUST be Yes
CE-VLAN CoS ID Value MUST be Yes
Preservation
S-VLAN ID Preservation N/A as only one ENNI in the service instance
S-VLAN CoS ID Value N/A as only one ENNI in the service instance
Preservation
Color Forwarding SHOULD be yes. When Ingress BWP at UNI has EIR = 0 frames
egressing at ENNI MUST be marked green.
Service Level Specification MUST list values for each of the following attributes from MEF
26.0.3 [17]: { One-way Frame Delay, One-way Frame Delay Range,
One-way Mean Frame Delay, Inter Frame Delay Variation, One-
way Frame Loss Ratio, One-way Availability, One-way High Loss
Intervals, One-way Consecutive High Loss Intervals} where Not
Specified (N/S) is an acceptable value.
MAY specify additional attributes and values.
Unicast Frame Delivery Deliver Unconditionally or Deliver Conditionally. If Delivered
Conditionally, MUST specify the delivery criteria.
Multicast Frame Delivery Deliver Unconditionally or Deliver Conditionally. If Delivered
Conditionally, MUST specify the delivery criteria.
Broadcast Frame Delivery Deliver Unconditionally or Deliver Conditionally. If Delivered
Conditionally, MUST specify the delivery criteria.
Table 11: OVC service attributes and parameters for the Access EVPL service
6.2.5 OVC End Point per ENNI Service Attributes
The OVC End Point per ENNI attribute values associated with the Access EVPL service are
shown in Table 12.

[R11] An Access EVPL Service instance MUST assign OVC End Point at an ENNI
Service Attributes and values according to Table 12.

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

OVC End Point per ENNI Possible Values


Service Attribute Name
OVC End Point Identifier No additional constraints from definition in MEF 26 [8]
Class of Service Identifier for The CoS Identifier for ENNI Frames MUST be the OVC End Point to
ENNI Frames which the ENNI Frame is mapped; that OVC MUST have a single CoS
Name which is associated with the entire set of S-Tag PCP values {0
7}.
Ingress Bandwidth Profile Per Required, MUST specify <CIR, CBS, EIR, EBS, CM, CF>; MUST
OVC End Point 6 allow configuration to support CIR values up to 70% of the ENNI
speed 7, in the following increments:
1 10 Mb/s, increments of 1 Mb/s
10 100 Mb/s, increments of 10 Mb/s
100 1000 Mb/s, increments of 100 Mb/s
1 10 Gb/s, increments of 1 Gb/s.
These required CIR increments are subject to the limit imposed by the
ENNI speed. For example, a 100 Mb/s ENNI MUST support CIR
values of 1 10 Mb/s in increments of 1 Mb/s, and 10 70 Mb/s in
increments of 10 Mb/s.
MAY support other values of CIR.
MUST allow configuration of EIR = 0, EBS = 0, CF = 0, Color Mode =
color aware
MAY support other values of EIR, EBS, CF, and Color Mode.
MUST have CBS >= 12176 bytes
MUST NOT be combined with any other type of ingress bandwidth
profile.

Ingress Bandwidth Profile Per Not used.


ENNI Class of Service
Identifier
Egress Bandwidth Profile Per MUST NOT specify.
End Point

Egress Bandwidth Profile Per MUST NOT specify.


ENNI Class of Service
Identifier
Table 12: ENNI OVC End Point Service Attributes for Access EVPL Service.

6.2.6 ENNI Service Attributes


The following table specifies the ENNI Service Attributes for the Access EVPL service. The
Maximum Number of OVC End Points per OVC is required to be exactly 1 for Access EVPL as
this service does not support hairpin switching of traffic (see definition and discussion of
6
The ingress CIR for an OVC at the ENNI should be greater than the corresponding ingress CIR at the UNI due to
the presence of the added SVLAN tag (4 bytes) at the ENNI. As an example, if the average frame size was 200
bytes, the CIR should be increased by 2%.
7
MEF Bandwidth Profile traffic parameters such as CIR count only Service Frame bits, not interframe gap or
preamble bits. Setting CIR above 76% of the physical layer speed of the EI has consequences, which are discussed
in more detail in Appendix A.

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

hairpin switching in Section 7.2.2 of MEF 26 [8]) by the Operator providing the Access EVPL
service.

[R12] An Access EVPL Service instance MUST assign ENNI Service Attributes and
values according to Table 13.

ENNI Service Attribute Possible Values


Name
Operator ENNI Identifier No additional constraints from definition in MEF 26 [8]
Physical Layer No additional constraints from definition in MEF 26 [8]
Frame Format No additional constraints from definition in MEF 26 [8]
Number of Links No additional constraints from definition in MEF 26 [8]
Protection Mechanism No additional constraints from definition in MEF 26 [8]
ENNI Maximum No additional constraints from definition in MEF 26 [8]
Transmission Unit Size
End Point Map Each S-VLAN ID value associated with an instance of
Access EVPL Service MUST map to a distinct End Point,
of Type = OVC
Maximum Number of No additional constraints from definition in MEF 26 [8]
OVCs
Maximum Number of No additional constraints from definition in MEF 26 [8]
OVC End Points per
OVC
Table 13: ENNI Service Attributes for Access EVPL Service.
Note that the combination of the End Point Map attribute constraint above and the requirement
that the Access EVPL OVC is point to point only, implies each S-VLAN ID corresponds to a
single Subscriber UNI.

6.3 Service OAM Fault Management (SOAM-FM) Requirements for Access EPL
and Access EVPL Service
To enable uniform behavior of SOAM-FM for the Access EPL and Access EVPL Services
across all Access Providers, the appropriate requirements as detailed in the SOAM FM IA (MEF
30) [10] must be followed. Specifically:

[R13] The Access EPL and Access EVPL Services MUST be configurable to tunnel
all SOAM frames at the default Test and Subscriber MEG levels as defined in
the SOAM FM IA (MEF 30) [10] document, section 7.1.
If the Access Provider uses SOAM-FM in their network, they have available for their use the
Operator, UNI, and ENNI MEG levels as specified in the SOAM-FM IA [10], section 7.1.

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

6.4 L2CP Requirements For Access EPL And Access EVPL Service
Processing of L2CP frames is for further study. Until defined in a future revision of this
document, processing of L2CP frames is agreed to by the two parties involved in the Access
Service.

7. References
[1] MEF Technical Specification MEF 6.1, Ethernet Services Definitions - Phase 2, April,
2008.

[2] MEF Technical Specification, MEF 10.2, Ethernet Services Attributes - Phase 2,
October 2009.

[3] IEEE 802.3-2005, Part 3: Carrier sense multiple access with collision detection
(CSMA/CD) access method and physical layer specifications

[4] RFC 2119, Key words for use in RFCs to Indicate Requirement Levels, S. Bradner

[5] IEEE 802.1ad-2005, Virtual Bridged Local Area Networks Amendment 4: Provider
Bridges

[6] MEF Technical Specification MEF 4, Metro Ethernet Network Architecture Framework
- Part 1: Generic Framework, May 2004

[7] ITU-T Recommendation Y.1731, OAM functions and mechanisms for Ethernet based
networks

[8] MEF Technical Specification MEF 26, External Network to Network Interface (ENNI)
Phase 1, January 2010.

[9] MEF Technical Specification MEF 20, User Network Interface (UNI) Type 2
Implementation Agreement, July 2008.

[10] MEF Technical Specification MEF 30, Service OAM Fault Management
Implementation Agreement, January 2011.

[11] IEEE 802.1ag-2007, Virtual Bridged Local Area Networks Amendment 5: Connectivity
Fault Management.

[12] IEEE 802.1aj-2009. IEEE Standard for Local and metropolitan Area Networks Virtual
Bridged Local Area Networks Amendment 11: Two-Port Media Access Control (MAC)
Relay. - December 2009.

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

[13] IEEE P802.1AB-REV/D6.0-2009. IEEE Standard for Local and metropolitan Area
Networks - Station and Media Access Control Connectivity Discovery June 2009.

[14] IEEE P802.1X-REV/D4.5 IEEE Draft Standard for Local and metropolitan Area
Networks. Port-based Network Access Control. October 2009.

[15] MEF Technical Specification MEF 26.0.2, OVC Layer 2 Control Protocol Tunneling
Amendment to MEF 26, January 2011.

[16] MEF Technical Specification MEF 23.1, Carrier Ethernet Class of Service Phase 2,
(in progress) 2011.

[17] MEF Technical Specification MEF 26.0.3, Service Level Specification Amendment to
MEF 26, October 2011.

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

8. Appendix A: Effect of Inter-frame Overhead on CIR (Informative)


MEF Bandwidth Profile algorithms count only Service Frame bits, not interframe gap or
preamble bits. Setting CIR too close to the bit rate of the physical layer of the UNI has
consequences, which may appear only under certain traffic conditions. Figure 6 shows different
ways of counting the length of a frame:

Figure 6. Length of an Ethernet frame as measured with and without the 20 byte inter-frame
overhead.
Since Bandwidth Profile traffic parameters such as CIR do not account for interframe gap or
preamble bits that are added by the Ethernet physical layer, a policed stream of MEF Service
Frames of constant size X, will result in a stream of physical layer frames of size X+20 bytes at a
UNI. Clearly the impact of this overhead inflation varies directly with frame size, from a low
of 1.3% for a 1518 byte frame, to a maximum of 31% for a 64 byte frame. The result of this
effect is shown in Figure 7 for a 100 Mb/s interface. The resulting curve shows that as the frame
size decreases, an increasing fraction of the line rate is consumed by overhead and the maximum
bits/sec of Service Frames transmitted drops sharply as the frame size decreases below 200
bytes.
The resulting caution from these observations is that provisioning a CIR greater than 76% of a
physical interface speed, will allow the possiblility that the maximum bits/sec of Service Frames
transmitted may be considerably less than the CIR value when traffic is comprised of a high
percentage of small frame sizes.

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

Maximum MEF Service Frame Bit Rate


Achievable on 100 Mb/s Interface
100.00

90.00
Service Frame Mb/s

80.00

70.00

60.00
50 250 450 650 850 1050 1250 1450 1650 1850
Frame Size, bytes

Figure 7. Resulting Layer 1 bit rates for different MEF CIR measured as Service Frames

9. Appendix B: Use Cases (Informative)


The following are non-normative examples of how the E-Access Services defined in this
document may be used to provide MEF 6.1 UNI to UNI services. The examples are offered to
illustrate some of the applications and show a selective subset of the attributes that would be
involved.

9.1 EPL Service

The following figure shows the Subscriber and Service Provider Points of View (POV) for an
instance of EPL Service offered by the Service Provider using Access EPL Service in the Access
Provider Network.

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

Figure 8. EPL Service as implemented across two networks using Access EPL, showing the
Subscriber and Service Provider POVs.

An illustrative table below shows some of the attributes that must be specified as part of the end
to end service, color coded to show that they belong to the end to end service (red), the Access
Provider (blue), or the Service Provider (gray).

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

EPL Service Attribute Value Access EPL Value SP OVC Value


(End to End) Attribute Attribute
1 EVC Type Point to Point OVC Type Point to Point OVC Type Point to Point

2 All to One Bundling Yes N/A N/A

3 CE-VLAN ID to EVC Map All Service OVC Endpoint All CE-VLAN ID OVC Endpoint All CE-VLAN ID
Frames map to Map at UNI A values map to Map at UNI C values map to
one EVC single OVC single OVC
4 N/A N/A ENNI Endpoint OVC Endpoint ENNI Endpoint OVC Endpoint
Map E = SVLAN ID Map F = SVLAN ID
158 158
5 Ingress bandwidth profile CIR= 100 Mb/s, Ingress CIR= 100 Mb/s, Ingress CIR= 100 Mb/s,
per EVC CBS = 12K, bandwidth CBS = 12K, bandwidth CBS = 12K,
EIR, EBS=0; profile per OVC EIR, EBS=0; profile per OVC EIR, EBS=0;
CM=blind; EP at UNI A CM=blind; EP at UNI C CM=blind;
CF=0 CF=0
6 N/A N/A Ingress CIR should Ingress CIR should
bandwidth reflect S-tag bandwidth reflect S-tag
profile per OVC overhead, rest profile per OVC overhead, rest
EP at ENNI same as UNI EP at ENNI same as UNI
7 CE-VLAN ID, CoS MUST be yes CE-VLAN ID, MUST be yes CE-VLAN ID, MUST be yes
preservation CoS CoS
preservation preservation
8 CoS ID based on EVC, CoS ID based All PCP values CoS ID based All PCP values
value=M S-tag PCP =M S-tag PCP =M
9 EVC Performance MFD= 80 ms OVC MFD=10 OVC MFD = 50
for Label=M, Performance Performance
PT=Continental

Table 14. Sample attributes for an EPL service.


Row 1 shows how the EVC and OVC types all line up as point to point.
Row 2 shows the All to One bundling EVC attribute is Yes.
Row 3 illustrates the CE-VLAN ID to EVC map and the OVC Endpoint Maps with all CE-
VLANs mapped to one OVC or EVC.
Row 4 illustrates that the S-VLAN ID value for the OVC must agree for both networks in the
ENNI endpoint maps.
Row 5 shows how the ingress bandwidth profile for the EVC is realized in the two OVCs UNI
endpoints.
Row 6 shows that the ingress bandwidth profiles at the ENNI should be the same except
reflecting a slight CIR increase due to the per-frame S-tag overhead.
Row 7 shows that CE-VLAN and CoS ID Value preservation apply end to end.
Row 8 states the CoS ID for this case is the EVC, with a CoS Label of M level; in the
subtending OVCs, this is accomplished by specifying that all PCP values are mapped to the M
Class of Service.

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

Row 9 illustrates that the EVC Mean Frame Delay (MFD) performance for CoS Label = M, and
the Continental Performance Tier is 80 ms according to the MEF 23.1 [16]. The individual
OVCs have adequate performance to meet the end to end goal.

9.2 EP-LAN Service

The following figure shows the Subscriber and Service Provider Points of View (POV) for an
instance of EP-LAN Service offered by the Service Provider using Access EPL Service in the
Access Provider Network.

Figure 9. EP-LAN Service as implemented across two networks using Access EPL, showing the
Subscriber and Service Provider Points of View.

An illustrative table below shows some of the attributes that must be specified as part of the end
to end service, color coded to show that they belong to the end to end service (red), the Access
Provider (blue), or the Service Provider (gray).

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

EP-LAN Service Value Access EPL Value SP OVC Value


Attribute (End to Attribute Attribute
End)
1 EVC Type Multipoint to OVC Type Point to Point OVC Type Multipoint to
Multipoint Multipoint
2 All to One Bundling Yes N/A N/A

3 CE-VLAN ID to EVC All Service OVC Endpoint All CE-VLAN OVC Endpoint All CE-VLAN
Map Frames map to Map at UNI A ID values map Map at UNIs C ID values map
one EVC to single OVC &D to single OVC

4 N/A N/A ENNI Endpoint OVC Endpoint ENNI Endpoint OVC Endpoint
Map E = SVLAN Map F = SVLAN
ID 158 ID 158
5 Ingress bandwidth CIR= 100 Mb/s, Ingress CIR= 100 Ingress CIR= 100
profile per EVC CBS = 12K, EIR, bandwidth profile Mb/s, CBS = bandwidth Mb/s, CBS =
EBS=0; per OVC EP at 12K, EIR, profile per 12K, EIR,
CM=blind; UNI A EBS=0; OVC EP at EBS=0;
CM=blind; UNIs C & D CM=blind;
CF=0 CF=0
6 N/A N/A Ingress CIR should Ingress CIR should
bandwidth profile reflect S-tag bandwidth reflect S-tag
per OVC EP at overhead, rest profile per overhead, rest
ENNI same as UNI OVC EP at same as UNI
ENNI
7 CE-VLAN ID, CoS MUST be yes CE-VLAN ID, MUST be yes CE-VLAN ID, MUST be yes
preservation CoS preservation CoS
preservation
8 CoS ID based on EVC, CoS ID based S- All PCP values CoS ID based All PCP values
value=M tag PCP =M S-tag PCP =M
9 EVC Performance MFD= 80 ms for OVC MFD=10 OVC MFD = 50
Label=M, Performance S= {all ordered Performance S= {all ordered
PT=Continental, OVC EP pairs OVC EP pairs
S= {all ordered per OVC} per OVC}
UNI pairs}

Table 15. Sample attributes for an EP-LAN service.


Row 1 shows how the EVC type of Multipoint to Multipoint can be constructed using the
Service Providers MP2MP OVC and the Access Providers point to point OVC.
Rows 2-9 are the same as the previous example.

9.3 EP-LAN Service with Hairpin Switching by Service Provider


The following figure illustrates an EP-LAN case with two UNIs in the Access Provider network,
which can be connected via hairpin switching from the Service Provider B. Note that two S-
VLAN IDs will be needed at the ENNI, one for each OVC End Point (and are indicated in Row 4
of Table 15). For a discussion of hairpin switching, please see MEF 26, Section 7.2.2.

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

Figure 10. EP-LAN example illustrating a Service Provider using hairpin switching between UNI A
& B.

The following table shows what attribute is different in the EP-LAN case with hairpin switching
show above:

EP-LAN Service Value Access EPL Value SP OVC Value


Attribute (End to Attribute Attribute
End)
4 N/A N/A ENNI Endpoint OVC Endpoint ENNI Endpoint OVC Endpoint
Map E = SVLAN Map F = SVLAN ID
ID 158 158
OVC Endpoint OVC Endpoint
G = SVLAN H = SVLAN ID
ID 455 455

Table 16. Change in EP-LAN Attributes in hairpin switching example.

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

9.4 EVPL Service

The following figure shows the Subscriber and Service Provider Points of View (POV) for two
instances of EVPL Service offered by the Service Provider using Access EVPL Service in the
Access Provider Network.

Figure 11. EVPL Service as implemented across two networks using Access EVPL, showing the
Subscriber and Service Provider POVs.

An illustrative table below shows some of the attributes that must be specified as part of the end
to end EVPL service, color coded to show that they belong to the end to end service (red), the
Access Provider (blue), or the Service Provider (gray).

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

EVPL Service Value Access Value SP OVC Value


Attribute (End to EVPL Attribute
End) Attribute
1 EVC Type Point to Point OVC Type Point to Point OVC Type Point to Point

2 All to One Bundling No N/A N/A

3 CE-VLAN ID to EVC Specifies what CE- OVC Endpoint OVC Endpoint OVC Endpoint OVC Endpoint
Map VLAN ID maps to Map at UNI A a = CE-VLAN Map at UNI C & c = CE-VLAN
each EVC ID 12 E ID 12
OVC Endpoint OVC Endpoint
b = CE-VLAN e = CE-VLAN
ID 42 ID 42
4 N/A N/A ENNI Endpoint OVC Endpoint ENNI Endpoint OVC Endpoint
Map S = SVLAN ID Map T = SVLAN ID
158 158
OVC Endpoint OVC Endpoint
U = SVLAN ID V = SVLAN ID
455 455
5 Ingress bandwidth CIR= 100 Mb/s, Ingress CIR= 100 Mb/s, Ingress CIR= 100 Mb/s,
profile per EVC CBS = 12K, EIR, bandwidth CBS = 12K, bandwidth CBS = 12K,
EBS=0; CM=blind; profile per OVC EIR, EBS=0; profile per OVC EIR, EBS=0;
EP at UNI A CM=blind; EP at UNI C CM=blind;
CF=0 CF=0
6 N/A N/A Ingress CIR should Ingress CIR should
bandwidth reflect S-tag bandwidth reflect S-tag
profile per OVC overhead, rest profile per OVC overhead, rest
EP at ENNI same as UNI EP at ENNI same as UNI
7 CE-VLAN ID, CoS MUST be YES or CE-VLAN ID, MUST be yes CE-VLAN ID, MUST be YES
preservation NO CoS CoS or NO
preservation preservation
8 CoS ID based on EVC, CoS ID based All PCP values CoS ID based All PCP values
value=M S-tag PCP =M S-tag PCP =M
9 EVC Performance MFD= 80 ms for OVC MFD=10 OVC MFD = 50
Label=M, Performance Performance
PT=Continental

Table 17. Sample attributes for an EVPL service.

The main difference from EPL in this example is row 2, indicating All to one bundling is No,
and the corresponding change in Row 3 indicating which CE-VLANs map to which EVCs, and
Row 4 showing there are two SVLAN IDs at the ENNI, corresponding to the two OVCs in this
example. Additionally Row 7 shows that the End-to-end EVPL service can have CE-VLAN ID
preservation as Yes or No, and since Access EVPL is always Yes for this attribute, it will
support both choices.

9.5 Access to Layer 3 Services


The following figure shows how an Internet Service Provider could use Access EPL or Access
EVPL Service to aggregate customers in Access Provider As footprint. Note that there are only
OVCs, no EVCs, and the Subscriber seesan IP service, not a MEF defined service.

MEF 33 The Metro Ethernet Forum 2012. 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.
Ethernet Access Services Definitions

Figure 12. Access aggregation to Layer 3 services using Access EPL or Access EVPL.

MEF 33 The Metro Ethernet Forum 2012. 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.

S-ar putea să vă placă și