MEF On The GO 1.0.120617V2

Home About Contact
Ethernet Academy Training Services MEF

Fundamentals
of
Carrier Ethernet
Carrier Ethernet
Services over
Transport
Technologies
Carrier Ethernet
Services over
Access
Technologies
Key
Components
of
Carrier Ethernet
Attributes
of
Carrier Ethernet
Services
MEF Certification
of
Carrier Ethernet
Services
Typical Target
Applications for
Carrier Ethernet
Services
Positioning of
Carrier Ethernet
with other
Technologies
Synchronization
over
Carrier Ethernet &
Circuit Emulation
Carrier Ethernet
Service OAM
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Test Objectives
List of the certification
test objectives providing
the examinee with a
summary of the topics
covered in the MEF-CECP
exam
MEF Glossary
Consolidated list of
primary and equivalent
terms used in the MEF
MEF Diagrams
Gallery of diagrams used
in MEF materials
References
Links to all documents
referenced by the MEF-
CECP certification exam,
as well as other useful
information
Studying for MEF-CECP Certification
MEF-CECP Study Guide
Study Guide
Links to all the topics
covered by the MEF-CECP
Study Guide in one easy-
to-navigate page
Home About Contact
Metro Ethernet Forum Ethernet Academy
Welcome to MEF on the Go!
The MEF on the Go is designed to make your educational experience
straight forward and simple. Start by downloading MEF reference
materials. Once you are familiar with the MEF reference material
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
the MEF such as MEF Quarterly Meetings or events.
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
Topics:
Access the MEF-CECP Study
Guide
MEF-CECP Exam Objectives
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
online, or at a testing center.

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!
Copyright 2011-2012 Metro Ethernet Forum Copyright 2011-2012 Ethernet Academy
Home About Contact
Fundamentals of Carrier Ethernet
Study Guide Section 1
Introduction
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
Carrier Ethernet as defined by the MEF over the last 10 years.
The fundamental concepts of Carrier Ethernet, Carrier Ethernet services and
services types (E-Line, E-LAN and E-Tree) are introduced as well as the
concepts of private and virtual Carrier Ethernet services.

In this Section
1 Fundamentals of Carrier Ethernet
1.1 Carrier Ethernet and LAN
Ethernet
1.2 Carrier Ethernet Service Types
1.3 Virtual Service and Private
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:

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Comments
Send Feedback
Home About Contact
Carrier Ethernet Services over Transport
Technologies
Carrier Ethernet services are designed to be delivered over all deployed
transport infrastructures. This section explains the capabilities and relative
advantages of each transport technology in order to deploy a given Carrier
Ethernet service in the most effective way possible.
This section also explains about use of resilience and protection mechanisms
within the underlying transport technology to maximize the resiliency of the
Carrier Ethernet service running over that technology.
This material is not intended to promote a given transport technology since
the MEF defines Carrier Ethernet services without reference to a particular
standard or technology for the underlying transport.

In this Section
2 Carrier Ethernet Services over
Transport Technologies
2.1 Transport Technologies
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)
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

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
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 Transporting Carrier Ethernet
Services
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Carrier Ethernet Services over Access
Technologies
A key benefit of Carrier Ethernet is its ability to provide consistent, cost-
efficient, high-performance services delivered to users who are connected
over the widest variety of access networks in any location.
All the access infrastructures described in this section have significant
advantages depending on the range, bandwidth requirements, infrastructure
availability and other capabilities required for delivery of the E-Line, E-LAN,
E-Tree or E-Access service. In fact, in many instances, Service Providers will
use a combination of several access technologies to their Subscriber's various
sites in order to complete the solution for the customer.
This section highlights the relative capabilities of each access technology so
that both Subscribers and Service Providers can understand better how to
request and implement Carrier Ethernet services.

In this Section
Access Technologies
3.1 Access Infrastructures
3.1.1 HFC (DOCSIS)
3.1.2 PON
3.1.3 Packet Radio
3.1.4 PDH
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

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
IEEE 802.16
3 Carrier Ethernet Access
Technologies
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Key Components of Carrier Ethernet
This section describes the basic constructs and definitions of Ethernet services
including the following:
Subscriber
Service Provider
Operator
Carrier Ethernet Network (CEN)
User Network Interface (UNI)
External Network to Network Interface (ENNI)
Ethernet Virtual Circuit (EVC)
Operator Virtual Circuit (OVC)

In this Section
4 Key Components of Carrier
Ethernet
4.1 Subscribers, Service Providers
and Operators
4.2 EVC, OVC, UNI, ENNI and CEN
(MEN)
4.3 Service Models
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 13
MEF 26.1
4 Components of Carrier Ethernet
Send Feedback
Name:

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Email:
Comments
Send Feedback
Home About Contact
Attributes of Carrier Ethernet Services
The Carrier Ethernet Service Definition Framework provides a model for
specifying Carrier Ethernet services. Carrier Ethernet Service types are generic
constructs used to create a broad range of services. Each Carrier Ethernet
service type has a set of Carrier 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 as shown in the following figure:
Figure 5.F1 - Type-Attribute-Attribute Parameter
[Source: MEF 6.1, figure 1]
MEF 6.1 defines three Ethernet Service type generic constructs:
Ethernet Line (E-Line) Service type
Ethernet LAN (E-LAN) Service type
Ethernet Tree (E-Tree) Service type
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.
In this Section
5 Attributes of Carrier Ethernet
Services
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

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
The subsections of this part of the Study Guide describe each attribute type
and explain how they are used to create the various Carrier Ethernet services.

MEF 6.1
MEF 10.2
MEF 13
MEF 20
MEF 26.1
IEEE 802.1AX
IEEE 802.3 clause 43
5 Key UNI, ENNI, OVC, and EVC
Service Attributes
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
MEF Certification of Carrier Ethernet
Services
Introduction
The MEF is the only industry body offering certification of Carrier Ethernet
services for service providers and equipment vendors. This certification is
proof that a Carrier Ethernet service, or equipment used to deliver a Carrier
Ethernet service, has been tested successfully for compliance with the
relevant MEF specifications.
This section describes the:-
Purpose of MEF Certification
Development of MEF Technical Specifications, Implementation
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
Vendors

In this Section
6 MEF Certification of Carrier
Ethernet
6.1 Purpose of Certification
6.2 Definitions, IAs, ATSs, Test
Plans
6.3 Testing and Certification Process
6.4 Certification for SPs
6.5 Certification for Vendors
Download PDF
Download a pdf for
offline viewing.
Reference Documents
6 MEF Certification
Send Feedback
Name:
Email:

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Comments
Send Feedback
Home About Contact
Typical Target Applications Using Carrier
Ethernet Services
This section of the MEF-CECP Study Guide explains which aspects of Carrier
Ethernet need to be taken into account when running popular applications.
This is not an exhaustive list but does provide examples of the main factors
relevant for different applications.
Section 7.1: Access to IP Services
Popular application for enterprises using Carrier Ethernet to obtain services
from ISPs
Section 7.2: Wholesale Access Services
Operators providing Carrier Ethernet services to service providers in order to
extend the coverage of the latter's footprint
Section 7.3: Mobile Backhaul
Using Carrier Ethernet for backhauling cell towers
Section 7.4: Business Services
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
Section 7.6: Frame Relay/ATM Replacement
Carrier Ethernet services used to replace Frame Relay and/or ATM network
infrastructure
In this Section
7 Typical Applications Using Carrier
Ethernet Services
7.1 Access to IP Services
7.2 Wholesale Access Services
7.3 Mobile Backhaul
7.3.1 EVPL in Mobile Backhaul
7.3.2 MEF 22 Use Cases
7.4 Business Services
7.5 TDM Private Line Replacement
7.6 Frame Relay/ATM Replacement
7.7 WDM Private Network
Replacement
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 6.1
MEF 8
MEF 10.2

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Section 7.7: WDM Private Network Replacement
Carrier Ethernet services used instead of WDM connections

MEF 26.1
MEF 28
Technologies
MEF Reference Presentation: Mobile
Backhaul
MEF White Paper: CESoE
7 Target Applications for Carrier
Ethernet Services
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Positioning of Carrier Ethernet with other
technologies
Carrier Ethernet vs L2VPN, IP and TDM
This section provides information on L2VPN, IP and TDM service solutions
comparable to Carrier Ethernet in terms of the differences between these
solutions and Carrier Ethernet. In addition, information is provided on ways to
achieve a comparable service over a Carrier Ethernet Network (CEN).

In this Section
8 Positioning of Carrier Ethernet
with other technologies
8.1 Carrier Ethernet and L2VPN
8.2 Carrier Ethernet and IP
8.3 Carrier Ethernet and TDM
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 6.1
MEF 8
MEF 10.2
MEF 22.1
IETF RFC 4448
8 Comparing and Positioning Carrier
Ethernet Services

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Synchronization over Carrier Ethernet &
Circuit Emulation
Circuit Emulation Service over Ethernet (CESoETH) is a technology that enables
transport of TDM services over a Carrier Ethernet Network (CEN) as well as
enabling packet-based clock synchronization over a CEN.
CESoETH is specified in MEF 8 "Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks".
MEF 8 gives precise instructions for implementing interoperable CES solutions
that reliably transport TDM circuits across CENs while meeting the required
performance of circuit emulated TDM services as defined in ITU-T and ANSI
TDM standards.
This section:-
Explains the concept of emulated TDM circuits over Ethernet
Presents the MEF 8 model
Details the components required for the service
Details the specific UNI and EVC attributes of CES over Ethernet
Explains the concept of packet-based sychronization and its
implementation over Carrier Ethernet

In this Section
9 Synchronization over Carrier
Ethernet & Circuit Emulation
 
9.1 Purpose and Need
9.1.1 What is CESoETH
9.1.2 MEF 8 model
 
9.2 CES Components
9.2.1 Interface to Customer
9.2.2 Generic Interworking
Function (GIWF)
9.2.3 Functional Layering
 
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
 
9.4 Synchronization
9.4.1 Packet Based
Synchronization Methods
9.4.1.1 Adaptive Clock Recovery
9.4.1.2 NTP

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
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
Technologies
9 CES over Ethernet
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Carrier Ethernet Service Operations,
Administration and Maintenance
This section provides information about relevant standards, framework, fault
and performance management of Ethernet Service OAM.

In this Section
10 Carrier Ethernet Service
Operations, Administration and
Maintenance
10.1 Relevant Standards
10.1.1 IEEE 802.1ag Overview
10.1.2 Y.1731 Overview
 
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
 
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
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
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.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
 
10.5 CoS Implementation
Agreement - MEF 23
10.5.1 Ethernet Network Section
10.5.2 CoS Label Model
10.5.3 Performance Parameters
 
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
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact

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.
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Home About Contact

Objective Description
MEF
Specs
MEF
Marketing
IEEE
Standards
ITU-T
Standards
IETF
RFC
1.1
Describe and distinguish
between the service
attributes of EPL, EVPL, EP-
LAN, EVP-LAN, EP-Tree, and
EVP-Tree.
MEF 6.1
1.2
Describe how EPL, EVPL, EP-
EVP-Tree are used to meet
various subscriber needs.
MEF 6.1
2.1
Describe the connectivity
properties of bridging,
provider bridging, provider
backbone bridging (PBB),
provider backbone bridging
with traffic engineering
extensions (PBB-TE),
Ethernet over SONET/SDH,
Carrier Ethernet over MPLS
VPWS, Carrier Ethernet over
MPLS VPLS, Carrier Ethernet
over MPLS TP, Carrier
Ethernet over OTN, and
Carrier Ethernet over WDM.

802.1ah
802.1Qay
802.1ad-2005

4761
5921
2.2
Describe the capabilities of
the bridging, provider
bridging, provider backbone
bridging (PBB), provider
backbone bridging with
traffic engineering
extensions (PBB-TE),

MEF White
Paper:
Ethernet
Services and
802.1ad-2005 Y.1415
4448
4761
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
SONET/SDH, MPLS VPWS,
MPLS VPLS, MPLS TP, OTN
and WDM with regards to
delivery of Carrier Ethernet
services.
Access
Technologies
2.4
Describe the advantages of
specific Carrier Ethernet
transport technologies.

Carrier
Ethernet
Access
Reference
Presentation
802.1Q-2009
5921
5960
2.5
Describe service protection
mechanisms.

Mobile
Backhaul
Reference
Presentation
802.1Q-2009
G.8031
G.8032

3.1
Ethernet over PDH, Ethernet
over bonded copper,
Ethernet over HFC, Ethernet
over packet radio, Ethernet
over fiber and Ethernet over
PON.

MEF White
Paper:
Ethernet
Services and
Access
Technologies

3.2
Compare and contrast
Access technologies.

MEF White
Paper:
Ethernet
Services and
Access
Technologies

3.3
Given a scenario, identify
which Carrier Ethernet
Access Technology will meet
the stated requirements.

Carrier
Ethernet
Access
Reference
Presentation
MEF White
Paper:
Ethernet
Services and
Access
Technologies
802.3-2005
802.16-2009

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

4.2
Describe the role of Ethernet
User-to-Network Interface
(UNI), Ethernet External
Network-to-Network
Interface (ENNI), Ethernet
Virtual Connection (EVC),
Service Provider, Operator,
and Operator Virtual
Connection (OVC).
MEF 26
Define per UNI service
attributes (e.g., physical
MEF 10.2
5.1
interfaces, Frame format,
Ingress/egress Bandwidth
Profiles, CE-VLAN ID/EVC
Map, UNI protection).
MEF 20

5.2
Define EVC per UNI service
attributes (e.g.
ingress/egress Bandwidth
Profiles).
MEF 6.1
MEF 10.2

5.3
Define per EVC service
attributes (e.g., CE-VLAN ID
Preservation, CoS ID
Preservation, Relationship
between Service Level
Agreement and Service
Level Specification, Class of
Service).
MEF 10.2
5.4
Define OVC End Point per
ENNI service attributes
(e.g., ingress/egress
bandwidth profiles).
MEF 26
5.5 Describe bandwidth profiles.
MEF 10.2
MEF 26

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

5.7
Define and describe the
components of a Service
Level Specification and the
relationship to Service Level
Agreement.
MEF 10.2
5.8
Define and describe ENNI
Profiles, End Point Map,
ENNI protection).
MEF 26
5.9
Define and describe OVC
Agreement and Service
Level Specification, Class of
Service, hairpin switching).
MEF 26
5.10
Carrier Ethernet protection
mechanisms.
MEF 20
MEF 26

802.1AX
802.3 clause 43

6.1
Describe the Certification
process and requirements
for networking equipment.
6.2
process and requirements
for services delivered by a
service provider

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

6.4
Describe the benefits of MEF
Certification for equipment
vendors, Service Provider,
and end users.

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

7.2
Describe which UNI or ENNI
attribute values are selected
for a given target
application.
MEF 10.2
MEF 26

7.3
Describe which EVC or OVC
for a given target
application.
MEF 10.2
MEF 26

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

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

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

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

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

9.3
Define the MEF Service
Definitions used to deliver
emulated circuits.
MEF 8
9.4
Define the EVC service
attributes required for
emulated circuits.
MEF 8
9.5
Define the three techniques
and their uses for delivering
synchronized clock over
emulated circuits (e.g.,
Adaptive, 1588v2,
Synchronous Ethernet, NTP,
PTP).
MEF 22
9.6
Describe how circuit
emulation is used in Mobile
Backhaul applications.
MEF 22
10.1
Describe the various
partitioning of
responsibilities for Service
Operations Administration
and Maintenance (SOAM).
MEF 17
10.2
Describe the basic
mechanisms for fault
management.
MEF 17 Y.1731
10.3
Describe the basic
mechanisms for performance
management.
MEF 10.2
MEF 17
Global
Interconnect
Reference
Presentation
Y.1731
10.4
Describe the basic metrics
for performance
management.
MEF 6.1
MEF 10.2

Home About Contact

Diagrams
Fundamentals
of
Carrier Ethernet
Carrier Ethernet
Services over
Transport
Technologies
Carrier Ethernet
Services over
Access
Technologies
Key
Components of
Carrier Ethernet
Attributes of
Carrier Ethernet
Services
MEF Certification
of
Carrier Ethernet
Services
Typical Target
Applications for
Carrier Ethernet
Services
Positioning of
Carrier Ethernet
with other
Technologies
Synchronization
over
Carrier Ethernet &
Circuit Emulation
Carrier Ethernet
Service OAM
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Home About Contact

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
Service Definitions
E-Line, E-LAN & E-Tree:
MEF 6.1
ENNI Support for UTA and VUNI:
MEF 28
E-Access:
MEF 33
MEF Specifications
Service Attributes
EVC and UNI
MEF 10.2
OVC and ENNI
MEF 26.1
MEF Specifications
Service OAM
Requirements and Framework
Phase 1
MEF 17
MEF Specifications
Implementation
Agreements
Emulation of PDH Circuits
MEF 8
User Network Interface (Type 1)
MEF 13
UNI Type 2
MEF 20
Mobile Backhaul Phase 2
MEF Specifications
Abstract Test Suites
Ethernet Services at the UNI
MEF 9
Traffic Management Phase 1
MEF 14
Circuit Emulation Services
MEF 18
MEF White Papers
Ethernet Services and Access
Technologies
Introduction to CESoE
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
MEF 22.1
MEF Reference
Presentations
Carrier Ethernet and Access
Technologies
Carrier Ethernet and Mobile
Backhaul
Interconnect of Carrier Ethernet
Networks and Services
IEEE Standards
Provider Bridges
802.1ad-2005
Provider Backbone Bridges
802.1ah-2008
Link Aggregation
802.1AX-2008
Virtual LANs
802.1Q-2005
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
ITU-T Recommendations
Ethernet-MPLS Interworking
Y.1415
OAM Functions and Mechanisms
Y.1731
Ethernet Protection Switching
G.8031
Ethernet Ring Protection
Switching
G.8032
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

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 to Study Guide Continue to Study Guide
Home About Contact
Metro Ethernet Forum Ethernet Academy

Objective Description
MEF
Specs
MEF
Marketing
IEEE
Standards
ITU-T
Standards
IETF
RFC
1.1
Describe and distinguish
between the service attributes
of EPL, EVPL, EP-LAN, EVP-
LAN, EP-Tree, and EVP-Tree.
MEF 6.1
1.2
Describe how EPL, EVPL, EP-
EVP-Tree are used to meet
various subscriber needs.
MEF 6.1
2.1
Describe the connectivity
properties of bridging,
provider bridging, provider
backbone bridging (PBB),
with traffic engineering
extensions (PBB-TE), Ethernet
over SONET/SDH, Carrier
Ethernet over MPLS VPWS,
Carrier Ethernet over MPLS
VPLS, Carrier Ethernet over
MPLS TP, Carrier Ethernet over
OTN, and Carrier Ethernet

802.1ah
802.1Qay
802.1ad-2005

4761
5921
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!
over WDM.
2.2
Describe the capabilities of the
bridging, provider bridging,
(PBB), provider backbone
bridging with traffic
engineering extensions (PBB-
TE), SONET/SDH, MPLS VPWS,
MPLS VPLS, MPLS TP, OTN and
WDM with regards to delivery
of Carrier Ethernet services.

MEF White
Paper:
Ethernet
Services and
Access
Technologies
802.1ad-2005 Y.1415
4448
4761
2.4
Describe the advantages of
transport technologies.

Carrier
Ethernet
Access
Reference
Presentation
802.1Q-2009
5921
5960
2.5
Describe service protection
mechanisms.

Mobile
Backhaul
Reference
Presentation
802.1Q-2009
G.8031
G.8032

3.1
Ethernet over PDH, Ethernet
over bonded copper, Ethernet
over HFC, Ethernet over
packet radio, Ethernet over
fiber and Ethernet over PON.

MEF White
Paper:
Ethernet
Services and
Access
Technologies

3.2
Compare and contrast specific
Carrier Ethernet Access
technologies.

MEF White
Paper:
Ethernet
Services and
Access
Technologies

3.3
Given a scenario, identify
which Carrier Ethernet Access
Technology will meet the
stated requirements.

Carrier
Ethernet
Access
Reference
Presentation
MEF White
Paper:
Ethernet
Services and
Access
Technologies
802.3-2005
802.16-2009

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

4.2
Describe the role of Ethernet
User-to-Network Interface
(UNI), Ethernet External
Network-to-Network Interface
(ENNI), Ethernet Virtual
Connection (EVC), Service
Provider, Operator, and
Operator Virtual Connection
(OVC).
MEF 26
5.1
Define per UNI service
Profiles, CE-VLAN ID/EVC Map,
UNI protection).
MEF 10.2
MEF 20

5.2
Define EVC per UNI service
attributes (e.g. ingress/egress
Bandwidth Profiles).
MEF 6.1
MEF 10.2

5.3
Define per EVC service
Agreement and Service Level
Specification, Class of
Service).
MEF 10.2
5.4
Define OVC End Point per
ENNI service attributes (e.g.,
ingress/egress bandwidth
profiles).
MEF 26
MEF 10.2
MEF 26

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

5.7
components of a Service Level
Specification and the
relationship to Service Level
Agreement.
MEF 10.2
5.8
Define and describe ENNI
Profiles, End Point Map, ENNI
protection).
MEF 26
5.9
Define and describe OVC
Agreement and Service Level
Specification, Class of Service,
hairpin switching).
MEF 26
5.10
Carrier Ethernet protection
mechanisms.
MEF 20
MEF 26

802.1AX
802.3 clause 43

6.1
process and requirements for
networking equipment.

6.2
process and requirements for
services delivered by a service
provider

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

Describe the benefits of MEF
6.4
Certification for equipment
vendors, Service Provider, and
end users.

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

7.2
Describe which UNI or ENNI
for a given target application.
MEF 10.2
MEF 26

7.3
Describe which EVC or OVC
for a given target application.
MEF 10.2
MEF 26

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

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

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

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

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

9.3
Define the MEF Service
Definitions used to deliver
emulated circuits.
MEF 8
9.4
Define the EVC service
attributes required for
emulated circuits.
MEF 8
9.5
Define the three techniques
and their uses for delivering
synchronized clock over
emulated circuits (e.g.,
Adaptive, 1588v2,
Synchronous Ethernet, NTP,
PTP).
MEF 22
9.6
Describe how circuit emulation
is used in Mobile Backhaul
applications.
MEF 22
10.1
Describe the various
partitioning of responsibilities
for Service Operations
Administration and
Maintenance (SOAM).
MEF 17
10.2
Describe the basic mechanisms
for fault management.
MEF 17 Y.1731
10.3
Describe the basic mechanisms
for performance management.
MEF 10.2
MEF 17
Global
Interconnect
Reference
Y.1731
Copyright 2011-2012 Metro Ethernet Forum Copyright 2011-2012 Ethernet Academy
Presentation
10.4
Describe the basic metrics for
performance management.
MEF 6.1
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
Home About Contact
Study Guide Section 1.1
Carrier Ethernet and LAN Ethernet
The very widely used LAN Ethernet technology developed and implemented
around the world since the 1970's is just that - a Local Area Network
technology designed for use within buildings or between buildings in a
campus. LAN Ethernet is not designed for use over long distances within
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
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
and user needs nor does it support the type of management capabilities
required for large network service delivery that is available with legacy WAN
technologies.
In order to combine the advantages of LAN Ethernet's large installed base and
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
that today provide the basis for the use of Ethernet as a global networking
solution.
The MEF defined five key attributes that differentiate Carrier Ethernet from
LAN Ethernet, and which form the basis for the development of Carrier
In this Section
Ethernet
Service
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 6.1
Send Feedback
Name:
Email:

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Ethernet specifications by the MEF.
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
Comments
Send Feedback
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

Home About Contact
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.
There are three service types that describe the basic connectivity options of a
Carrier Ethernet service:
E-Line
E-LAN
E-Tree
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,
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
Guide.
E-Line
An E-Line is a point to point Ethernet service that connects exactly 2 UNIs.
Those 2 UNIs can communicate only with each other.
In this Section
Ethernet
Service
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 6.1
Send Feedback
Name:
Email:

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Figure 1.2.F1: E-Line Carrier Ethernet service type
E-Lines are used to create:-
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.
Comments
Send Feedback
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.

Home About Contact
Virtual Service and Private Service
In its simplest form, each UNI is dedicated to a single service instance,
providing very simple mapping of customer traffic into the 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
Interface (UNI) connectivity.
Private services can be offered for any topology.
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
EP-Tree: Ethernet Private Tree for port-based rooted-multipoint
service. EP-Tree is the private variant of an E-Tree.
The advantage of the private service approach is its simplicity. The
disadvantage is its lack of scalability since it requires several ports on both
the Customer Equipment (CE) and the switch/router at the provider edge.
To overcome this barrier to scalability, the MEF defined the virtual service
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.
A virtual service means that a UNI can deliver multiple services using a single
physical port, and can be offered for any topology.
In this Section
Ethernet
Service
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 6.1
Send Feedback
Name:
Email:

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
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
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.
Comments
Send Feedback

Home About Contact

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.

'
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Home About Contact

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]."
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Download
Reference Presentation
The MEF has prepared an overview presentation which explains the MEF 6.1 specification.
Download

Home About Contact
Test Objectives 1 1
Service Definitions
1.1 Describe and distinguish between the service attributes of EPL, EVPL, EP-
LAN, EVP-LAN, EP-Tree, and EVP-Tree.
1.2 Describe how EPL, EVPL, EP-LAN, EVP-LAN, EP-Tree, and EVP-Tree are
used to meet various subscriber needs.
In this Section
Ethernet
Service
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 6.1
Send Feedback
Name:
Email:

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Comments
Send Feedback
Home About Contact
Technologies
Carrier Ethernet services can be implemented over any network based on the
following transport technologies:
Transparent Bridging
Provider Bridging (PB)
Provider Backbone Bridging (PBB)
Provider Backbone Bridging with Traffic Engineering (PBB-TE)
MPLS VPWS
MPLS VPLS
MPLS TP
SONET/SDH
OTN
DWDM and CWDM
It is important to understand which transport technologies enable which
Carrier Ethernet services and which attributes are required, as well as to
understand the differences in capabilities (e.g. transparency to L2CP,
topology) of these technologies. This is explained in the corresponding sections
on each technology.
For the sake of simplicity, the above technologies have been grouped under
the following categories:
IEEE-based transport technologies
MPLS-based transport technologies
In this Section
technologies
2.1.1.1 Bridging
Bridging (PBB)
(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.1 SONET/SDH
2.1.3.2 OTN
2.1.3.3 WDM
Download PDF

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
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
Services
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Technologies
Protection and Resiliency
When connecting network elements in order to create a network, it is
common practice to consider and provision for various failures. Ideally, the
traffic should continue to flow even if a failure of a link or a port has
occurred.
There are three types of failures to consider:
1. Port Failure
2. Link Failure
3. Network Element (NE) Failure
Since MEF services define interfaces only, we focus on the first two types of
failures. It should be noted that NE failure handling is heavily dependent on
the transport technology of the specific network in question.
Port protection
We focus our discussion on the external Interfaces - namely UNI and ENNI.
MEF 20 defines as a mandatory feature of UNI Type 2.2 the capability to
protect against a UNI-N port failure and/or protect against a failure of a
physical link crossing the UNI point.
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
In this Section
technologies
2.1.1.1 Bridging
Bridging (PBB)
(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.1 SONET/SDH
2.1.3.2 OTN
2.1.3.3 WDM
Download PDF

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
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
links and operate 3 of them as active links with one standby link. This would
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
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
more than one active link (load sharing LAG). MEF recommends operating LAG
with its control protocol LACP.
UNI protection is depicted in the following figure:
2.2.F1 - UNI protection
ENNI Protection is depicted in the following figure:
2.2.F2 - ENNI Protection
It should be noted that some vendors do allow LAG between different line-
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
solution.
Service protection
Service Protection deals with the need to ensure that the EVC/OVC can
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
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.
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.
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
Services
Send Feedback
Name:
Email:
Comments
Send Feedback
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
Home About Contact
Technologies
Study Guide Section 2.1.1
IEEE-based transport technologies
Carrier Ethernet services can be delivered over IEEE 802.1 standards-based:
Bridged networks
Provider Bridged (PB) networks
Provider Backbone Bridged (PBB) networks
Provider Backbone Bridged with Traffic Engineering (PBB-TE) networks
All these networks require some form of layer 1/2 transport technology to
interconnect bridges. Typically, these bridges are interconnected with IEEE
802.3 Ethernet.
The capabilities of each of the IEEE 802.1 standards-based technologies used
in these networks needs to be taken into account when implementing any of
the six Carrier Ethernet services:
EPL
EVPL
EP-LAN
EVP-LAN
EP-Tree
EVP-Tree
These technologies, and the Carrier Ethernet services delivered over them,
can operate over any physical topology:
In this Section
technologies
2.1.1.1 Bridging
Bridging (PBB)
(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.1 SONET/SDH
2.1.3.2 OTN
2.1.3.3 WDM
Download PDF

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
mesh
partial mesh
tree
set of rings

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
Services
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Technologies
Study Guide Section 2.1.1.1
Bridging
Bridging refers to networks that pass frames using C-Tags in accordance with
IEEE 802.1Q. The C-Tag frame format is shown below:
2.1.1.1.F1 - C-Tag Frame Format
The format of the C-Tag itself is provided below:
2.1.1.1.F2 - C-Tag Format
In a CEN (Carrier Ethernet Network) that is based on bridging, the ingress
In this Section
technologies
2.1.1.1 Bridging
Bridging (PBB)
(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.1 SONET/SDH
2.1.3.2 OTN
2.1.3.3 WDM
Download PDF

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
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
available VLAN IDs in the range 1 through 4094 must be shared and
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
to regenerate the tags and priorities in the frames forwarded to the
subscriber site. In addition, MAC learning is shared by subscriber bridges and
the CEN's bridges, which again implies several limitations. This fact coupled
with limited port filtering of the bridges makes support of E-Tree a significant
configuration challenge. In addition, such a network cannot support bundling,
as it is not possible to regenerate the original CE-VLAN IDs on an egress UNI
using a single C-Tag.
Since the CEN operates using bridges, it relies on xSTP (any variant of
Spanning Tree Protocol) for loop prevention and resiliency. In the event of a
link failure, xSTP is used to find a new path through the CEN. This implies
that some subscriber L2CPs will not be tunneled through a CEN based on
bridging.
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
that can be supported.
Also, there must be coordination between all participating UNIs of the CE-
VLAN IDs used for each service.
The CoS ID for an EVC is identified by the PCP bits. No other field can
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
to Yes.
In addition, the 8 possible values are shared between CoS ID and frame color.
These values need to be transported through the CEN.
It is clear that only small scale CENs will be based on bridging, and where
there are no ENNIs (since they require use of S-Tags).
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
Services
Send Feedback
Name:
Email:
Comments
Send Feedback
2.1.1.1.T1 - Bridging support for Carrier Ethernet Services
Home About Contact
Technologies
Provider Bridging (PB)
Provider Bridging (PB), as specified by IEEE 802.1ad, aims to solve the
problematic coordination of VLAN IDs between service providers and
subscribers that is required in bridging. PB is also designed to support
tunneling of customer traffic through a service provider's network. This
tunneling is achieved using a stacked VLAN approach, also known as Q-in-Q.
The IEEE 802.1ad amendment introduced a second type of VLAN tag for the
purpose of delineating the service provider's tag from the customer's tag. This
service provider tag is known as the S-Tag, while the customer continues to
use the original VLAN tag, known as the C-Tag.
The Double Tag Frame Format is shown below:
2.1.1.2.F1 - Double Tag Frame Format
The structure of the S-Tag is shown below:
In this Section
technologies
2.1.1.1 Bridging
Bridging (PBB)
(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.1 SONET/SDH
2.1.3.2 OTN
2.1.3.3 WDM
Download PDF

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
2.1.1.2.F2 - S-Tag Format
The value of the S-VLAN ID can be 1 through 4094.
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
transported through separate bridges with no overlap of their paths.
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
frame's color. When the DEI bit is clear, the frame is considered to be Green.
When the DEI bit is set, the frame is considered to be Yellow.
The edge bridge of the PB network performs the mapping to an EVC or an
OVC, where the EVC or OVC is identified by an S-VLAN ID. It is also possible to
add an S-Tag to ingress C-Tagged frame, thereby preserving the Subscriber's
original C-VLAN ID. This is also true in the case of an untagged frame.
PB supports all six MEF-defined services (EPL, EVPL, EP-LAN, EVP-LAN, EP-
Tree and EVP-Tree). PB inherently supports service multiplexing by allowing
service providers to map C-VLANs to S-VLANs at a port being used for the UNI.
PB relies on the bridges within the CEN (Carrier Ethernet Network) for
multicast operations required by E-LAN and E-Tree services.
Note that E-Tree requires certain specific filtering to be configured on those
bridges connected to leaf UNIs.
The capabilites are 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
Services
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.
Home About Contact
Technologies
Provider Backbone Bridging (PBB)
Provider Backbone Bridging (PBB) in IEEE 802.1ah was developed to solve the
problem of scaling to more than 4,094 services in a Provider Bridged network,
and to provide service providers with a bridging technology that would allow
them to encapsulate the Subscriber's MAC addresses, VLANs, and data, making
the transport of such frames "transparent" across their network.
The concept of PBB is to create a backbone network that interconnects PB
networks at the customer edge.
PBB can be used to connect C-Tagged networks (CEs in MEF's terminology).
A PBB network (PBBN) can be a service provider's CEN that provides
connectivity between UNIs for Subscribers through EVCs. Similarly, a PBB
network could be an operator's network that provides connectivity from ENNI-
to-ENNI or from ENNI-to-UNI for service providers through OVCs.
The concept of MAC-in-MAC was introduced in PBB. MAC-in-MAC allows the
service provider to fully encapsulate the customer 802.1Q frame within
another MAC, which abstracts the service provider from the Subscriber's
address and VLAN information.
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
unaltered from end-to-end throughout the provider's backbone network. The
backbone bridges can only interpret the outermost MAC header information.
Furthermore, a new Tag type called the I-SID (Backbone Service Instance
In this Section
technologies
2.1.1.1 Bridging
Bridging (PBB)
(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.1 SONET/SDH
2.1.3.2 OTN
2.1.3.3 WDM
Download PDF

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
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
million service instances. This is equivalent to the scalability provided by
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.
PBB introduces two new types of tags: the Backbone VLAN Tag (B-Tag) and
the Backbone Service Instance Tag (I-Tag). The B-Tag is identical to an S-Tag,
but is the tag that Backbone Bridges within the PBBN use to make traffic
forwarding decisions. The I-Tag encapsulates the Subscriber's MAC information
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.
The frame format is depicted below:
2.1.1.3.F1 - frame format
On ingress, each service frame is parsed in order to identify the correct
EVC/OVC to which it is mapped. A new MAC header is then added accordingly.
The CEN (Carrier Ethernet Network) then forwards the frame through the
PBBN according to the backbone header. Forwarding is performed exactly as
in PB (Provider Bridging). Bridges learn (backbone) addresses, flood when an
unknown address is identified, and use the same xSTP-based resiliency
mechanisms as in PB.
The B-Tag (which is identical to an S-Tag is format and TPID) has 3 bits of PCP
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 -
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.
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
Services
Send Feedback
Name:
Email:
Comments
Send Feedback
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.

Home About Contact
Technologies
Provider Backbone Bridging - Traffic Engineering (PBB-TE)
PBB networks are quite different from other transport networks in some
fundamental aspects. The PBB network selects the path between source and
destination without the operator's control. PBB lacks pre-defined back-up
paths that are essential for delivering sub-50 msec service protection. Finally,
the flooding of unknown frames can impact the the ability to provide a
service with guaranteed bandwidth.
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
PBT (Provider Bridging Transport).
PBB-TE uses the same frame format as in PBB. However PBB-TE enables
definition of end-to-end active and backup paths by means of management
plane configuration. The network operator has administrative control over
these paths, which allows them to "traffic engineer" the network. This method
is sometimes referred to as Connection Oriented Ethernet.
Having pre-defined paths eliminates the need to flood the network with
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
node faults in less than 50 msec.
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
more easily guarantee bandwidth.
In this Section
technologies
2.1.1.1 Bridging
Bridging (PBB)
(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.1 SONET/SDH
2.1.3.2 OTN
2.1.3.3 WDM
Download PDF

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
table:
2.1.1.4.T1 - PBB-TE Support for Carrier Ethernet Services
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
Services
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Technologies
MPLS based transport technologies
Carrier Ethernet services can be delivered over networks based on MPLS
VPWS, MPLS VPLS and MPLS-TP. These technologies are based on MPLS
standards specified by IETF and ITU-T. They all require some form of layer
1/2 transport technology betweeen the routers. These technologies can
operate over any physical topology: mesh, partial mesh, tree or set of rings.
From the point of view of Carrier Ethernet, the fundamentals of VPWS, VPLS
and MPLS TP are similar. LERs (PEs) at the network edges and LSRs (PEs) in
the core.

In this Section
technologies
2.1.1.1 Bridging
Bridging (PBB)
(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.1 SONET/SDH
2.1.3.2 OTN
2.1.3.3 WDM
Download PDF

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
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
Services
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Technologies
Virtual Private Wire Service (VPWS)
VPWS (Virtual Private Wire Service) is the simplest form of enabling Ethernet
services over MPLS. It is also known as ETHoMPLS (Ethernet over MPLS), or VLL
(Virtual Leased Line)
VPWS comprises point-to-point LSPs that carry Ethernet PWs (pseudowires)
between LERs (Label Edge Routers). These LERs or PEs (Provider Equipment)
in Carrier Ethernet terminology provide the UNI-N functionality. In such a
case, the CEN (Carrier Ethernet Network) provides Ethernet services to CEs
(Customer Equipment) attached to the PEs.
In other deployments, the network is a CEN where some external interfaces
are ENNIs. In such a case, the PW is between the ENNI-N and a UNI-N or
between two ENNI-Ns.
The objective is to create virtual connections between PEs with pseudowires
and to transport the Ethernet services over these pseudowires.
The entire Ethernet frame (excluding FCS) is carried over the MPLS/PW.
Therefore, no MAC learning is required.
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
of this explanation.
Multiple PWs can be carried over a single LSP, and each PW can be configured
In this Section
technologies
2.1.1.1 Bridging
Bridging (PBB)
(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.1 SONET/SDH
2.1.3.2 OTN
2.1.3.3 WDM
Download PDF

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
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.
The following figure illustrates how a C-TAG frame sent from the CE is
encapsulated over MPLS PW:
2.1.2.1.F1 - VPWS
The tunnel label (LSP label) is a 20-bit field, yielding over 16 million unique
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
can be mapped to a single PW or to multiple PWs, theoretically 16 million
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
over a single VPWS.
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
color forwarding where applicable.
Up to eight CoSs can be delivered over MPLS LSPs. However, assuming that
some CoSs need to also denote color, the effective number is five CoSs. MPLS
networks can support the 3-CoS model of MEF 23.
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
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:
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
Services
Send Feedback
Name:
Email:
Comments
Send Feedback
2.1.2.1.T1 - VPWS Support for Carrier Ethernet Services
Home About Contact
Technologies
Virtual Private LAN Service (VPLS)
2.1.2.1.F1 - VPLS
Resiliency is also provided by the MPLS LSP and PW layers which can be
considered to be independent of the VPLS service instance. Services are
denoted in the same manner as for VPWS, as is CoS ID.
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
frames, learns the customer MAC addresses and makes the forwarding
decision. Once a destination or set of destinations is determined, the
appropriate frame is encapsulated with the tunnel and PW headers. When
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.
In this Section
technologies
2.1.1.1 Bridging
Bridging (PBB)
(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.1 SONET/SDH
2.1.3.2 OTN
2.1.3.3 WDM
Download PDF

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Multiple VPLS instances - one per service or L2VPN - can use the same
network infrastructure.
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.
The CEN (Carrier Ethernet Network) does not use xSTP (variants of Spanning
Tree Protocol) for forwarding or resiliency. The Customer xSTP is not tunneled
across the VPLS-based CEN.
E-Tree is naturally supported by VPLS. The concept of hub (root) and spoke
(leaf) is also part of the VPLS standard.
2.1.2.2.T1 - VPLS Support for Carrier Ethernet Services
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
Services
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Technologies
MPLS-TP
MPLS-TP (MPLS Transport Profile) is jointly specified by the IETF and the ITU-
T. It is designed to be a sub-set of the MPLS framework that provides
connection-oriented services better suited to transport networks.
MPLS-TP uses the same packet format as MPLS, as well as uses LSPs (Label
Switched Paths) and PWs (pseudowires)
The MPLS-TP path is configured by the management system, but can
optionally be determined and provisioned by the GMPLS control plane. MPLS-
TP supports active and backup paths, providing linear protection with sub-50
msec recovery. The concept of pre-defined active and backup paths facilitates
traffic engineering and enables guaranteed bandwidth across the CEN (Carrier
Ethernet Network)
MPLS-TP also provides extensive OAM support, including Y.1731 FM (Fault
Management) and PM (Performance Management). Unlike MPLS, MPLS-TP does
not use IP routing, so MPLS-TP CENs can be purely layer 2 networks.
MPLS supports point-to-point LSPs and also point-to-multipoint LSPs. Unlike
MPLS, the forward and reverse directions of traffic are carried over the same
network path at all times.
In this Section
technologies
2.1.1.1 Bridging
Bridging (PBB)
(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.1 SONET/SDH
2.1.3.2 OTN
2.1.3.3 WDM
Download PDF

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
E-LANs and E-Trees can be implemented by running VPLS over MPLS-TP based
LSPs and PWs.
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
VPWS for more details.
EPL services can be provided over MPLS-TP with transparent handling of L2CPs
in a similar fashion to that supported by VPWS.
2.1.2.3.T1 - MPLS-TP Support for Carrier Ethernet Services

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
Services
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Technologies
Transparent Transport Technologies
Carrier Ethernet E-Line services can be delivered transparently over networks
based on SONET/SDH, OTN or WDM as explained in the following sections.

In this Section
technologies
2.1.1.1 Bridging
Bridging (PBB)
(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.1 SONET/SDH
2.1.3.2 OTN
2.1.3.3 WDM
Download PDF

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
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
Services
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Technologies
SONET/SDH
Carrier Ethernet E-Line services can be delivered over SONET and SDH. SONET
and SDH are widely deployed technologies in transport networks. They are
typically based on ring topologies. Each ring can operate at several rates, up
to a maximum of 10 Gbps.
An example of the network architecture is illustrated below:
2.1.3.1.F1 - Network Architecture
In this Section
technologies
2.1.1.1 Bridging
Bridging (PBB)
(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.1 SONET/SDH
2.1.3.2 OTN
2.1.3.3 WDM
Download PDF

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
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
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.
Encapsulation of an Ethernet frame inside GFP-F frame is illustrated below:
2.1.3.1.F2 - Encapsulation of an Ethernet frame inside GFP-F frame
All of the encapsulation techniques (e.g. GFP, POS) are not aware of the
Ethernet frame structure. This means that any L2CP frame can be tunneled
through a SONET/SDH-based E-Line service. Also, no MAC learning, forwarding
or filtering is performed by these network elements.
Each incoming service is transported transparently over the CEN (Carrier
Ethernet Network). Each service is carried in its own container with no
bandwidth sharing or contention amongst containers. Likewise, each service
requires a dedicated port on the ADM. For example, if a single CE sends traffic
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
containers. This can be done by the ADM (Add/Drop Multiplexing) function of
SONET/SDH network element.
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
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
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
Services
Send Feedback
Name:
Email:
Comments
Send Feedback
sub-50 msec service restoration that is transparent to the Ethernet layer.
2.1.3.1.T1 - SONET/SDH Support for Carrier Ethernet Services
Home About Contact
Technologies
Optical Transport Network (OTN)
E-Line services can be delivered over Optical Transport Networks (OTN) using
Ethernet over OTN as specified by the ITU-T G.709 Recommendation. OTN is a
standard method for transparent transport of services over optical
wavelengths in WDM systems. OTN is often regarded as a next generation
SONET/SDH technology that supports 10, 40 and 100 Gbps transport links.
Transport of Ethernet frames over OTN is highly transparent.
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
(ODU). For example, the most appropriate OTN container for Carrier Ethernet
services at the UNI is ODU0, which supports the transport of a 1000BASE-X
signal mapped to the container using Generic Framing Procedure (GFP). This is
a scalable solution for delivering high bandwidth EPL Services.
Ethernet over OTN provides the same resiliency as SONET/SDH but with more
flexible bandwidth allocation. It is fully transparent to the Ethernet frame,
meaning any L2CP frame can be tunneled over the OTN-based network. No
MAC learning, forwarding or filtering is performed.
Support for EVPL is limited and requires specific mapping and depends on the
topology.
VLANs and CoS are not supported.
In this Section
technologies
2.1.1.1 Bridging
Bridging (PBB)
(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.1 SONET/SDH
2.1.3.2 OTN
2.1.3.3 WDM
Download PDF

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
2.1.3.2.T1 - OTN Support for Carrier Ethernet Services

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
Services
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Technologies
WDM
Carrier Ethernet E-Line services can be delivered over Wave Division
Multiplexed (WDM) networks using Ethernet over WDM technology. Both these
physical layer transport technologies carry packetized digital traffic (i.e.,
Ethernet frames) over photonic channels. DWDM and CWDM technologies can
be used to provide very high bandwidth connections in the order of hundreds
of Gbps over distances ranging up to 80km (50 miles) without repeaters.
However, when WDM is used to deliver Carrier Ethernet services, it supports
point-to-point topologies only.
Incoming traffic is mapped by a multiplexer to a specific optical channel.
Mapping is agnostic to the content and header of the Ethernet frame and
therefore provides a very transparent point-to-point service.
This is illustrated in the following figure:
2.1.3.3.F1 - WDM
The WDMs cannot decipher the CoS Identifier and VLAN tag information
contained within an Ethernet frame, so all Ethernet frames associated with a
particular service are transported by the same photonic channel. Only physical
In this Section
technologies
2.1.1.1 Bridging
Bridging (PBB)
(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.1 SONET/SDH
2.1.3.2 OTN
2.1.3.3 WDM
Download PDF

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
layer failures can be detected and acted upon with this technology, and
recovery is performed without intervention from the Ethernet MAC layer.
2.1.3.3.T1 - WDM Support for Carrier Ethernet Services

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
Services
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact

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.

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Home About Contact

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.

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Home About Contact

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.

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Home About Contact

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.

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Home About Contact

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.

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Home About Contact

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.

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Home About Contact

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.

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Home About Contact

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.
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Document download
Wikipedia
Home About Contact

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

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."
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
More links relating to VPLS can be found at the Wikipedia page on this topic.
Document download
Wikipedia
Home About Contact

IETF RFC 5921
A Framework for MPLS in Transport Networks

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
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
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
Home About Contact

IETF RFC 5960
MPLS Transport Profile Data Plane Architecture

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
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
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
Home About Contact
Test Objectives 2 1
Transporting Carrier Ethernet Services
2.1 Describe the connectivity properties of bridging, provider bridging,
provider backbone bridging (PBB), provider backbone bridging with traffic
engineering extensions (PBB-TE), Ethernet over SONET/SDH, Carrier Ethernet
over MPLS VPWS, Carrier Ethernet over MPLS VPLS, Carrier Ethernet over MPLS
TP, Carrier Ethernet over OTN, and Carrier Ethernet over WDM.
2.2 Describe the capabilities of bridging, provider bridging, provider backbone
bridging (PBB), provider backbone bridging with traffic engineering extensions
(PBB-TE), SONET/SDH, MPLS VPWS, MPLS VPLS, MPLS TP, OTN and WDM with
regards to delivery of Carrier Ethernet services.
2.3 Deleted
2.4 Describe the advantages of specific Carrier Ethernet transport
technologies.
2.5 Describe service protection mechanisms.
In this Section
technologies
2.1.1.1 Bridging
Bridging (PBB)
(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.1 SONET/SDH
2.1.3.2 OTN
2.1.3.3 WDM
Download PDF

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
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
Services
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Technologies
Access Infrastructures
Carrier Ethernet services are designed to be delivered over all the commonly
available packet access infrastructures deployed today including:
HFC (DOCSIS)
PON
Packet Radio
PDH (T1/E1/T3/E3)
Dark and active fiber
Bonded copper
This section explains the considerations to be taken into account when using
different access infrastructures for the implementation of Carrier Ethernet
services.
The range of access technologies supporting Carrier Ethernet services are
depicted in the following figure:
3.1.F1 - Carrier Ethernet Services over Access Infrastructures
In this Section
Access Technologies
3.1.1 HFC (DOCSIS)
3.1.2 PON
3.1.3 Packet Radio
3.1.4 PDH
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
Technologies
Technologies
IEEE 802.3

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page

IEEE 802.16
Technologies
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Technologies
Carrier Ethernet over HFC (DOCSIS)
Reach, Rates and Triple Play
Hybrid fiber-coaxial (HFC) is an industry term for a broadband network which
combines optical fiber and coaxial cable. It has been commonly employed by
MSO/cable TV operators since the early 1990s.
The fiber optic network extends from the cable operators' master/regional
head-end, to a neighborhoods hub site, and finally to a fiber optic node
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
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
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
standard developed by CableLabs and contributing companies. DOCSIS defines
the communications and operation support interface requirements for a data
over cable system. DOCSIS 1.0, 1,1 and 2.0 all utilize a single upstream and a
single downstream channel, while the DOCSIS 3.0 standard allows for channel
bonding, and hence higher throughput rates. DOCSIS 3.0 allows for a peak
downstream rate of approximately 350 Mbps and a peak upstream rate of
In this Section
Access Technologies
3.1.1 HFC (DOCSIS)
3.1.2 PON
3.1.3 Packet Radio
3.1.4 PDH
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
Technologies
Technologies
IEEE 802.3

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
approximately 125 Mbps.
3.1.1.F1 - Carrier Ethernet and HFC

IEEE 802.16
Technologies
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Technologies
Carrier Ethernet over PON
Reach, Rates and Triple Play
Passive Optical Networking (xPON) is a point-to-multipoint optical access
architecture that facilitates broadband communications between an 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 of
approximately 40 km (25 miles). PON supports from 1 to 128 users per single
strand of fiber.
PON is a cost-effective access method because it conserves fiber for service
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,
with total downstream bandwidth reaching 10 Gbps (statistically shared
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
supported on both platforms. Standards are also underway at CableLabs for
translation of DOCSIS management commands into Ethernet formats to
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.
In this Section
Access Technologies
3.1.1 HFC (DOCSIS)
3.1.2 PON
3.1.3 Packet Radio
3.1.4 PDH
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
Technologies
Technologies
IEEE 802.3

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
3.1.2.F1 - Carrier Ethernet Services over PON Infrastructures

IEEE 802.16
Technologies
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Technologies
Carrier Ethernet over Packet Radio
Reach, rates, licensed and unlicensed
Where wireline services are not available or practical, delivering Ethernet
over a point-to-point wireless access network can make a previously
unattainable connection practical. Also, where mobility is required, broadband
wireless services from mobile service providers may provide an effective
connectivity option.
Terrestrial Microwave
A microwave link uses microwave frequencies (above 1 GHz) for line of sight
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
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
frequency. 100 Mbps Fast Ethernet can be achieved reliably up to 48 KM (30
miles) at 6 GHz.
The use of microwave links avoids the need to install cables between
communication equipment. Microwave links may be set up over licensed
frequencies (filed and protected by government agencies) or over unlicensed
In this Section
Access Technologies
3.1.1 HFC (DOCSIS)
3.1.2 PON
3.1.3 Packet Radio
3.1.4 PDH
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
Technologies
Technologies
IEEE 802.3

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
frequencies (through the use of low power within unlicensed regulatory limits)
Broadband Wireless
EVDO (Evolution of Existing Systems for Data Only) is a commonly available
upgraded service of cellular providers with CDMA (Code Division Multiple
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.
A system uses the same reverse channel which limits the uplink data
transmission rate to approximately 1.8 Mbps. The EVDO system has an
upgraded packet data transmission control system that allows for bursty data
transmission rather than for more continuous voice data transmission.
GSM (Global System for Mobile)
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
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.
IEEE 802.16
Technologies
Send Feedback
Name:
Email:
Comments
Send Feedback
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

Home About Contact
Technologies
Carrier Ethernet over PDH
An alternative to SONET/SDH nor Dark Fiber facilities are used by Service
Providers that have found that an existing PDH network - consisting of
traditional DS1/E1, DS3 and E3 standard circuits - enable the Service Provider
to deliver Carrier Ethernet to locations that would otherwise be unreachable.
Ethernet over Bonded T1/E1
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
humble beginnings as voice trunk line technologies, to their more recent
achievement as the gold standard of Internet access for small and medium-
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
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
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
demanded by many enterprise customers. Because there are multiple links
involved in the access method, it is inherently protected against interruptions
of one or more of those links (for example, a destruction of a facility by a
backhoe or an excavator).
In this Section
Access Technologies
3.1.1 HFC (DOCSIS)
3.1.2 PON
3.1.3 Packet Radio
3.1.4 PDH
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
Technologies
Technologies
IEEE 802.3

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
There are three standardized methods for delivering Carrier Ethernet over
T1/E1 lines:-
multilink point-to-point protocol (MLPPP)
GFP/VCAT
G.bond or EFM
While each technology has its strengths, they all deliver comparable
performance and are available from many equipment vendors.
Ethernet over DS3/E3
Just as T1/E1 is a desirable access technology for delivering Ethernet service,
DS3 and E3 circuits provide another alternative using readily available
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
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
IEEE 802.16
Technologies
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Technologies
Carrier Ethernet over Fiber
For applications where it is available or where the bandwidth requirements
dictate it, delivering Ethernet over optical fiber is an excellent choice. With
virtually unlimited bandwidth support, noise immunity and the ability to
traverse long distances, optical fiber can provide the performance for the
applications of today and those envisioned for tomorrow.
Active Ethernet
One of the most common Ethernet over Fiber architectures is point-to-point,
where the connection is from the Service Providers aggregation switch to a
Network Interface Device (NID) located at the customer premises.
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
infrastructure build-out. Fiber optics as an access medium is also preferred
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,
Gigabit and 10 Gigabit data rates, as well as multiplex multiple channels using
Wavelength Division Multiplexing (WDM), enable it to support any foreseeable
future data rates and services.
The distances that can be supported by a fiber infrastructure are limited only
by the active interface hardware. Using standard optics, 2 km-150 km (1.25
In this Section
Access Technologies
3.1.1 HFC (DOCSIS)
3.1.2 PON
3.1.3 Packet Radio
3.1.4 PDH
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
Technologies
Technologies
IEEE 802.3

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
94 mile) distances can be easily be achieved.
3.1.5.F1 Carrier Ethernet over Fiber
IEEE 802.16
Technologies
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Technologies
Carrier Ethernet over Bonded Copper
Ethernet in the First Mile over Copper (EFMCu) allows fast deployment of
resilient symmetrical Ethernet Access/Backhaul links over existing voice-grade
copper infrastructure, providing a very economical alternative to fiber. There
are two standardized EFMCu technologies:
Long reach 2BASE-TL, delivering a minimum of 2 Mbit/s and a
maximum of 5.69 Mbit/s over distances of at least 2700 m, using
standard G.SHDSL.bis technology over a single copper pair. This
bandwidth is symmetrical.
Short reach 10PASS-TS, delivering a minimum of 10 Mbit/s over
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.
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.
Both EFMCu technologies support an optional aggregation or bonding of
multiple copper pairs (up to 32), providing higher bandwidth, longer reach
and improved resiliency. The aggregate bandwidth, in excess of 100 Mbps, for
downlink traffic, offered by copper bonding solutions meet the needs of most
bandwidth-intensive Carrier Ethernet applications.
In this Section
Access Technologies
3.1.1 HFC (DOCSIS)
3.1.2 PON
3.1.3 Packet Radio
3.1.4 PDH
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
Technologies
Technologies
IEEE 802.3

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
3.1.6.F1 Carrier Ethernet over Bonded Copper

IEEE 802.16
Technologies
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Technologies
Comparisons
Benefits of HFC (DOCSIS) for Carrier Ethernet services
HFC permits the addition of high-speed data transfer to an existing Cable TV
(CATV) system. It is employed by many cable television operators to provide
Internet access and Business Services over their existing (HFC) infrastructure.
With its large coverage and available performance, HFC/DOCSIS technology is
a valuable asset for Cable TV/MSO providers to deliver Ethernet-based
services to the SOHO/SMB and high-speed Internet access to residential
customers.
Benefits of PON for Carrier Ethernet services
PONs immediate benefit is the increase in the bandwidth delivered to the
residential and SME/SMB subscriber compared to legacy twisted pair
technologies. Other benefits of PON include:
1. Delivery of new bandwidth-intensive applicaiton
2. Significant reductions in fiber infrastructure
3. Large reductions in electrical cost
4. Reduced maintenance requirements
Benefits of PDH for Carrier Ethernet services
The primary benefit that comes from using T1/E1 for delivering Carrier
In this Section
Access Technologies
3.1.1 HFC (DOCSIS)
3.1.2 PON
3.1.3 Packet Radio
3.1.4 PDH
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
Technologies
Technologies
IEEE 802.3

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Ethernet services is that Service Providers are able to reach all of their
customer locations, regardless of geography and proximity to their facilities.
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,
allowing the service provider to recognize revenue sooner and to decouple
sales efforts from the infrastructure build-outs associated with many
alternative technologies.
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
turn-up and revenue recognition are additional side benefits of this
infrastructure.
Benefits of Fiber for Carrier Ethernet services
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.
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
Ethernet
Access
Method
Technology
Alternatives
Deployment Scenarios
(When to use the
technology)
Advantages
Ethernet
over Fiber
- Active Ethernet
- Ethernet over
SONET/SDH -
Passive Optical
Network
- On-net buildings -
Greenfield - Dense
Metro area - 1Gbit/s or
greater bandwidth
requirements
- Highest bandwidth -
Noise immunity -
Security - Long reach -
SONET/SDH leverage
existing - Growth
potential via xWDM
Ethernet
over PDH
- Bonded T1/E1 -
DS3/E3 and
bonded DS3/E3
- Remote branch
offices - Off-net
customer locations
(out of region, type 2)
- SMB
- Leverage existing
transport - Universally
deployable - Lower
CAPEX - No reach
limitations - Well
understood provisioning
- Resiliency through
bonding
Ethernet
over
Copper
- 2BASE-TL -
10PASS-TS
- Remote branch
offices - On-net or off-
net - SMB - Campus
settings - Traffic
monitoring
- Ubiquitous copper
availability - Rapid
deployment - Low cost
unbundled local loop -
Resiliency through
IEEE 802.16
Technologies
Send Feedback
Name:
Email:
Comments
Send Feedback
bonding
Wireless
Ethernet
- Terrestrial
microwave -
WiMAX -
Broadband
wireless - Free
space optics -
WiFi
- Remote branch office
- Campus setting - No
fiber or copper
available - Mobility
required
- Installation requires
no trenching - Rapid
deployment - Some
alternatives offer
mobility
Hybrid
Fiber Coax DOCSIS 2.x/3.x
- Work at home -
SOHO/SMB - Remote
branch office
- Extensive coverage -
High performance
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
Ethernet over Active Fiber
10 Mbps, 100 Mbps, 1 Gbps, 10 Gbps, 40 Gbps
and above
Ethernet over PON
1 Gbps with EPON 1.25 Gbps upstream & 2.5
Gbps downstream with GPON
Ethernet over SONET/SDH 155 Mbps to 1 Gbps
Ethernet over
HFC/DOCSIS
Up to 100 Mbps with DOCSIS 3.0
Ethernet over DSL
Minimum of 2 Mbps using G.SHDSL Minimum of
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
Microwave
1 Mbps to >1Gbps
Ethernet over WiMax <70Mbps at 50km (31 mile)

Home About Contact
Technologies
Examples
When investigating access technologies for a specific scenario, the following
considerations should be taken:
Existance of legacy lines
Availability of fiber
Required bandwidth
Requirement for symmetric or mainly downlink bandwidth
Resiliency requirements
Long or short reach
Need to support TDM circuits
Use case 1
When planning Carrier Ethernet service for a small office/home office (SoHo)
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.
A higher symmetrical bandwidth service would be offered via direct active
fiber.
Use case 2
In this Section
Access Technologies
3.1.1 HFC (DOCSIS)
3.1.2 PON
3.1.3 Packet Radio
3.1.4 PDH
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
Technologies
Technologies
IEEE 802.3

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
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
not feasible from a cost and time perspective. More probable options include
Ethernet over bonded copper, or wireless Internet access services through
WiMAX or LTE technologies.
Use case 3
A remote farm requires services for enabling video delivery and weather
information. Since the requirement is for high bandwidth of 20 Mbps, the
solution would be packet microwave which is ideal for remote locations. Such
rates would exclude 3G/CDMA access, leaving WiMax or Point-to-Point
microwave as possible alternatives.
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
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
Technology
Service
Provider
Application
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
IEEE 802.16
Technologies
Send Feedback
Name:
Email:
Comments
Send Feedback
measurement
500kbps Wireless Broadband
Wireless
Wireless
Operator
Hydrological pressure
measurement
10Mbps Copper T1 Ethernet over
Bonded T1
ILEC Air quality measurement
150Mbps Fiber Ethernet over
SONET
CLEC Remote imaging and
chemical analysis
2Mbps Copper -
Coaxial
HFC/DOCSIS MSO Chemical analysis
500Mbps Fiber Direct 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
Home About Contact

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

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Home About Contact

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

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Home About Contact

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.

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Home About Contact

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.

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Home About Contact
Test Objectives 3 1
Carrier Ethernet 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
and Ethernet over PON.
3.2 Describe the advantages of specific Carrier Ethernet Access technologies.
3.3 Given a scenario, identify which Carrier Ethernet Access Technology will
meet the stated requirements.
In this Section
Access Technologies
3.1.1 HFC (DOCSIS)
3.1.2 PON
3.1.3 Packet Radio
3.1.4 PDH
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
Technologies
Technologies
IEEE 802.3

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
IEEE 802.16
Technologies
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Subscribers, Service Providers and Operators
The basic model described in MEF 10 for Ethernet services is of a Subscriber
being the end user for the service (which can be an enterprise, an application
service provider, SME, etc) contacting a Service Provider who manages and
operates a Carrier Ethernet Network (CEN) for delivery of Ethernet services.
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
(CIR) and Excess Bandwidth (EIR). The Service Provider then offers the
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
contracts with the Subscriber for delivery of service per the service
requirements specified by the subscriber. The commitment of the SP is
specified in the Service Level Agreement (SLA) which defines the service,
billing, support and maintenance.
Operators
MEF 26 expands the basic model (described in MEF 10) to facilitate the cases
where the service spans multiple CENs operated by different administrative
entities.
Each CEN is managed by an Operator where the Operator provides
connectivity services to the Service Provider that in turn provides the UNI-to-
In this Section
Ethernet
and Operators
(MEN)
4.3 Service Models
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 13
MEF 26.1
Send Feedback
Name:

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
UNI (end-to-end service) to the Subscriber (as described in the MEF 10
model)
The Service Provider is in charge of assembling and managing the UNI-to-UNI
service. This includes aspects of the service such as billing, technical support,
performance monitoring and reporting to the subscriber.
This model is illustrated below.
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.

Email:
Comments
Send Feedback
Home About Contact
EVC, OVC, UNI, ENNI and CEN (MEN)
Definition of UNI, UNI-N and UNI-C per MEF 10.2
This section describes the basic constructs and definitions of Ethernet
services.
The User Network Interface (UNI) is the physical interface or port that is the
demarcation between the Subscriber and the Service Provider.
The network that provides the Ethernet services is called the Carrier Ethernet
Network (CEN). Note that some earlier MEF specifications refer to CEN as MEN
(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.

The basic service model as described in MEF 10.2 is depicted below:
Figure 4.2.F1 - Basic Service Model per MEF 10.2
[Source: MEF 10.2 Figure 1]
The UNI is the demarcation point where the Customer Edge (CE) connects to
In this Section
Ethernet
and Operators
(MEN)
4.3 Service Models
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 13
MEF 26.1
Send Feedback
Name:

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
the network.
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
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.
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
Email:
Comments
Send Feedback
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
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.

Home About Contact
Service Models
The MEF 26 Service Model
MEF 26 expands the basic model described in MEF 10 to facilitate those cases
where the service spans multiple CENs which are operated by different
administrative entities.
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)
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.
This model is illustrated below.
Figure 4.3.F1 - MEF 26 Model
The Operator may have only limited knowledge of the UNI-to-UNI service, or
may know nothing at all about it in the case of the Operator that provides
transit CENs for several services.
In this Section
Ethernet
and Operators
(MEN)
4.3 Service Models
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 13
MEF 26.1
Send Feedback
Name:

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Note that the Service Provider may well also be an Operator of a CEN. In such
cases, the Service Provider/Operator contacts another CEN operator in order
to extend the Service Provider's reach to locations outside the Service
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.
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.

Email:
Comments
Send Feedback
Home About Contact

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
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Download
Home About Contact

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."
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Download
The MEF has prepared an overview presentation which explains the MEF 13 Implementation Agreement.
Download
Home About Contact

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 interface 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 including Link OAM.
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
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
Download
Home About Contact
Test Objectives 4 1
Basic Definitions
4.1 Define Ethernet User-to-Network Interface (UNI), Ethernet External
Network-to-Network Interface (ENNI), Ethernet Virtual Connection (EVC),
Service Provider, Operator, and Operator Virtual Connection (OVC).
4.2 Describe the role of Ethernet User-to-Network Interface (UNI), Ethernet
External Network-to-Network Interface (ENNI), Ethernet Virtual Connection
(EVC), Service Provider, Operator, and Operator Virtual Connection (OVC).
In this Section
Ethernet
and Operators
(MEN)
4.3 Service Models
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 13
MEF 26.1
Send Feedback
Name:

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Email:
Comments
Send Feedback
Home About Contact
This page is intentionally left blank.
In this Section
Services
5.1
5.2 UNI Attributes
5.4 EVC Attributes
5.4.1 L2CP per MEF 6.1.1
5.5 ENNI Attributes
5.6 OVC Attributes
Attributes
5.9
Download PDF
Download a pdf for
offline viewing.
Reference Documents

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
MEF 6.1
MEF 10.2
MEF 13
MEF 20
MEF 26.1
IEEE 802.1AX
Service Attributes
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
[15:33:56] Susan Bud:
UNI Service Attributes
This topic area describes the various UNI service attributes as specified in
section 7 of MEF 10.2.
The entire list of parameters is shown on table 3 of MEF 6.1.
These are the service attributes that are independent of the EVCs connecting
this UNI with other UNIs.
It should be noted that 2 UNIs connected with an EVPL service may have some
of their UNI attributes set differently.
In this Section
Services
5.1
5.2 UNI Attributes
5.4 EVC Attributes
5.4.1 L2CP per MEF 6.1.1
5.5 ENNI Attributes
5.6 OVC Attributes
Attributes
5.9
Download PDF
Download a pdf for
offline viewing.
Reference Documents

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Table 5.2.T1 - UNI Service Attributes
[Source: MEF 6.1, Table 3]

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

Physical Interface
The UNI speed can be 10 Mbps, 100 Mbps, 1 Gbps or 10 Gbps. The Mode MUST
be set to Full Duplex.
Essentially, all PHYs defined by IEEE 802.3-2005 are supported with the
exceptions of 1000BASE-PX-D and 1000BASE-PX-U, since Link OAM is not
supported for these PHYs.
UNI Type 1 supports only a sub-set of the list. Please refer to MEF 13 for
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
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
MEF 6.1
MEF 10.2
MEF 13
MEF 20
MEF 26.1
IEEE 802.1AX
Service Attributes
Send Feedback
Name:
Email:
Comments
Send Feedback
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
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
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.

Home About Contact
EVC per UNI Service Attributes
EVC-related attributes are divided into two groups:
1. EVC per UNI Attributes these are attributes that can be set differently
for each UNI associated with the EVC
2. EVC Attributes these are general attributes that define the EVC and
its behavior and apply on all UNIs associated with the EVC

UNI EVC ID
A string formed by the concatenation of the UNI ID and the EVC ID.

CE-VLAN ID / EVC Map
The map defines which value(s) of CE-VLAN ID are mapped to each of the
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
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
frame is associated.
In this Section
Services
5.1
5.2 UNI Attributes
5.4 EVC Attributes
5.4.1 L2CP per MEF 6.1.1
5.5 ENNI Attributes
5.6 OVC Attributes
Attributes
5.9
Download PDF
Download a pdf for
offline viewing.
Reference Documents

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
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
by the Service Provider.
More than one CE-VLAN ID can be mapped to an EVC only if Bundling is set to
Yes at that UNI.
Any value of CE-VLAN ID not assigned to an EVC at a UNI must be dropped.
Figure 5.3.F1 - Mapping CE-VLAN IDs to EVCs
[Source: MEF 10.2, Figure 9]
An example of a map is given below:
Figure 5.3.T1 - Mapping CE-VLAN IDs to EVCs
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

MEF 6.1
MEF 10.2
MEF 13
MEF 20
MEF 26.1
IEEE 802.1AX
Service Attributes
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
EVC 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
manner for a given service type. MEF 6.1 details the possible values for each
of the 6 service types.
EVC Type
Defines the service type - namely:-
Point-to-Point
Multipoint-to-Multipoint
Rooted-Multipoint
Note that Private/Virtual is deduced by the UNI attributes.

EVC ID
An arbitrary string - unique across the CEN - for the EVC supporting the
service instance.

UNI List
The UNI List for an EVC is a list of pairs of the form <UNI Identifier, UNI
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
In this Section
Services
5.1
5.2 UNI Attributes
5.4 EVC Attributes
5.4.1 L2CP per MEF 6.1.1
5.5 ENNI Attributes
5.6 OVC Attributes
Attributes
5.9
Download PDF
Download a pdf for
offline viewing.
Reference Documents

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
must be Root.

Maximum Number of UNIs
Any integer 2 is allowed. It must be 2 for Point-to-Point EVC.

EVC Maximum Transmission Unit Size
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
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
to the EVC.
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
Ethernet) provides connectivity between devices that have a Fiber Channel
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
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.
MEF 6.1
MEF 10.2
MEF 13
MEF 20
MEF 26.1
IEEE 802.1AX
Service Attributes
Send Feedback
Name:
Email:
Comments
Send Feedback
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
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.

Home About Contact
L2CP per MEF 6.1.1
This section expands on the EVC L2CP handling rules.
L2CP Processing Requirements for Service Frames with a MAC DA in the
range of 01-80-C2-00-00-00 to -0F
The action (tunnel, peer, or discard) for each L2CP Service Frame is
decided using a two-step logic based on the frame's:
1. MAC DA
2. Ethertype and subtype or LLC code (that is, based on the protocol)
The logic for processing of the L2CP Service Frames is presented in the
following Flow Chart:
In this Section
Services
5.1
5.2 UNI Attributes
5.4 EVC Attributes
5.4.1 L2CP per MEF 6.1.1
5.5 ENNI Attributes
5.6 OVC Attributes
Attributes
5.9
Download PDF
Download a pdf for
offline viewing.
Reference Documents

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page

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

STEP 1
Step 1 in the handling logic means that depending on the service type,
specific MAC DA's must be tunneled through the EVC.
For private services - EPL (non-transparent option), EP-LAN and EP-Tree -
which are delivered over a packet-aware network (e.g. IEEE 802.1 or MPLS
based) the following table applies:
Figure 5.4.1.T1 - L2CP Handling for Private Service
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)

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:
MEF 6.1
MEF 10.2
MEF 13
MEF 20
MEF 26.1
IEEE 802.1AX
Service Attributes
Send Feedback
Name:
Email:
Comments
Send Feedback
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

Home About Contact
ENNI 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
the set can have an identical value for each Operator while another attribute
can have a different value for each Operator. The ENNIs are illustrated below:
Figure 5.5.F1 - Operator to Operator ENNI
Operator ENNI Identifier
A unique text string identifying this ENNI within the CEN to which it belongs.
It can be up to 45 bytes long.

Physical interface, frame format
Each link in an ENNI MUST be one of the following physical layers in full
duplex mode as defined in IEEE Std 802.3 2005 : 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 CEN can be different than the physical layer at
another ENNI supported by the Operator CEN.
In this Section
Services
5.1
5.2 UNI Attributes
5.4 EVC Attributes
5.4.1 L2CP per MEF 6.1.1
5.5 ENNI Attributes
5.6 OVC Attributes
Attributes
5.9
Download PDF
Download a pdf for
offline viewing.
Reference Documents

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Each ENNI Frame MUST have the standard Ethernet format with one of the tag
configurations specified in the table below. [DA = Destination Address, SA =
Source Address, ET = Ethertype/Length, S-Tag with Tag Protocol Identification
Field (TPID) = 0x88A8, C-Tag with TPID = 0x8100.]
Figure 5.5.T1 - ENNI Frame Tags
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)
Number of Links
Specifies the number of physical links at the ENNI. The value can be 1 or 2.
2 are used when resiliency is implemented.
ENNI Resiliency
The Protection Mechanism defines the resiliency scheme at the ENNI. There
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
MEF 6.1
MEF 10.2
MEF 13
MEF 20
MEF 26.1
IEEE 802.1AX
Service Attributes
Send Feedback
Name:
Email:
Comments
Send Feedback
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.

Home About Contact
OVC Attributes
This section describes the OVC service attributes.

OVC ID
A string of at most 45 bytes that uniquely identifies the OVC within a given
CEN.

OVC type
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
Multipoint-to-Multipoint. An OVC that associates exactly two 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 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.

OVC End Point List
A list of OVC End Point Identifiers.

In this Section
Services
5.1
5.2 UNI Attributes
5.4 EVC Attributes
5.4.1 L2CP per MEF 6.1.1
5.5 ENNI Attributes
5.6 OVC Attributes
Attributes
5.9
Download PDF
Download a pdf for
offline viewing.
Reference Documents

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
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. This must be an integer greater or equal to 0.

Maximum Number of ENNI OVC End Points
A list of OVC End Point Identifiers. 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. This must be an integer greater or
equal to 1.

OVC Maximum Transmission Unit Size
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
the ENNI MTU size. When an ENNI frame is larger than the OVC MTU that is
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
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
Note: This handling is required when OVC CE-VLAN ID Preservation is set to
MEF 6.1
MEF 10.2
MEF 13
MEF 20
MEF 26.1
IEEE 802.1AX
Service Attributes
Send Feedback
Name:
Email:
Comments
Send Feedback
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
(*) 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

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.

Home About Contact
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 behavior is possible when an OVC associates two or more
OVC End Points at a given ENNI.
Hairpin switching provides value in several scenarios.
One example is where an Operator supplying a Service Provider with a
tunneling service (e.g. E-Access) does not have suitable Carrier Ethernet
switching capability available in its own network. Therefore the tunnel service
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
ENNI (Service Provider CEN - Operator CEN) towards a different UNI attached
to the Operator CEN. In this example, the Service Provider CEN provides the
switching capability between the Operator's two UNIs facing the Subscriber.
Note that hairpin switching cannot occur at a UNI.
The concept of hairpin switching is illustrated in the following figure:

In this Section
Services
5.1
5.2 UNI Attributes
5.4 EVC Attributes
5.4.1 L2CP per MEF 6.1.1
5.5 ENNI Attributes
5.6 OVC Attributes
Attributes
5.9
Download PDF
Download a pdf for
offline viewing.
Reference Documents

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Figure 5.6.1.F1 - Hairpin Switching
In order to facilitate hairpin switching the concept of OVC end points in
introduced.
The figure below shows an example of the use of OVC End Points for Hairpin
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
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 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
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
will be followed by a Service Frame sent from UNI Ab to UNI Aa.

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.

MEF 6.1
MEF 10.2
MEF 13
MEF 20
MEF 26.1
IEEE 802.1AX
Service Attributes
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
OVC End Point per ENNI
There are service attributes for each instance of an OVC End Point at a given
ENNI.
OVC End Point Identifier
The OVC End Point Identifier is a string of up to 45 bytes administered by the
Operator that is used to identify an OVC End Point within a given CEN. The
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.
CoS ID
A Class of Service Identifier is a set of one or more S-Tag PCP values. Each
Class of Service Identifier indicates a single Class of Service instance. The Class
of Service 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 different 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 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
One CoS ID can be set to 100% discard
In this Section
Services
5.1
5.2 UNI Attributes
5.4 EVC Attributes
5.4.1 L2CP per MEF 6.1.1
5.5 ENNI Attributes
5.6 OVC Attributes
Attributes
5.9
Download PDF
Download a pdf for
offline viewing.
Reference Documents

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
CoS ID can have different maps between different OVC end points, as
long as they are associated with different OVCs
Frame color can be marked in one of two methods: DEI bit or S-tag PCP
values. According to MEF 23, the following values are recommended for a 3
CoS model:
For green color or when color is marked using DEI bit:
Figure 5.7.T1 - H, M, L - Green Color
For yellow color or when color is marked using PCP bits:
Figure 5.7.T2 - H, M, L - Yellow Color

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
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:
MEF 6.1
MEF 10.2
MEF 13
MEF 20
MEF 26.1
IEEE 802.1AX
Service Attributes
Send Feedback
Name:
Email:
Comments
Send Feedback
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.

Home About Contact
Bandwidth Profiles
Concept
A Bandwidth Profile (BWP) enforces the utilization of bandwidth according to
the Service Level Specification that has been agreed upon by the Subscriber
and Service Provider. It can be thought of as enforcing the long term average
guaranteed bandwidth (CIR) and excess bandwidth (EIR) allowed by the
service. CIR (Committed Information Rate) is the bit rate for which the SP
provides performance guarantees in terms of performance attributes for the
service. EIR (Excess Information Rate) is the additional bit-rate that the
subscriber can utilize and for which traffic can probably pass through the CEN
as long as there is no congestion. Note that the total rate, sometimes known
as PIR (Peak Information Rate), is the sum of CIR and EIR. The BWP classifies
the service frames into 3 "colors" each denoting a certain compliance level:
Green Frames within the CIR / CBS compliance level. These frames
are subject to the SLS.
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
congestion conditions in the network.
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 .
There are two types of bandwidth profiles:
In this Section
Services
5.1
5.2 UNI Attributes
5.4 EVC Attributes
5.4.1 L2CP per MEF 6.1.1
5.5 ENNI Attributes
5.6 OVC Attributes
Attributes
5.9
Download PDF
Download a pdf for
offline viewing.
Reference Documents

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Ingress Bandwidth Profile limits the rates of frames entering the
CEN.
Egress Bandwidth Profile limits the rate of frames egressing the CEN
and thus protecting overload towards the egress CE.
Bandwidth Profile can be applied in three forms:
Per UNI
Per EVC
Per CoS ID per EVC
However, the algorithm is the same for all three forms.
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
cannot define an ingress BWP per UNI in addition to an ingress BWP per EVC.
The three BWP forms are illustrated below:
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:
MEF 6.1
MEF 10.2
MEF 13
MEF 20
MEF 26.1
IEEE 802.1AX
Service Attributes
Send Feedback
Name:
Email:
Comments
Send Feedback
Figure 5.8.F5 - Egress Bandwidth Profile per EVC
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.
Home About Contact
This page is intentionally left blank.
In this Section
Services
5.1
5.2 UNI Attributes
5.4 EVC Attributes
5.4.1 L2CP per MEF 6.1.1
5.5 ENNI Attributes
5.6 OVC Attributes
Attributes
5.9
Download PDF
Download a pdf for
offline viewing.
Reference Documents

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
MEF 6.1
MEF 10.2
MEF 13
MEF 20
MEF 26.1
IEEE 802.1AX
Service Attributes
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
EVC Performance 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
Inter-Frame Delay Variation
Frame Loss Ratio
Availability
The Performance attributes are per CoS ID. They must be specified for at
least one CoS ID, but some of the attributes can be set to N/S (Not
specified).
In general, all service performance attributes are measured during some time
interval T (e.g. 5 minutes, 2 hours, etc.).
Service performance is measured between an ordered pair of UNIs.
For E-Line, there are 2 ordered pairs (UNI1, UNI2) and (UNI2, UNI1).
For E-LAN and E-Tree, measurement can be performed on any sub-set of the
ordered pairs.
For E-Tree, each pair must include at least one root UNI.
Frames are counted against the performance attribute only if they meet all
the following criteria:
In this Section
Services
5.1
5.2 UNI Attributes
5.4 EVC Attributes
5.4.1 L2CP per MEF 6.1.1
5.5 ENNI Attributes
5.6 OVC Attributes
Attributes
5.9
Download PDF
Download a pdf for
offline viewing.
Reference Documents

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
The egress frame results from an ingress frame where both UNIs
(ingress and egress) belong to the ordered set.
The first bit of the frame must arrive to the egress UNI during the
time interval T.
The ingress BWP had compliance level of green.
Note that Unicast, Multicast, Broadcast and L2CP frames can all be used for
performance measurement.
One-way Frame Delay
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 below.
Figure 5.10.F1. - One way frame delay
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 (IFDV) is the difference between the one-way
MEF 6.1
MEF 10.2
MEF 13
MEF 20
MEF 26.1
IEEE 802.1AX
Service Attributes
Send Feedback
Name:
Email:
Comments
Send Feedback
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.
Home About Contact

MEF 20
User Network Interface (UNI) Type 2 Implementation Agreement

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
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
The MEF has prepared an overview presentation which explains the MEF 20 Implementation Agreement.
Download
Home About Contact

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.

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Home About Contact

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.

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Home About Contact
Test Objectives 5 1
Key UNI, ENNI, OVC, and EVC Service Attributes
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.2 Define EVC per UNI service attributes (e.g. ingress/egress Bandwidth
Profiles).
5.3 Define per EVC service attributes (e.g., CE-VLAN ID Preservation, CoS ID
Preservation, Relationship between Service Level Agreement and Service Level
Specification, Class of Service).
5.4 Define OVC End Point per ENNI service attributes (e.g., ingress/egress
bandwidth profiles).
5.6 Given a service scenario, describe relevant service attribute
settings/parameters.
5.7 Define and describe the components of a Service Level Specification and
the relationship to Service Level Agreement.
5.8 Define and describe ENNI attributes (e.g., physical interfaces, Frame
format, Ingress/egress Bandwidth Profiles, End Point Map, ENNI protection).
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).
5.10 Define and describe the Carrier Ethernet protection mechanisms.
In this Section
Services
5.1
5.2 UNI Attributes
5.4 EVC Attributes
5.4.1 L2CP per MEF 6.1.1
5.5 ENNI Attributes
5.6 OVC Attributes
Attributes
5.9
Download PDF
Download a pdf for
offline viewing.
Reference Documents

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
MEF 6.1
MEF 10.2
MEF 13
MEF 20
MEF 26.1
IEEE 802.1AX
Service Attributes
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
The MEF Certification Program comprises three parts:-
MEF Services Certification Program
MEF Equipment Certification Program
MEF Professional Certification Program
The purpose of these three certification programs is to provide the
Subscribers, Service Providers and Operators with a neutral reference point for
compliance with and knowledge of Carrier Ethernet specifications.
MEF Certification in Subscriber RFPs
Subscribers (e.g. enterprises, governmental organizations, health and
educational facilities) are buying more and more Carrier Ethernet services
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
point in the selection process of suppliers of Carrier Ethernet services.
MEF Certification in Service Provider and Operator RFPs
MEF Certification enables Service Providers and Operators to go to market wit
Carrier Ethernet services certified as being compliant with MEF specifications
to support the following market requirements:
Subscribers demand of Service Providers that services be predictable in terms
of service functionality and performance. MEF certification increases the
confidence of Subscribers that services offered to them do meet functionality
and performance requirements.
Services RFPs need to be less complex. MEF certification (e.g. MEF 9 and MEF
14) in an RFP replace longform descriptions of Subscriber requirements.
In this Section
Ethernet
Plans
Download PDF
Download a pdf for
offline viewing.
Reference Documents
6 MEF Certification
Send Feedback
Name:
Email:

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Services certification also streamlines the interconnection services between
different Service Providers and Operators.
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
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.

Comments
Send Feedback
Home About Contact
Services
Definitions, Implementation Agreements, Abstract Test Suites and Plans
The MEF produces three types of technical documents:
Technical Specifications (TS)
The TS includes architectural and abstract models required to create a robust
platform of technical requirements and defintions. TSs are the principal
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.
Implementation Agreements (IA)
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
MEF 20 and MEF 23.
Abstract Test Suites (ATS)
The ATS comprises a series of tests to be used to measure conformance to
specific MEF specifications - which can be Technical Specifications or
Implementation Agreements. The purpose of the ATS is to form the basis of
test plans such as those used in the MEF Certification Programs. Examples of
ATSs include MEF 9, MEF 14 and MEF 18
Test Plan
In this Section
Ethernet
Plans
Download PDF
Download a pdf for
offline viewing.
Reference Documents
6 MEF Certification
Send Feedback
Name:
Email:

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
The MEF Certification Test Lab uses one or more ATSs to create a separate
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
Certification Test Lab will receive the Test Plan as part of the preparation
process before undertaking the certification test.

Comments
Send Feedback
Home About Contact
Services
Testing and Certification Process
Requirements from Equipment Vendor
An Equipment Vendor can apply to have a service or device certified by the
MEF Certification Test Lab if it is a MEF member in good standing. The MEF
member approaches the MEF approved test lab (Iometrix) at
certification@iometrix.com for more information on pricing and scheduling.
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
and to approve the Test Plan developed by Iometrix.
Equipment Vendor Testing Process
Test plans, configuration guides and engineering support are made available
by Iometrix to Equipment Vendors at all stages of the vendor's preparation for
certification testing.
Testing takes place at the Iometrix facilities in San Francisco, California or
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.
Vendors are requested to provide on-site engineering support to configure
equipment and resolve exceptions that may arise during the course of testing.
In this Section
Ethernet
Plans
Download PDF
Download a pdf for
offline viewing.
Reference Documents
6 MEF Certification
Send Feedback
Name:
Email:

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Vendors are responsible for the delivery of all components to be tested and
Iometrix supplies all test equipment and software.
Requirements from Service Provider
A preliminary technical review is conducted by Iometrix to assess the
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.

Comments
Send Feedback
Home About Contact
Services
Certification for Service Providers
Carrier Ethernet 1.0 (MEF 9 and MEF 14)
Service provider members of the MEF seeking to certify one or more of their
EPL, EVPL and E-LAN services as conforming to MEF 9, MEF 14 and/or MEF 18
specifications within the Carrier Ethernet 1.0 generations framework can apply
to the MEF Certification Test Lab (Iometrix) to schedule and prepare for
independent, streamlined testing of their service(s).
The testing and certification in Carrier Ethernet 1.0 (MEF 9 and MEF 14) is
based on a 'Certification by ATS' model. This means that a single ATS is 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 and E-LAN.
To date, over 60 Service Providers have certified well over 200 Carrier
Ethernet services as conforming with MEF 9 and/or MEF 14.
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
certification transitions the industry from 'Certification by ATS' to
'Certification by Service'. Instead of certifying a service as conforming to a
particular MEF ATS, the certification verifies that the service conforms to the
In this Section
Ethernet
Plans
Download PDF
Download a pdf for
offline viewing.
Reference Documents
6 MEF Certification
Send Feedback
Name:
Email:

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
relevant sections of a range of Abstract Test Suites as described in the Carrier
Ethernet 2.0 Certification Blueprint.
Key Words
MEF 9; MEF 14; ATS; E-Line; E-LAN; E-Tree; E-Access

Comments
Send Feedback
Home About Contact
Services
Certification for Equipment Vendors
Carrier Ethernet 1.0 (MEF 9, MEF 14 and MEF 18)
Equipment vendor members of the MEF seeking to certify one or more of their
equipment products as conforming to MEF 9, MEF 14 and/or MEF 18
specifications within the Carrier Ethernet 1.0 generations framework can apply
to the MEF Certification Test Lab (Iometrix) to schedule and prepare for
independent, streamlined testing of their product(s).
The testing and certification in Carrier Ethernet 1.0 (MEF 9, MEF 14 and MEF
18) is based on a 'Certification by ATS' model. This means that a single ATS is
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
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
emulation of TDM circuits over Carrier Ethernet networks.
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.
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
In this Section
Ethernet
Plans
Download PDF
Download a pdf for
offline viewing.
Reference Documents
6 MEF Certification
Send Feedback
Name:
Email:

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
certification transitions the industry from 'Certification by ATS' to
'Certification by Service'. Instead of certifying a product as conforming to a
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.
Key Words
MEF 9; MEF 14; MEF 18; ATS; E-Line; E-LAN; E-Tree; E-Access
Comments
Send Feedback
Home About Contact
Test Objectives 6 1
Certification
6.1 Describe the Certification process and requirements for networking
equipment.
6.2 Describe the Certification process and requirements for services delivered
by a service provider.
6.3 Describe what is covered by MEF 9, MEF 14, and MEF 18 Certifications.
6.4 Describe the benefits of MEF Certification for equipment vendors, Service
Provider, and end users.
In this Section
Ethernet
Plans
Download PDF
Download a pdf for
offline viewing.
Reference Documents
6 MEF Certification
Send Feedback
Name:
Email:

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Comments
Send Feedback
Home About Contact
Ethernet Services
Access to IP Services
Many of today's enterprise applications are transported using IP. This can be
any Internet application but especially relevant are applications and content
consumption from application content providers (e.g. VoIP gateway, video
content, etc.). Subscribers to a CEN Service Provider can take advantage of
the benefits of Carrier Ethernet services when consuming IP services.
When connecting to the Internet, the CEN can provide the connectivity
required to the ISP's POP facilitating any required bandwidth with the
granularity, manageability and service performance supported by Carrier
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
benefits to the Subscribers is that the same CEN Service Provider that provides
services for corporate interconnectivity can also provide the Internet
connectivity.
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
each subscriber is designated as a leaf ensuring that each subscriber's
traffic cannot be seen by other subscribers.
The EVPL is simpler from an implementation point of view, but has scalability
issues, requiring many EVPLs. Also, the bandwidth is not shared between
In this Section
Ethernet Services
7.3 Mobile Backhaul
Replacement
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 6.1
MEF 8
MEF 10.2

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
subscribers, which may be a problem for large deployments in view of the
fact that Internet access is often bursty and used at different times of the
day by different subscribers.
In the following example an ISP named Turbo 2000 Internet Access Inc. is
connected to three enterprises for Internet Access. Each customer connects to
the ISP's POP using EVPL with CE-VLAN ID of 2000. This enables the customer
to use the same UNI port for other services (e.g. Disaster Recovery, L2VPN,
etc.) using different CE-VLAN ID(s).
Figure 7.1.F1: Example - Turbo 2000 Internet Access, Inc.
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
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:
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

MEF 26.1
MEF 28
Technologies
Backhaul
Ethernet Services
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Ethernet Services
Wholesale Access Services
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
tunnel service from an Access Service Provider. The latter may not be a full
CEN Operator, but rather a simplified service where the Access SP provides
such service utilizing a relatively simple device, often referred to as a NID
(Network Interface Device). This NID is typically co-located at the End-User's
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
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
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
UNI-N functions are implemented at the VUNI, while the RUNI functionality is
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
mapped to different EVCs based on the UNI CE-VLAN ID/EVC map.
The following figure illustrates this service set-up:
In this Section
Ethernet Services
7.3 Mobile Backhaul
Replacement
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 6.1
MEF 8
MEF 10.2

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Figure 7.2.F1

UTA Service Attributes
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
mapped to the tunnel. L2CP rules must tunnel all protocols in order to
provide the highest level of transparency possible.
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
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
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.
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.

MEF 26.1
MEF 28
Technologies
Backhaul
Ethernet Services
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Ethernet Services
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
Controller = RNC, S-GW). This network is called the Radio Access Network
(RAN) by the 3GPP. Mobile backhaul networks have traditionally been realized
using TDM and ATM technologies. However, next generation mobile equipment
and networks are based on Ethernet. Carrier Ethernet services provide the
connectivity in the mobile backhaul network, possibly in a converged network,
together with traditional fixed services. Ethernet is becoming increasingly
available, even at sites with access to legacy services. This opportunity allows
mobile operators to make the choice of which transport technology to utilize.
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
constellation of forms depending on factors such as transport technology,
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
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
site composed of several network controllers including: OSS, WCDMA Radio
Network Controller, S-GW or synchronization server. A RAN BS may also be a
single base station or a collection of several base stations. Multiple RAN NCs
In this Section
Ethernet Services
7.3 Mobile Backhaul
Replacement
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 6.1
MEF 8
MEF 10.2

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
and RAN BSs can be connected to the CEN at any given time.
Figure: 7.3.F1
[Source: MEF 22, Figure 1]
More complex scenarios involving multiple CEN domains are possible. Note
that the CEN SP provides a service to a mobile operator and not to end users
(mobile users).
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-
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
Carrier Ethernet services:
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.
The EVPL approach is illustrated in the following figure:
Figure: 7.3.F2
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
The mobile network has several classes of service for different applications
that use the network. The following table describes MEF 22 recommended
MEF 26.1
MEF 28
Technologies
Backhaul
Ethernet Services
Send Feedback
Name:
Email:
Comments
Send Feedback
mapping between the 3GPP classes and the CEN CoSs:
Table: 7.3.T1
[Source: MEF 22, Table 2]
Home About Contact
Ethernet Services
TDM Private Line Replacement
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
SONET/SDH networks. In these services, each location has a PBX connected via
an E1/T1 (or bundled E1/T1 for increased bandwidth) to an ADM switch of the
SONET/SDH network.
For example, in the following figure we see a Private Line service providing 2
Mbps between 2 PBXs.
Figure 7.5.F1 - PBX over legacy PDH and SONET
E-Line is the modern solution for connecting PBXs and supports replacement
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.
The solution is implemented by implementing a CESoETH service between the
two locations.
In this Section
Ethernet Services
7.3 Mobile Backhaul
Replacement
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 6.1
MEF 8
MEF 10.2

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Figure 7.5.F2 - PBX over Carrier Ethernet
The service can be provided using EPL or EVPL. EVPL allows the Service
Provider to offer another communication service (e.g. L2VPN) for the
customer utilizing the same UNI port.
In order to provide the required bandwidth, the service should offer the
following:
CIR=2 Mbps, CBS=10,000 bytes, EIR=0, EBS=0
Performance objectives: Frame Delay, Inter-Frame Delay Variation and Loss
Ratio to ensure low loss rate and minimal delay variation.

MEF 26.1
MEF 28
Technologies
Backhaul
Ethernet Services
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Ethernet Services
Frame Relay/ATM Replacement
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
transport protocols (IP, TDM, etc.) over virtual circuits. However, these
services are often highly bandwidth constrained and are relatively expensive.
Furthermore, they mainly provide point-to-point connectivity (although some
ATM networks support Ethernet L2VPN using technologies like LAN Emulation
(LANE).
The following figure describes such a scenario where an enterprise connects
its 3 locations over 3 point-to-point circuits from a WAN service provider who
operates an ATM or FR network:
Figure 7.6.F1 - Legacy ATM-FR
In this set-up, each Network Edge at each location would have an ATM or FR
interface(s) pointing towards the WAN provider. For the sake of this example,
we can assume that each circuit provides 2 Mbps guaranteed bandwidth
In this Section
Ethernet Services
7.3 Mobile Backhaul
Replacement
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 6.1
MEF 8
MEF 10.2

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
between each location.
The need for more bandwidth at a lower price, and with a more sophisticated
and dynamic service provisioning, presents the opportunity for a Carrier
Ethernet Service Provider to offer a very attractive alternative.
The customer can buy one of the following two services and replace the
current Network Edge with a switch/Customer Edge:
1. 3 EVPLs, each having ingress BWP per EVC with CIR=2 Mbps, CBS=20
Kbytes and possibly also allowing for some additional traffic using EIR=2
Mbps, EBS=20 Kbytes
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
Internet access. For this reason, the Service Provider facilitates the
addition of new Carrier Ethernet services over the same UNI.
The first alternative is depicted below, where a site requires a single UNI port
for the 2 EVPLs:
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.

MEF 26.1
MEF 28
Technologies
Backhaul
Ethernet Services
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Ethernet Services
EVPL in 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
configurations:
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
UNI-N and at the RAN BS UNI-N to the EVC connecting the RAN BS and
RAN NC. This implies that each RAN NC UNI can distinguish up to four
thousand distinct RAN BSs.
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
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
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
enabled and 4 classes of service are supported.
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
present use case.
In this Section
Ethernet Services
7.3 Mobile Backhaul
Replacement
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 6.1
MEF 8
MEF 10.2

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Table 7.3.1.T1 - EVC per EVP-Line
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
RAN BS UNI-C:
Option A : The CE-VLAN ID Preservation Attribute is enabled and the
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
itself. Either PCP or DSCP values specify different Classes of Service.
Option B : The CE-VLAN ID Preservation Attribute is disabled and the
RAN BS UNI-C transmits/receives untagged service frames to/from
UNI-N where they are mapped to the default CE-VLAN ID. DSCP
values specify different Classes of Service. A default mapping of
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
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
MEF 26.1
MEF 28
Technologies
Backhaul
Ethernet Services
Send Feedback
Name:
Email:
Comments
Send Feedback
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.

Home About Contact
Ethernet Services
MEF 22 Use Cases
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
scenario using Ethernet services. Although the use cases are not exhaustive of
all possible deployment scenarios, they are the foundation of the Mobile
Backhaul Implementation Agreement Phase 1 (MEF 22).
Use cases 1a and 1b below depict deployments where the RAN BS and RAN NC
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
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
connected to the UNI.
Figure 1 (7.3.2.F1) - Generic Interworking Function with Legacy MBH Network
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
types of mobile traffic. This may be appropriate in cases where an Operator
wants to offload low priority, high bandwidth traffic from the legacy network
to the CEN in order to scale according to network demand. How and where
In this Section
Ethernet Services
7.3 Mobile Backhaul
Replacement
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 6.1
MEF 8
MEF 10.2

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
traffic is split and sent over the legacy network is out of scope for this Study
Guide.
Figure 2 (7.3.2.F2) - Generic Interworking Function without Legacy Network
Figure 2 depicts a deployment scenario - Use Case 2 - where the legacy
network has been substituted by a Carrier Ethernet Network and where the
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
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
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
RAN CE transports real-time and synchronization traffic via the legacy network
is out of scope.
Figure 3 (7.3.2.F3) - UNI with MBH Legacy Network
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

MEF 26.1
MEF 28
Technologies
Backhaul
Ethernet Services
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Ethernet Services
Business Services
Carrier Ethernet for Business covers a wide variety of communication services
offered to enterprises, SMBs and corporate offices of all sizes. The following
are the areas in which high-bandwidth, low-latency and reduced-cost are
enabling and improving applications.
Site-to-site access
Data center & server consolidation
Business continuity/disaster recovery
Service orientated architecture
Software as a service
Converged networking
Carrier Ethernet provides scalable, efficient and easy to manage solutions for
enabling all of these services and applications.
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
information in batch up-loads overnight. This delayed fulfilling restocking,
resulting in the inability to quickly meet customer demand and poor
utilization of resources. Security is a constant issue, but the CCTV is
essentially an offline and reactive service.
In this Section
Ethernet Services
7.3 Mobile Backhaul
Replacement
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 6.1
MEF 8
MEF 10.2

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
The goals of the project in this use case are to increase capacity, improve
network resiliency and scalability, provide the flexibility to simplify addition
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
stock shrinkage with national central CCTV monitoring ability.
The low cost solution is based on a mixture of enabling transport technologies.
The EP-Tree service type is implemented to ensure separation between the
divisional operations under the supervision of the corporate headquarters. This
solution is based on standardized, certified, Ethernet Business Services.
The following figure depicts the solution:
Figure 7.4.F1 - Example Business Services Application
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
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
MEF 26.1
MEF 28
Technologies
Backhaul
Ethernet Services
Send Feedback
Name:
Email:
Comments
Send Feedback
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

Home About Contact
Ethernet Services
WDM Private Network Replacement
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-
bandwdith low-latency connection between its sites. Usually, these networks
are point-to-point where each router's port is connected to a specific router
port at another location.
Such a scenario is illustrated in the following figure:
Figure 7.7.F1 - 3 E-Lines replace WDM
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
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
install and manage the WDM links and also may not be feasible for long-haul
scenarios. This solution requires leasing dark fiber facilities from an Operator,
which is typically a very expensive offering, making this solution even less
In this Section
Ethernet Services
7.3 Mobile Backhaul
Replacement
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 6.1
MEF 8
MEF 10.2

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
attractive for long-haul applications. Also, this type of solution cannot scale
easily as the enterprise adds more locations.
Carrier Ethernet offers a comparable solution where all locations are
connected using an EP-LAN service, which enables the relatively simple and
fast addition of new sites as the enterprise grows. It provides the same
transparency as a WDM network and supports any-to-any communication
supporting new services like shared storage, video distribution etc.
The solution is depicted below:
Figure 7.7.F2 1 E-LAN replaces WDM
Example
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
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.
MEF 26.1
MEF 28
Technologies
Backhaul
Ethernet Services
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact

MEF 8
Implementation Agreement for the Emulation of PDH Circuits over Metro Ethernet Networks

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
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
The MEF has prepared an overview presentation which explains the MEF 8 specification.
Download
Home About Contact

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."
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Download
Download
Home About Contact

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

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Home About Contact

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

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Home About Contact
Test Objectives 7 1
Target Applications for Ethernet Services
7.1 Describe wholesale access services, retail commercial/business services,
mobile backhaul services, Ethernet access to IP services, and supporting
legacy services over Ethernet.
7.2 Describe which UNI or ENNI attribute values are selected for a given target
application.
7.3 Describe which EVC or OVC attribute values are selected for a given target
application.
7.4 Describe how specific service requirements of a target application (e.g.,
frame relay, Dedicated Internet Access, DSL or Cable Internet access, TDM
Private Lines, WDM private network are met using Ethernet services.
7.5 Given a scenario, determine appropriate Ethernet services.
In this Section
Ethernet Services
7.3 Mobile Backhaul
Replacement
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 6.1
MEF 8
MEF 10.2

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
MEF 26.1
MEF 28
Technologies
Backhaul
Ethernet Services
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
technologies
Carrier Ethernet and L2VPN
L2VPN over Metro or Wide Area Network is a service where a customer
connects several locations with Layer 2 connectivity, that is, without IP
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
that require more than few hundred Mbps.
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
applications of the subscriber.
In most cases the service offered was point-to-point.
Note: ATM supported LANE (LAN Emulation) but this was never a widely used
service.
The network that realized the service was often TDM-based, providing very
predictable bandwidth and delay performance and high level of fault
management and resiliency. However, these legacy networks were expensive
to manage, had a relatively limited bandwidth that could be allocated to a
single service, and had relatively high price points.
Carrier Ethernet provides a much more scalable, cost-effective alternative.
In this Section
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 6.1
MEF 8
MEF 10.2
MEF 22.1
IETF RFC 4448
Ethernet Services

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
In CE, the subscriber can map traffic to the services based on CE-VLAN IDs
and can have bandwidth profiles that enable sharing of bandwidth between
different service instances.
CE also enables the introduction of E-LAN and E-Tree services which could not
be supported efficiently over ATM or FR.
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
are:
Scalable bandwidth (granularity, up to 10 Gbps)
Support of Multi-point services
Bandwidth sharing between services

Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
technologies
Carrier Ethernet and IP
L3VPN / IP Service
Many core networks are built over IP/MPLS both nationally and internationally.
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
routers that are MPLS-capable. Such a network can provide connectivity
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
Development Organization that is attempting to create standards for such
services. In contrast to L3VPN, Ethernet services are built on the concept of
Ethernet based forwarding, hence can be referred to as L2VPN. When we
consider L3VPN Vs. L2VPN the following comparison can be made:
L2VPN L3VPN
Customer Handoff
Ethernet UNI
Ethernet port (or PDH
circuit)
Service Identification VLAN ID / EVC IP Address
Service Rate Granular, up to 10 Gbps
Granular, up to 10
Gbps
Defined by Service
In this Section
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 6.1
MEF 8
MEF 10.2
MEF 22.1
IETF RFC 4448
Ethernet Services

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
SLS
performance objectives,
controlled by Bandwdith
profile
Proprietary
CoS Identification PCP, DSCP, Per EVC DSCP/ToS
Packet/Frame
Routing/Forwarding
MAC Address (E-LAN) VLAN
ID (E-Line)
IP Address
Fault Management
Link Trace, Continuity
Check (Layer 2 Ping),
Loopbacks
Traceroute, ICMP Ping
Performance Management
Frame Delay, Frame Delay
Variation, Frame Loss
Ratio, Service Availability
Packet Delay, Packet
Delay Variation,
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
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
technologies
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
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.
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
enables more sophisticated bandwidth sharing schemes and of course scales as
the number of locations grow. For the cases where time synchronization is
important, synchronization over packet networks (1588v2 or NTP) can be
used. TDM-based CES over Ethernet services also provides a comparable
service.
Example:
Assuming that the customer has a symmetrical service of 4 Mbps using 2xE1s
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
case the following UNI Attributes are recommended:
All-to-One Bundling = Yes (which means Bundling=No, Service
In this Section
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 6.1
MEF 8
MEF 10.2
MEF 22.1
IETF RFC 4448
Ethernet Services

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Multiplexing = No)
Ingress Bandwidth Profile per UNI
CIR = 4 Mbps
CBS = 50,000 bytes
EIR=0
EBS=0
L2CP Processing Tunnel all L2CPs
Where a single EVC with single CoS ID is planned, the following EVC Attributes
are recommended:
No bandwidth profile
Conditional delivery Deliver Unconditionally for Unicast, Multicast,
Broadcast
Service Performance will be set to target the performance
guaranteed to the subscriber

Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact

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
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
There is currently no overview presentation available for MEF 22.1.

Home About Contact
Test Objectives 8 1
Comparing and Positioning Ethernet Services
8.1 Compare and contrast Ethernet services with L2, IP, and TDM private line
services.
8.2 Given a scenario, recommend an Ethernet service to meet end user
specifications.
In this Section
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 6.1
MEF 8
MEF 10.2
MEF 22.1
IETF RFC 4448
Ethernet Services

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Circuit Emulation
Purpose and Need
Since the 1960's when TDM was first developed for wide area networks, a huge
installed-base of TDM circuits and equipment ports (T1/E1, T3/E3 etc.) has
emerged throughout the world supporting both voice communications and also
data networking.
However, with the advent of the Internet, packet-based networking (Carrier
Ethernet, IP, MPLS) for both data networking and voice communications has
overtaken TDM, becoming the primary approach to digital networking in wide
area networks.
The original purpose of TDM was to enable multiplexed voice calls over a
single physical circuit. Voice calls require minimum end-to-end delay (latency)
and delay variation to achieve reasonable voice quality. This purpose was
achieved by designing TDM in such a way that clock synchronization between
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
the synchronized clocks - whether or not actual traffic is contained within the
TDM frames. This translates into low latency and delay variation at the
expense of bandwidth and flexibility.
Packet-based networking originally provided cost effective networking with
high bandwidth capabilities and flexibility, but without the guarantee of low
latency and delay variation required for voice calls and some data
applications. However, with the advent of Carrier Ethernet, and the
In this Section
 
9.1.2 MEF 8 model
 
9.2 CES Components
Function (GIWF)
 
9.3.1 E-Line
 
9.4 Synchronization
9.4.1 Packet Based
9.4.1.2 NTP

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
improvement of the underlying transport infrastructures, it is now feasible to
guarantee low latency and delay variation in packet-based networks enabling
the transport of all types of applications including voice and clock
synchronization.
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
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
over a single packet-based network.

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
Technologies
9 CES over Ethernet
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Circuit Emulation
What is CESoETH?
Circuit Emulation Service over Ethernet (CESoETH) is a technology for
transporting TDM services over a Carrier Ethernet Network (CEN)
CESoETH tunnels TDM traffic through a CEN where the packet network
emulates a circuit-switched network, re-creating the TDM circuit at the far
end such that the CEN is invisible to TDM source and destination equipment.
CESoETH runs on a standard Ethernet point-to-point service (E-Line). CESoETH
can be referred to as TDM emulation over packet network.
The service is illustrated in the following figure:
Figure 9.1.1.F1 - CESoETH
CESoETH enables an Carrier Ethernet Service Provider to offer a true
converged service over the packet network - a service that supports both
legacy TDM-based interfaces and services, along side more advanced
Ethernet-based services.
CESoETH is the solution for any point-to-point service between locations that
have TDM interfaces such as E1, T1, E3, T3 where the wide area network is a
In this Section
 
9.1.2 MEF 8 model
 
9.2 CES Components
Function (GIWF)
 
9.3.1 E-Line
 
9.4 Synchronization
9.4.1 Packet Based
9.4.1.2 NTP

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
CEN. When the service itself is TDM and when timing synchronization is
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
support CESoETH service can be used to support other Ethernet services which
are packet based. However, this is achieved using a separate EVC.

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
Technologies
9 CES over Ethernet
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Circuit Emulation
MEF 8 Model
MEF 8 is the Implementation Agreement for Circuit Emulation over a Carrier
Ethernet Network (CEN)
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
TDM interface. However a CEN supports only Ethernet UNIs. A component is
defined to convert TDM to Ethernet. This component is called Generic
Interworking Function (GIWF)
This model is illustrated in the following figure:
Figure 9.1.2.F1
It should be noted that this schematic drawing may be realized using a single
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.
In this Section
 
9.1.2 MEF 8 model
 
9.2 CES Components
Function (GIWF)
 
9.3.1 E-Line
 
9.4 Synchronization
9.4.1 Packet Based
9.4.1.2 NTP

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
From that point on, the transport network is 'unaware' that a TDM service is
being carried over the EVC/OVC.
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.
However, the same UNI can be used to support other services between these
customer locations, using separate EVCs and utilizing the service multiplexing
capabilities of MEF services.
It should be noted that similar techniques are used by IETF solutions for
carrying TDM traffic over MPLS or IP networks using pseudowires.
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
require communication between themselves, a third (not shown in the figure)
T-Line is created. This service scenario is depicted in the figure below:
Figure 9.1.2.F1

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
Technologies
9 CES over Ethernet
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Circuit Emulation
CES Components
CESoETH requires several architectural components in addition to the
implementation of TDM to Ethernet conversion. This section describes the
various components and their use in the implementation of a Carrier Ethernet-
based TDM service.
In this Section
 
9.1.2 MEF 8 model
 
9.2 CES Components
Function (GIWF)
 
9.3.1 E-Line
 
9.4 Synchronization
9.4.1 Packet Based
9.4.1.2 NTP

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
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
Technologies
9 CES over Ethernet
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Circuit Emulation
Interface to Customer
The Subscriber of CESoETH is presented a TDM interface by the Service
Provider. TDM services may be transported in two ways:-
structure-agnostic (where any underlying structure is ignored by the
transport mechanism)
structure-aware (where the underlying structure is exploited by the
transport mechanism)
MEF Specifications supports the following interfaces:
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) 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]
The TDM data (and optionally clock) is converted and mapped to packets for
transport over a CEN. This operation is performed by the GIWF. After this
conversion from TDM to packet, there is a standard MEF ETH UNI - the point
at which the ETH service starts.
At the egress of the ETH service, the GIWF regenerates the TDM stream.
In this Section
 
9.1.2 MEF 8 model
 
9.2 CES Components
Function (GIWF)
 
9.3.1 E-Line
 
9.4 Synchronization
9.4.1 Packet Based
9.4.1.2 NTP

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Note that the ETH service that carries the CES data is managed and
maintained from UNI to UNI. However, the specific statistics that are
delivered for CESoETH are measured between GIWFs.

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
Technologies
9 CES over Ethernet
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Circuit Emulation
Generic Interworking Function (GIWF)
The Circuit Emulation Interworking Functional, also known as the Generic
Inter-Working Function (GIWF), is defined as the adaptation function that
interfaces the CES application to the Ethernet layer. GIWF handles the
emulation of the service presented at the CES TDM Interface. The CES GIWF is
responsible for all the functions required for the emulated service to function
including:
Encapsulation on ingress
Decapsulation on egress
Payload formation and extraction
Synchronization
Carriage of TDM signaling and alarms
Error Response and Defect Behaviour
TDM performance monitoring
The details of these functions are detailed in section 6 of MEF 8 but are
outside the scope of this study guide.
The GIWF has two interfaces:
Customer facing - CES TDM Interface
ETH UNI facing - CES Payload (i.e. packetised TDM payload, CES
control word, optional RTP header)

In this Section
 
9.1.2 MEF 8 model
 
9.2 CES Components
Function (GIWF)
 
9.3.1 E-Line
 
9.4 Synchronization
9.4.1 Packet Based
9.4.1.2 NTP

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
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
Technologies
9 CES over Ethernet
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Circuit Emulation
Functional Layering
Circuit Emulation Services over Ethernet (CESoETH) uses a point-to-point
connection between two GIWFs. Essentially it uses the CEN as an intermediate
network (or virtual wire) between two TDM networks. This is handled as an
application layer function in terms of the layered network model defined in
MEF 8. The GIWF provides the adaptation of the CES application to the
Ethernet services layer.
This functional layering is shown in the table below with mapping onto the
various encapsulation headers
CES Application Data
Adaptation Function
Ethernet Service Layer
When one considers a packet "inside the CEN" the realization of the above
layered model will look as shown below:
TDM Payload
RTP (Optional)
CESoETH Control Word
Emulated Circuit Identifier
In this Section
 
9.1.2 MEF 8 model
 
9.2 CES Components
Function (GIWF)
 
9.3.1 E-Line
 
9.4 Synchronization
9.4.1 Packet Based
9.4.1.2 NTP

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
VLAN Tags
MAC SA
MAC DA

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
Technologies
9 CES over Ethernet
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Circuit Emulation
Service Definitions

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
used and the attributes for that E-Line.
E-Line requirement for CESoETH
UNI attributes for CESoETH
EVC attributes for CESoETH
EVC Per UNI attributes for CESoETH

In this Section
 
9.1.2 MEF 8 model
 
9.2 CES Components
Function (GIWF)
 
9.3.1 E-Line
 
9.4 Synchronization
9.4.1 Packet Based
9.4.1.2 NTP

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
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
Technologies
9 CES over Ethernet
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Circuit Emulation
E-Line
Only E-Lines can be used for CESoETH. This is because the E-Line is the single
Carrier Ethernet service type for point-to-point connections, and CESoETH is
inherently a point-to-point service. In other words, only E-Lines connect
exactly two customer TDM interfaces over a CEN.
Subscribers can choose between using an E-Line EPL (private service) and an
EVPL (virtual service) An EPL is chosen where only one Carrier Ethernet
service is required on the UNI (i.e. CESoETH) EVPL is chosen when more than
one Carrier Ethernet service is required on the UNI (e.g. CESoETH and Internet
access; two CESoETH etc.)
Altough EPL provides higher transparency in terms of L2CP processing, this is
not relevant for CESoETH, which does not make use of L2CP.
Note that the UNI-N in this case is a regular UNI-N supporting Ethernet
services. However, the UNI-C is internal to the GIWF since the customer has a
TDM interface to the network.
The service requirements for CESoETH are:
Point-to-point service
Guaranteed bitrate in known quantum (2 Mbps for E1, 1.5 for T1,
etc.)
Single class of service
In this Section
 
9.1.2 MEF 8 model
 
9.2 CES Components
Function (GIWF)
 
9.3.1 E-Line
 
9.4 Synchronization
9.4.1 Packet Based
9.4.1.2 NTP

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Specific service performance targets to support service QoS similar to
TDM networks, meaning:
Low loss ratio
Small delay
Small delay variation
No VLAN manipulation is required
The following example describes how mobile backhaul of 2G traffic can be
realized using E-lines between each cell site and the BSC.
Figure 9.3.1.F1 - Mobile Backhaul

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
Technologies
9 CES over Ethernet
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Circuit Emulation
UNI Attributes
A UNI that is an end-point to a CESoETH service is a regular UNI with no
specific additional requirements imposed on the UNI. Either UNI type (1, 2.1,
2.2) can be used. Some specific UNI attributes should be set specifically in
order to facilitate the CESoETH service. The table below lists and explains the
additional requirements of the various UNI attributes:
UNI Service Attribute Recommended Setting
UNI Identifier No Aditional Requirement
Physical Medium No Aditional Requirement
Speed No Aditional Requirement
Mode FDX
MAC Layer 802.3-2005
UNI MTU Size No Aditional Requirement
Service Multiplexing Yes if there are several EVCs
connecting this UNI No if the UNI is
used for a single CESoETH and
nothing else
Bundling No
In this Section
 
9.1.2 MEF 8 model
 
9.2 CES Components
Function (GIWF)
 
9.3.1 E-Line
 
9.4 Synchronization
9.4.1 Packet Based
9.4.1.2 NTP

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
All to One Bundling No if Service Multiplexing was set to
Yes Yes if Service Multiplexing was
set to No
CE-VLAN ID for untagged and
Priorty Tagged frames
No Aditional Requirement
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
to ensure the CIR for constant rate
traffic
Egress BWP per UNI No
L2CP Processing Pass to EVC all L2CPs, expect for
PAUSE frames PAUSE cannot be
used along side with guaranteed bit-
rate applications

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
Technologies
9 CES over Ethernet
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Circuit Emulation
EVC Attributes
The EVC that carries CESoETH can be an EPL or an EVPL. It carries non-VLAN
traffic and therefore VLAN and CoS preservation are irrelevant. Since CESoETH
uses no L2CP it implies that all L2CP can be discarded by the EVC.
The major issue to consider is the service performance attributes for this
single CoS ID service.
The Delay and Delay Variation are to be set according to the specific
requirements of the customers, but must be kept to a minimum.
The following table lists the EVC attributes and the suggested settings for
such an EVC:
EVC Service Attribute Recommended Value
EVC Type Point to Point
UNI List No Additional Requirement
EVC MTU Size No Additional Requirement
CE-VLAN ID Preservation No
CE-VLAN CoS Preservation No
Unicast Service frame Delivery Deliver unconditionally
In this Section
 
9.1.2 MEF 8 model
 
9.2 CES Components
Function (GIWF)
 
9.3.1 E-Line
 
9.4 Synchronization
9.4.1 Packet Based
9.4.1.2 NTP

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Multicast Service frame Delivery Deliver unconditionally
Broadcast Service frame Delivery Deliver unconditionally
L2CP Processing Discard all L2CPs
EVC Performance
Frame loss ratio 0.01%
One-Way Frame Delay 10 msec for
99th percentile
One-Way Frame Delay Variation 1
msec for 99 th percentile
Availability 99.95%
Note that the exact values for service performance may be dictated by the
appropriate TDM standard or the service requirement that the Subscriber has.
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
Technologies
9 CES over Ethernet
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Circuit Emulation
EVC per UNI Attributes
The major issue to consider when setting the EVC per UNI attributes for
CESoETH is the ingress bandwidth profile (BWP) The service must guarantee
CIR at a rate that matches the TDM traffic CBR. Because the packetization
process adds additional overhead and because the BWP counts also the ETH
headers in some cases, the CIR could be set a little higher compared to the
TDM nominal bitrate.
For example, for an EVC carrying E1, the CIR could be set to say 2.2 Mbps,
allowing 10% margin. If the service was originally an E3 of 34.368 Mbps, then
the CIR could be set to say 38 Mbps.
CBS can be set relatively to a relatively small level since the TDM traffic is
very constant with minimal bursts. Since it is important not to drop any 'TDM
service' packets, a CBS of 3 times the MTU could be set.
EIR and EBS are set to 0 since ALL traffic must be counted against the SLS.
CF and CM are not relevant in such a case.
The following table lists the EVC per UNI attributes and the suggested settings
for such an EVC:
EVC per UNI Service Attribute Recommended Value
UNI EVC ID No Additional Requirement
In this Section
 
9.1.2 MEF 8 model
 
9.2 CES Components
Function (GIWF)
 
9.3.1 E-Line
 
9.4 Synchronization
9.4.1 Packet Based
9.4.1.2 NTP

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
CE-VLAN ID / EVC Map No Additional Requirement
Ingress Bandwidth Profile per
EVC
CIR = 2.2Mbps for E1 service
CBS=3x1522 = 4566 bytes EIR=0,
EBS=0 CF=0, CM=0
Ingress Bandwidth Profile per CoS
ID
Must not specify
Egress Bandwidth Profile per EVC Must not specify
Egress Bandwidth Profile per CoS
ID
Must not specify

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
Technologies
9 CES over Ethernet
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Circuit Emulation
Synchronization
Synchronization is the means of keeping all digital equipment in a
communications network operating at the same specified clock rate.
Differences in timing at nodes within a network cause the receiving node to
either drop or reread information sent to it. This is referred to as 'clock slip'.
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.
When the receiver cannot keep up with the sender, it will periodically drop
some of the information sent to it resulting in reduced voice quality or
retransmission of data if the source can support this.
To achieve the required synchronization of the TDM nodes across the
asynchronous Ethernet network, a clock recovery mechanism must be
employed at the receiver side of a CESoETH connection. Clock recovery
mechanisms need to withstand the potential Frame Delay, Inter-Frame Delay
Variation (IFDV) and frame loss of Ethernet networks yet still comply with
strict synchronization standard requirements. Variations of recovered clocks
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
Networks (CENs) may introduce frame delay variation in the order of
milliseconds.
The different sync parameters are illustrated below:
In this Section
 
9.1.2 MEF 8 model
 
9.2 CES Components
Function (GIWF)
 
9.3.1 E-Line
 
9.4 Synchronization
9.4.1 Packet Based
9.4.1.2 NTP

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Figure 9.4.F1 - Sync Parameters
Synchronization can be achieved for both phase and/or Time of Day. There
are three catagories of solutions:
1. External source GPS or TDM network. This is outside the scope of the
Carrier Ethernet domain.
2. Synchronization of packet network elaborated in the following
sections.
3. Synchronization over physical Ethernet Synchronous Ethernet or SyncE
Synchronization is a key component in cellular network technologies and
different cellular network technologies have different synchronization
requirements.
Synchronization is used to support mobile application and system
requirements to minimize air interference, facilitate handover between base
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.
The following table specifies for each mobile technology which parameters are
required to be synchronized:
Mobile Network
Architecture
Frequency Sync Time-of-day / Phase
Sync
CDMA2000 Yes
GSM Yes
UMTS-FDD Yes
LTE-FDD Yes
UMTS-TDD Yes Yes
LTE-FDD with MBMS-
Single Freq. Network
Yes Yes
LTE-TDD Yes Yes
Mobile WiMAX Yes Yes
TD-SCDMA Yes Yes

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
Technologies
9 CES over Ethernet
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Circuit Emulation
Packet Based Synchronization Methods
Packet-based methods use a master-slave mechanism where a master
distributes timing to the slaves via packets that carry timestamps. The master
has access to an accurate reference, such as GPS and this source clock is
distributed from a Primary Reference Clock (PRC).
Figure 9.4.1.F1 - Packet Based Methods
In this Section
 
9.1.2 MEF 8 model
 
9.2 CES Components
Function (GIWF)
 
9.3.1 E-Line
 
9.4 Synchronization
9.4.1 Packet Based
9.4.1.2 NTP

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
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
Technologies
9 CES over Ethernet
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Circuit Emulation
Adaptive Clock Recovery
Adaptive Clock Recovery (ACR) is a method with several variants and
implementations. In all of them, ACR reconstructs (recovers) the original clock
from the actual payload of the data stream. In other words, a synchronous
clock is derived from an asynchronous packet stream.
This is achieved by having the clock source send bits at a constant rate and
aggregated into packets. However, these packets experience variable delay
over the CEN. As long as the packets arrive with a high probability (meaning
very low FLR) and within bounds on delay and inter-frame delay variation,
averaging functions can be employed to find the original clock rate.
From the CEN's point of view, these packets can be carried in a dedicated EVC
or could have a CoS with stringent performance objective within an EVC that
carries other traffic.
These two approaches are illustrated below:
Figure 9.4.1.1.F1 - Adaptive Clock Recovery

In this Section
 
9.1.2 MEF 8 model
 
9.2 CES Components
Function (GIWF)
 
9.3.1 E-Line
 
9.4 Synchronization
9.4.1 Packet Based
9.4.1.2 NTP

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Figure 9.4.1.1.F2 - Adaptive Clock Recovery

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
Technologies
9 CES over Ethernet
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Circuit Emulation
NTP
Network Time Protocol (NTP) is one of the oldest Ethernet protocols still in
use. It was originally designed over 25 years ago.
NTPv3 is defined in RFC 1305.
NTPv4, which is backwards compatible with NTPv3, is defined in RFC 5905.
NTPv4 offers several improvements over previous versions of NTP - one of
them being to extend the potential accuracy to tens of microseconds. NTPv4
can usually maintain time to within 10-20 milliseconds over the public
Internet and can achieve microsecond accuracy or better in local area
networks (under ideal conditions)
The main issue with NTP is that its accuracy can degrade substantially during
periods of network congestion. NTP packets are carried over UDP/IP/ETH
transport which is then encapsulated depending on the CEN transport
technology. Therefore, NTPv4 requires a dedicated CoS ID with stringent
performance objectives for Frame Loss Ratio, Frame Delay and Frame Delay
Variation.
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
of using NTP for precise timing applications is that there is no allowance to
account for network delays other than through multiple poll time averaging
techniques and buffering. So NTP, even in the latest implementation, does
not meet the higher precision requirements for 3G/4G mobile backhaul.
In this Section
 
9.1.2 MEF 8 model
 
9.2 CES Components
Function (GIWF)
 
9.3.1 E-Line
 
9.4 Synchronization
9.4.1 Packet Based
9.4.1.2 NTP

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
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
Technologies
9 CES over Ethernet
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Circuit Emulation
1588 v2
The Precision Time Protocol (PTP) specified in IEEE standard 1588v2 is the
latest in packet-based timing technology. Originally designed to provide
precise timing for critical industrial automation applications, it is now
providing the highest level of accurate frequency, phase and time of day to
wireless backhaul networks.
PTP overcomes the Ethernet NTP latency and delay variation issues, providing
an unprecedented accuracy in the nanosecond range. The effects of network
latency are greatly reduced by using a technique whereby the master and
slave communicate with one another to cancel out a measured delay between
the two nodes.
The IEEE1588 standard makes several assumptions about the network being
used (e.g. multicast support) but the key assumptions that affect clock
accuracy are:
1. The transmission delays are almost constant over time (or at least
change slowly)
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
master)
When carried over a Carrier Ethernet Network (CEN), 1588v2 requires a
dedicated CoS or even a dedicated EVC with stringent requirements on Frame
In this Section
 
9.1.2 MEF 8 model
 
9.2 CES Components
Function (GIWF)
 
9.3.1 E-Line
 
9.4 Synchronization
9.4.1 Packet Based
9.4.1.2 NTP

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Loss Ratio, Frame Delay and Inter-frame Delay Variation.
PTP Network Components
The following figure shows an example PTP synchronization network topology.
Figure 9.4.1.3.F1 - PTP Synchronization Network Topology
Grandmaster Clock
This is the primary reference source within a PTP sub-domain. The
Grandmaster clock has a high-precision time source, which can be a GPS
reference or an atomic clock.
Boundary Clock
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
switch/router at the boundary of a network.
IEEE 1588 boundary clocks are an effective way to reduce packet delay
variation. A boundary clock runs the PTP protocol and is synchronized to the
master clock. The boundary clock, in turn, acts as a master clock to all slaves
within the same network.
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
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
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
Technologies
9 CES over Ethernet
Send Feedback
Name:
Email:
Comments
Send Feedback
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.

Home About Contact
Circuit Emulation
SyncE
The IEEE 802.3-2008 standard specifies that transmit clocks can operate with
a frequency accuracy of up to +/-100 ppm.
The Synchronous Ethernet (SyncE) approach provides a mechanism to deliver a
network traceable physical layer clock over IEEE 802.3 PHYs with EEC as
specified in ITU-T G.8262 [33]. The SyncE model follows the same approach
that was adopted for traditional TDM (PDH/SDH) synchronization (i.e. utilizing
the physical layer line signals) and implemented with similar engineering rules
and principles. Synchronous Ethernet has also been designed specifically to
inter-work with the existing SONET/SDH synchronization infrastructure.
Note that Synchronous Ethernet is used to deliver frequency, but not phase or
time of day.
The following figure proivdes an example of synchronization using Synchronous
Ethernet:
In this Section
 
9.1.2 MEF 8 model
 
9.2 CES Components
Function (GIWF)
 
9.3.1 E-Line
 
9.4 Synchronization
9.4.1 Packet Based
9.4.1.2 NTP

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Figure 9.4.2.F1 - Synchronization using Synchronous Ethernet
The architectural aspects of Synchronous Ethernet are defined in ITU-T
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.
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
for clock accuracy, noise transfer, holdover performance, noise tolerance and
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
use in small network domains, while a hybrid solution complemented by a
packet-based synchronization method would be required to extend its reach.

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
Technologies
9 CES over Ethernet
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Test Objectives 9 1
Circuit Emulation over Ethernet
9.1 Define the purpose and need for Circuit Emulation over Ethernet
applications.
9.2 Define the critical components of circuit emulation over Ethernet service.
9.3 Define the MEF Service Definitions used to deliver emulated circuits.
9.4 Define the EVC service attributes required for emulated circuits.
9.5 Define the three techniques and their uses for delivering synchronized
clock over emulated circuits (e.g., Adaptive, 1588v2, Synchronous Ethernet,
NTP, PTP).
9.6 Describe how circuit emulation is used in Mobile Backhaul applications.
In this Section
 
9.1.2 MEF 8 model
 
9.2 CES Components
Function (GIWF)
 
9.3.1 E-Line
 
9.4 Synchronization
9.4.1 Packet Based
9.4.1.2 NTP

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
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
Technologies
9 CES over Ethernet
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Relevant Standards
Ethernet OAM is based on several standards:
IEEE 802.3ah: Link OAM
IEEE 802.1ag: Connectivity Fault Management (CFM)
ITU-T Y.1731: Requirements for OAM functions in Ethernet-based
networks and Ethernet services
The following figure describes their relationship and applicability for Ethernet
services:
10.1.F1 - SOAM relationship between standards
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
IEEE 802.1ag Overview
IEEE 802.1ag specifies protocols and procedures for Connectivity Fault
Management (CFM) for VLANs or services. These services could be Ethernet
Virtual Connections (EVCs) or Operator Virtual Connections (OVCs)
IEEE 802.1ag defines methods to:
detect
verify
isolate
report
end-to-end Ethernet connectivity faults.
Ethernet OAM runs over bridged networks in the Ethernet service layer, as
opposed to link layer OAM that is specified by IEEE 802.3 for cases where the
link is Ethernet.
IEEE 802.1ag and ITU-T Y.1731 define joint constructs and terminology. It
enables defining levels of hierarchical administrative domains, performing the
CFM procedures within each domain independently.
The following procedures and packet formats are defined:
1. Continuity Check
2. Loopback
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
3. Link trace
4. Alarm Indication Using Remote Defect Indication (RDI) - RDI is
triggered by the fault detection mechanism in the CCM procedure .
10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
ITU-T Y.1731 Overview
ITU-T Y.1731 augments IEEE 802.1ag in defining capabilities to perform
Performance Monitoring (PM) for Ethernet services. It also provides additional
Fault Management (FM) capabilities. Y.1731 defines the frame format and
multicast addresses to be used for both PM and FM.
The following procedures and packet formats are defined:
1. AIS (Alarm Indication Signal): Generated when an end-point detects loss
of connectivity
2. Lock: Used to verify connectivity problems in out-of-service mode
3. Test: Used to test the connectivity out-of-service. It can be used as
part of RFC 2544 or ITU-T Y.1564 testing
4. Delay Measurements: Using DMM/DMR procedure
5. Loss Measurement: Using LMM/LMR procedure
Some messages use unicast MAC DA and some use reserved multicast DA,
which is treated as L2CP. For multicast, the MAC DA address is defined as
follows:
There are two types of frames: Class 1 and Class 2
Class 1 - used by CCM - uses MAC DA of 01-c2-80-00-00-30 through 01-c2-80-
00-00-3x, where MEG level is represented by x
Class 2 - used by LBM and LTM - uses MAC DA of 01-c2-80-00-00-3y through
01-c2-80-00-00-3F, where y=8+MEG level
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page

10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Framework
This section explains about the domains and constructs used in Ethernet
Service OAM, as well as MEF 17 Framework and Requirements Phase 1.
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Domains
An OAM Domain is defined as a network or sub-network, operating at the ETH
Layer and belonging 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 implemented across a single or
across multiple (sub)networks. An OAM Domain determines the span of an OAM
flow across such administrative boundaries. OAM Domains can be hierarchical
but must not partially overlap.
A Subscriber's OAM Domain may completely overlap multiple Service Providers'
OAM Domains such that Service Providers OAM Domains remain transparent to
the Subscriber's OAM Domain.
A Service Provider's OAM Domain may completely overlap multiple CEN
Operators' OAM Domains such that CEN Operators OAM Domains remain
transparent to Service Provider's OAM Domain.
The following figure illustrates an OAM domain: A single CEN to which 4 CEs
are attached:
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
10.2.0.F1 - SOAM Domain
[Source: MEF30, Figure 2]
10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Constructs
This section explains the basic constructs of Ethernet Service OAM.
ME (Maintenance Entity) represents an OAM entity that requires management.
An 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 MEs that are relevant for E-Lines are shown in the figure below:
10.2.1.F2 - SOAM Maintenance Entities
Subscriber ME is the OAM Domain that connects the Customer Equipment of
the Subscriber. For E-LAN and E-Tree, there will typically be more than two
such end-points.
EVC ME is the OAM domain that connects the UNI-Ns of a given EVC.
Operator ME is the OAM domain of the OVC within the Operator's CEN.
UNI ME is the OAM domain between UNI-C and UNI-N.
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
NNI ME is the OAM domain between ENNI-Ns of a given ENNI.
Note that in some deployments not all MEs exist. For example when the UNI
link is not managed, the UNI ME does not exist.
Test ME is the OAM domain between UNI-Cs that enables the Service Provider
to isolate problems reported by the Subscriber.
Note that the Test ME is not active at all times, but is used on an on-demand
basis.
10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
MEG, MEP, MIP and MEG Level
MEG (Maintenance Entity Group for ME Group)
A MEG consists of the maintenance entities (ME) that belong to the same
service inside a common Service 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.
Note that IEEE 802.1ag uses the terminology of MA (Maintenance Association).
MEF is aligned with the ITU-T terminology of MEG.
MEP (MEG End Point)
A 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 the SOAM
Constructs section.
A Point-to-Point EVC has two MEPs, one at each end-point of the ME
(i.e. each UNI-N)
A Multipoint-to-Multipoint EVC of n UNIs has n MEPs, one at each
end-point
A Point-to-Point OVC has two MEPs, one at each end-point of the ME
(each External Interface associated with the OVC)
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page

MIP (MEG Intermediate Point)
A MEG Intermediate Point (MIP) is a provisioned OAM reference point which is
capable of reacting 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 as shown in the SOAM Constructs section. The number of MIPs
in a Point-to-Point EVC or Multipoint-to-Multipoint EVC is dependent on the
specific deployments. MIPs are used for Fault Management.

MEG Level
MEG Level is used to distinguish between OAM frames belonging to different
nested MEs, as shown in the SOAM Constructs section. MEs belonging to the
same MEG share a common MEG Level. Eight MEG Levels have been specified
for the purposes of Ethernet Sevice OAM: Levels 0 through 7.

When Subscribers, Service Providers, and Network Operators share a given
MEG Level space, allocation of MEG Levels can be negotiated among the
different parties 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 the EVC
ME belongs to a Service Provider OAM Domain
Operator MEs use MEG Levels 2, 1, or 0.
The MEG Levels used for UNI ME and NNI ME will default to 0.
This default allocation of MEG Level space between Subscribers, Service
Providers and Operators can be changed according to mutual agreement of
the parties.
MEF 30 specifies the following default MEG Level allocation per ME:
10.2.1.1.F1 - Default MEG Levels
[Source: MEF30, Table 3]
MEG levels are allocated in a hierarchical manner to enable the following
capabilities:
From a given MEG level point of view, higher level MEGs are passed
transparently, but lower level MEGs are not allowed to pass
A MEP at a given MEG Level must consume OAM frames with this MEG
level
10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM

Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
MEF 17
MEF 17 is "Service OAM Framework and Requirements Phase 1". MEF 17
provides requirements to be satisfied by the Service OAM mechanisms in
Carrier Ethernet Networks and a framework for discussing and implementing
those mechanisms. It also provides context for several MEF specifications (UNI
Type 2 and ENNI) and the work of other standards bodies.
MEF 17 addresses the following specific functional areas of Service OAM:
Fault Management : detection, verification, localization and
notification of faults
Performance Monitoring (including performance parameter
measurements)
Auto-discovery (including discovering service aware network elements
within provider networks)
Intra-provider and inter-provider Service OAM
The reader should note that provisioning aspects of Ethernet services and
CENs are not addressed in MEF 17.

In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Model
The Service OAM scope for Ethernet services is illustrated below:
10.2.2.1.F1 - SOAM Service Scope
Provisioning and Turn-up of the Circuit is outside the scope of MEF
specifications and this study guide.
The following figure from MEF 30, which is based on MEF 17 figure 1,
illustrates pairs of MEPs (thus MEs) and MIPs that may be communicating
across the various OAM domains defined by MEF 17, and also illustrates the
hierarchical relationship between these domains. Note that the orientations of
the MEPs in the diagram are exemplary, and are not requirements.
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
10.2.2.1.F2 - SOAM Maintenance Entities
A network element (NE) that implements UNI-N functionality, for example the
NE denoted as 2 in the figure, has a MEP at MEG level 4 for each EVC instance
that associates that UNI.
Any SOAM message with MEG level 4 or lower must be consumed by that NE.
Any SOAM message with MEG level 5 or higher is passed through transparently.
One can also see that the same NE can have a MIP at MEG level 7, enabling
the subscriber to troubleshoot connectivity problems between the CE and this
NE.
Since SOAM are used for fault management and performance management of
interfaces and EVC/OVCs, they must traverse the same path as the service
frames that are associated with that EVC/OVC.
This means that service frames and SOAM will have the same EVC headers as
the service frames.
This requirement leads to the requirement of deterministic and controlled
assignment of flows to shared links in a LAG.

10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Maintenance Entities
MEF 17 and MEF 30 (which adds the Test ME) together define the following
MEs:
Subscriber ME
The Subscriber ME spans the network between two UNI-Cs of the subscriber. It
is managed by the subscriber. However, the Service Provider (SP) and/or CEN
Operator can configure MIPs inside the CEN - or at the CEN's edge (UNI-N) - to
help with connectivity troubleshooting. Any performance monitoring done
between MEPs of this ME are passed as service frames from the SP's point of
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
appropriate EVC.
Test ME
The Test ME is assigned to the Service Provider for isolation of problems
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
network. The Test ME is not active at all times, but is used on an on-demand
basis.
EVC ME
An EVC ME is intended to provide the most complete view of the EVC. The
MEPs in the EVC ME are placed as close to the UNI reference point as possible.
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
This ME is used to perform performance monitoring of the EVC and can also
be used for EVC fault management.
Operator ME
An Operator ME is intended to provide the most complete view of the OVC.
The MEPs in the Operator ME are placed as close to the external interfaces
associated by this OVC as possible. This ME is used to perform performance
monitoring of the OVC and can also be used for OVC fault management. This
ME is confined to a single CEN and is used only for cases where an ENNI exists.
UNI ME
A UNI ME is used to monitor the UNI link, as specified in MEF 20. It is
mandatory for UNI Type 2. Since in many cases the UNI link is not a network,
performance monitoring is less relevant. However fault monitoring activities
are important for this ME.
ENNI ME
ENNI ME is used to monitor the ENNI link between two ENNI-Ns. OAM messages
use the active link to ensure that they monitor the same physical link used for
ENNI frames. Since the ENNI link is a wire and not a network, performance
monitoring is less relevant. However fault monitoring activities are important
for this ME.

10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Fault Management
This section provides the definition of fault management for Carrier Ethernet
services, as well as the procedures defined for implementing it.
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Definition
MEF FM describes the use of standard protocols, mechanisms, and procedures
for monitoring and investigating the status of Ethernet Virtual Connections
(EVCs), Operator Virtual Connections (OVCs), and External Interfaces (UNI and
ENNI) across a defined OAM Domain, where that domain can be a large
network (or subnetwork), or a simple link. SOAM FM uses the protocols
described in IEEE 802.1ag and ITU-T Y.1731. It provides end-to-end Ethernet
connectivity management, mechanisms to detect, verify, isolate and report
faults that affect the external interfaces or the EVC/OVCs. The following
sections describe the use of FM procedures and mechanisms with the
appropriate parameter settings that meet the requirements for fault
management of Ethernet services in the CEN.
It should be noted that the transport layer of the CEN may also have its own
FM mechanism (e.g. BFD and VCCV in MPLS-based networks), these
mechanisms and the interaction between them and the Ethernet layer's FM
are outside the scope of this document. Once a fault is detected in the
Ethernet layer, reports are made available for any higher-layer that is carried
over this layer. The details of reporting are outside the scope of this
document.

In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
4
Procedures
This section provides explanations of the procedures used for Fault
Management in Carrier Ethernet Service OAM:
Continuity Check Message
Loopback Message
Link Trace Message

In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Continuity Check Message (CCM)
The Continuity Check Message (CCM) is a message defined by IEEE 802.1ag in
order to verify the connectivity at the ETH layer between 2 MEPs sharing the
same MEG Level within an ME. These messages are sent proactively at a
configurable interval. Both ends need to be configured with the proper
transmission interval. The far end declares a connectivity failure when it does
not receive a CCM within a time interval that is N times (default 3) the
transmission interval.
The sending interval depends on the application behind the sending of CCMs.
The following is common practice:
Protection switching: 10 msec or 3.33 msec
Availability measurement: 1 or 10 seconds
CCMs can be administratively turned on and off, but compliant NEs must
support CCMs.
CCMs can be sent at any MEG Level, depending on the ME they monitor
(Subscriber ME, EVC ME, Operator ME, etc).
CCMs sent by the Subscriber ME must be set with the CE-VLAN ID that maps to
the monitored EVC. Such frames are subject to the Bandwidth Profile and are
considered to be Service Frames.
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
For SP ME, CCMs are carried using the same transport path and identifiers as
service frames for that EVC. Such frames may be subject to the EVC BWP, but
in some implementations, these CCMs are sent after the Ingress Bandwidth
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.
Since CCMs can trigger protection switching, they should encounter the
minimal delay possible between MEPs, and should not be dropped due to
congestion. MEF recommends sending CCMs at the highest priority permissible
by the EVC (this makes sense when the EVC/OVC supports multiple CoS IDs).
CoS IDs must be set to ensure lowest possible frame loss.
When CCMs are sent for a given ME, this ME can have the following
Connectivity Status values:
Active : A ME Connectivity Status of active implies that Service OAM
frames can be exchanged 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 of 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.
The following figure illustrates CCMs monitoring 3 MEs:
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.
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
availability measurement and thus are expected to be sent at 1 or 10 second
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
used for OVC availability measurement and thus are expected to be sent at 1
or 10 second intervals.
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
network element or link has failed. In order to do so, the Operator can start
a Loopback or Linktrace procedure.
10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
10.3.2.1.F1 - Example use of SOAM CCM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Loopback Message (LBM)
Loopback messages (LBM) are defined by IEEE 802.1ag and are used on-
demand in order to isolate a fault, which may have been detected by CCMs.
An LBM is sent from a MEP to a MIP or to a MEP in the same ME. The MIP/MEP
immediately replies with LBR (Loopback Reply)
LBM can be thought of as "layer 2 ping". LBMs are sent as a loopback (LB)
session of N (default is 3) consecutive LBMs in a pre-defined time interval. If
an LBR is not received within a given time interval (default is 5 seconds), the
MEP declares the MIP as being faulty.
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
CoS ID for an LBM - the one that yields the lowest possible loss for that
Ethernet service (EVC or OVC). An LBM is usually 64 bytes long, but can be
extended to any value up to the MTU size using specific TLVs.
The LBR is identical to the LBM except that the MAC DA and MAC SA are
swapped. The following figure illustrates LBR sent by the SP ME in order to
verify that the NE implementing ENNI-N at the far CEN is operating. An LB
session starts from the MEP at the UNI-N on the left destined for the ENNI-N
in Operator 2's network. Once it replies the SP knows that the NE and the
OVC to it are functional.
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
10.3.2.2.F1 - Example use of SOAM LBM

10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
LTM
Link Trace procedure identifies all MIPs and MEPs belonging to a ME. It can be
thought of as a "layer 2 trace route". The procedure is similar to a LB
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
recommended that LTM makes use of the highest CoS ID available, which will
yield the lowest possible loss for a particular ETH service (EVC or OVC). Each
MIP that belongs to this ME replies by generating an LTR unicast message .
This enables the originator to identify the path of this ME but can also
identify the broken link in case of a failure.
The following figure illustrates the use of LTM:
10.3.2.3.F1 - SOAM LTM
In this example, an LTM procedure is issued from MEP1. MIP1 and MIP2 reply,
but MIP3 does not reply.
The failure is between MIP2 and MIP3, or at the NE implementing MIP3.
There is no sense in sending messages to MIP4 and MEP2 as they will not pass
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
through.
The LTM frames should be sent with same CE-VLAN ID that maps to the
monitored EVC, that way it is guaranteed that the LTM passes the same path
as the monitored EVC's service frames.

10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
SOAM: Performance Management
This section provides the definition of performance management for Carrier
Ethernet services as well as explanations for the procedures to implement
performance management, computation methods and implementation
mechanisms.
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Definition
SOAM Performance Management (PM) handles the methods and procedures to
measure the performance attributes of a given EVC or OVC. It is used to verify
that the EVC/OVC's performance meets the SLS. Performance metrics are:
Frame Delay (FD)
Inter-frame Delay Variation (IFDV)
Frame Loss Ratio (FLR)
Availability
PM covers aspects of the measurement technique for each of the performance
objectives, implications for the EVC/OVC and its CoS handling.
In the context of the MEF PM framework, a PM Solution is a collection of
interdependent and related requirements of the components that implement
that solution. A PM Solution uses PM Functions which are capabilities that are
specified for performance monitoring purposes (e.g. Single-Ended Delay,
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-
Ended ETH-SLM). A PM Session is an instantiation of a PM Solution between a
given pair of MEPs using a given CoS over a given (possibly indefinite) period of
time.
The NE is responsible for conducting performance measurements, while the
EMS/NMS components are responsible for configuring, collecting, and
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
processing these performance measurements to determine one or more
performance metrics for the MEG. An implementation of a PM solution consists
of a MEG, supported by NEs, in which the MEPs of that MEG are implemented,
and the management functionality supported by the EMS and NMS system(s)
that typically manage them as shown in the figure below:
10.4.1.F1 - Performance monitoring definition
10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Procedures
This section provides explanations of two performance management
procedures - Delay Measurement Message (DMM) and Loss Measurement
Message (LMM)

In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Frame Delay
illustrated in the following figure:
10.4.2.0.F1 - Frame Delay for Service Frame
When the UNIs are not Time-synchronized, measuring this one-way frame
delay is not possible using the ETH-DM procedure. Therefore, an
approximation is to take 1/2 of the two-way delay between the 2 UNIs.
MEF 10.2 defines three performance attributes for One-Way Frame Delay:
One-way Frame Delay Performance corresponding to a percentile of
the distribution
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
One-way Mean Frame Delay
One-way Frame Delay Range
The Performance objectives are given for a time interval T (e.g. 15 minutes).
The Frame Delay measurements are done much more frequently (e.g. 1 per
second) This yields several (900 in this example) data points per time interval
T. These data points can be used to derive a distribution or some statistical
function.
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
Range: The difference between two pre-defined percentiles (e.g. 90th
percentile to 20th percentile).
Example:
Assume an E-Line service with single CoS ID.
The SLS specified for Frame Delay is that for any given 1-hour the 95th
percentile will be 50 msec.
The Service Provider measures the Frame Delay every 1 second between 2
MEPs in the EVC ME.
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
percentile is no greater than 50 msec, the SLS is met.
The reader can refer to section 6.9.2 of MEF 10.2 for formal definitions of
these performance attributes. The computation method above is applicable
for E-Line.
For E-LAN and E-tree an additional step is required. Please refer to
Measurement in E-Line, E-LAN and E-Tree.

10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Delay Measurement Message (DMM)
ETH-DM procedure is an ITU-T Y.1731 procedure that can be used to
periodically measure Frame Delay and Inter-Frame Delay Variation in an EVC
or OVC. Measurements are performed between 2 MEPs belonging to the same
ME (EVC ME or Operator ME).
The procedure involves the sender MEP sending a DMM (Delay Measurement
Message) once per time interval (e.g. 1 second, 10 seconds, 1 minute). The
remote MEP responds with DMR (Delay Measurement Reply).
Assuming that the 2 MEPs are not time-synchronized, then only two-way
measurements can be taken. In other words, each MEP performs its own
measurements based on differences in the time between sending the DMM and
receiving the DMR.
Note that MIPs are transparent to this procedure.
These messages MUST traverse the same path as the service frames belonging
to the monitored EVC/OVC. The CoS ID of the DMM is set to match the
monitored CoS ID.
When several CoS IDs are to be measured, a separate procedure is run for
each CoS ID.
When using DMM/DMR PDUs, DMM frames are sent from a Controller MEP to a
Responder MEP which, in turn, responds with DMR frames. Controller to
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Responder measurements and Responder to Controller measurements are also
known as forward and backward measurements, respectively. With optional
time-of-day (ToD) clock synchronization one-way FD can be measured. Two-
way FD and IFDV measurements and one-way IFDV measurements can always
be taken and do not require ToD clock synchronization. For FD, if ToD
synchronization is not accurate enough for PM functions, the one-way metrics
of MEF 10.2 [12] and MEF 10.2.1 [13] can be estimated by dividing the two-
way measurement by 2, although this introduces considerable statistical bias
for delay metrics other than MFD (Mean Frame Delay).
The process is illustrated below:
10.4.2.1.F1 - DMM
Each DMM message sent contains the following information in the DMM PDU:
TxTimeStampf: Timestamp at the time of sending the DMM PDU
Upon receiving DMM, the far end has the following variable:
RxTimeStampf: Timestamp at the time of receiving the DMM PDU
One-way frame delay can be computed as (RxTimeStampf TxTimeStampf)
When two-way measurements are conducted, the remote MEP copies the
TxTimeStampf from the DMM to the DMR. The process should be completed as
fast as possible and should not involve the CPU of the NE, where possible.
Once the DMR is received by the sending MEP, it notes RxTimeb Timestamp at
the time of receiving the DMR PDU.
The two-way delay can be computed by (RxTimeb TxTimeStampf)

10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Loss Measurement Message (LMM)
ETH-LM procedure is an ITU-T Y.1731 procedure that can be used to
periodically measure Frame Loss Ratio of an EVC or OVC. Measurements are
made between 2 MEPs belonging to the same ME (EVC ME or Operator ME)
The procedure involves a sender MEP sending an LMM (Loss Measurement
Message) once per time interval (e.g. 1 second, 10 seconds, 1 minute) The
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
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
in turn responds with LMR frames. LMM PDUs can be sent to the unicast
address of the Responder MEP at the MEG Level of the ME.
For each ME for which an LM procedure is configured, a MEP maintains two
local counters for each peer MEP (MEP in its MEG) and for each CoS ID.
TxFCl: Counter for in-profile data frames transmitted towards the
peer MEP.
RxFCl: Counter for in-profile data frames received from the peer
MEP.
The LM process is illustrated below:
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
10.4.2.2.F1 - SOAM Loss Measurement
Note that MIPs are transparent to this procedure.
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
monitored CoS ID.
When several CoS IDs are to be measured, a separate procedure is run for
each CoS ID.
It should be possible to administratively configure the following information in
the LMM PDU:
TxFCf Copied from the local TxFCl
The Refector MEP generates LMR in return for any valid LMM received. The
LMR PDU contains:
TxFCf: Value of TxFCf copied from the LMM frame
RxFCf: Value of local counter RxFCl at the time of LMM frame
reception
TxFCb: Value of local counter TxFCl at the time of LMR frame
transmission
Upon reception of the LMR, the Probe MEP performs the FLR calculation for
both ends for the time interval t 1 -t 0 (Where t 1 is the current time and t 0
is the last sample time).
Number of Frame Lost (local) = |TxFCf(t 1 ) TxFCf(t 0 )| -
|RxFCf(t 1 ) RxFCf(t 0 )|
Number of Frame Lost (Far end) = |TxFCb(t 1 ) TxFCb(t 0 )| -
|RxFCl(t 1 ) RxFCl(t 0 )|
Calculating FLR is explained in the section on Frame Loss Ratio.

10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Computation Methods
This section provides an explanation on how SOAM Performance Management
procedures are are used to compute the performance attributes defined in
MEF 10.2.
These performance attributes refer to EVC performance attributes for a
specific CoS ID. Similar attributes will be defined in the future for ENNI and
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
the applications of these computation methods for different Ethernet service
types.

In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Computing Frame Delay
One-way Frame Delay
illustrated in the following figure:
Frame Delay for Service Frame
When the UNIs are not Time-synchronized, measuring this one-way frame
delay is not possible using the ETH-DM procedure. Therefore, an
approximation is to take 1/2 of the two-way delay between the 2 UNIs.
MEF 10.2 defines three performance attributes for One-Way Frame Delay:
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
One-way Frame Delay Performance corresponding to a percentile of
the distribution
One-way Mean Frame Delay
One-way Frame Delay Range
The Performance objectives are given for a time interval T (e.g. 15 minutes).
The Frame Delay measurements are done much more frequently (e.g. 1 per
second) This yields several (900 in this example) data points per time interval
T. These data points can be used to derive a distribution or some statistical
function.
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
Range: The difference between two pre-defined percentiles (e.g. 90th
percentile to 20th percentile).
Example:
Assume an E-Line service with single CoS ID.
The SLS specified for Frame Delay is that for any given 1-hour the 95th
percentile will be 50 msec.
The Service Provider measures the Frame Delay every 1 second between 2
MEPs in the EVC ME.
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
percentile is no greater than 50 msec, the SLS is met.
for E-Line.
For E-LAN and E-tree an additional step is required. Please refer to

10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Inter-Frame Delay Variation (IFDV) is the difference between the one-way
delay of a pair of selected Service Frames. This definition is borrowed from
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
applicable to Qualified Service Frames.
Note: MEF 10 and 10.1 refer to Inter-Frame Delay Variation as Frame Delay
Variation.
Note: The term Jitter is not an appropriate term to be substituted for Frame
Delay Variation.
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 some (small) time value t .
The concept is depicted below:
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
10.4.3.1.F1 - Inter-Frame Delay Variation Performance
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
difference between 2 consecutive readings is the measured value. At the end
of the time interval T, a percentile is calculated and is compared with the
objective. 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 the following
table:
Parameter Description
T The interval
S Subset of the ordered UNI pairs of the EVC
P Inter-Frame Delay Variation Performance percentile
D t
The separation between frame pairs for which Inter-Frame
Delay Variation Performance is defined
Inter-Frame Delay Variation Performance Objective

for E-line.
An additional step is required in the case of an E-LAN or E-Tree. Please refer
to Measurement in E-line, E-LAN and E-Tree.
10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Frame Loss Ratio
One-way Frame Loss Ratio (FLR) for a given EVC and for a specific CoS ID
measures the fraction of compliant frames dropped within the Carrier
Ethernet Network (CEN) Only the following frames are counted: Frames that
entered the CEN within time interval T, declared green by the appropriate
ingress BWP and which have been forwarded to the egress UNI (not dropped
due to conditional delivery or L2CP handling rules).
FLR is given from UNI A to UNI B, and can be different for each direction. A
more formal definition of one-way FLR is provided below:
Let 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. Note that each
Service Frame can be a Unicast, Multicast, Broadcast or L2CP
Let denote the number of such Service Frames delivered to UNI j.
Define
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
The following figure provides an example:
10.4.3.2.F1 - Frame Loss Ratio
The reader can refer to section 6.9.6 of MEF 10.2.1 for formal definitions of
these performance attributes.
The computation method above is applicable for E-Line.
For E-LAN and E-Tree an additional step is required. Please refer to the
section Measurement in E-Line, E-LAN and E-Tree.
10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Availability
Availability Performance is the percentage of time within a specified time
interval T during which the Frame Loss Ratio is small. As an example, a
Service Provider can define the Availability Performance to be measured over
a month (T = 30 days) 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.
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.
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.
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
10.4.3.3.F1 -Availability for Small Time Intervals
[Source: MEF 10.2.1, Figure B]
The Availability for a particular Class of Service instance from UNI i to UNI j
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
Provider and Subscriber during which the service may not perform well or at
all. Examples of a Maintenance Interval include:
A time interval during which the Service Provider may disable the
service for network maintenance such as equipment replacement
A time interval during which the Service Provider and Subscriber may
perform joint fault isolation testing, and
A time interval during which the Service Provider may change service
features and making the changes may disrupt the service.
The reader can refer to section 6.9.7 of MEF 10.2.1 for formal definitions of
for E-Line. For E-LAN and E-tree an additional step is required, please refer to

10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Measurements in E-Line, E-LAN, E-Tree
This topic discusses the implementation of the various Performance
Management attribute computation methods for a given Ethernet Service type.
For E-Line services, the one-way performance attributes (Frame Delay, Frame
Loss Ratio, etc.) are measured and computed separately in each direction
(UNI A to UNI B and UNI B to UNI A). A SP may set performance objectives
and measure performance for both directions or only one direction.
For E-LAN and E-Tree the computation is more complex. Such a service has N
UNIs associated with it. Since measurement is made between pairs of UNIs,
scalability and complexity issues may require monitoring only a sub-set of the
UNI pairs. Note that for E-LAN with 6 UNIs, there are 6X5 = 30 UNI pairs. The
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
list or any sub-set of that list.
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
two leaf UNIs cannot communicate with each other. For each UNI pair within
the sub-set S, the procedures are carried out and summarized every time
interval T (T can be different per attribute)
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
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
for each ordered pair of UNIs within S, as:
The only attribute that should be computed differently is One-Way Mean
Frame Delay. For Mean Frame Delay, the value is calculated as the Arithmetic
Mean over all Mean Frame Delays of the ordered UNI pairs.

10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Class of Service Implementation Agreement - MEF 23
MEF 23 is an Implementation Agreement (IA) that specifies a small common
set of Classes of Service (CoS) that can be used by Operators, Service
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
as a subset of the CoS an Operator may provide. The MEF CoS IA facilitates:
Ethernet service interoperability and consistency between Operators
a common CoS set for Subscribers to utilize and
support of key applications
The Scope and applicability of the Class of Service Implementation Agreement:
Both UNI and ENNI
Both Multipoint and Point-to-Point and
Both single and multiple CENs
This is depicted in the following figure:
10.5.F1 Class of Service Implementation Agreement
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
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
disposition (i.e. Color) including Color Identification at the EI (External
Interface) are provided. Place holders for Frame Delay, Frame Delay Variation
and Frame Loss Ratio Performance Objectives are also specified. Values for
these Objectives are to be specified in Phase 2. This IA builds upon previous
work in IEEE, ITU and IETF for consistency, fast development and facilitation
of end-to-end CoS.
The following terms are defined:
CoS Label - a term independent of all Service Provider, Operator and
other standards' CoS names. It is a label used in MEF CoS IA to refer
to a MEF specified class or CoS.
CoS Indication - At the UNI and the ENNI the CoS for a given frame is
indicated by a CoS Identifier
Color Indication At the UNI and ENNI the Color for a given frame is
indicated by the Color Identifier. Color (Green,Yellow or Red) is a
part of the Bandwidth Profile specification.
The 3 CoS Model defines the CoS ID indication by PCP or DSCP bits and the
color indication:
10.5.F2 - 3 CoS Model
Common CoS lexicon between the Service Providers on either side of the
standardized Ethernet interconnect facilitates CoS alignment:
CENs are still free to implement a subset or superset of the CoS
MEF 23 specifies interoperability between CENs using up to 3 MEF CoS, and
any additional number of "proprietary CoS".
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:
10.5.F3 Mapping CoS IDs

10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Carrier Ethernet Service OAM
Ethernet Network Section
When CoS IA is to be applied to an OVC that, along with other OVCs, comprise
an EVC, the CENs associated with the OVCs are referred to as Ethernet
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
EVC has separate per-OVC CPOs that need to have consistency with the UNI-
to-UNI CPOs for the EVC. Each CoS Frame Set associated with an OVC is
assigned a PT for its set of CPOs. The ENS Model is referring to the
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
CPOs to verify consistency with EVC CPOs (for example, when an EVC
comprised of 2 OVCs). This is illustrated in the following figure:
Figure 10.5.1.F1 - ENS Model Illustration
[Source MEF 23.1 Figure 4]

In this example, the EVC traverses an ENNI that connects two CENs. The EVC
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
will still have a UNI-to-UNI CPO set based on PT3 as represented by the
bracket on top. The OVCs that comprise the EVC may have CPOs as
represented by the bottom brackets.
The OVC in CEN1 (UNI-to-ENNI) uses PT1 and the OVC in CEN2 uses PT2 set of
CPOs. Each of these OVCs is aligned with an ENS within an ENS Model that will
relate OVC CPOs to the EVC CPOs using concatenation of OVC CPOs.
Even after measuring the performance on each OVC, the concatenation of the
results to the EVC's level is not trivial. For example when one measures
percentiles, there is no additivity.
Note that the OVC CPO values in PTs 1-4 in MEF 23.1 are not likely to
concatenate precisely to the EVC CPO values in the PT 1-4 tables in in MEF
23.1 The methods, techniques and negotiations needed to arrive at
acceptable objectives are beyond the scope of MEF 23.1 and this study guide.

10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Class of Service Label Model
The CoS Label Model Tables provide normative information for each MEF CoS
Label in a Three CoS Label Model.
This does not preclude implementation of a subset or superset of the CoS in
the Carrier Ethernet Networks.
The Tables provide:
CoS Label
Class of Service Performance Objectives (CPO)
Bandwidth Profile constraints
CoS Identifier
Color Identifier
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
in MEF 23.1.
FD, MFD, IFDV, FDR and FLR CPOs are specified normatively as one of the
following:
1. Numeric values expressed in milliseconds (ms) for FD, MFD, IFDV and
FDR. FLR is expressed as a decimal number representing a percentage.
2. Unspecified performance for a particular CPO for a given CoS Label via
N/S
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
In MEF 23 (CoS IA Phase 1), CPOs were expressed in relative terms. In
contrast, inn MEF 23.1 (CoS IA Phase 2) CPOs are expressed using values.
In Phase 2, the Phase 1 CoS Model table is divided into several ???
Since MEF 23.1 supports a Three CoS Label Model and its subsets, there is a
need to interwork or map between the subsets.
Example
The Operator of CEN 1 adopts all CoS Labels in the Three CoS Label Model.
The Operator of CEN 2 adopts a subset with 2 CoS Labels including CoS Labels
H and L. If CEN 1 and CEN 2 are connected via an ENNI there must be
mapping between the two models. Specific mapping may be defined in future
phases of MEF CoS IA.
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
Operators may use the PCP (i.e., 4, 6,7) and DSCP values not specified.
Table 2 introduces the CoS Labels and specifies the Bandwidth Profile
constraints and CoS ID types in Phase 2.
Table 3 provides the PCP and DSCP values used for per frame Color ID when
CoS ID type is EVC or OVC EP.
Table 4 identifies the PCP and DSCP values to be used to identify the CoS
Label and per frame Color ID when CoS ID type is PCP or DSCP.
Note that the EVC or OVC part of the CoS Identifier is not explicitly shown for
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
EVC or OVC EP, e.g., PCP values are not relevant to CoS ID or may not be
present as in the case of an EVC with only untagged frames.
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
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).
In IEEE 802.1ad there is a traffic class called Best Effort which is associated
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
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.
10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
10.5.2.T1 Class of Service Label Model Table 2
while the case of CIR > 0 will require conformance with CPOs.
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.
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.
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Carrier Ethernet Service OAM
Performance Parameters
Table 5 of MEF 23.1 specifies Performance Parameters required to derive and
specify CPOs. The CPOs in Table 6, Table 7, Table 8 and Table 9 are based on
the parameter values in Table 5.
For a given CPO value, an Operator can provide parameter values less than
the maximum or more than the minimum parameter values (i.e. more
stringent parameter values) and still be compliant with MEF 23.1 IA.
From a Service OAM Performance Monitoring (SOAM-PM) point of view, these
parameter values provide a basis for how the measurements are made for the
CoS Frame Sets. In Phase 2, parameters associated with each performance
metric are stated separately for each CoS Label due to variances in
Percentiles, though the values are uniform across PTs.
In MEF 23.1 the scope of CPOs is limited to Point-to-Point EVC/OVC types -
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
performance metrics with similar parameters. Parameters may not be
specified (i.e., N/S) in MEF 23.1 when the associated CPOs are not specified
(i.e., N/S).
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Figure 10.5.3.T1 - Table 5: CoS Label H, M and L Parameter Values
Tables 6, 7, 8 and 9 provide CPOs for each performance metric per each CoS
Label. Each Table provides CPOs for one PT of the four PTs. These are
normative as per the requirements that refer to them.
Note: Multipoint includes Rooted Multipoint.
Figure 10.5.3.T2 - Table 6: Metro PT CPOs
10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
Figure 10.5.3.T3 - Table 7: Regional PT CPOs

Figure 10.5.3.T4 - Table 8: Continental PT CPOs

Figure 10.5.3.T5 - Table 9: Global PT CPOs
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.

ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback

Home About Contact
Performance Management Implementation
This section describes how performance metrics are taken into account in
three different scenarios:
Multi-CoS EVC
Using a Bandwidth Profile
Interconnect via ENNI

In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Multi-CoS EVC
Performance objectives are defined for a given CoS ID of an EVC. Each EVC
supports up to 8 CoS IDs and each can potentially have its own performance
objectives. For example, an EVC with 3 CoS named H, M, L might have the
following performance objectives:
10.6.1.T1 - Example CoS Performance Obj ectives
All objectives are specified over time interval T of 60 minutes. Assuming that
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,
each of the MEPs will trigger ETH-DM procedure every 1 second for each of
the CoS. MEP A will send 3 ETH-DM with the CE-VLAN ID of the EVC and with:
1. PCP value mapped to H CoS
2. PCP value mapped to M CoS
3. PCP value mapped to L CoS
When multiple PCP values map to a single CoS ID, the PCP that yields the
lowest loss is used. Therefore once a second there are 6 procedures initiated
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
(2 MEPs, 3 CoS each) At the end of the 60 minutes interval, each MEP
calculates the IFDV for each CoS ID and reports the measurement. This
measurement is compared with the performance objective for the given CoS
ID.
In the CoS Performance objectives example above, when we consider FLR we
see that there is no objective set for the L CoS ID. Therefore, the ETH-LM
procedure is executed at each MEP only for 2 CoS (H and M). We also see that
Availability is not computed since it was not specified as a performance
objective for this service instance.

10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Relationship to Bandwidth Profile
Performance objectives for an EVC apply only for service frames that meet all
the following conditions:
They are mapped to the EVC
Delivery rules allow delivery to the egress UNI(s)
The ingress bandwidth profile declared them as green frames
The frame size is no greater than the EVC's MTU size
It should be noted that frames dropped by the egress BWP do count against
the SLS's performance objectives. From this definition it is clear that a Best
Effort service (ingress BWP per EVC set with CIR=0, CBS=0) yields no
performance objectives, as no frame would meet the above criteria. In the
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.

In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Interconnection via ENNI
MEF 26.0.3 defines performance objectives for an OVC. The performance
objectives will be further enhanced in the coming MEF 23.1 specification.
An E-Line may traverse multiple CENs. In the following example an E-Line
comprises two Point-to-Point OVCs.
10.6.3.F1 - E-Line
Calculating the performance objectives for each OVC in order to meet specific
EVC performance objectives is made challenging by the fact that the
percentiles and FLR are not additive.
Future versions of MEF 23 and MEF SOAM PM specifications are expected to
provide solutions for this use case.

In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact

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]."
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Download
Download
Home About Contact

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

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Home About Contact

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.

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Home About Contact
Test Objectives 10 1
Service Operations, Administration and Maintenance (SOAM)
10.1 Describe the various partitioning of responsibilities for Service Operations
Administration and Maintenance (SOAM).
10.2 Describe the basic mechanisms for fault management.
10.3Describe the basic mechanisms for performance management.
10.4 Describe the basic metrics for performance management.
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact

IEEE 802.1AX
Link Aggregation
Specification
Abstract:
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Download
Download
Home About Contact

IEEE 802.1AX
Link Aggregation
Specification
Abstract:
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Download
Download
Home About Contact

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
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
The MEF has prepared an overview presentation which explains the MEF 9 ATS.
Download
Home About Contact

MEF 14
Abstract Test Suite for Traffic Management Phase 1

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
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
The MEF has prepared an overview presentation which explains the MEF 14 Abstract Test Suite.
Download
Home About Contact

MEF 18
Abstract Test Suite for Circuit Emulation Services over Ethernet
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
Download
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Home About Contact

Global Interconnect

Download

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Home About Contact

Diagrams: Fundamentals of Carrier Ethernet
Figure 1.1.F1: 5 Attributes of Carrier
Ethernet
Figure 1.1.F2: Typical Carrier
Ethernet Network
Figure 1.2.F1: E-Line Carrier
Ethernet service type
Figure 1.2.F2: E-LAN Carrier Ethernet
service type
Figure 1.2.F3: E-Tree Carrier Ethernet
service type
Figure 1.3.F1: Example EVP-Tree
Figure 1.3.F2: Multiple Carrier
Ethernet services using single UNI

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page

Home About Contact

Diagrams: Carrier Ethernet Services over Transport Technologies
2.1.1.1.F1 - C-Tag Frame Format
2.1.1.1.F2 - C-Tag Format

2.1.1.1.T1 - Bridging support for
Carrier Ethernet Services
2.1.1.2.F1 - Double Tag Frame Format
2.1.1.2.F2 - S-Tag Format
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
2.1.1.2.T1 - Provider Bridging Support
for Carrier Ethernet Services
2.1.1.3.F1 - Evolving Frame Format

2.1.1.3.T1 - Provider Backbone
Bridging Support for Carrier Ethernet
Services
2.1.1.4.T1 - PBB-TE Support for
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.2.2.T1 - VPWS Support for Carrier
Ethernet Services
2.1.2.3.T1 - MPLS-TP Support for
2.1.3.1.F1 - Network Architecture
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
Ethernet Services
2.1.3.3.F1 - WDM
2.1.3.3.T1 - WDM
Support for Carrier
Ethernet Services

Home About Contact

Diagrams: Carrier Ethernet Services over Access Technologies
3.1.F1 - Carrier Ethernet Services
over Access Infrastructures

3.1.1.F1 - Carrier Ethernet and HFC
3.1.2.F1 - Carrier Ethernet Services
over PON Infrastructures
3.1.3.F1 - Carrier Ethernet over
Packet Wireless
3.1.3.F2 - Access Technologies for
Carrier Ethernet Mobile Backhaul

3.1.4.F1 - Carrier Ethernet over
DS3/E3
3.1.4.T1 Summary Table for Carrier
Ethernet over PDH
3.1.6.F1 Carrier
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
3.1.5.F1 Carrier Ethernet over Fiber
Ethernet over Bonded
Copper

Home About Contact

Diagrams: Key Components of Carrier Ethernet
Figure 4.1.F1 - Subscribers, Service
Providers and Operators
Figure 4.2.F1 - Basic Service Model
per MEF 10.2
Figure 4.2.F2 - UNI-C and UNI-N
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

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Home About Contact

Diagrams: Attributes of Carrier Ethernet Services
Figure 5.F1 - Type-Attribute-Attribute
Parameter
Figure 5.2.T1 - UNI Service
Attributes
Figure 5.2.T2 - Attribute
Combinations
Figure 5.2.T3 - MACs for Bridge and
GARP
Figure 5.2.T4 - Untagged frame at
the UNI
Table 5.2.T5 - MACs for Bridge and
GARP
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Table 5.2.T6 - L2CP Protocols and
Associated Ethertypes and Subtypes
Figure 5.2.F1 - 'Peer' action
Figure 5.2.F2 - 'Pass to EVC' action
Figure 5.3.F1 - Mapping CE-VLAN IDs to
EVCs
Figure 5.3.T1 - Mapping CE-VLAN IDs
to EVCs

Figure 5.3.F2 - Mapping CE-VLAN IDs to
EVCs
Figure 5.4.F1 - Preserving Customer
VLAN-IDs
Figure 5.4.F2 - CE-VLAN ID
Preservation Example
Figure 5.4.T1 - Protocols Figure 5.4.T2 - EVCs and CoS ID
example
Figure 5.5.F1 - Operator to Operator
ENNI
Figure 5.5.T1 - ENNI Frame Tags Figure 5.6.1.F2 - Service Frame in
Hairpin Switching
Figure 5.6.T1 - Correspondence
between Ingress and Egress
Figure 5.6.T2 - Correspondence Ingress
to Egress 2
Figure 5.6.T3 - CE-VLAN CoS
Preservation
Figure 5.7.T1 - H, M, L - Green Color
Figure 5.7.T2 - H, M, L - Yellow Color Figure 5.7.T3 - Ingress Bandwidth
Profile Compliance
Figure 5.7.F1 Bandwidth Profile per
OVC
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
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
variation
Figure 5.10.F3 - Frame loss ratio

Home About Contact

Diagrams: MEF Certification of Carrier Ethernet Services
Currently, there are no diagrams in section 6.

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Home About Contact

Diagrams: Typical Target Applications for Carrier Ethernet Services
Figure 7.1.F1: Example - Turbo 2000
Internet Access, Inc.
Table 7.1.T1: Example - UNI Service
Attributes
Table 7.1.T2: Example - EVC Service
Attributes
Table 7.1.T3: Example - EVC per UNI
Service Attributes
Figure 7.2.F1 Figure 7.2.F3
Table 7.2.T1 Table 7.2.T2 Figure: 7.3.F1
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
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
UNI-NI
Figure 1 (7.3.2.F1) - Generic
Interworking Function with Legacy
MBH Network
Figure 2 (7.3.2.F2) - Generic
Interworking Function without Legacy
Network
Figure 3 (7.3.2.F3) - UNI with MBH
Legacy Network
Figure 4 (7.3.2.F4) - UNI without
Legacy MBH Network
Figure 7.4.F1 - Example Business
Services Application
Figure 7.4.T1
Figure 7.4.T2
Figure 7.4.T3 Figure 7.4.F2 - Operators and Service
Providers for Business Services
Applications
Figure: 7.4.T4
Figure 7.5.F1 - PBX over legacy PDH
and SONET
Figure 7.5.F2 - PBX over Carrier
Ethernet
Figure 7.6.F1 - Legacy ATM-FR
Figure 7.6.F2 - Carrier Ethernet
replacing ATM-FR
Figure 7.6.T1 - Table of CE-VLAN ID
per EVC
Figure 7.7.F1 - 3 E-Lines replace WDM
Figure 7.7.F2 1 E-LAN replaces WDM

Home About Contact

Diagrams: Positioning of Carrier Ethernet with other Technologies
Figure 8.2.F1: Carrier Ethernet and
IP/MPLS Core Network

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
Home About Contact

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.F1 - Sync Parameters
Figure 9.4.1.F1 - Packet Based
Methods
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
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
Clocks
Figure 9.4.1.3.F4 -Peer to Peer
Figure 9.4.2.F1 - Synchronization using
Synchronous Ethernet

Home About Contact

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
Entities
10.2.2.1.F1 - SOAM Service Scope
10.2.2.1.F2 - SOAM Maintenance Entities
10.3.2.1.F1 - Example use of
SOAM CCM
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
10.3.2.2.F1 - Example use of
SOAM LBM
10.3.2.3.F1 - SOAM LTM
10.4.1.F1 - Performance
monitoring definition
10.4.2.1.F1 - DMM 10.4.2.2.F1 - SOAM Loss Measurement
10.4.3.1.F1 - Inter-Frame Delay
Variation Performance
10.4.3.2.F1 - Frame Loss Ratio
10.4.3.3.F1 -Availability for Small Time
Intervals
10.4.2.0.F1 - Frame Delay for
Service Frame 10.5.F1 Class of Service
Implementation Agreement
10.5.F2 - 3 CoS Model
10.5.F3 Mapping CoS
IDs
Figure 10.5.1.F1 - ENS Model
Illustration
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.T2 - Table 6: Metro
PT CPOs

Figure 10.5.3.T3 - Table 7:
Regional PT CPOs
Figure 10.5.3.T4 - Table 8: Continental PT
CPOs

Figure 10.5.3.T5 - Table 9: Global
PT CPOs
10.6.1.T1 - Example CoS
Performance Obj ectives
10.6.3.F1 - E-Line

Home About Contact

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
Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
provided showing use cases of some of the defined services."
Download

Currently, there is no MEF reference presentation available for MEF 33.



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

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.
Page i

Table of Contents
1. ABSTRACT ...............................................................................................................................................................1
2. TERMI NOLOGY ......................................................................................................................................................1
3. SCOPE........................................................................................................................................................................6
3.1 SCOPE OF FUTURE PHASES ...................................................................................................................................6
4. COMPLIANCE LEVELS.........................................................................................................................................7
5. I NTRODUCTI ON.....................................................................................................................................................7
6. ETHERNET SERVI CE DEFI NI TI ON FRAMEWORK (NORMATI VE)..........................................................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. SERVI CE DEFI NI TI ONS (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 (NORMATI VE) ............................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. SERVI CE 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 (I NFORMATI VE)................................................42
12. APPENDIX B: PRACTI CAL EXAMPLES OF ETHERNET SERVICES (INFORMATI VE).......................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
Page ii

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
Page iii

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
Page 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
Bundling
A UNI attribute in which all CE-VLAN IDs are associated
with a single EVC.
[2]
Availability
Performance
A measure of the percentage of time that a service is useable. [2]
Bandwidth Profile
A characterization of Service Frame arrival times and
lengths at a reference point and a specification of the
disposition of each Service Frame based on its level of
compliance with the Bandwidth Profile. In this document
the reference point is the UNI.
[2]
Bandwidth profile
per CoS I D
A bandwidth profile applied on a per-Class of Service basis.
[2]
Bandwidth profile
per EVC
A bandwidth profile applied on a per-EVC basis.
[2]
Bandwidth profile
per UNI
A bandwidth profile applied on a per-UNI basis.
[2]
Broadcast Service
Frame
A Service Frame that has the broadcast destination MAC
address.
[2]
Bundling
A UNI attribute in which more than one CE-VLAN ID can
be associated with an EVC.
[2]
CBS Committed Burst Size [2]
CE Customer Edge [2]
CE-VLAN CoS Customer Edge VLAN CoS [2]


MEF 6.1
Page 2

CE-VLAN CoS
Preservation
An EVC attribute in which the CE-VLAN CoS of an egress
Service Frame is identical in value to the CE-VLAN CoS of
the corresponding ingress Service Frame.
[2]
CE-VLAN I D Customer Edge VLAN ID [2]
CE-VLAN I D
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.
[2]
CE-VLAN I D /
EVC Map
An association of CE-VLAN IDs with EVCs at a UNI.
[2]
CE-VLAN Tag Customer Edge VLAN Tag [2]
CF Coupling Flag [2]
CI R Committed Information Rate [2]
Class of Service
A set of Service Frames that have a commitment from the
Service Provider to receive a particular level of performance.
[2]
Class of Service
I dentifier
An indicator for a particular CoS instance. 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 than one CE-
VLAN CoS values, c) the combination of the EVC to which
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.
[2]
CM Color Mode [2]
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.
[2]
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.
[2]
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
[2]
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.
[2]


MEF 6.1
Page 3

Committed
I nformation Rate
CIR is a Bandwidth Profile parameter. It defines the average
rate in bits/s of Service Frames up to which the network
delivers Service Frames and is committed to meeting the
performance objectives defined by the CoS Service
Attribute.
[2]
CoS Class of Service [2]
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.
[2]
Customer Edge Equipment on the Subscriber side of the UNI. [2]
Customer Edge
VLAN CoS
The Priority Code Point bits in the IEEE 802.1Q Customer
VLAN Tag in a Service Frame that is either tagged or
priority tagged.
[2]
Customer Edge
VLAN I D
The identifier derivable from the content of a Service Frame
that allows the Service Frame to be associated with an EVC
at the UNI.
[2]
Customer Edge
VLAN Tag
The IEEE 802.1Q Customer VLAN Tag in a tagged Service
Frame.
[2]
EBS Excess Burst Size [2]
Egress Bandwidth
Profile
A service attribute that specifies the length and arrival time
characteristics of egress Service Frames at the egress UNI.
[2]
Egress Service
Frame
A Service Frame sent from the Service Provider network to
the CE.
[2]
EI R Excess Information Rate [2]
E-LAN Service
An Ethernet service type that is based on a Multipoint-to-
Multipoint EVC.
This
Document
E-Line Service
An Ethernet service type that is based on a Point-to-Point
EVC.
This
Document
EPL Ethernet Private Line
This
Document
E-Tree Service
An Ethernet service type that is based on a Rooted-
Multipoint EVC.
This
Document
Ethernet Virtual
Connection
An association of two or more UNIs that limits the exchange
of Service Frames to UNIs in the Ethernet Virtual
Connection.
[2]
EVC Ethernet Virtual Connection [2]
EVC MTU Size The maximum sized Service Frame allowed for an EVC. [2]
EVPL Ethernet Virtual Private Line
This
Document


MEF 6.1
Page 4

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.
[2]
Excess
I nformation 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.
[2]
FDX Full Duplex [5]
FD Frame Delay [2]
FDV Frame Delay Variation [2]
FLR Frame Loss Ratio [2]
Frame Short for Ethernet Frame [2]
Frame Delay
The time required to transmit a Service Frame from ingress
UNI to egress UNI.
[2]
Frame Delay
Performance
A measure of the delays experienced by different Service
Frames belonging to the same CoS instance.
[2]
Frame Delay
Variation
The difference in delay of two Service Frames.
[2]
Frame Delay
Variation
Performance
A measure of the variation in the delays experienced by
different Service Frames belonging to the same CoS
instance.
[2]
Frame Loss Ratio
Performance
Frame Loss Ratio is a measure of the number of lost frames
between the ingress UNI and the egress UNI. Frame Loss
Ratio is expressed as a percentage.
[2]
I ngress
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.
[2]
I ngress Service
Frame
A Service Frame sent from the CE into the Service Provider
network.
[2]
Layer 2 Control
Protocol Service
Frame
A Service Frame that is used for Layer 2 control, e.g.,
Spanning Tree Protocol.
[2]
Layer 2 Control
Protocol
Tunneling
The process by which a Layer 2 Control Protocol Service
Frame is passed through the Service Provider network
without being processed and is delivered unchanged to the
proper UNI(s).
[2]
Maximum
Number of EVCs
The maximum number of EVCs that may be on a UNI. [2]


MEF 6.1
Page 5

Maximum
number of UNI s
The maximum number of UNIs that may be in an EVC. [2]
MEN Metro Ethernet Network [12]
Metro Ethernet
Network
The Service Providers network providing Ethernet services.
[12]
MNU Maximum Number of UNIs [2]
MTU Maximum Transmission Unit
This
Document
MTU size
The maximum sized Service Frame allowed for an Ethernet
service.
[2]
Multicast Service
Frame
A Service Frame that has a multicast destination MAC
address.
[2]
Multipoint-to-
Multipoint EVC
An EVC with two or more UNIs. 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 it.
[2]
N/A Not Applicable
N/S Not Specified
Point-to-Point
EVC
An EVC with exactly 2 UNIs.
[2]
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.
[2]
Service Frame
An Ethernet frame transmitted across the UNI toward the
Service Provider or an Ethernet frame transmitted across the
UNI toward the Subscriber.
[2]
Service Frame
Delivery
An EVC service attribute defined in [2]
[2]
Service Level
Agreement
The contract between the Subscriber and Service Provider
specifying the agreed to service level commitments and
related business agreements.
[2]
Service Level
Specification
The technical specification of the service level being offered
by the Service Provider to the Subscriber.
[2]
Service
Multiplexing
A UNI service attribute in which the UNI can be in more
than one EVC instance.
[2]
Service Provider The organization providing Ethernet Service(s). [2]
SLA Service Level Agreement [2]
SLS Service Level Specification [2]


MEF 6.1
Page 6

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
Frame
A Service Frame that has a unicast destination MAC
address.
[2]
User Network
I nterface
The physical demarcation point between the responsibility of
the Service Provider and the responsibility of the Subscriber.
[2]
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
Page 7

4. Compliance Levels
The key words MUST, MUST NOT, REQUI RED, SHALL, SHALL NOT,
SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTI ONAL 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
Page 8

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 I D)
Ethernet Private Line Ethernet Virtual Private Line E-Line
1
(EPL) (EVPL) (point-to-point EVC)
Ethernet Private LAN Ethernet Virtual Private LAN E-LAN
(EP-LAN) (EVP-LAN) (multipoint-to-multipoint EVC)
Ethernet Private Tree Ethernet Virtual Private Tree E-Tree
(EP-Tree) (EVP-Tree) (rooted multipoint EVC)
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
Page 9

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
Speed
10 Mbps, 100 Mbps, 10/100 Mbps Auto-negotiation, 10/100/1000
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.
All to One Bundling
Yes or No. MUST be No if Bundling or Service Multiplexing is
Yes.
CE-VLAN ID for untagged
and priority tagged Service
Frames
MUST specify CE-VLAN ID for untagged and priority tagged
Service Frames in the range of 1-4094. This requirement does not
apply for services with all to one bundling at the UNI.
Maximum number of
EVCs
MUST be an integer 1.
Per UNI
OPTI ONAL. If supported, MUST specify <CIR, CBS, EIR,
EBS, CM, CF>. MUST NOT be combined with any other type of
ingress bandwidth profile.
Egress Bandwidth Profile
Per UNI
egress bandwidth profile.
Layer 2 Control Protocols
Processing
For each protocol, MUST specify one of: Peer, Discard, Pass to
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
Page 10
Point-to-Point EVC Point-to-Point EVC

Metro Ethernet
Network
UNI UNI
Metro Ethernet
Network
UNI UNI

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
ID.
UNI EVC ID
MUST specify the mapping table of CE-VLAN IDs to the EVC at
the UNI.
Per EVC
OPTI ONAL. If supported, MUST specify CoS ID per [2],
section 6.8, and MUST specify <CIR, CBS, EIR, EBS, CM, CF>
for each CoS. MUST NOT be combined with any other type of
Per CoS Identifier
Per EVC
3
MUST NOT specify .

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
Page 11

EVC per UNI Service
Attribute
E-Line Service type Requirement
Per CoS Identifier
MUST NOT specify.
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.
EVC ID
An arbitrary string, unique across the MEN, for the EVC
supporting the service instance.
UNI List
MUST provide the list of UNI Identifiers and type for each UNI
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
Preservation
MUST be either Yes or No
Unicast Service Frame
Delivery
Deliver Unconditionally or Deliver Conditionally. If Delivered
Conditionally, MUST specify the delivery criteria.
Multicast Service Frame
Delivery
Broadcast Service Frame
Delivery
Layer 2 Control Protocol
Processing (only applies
for L2CPs passed to the
EVC)
For each protocol passed to the EVC, MUST specify one of:
Tunnel or Discard.
EVC Performance
At least one CoS is REQUI RED. MUST specify CoS ID, per
section 6.8 of [2]. MUST list values for each of the following
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
Page 12
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.
Multi poi nt-to-Multipoint EVC Multi poi nt-to-Multipoint EVC
UNI
UNI
UNI
UNI
Metro Ethernet
Network
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
ID.
UNI EVC ID
MUST specify the mapping table of CE-VLAN IDs to the EVC at
the UNI.
OPTI ONAL. If supported, MUST specify <CIR, CBS, EIR, EBS,
CM, CF>
Per EVC
[2]. MUST NOT be combined with any other type of


MEF 6.1
Page 13

EVC per UNI Service
Attribute
E-LAN Service type Requirement
Per CoS Identifier
OPTI ONAL. If supported, MUST specify CoS ID per [2], section
6.8, and MUST specify <CIR, CBS, EIR, EBS, CM, CF> for each
CoS. MUST NOT be combined with any other type of ingress
bandwidth profile.
Per EVC
OPTI ONAL. If supported, MUST specify <CIR, CBS, EIR, EBS,
CM, CF> [2]. MUST NOT be combined with any other type of
Per CoS Identifier
OPTI ONAL. If supported, MUST specify CoS ID per [2], section
6.8, and MUST specify <CIR, CBS, EIR, EBS, CM, CF> for each
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
the E-LAN Service type.

EVC Service Attribute E-LAN Service type Requirement
EVC Type MUST be Multipoint-to-Multipoint.
EVC ID
UNI List
associated with the EVC. UNI Type must be Root for each UNI
Maximum Number of UNIs MUST be 2.
CE-VLAN CoS
Preservation
Delivery
Delivery
Delivery


MEF 6.1
Page 14

EVC Service Attribute E-LAN Service type Requirement
Processing (only applies for
L2CPs passed to the EVC)
For each protocol passed to the EVC, MUST specify one of:
Tunnel or Discard.
Ratio, and Availability} for each CoS, where Not Specified (N/S)
is an acceptable value.
EVC Performance
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.
Leaf UNI
Rooted
Multi poi nt EVC

Metro Ethernet
Network
Root UNI
Leaf UNI Leaf UNI
Leaf UNI
Root UNI
Rooted
Multi poi nt EVC
Root UNI
Leaf UNI
Metro Ethernet
Network
Root UNI
Leaf UNI Leaf UNI
Leaf UNI

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
Page 15
Root UNI
Root UNI

Rooted-
Multipoi nt 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.
MUST specify the mapping table of CE-VLAN IDs to the EVC at the
UNI.
CE-VLAN ID / EVC
Map
OPTI ONAL. If supported, MUST specify <CIR, CBS, EIR, EBS, CM,
CF>
Ingress Bandwidth
Profile Per EVC
[2]. MUST NOT be allowed if any other ingress bandwidth
profile is applied at this UNI for this EVC.
OPTI ONAL. If supported, MUST specify CoS ID per [2], section 6.8,
and MUST specify <CIR, CBS, EIR, EBS, CM, CF> for each CoS.
MUST NOT be combined with any other type of ingress bandwidth
profile.
Ingress Bandwidth
Profile Per CoS
Identifier
OPTI ONAL. If supported, MUST specify <CIR, CBS, EIR, EBS, CM,
CF>
Egress Bandwidth
Profile Per EVC
[2]. MUST NOT be combined with any other type of egress
bandwidth profile.
OPTI ONAL. If supported, MUST specify CoS ID per [2], section 6.8,
and MUST specify <CIR, CBS, EIR, EBS, CM, CF> for each CoS.
MUST NOT be combined with any other type of egress bandwidth
profile.
Egress Bandwidth
Profile Per CoS
Identifier


MEF 6.1
Page 16

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
the E-Tree Service type.
EVC Service Attribute E-Tree EVC Service type Requirement
EVC Type MUST be Rooted-Multipoint
EVC ID
An arbitrary string, unique across the MEN, for the EVC supporting
the service instance.
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
UNIs
MUST be 2
CE-VLAN ID
Preservation
CE-VLAN CoS
Preservation
Delivery
Delivery
Delivery
Processing (only applies
for L2CPs passed to the
EVC)
For each protocol passed to the EVC, MUST specify one of: Tunnel
or Discard
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
Page 17
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
UNI UNI
P2P EVC
CE CE

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
10 Mbps, 100 Mbps, 10/100 Mbps Auto-negotiation,
10/100/1000 Mbps Auto-negotiation, 1 Gbps, or 10 Gbps
Speed
MUST be Full Duplex Mode
MUST be 1522 UNI MTU Size
MUST be No Service Multiplexing
MUST be No Bundling
MUST be Yes All to One Bundling


MEF 6.1
Page 18

Frames
All untagged and priority tagged Service Frames at the UNI
MUST map to the same EVC as is used for all other Service
Frames.
Maximum number of EVCs MUST be 1
Ingress Bandwidth Profile Per
UNI
MUST NOT specify
5
Egress Bandwidth Profile Per
UNI
MUST NOT specify
Processing
MUST specify in accordance with Section 8.1 of this document.
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
Attribute
Service Attribute Parameters and Values
UNI EVC ID
A string formed by the concatenation of the UNI ID and the
EVC ID.
All Service Frames at the UNI MUST map to a single Point-to-
Point EVC.
EVC
EBS, CM, CF>. MUST NOT be combined with any other type
of ingress bandwidth profile.
CoS ID
section 6.8, and MUST specify <CIR, CBS, EIR, EBS, CM,
CF> for each CoS. MUST NOT be combined with any other
type of ingress bandwidth profile
EVC
MUST NOT specify
CoS ID
MUST NOT specify
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
EVC ID

5
See Ingress Bandwidth Profile per EVC service attribute in Table 11.


MEF 6.1
Page 19

UNI List
MUST list the two UNIs associated with the EVC. The UNI
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
Delivery
MUST Deliver Unconditionally
Delivery
Delivery
EVC Performance
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
Page 20
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.
Metro Ethernet
Network
Service
Multiplexing
Blue
EVC
Yellow
EVC
Green
EVC

Figure 7 below shows the basic structure of EVPL service.

Metro Ethernet
Network
Service
Multiplexing
Blue
EVC
Yellow
EVC
Green
EVC

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.

Speed
SHOULD be supported at one or more UNIs. Service Multiplexing
Yes or No. If Yes, then CE-VLAN ID Preservation MUST be
Yes.
Bundling
MUST be No All to One Bundling


MEF 6.1
Page 21

Frames
Service Frames in the range of 1-4094.
UNI
UNI
of egress bandwidth profile.
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
Attribute
UNI EVC ID
EVC ID.
CE-VLAN ID / EVC Map MUST specify mapping table of CE-VLAN IDs to the EVC ID.
EVC
CoS ID
type of ingress bandwidth profile.
EVC
MUST be No
CoS ID
MUST be No
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 Type MUST be Point-to-Point
EVC ID


MEF 6.1
Page 22

UNI List
MUST list the two UNIs associated with the EVC. The UNI
type MUST be Root for each UNI.
CE-VLAN CoS Preservation MUST be either Yes or No
Delivery
Delivery
Delivery
EVC Performance
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 I D


MEF 6.1
Page 23
preservation. I n addition, EP-LAN supports CE-VLAN CoS preservation.
Metro Ethernet
Network
MP2MP EVC

Figure 8 below shows the basic structure of EP-LAN service.

Metro Ethernet
Network
MP2MP EVC

Figure 8: Ethernet Private LAN (EP-LAN) Service
Table 18 provides the UNI service attributes, parameters, and values for the EP-LAN service.
Speed
MUST be No Service Multiplexing
MUST be No Bundling
MUST be Yes All to One Bundling
Frames
Frames.
MUST be 1 Maximum number of EVCs
UNI


MEF 6.1
Page 24

UNI
Processing
MUST specify in accordance with Section 8.3 of this
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
Attribute
UNI EVC ID
EVC ID.
All Service Frames at the UNI MUST map to a single
Multipoint-to-Multipoint EVC.
EVC
CoS ID
EVC
CoS ID
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 Type MUST be Multipoint-to-Multipoint
EVC ID
UNI List
MUST list the UNIs associated with the EVC. The UNI type
MUST be Root for each UNI.
EVC MTU size MUST be 1522.


MEF 6.1
Page 25

Delivery
Delivery
Delivery
EVC Performance
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)
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
Page 26
MP2MP EVC
P2P EVC
Value-add
Service
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.

Speed
Yes.
Bundling
Frames
UNI
UNI
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
Page 27

EVC per UNI Service
Attribute
UNI EVC ID
EVC ID.
EVC
EBS, CM, CF>. MUST NOT be combined with any other
ingress bandwidth profile is applied at this UNI for this EVC.
CoS ID
type of Ingress Bandwidth Profile.
EVC
OPTI ONAL. MUST specify <CIR, CBS, EIR, EBS, CM, CF>
for each CoS. MUST NOT be combined with any other type of
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 Type MUST be Multipoint-to-Multipoint
EVC ID
UNI List
MUST list the UNIs associated with the EVC. The UNI type
MUST be Root for each UNI.
Delivery
Delivery
Delivery


MEF 6.1
Page 28

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.
EVC Performance
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 I D
preservation. I n 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
Page 29

Speed
Mode MUST be Full Duplex
UNI MTU Size MUST be 1522
Service Multiplexing MUST be No
Bundling MUST be No
All to One Bundling MUST be Yes
Frames
Frames.
UNI
EBS, CM, CF>. MUST NOT combined with any other type of
UNI
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
Attribute
UNI EVC ID
EVC ID.
All Service Frames at the UNI MUST map to the Rooted-
Multipoint EVC.
EVC
CoS ID


MEF 6.1
Page 30

EVC per UNI Service
Attribute
EVC
CoS ID
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 ID
UNI List
MUST list the UNIs associated with the EVC. The UNI Type
for at least 1 UNI MUST be Root. All UNIs that are not UNI
Type Root MUST be UNI Type Leaf.
Delivery
Delivery
Delivery
L2CP frames passed to the EVC)
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
Page 31
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.

Speed
Yes.
Bundling
Frames


MEF 6.1
Page 32

UNI
UNI
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
Attribute
UNI EVC ID
EVC ID.
EVC
CoS ID
EVC
CoS ID
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 ID
UNI List
MUST list the UNIs associated with the EVC. The UNI Type
for at least 1 UNI MUST be Root. All UNIs that are not UNI
Type Root MUST be UNI Type Leaf.


MEF 6.1
Page 33

Unicast Service Frame Delivery
Delivery
Delivery
L2CP frame passed to the EVC)
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
Page 34

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
Option 1 Option 2
Applicability
STP[3]/RSTP[3]/MSTP[4] 01-80-C2-00-00-00 MUST Tunnel MUST Tunnel All UNIs in the EVC


MEF 6.1
Page 35

PAUSE[5] 01-80-C2-00-00-01
SHOULD
Discard
SHOULD
Discard
All UNIs in the EVC
LACP/LAMP[5] 01-80-C2-00-00-02
SHOULD Peer
or Discard
SHOULD
Tunnel
Option 1: Per UNI
Option 2: All UNIs in
the EVC
Link OAM[5] 01-80-C2-00-00-02
SHOULD Peer
or Discard
SHOULD
Tunnel
Option 1: Per UNI
the EVC
Port Authentication[7] 01-80-C2-00-00-03
SHOULD Peer
or Discard
SHOULD
Tunnel
Option 1: Per UNI
the EVC
E-LMI[9] 01-80-C2-00-00-07
SHOULD Peer
or Discard
MUST Tunnel
Option 1: Per UNI
the EVC
LLDP[8] 01-80-C2-00-00-0E
SHOULD
Discard
MUST Tunnel All UNIs in the EVC
GARP[4]/MRP[17] Block
01-80-C2-00-00-20
through
01-80-C2-00-00-2F
MUST Discard
or Tunnel
MUST Tunnel All UNIs in the EVC
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
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
through
01-80-C2-00-00-2F
MUST Peer, Tunnel or
Discard
Per UNI
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


MEF 6.1
Page 36

STP[3]/RSTP[3]/MSTP[4] 01-80-C2-00-00-00
SHOULD Tunnel
MAY Discard
All UNIs in the EVC
01-80-C2-00-00-20
through
01-80-C2-00-00-2F
Discard
Per UNI
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
01-80-C2-00-00-20
through
01-80-C2-00-00-2F
Discard
Per UNI
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


MEF 6.1
Page 37

STP[3]/RSTP[3]/MSTP[4] 01-80-C2-00-00-00
SHOULD Tunnel
6
MAY Discard
All UNIs in the EVC
01-80-C2-00-00-20
through
01-80-C2-00-00-2F
Discard
Per UNI
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
01-80-C2-00-00-20
through
01-80-C2-00-00-2F
Discard
Per UNI
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
Page 38

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
Page 39

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
Page 40

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
Page 41

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
Page 42

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 I EEE 802.1 Term
Peer Participate
Tunnel Forward (relay)
Discard Not forward, Not participate
Table 37: MEF and I EEE 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
Page 43

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
Class of Service Offering
EVC Performance
Attribute
Parameters
Krypton Argon Neon
CoS ID (Priority Code Point
value)
N/A PCP=5 PCP=4 PCP=0
Subset of ordered UNI
pairs (S)
All All All
FD Objective X ms Y ms (Y>X) Z ms (Z>Y)
Percentile (P) 95% 95% 95%
Frame Delay (FD)
Time interval (T) 1 hour 1 hour 1 hour
pairs (S)
All All All
FDV objective Q ms N/S N/S
Percentile (P) 95% N/S N/S
Time interval (T) 1 hour N/S N/S
Frame Delay Variation (FDV)
Pair interval (t) 100 ms N/S N/S
pairs (S)
All All All
FLR Objective A% B% (B>A) C% (C>B)
Frame Loss Ratio (FLR)
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
small time intervals (n)
1 1 1
Small time interval (t) 2 minutes 2 minutes 2 minutes
Unavailability frame loss
ratio threshold (Cu)
50% 75% 100%
Availability
Availability frame loss
ratio threshold (Ca)
0% 25% 50%
Table 38: EVC Performance Attributes and Parameters per CoS Offering


MEF 6.1
Page 44

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
PB1 PB2
VLAN-based Services
Spanning Tree Protocols Tunnel Tunnel Discard
PAUSE (802.3x) Discard Discard Discard
LACP/LAMP
Discard (unprotected
UNI)
Peer (protected UNI)
Tunnel
Discard (unprotected 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
Page 45
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.
Network
Metro Ethernet
Network
Site B
EPL1 EVC
Capacity =CIR
U1
U2
Site A
Port Rate =CIR
Port Rate =CIR
Network
Metro Ethernet
Network
Site B
EPL1 EVC
Capacity =CIR
U1
U2
Site A
Port Rate =CIR
Port Rate =CIR

Figure 12: Example of Transport-Oriented Private Data Network I nterconnect 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
tagged Service Frames
NA NA
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
Page 46

Table 41 provides the EVC per UNI attributes for the Private Data Networking example.
UNI Service Attribute UNI s 1 UNI 2
UNI EVC ID U1_EPL1 U2_EPL1
All Service Frames at the UNI
map to a single EPL EVC
Ingress Bandwidth Profile Per EVC N/A N/A
Ingress Bandwidth Profile Per CoS ID
CoS ID = EVC
CIR=1Gbps, CBS=1522, EIR=0,
EBS=0, color blind, CF=0
CoS ID = EVC
CIR=1Gbps, CBS=1522, EIR=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
Page 47

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.
Carrier Ethernet
Network
Carrier Ethernet
Network

Site B
EPL2 EVC
Capacity =X

U3

U4

Site A
Port Rate =Z
Port Rate =Y

Figure 13: Example of Transport-Oriented Public Data Network I nterconnect 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
Page 48

Physical Medium 1000BASE-SX 100BASE-TX
Speed 1 Gbps 100 Mbps
Mode FDX FDX
Bundling No No
NA NA
Ingress Bandwidth Profile UNI N/A N/A
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 EVC ID U3_EPL2 U4_EPL2
Ingress Bandwidth Profile Per CoS ID
PCP = 5:
CIR=20Mbps, CBS=10k,
EIR=0, EBS=0, color blind,
CF=0
PCP = 0:
CIR=10Mbps, CBS=50k,
CF=0
PCP = 5:
CIR=30 Mbps, CBS=10k,
CF=0
PCP = 0:
CIR=5 Mbps, CBS=10k,
EIR=10 Mbps, EBS=50K, color
blind, CF=0
Table 44: EVC per UNI attributes for the public data networking example using EPL Service


MEF 6.1
Page 49

Table 45 provides the EVC attributes for the public data networking example.
EVC ID EPL2
UNI List {U3, U4}
EVC MTU size 1522
Service Performance
CoS ID=5: Krypton CoS
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
Page 50
Metro Ethernet
Network
U3 (Leaf)
U1 (Root )

U2 (Root )
U4 (Leaf) U502 (Leaf)
RMP_123
(EVC)
Metro Ethernet
Network
U3 (Leaf)
U1 (Root )
U2 (Root )
U4 (Leaf) U502 (Leaf)
RMP_123
(EVC)

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 UNI s Leaf UNI s
U1 (primary),
U2 (back-up)
Physical Medium 1000BASE-LX 100BASE-TX
Mode FDX FDX
Bundling No No
1 (but not significant) 1 (but not significant
CIR=1 Mbps, CBS=10KB, EIR=0,
7
Ingress Bandwidth Profile Per UNI N/A 8

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
Page 51

Table 47 provides the EVC per UNI attributes for the video broadcast example.
UNI Service Attribute UNI s 1 & 2 UNI s 3 502
UNI EVC ID U1_RMP123, U2_RMP123 U1_RMP123, ... U502_RMP123
map to a single Rooted-
Multipoint EVC
map to a single Rooted-
Multipoint EVC
Ingress 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 Type Rooted-Multipoint
EVC ID RMP_123
UNI List {U1, Root/U2, Root/U3, Leaf/U4, Leaf/.../U502, Leaf}
9
EVC MTU size 1522
Multicast Service Frame Delivery
Deliver Conditionally: only deliver content subscribed to on a given Leaf
UNI
EVC Performance (for all ordered
UNI pairs where at least one UNI in
each pair is of type Root).
Krypton CoS
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
Page 52
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.
MEN
U2
U50
U4
U3
U1
MP_111
EVP-LAN Service
RMP_333
EVP-Tree Service
MEN
U2
U50
U4
U3
U1
MP_111
EVP-LAN Service
RMP_333
EVP-Tree 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 UNI s 1 & 2 UNI s 3 50
UNI Identifier U1, U2 U3 U50
Physical Medium 1000BASE-LX 100BASE-TX
Mode FDX FDX
Service Multiplexing Yes Yes
Bundling Yes Yes
All to One Bundling No No
1 1
Ingress 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
Page 53

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.
UNI s 1 & 2 UNI s 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
EIR (Mbps) 20 N/A 20 N/A
EBS (KB) 50 N/A 50 N/A
CM Color Blind N/A Color Blind N/A
Ingress Bandwidth
Profile Per CoS ID of
EVC for Neon CoS
on EVC_1
CF 0 N/A 0 N/A
CIR (Mbps) N/A 10 N/A 10
CBS (KB) N/A 20 N/A 20
EIR (Mbps) N/A 0 N/A 0
EBS (KB) N/A 0 N/A 0
CM N/A Color Blind N/A Color Blind
Ingress Bandwidth
EVC for Krypton
CoS on EVC_2
CF N/A 0 N/A 0
CIR (Mbps) 20 N/A 20 N/A
CBS (KB) 70 N/A 70 N/A
EIR (Mbps) 20 N/A 20 N/A
EBS (KB) 70 N/A 70 N/A
CM Color Blind N/A Color Blind N/A
Egress Bandwidth
EVC for Neon CoS
CF 1 N/A 1 N/A
CIR (Mbps) N/A 10 N/A 1
CBS (KB) N/A 20 N/A 15
EIR (Mbps) N/A 0 N/A 0
EBS (KB) N/A 0 N/A 0
CM N/A Color Blind N/A Color Blind
Egress Bandwidth
EVC for Krypton
CoS
CF N/A 0 N/A 0
Table 50: EVC per UNI attributes for the distance learning, business data example


MEF 6.1
Page 54

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
UNI List {U1, Root/U2, Root/.../U50, Root}
{U1, Root/U2, Root/U3,
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
Unicast Service Frame Delivery
Deliver Conditionally: for known D-
MACs only to destination UNI; for
unknown D-MACs, deliver
unconditionally to all destination
UNIs
Deliver Unconditionally
Deliver Conditionally: only deliver
content subscribed to on a given Leaf
UNI
Broadcast Service Frame Delivery Deliver Unconditionally Deliver Unconditionally
Processing
Table 39, VLAN-based Table 39, VLAN-based
EVC Performance
Neon CoS (for all ordered UNI pairs) Krypton CoS (for all ordered UNI
pairs where at least one UNI in each
pair is of type Root)
Table 51: EVC attributes for the distance learning, business data example
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:
Status:
PROPOSED STANDARD
Updated by:
RFC 5462
Authors:
K. Kompella, Ed.
Y. Rekhter, Ed.
Stream:
IETF
Source:
l2vpn (int)
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]
RFC 5921
"A Framework for MPLS in Transport Networks", July 2010
Canonical URL:
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)
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.
RFC 5960
"MPLS Transport Profile Data Plane Architecture", August
2010
Canonical URL:
Status:
PROPOSED STANDARD
Authors:
D. Frost, Ed.
S. Bryant, Ed.
M. Bocci, Ed.
Stream:
IETF
Source:
mpls (rtg)
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]
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.

Point-to-Point Ethernet Virtual Connections
CE
CE
UNI
UNI
CE
CE
UNI
UNI
CE
CE
UNI
UNI
Ethernet Virtual Private Line (EVPL)
CE
CE
UNI
UNI
CE
CE
UNI
UNI
CE
CE
UNI
UNI
CE
CE
UNI
UNI
CE
CE
UNI
UNI
CE
CE
UNI
UNI

Introduction
Corporate IT managers are exploring ways to add
network capacity while maintaining or reducing their
recurring operating expenses. Increasingly,
businesses are moving away from traditional TDM,
Frame Relay or ATM circuits and turning to Carrier
Ethernet Services to address these apparently
conflicting needs. Service providers have responded
with rich offerings that combine heretofore unmatched
scalability and flexible bandwidth options with reliability
and quality of service previously only available with
old-school telecom circuits.

Industry forums and standards bodies like the MEF,
IEEE, ITU-T and IETF have developed the necessary
extensions to the original Ethernet protocol, making it
suitable for service provider applications. For its part,
the MEF has documented numerous technical
requirements for building and managing feature-rich
business-class Ethernet services. In addition, the
MEF has developed a successful certification program
to verify that equipment and services satisfy these
requirements.

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


2 of 11

The Carrier Ethernet technology and market have
evolved to the point where purpose-built hardened
equipment is now used to deliver MEF-certified
services. The MEF technical work resulted in the
formal definition of the carrier-class Ethernet that has
come to be known simply as Carrier Ethernet. The
customer base for Ethernet services has also evolved
from large Enterprises located in fiber-rich
metropolitan centers to those with globally distributed
operations and mid-sized businesses in suburban and
rural settings.

This last point is critical: this shift in the market has
created opportunities and advantages for service
providers who can offer ubiquitous coverage in a cost-
effective and timely manner.

This paper focuses on informing the reader about the
applications and individual advantages of currently
available access technologies. The primary audience
of this paper is the service provider who is interested
in delivering an Ethernet service without boundaries.
However, businesses who are consumers of Carrier
Ethernet services may also find it informative.

A Growing Opportunity with Real-World
Challenges

According to data from Vertical Systems, Carrier
Ethernet Services grew 41% in 2008 and will be a 31
billion dollar worldwide market by 2012. Carrier
Ethernet has been globally embraced by more than 50
service providers and 100 equipment manufacturers.
This figure is growing at an annual rate of 40%.

The number one challenge facing service providers
today is the difficulty of providing access to all their
customer locations. While tremendous investments
have been made to build out their fiber plant, no single
provider can deliver on-net access to wide area
Ethernet services with the same coverage as their
traditional services. The good news is that service
providers and equipment vendors have been actively
working together to tackle these challenges.

Ubiquity Requires Multiple Access Technology
Solutions

With the evolution from best-effort Ethernet services
to higher-performing MEF-certified services, the
primary obstacle confronting Ethernet service delivery
is the difficulty expanding the Ethernet service footprint
and making it available ubiquitously. Or, at a
minimum, making it available to the locations where
business users want to purchase it.

The need for ubiquitous Ethernet service delivery has
driven the development and deployment of a variety of
access technologies, each optimized for different
access situations. Rarely can carriers find a single
access technology that can address all the access
requirements of their region. This problem is even
more pronounced when carriers follow customers out-
of-region into other carriers territories.

Fortunately, it is now possible to deliver a consistent
MEF-certified Ethernet service over a variety of access
architectures using MEF-certified equipment from
multiple vendors. Some of the technologies used to
deliver MEF-certified services include the following
access alternatives:

Ethernet over Fiber (Active Fiber, PON,
SONET/SDH)
Ethernet over PDH (T1/E1, DS3/E3)
Ethernet over Copper (EFMCu)
Wireless Ethernet (WiMAX, Broadband Wireless,
Microwave)
Ethernet over HFC/DOCSIS

The network drawing on the following page illustrates
an access architecture that uses several of these
technologies. When properly deployed, the only
difference among the Ethernet services delivered
across this variety of access technologies is the
maximum bandwidth that can be transported over
each technology. The underlying service definitions
and SLAs can be identical, providing the end user with
a seamless Ethernet experience even while a variety
of different access technologies are in play.


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

3 of 11


4 of 11

Ethernet over Fiber

For applications where it is available or where the
bandwidth requirements dictate it, delivering Ethernet
over optical fiber is an excellent choice. With virtually
unlimited bandwidth support, noise immunity and the
ability to traverse long distances, optical fiber can
provide the performance for the applications of today
and those envisioned for tomorrow.

Active Ethernet
One of the most common Ethernet over Fiber
architectures is point-to-point, where the connection is
from the Service Providers aggregation switch to a
Network Interface Device (NID) located at the
customer premises.

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
infrastructure build-out. Fiber optics as an access
medium is also needed when Ethernet speeds are 1
Gbps or higher.

Benefits of Active Ethernet
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,
which results in customer satisfaction and service
differentiation that enables profitability and customer
retention. 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.

The CAPEX investment in fiber optic infrastructure is a
one-time investment with minimal recurring operational
cost. Fibers ability to service 100 Mbps, Gigabit and 10
Gigabit data rates as well as multiplex multiple channels
using Wavelength Division Multiplexing (WDM) enable it
to support any foreseeable future data rates.
The distances that can be supported by a fiber
infrastructure are limited only by the active interface
hardware. Using standard optics, 2 km-150 km distances
can be easily achieved.

Ethernet over Passive Optical Networking (xPON)
PON is a point-to-multipoint optical access architecture
that facilitates broadband communications between an
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
of approximately 40 km. PON supports from 1 to 128
users per single strand of fiber.

PON is a cost-effective access method because it
conserves fiber for service providers offering high
bandwidth business and residential access
applications, green field deployments, mobile
backhaul and any upgrade from twisted pair or
coaxial copper networks.

Benefits of PON
PONs most obvious benefit is the increase in the
bandwidth delivered to the subscriber compared to
legacy copper technologies. Using PON, service
providers can launch new bandwidth-intensive
applications. Other benefits of PON are: 1)
significant reductions in fiber infrastructure, 2) large
reductions in electrical cost and 3) reduced
maintenance requirements.

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. MEF services
are supported on both platforms. Standards are also
underway at CableLabs for translation of DOCSIS
management commands into Ethernet formats to
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.

Ethernet over SONET/SDH (EoS)
Often the best way to deliver Ethernet service is to
use what you have available period. With SONET
and SDH equipment deployed nearly everywhere
fiber is, using this existing and highly reliable
transport technology can be an obvious decision.
While early implementations from equipment
vendors were lacking support for service
differentiation and granular QoS, newer products are
MEF-certified and deliver a variety of sophisticated
services from 1 Mbps up to over 1 Gbps. Ethernet
interface cards are available for modern
SONET/SDH transport equipment and low-cost
external devices are available for use when leasing
transport or when the existing SONET/SDH
equipment cant support the services the carrier
wishes to offer.


5 of 11

Benefits of Ethernet over SONET/SDH (EoS)
Delivering Ethernet services over SONET/SDH allows
the service provider to leverage infrastructure that is
already in place using familiar transport technology.
SONET/SDH networks have traditionally been
regarded as the gold standard for resiliency. This
well-understood technology is widely available
wherever fiber has been pulled. In addition, modern
circuit bonding protocols, such as virtual
concatenation (VCAT), have helped make Ethernet
services over SONET/SDH available at fractions of
the line rate, eliminating stranded capacity and
further driving down costs.

Ethernet over PDH

If neither SONET/SDH nor Dark Fiber facilities are
available, service providers have found that the
existing PDH network, consisting of traditional
DS1/E1, DS3 and E3 standards enable them to
deliver Carrier Ethernet to locations that would
otherwise be unreachable.

Ethernet over Bonded T1/E1
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
humble beginnings as voice trunk line technologies
to their more recent achievement as the gold
standard of Internet access for small and medium-
sized businesses, T1s and E1s have proven to be
well-understood and versatile last-mile
technologies.

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 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
demanded by many enterprise customers.
Because there are multiple links involved in the
access method, it is inherently protected against
interruptions of one or more of those links for
example by a backhoe or an excavator.

There are three standardized methods for delivering
Ethernet over T1/E1 lines. These are: multilink
point to point protocol (MLPPP), GFP/VCAT and
G.bond or EFM. While each technology has its
strengths, they all deliver comparable performance
and are available from multiple equipment vendors.

Benefits of Bonded T1/E1
The number one benefit that comes from using
bonded T1/E1 for delivering Ethernet services is
that service providers are able to reach all of their
customer locations, regardless of geography and
proximity to their facilities. 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, allowing the service
provider to recognize revenue sooner and to
decouple sales efforts from the infrastructure build
outs associated with many alternative technologies.

Ethernet over DS3/E3
J ust as T1/E1 is a desirable access technology for
delivering Ethernet service, DS3 and E3 circuits
provide another alternative using readily available
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
for backhaul between remote co-location facilities
and points of presence.

Benefits of DS3/E3
The primary benefit of using DS3/E3 is to deliver
Ethernet at rates greater than 3 Mbps over the
existing transport infrastructure. Rapid service turn-
up and revenue recognition are additional side
benefits of leveraging this infrastructure.

Ethernet over Copper

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

Long reach 2BASE-TL, delivering a minimum of
2 Mbit/s and a maximum of 5.69 Mbit/s over
distances of at least 2700 m, using standard
G.SHDSL.bis technology over a single copper
pair.
Short reach 10PASS-TS, delivering a minimum
of 10 Mbit/s over distances of at least 750 m

6 of 11

(2460 ft), using VDSL technology over a single
copper pair.

Extensions to these standard technologies
developed by some equipment vendors have
enabled some service providers to improve on the
rate/reach curves provided by the standard
implementations.

Both EFMCu technologies support an optional
aggregation or bonding of multiple copper pairs (up
to 32), providing higher bandwidth, longer reach
and improved resiliency. The aggregate bandwidth,
in excess of 100 Mbps, offered by copper bonding
solutions meet the needs of most bandwidth-
intensive Metro Ethernet applications.

Benefits of Ethernet over Copper
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.

By reducing service provider capital expenditures
for implementation, EFMCu serves as the easiest,
lowest-cost, and immediately deployable solution
for providing feature-rich, high-speed access and
services to subscribers.

With Ethernet over Copper, service providers,
governments and private enterprises have a cost-
effective solution for extending their Ethernet
networks without having to deploy fiber.

Eliminating the need to install fiber optic cable
removes a fundamental barrier that has inhibited
the adoption of Ethernet in the public network.
Using the multi-pair bonding service providers can
offer high performance (10-100 Mbps) service over
a reliable infrastructure with resiliency built right in.
EFMCu using multi-pair bonding provides the
subscriber with a fiber-like experience and gives the
service provider the ability to universally offer
Ethernet services over both fiber and copper media.

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

EFMCu is an attractive access solution for both
residential and business users and is spectrally
compatible with other legacy PSTN/ISDN, T1/E1
and DSL services so they can co-exist in the same
cables.

Wireless Ethernet

Where wireline services are not available or
practical, delivering Ethernet over a point-to-point
wireless access network can make a previously
infeasible connection practical. Also, where
mobility is required, broadband wireless services
from mobile service providers may provide an
excellent connectivity option.

Terrestrial Microwave
A microwave link uses microwave frequencies
(above 1 GHz) for line of sight radio
communications (20 to 30 miles) between two
directional antennas. Microwave link transceivers
are now available with standard Ethernet interfaces
that can 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 8 miles at 11 GHz but will
perform poorly over 15 miles due to rain fade at that
frequency. 100 Mbps Fast Ethernet can be
achieved reliably up to 30 miles at 6 GHz.

The use of microwave links avoids the need to
install cables between communication equipment.
Microwave links may be licensed (filed and
protected by government agencies) or may be
unlicensed (through the use of low power within
unlicensed regulatory limits).

Broadband Wireless
EVDO (Evolution of Existing Systems for Data
Only) is a common upgraded service of cellular
providers with CDMA (Code Division Multiple
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. A system uses the same reverse
channel which limits the uplink data transmission
rate to approximately 1.8 Mbps. The EVDO system
has an upgraded packet data transmission control
system that allows for bursty data transmission
rather than for more continuous voice data
transmission.

GSM (Global System for Mobile) 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

7 of 11

capabilities, by means of General Packet Radio
Service (GPRS). The latest 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.

LTE (Long Term Evolution or 3GPP) is the name
given to a project within the Third Generation
Partnership Project 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
should provide 100 Mbps peak download rates.

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

Free Space Optics (FSO)
FSO is an alternative to the radio frequency
wireless technologies previously described. While
the most common use of optical transmission is
through fiber optic cable, FSO enables service
providers to connect two points at a medium to long
distance (from an access perspective) through the
air and provide Gigabit Ethernet speeds. As light is
used instead of electro-magnetic signal, there is no
need to purchase expensive radio spectrum,
making FSO a complement to copper and fiber
communications.

Ethernet over HFC/DOCSIS

Hybrid fiber-coaxial (HFC) is an industry term for
a broadband network which combines optical fiber
and coaxial cable. It has been commonly employed
by MSO/cable TV operators since the early 1990s.

The fiber optic network extends from the cable
operators' master/regional head-end, to a
neighborhoods hub site, and finally to a fiber optic
node which serves anywhere from 25 to 2000
homes. A master head-end will usually have
satellite dishes for reception of distant video signals
as well as IP 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 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 standard developed by
CableLabs and contributing companies. DOCSIS
defines the communications and operation support
interface requirements for a data over cable
system. It permits the addition of high-speed data
transfer to an existing Cable TV (CATV) system. It
is employed by many cable television operators to
provide Internet access and Business Services over
their existing (HFC) infrastructure.

With its large coverage and available performance,
HFC/DOCSIS technology is a valuable asset for
Cable TV/MSO providers to deliver Ethernet-based
services to the SOHO/SMB and high-speed Internet
access to residential customers.


8 of 11

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
B/W Access Media
Access
Technology
Service
Provider
Application
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
500kbps Wireless
Broadband
Wireless
Wireless
Operator Hydrological pressure measurement
10Mbps Copper T1
Ethernet over
Bonded T1 ILEC Air quality measurement
150Mbps Fiber
Ethernet over
SONET CLEC Remote imaging and chemical analysis
2Mbps Copper - Coaxial HFC/DOCSIS MSO Chemical analysis
500Mbps Fiber
Direct 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.


9 of 11

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
E-Tree Services
MEF 6.1 Metro Ethernet Services Definitions Phase 2
MEF 10.1 Ethernet Services Attributes Phase 2
PDH/Circuit
emulation
MEF 3: Circuit Emulation Service Definitions, Framework and Requirements
MEF 8: Implementation Agreement for the Emulation of PDH Circuits
Mobile Backhaul MEF 22: Carrier Ethernet for Mobile Backhaul Implementation Agreement
Test/Certification
MEF 9: Ethernet Services at the UNI
MEF 14: Traffic Management
Carrier Ethernet
Access Method
Technology Alternatives Applicable Standards
Active Fiber - IEEE 802.3-2005
Ethernet over SONET/SDH
- ITU-T X.86 encapsulation
- ITU-T G.707 and G.7043 (GFP-VCAT) Ethernet over
Fiber
Passive Optical Network
- IEEE 802.3-2005 (EPON)
- IEEE 802.3av (10GEPON)
- ITU-T G.984 (GPON)
Bonded T1/E1
- RFC1990 (Multilink PPP) and RFC3518 (BCP)
- ITU-T G.7041 and G.7043 (GFP-VCAT)
- ITU-T G.998.2 (G.bond) Ethernet over
PDH
DS3/E3 and bonded
DS3/E3
- ITU-T X.86 encapsulation with optional link aggregation
- ITU-T G.7041 and G.7043 (GFP-VCAT)
- ITU-T G.998.2 (G.bond)
2BASE-TL
- IEEE 802.3-2005 2BASE-TL using ITU-T G.991.2
(G.SHDSL.bis) Ethernet over
Copper
10PASS-TS
- IEEE 802.3-2005 10PASS-TS using ITU-T G.993.1
(VDSL)
Terrestrial microwave - IEEE 802.3-2005 user interface
WiMAX - IEEE 802.16
Broadband wireless
- 3GPP Rel. 7 (HSDPA/HSPA+)
- 3GPP Rel. 8 (LTE)
- CDMA2000 EV-DO rev.A TIA-856 (EVDO)
Free space optics - IEEE 802.3-2005 user interface
Wireless Ethernet
WiFi - IEEE 802.11
Hybrid Fiber Coax DOCSIS - DOCSIS 1.x, 2.x, 3.0, EuroDOCSIS

10 of 11

Glossary of Abbreviations

3GPP Third Generation Partnership Project
(Standardization body developing GSM
technologies)
3GPP2 Third Generation Partnership Project 2
(Standardization body developing
CDMA technologies)
ADM Add Drop Multiplexer
ARP Address Resolution Protocol
ATM Asynchronous Transfer Mode
BCP Bridging Control Protocol
BPDU Bridge Protocol Data Unit
BWA Broadband Wireless Access
CDMA Code Division Multiple Access
CFM Connectivity Fault Management
CLEC Competitive Local Exchange Carrier
CWDM Coarse Wave Division Multiplexing
DOCSIS Data over Cable Service Interface
Specification
DS3 Digital Signal level 3
DSL Digital Subscriber Line (as in xDSL)
E1 European PDH signal level 1
E3 European PDH signal level 3
EFM Ethernet in the First Mile
EFMCu Ethernet in the First Mile Copper
E-LAN Ethernet-LAN Service
E-Line Ethernet Point-to-Point
EoS Ethernet over SONET/SDH
EPON Ethernet Passive Optical Network
EVC Ethernet Virtual Connection
EVDO Evolution of Existing Systems for Data
Only
FSO Free Space Optics
GFP Generic Framing Protocol
GPRS General Packet Radio Service
GSM Global System for Mobile
HFC Hybrid Fiber Coax
HSDPA High-Speed Downlink Packet Access
HSPA High-Speed Packet Access
IEEE Institute of Electrical & Electronics
Engineers
IETF Internet Engineering Task Force
ILEC Incumbent Local Exchange Carrier
ITU-T International Telecommunication Union
Telecommunication Standardization
Sector
LAN Local Area Network
LLDP Link Layer Discovery Protocol
LTE Long Term Evolution
MEF New name for entity formerly known as
Metro Ethernet Forum
MLPPP Multi-Link Point-To-Point Protocol
MSO Multiple Service Operator (Comcast,
COX, Time Warner Cable, etc)
NID Network Interface Device
OAM Operations, Administration and
Maintenance
OLO Other Licensed Operator
OLT Optical Line Termination
PDH Plesiochronous Digital Hierarchy
QoS Quality of service
RFI Request for Information
RFP Request for Proposal
RFQ Request for Quotation
SDH Synchronous Digital Hierarchy
SHDSL Single-Pair High-Speed Digital
Subscriber Line
SLA Service Level Agreement
SLO Service Level Objectives
SLS Service Level Specifications
SMB Small and Medium Business
SOHO Small Office, Home Office
SONET Synchronous Optical NETwork
T1 Telecommunications level 1
TDM Time Division Multiplexing
UMTS Universal Mobile Telecommunications
System
UNI User to Network Interface
VCAT Virtual Concatenation
VDSL Very High Speed Digital Subscriber Line
VLAN Virtual LAN
VoD Video on Demand
WiMAX Worldwide Interoperability for Microwave
Access
WDM Wave Division Multiplexing

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
J on 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

11 of 11

MEF 10.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.

MEF 10.2


27 October 2009

MEF 10.2

Disclaimer
or otherwise:
a) any express or implied license or right to or under any patent, copyright, trademark or
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.
accelerating industry cooperation on Metro Ethernet technology. The MEF does not, expressly or
otherwise, endorse or promote any specific products or services.

MEF 10.2
Page i

Table of Contents
1. Abstract ................................................................................................................................ 1
2. Terminology......................................................................................................................... 1
3. Scope..................................................................................................................................... 5
4. Compliance Levels .............................................................................................................. 6
5. I ntroduction ......................................................................................................................... 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
Page ii

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 (I nformative) .................................................................................................... 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
Page iii

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 ( )
k
S I ........................................................................ 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
Page iv

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
Page 1

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 I D Customer Edge VLAN ID
CE-VLAN I D 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 I D/EVC Map An association of CE-VLAN IDs with EVCs at a UNI.
CE-VLAN Tag Customer Edge VLAN Tag
CF Coupling Flag
CI R 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 I dentifier 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
Page 2

CM Color Mode
Color Mode CM is a Bandwidth Profile parameter. The 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 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
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 I nformation
Rate
CIR is a Bandwidth Profile parameter. It defines the average
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 I D 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
Page 3

Egress Service Frame A Service Frame sent from the Service Provider network to the
CE.
EI R 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
Connection
An association of two or more UNIs that limits the exchange of
Service Frames to UNIs in the Ethernet Virtual Connection.
EVC Maximum
Transmission Unit Size
The maximum sized Service Frame allowed for an EVC.
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 I nformation 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
Frame Delay Range The difference between the Frame Delay Performance values
corresponding to two different percentiles.
Frame Delay Range
Performance
A measure of the extent of delay variability experienced by
different Service Frames belonging to the same CoS instance.
Frame Loss Ratio
Performance
between the ingress UNI and the egress UNI. Frame Loss Ratio
is expressed as a percentage.
MEF 10.2
Page 4

I ngress 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.
I ngress Service Frame A Service Frame sent from the CE into the Service Provider
network.
I FDV Inter-Frame Delay Variation
I nter-Frame Delay
Variation
The difference in delay of two Service Frames belonging to the
same CoS instance.
I nter-Frame Delay
Variation Performance
A measure of the variation in the delays experienced by
Service Frame
A Service Frame that is used for Layer 2 control, e.g., Spanning
Tree Protocol.
Tunneling
The process by which a Layer 2 Control Protocol Service
Frame is passed through the Service Provider network without
being processed and is delivered unchanged to the proper
UNI(s).
Maximum Number of UNI s The maximum number of UNIs that may be in an EVC.
Mean Frame Delay
Performance
The arithmetic mean, or average of delays experienced by
MNU Maximum Number of UNIs
Multicast Service Frame A Service Frame that has a multicast destination MAC address.
Multipoint-to-Multipoint
EVC
Ordered Pair of UNI s 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
Frames
The set of frames that comply with specific criteria, such as the
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
Page 5

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).
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.
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 I nterface 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
Page 6

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).
The key words "MUST", "MUST NOT", "REQUI RED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTI ONAL" 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
Page 7

Service Provider Metro Service Provider Metro
Ethernet Network Ethernet Network
Customer Customer
Edge Edge
(CE) (CE)
User Network User Network
Interface Interface
(UNI) (UNI)
User Network User Network
Interface Interface
(UNI) (UNI)
Customer Customer
Edge Edge
(CE) (CE)

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
Page 8

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.
EVC
1
EVC
2

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
Page 9

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.
Root
Leaf
Leaf
Broadcast, multicast and Broadcast, multicast and unicast unicast unknown unknown
Known Known unicast unicast
Broadcast, multicast and Broadcast, multicast and unicast 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 1898
th
EVC in the MEN and the customer for the EVC is
MegaMart.
MEF 10.2
Page 10

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
Page 11

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
Page 12

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
Page 13

I ngress Service Frame Egress Service Frame(s)
6

No IEEE 802.1Q Customer
VLAN Tag [10]
No IEEE 802.1Q Customer VLAN Tag [10]
Contains IEEE 802.1Q
Customer VLAN Tag [10]
Contains IEEE 802.1Q Customer VLAN Tag [10] with VLAN ID
equal to the VLAN ID of the Tag on the ingress Service Frame
Table 2 CE-VLAN I D 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 I D/EVC Map
Characteristic
Service Frames with CE-VLAN I D Preserved
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 I D 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
Page 14

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
Page 15

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
Page 16

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
Page 17

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.
Metro Ethernet Metro Ethernet
Net work Net work
UNI to UNI UNI to UNI
first bit in first bit in
last bit out last bit out
time time
CE CE CE CE
Frame Frame
Delay Delay

Figure 5 - Frame Delay for Service Frame
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 { } j i m j m i j i S = = , ,..., 1 , ,..., 1 | , .
Let
j i
T
d
,
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
=
j i
T
d
,
Undefined.

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
Page 18

Then the One-way Frame Delay Performance metric SHALL be defined as the maximum
value of all of the values
j i
T
d
,
for S j i , , unless all
j i
T
d
,
are Undefined in which case
the performance is Undefined.
Let
j i
Tx
j i
Ty
j i
Tyx
d d d
, , ,
= represent the difference between Percentiles P
y
and P
x
(where
P
y
>P
x
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 =
j i
Txy
d
,
Undefined.
Then the One-way Frame Delay Range Performance metric SHALL be defined as the
maximum value of all of the values of the difference
j i
Tx
j i
Ty
j i
Tyx
d d d
, , ,
= for S j i , ,
unless all
j i
Txy
d
,
are Undefined in which case the performance is Undefined.
Let
j i
T
,
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 =
j i
T
,
Undefined.
Then the One-way Mean Frame Delay Performance metric SHALL be defined as the
maximum value of all of the values
j i
T
,
j i
T
,
are Undefined in
which case the performance is Undefined.
To restate the Frame Delay definition mathematically, let the UNIs in the EVC be numbered
from 1 to mand let
j i
T
D
,
be the set of one-way Frame Delay values for all Qualified Service
Frames at UNI j resulting from an ingress Service Frame at UNI i.
j i
T
D
,
can be expressed as
{ }
j i
N
j i j i j i
T
j i
d d d D
, ,
2
,
1
,
,
,..., , = , where
j i
k
d
,
is the one-way Frame Delay of the k
th
Service Frame.
Define
j i
T
d
,
for P > 0 as
( )
=

=
otherwise
1 if ,
100
| min
,
1
,
,
,
,
Undefined
N d d I
N
P d
d
j i
N
k
j i
k
j i
j i
T
j i

where,
( )

=
otherwise 0
if 1
,
k
k
d d
d d I .
MEF 10.2
Page 19

j i
T
d
,
is the minimal delay during the time internal T that P percent of the frames do not exceed.
Note that when P>0, only values of d within
j i
T
D
,
will satisfy P(100/N
<i,k>
)I(d,d
k
).
Then a one-way Frame Delay Performance metric for an EVC can be expressed as
{ }
=
>
=
S j i N Undefined
N S j i d
d
j i
j i
j i
T
S T
, | 0 all when
0 where and , | max
,
,
,
,
.
The One-way Frame Delay attribute permits specification of multiple values for P, (P
0
, P
1
, P
2
,
) and corresponding objectives (
j i
d
,
0
,
j i
d
,
1
,
j i
d
,
2
, ). Another parameter is the objective

for the difference between the delay performance of two selected percentiles, P
x
and P
y
,
expressed as
=
>
=
0 if
0 if ) (
,
,
, ,
,
j i
j i
j i
Tx
j i
Ty j i
Tyx
N Undefined
N d d
d
Then a one-way Frame Delay Range Performance metric for an EVC can be expressed as
{ }
, | 0 all when
0 where and , | max
,
,
,
=
>
=
S j i N Undefined
N S j i d
d
j i
j i
j i
Tyx
TyxS
.
The minimum one-way delay is an element of
j i
T
D
,
, where
j i
d
,
min

j i
k
d
,
(for all
j i
N k
,
,..., 2 , 1 = ), and is a possible selection as one of the percentiles. The minimum delay
represents the N
<i,j>
-1
th percentile and all lower values of P as 0 P .
Another One-way Frame Delay attribute is the arithmetic mean of
j i
T
D
,
, which can be expressed
as
( )
=
>
=

=
0 if
0 if
1
,
,
1
,
,
,
,
j i
j i
N
k
j i
k
j i
j i
T
N Undefined
N d
N
j i

Then a One-way Mean Frame Delay Performance metric for an EVC can be expressed as
{ }
=
>
=
S j i N Undefined
N S j i
j i
j i
j i
T
j i
T
TS
, | 0 all when
0 where and , | max
,
,
, ,

.
The parameters of a One-way Frame Delay Performance metric are given in Table 4.

MEF 10.2
Page 20

T The time interval
x
P

A specific percentile of the Frame Delay Performance, 0 >
x
P
y
P Another specific percentile of the Frame Delay Performance, where
x y
P P >
x
d

One-way Frame Delay Performance Objective corresponding to
x
P
y
d

y
P
yx
d

One-way Frame Delay Range Objective corresponding to the Frame Delay
Performance at P
x
and P
y
) (
, , , j i
Tx
j i
Ty
j i
Tyx
d d d = where
x y
P P >

One-way Mean Frame Delay Performance Objective
Table 4 One-way Frame Delay Performance Parameters
Given T, S,
x
P , and a one-way Frame Delay Performance objective
x
d
, 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
x S T
d d
,
. Further, given
y
P and a One-way Frame Delay Performance
objective
y
d
, expressed in time units, the objective for one-way Frame Delay Range between
x
P
and
y
P SHALL be defined as met over the time interval T for the subset S if and only if
yx TyxS
d d
. Finally, given a One-way Mean Frame Delay Performance objective , expressed in

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 j i, , 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
MEF 10.2
Page 21

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 [T
1
, T
2
].
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
i
a be the time of the arrival of the first bit of the i
th
Service Frame at the ingress UNI, then
the two frames i and j are selected according to the selection criterion:
{ } i j and t a a
i j
> =
Let
i
r 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
j i
d d . Define
( ) ( ) ( ) ( )
i j i j j j i i j i ij
r r a a a r a r d d d = = =
With
j
d being the delay of the j
th
frame, a positive value for
j i
d d 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
ij
d is not defined and does not contribute to the
evaluation of the Inter-Frame Delay Variation.
MEF 10.2
Page 22

Figure 6 shows a depiction of the different times that are related to Inter-Frame Delay Variation
Performance.
Ingress
Egress
i i+1 j+1 j
a
i
a
j
t
r
i
r
j
Time
d
i
d
j

Figure 6 I nter-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
j i
T
d
,
~
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
Undefined d
j i
T
=
,
~
.
Then the Inter-Frame Delay Variation Performance metric SHALL be the maximum of
the values
j i
T
d
,
~
j i
T
d
,
~
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
{ } j i m j m i j i S = = , ,..., 1 , ,..., 1 | , .
Let
} ,..., , {
, ,
2
,
1
,
,
j i
N
j i j i j i
T
j i
d d d V =
MEF 10.2
Page 23

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

=

=
otherwise
1 if ) , (
100
| min ~
,
1
,
,
,
,
Undefined
N d d I
N
P d
d
j i
N
k
j i
k
j i
j i
T
j i

where;
( )
otherwise
if
0
1
,
d d
d d I

= .
Then an Inter-Frame Delay Variation Performance metric for an EVC can be expressed as
{ }
=

=
S j i N Undefined
N S j i d
d
j i
j i
j i
T
S T
, | 0 all when
1 where and , |
~
max
~
,
,
,
,
.
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.

T The interval
P Inter-Frame Delay Variation Performance percentile
t
The separation between frame pairs for which Inter-Frame Delay
Variation Performance is defined
d

Table 5 I nter-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 d d
S T

,
~
.
Recall that if the Inter-Frame Delay Variation is Undefined for time interval T and ordered pair
j i, , 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
Page 24

EVC.
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 ( )
i
t flr 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:
( )
{ }
=

= =
S j i I
I S j i FLR
FLR t flr
j i
t
j i
t
j i
t
S t i
i
i i
i
, | 0 all when 0
1 where and , | max
,
, ,
,

where the set of ordered pairs, S, contains both ordered pairs of UNIs in the Point-to-Point EVC.
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
j i
T
I
,
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.
Let
j i
T
E
,
denote the number of such Service Frames delivered to UNI j.
Define

|
|
.
|
\
|

=
otherwise
1 if 100
,
,
, ,
,
Undefined
I
I
E I
FLR
j i
T j i
T
j i
T
j i
T
j i
T
.
MEF 10.2
Page 25

Then the One-way Frame Loss Ratio Performance metric SHALL be defined as
{ }
=

=
S j i I Undefined
I S j i FLR
FLR
j i
T
j i
T
j i
T
S T
, | 0 all when
1 where and , | max
,
, ,
,
.
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.

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
L FLR
S T
,
.
Recall that if the One-way Frame Loss Ratio Performance is Undefined for time interval T and
ordered pair j i, , 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.
EVC.
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
Page 26

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,

u
C , a loss ratio threshold which if equaled or exceeded suggests unavailability,

a
C , a loss ratio threshold which if not exceeded suggests availability with
u a
C C , and
n, the number of consecutive small time intervals, t , over which to assess availability.
Suppose the time interval | |
1 0
,t t T = and define ( ) | | n i t i t t i t t
i
,..., 2 , 1 for , , 1
0 0
= + + = .
Define sets of n consecutive small time intervals as
( ) ( )
{ }
kn n k n k k
t t t S =
+ +
,..., ,
2 1 1 1
. Also define
( )
i
t flr to be the Frame Loss Ratio defined in Section 6.9.5 with
i
t replacing T. Let
{ } T t t T
i i
= |
~
. Let K be the largest integer such that
K i i
S t T t ,
~
. In other words,
K
S
is the last sequence of small time intervals completely contained in T.
Define the function ( ) k D
s
to indicate if a sequence of small time intervals includes Scheduled
Downtime:
( )
=
otherwise 0
during Downtime Scheduled any is there if 1
k
s
S
k D .
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 ( ) k D
u
to indicate if a sequence of small time intervals includes Unscheduled
Downtime:
( )
=
otherwise 0
during Downtime duled any Unsche is there if 1
k
u
S
k D .
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
Page 27

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
( )
( )

=
otherwise 1
, if 0
k i u i
S t C t flr
k U and ( )
( )

=
otherwise 0
, if 1
k i a i
S t C t flr
k A .
Finally define an indicator function ( )
k
S I as follows whose value is 1 if the service is available
during
k
S and 0 otherwise:
( )
( )
=
=
otherwise 1
1 1 if 0
1
u
D
S I
( )
( )
( ) ( ) ( ) ( )
( ) ( ) ( ) ( ) ( ) ( ) ( )
( )
= = =
= =
=
=
otherwise
1 and 0 and 0 if
1 and 0 if 1
1 if 0
1
k A
S I k D k D k U
k D k D
k D
S I
k s u
s u
u
k
for K k ,..., 2 = .
Note that any
k
S that has Unscheduled Downtime is defined as unavailable and thus
Unscheduled Downtime overrides Scheduled Downtime during an interval
k
S .
Figure 7 illustrates four examples of calculating ( )
k
S I when there is no Scheduled Downtime
and no Unscheduled Downtime. In this example, 4 = n .
I(S
k-1
) = 1 (available)
flrC
u
flrC
u
flrC
u
flrC
u
S
k-1
S
k
I(S
k-1
) = 1 (available) I(S
k
) = 0 (unavailable)
flrC
u
flr<C
u
flrC
u
flrC
u
I(S
k
) = 1 (available)
flrC
a
flrC
a
flrC
a
flrC
a
I(S
k-1
) = 0 (unavailable) I(S
k
) = 1 (available)
flrC
a
flr>C
a
flrC
a
flrC
a
I(S
k
) = 0 (unavailable) I(S
k-1
) = 0 (unavailable)
t t t t t t t t
t t t t t t t t
t t t t t t t t
t t t t t t t t

Figure 7 Examples of the Calculation of ( )
k
S I
MEF 10.2
Page 28

Then the Availability Performance metric SHALL be defined as
<
(
|
.
|
\
|
=

=
otherwise 100
if ) (
100
1
K M M S I
M K
A
K
k
k
T
.
For the SLS, an Availability Performance metric MUST specify a set of parameters and an
objective as shown in Table 7.

T The time interval
t A time interval much smaller than T
u
C Unavailability frame loss ratio threshold
a
C Availability frame loss ratio threshold with
u a
C C
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 ,
u
C ,
a
C , 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 { } i j m j m i j i S > = = , ,... 1 , ,..., 1 | , .
Let t be a time interval much smaller than T.
Let
u
C be a loss ratio threshold which if equaled or exceeded suggests unavailability.
Let
a
C be a loss ratio threshold which if not exceeded suggests availability with
u a
C C .
Let n be the number of small time intervals, t , over which to assess availability.
Let
j i
T
A
,
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
Page 29

Then the Availability Performance metric SHALL be defined as
{ } S j i A A
j i
T S T
= , | min
,
,
.
For the SLS, an Availability Performance metric MUST specify a set of parameters and an
objective as shown in Table 8.

T The time interval
S Subset of the UNI pairs
u
a
C Availability frame loss ratio threshold with
u a
C C
A

Availability Performance objective
Table 8 Availability Performance Parameters for a Multipoint EVC
Given T, S, t ,
u
C ,
a
C , 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
S T
,
.
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
Page 30

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
All Ethernet physical media compatible with
Speed and Mode specified in [2] or [3].
100 Mbps Full duplex
10/100 Mbps
Auto-
Negotiation
Full duplex
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
Page 31

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
Page 32

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
Page 33

CE-VLAN I D EVC
47 EVC
1
1343 EVC
2

17
16
EVC
3

EVC
1
EVC
2
EVC
3
47
1343
untagged and
priority tagged, 17
UNI

Figure 9 Example of a CE-VLAN I D/EVC Map
In this example, an ingress Service Frame with CE-VLAN ID 47 is transported according to the
properties and attributes of EVC
1
. An untagged or priority tagged ingress Service Frame is
transported according to the properties and attributes of EVC
3
. An egress frame coming from
EVC
2
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
Page 34

mappings for the EVC are identical as is the case for EVC
1
in Figure 10. (Otherwise the CE-
VLAN ID cannot be preserved).

UNI A UNI B
CE-VLAN I D EVC CE-VLAN I D EVC
47 EVC
1
47 EVC
1

1343 EVC
2
17
16
EVC
2

187 EVC
3
1343 EVC
3

EVC
1
EVC
2
EVC
3
47
1343
187
UNI A UNI B
47
1343
untagged and priority tagged, 17

Figure 10 Example of CE-VLAN I D/EVC Maps at Two UNI s
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 EVC
1
. (EVC
1
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
Page 35

UNI A UNI B UNI C
CE-VLAN I D EVC CE-VLAN I D EVC CE-VLAN I D EVC
47,48,49 EVC
1
47,48,49 EVC
1
1 EVC
2

113 EVC
3
1 EVC
2
47 EVC
3

EVC
1
EVC
2
EVC
3
47,48,49
113
UNI A UNI C
47
UNI B
47,48,49
1
1

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 I D EVC CE-VLAN I D EVC
2000 EVC
1
2000 EVC
1

2001 EVC
3
2001 EVC
3

All others EVC
4
1, , 1999, 2002, , 4095 EVC
4
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
Page 36

Valid
Combination
1
Valid
Combination
2
Valid
Combination
3
Valid
Combination
4
Valid
Combination
5
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
Page 37

Committed I nformation 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 I nformation 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 REQUI RED for Bandwidth Profiles. Color aware mode is OPTI ONAL 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,
{ }
, 1
, 0 , ,
j j j j
t t j l t
+
with arrival times at the reference point
j
t and lengths
j
l , the level of
compliance color assigned to each Service Frame MUST be defined according to the algorithm
in Figure 13. For this algorithm, ( ) CBS t B
c
=
0
and ( ) EBS t B
e
=
0
. ( ) t B
c
and ( ) t B
e
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
Page 38

Declare Service Frame Red Declare Service Frame Red
( ) ( ) ( )
( ) ( ) ( )
( ) ( ) ( ) ( )
)
`
+ + =
)
`
+ =
)
`
+ =

j j j j e j e
j j j c j
j j j c j c
t O CF t t
EIR
t B EBS t B
CBS t t
CIR
t B t O
t t
CIR
t B CBS t B
1 1
1 1
1 1
8
, min
8
, 0 max
8
, min
( ) 1 at time arrives length of Frame Service j t l
j j
( ) |
( )|
( ) ( )
j c j
t B l
CM
==
==
AND
Green Frame Service OR
blind - color
( ) |
( )|
( ) ( )
j e j
t B l
CM
=
==
AND
Red ! Frame Service OR
blind - color
( ) ( )
j j c j c
l t B t B =
Green Frame Service Declare
( ) ( )
j j e j e
l t B t B =
Yellow Frame Service Declare
Yes
Yes
No
No

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 ] , [
k j
t t the amount of traffic declared green, W
G
and
the amount of traffic declared yellow, W
Y
are lower bounded below by the values:
( ) ( )
j k j c G
t t
CIR
t B W +
8

( ) ( )
j k j e Y
t t
EIR
t B W +
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
Page 39

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 { } , 0 , , j l t
j j
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.
UNI UNI
EVC EVC
1 1
EVC EVC
2 2
EVC EVC
3 3
Bandwidth Profile Bandwidth Profile
per Ingress UNI per Ingress UNI

Figure 14 I ngress Bandwidth Profile per I ngress UNI
7.11.2.2 Ingress Bandwidth Profile per EVC Service Attribute
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, EVC
1
could have CIR=15
Mbps, EVC
2
could have CIR =10 Mbps, and EVC
3
could have CIR =20 Mbps.
The Ingress Bandwidth Profile per EVC service attribute is associated with each EVC at the
UNI.

MEF 10.2
Page 40

UNI UNI
EVC EVC
1 1
EVC EVC
2 2
EVC EVC
3 3
Bandwidth Bandwidth Profileper Profileper EVC EVC
1 1
Bandwidth Profile per EVC Bandwidth Profile per EVC
2 2
Bandwidth Profile per EVC Bandwidth Profile per EVC
3 3

Figure 15 I ngress Bandwidth Profile per EVC
7.11.2.3 Ingress Bandwidth Profile per Class of Service Identifier Service Attribute
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 EVC
1
, 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.

UNI UNI
EVC EVC
1 1
EVC EVC
2 2
CE CE- -VLAN CoS 0,1,2,3 VLAN CoS 0,1,2,3
CE CE- -VLAN CoS 4,5 VLAN CoS 4,5
CE CE- -VLAN CoS 6,7 VLAN CoS 6,7
Ingress Bandwidth Profile per CoS ID Ingress Bandwidth Profile per CoS ID

Figure 16 I ngress Bandwidth Profile per Class of Service I dentifier
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
Page 41

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
EVC
1
. Note also for the configuration in Figure 16, that it is possible to configure a per-EVC
Ingress Bandwidth Profile for EVC
2
but there happens to not be an Ingress Bandwidth Profile for
EVC
2
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.

I ngress Bandwidth
Profile Compliance
Service Frame Disposition
Red Discard
Yellow
Deliver to the egress UNI according to the Service Attributes of the
service instance but SLS performance objectives do not apply.
Green Deliver to the egress UNI according to the Service Attributes of the
service instance and SLS performance objectives apply. Not Applied
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
Page 42

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, { } 0 , , j l t
j j
. 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
Page 43

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 EVC
1
.
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
Page 44

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
Page 45

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
Page 46

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
Page 47

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
Page 48

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 Gbps
20

Mode (Section 7.2) Full Duplex
MAC Layer (Section 7.3) IEEE 802.3 2005 [2]
UNI Maximum Transmission Unit Size
(Section 7.4)
Integer 1522.
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
tagged Service Frames (Section 7.6)
A number in 1, 2, , 4094.
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 No
21

All to One Bundling (Section 7.10) Yes or No
22

Ingress Bandwidth Profile Per Ingress UNI
(Section 7.11.2.1)
No or parameters as defined in Section 7.11.1
Ingress Bandwidth Profile Per EVC
(Section 7.11.2.2)
No or parameters as defined in Section 7.11.1 for
each EVC
23

Ingress Bandwidth Profile Per Class of
Service Identifier (Section 7.11.2.3)
each Class of Service Identifier
24

Egress Bandwidth Profile Per Egress UNI
(Section 7.11.3.1)
No or parameters as defined in Section 7.11.1
Egress Bandwidth Profile Per EVC
(Section 7.11.3.2)
each EVC
25

Egress Bandwidth Profile Per Class of
Service Identifier (Section 7.11.3.3)
each Class of Service Identifier
26

Layer 2 Control Protocols Processing
(Section 7.13)
A list of Layer 2 Control Protocols with each
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
Page 49

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
6.1.2.2)
An arbitrary string, unique across the MEN, for the EVC supporting
the service instance
UNI List (Section 6.3) A list of <UNI Identifier, UNI Type>pairs
Maximum Number of
UNIs (Section 6.4)
Integer. MUST be 2 if EVC Type is Point-to-Point. MUST be
greater than or equal to 2 otherwise.
EVC Maximum
(Section 6.10)
Integer 1522.
CE-VLAN ID
Preservation (6.6.1)
Yes or No
CE-VLAN CoS
Preservation (Section
6.6.2)
Yes or No
Delivery (6.5.1.1)
Discard, Deliver Unconditionally, or Deliver Conditionally. If
Deliver Conditionally is used, then the conditions MUST be
specified.
Delivery (Section
6.5.1.2)
specified.
Delivery (Section
6.5.1.3)
specified.
Layer 2 Control
Protocols Processing
(Section 6.7)
A list of Layer 2 Control Protocols labeled Tunnel or Discard.
EVC Performance
(Sections 6.8 and 6.9)
Performance objectives for One-way Frame Delay Performance,
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
Page 50

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 J une 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, J une 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, J une 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),
J anuary 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
Page 51

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.

Figure 20 CE-VLAN I D/EVC Map Notation

Figure 21 Example 1: CE-VLAN I D Preservation =Yes with All to One Bundling
28

Figure 22 Example 2: CE-VLAN I D Preservation =Yes with Bundling on EVC2
28

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.
INGRESS
MAP
EGRESS
MAP
INGRESS SERVICE FRAME
FORMAT
EGRESS SERVICE FRAME
FORMAT
Untagged
Priority Tagged
Tagged
Untagged
Priority Tagged
Tagged
Tagged Tagged
A* A*
B B
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
INGRESS FRAMES (UNI A)
Frame A - Untagged
Frame B - Priority Tagged
Frame C - Tagged 10
Frame D - Tagged 12

EGRESS FRAMES (UNI A)
Frame E - Untagged
Frame F - Priority Tagged
Frame G - Tagged 10
Frame H - Tagged 12

UNI A
CE-VLAN ID EVC
1, ..., 4095 EVC1
INGRESS FRAMES (UNI B)
Frame E - Untagged
Frame G - Tagged 10
Frame H - Tagged 12

EGRESS FRAMES (UNI B)
Frame A - Untagged
Frame C - Tagged 10
Frame D - Tagged 12

UNI B
CE-VLAN ID EVC
1, ..., 4095 EVC1
EVC1
INGRESS FRAMES (UNI C)
Frame A - Untagged
Frame C - Tagged 20
Frame D - Tagged 22
Frame E - Tagged 30

EGRESS FRAMES (UNI C)
Frame F - ?
Frame G - ?
Frame H - Tagged 20
Frame I - Tagged 22
Frame J - Tagged 30
? means format not mandated
UNI C
CE-VLAN ID EVC
EVC2
EVC3
INGRESS FRAMES (UNI D)
Frame F - Untagged
Frame G - Priority Tagged
Frame H - Tagged 20
Frame I - Tagged 22
Frame J - Tagged 30

EGRESS FRAMES (UNI D)
Frame A - ?
Frame B - ?
Frame C - Tagged 20
Frame D - Tagged 22
Frame E - Tagged 30
? means format not mandated
EVC2
EVC3
20*, 22
30
UNI D
CE-VLAN ID EVC
EVC2
EVC3
20*, 22
30
MEF 10.2
Page 52

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.

Figure 23 CE-VLAN I D/EVC Map Notation

INGRESS
MAP
EGRESS
MAP
INGRESS SERVICE FRAME
FORMAT
EGRESS SERVICE FRAME
FORMAT
Untagged
Priority Tagged
Tagged
Untagged
Untagged
Untagged
Tagged
Untagged
A* A*
B
B
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
Untagged
Priority Tagged
Tagged
Tagged
Tagged
Tagged
A*
A*
B B Tagged Tagged
MEF 10.2
Page 53

Figure 24 Example 3: CE-VLAN I D 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.
INGRESS FRAMES (UNI E)
Frame A - Untagged
Frame C - Tagged 40
Frame D - Tagged 42

EGRESS FRAMES (UNI E)
Frame E - Untagged
Frame F - Untagged
Frame G - Untagged

UNI E
CE-VLAN ID EVC
40* EVC4
INGRESS FRAMES (UNI F)
Frame E - Untagged
Frame G - Tagged 44
Frame H - Tagged 46

EGRESS FRAMES (UNI F)
Frame A - Untagged
Frame B - Untagged
Frame C - Untagged

UNI F
CE-VLAN ID EVC
44* EVC4
EVC4
INGRESS FRAMES (UNI G)
Frame A - Untagged
Frame C - Tagged 50
Frame D - Tagged 52

EGRESS FRAMES (UNI G)
Frame H - Untagged

UNI G
CE-VLAN ID EVC
50* EVC5
INGRESS FRAMES (UNI H)
Frame E - Untagged
Frame G - Tagged 54
Frame H - Tagged 56

EGRESS FRAMES (UNI H)
Frame A - Tagged 56
Frame B - Tagged 56
Frame C - Tagged 56

UNI H
CE-VLAN ID EVC
56 EVC5
EVC5
INGRESS FRAMES (UNI I)
Frame A - Untagged
Frame C - Tagged 60
Frame D - Tagged 62

EGRESS FRAMES (UNI I)
Frame H - Untagged

UNI I
CE-VLAN ID EVC
60* EVC6
INGRESS FRAMES (UNI J)
Frame E - Untagged
Frame G - Tagged 64
Frame H - Tagged 60

EGRESS FRAMES (UNI J)
Frame A - Tagged 60
Frame B - Tagged 60
Frame C - Tagged 60

UNI J
CE-VLAN ID EVC
60 EVC6
EVC6
INGRESS FRAMES (UNI K)
Frame A - Untagged
Frame C - Tagged 70
Frame D - Tagged 72

EGRESS FRAMES (UNI K)
Frame H - Tagged 72

UNI K
CE-VLAN ID EVC
72 EVC7
INGRESS FRAMES (UNI L)
Frame E - Untagged
Frame G - Tagged 74
Frame H - Tagged 76

EGRESS FRAMES (UNI L)
Frame D - Tagged 76

UNI L
CE-VLAN ID EVC
76 EVC7
EVC7
MEF 10.2
Page 54

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.
EVC
1
EVC
3
EVC
2
A
B
C
D

EVCs UNI A UNI B UNI C UNI D
EVC UNIs CE-VLAN
I D
EVC CE-VLAN
I D
EVC CE-VLAN
I D
EVC CE-VLAN
I D
EVC
EVC
1
A,D *17 EVC
1

2065 EVC
1
EVC
2
B,D *337 EVC
2
2066 EVC
2
EVC
3
C,D *1023 EVC
3
2067 EVC
3
Figure 25 Untagged UNI s
Consider an untagged ingress Service Frame at UNI A. It will be mapped to EVC
1
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 EVC
1
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
B
C
D
EVC
1
Higher
Layer
Service
Higher
Layer
Service
Customers

MEF 10.2
Page 55

EVC UNI s CE-VLAN I D EVC CE-VLAN I D EVC CE-VLAN I D EVC CE-VLAN I D EVC
EVC
1
A (Leaf)
B (Leaf)
C (Leaf)
D (Root)
*17 EVC
1
3379 EVC
1
*1023 EVC
1
2065 EVC
1

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
B
D
EVC
1
Higher
Layer
Service
Higher
Layer
Service
Customers
C
EVC
2

EVC UNI s CE-VLAN I D EVC CE-VLAN I D EVC CE-VLAN I D EVC CE-VLAN I D EVC
EVC
1
A,C,D 2881 EVC
1

124 EVC
1
2065 EVC
1
EVC
2
B,C,D 3379 EVC
2
125 EVC
2
2066 EVC
2
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
Page 56

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.

whi l e( ( L <= C( t ) ) && ( B( t ) > 0) )
{
C( t ) = C( t ) L;
t r ansmi t t he f r ame at t he head of t he buf f er ; / / Shoul d be decl ar ed gr een
}
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
Page 57

i f ( B( t ) == 0) / / I f buf f er i s empt y
{
i f ( l engt h of new f r ame <= C( t ) )
{
C( t ) = C( t ) l engt h of new f r ame;
t r ansmi t new f r ame; / / Shoul d be decl ar ed gr een
}
el se
{
pl ace new f r ame i n buf f er ;
}
}
el se
{
whi l e( L <= C( t ) )
{
C( t ) = C( t ) L;
t r ansmi t t he f r ame at t he head of t he buf f er ; / / Shoul d be decl ar ed gr een
}
i f ( B( t ) <= THS)
{
}
el se
{
whi l e( ( L <= E( t ) && ( B( t ) > THS) )
{
E( t ) = E( t ) L;
t r ansmi t t he f r ame at t he head of t he buf f er ; / / Shoul d be decl ar ed yel l ow
}
i f ( B( t ) <= THS)
{
}
el se
{
di scar d new f r ame;
}
}
}
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
Page 58

UNI A UNI C UNI E
UNI B UNI D
Important paths for CoS 1
Important paths for CoS 2
Multipoint EVC

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:
{ } E A D A C A B A S
A
, , , , , , ,
1 ,
=
{ } E B D B C B A B S
B
, , , , , , ,
1 ,
=
{ } B C A C S
C
, , ,
1 ,
=
{ } B D A D S
D
, , ,
1 ,
=
{ } B E A E S
E
, , ,
1 ,
=
{ } E A C A S
A
, , ,
2 ,
=
{ } E C A C S
C
, , ,
2 ,
=
{ } A E C E S
E
, , ,
2 ,
=
For this example, assume that T, t ,
u
C ,
a
C , and n, are used for all availability definitions.
Then using the definition in Section 6.9.8,
1 ,
,
A
S T
A 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,
2 ,
,
C
S T
A 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
Page 59

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:
{ } E B D B C B E A D A C A B A S , , , , , , , , , , , , ,
1
=
{ } E C E A C A S , , , , ,
2
=
For this example, assume that T, t ,
u
C ,
a
C , and n, are used for both availability definitions.
Then using the definition in Section 6.9.8,
1
,S T
A can be viewed as the availability of Class of
Service 1 on the EVC and
2
,S T
A can be viewed as the availability of Class of Service 2 on the
EVC.

MEF 13

MEF 13

User Network I nterface (UNI ) Type 1
I mplementation Agreement

November, 2005

MEF 13

Disclaimer
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.
user of this document. The MEF is not responsible or liable for any modifications to this docu-
ment made by any other party.
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

User Network I nterface (UNI ) Type 1 I mplementation Agreement
MEF 13
Page i

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

User Network I nterface (UNI ) Type 1I mplementation Agreement
MEF 13
Page 1

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
CE-VLAN CoS
The user-priority bits of the IEEE 802.1Q Tag in a tagged Service Frame over
UNI.
CE-VLAN I D
The identifier derivable from the content of a Service Frame that allows the
Service Frame to be associated with an EVC at the UNI.
CI R committed Information Rate
EVC
Ethernet Virtual Connection. An association of two or more UNIs that limits
the exchange of frames to UNIs in the Ethernet Virtual Connection
Frame Short for Ethernet frame.
I ngress The direction from the CE into the Service Provider network.
Layer 2 Control
Protocol Service
Frame
A Service Frame that is used for Layer 2 control, e.g., Spanning Tree Proto-
col.
Multicast Service
Frame
A Service Frame that has a multicast destination MAC address.
Multipoint EVC An EVC with two or more UNIs.
EI R Excess Information Rate
Point-to-Point
EVC
An EVC with exactly 2 UNIs.
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 Multip-
lexing
A UNI attribute in which the UNI can be in more than one EVC instance.
Service Provider The organization providing Ethernet Service(s).
Subscriber The organization purchasing and/or using Ethernet Services.
UNI
User Network Interface. The physical demarcation point between the respon-
sibility of the Service Provider and the responsibility of the Subscriber
Unicast Service
Frame
A Service Frame that has a unicast destination MAC address.
MEF 13
Page 2

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
document are to be interpreted as described in RFC 2119. All key words must be use upper case,
bold text
MEF 13
Page 3

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
Page 4

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
Page 5

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
Page 6

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
EVCs
8 64 512
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
CE-VLANs
8 64 512
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
Page 7

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:
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)
Marker Protocol
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
Marker Protocol
MEF 13
Page 8

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.
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
Page 9

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 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall

MEF 26.1

External Network Network Interface (ENNI)
Phase 2

January 2012


Disclaimer
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.
or otherwise:
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
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
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

(C) 2012. The Metro Ethernet Forum. All Rights Reserved.

External Network Network Interface (ENNI) Phase 2

Page i

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


Page ii

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


Page iii

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-N
i
......................................................................................... 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 ( )
k j i
t A
,
........................................................................... 42
Figure 11 Example of the Determination of ( )
k j i
t A
,
............................................................ 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 23 Example of Hairpin Switching.................................................................................. 71
Figure 24 Example of a Data Loop with Hairpin Switching ..................................................... 71
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


Page iv

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 36 Rooted-Multipoint EVC using a Bundled OVC........................................................ 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


Page 1

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
OVC
A non-Rooted Multipoint OVC that associates an OVC End
Point that has more than one S-VLAN ID value that maps to it.
This docu-
ment
CE Customer Edge MEF 10.2[5]
CHLI Consecutive High Loss Interval This docu-
ment
Color For-
warding
An OVC attribute defining the relationship between the Color of
an egress ENNI Frame and the Color of the corresponding in-
gress ENNI Frame or Service Frame
This docu-
ment
Consecutive
High Loss
Interval
A sequence of small time intervals, each with a high frame loss
ratio
This docu-
ment
C-Tag Subscriber VLAN Tag IEEE Std
802.1ad[4]
DSCP Diff-Serve Code Point RFC
2474[14]
End Point
Map
A mapping of specified S-Tag VLAN ID values to specified
OVC End Point Identifiers
This docu-
ment
End Point
Map Bun-
dling
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
This docu-
ment
End Point
Type
A parameter in the End Point Map (In this specification the End
Point Type is always OVC End Point.)
This docu-
ment
ENNI A reference point representing the boundary between two Opera-
tor MENs that are operated as separate administrative domains
MEF 4[1]

1
MEF 4 [1] hyphenates the acronym but this document does not.


Page 2

ENNI Frame The first bit of the Destination Address to the last bit of the
Frame Check Sequence of the Ethernet Frame transmitted across
the ENNI
This docu-
ment
ENNI MTU

MTU of an ENNI frame at the ENNI This docu-
ment
ENNI-N
i

The functional element administered by the Operator of the ith
Operator MEN that supports the protocols and procedures re-
quired in this document
This docu-
ment
EVC An association of two or more UNIs MEF 10.2[5]
E-WAN An MEF defined ETH services aware network that provides con-
nectivity between two or more MENs via ENNIs
MEF 4[1]
External In-
terface
Either a UNI or an ENNI
2
MEF 4[1]
High Loss
Interval
A small time interval with a high frame loss ratio This docu-
ment
HLI High Loss Interval This docu-
ment
L2CP Tun-
neling
The process by which a frame containing a Layer 2 Control Pro-
tocol is transferred between External Interfaces.
This docu-
ment
Leaf OVC
End Point
An OVC End Point that has the role of Leaf This docu-
ment
MEN A Metro Ethernet Network comprising a single administrative
domain
MEF 10.2[5]
MTU Maximum Transmission Unit This docu-
ment
Multipoint-
to-Multipoint
OVC
An OVC that can associate two or more Root OVC End Points This docu-
ment
Network Op-
erator
The Administrative Entity of a MEN MEF 4[1]
Operator Vir-
tual Connec-
tion
An association of OVC End Points This docu-
ment
OVC Operator Virtual Connection This docu-
ment
OVC End
Point
An association of an OVC with a specific External Interface i.e.,
UNI, ENNI
This docu-
ment
OVC End
Point Role
A property of an OVC End Point that determines the forwarding
behavior between it and other OVC End Points that are associ-
ated with the OVC End Point by an OVC
This docu-
ment

2
MEF 4 considers several types of External Interfaces. This document is limited to consideration of the UNI and
ENNI.


Page 3

OVC Identi-
fier
string that is unique among all OVCs in the Operator MEN This docu-
ment
Point-to-
Point OVC
An OVC that associates exactly two Root OVC End Points This docu-
ment
Resiliency
Performance
The number of High Loss Intervals and Consecutive High Loss
Intervals in a time interval T
This docu-
ment
Root OVC
End Point
An OVC End Point that has the role of Root This docu-
ment
Rooted-
Multipoint
OVC
An OVC that can associate at least one Leaf or Trunk OVC End
Point
This docu-
ment
Service
Frame
An Ethernet frame transmitted across the UNI toward the Ser-
vice Provider or an Ethernet frame transmitted across the UNI
toward the Subscriber
MEF 10.2[5]
Service Pro-
vider
The organization responsible for the UNI to UNI Ethernet ser-
vice
MEF 10.2[5]
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-
byte field that, when present in an Ethernet frame, appears im-
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
IEEE Std
802.1ad[4]
Trunk OVC
End Point
An OVC End Point that has the role of Trunk This docu-
ment
UNI The physical demarcation point between the responsibility of the
Service Provider and the responsibility of the Subscriber
MEF 10.2[5]
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-N
i
.
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.


Page 4

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].


Page 5

Operator A
Operator D
Operator C
Operator B UNI 3
UNI 2
UNI 4
UNI 1
ENNI
ENNI
ENNI

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


Page 6

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.


Page 7

Public Service Networks
(Internet, PPP, FR, ATM)
Admin Domain X
External Transport
Networks
Admin Domain X
Subscriber
Admin Domain Y
Ethernet-aware Wide
Area Network (E-WAN)
Admin Domain Z
Admin Domain W
UNI
Service Interworking NNI
Network Interworking NNI
Network Interworking NNI
External NNI
External NNIs

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


Page 8

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.
ENNI
UNI A
UNI B
a
b
c
e d
f
a OVC End Point
OVC
Operator
MEN

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.


Page 9

UNI P UNI T
UNI V UNI S
UNI R
UNI Q
ENNI AB
ENNI BC
A1 A3
A2
B3
B4
B1
B2
C1
C4
Operator
MEN A
Operator
MEN B
Operator
MEN C
OVC End
Point x
OVC End
Point y
A3, B3 UNI P, UNI R 3 (black)
B4, C4 UNI S, UNI V 4 (green)
A2, B2 UNI Q, UNI S 2 (blue)
A1, B1, C1 UNI P, UNI R, UNI T 1 (red)
OVCs UNIs EVC

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-N
1
and ENNI-N
2
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.


Page 10

ENNI
Operator MEN 1
Operator MEN 2
ENNI-N
1 ENNI-N
2

Figure 5 Representation of ENNI-N
i

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).


Page 11

ENNI
Operator MEN
ENNI
UNI
UNI

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.


Page 12

Attribute Name Summary Description Possible Values
Operator ENNI Identi-
fier
An identifier for the ENNI intended
for management purposes
A string that is unique across the
Operator MEN.
Physical Layer The physical layer of the links sup-
porting the ENNI
One of the PHYs listed in [R5]
Frame Format The format of the PDUs at the
ENNI
Frame formats as specified in
Section 7.1.3
Number of Links The number of physical links in the
ENNI
An integer with value 1 or 2
Protection Mechanism The method for protection, if any,
against a failure
Link Aggregation, none, or other
ENNI Maximum
Transmission Unit
Size
The maximum length ENNI Frame
in bytes allowed at the ENNI
An integer number of bytes
greater than or equal to 1526
End Point Map The map that associates each S-
Tagged ENNI Frame with an End
Point
A table with rows of the form
<S-VLAN ID value, End Point
Identifier, End Point Type>
Maximum Number of
OVCs
The maximum number of OVCs
that the Operator can support at the
ENNI
An integer greater than or equal
to 1
Maximum Number of
OVC End Points per
OVC
The maximum number of OVC
End Points that the Operator can
support at the ENNI for an OVC.
An integer greater than or equal
to 1
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.


Page 13

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.


Page 14

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.


Page 15

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
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].


Page 16

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
158 Gotham Central Exchange_12-1224 OVC
189 Gotham Central Exchange_12-1589 OVC

Operator MEN B End Point Map
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.


Page 17

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.


Page 18

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.


Page 19

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


Page 20

Ingress OVC End Point Role
Root Leaf Trunk
(Leaf S-VID)
Trunk
(Root S-VID)
Root

Leaf
Trunk
(Leaf S-VID)

E
g
r
e
s
s

O
V
C

E
n
d

P
o
i
n
t

R
o
l
e

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.



Page 21

OVC Identifier An identifier for the OVC intended for management
purposes
A string that is
unique across the
Operator MEN
OVC Type An indication of the number and roles of the OVC End
Points associated by the OVC.
Point-to-Point,
Multipoint-to-
Multipoint, or
Rooted-Multipoint
OVC End Point
List
A list of OVC End Points associated by the OVC and
the OVC End Point Role of each OVC End Point asso-
ciated by the OVC
A list of <OVC
End Point Identi-
fier, OVC End
Point Role> pairs
Maximum Num-
ber of UNI OVC
End Points
The bound on the number of OVC End Points at differ-
ent UNIs that can be associated by the OVC
An integer greater
than or equal to 0
4

Maximum Num-
ber ENNI OVC
End Points
The bound on the number of OVC End Points at ENNIs
that can be associated by the OVC
An integer greater
than or equal to 1
4

OVC Maximum
Transmission
Unit Size
The maximum length in bytes allowed in a frame
mapped to the an OVC End Point that is associated by
the OVC
An integer number
of bytes greater
than or equal to
1526
CE-VLAN ID
Preservation
A relationship between the format and certain field val-
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
Yes or No
CE-VLAN CoS
Preservation
A relationship between the format and certain field val-
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
Yes or No
S-VLAN ID
Preservation
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
Yes or No
S-VLAN CoS
Preservation
A relationship between the S-VLAN PCP value of a
frame at one ENNI and the S-VLAN PCP value of the
corresponding frame at another ENNI
Yes or No

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.


Page 22

Color Forward-
ing
The relationship between the Color of an egress ENNI
Frame and the Color of the corresponding ingress
ENNI Frame or Service Frame
Yes or No
Service Level
Specification
Frame delivery performance definitions and objectives
for frames between External Interfaces
See Section 7.2.16
Unicast Service
Frame Delivery
This attribute describes how ingress frames mapped to
an OVC End Point with a unicast destination MAC ad-
dress are delivered to the other External Interfaces with
OVC End Points associated by the OVC
Deliver Uncondi-
tionally or Deliver
Conditionally
Multicast Service
Frame Delivery
an OVC End Point with a multicast destination MAC
address are delivered to the other External Interfaces
with OVC End Points associated by the OVC
Deliver Uncondi-
tionally or Deliver
Conditionally
Broadcast Ser-
vice Frame De-
livery
an OVC End Point with the broadcast destination MAC
address are delivered to the other External Interfaces
with OVC End Points associated by the OVC
Deliver Uncondi-
tionally or Deliver
Conditionally
Layer 2 Control
Protocol Tunnel-
ing
The Layer 2 Control Protocols that are tunneled by the
OVC
A list on Layer 2
Control Protocols
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.


Page 23

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-


Page 24

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.


Page 25

Ingress
Interface
Ingress
Frame For-
mat
Egress
Interface
Egress Frame Format
UNI Untagged UNI Untagged
UNI Untagged ENNI S-Tag only
UNI C-Tagged UNI
C-Tagged with VLAN ID value equal to that of in-
gress Service Frame at the UNI
UNI C-Tagged ENNI
S-Tag and C-Tag with the VLAN ID value in the C-
Tag equal to the VLAN ID value in the C-Tag at the
UNI
ENNI
S-Tag and C-
Tag
UNI
C-Tagged with the VLAN ID value of the C-Tag
equal to that of the VLAN ID value in the C-Tag of
the ingress frame at the ENNI
ENNI S-Tag only UNI Untagged
ENNI
S-Tag and C-
Tag
ENNI
S-Tag and C-Tag with the VLAN ID value in the C-
Tag equal to the VLAN ID value in the C-Tag at the
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
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.


Page 26

Ingress
Interface
Ingress Frame Format
Egress
Interface
Egress Frame Format
UNI
C-Tagged with VLAN ID
value in the range 1, ,
4094
UNI
C-Tagged with VLAN ID value equal to
that of the ingress Service Frame at the
UNI
UNI
C-Tagged with VLAN ID
value in the range 1, ,
4094
ENNI
S-Tag and C-Tag with the VLAN ID
value in the C-Tag equal to the VLAN
ID value in the C-Tag at the UNI
ENNI
S-Tag and C-Tag with
VLAN ID value in the C-
Tag in the range 1, ,
4094
UNI
Tagged with the VLAN ID value of the
C-Tag equal to that of the C-Tag of the
ingress frame at the ENNI
ENNI
S-Tag and C-Tag with
VLAN ID value in the C-
Tag in the range 1, ,
4094
ENNI
S-Tag and C-Tag with the VLAN ID
value in the C-Tag equal to the VLAN
ID value in the C-Tag at the ingress
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
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
Format
Egress Frame Format
S-Tag and C-Tag
S and C-Tag with the VLAN ID value in the C-Tag equal to the VLAN ID
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.


Page 27

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
Interface
Ingress
Frame For-
mat
Egress
Interface
Egress Frame Format
UNI C-Tagged UNI
C-Tagged with PCP value equal to that of ingress
Service Frame
UNI C-Tagged ENNI
S-Tag and C-Tag with the PCP value in the C-Tag
equal to the PCP value in the C-Tag at the UNI
ENNI
S-Tag and C-
Tag
UNI
C-Tagged with the PCP value of the tag equal to that
of the C-Tag of the ingress frame at the ENNI
ENNI
S-Tag and C-
Tag
ENNI
S-Tag and C-Tag with the PCP value in the C-Tag
equal to the PCP value in the C-Tag of the ingress
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.


Page 28

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


Page 29

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.


Page 30

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 Availability
5
, 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 identifier
6
, 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] .


Page 31

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 EI
1
and results in a frame that egresses at
EI
2
is defined as the time elapsed from the reception of the first bit of the ingress frame at EI
1

until the transmission of the last bit of the first corresponding egress frame at EI
2
. If the frame is
erroneously duplicated in the Operator MEN and multiple copies delivered to EI
2
, 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-way
7
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,
O
D , between a UNI and an
ENNI on single Operator MEN can be expressed as
M E U O
d d d D + + = were
U
d is the time to
transmit the frame across the UNI,
E
d is the time to transmit the frame across the ENNI, and
M
d
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
2 2 1 1 U M E M U
d d d d d + + + + . But
2 2 1 1 2 2 1 1 2 1
2
U M E M U E M U M U O O
d d d d d d d d d d D D + + + + + + + + = + .
Adding the two OVC delays overstates the UNI to UNI delay by
E
d .

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.


Page 32

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 j i m j m i j i S , , ,..., 1 , ,..., 1 | , .
Let
j i
Td
d
,
represent the
d
P -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
egress frames, then =
j i
Td
d
,
Undefined.
Then the One-way Frame Delay Performance metric MUST be defined as the
maximum value of all of the defined values
j i
Td
d
,
j i
Td
d
,

Let
j i j i
Tr
j i
TR
d d d
,
min
, ,
= .
j i
Tr
d
,
represents the
r
P -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.
j i
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
=
j i
TR
d
,
Undefined.
Then the One-way Frame Delay Range Performance metric MUST be defined as
the maximum value of all of the defined values of
j i
TR
d
,
j i
TR
d
,
Let
j i
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
egress frames, then =
j i
T
,
Undefined.


Page 33

Then the One-way Mean Frame Delay Performance metric MUST be defined as
the maximum value of all of the defined values
j i
T
,
j i
T
,
To restate the Frame Delay definition mathematically, let the OVC End Points associated by the
OVC be numbered from 1 to m and let
j i
T
D
,
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
the EI where OVC End Point i is located.
j i
T
D
,
can be expressed as { }
j i
N
j i j i j i
T
j i
d d d D
, ,
2
,
1
,
,
,..., , = ,
where
j i
k
d
,
is the one-way Frame Delay of the k
th
frame. Define
j i
Td
d
,
for 0 >
d
P as
( )
=

=
otherwise
1 if ,
100
| min
,
1
,
,
,
,
Undefined
N d d I
N
P d
d
j i
N
k
j i
k
j i
d
j i
Td
j i

where ( )
k
d I , is an indicator function defined by
( )
otherwise 0
if 1
,
k
k
d d
d d I .

j i
Td
d
,
is the minimal delay during the time internal T that
d
P percent of the frames do not ex-
ceed.
Then a One-way Frame Delay Performance metric for an OVC can be expressed as
{ }
=
>
=
S j i N Undefined
N S j i d
d
j i
j i
j i
Td
S T
, all for 0 all when
0 where and , | max
,
,
,
,
.
The One-way Frame Delay attribute permits specification of multiple values for
d
P , (P
0
, P
1
, P
2
,
) and corresponding objectives (
j i
d
,
0
,
j i
d
,
1
,
j i
d
,
2
, ).
Another parameter is the objective for the difference between the delay
r
P percentile delay and
{ }
j i
T
j i
D d d
, ,
min
min = , expressed as
=
>
=
0 if
0 if ) (
,
,
,
min
,
,
j i
j i
j i j i
Tr j i
TR
N Undefined
N d d
d
where


Page 34

( )
=

=
otherwise
1 if ,
100
| min
,
1
,
,
,
,
Undefined
N d d I
N
P d
d
j i
N
k
j i
k
j i
r
j i
Tr
j i
.
Then a One-way Frame Delay Range Performance metric for an OVC can be expressed as
{ }

0 where and , | max
,
,
,
,
=
>
=
S j i N Undefined
N S j i d
d
j i
j i
j i
TR
S TR
.
Another One-way Frame Delay attribute is the arithmetic mean of
j i
T
D
,
, which can be expressed
as
( )
=
>
=

=
0 if
0 if
1
,
,
1
,
,
,
,
j i
j i
N
k
j i
k
j i
j i
T
N Undefined
N d
N
j i

Then a One-way Mean Frame Delay Performance metric for an OVC can be expressed as
{ }
=
>
=
S j i N Undefined
N S j i
j i
j i
j i
T
S T
0 where and , | max
,
,
,
,
.
The parameters of a One-way Frame Delay Performance metric are given in Table 10.

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
d
P

A specific percentile for the Frame Delay Performance, 0 >
d
P
r
P A specific percentile for the Frame Delay Range Performance, 0 >
r
P
d

d
P
R
d
One-way Frame Delay Range Objective corresponding to

r
P
One-way Mean Frame Delay Performance Objective
Table 10 One-way Frame Delay Performance Parameters
[R54] Given T, S, COS ID,
d
P , 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
d d
S T
,
or
S T
d
,
is Undefined.


Page 35

r
P , and a One-way Frame Delay Range Performance objec-
tive
R
d
, expressed in time units, an SLS MUST define the one-way Frame Delay
Range Performance objective as met over the time interval T for the subset S if
and only if
R S TR
d d
,
or
S TR
d
,
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
,

S T
or
S T ,
is Undefined.
Recall that if any of the above performance attributes are Undefined for time interval T and or-
dered pair j i, , 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 RFC3393
8
where IP packet delay variation is
defined.
Let
i
a be the time of the arrival of the first bit of the i
th
frame at the ingress EI, then the two
frames i and j are selected according to the selection criterion:
{ } i j and a a
i j
> =
Let
i
r 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
j i
d d . Define
( ) ( ) ( ) ( )
i j i j j j i i j i ij
r r a a a r a r d d d = = =

8
C. Demichelis and P. Chimento, IP Packet Delay Variation Metric for IP Performance Metric (IPPM), RFC 3393,
November 2002.


Page 36

With
j
d being the delay of the j
th
frame, a positive value for
j i
d d 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
ij
d 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.
Ingress
Egress
i i+1 j+1 j
a
i
a
j
r
i
r
j
Time
d
i
d
j

Figure 9 Inter-Frame Delay Variation Definition
and a given Class of Service Identifier, the SLS MUST define the Inter-Frame
Delay Variation Performance metric as follows:
Let
j i
T
d
,
~
be the
v
P -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,
then Undefined d
j i
T
=
,
~
.
Then the Inter-Frame Delay Variation Performance metric MUST be the maxi-
mum of the defined values
j i
T
d
,
~
j i
T
d
,
~
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 [T
1
, T
2
].


Page 37

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 j i m j m i j i S , , ,..., 1 , ,..., 1 | , .
Let
} ,..., , {
, ,
2
,
1
,
,
j i
N
j i j i j i
T
j i
d d d V =
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

=

=
otherwise
1 if ) , (
100
| min ~
,
1
,
,
,
,
Undefined
N d d I
N
P d
d
j i
N
k
j i
k
j i
v
j i
T
j i

where ( ) d I , is an indicator function defined by
( )
otherwise
if
0
1
,
d d
d d I

.
Then an Inter-Frame Delay Variation Performance metric for an OVC can be expressed as
{ }
=

=
S j i N Undefined
N S j i d
d
j i
j i
j i
T
S T
1 where and , |
~
max
~
,
,
,
,
.
The parameters of an Inter-Frame Delay Variation performance metric are given in Table 11.


Page 38

T The time interval
v
P Inter-Frame Delay Variation Performance percentile, 0 >
v
P

The separation between frame pairs for which Inter-Frame Delay Variation Per-
formance is defined
d
(

Table 11 Inter-Frame Delay Variation Parameters
v
P , , 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 d d
S T
(

,
~
or
S T
d
,
~
is Undefined.
Recall that if the Inter-Frame Delay Variation is Undefined for time interval T and ordered pair
j i, , then the performance for that ordered pair is excluded from calculations on the perform-
ance of pairs in S.
7.2.16.3 One-way Frame Loss Ratio Performance for an OVC
and a given Class of Service Identifier, the SLS MUST define the One-way
Frame Loss Ratio Performance metric as follows:
Let
j i
T
I
,
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


Page 39

7.2.17, 7.2.18, and 7.2.19). Each frame can be a Unicast, Multicast, or Broadcast
frame.
Let
j i
T
E
,
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
from a frame counted in
j i
T
I
,
.
Define

|
|
\
|

=
otherwise
1 if 100
,
,
, ,
,
Undefined
I
I
E I
FLR
j i
T
j i
T
j i
T
j i
T
j i
T
.
Then the One-way Frame Loss Ratio Performance metric MUST be defined as
{ }
=

=
S j i I Undefined
I S j i FLR
FLR
j i
T
j i
T
j i
T
S T
1 where and , | max
,
, ,
,
.
The parameters of a One-way Frame Loss Ratio Performance metric are given in Table 12.

T The time interval
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 L FLR
S T
,
or
S T
FLR
,
is
Undefined.
Recall that if the One-way Frame Loss Ratio Performance is Undefined for time interval T and
ordered pair j i, , then the performance for that ordered pair is to be excluded from calculations
on the performance of pairs in S.


Page 40

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
k
t in T is defined to be either Available or Unavailable and this is represented by
( )
k j i
t A
,
where ( ) 1
,
=
k j i
t A means that
k
t is Available and ( ) 0
,
=
k j i
t A means that
k
t
is Unavailable.
The definition of ( )
k j i
t A
,
is based on the frame loss ratio function ( )
k j i
t flr
,
which is de-
fined as follows.
Let
j i
t
I
,
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,


Page 41

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]
Let
j i
t
E
,
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
counted in
j i
t
I
,
.
Then ( )
|
|
\
|

=

otherwise 0
1 if
,
,
, ,
,
j i
t
j i
t
j i
t
j i
t
j i
I
I
E I
t flr .
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 ( ) t flr
j i

,
as
( )
|
|
\
|

=

otherwise 0
1
~
if
~
~
,
,
, ,
,
j i
t
j i
t
j i
t
j i
t
j i
I
I
E I
t flr

where
~
, ,
=

j i
t
j i
t
I I 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.
0
t 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. ( )
k j i
t A
,
is defined in Figure 10
for ,... 2 , 1 , 0 = k .


Page 42

( ) 1
1 ,
=
k j i
t A
( ) ,
,
C t flr
m j i
>
1 ,..., 1 , + + = n k k k m
( ) ,
,
C t flr
m j i

1 ,..., 1 , + + = n k k k m
( ) 0
,
=
k j i
t A
( ) 1
,
=
k
j i
t A
Yes
No
Yes
No
Yes
No
/*Chec k ava ilabili ty of pre vious interval*/
/ *Transiti on to Avai labl e if
next n interval s have low
l oss*/
/*Transition t o Unavai lable
if ne xt n intervals have high
loss*/
0 or = k
Begin

Figure 10 Flowchart Definition of ( )
k j i
t A
,

An alternative way of expressing ( )
k j i
t A
,
for 0 = k is
( )
( )
= >
=
otherwise 1
1 ,... 1 , 0 all for if 0
,
0 ,
n m C t flr
t A
m j i
j i

and for ,... 2 , 1 = k is
( )
( ) ( )
( ) ( )
( )
+ + = =
+ + = > =
=
otherwise
1 ,..., 1 , all for and 0 if 1
1 ,..., 1 , all for and 1 if 0
1
, 1
, 1
,
k i,j
m j i k i,j
m j i k i,j
k j i
t A
n k k k m C t flr t A
n k k k m C t flr t A
t A .
In the event of a conflict between the above equations and Figure 10, the content of Figure 10 is
controlling.
The availability for
k
t is based on the frame loss ratio during the short interval and each of the
following 1 n short intervals and the availability of the previous short time interval. In other
words, a sliding window of width t n is used to define availability. This use of a sliding win-
dow is similar to that of ITU-T Y.1563. [23]


Page 43

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.
Time
( ) C t flr
m j i
>
,
( ) C t flr
m
j i

,
0
t
10 = n
t n t n
( ) 1
,
=
k
j i
t A ( ) 1
,
=
k j i
t A ( ) 0
,
=
k
j i
t A
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 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0

Figure 11 Example of the Determination of ( )
k j i
t A
,

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.


Page 44

( ) C t flr
m j i
>
,
Time
( ) C t flr
m
j i

,
0
t
10 = n
t n t n
( ) 1
,
=
k
j i
t A ( ) 1
,
=
k
j i
t A ( ) 0
,
=
k
j i
t A
Mai ntenance Interval
Excluded from Availability calculation for T
1 1 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
X
X XXXX XXXX XXX XXXX XXXX XXX XXXX XXX XXXX X

Figure 12 Example of the Impact of a Maintenance Interval
Let { } Interval e Maintenanc a intersect not does and |
k k T
t T t k W = and let
T
W represent the
number of elements in the set
T
W . 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
( )
>
=

otherwise 100
0 if
100
,
,
T T
W k
T k j i
T
j i
W t A
W A .
Note that the definition of
T
W means that the boundaries of T and the boundaries of a Mainte-
nance Interval do not have to align with the boundary of a
k
t . A
k
t that straddles the bound-
ary between two Ts is excluded from the definition of Availability Performance for each interval
T. A
k
t 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 m ,..., 2 , 1 and let S be a non-empty
subset of the ordered pairs of OVC End Points, i.e.,
{ } = = S j i m j m i j i S , , ,..., 2 , 1 , ,... 2 , 1 | , .
Then the Availability for a particular Class of Service Identifier for the set S is defined by
{ } S j i A A
j i
T
S
T
= , | min
,
.
The parameters of a One-Way Availability Performance Metric are given in Table 13.


Page 45

T The time interval
S Non-empty subset of the ordered OVC End Point pairs
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 A A
S
T
.
dered pairs of OVC End Points associated the OVC.
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.


Page 46

SLS Interval, T
Unavailable Time Available Time
High Loss Intervals
Non-High Loss
Intervals
Consecutive Hi gh Loss
Intervals
Non-Consecutive
High Loss Intervals
Maintenance Interval
Time

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:
) (
, k j i
t H : the high loss state of
k
t ,
equal to 1 when ( ) C t flr
j i
>
,
and ( ) 1
,
=
k j i
t A , equal to 0 otherwise,
including any
k
t that intersects a Maintenance Interval

j i
T
L
,
: 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

j i
T
B
,
: 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


Page 47

For every t in T that does not intersect a Maintenance Interval, the frame loss ratio and Avail-
ability state determine the value of ) (
, k j i
t H , either 1 or 0 as defined above.
[R66] For the SLS, the count of High Loss Intervals over T MUST be determined by
( )

=
T t
j i
j i
T
t H L
,
,
.
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
{ } T t k
k
= | integer min
0
,
=
j i
T
B
( ) k p k m t H
m
j i
,..., 1 , 1
,
+ = =
( )
, 1
,
=
p k
j i
t H
1
, ,
+ =
j i
T
j i
T
B B
1 + = k k
T t
k
End
No
No
No
Yes
Yes
Yes
/*Counter = 0 at st art of T*/
/*p consecutive High Loss
intervals?*/
/*Exist ing cons ecutive run?*/
/*Increment counter*/

Figure 14 Determining and Counting Consecutive High Loss Intervals over T
Figure 15 shows an example that depicts the HLI and CHLI counting processes.


Page 48

( ) C t flr
m j i
>
,
Time
( ) C t f lr
m
j i

,
0
t
3 , 10 = = p n
( )
k
j i
t A
,
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
0 0 0 1 1 11 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 ( )
k
j i
t H
,
0 0 0 1 2 13 4 4 5 6 7 7 8 8 8 8 18 8 8 8 8 8 8 8 8 8 8 18 8 8 8 8 8 8 8 8 8 8 18 9 9 9 9 9
0 0 0 0 0 11 1 1 1 1 2 2 2 2 2 2 12 2 2 2 2 2 2 2 2 2 2 12 2 2 2 2 2 2 2 2 2 2 12 2 2 2 2 2
1 1 0 1 1 1
j i
T
L
,
j i
T
B
,
0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1
t n t n
1

Figure 15 Example of Counting High Loss Intervals and Consecutive High Loss Intervals
Let the OVC End Points associated by the OVC be numbered m ,..., 2 , 1 and let S be a non-empty
subset of the ordered pairs of OVC End Points, i.e.,
{ } = = S j i m j m i j i S , , ,..., 2 , 1 , ,... 2 , 1 | , .
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
{ } S j i L L
j i
T
S
T
= , | max
,
and { } S j i B B
j i
T
S
T
= , | max
,
.
The parameters of the One-Way Resiliency Performance metrics are given in Table 14.

T The time interval
S Non-empty subset of the ordered OVC End Point pairs associated by the OVC
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.


Page 49

[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 L L
S
T
, and the CHLI Perform-

ance objective as being met if and only if B B
S
T
.
dered pairs of OVC End Points associated the OVC so long as it is non-empty.
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 OVC
9
.
[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
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.


Page 50

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
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 Addresses
10

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


Page 51

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-
terface
Egress Inter-
face
Egress Frame Format
11

UNI (L2CP
Service
Frame)
UNI (L2CP
Service
Frame)
Identical to the ingress frame.
UNI (L2CP
Service
Frame)
ENNI (L2CP
ENNI Frame)
All fields from the Destination Address through the Payload of
the ingress Service Frame present and unchanged. S-Tag added
in after the Source Address.
ENNI (L2CP
ENNI Frame)
UNI (L2CP
Service
Frame)
All fields from the Destination Address through the Payload ex-
cept the S-Tag of the ingress ENNI Frame present and un-
changed. No S-Tag is present.
ENNI (L2CP
ENNI Frame)
ENNI (L2CP
ENNI Frame)
All fields from the Destination Address through the Payload of
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.


Page 52

OVC End Point
Identifier
An identifier for the OVC End Point
intended for management purposes
A string that is unique across the
Operator MEN

Trunk Identifiers For a Trunk OVC End Point, specifies
the S-VLAN ID values used on the
ENNI to distinguish frames originating
at a Root UNI and frames originating at
a Leaf UNI
<Root S-VLAN ID value, Leaf
S-VLAN ID value> for Trunk
OVC End Points; Not Applica-
ble to Root or Leaf OVC End
Points
Class of Service
Identifiers
The way that a Class of Service is de-
termined for an ENNI Frame at each
ENNI
The OVC associating the End
Point and non-overlapping sets
of values of the S-Tag Priority
Code Point
Ingress Bandwidth
Profile Per OVC
End Point
Ingress policing by the Operator MEN
on all ingress ENNI Frames mapped to
the OVC End Point
No or parameters as defined in
Section 7.6.1
Ingress Bandwidth
Profile Per ENNI
Class of Service
Identifier
Ingress policing by the Operator MEN
on all ingress ENNI Frames with the
Class of Service Identifier for the re-
ceiving Operator MEN
Section 7.6.1
Egress Bandwidth
Profile Per End
Point
Egress policing by the Operator MEN
on all egress ENNI Frames mapped to
the OVC End Point
Section 7.6.1
Egress Bandwidth
Profile Per ENNI
Class of Service
Identifier
Egress policing by the Operator MEN
on all egress ENNI Frames with the
Class of Service Identifier for the re-
ceiving MEN
Section 7.6.1
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.


Page 53

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


Page 54

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


Page 55

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 Point
1
could have CIR=15 Mbps, OVC End Point
2
could have
CIR = 10 Mbps, and OVC End Point
3
could have CIR = 20 Mbps.

ENNI ENNI
OVC EP OVC EP
1 1
OVC EP OVC EP
2 2
OVC EP OVC EP
3 3
Bandwidth Profile per OVC EP Bandwidth Profile per OVC EP
1 1
2 2
3 3

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


Page 56

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


Page 57

UNI OVC Identifier An identifier for the instance of
the OVC at a UNI intended for
management purposes
A string formed by the concatena-
tion of the UNI Identifier and the
OVC Identifier

OVC End Point Map The CE-VLAN ID(s) that map to
the OVC End Point at the UNI
A list of one or more CE-VLAN
ID values
Class of Service Identi-
fiers
The way that a Class of Service
is determined for a frame at each
UNI
Non-overlapping sets of values of
C-Tag Priority Code Point values
or DSCP values as specified in
Section 7.5.3
Ingress Bandwidth Pro-
file Per OVC End Point
at a UNI
Ingress policing by the Operator
MEN on all ingress Service
Frames mapped to the OVC End
Point
Section 7.11.1 in MEF 10.2 [5]
Ingress Bandwidth Pro-
file Per Class of Ser-
vice Identifier at a UNI
Ingress policing by the Operator
on all ingress Service Frames
with a given Class of Service
Identifier
Egress Bandwidth Pro-
file Per OVC End Point
at a UNI
Egress policing by the Operator
on all egress Service Frames
mapped to the OVC End Point
Egress Bandwidth Pro-
file Per Class of Ser-
vice Identifier at a UNI
Egress policing by the Operator
on all egress Service Frames
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.


Page 58

[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


Page 59

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.


Page 60

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.
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.
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,


Page 61

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


Page 62

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, ( ) CBS t B
c
=
0
and
( ) EBS t B
e
=
0
. ( ) t B
c
and ( ) t B
e
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, { }
, 1
, 0 , ,
j j j j
t t j l t
+
with arrival times at the
reference point
j
t and lengths
j
l , the level of compliance color assigned to each
ENNI Frame MUST be defined according to the algorithm in Figure 17.

Declare ENNI Frame Red
( ) ( ) ( )
( ) ( ) ( )
( ) ( ) ( ) ( )
)
`
+ + =
)
`
+ =
)
`
+ =

j j j j e j e
j j j c j
j j j c j c
t O CF t t
EIR
t B EBS t B
CBS t t
CIR
t B t O
t t
CIR
t B CBS t B
1 1
1 1
1 1
8
, min
8
, 0 max
8
, min
( ) ( )
j c j
t B l AND
( ) ( )
j e j
t B l AND
( ) ( )
j j c j c
l t B t B =
( ) ( )
j j e j e
l t B t B =
Yes
Yes
No
No
[(CM == color-blind)
OR (ENNI Frame == Green)]
[(CM == color-blind)
OR (ENNI Frame != Red)]
Declare ENNI Frame Green
Declare ENNI Frame Yellow
ENNI Frame of length l
j
arrives at time t
j
(j 1)

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


Page 63

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 { } , 0 , , j l t
j j
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.


Page 64

Ingress Bandwidth
Profile Compliance
ENNI Frame Disposition
Red Discard
Yellow
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
mapped but SLS performance objectives do not apply.
Green
Not Applied
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
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, { } 0 , , j l t
j j
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.


Page 65

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.


Page 66

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.


Page 67

1
Operator MEN
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 1
UNI 2
UNI 3
UNI 4
EVC 1-2
EVC 1-3
EVC 1-4
EVC 1-4 37
EVC 1-3 765
EVC 1-2 45
EVC CE-VLAN ID
EVC 1-2 33
EVC CE-VLAN ID
EVC 1-3 28
EVC CE-VLAN ID
EVC 1-4 33
EVC CE-VLAN ID

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


Page 68

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.

A
D C
B
UNI 1
UNI 2
UNI 3
1
2
5
6
8 9
10
11
12
13
15
16
UNI 4
11 37
2 765
1 45
O EP C-VID
3 114
O EP S-VID
4 114
O EP S-VID
5 33
O EP C-VID
12 1024
6 1023
O EP S-VID
13 1024
7 1023
O EP S-VID
14 2022
8 2023
O EP S-VID
15 2022
9 2023
O EP S-VID
10 28
O EP C-VID
16 33
O EP C-VID
4
3
7
14

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].


Page 69

UNI 1
UNI 2
UNI 3
UNI 4
EVC 1-2-3-4
EVC 1-2-3-4 All
EVC CE-VLAN ID
EVC 1-2-3-4 All
EVC CE-VLAN ID
EVC 1-2-3-4 All
EVC CE-VLAN ID
EVC 1-2-3-4 All
EVC CE-VLAN ID

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.

A
D C
B
UNI 1
UNI 2
UNI 3
1
4
5
10
16
UNI 4
1 All
O EP C-VID
3 114
O EP S-VID
4 114
O EP S-VID
5 All
O EP C-VID
6 1023
O EP S-VID
7 1023
O EP S-VID
8 2023
O EP S-VID
9 2023
O EP S-VID
10 All
O EP C-VID
16 All
O EP C-VID
3
6
7
8 9
Each OVC has CE-VLAN ID
Preservation and CE-CoS
Preservation in force.

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.


Page 70

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.


Page 71

A
B
UNI B
B3
A2 1028
A1 2023
O EP S-VID
B2 1028
B1 2023
O EP S-VID
A1 B1
A2
UNI Ab
UNI Aa
A3
A4
B2

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.
A
B
UNI B
B3
A2 1028
A1 2023
O EP S-VID
B2 1028
B1 2023
O EP S-VID
A1 B1
A2
UNI Ab
UNI Aa
A3
A4
B2

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.


Page 72

Each OVC has CE-VLAN ID
Preservation and CE-CoS
Preservation in force.
A
D C
B
UNI 1
UNI 2
UNI 3
1
4
5
10
14
16
UNI 4
1 All
O EP C-VID
3 114
O EP S-VID
4 114
O EP S-VID
5 All
O EP C-VID
12 1024
6 1023
O EP S-VID
13 1024
7 1023
O EP S-VID
14 2022
8 2023
O EP S-VID
15 2022
9 2023
O EP S-VID
10 All
O EP C-VID
16 All
O EP C-VID
3
6
12 7
13
8 9
15

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.


Page 73

A
D C
B
UNI 1
UNI 2
UNI 3
1
2
5
6
8
9
10
11
12
15
16
UNI 4
11 37
2 765
1 45
O EP C-VID
3 114
O EP S-VID
4 114
O EP S-VID
5 33
O EP C-VID
12 1024
6 1023
O EP S-VID
7 1024
7 1023
O EP S-VID
8 1024
8 1023
O EP S-VID
15 1024
9 1023
O EP S-VID
10 28
O EP C-VID
16 33
O EP C-VID
4
3
7
The OVC in Operator MEN
D has S-VLAN ID
Preservation = Yes.
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.


Page 74

CoS Label CoS Identifier (S-Tag PCP Value)
H 5
M 3
L 1
Table 21 MEF 23.1 CoS Identifiers
A B
CoS in A
H
M
L
CoS in B
H
M
L
S-Tag
PCP Value
5
5
3
3
1
1

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.


Page 75

A B
CoS in A
Square
CoS in B
Paper
S-Tag
PCP Value
4
3

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.


Page 76

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.
Leaf UNI X Leaf UNI Y
Leaf UNI Z
Rooted-Multipoint OVC
Trunk OVC End Point
Root OVC End Point
Leaf OVC End Point
Path for frames
originating at a Root UNI
Path for frames
originating at a Leaf UNI
MEN A
MEN B MEN C
UNI
ENNI

Figure 30 Rooted-Multipoint EVC using Trunk OVC End Points
MEN A MEN B
OVC End Point
Identifier
Root S-VLAN
ID value
Leaf S-VLAN
ID value
OVC End Point
Identifier
Root S-VLAN
ID value
Leaf S-VLAN
ID value
PAIX A32 1065 1066 PAIX B12 1065 1066

MEN B MEN C
OVC End Point
Identifier
Root S-VLAN
ID value
Leaf S-VLAN
ID value
OVC End Point
Identifier
Root S-VLAN
ID value
Leaf S-VLAN
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


Page 77

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.
Leaf UNI Z
Trunk OVC End Point
Root OVC End Point
Leaf OVC End Point
Path for frames
Path for frames
MEN A
MEN B
MEN C
UNI
ENNI
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
Leaf UNI X Leaf UNI Y Leaf UNI Z
R
o
o
t

U
N
I

T

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.


Page 78

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
R
o
o
t

U
N
I

T
Leaf UNI Z
Trunk OVC End Point
Root OVC End Point
Leaf OVC End Point
Path for frames
Path for frames
MEN A
MEN B MEN C
UNI
ENNI
ENNI AB ENNI BC

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


Page 79

Root UNI S Root UNI T
Leaf UNI X
Leaf UNI Z
Trunk OVC End Point
Root OVC End Point
Leaf OVC End Point
Path for frames
Path for frames
MEN A
MEN B MEN C
UNI
ENNI
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 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.


Page 80

Root UNI S
Leaf UNI X
Trunk OVC End Point
Root OVC End Point
Leaf OVC End Point
Path for frames
Path for frames
MEN A
MEN B
MEN C
UNI
ENNI
ENNI AB
ENNI BC
MEN D
Bundled OVC
ENNI BD
Root UNI T
Root UNI U
Leaf UNI Z
Leaf UNI Y

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.


Page 81

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


Page 82

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

User Network I nterface (UNI ) Type 2
I mplementation Agreement

J uly, 2008

UNI Type 2 I mplementation Agreement

MEF 20
The Metro Ethernet Forum2008. Any reproduction of this document, or any portion thereof, shall contain the
Page ii

Disclaimer
without notice and the MEF (Metro Ethernet Forum) is not responsible for any errors. The MEF
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
(b) any warranty or representation that any MEF member companies will announce any
(c) any form of relationship between any MEF member companies and the recipient or user of
this document.
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.


MEF 20
Page 1

Table of Contents
1. ABSTRACT .....................................................................................................................................................2
2. TERMI NOLOGY ............................................................................................................................................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. COMPLI ANCE LEVELS...............................................................................................................................4
5. CONVENTION................................................................................................................................................4
6. BACKWARD COMPATI BI LI TY .................................................................................................................4
7. SUPPORTI NG UNI TYPE 2 FUNCTI ONALI TI ES....................................................................................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 DI SCOVERY & CONFI GURATI ON.....................................................................................6
9. SUPPORTI NG E-LMI ....................................................................................................................................7
10. SUPPORTI NG 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. SUPPORTI NG PROTECTI ON...................................................................................................................15
12. SUPPORTI NG ENHANCED UNI ATTRI BUTES....................................................................................16
13. L2CP AND SERVI CE OAM HANDLI NG.................................................................................................17
14. APPENDIX A (TEST-MEG DEFI NI TI ON)...............................................................................................19
15. APPENDIX B (UP-MEP AND DOWN-MEP DEFINITI ON) ...................................................................20
REFERENCES..........................................................................................................................................................21


MEF 20
Page 2

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
AI S Alarm Indication Signal
BW Bandwidth
CCM Connectivity Check Message
CE Customer Equipment
CFM Connectivity Fault Management
CoS ID Class of Service Identifier
DA Destination Address
Down-MEP
A MEP in an 802.1 Bridge that sends frames away from the Bridge Relay Entity; see
[IEEE 802.1ag]
E-LAN MEF Multipoint to Multipoint service; see [MEF 10.1]
E-LI NE MEF Point-to-Point service; see [MEF 10.1]
E-LMI Ethernet Local Management Interface [MEF16]
EVC
Ethernet Virtual Connection: an association between two or more UNIs for the purpose
of delivering Ethernet services.
EVC I D The Identifier for an EVC
I A 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
MI P Maintenance Entity Intermediate Point


MEF 20
Page 3

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
UNI
User Network Interface. The UNI is a demarcation point between the responsibility
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
Up-MEP
A MEP in an IEEE 802.1 Bridge that sends frames toward the Bridge Relay Entity; see
[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
Page 4

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.

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
Page 5

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 SUPPORTI NG 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 SUPPORTI NG 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 SUPPORTI NG SUBSETS OF UNI TYPE 2 FUNCTI ONALI TI ES

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

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

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.
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.
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
Page 8

10. Supporting Ethernet OAM
10.1 LI NK 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].

Type 2.2 MAY support Active DTE mode capabilities as specified in clause 57.2.9 of [IEEE
802.3].

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].

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].

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].

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
Page 9

10.2 SERVI CE 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
Page 10

1

2

3

4

5

6

7

8
Subscriber
Equipment
Subscriber
Equipment Operator A NEs Operator B NEs Service Provider
UNI ME E-NNI ME
Subscriber MEG
EVC ME
Operator A
UNI MEG
Test MEG
Operator B MEG
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
Page 11
[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.

Per EVC Subscriber ME
Per EVC Test ME
UNI ME
Default UNI-C MEPs Def aul t UNI-N MEPs
D
Up or Down MEPs
own MEPs
Down MEPs
Per EVC Subscriber ME
Per EVC Test ME
UNI ME
NI-C MEPs UNI-N MEPs
D
Do
s
Default U Def aul t
own MEPs
wn MEPs
Up or Down MEP
Subscriber-MEPs
Test-MEPs
UNI-MEP

Figure2. UNI Type 2 MEP I nstances

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
Page 12

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

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

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
Page 15

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
Page 16

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

[R71] A UNI-N Type 2 MUST be able to support Per-EVC egress BW profiling of CIR as

[R72] A UNI-N Type 2 MUST be able to support Per-CoS ID egress BW profiling of CIR as

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

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

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
Page 19

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
Page 20
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.

1 2
UNI-C
UNI ME
UNI-N
Subscriber ME
Test ME Up MEP
Down MEP

Figure 3 - UNI Type 2 MEP Directions


MEF 20
Page 21

References

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 8

MEF 8

Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks

October 2004

Impl ementation Agreement for the Emul ation of
PDH Ci rcui ts over Metro Ethernet Networks

MEF 8
Page i

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.


MEF 8
Page ii

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
Page iii

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
Page 1

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
CCS Common Channel Signaling
CE Customer Equipment
CES Circuit Emulation Services
CESoETH Circuit Emulation Services over Ethernet
CF Coupling Flag
CIR Committed Information Rate
CRC Cyclic Redundancy Check (e.g. the 4-bit CRC-4 used to check data integrity of E1 circuits)
E-Line Ethernet Line Service
ECDX Emulated Circuit De/Multiplexing Function
ECID Emulated Circuit Identifier
EIR Excess Information Rate
EFTF Ethernet Flow Termination Function
ES Errored Second
ESR Errored Second Ratio
ESF Extended Super Frame
FCS Frame Check Sequence
FDL Facility Data Link
FER Frame Error Ratio


MEF 8
Page 2

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
IWF
The IWF receiving TDM data from the customers TDM-based equipment, and forwarding this
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-
agnostic
Structure-agnostic emulation is the transport of unstructured TDM, or of structured TDM when
the structure is completely disregarded by the transport mechanism.
Structure-
aware
Structure-aware emulation is the transport of structured TDM taking at least some level of the
structure into account.
Structure-
locked
Encapsulation utilized for Structure-Aware TDM transport where TDM structure boundaries are
indicated by packet payload boundaries
Structure-
indicated
Encapsulation utilized for Structure-Aware TDM transport where TDM structure boundaries are
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
Page 3

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
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
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
Page 4

Destination Address
Source Address
Ethertype
VLAN tags (optional)
Emulated Circuit Identifier (ECID)
CESoETH Control Word
RTP (optional)
Ethernet Services Layer
Adaptation Function
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 I WF handles the packetization of the TDM data, encapsulation into Ethernet frames and
forwarding into the Ethernet network. The corresponding TDM-bound I WF 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 I nterfaces
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 I nterface: 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 I nterface (CES TDM I nterface): 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
Page 5

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.
Customer
TDM
Service
CES TDM
I nterface
TDM Service
I nterface
TSP
(optional)
(e.g. framing,
mux/demux)
CES Payload
IWF
IWF
CES IWF
CES IWF Type
EFTF
Ethernet
I nterface
Adapted
Payload
DS1 (T1), E1,
DS3 (T3), E3,
Nx64
CES Control Word
RTP (optional)
TDM Payload
Ethertype
ECID
CES Control Word
RTP (optional)
TDM Payload
Destination Addr.
Source Address
Ethertype
ECID
CES Control Word
RTP (optional)
TDM Payload
FCS
ECDX

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
Page 6

6.1.5 Circuit Emulation I nter-working Function (CES I WF)
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
Page 7

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.
Emulated Circuit Identifier (ECID) (20 bits) Reserved (set to 0x102)
0 19 20 31


MEF 8
Page 8

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.
LEN (Length)
(6 bits)
SN (Sequence Number) (16 bits)
0 1 2 3 4 5 6 7 8 9 10 15 16 31
L R
M
(2 bits)
FRG
(2 bits)
Reserved
set to zero

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
Page 9

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
Page 10

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
Page 11

CC (4 bits) P X M V=2 PT (7 bits) SN (Sequence Number) (16 bits)
0 1 2 3 4 7 8 9 15 16 31
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
Page 12

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
Page 13

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
Page 14

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
Page 15

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-I ndicated 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
Page 16

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.
To MEN
Data
To TDM
(or TSP)
Clock
Data
Clock
MEN-bound
IWF
CESoETH IWF
Ext.
Free
Run
Data
TDM
Line
External Timing
Reference
TDM-bound
IWF
Eth.
Line Clock
Recovery
Clock

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
Page 17

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
Page 18

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)
Volume (6 bits) Duration (16 bits)
0 7 8 9 10 15 16 31
E Event code (8 bits) R
not required set to zero ABCD signaling value
(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
Page 19

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
Page 20

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 J itter 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
Page 21

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
Page 22

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
Page 23

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
Page 24

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
Page 25

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]:
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
Page 26

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
UNI
No
Ingress Bandwidth Profile Per EVC
CIR, CBS sufficient to handle the constant bit rate TDM flow
EIR, EBS, set to zero
Coupling flag (CF) set to zero
Ingress Bandwidth Profile Per CoS
Identifier
No (although bandwidth profile could equally well be supported on per
CoS basis rather than per EVC, e.g. where a subscriber runs both
CES and data traffic over the same EVC)
Layer 2 Control Protocol Processing
Discard IEEE 802.3x MAC Control (Pause) Frames with a destination
MAC address 0x0180C2000001
(real-time, constant bit rate services cannot be paused)
Peer, Discard or Pass to EVC all remaining protocols
UNI List List the two UNIs associated with the EVC.
CE-VLAN ID Preservation Yes or No
CE-VLAN CoS Preservation Yes or No
Layer 2 Control Protocols Processing Discard or Tunnel all remaining protocols
Classes of Service
Frame Delay as required for application, and to meet TDM standards
Frame Delay Variation as required for application, and to meet TDM
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
Page 27

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
Page 28

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
Page 29

10. References
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
Page 30

GR-253-CORE Synchronous Optical Network (SONET) Transport Systems: Common Generic Criteria
Telcordia Generic Requirements GR-253-CORE, Issue 3, September 2000
TR-NWT-
000170
Digital Cross-Connect System (DSC 1/0) Generic Criteria, Telcordia Technical Reference TR-
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,
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,
MEF 6 Ethernet Services Definitions Phase 1, MEF 6, June 2004,
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 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall

MEF 28

External Network Network Interface (ENNI)
Support for UNI Tunnel Access and Virtual UNI

October 2010


Disclaimer
or otherwise:
c) any form of relationship between any MEF member companies and the recipient or user
of this document.
accelerating industry cooperation on Metro Ethernet technology. The MEF does not, expressly or

(C) 2010. The Metro Ethernet Forum. All Rights Reserved.

External Network Network Interface Support for UTA and VUNI

Page i

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


Page ii

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


Page 1

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.

Remote UNI Remote UNI is a UNI serving as the UTA component
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

This document
UTA The UNI Tunnel Access (UTA) associates a VUNI and
remote UNI and is composed of VUNI and remote UNI
Components and at least one supporting OVC
2
.
This document
UTA Component A specific set of capabilities which may be used as part of
UTA.
This document
UTA OVC An OVC in the Network Operators MEN that provides an
association of a remote UNI with an ENNI in support of
UTA.
This document

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.


Page 2

VUNI Virtual UNI (VUNI) is the component consisting of a
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.
This document
VUNI End Point An End Point at the VUNI Providers side of a specific
ENNI that associates the ENNI with a VUNI in support of
UTA.
This document
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 Model
3

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.


Page 3

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 UNI
4

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].


Page 4

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 ENNI
5

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].


Page 5

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]
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.


Page 6

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
OVC End Points
MUST be 1
Maximum Number ENNI
OVC End Points
MUST be 1


Page 7

OVC Service Attribute Name Additional Constraints for UTA OVC
OVC Maximum Transmission
Unit Size
No additional constraints
S-VLAN ID Preservation No additional constraints
6

S-VLAN CoS Preservation No additional constraints
7

Color Forwarding MUST be No
8

SLS No additional constraints
Delivery
Delivery
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


Page 8

OVC End Point per UNI Service
Attribute
Additional Constraints for the UTA OVC End Point at the Remote
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 Identifier
9

OVC End Point at a UNI
(remote UNI)
If an Ingress Bandwidth Profile per OVC End Point at a remote
UNI is supported, it MUST be configured as color blind and
MUST specify either CIR as ZERO or EIR as ZERO
10
. For
more information on this Bandwidth Profile, please see [MEF
10.2]
Class of Service Identifier at a
UNI (remote UNI)
MUST NOT specify
(remote UNI)
MUST NOT specify
UNI (remote UNI)
MUST NOT specify
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.


Page 9

Service Attribute
Additional Constraints for the UTA OVC End Point at the ENNI
OVC End Point Identifier No additional constraints
Class of Service Identifiers MUST provide only a single Class of Service Identifier
OVC End Point
MUST be configured as color aware and MUST specify either
CIR as ZERO or EIR as ZERO
ENNI Class of Service
Identifier
MUST NOT specify
End Point
Identifier
MUST NOT specify
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.


Page 10

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
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
OVCs
Maximum Number of OVC
End Points per OVC
Table 5: ENNI Service Attribute Constraints for the UTA Network Operator


Page 11

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.


Page 12

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.


Page 13

VUNI Service Attribute Service Attribute Parameters and Constraints for UTA
VUNI Identifier
Arbitrary text string of no more than 45 bytes to identify the
VUNI. The VUNI Identifier MUST be unique among all VUNI
Identifiers within the scope of all ENNIs supported by the VUNI
Provider MEN.
ENNI CE-VLAN ID value for
ENNI Frames with no C-Tag
or a C-Tag whose VLAN ID
value is 0
MUST specify CE-VLAN ID value in the range of 1-4094.
Maximum number of related
OVC End Points in the VUNI
Provider MEN
MUST be an integer 1.
VUNI
(See Section 7.4.1)
VUNI
(See Section 7.4.2)
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 MEN
13
. 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.


Page 14

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
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 VUNI
14

Maximum Number of
OVCs
Maximum Number of
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.


Page 15

[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
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)
OVC End Point associated by
a VUNI
(See Section 7.4.3)
Class of Service Identifier
associated by a VUNI
(See Section 7.4.4)
OVC End Point associated by
a VUNI
(See Section 7.4.5)
Class of Service Identifier
associated by a VUNI
(See Section 7.4.6)
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.


Page 16

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


Page 17

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


Page 18

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,
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,
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.


Page 19

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


Page 20

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


Page 21

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.


Page 22

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.)

UNI W
UNI X
ENNI
CB
UNI Y
VUNI
Provider
Network
Operator B
UTA
Service
Components
OVC CB
End Point
OVC CB
End Point
VUNI
End Point
C
E
Remote
UNI
CE
CE
VUNI / RUNI
Association
Virtual
UNI
ENNI
BA
Network
Operator A
(Network Operator C)
OVC BA
End Point
OVC BA
End Point
Tunnel Extension OVC UTA OVC

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.


Page 23

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.


Page 24

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.

SVLAN or Label 1
SVLAN or Label 2
SVLAN or Label 4095
SVLAN or Label Z
T
o

P
h
y
s
i
c
a
l

p
o
r
t
s

o
r

s
w
i
t
c
h
i
n
g

f
a
b
r
i
c
C-Component
S-Component
ENNI
SVLAN-1
Untagged and C-TAG only frames
Untagged
(Process/peer/disc)
S-Bridge or
MPLS or other
VUNI
B
OVC
End Points
EVCs
Datapaths
C-Bridge #1
C-Bridge #2
C-Bridge #4094
Blocked Port
UNI Tunnel Access
S-VLAN 15
SVLAN-2
S-4094
One physical link
or bundle
SVLAN or Label 100
SVLAN or Label 99
Operator Edge Device
VUNI
End Points
SVLAN or Label 1
SVLAN or Label 2
SVLAN or Label 99
C-Bridge #5
VUNI
A

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):


Page 25

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.


Page 26

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.
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
Circuit Emulation
SyncE
When connecting network elements in order to create a network, it is
common practice to consider and provision for various failures. Ideally, the
traffic should continue to flow even if a failure of a link or a port occurred.
There are three types of failures to consider:
1. Port Failure
2. Link Failure
3. Network Element (NE) Failure

Port protection
We focus our discussion on external Interfaces (UNI or ENNI). MEF 20 defined
as mandatory feature ofUNI type 2.2 the capability to protect against a UNI-N
port failure and / or protecting against a failure of a physical link crossing the
UNI point.
UNI protection is depicted in the following figure:
Figure: UNI Protection
In this Section
 
9.1.2 MEF 8 model
 
9.2 CES Components
Function (GIWF)
 
9.3.1 E-Line
 
9.4 Synchronization
9.4.1 Packet Based
9.4.1.2 NTP

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
ENNI protectionis depicted in the following figure:
Figure: ENNI Protection
It should be noted that some vendors do allow LAG between different line-
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.
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.
Figure: Active StandbyEVC

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
Technologies
9 CES over Ethernet
Send Feedback
Name:
Email:
Comments
Send Feedback
Home About Contact
Measurements in E-Line, E-LAN, E-Tree
This topic discusses the implementation of the various Performance
Management attribute computation methods for a given Ethernet Service type.
For E-Line services, the one-way performance attributes (Frame Delay, Frame
Loss Ratio, etc.) are measured and computed separately in each direction
(UNI A to UNI B and UNI B to UNI A). A SP may set performance objectives
and measure performance for both directions or only one direction.
For E-LAN and E-Tree the computation is more complex. Such a service has N
UNIs associated with it. Since measurement is made between pairs of UNIs,
scalability and complexity issues may require monitoring only a sub-set of the
UNI pairs. Note that for E-LAN with 6 UNIs, there are 6X5 = 30 UNI pairs. The
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
list or any sub-set of that list.
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
two leaf UNIs cannot communicate with each other. For each UNI pair within
the sub-set S, the procedures are carried out and summarized every time
interval T (T can be different per attribute)
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
In this Section
Maintenance
 
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
Level
10.2.2 MEF 17
10.2.2.1 Model
 
10.3.1 Definition
10.3.2 Procedures
Message
 

Test Objectives
the examinee with a
exam
MEF Glossary
MEF Diagrams
in MEF materials
References
information
Study Guide
to-navigate page
for each ordered pair of UNIs within S, as:
The only attribute that should be computed differently is One-Way Mean
Frame Delay. For Mean Frame Delay, the value is calculated as the Arithmetic
Mean over all Mean Frame Delays of the ordered UNI pairs.

10.4.1 Definition
10.4.2 Procedures
Message
Message
Variation
LAN, E-Tree
 
Agreement - MEF 23
 
Implementation
Profile
Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 10.2
MEF 17
Interconnect
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback

MEF 17

MEF 17

Service OAM Requirements & Framework
Phase 1

April 2007

MEF 17

Disclaimer
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.
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.
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

MEF 17
Page 1

Table of Contents
1. Abstract ................................................................................................................................ 3
2. Terminology......................................................................................................................... 3
3. Scope..................................................................................................................................... 4
5. I ntroduction ......................................................................................................................... 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
Page 2

Figure 5: Point-to-point MEs at ETH Layer ................................................................................... 8
Figure 6: Relationship across different OAM Components ......................................................... 17

MEF 17
Page 3

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
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
Page 4

Term Definition
SI-NNI Service Interworking NNI
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.
document are to be interpreted as described in RFC 2119. All key words must be in upper case,
bold text.
MEF 17
Page 5

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.

Service
Interworking
NNI
Network
Interworking
NNI
Network
Interworking
NNI
Subscriber
UNI
Other L1
Transport Networks
(e.g., SONET, SDH, OTN)
MEN
Service Provider Z1
Other L2/L2+
Services Networks
(e.g., ATM, FR, IP)
External
NNI
Ethernet
Wide Area Network
(E-WAN)
Service Provider Y
MEN
Service Provider Z2
MEN
Service Provider X
Metro
Ethernet Network
(MEN)
Service Provider X
External
NNI
Subscriber
Subscriber
UNI
UNI

Figure 1: MEN External I nterfaces & 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
Page 6

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].

EMS

NE NE

NE
EMS

NE NE

NE
NMS
Environment
EMS-NMS Interface
EMS-NE Interface
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
Page 7

MEN
Service
Provider
Y
MEN
Service
Provider
X
Subscriber
Site A
UNI
E
T
H

U
N
I
-
C

Subscriber
Site B
Subscriber
Site C
E
T
H

U
N
I
-
N

E
T
H

U
N
I
-
C

E
T
H

U
N
I
-
N

E
T
H

E
-
N
N
I

E
T
H

E
-
N
N
I

E
T
H

U
N
I
-
C

E
T
H

U
N
I
-
N

UNI
UNI
E-NNI
Ethernet Services Layer

Figure 4: ETH Layer I nterfaces 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
Page 8

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

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.

Figure 5: Point-to-point MEs at ETH Layer

1

2

3

4

5

6

7

8
Subscriber
Equipment
Subscriber
Equipment Operator A NEs Operator B NEs Service Provider
TrCP TrCP
Subscriber ME
EVC ME
Operator B ME
NNI ME
Operator A ME
UNI ME UNI ME
TRAN
ETH
MEF 17
Page 9

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
Page 10

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
Page 11

(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
Page 12

(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
Page 13

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

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
Page 14

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
Page 15

(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
Page 16

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

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.

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.

Ethernet
link OAM
VPWS/VPLS
OAM
SO-
NET/SDH

Other
OAM
Bridged network OAM
Service OAM
Transport
Links
Network
Services
ETH
Layer
TRAN
Layer
MEF 17
Page 18

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 18
Page 1

MEF 18

Abstract Test Suite for Circuit Emulation
Services over Ethernet based on MEF 8

May 2007

Abstract Test Sui te for Ci rcui t Emul ation Servi ces
over Ethernet based on MEF 8

MEF 18
Page 2

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.


MEF 18
Page 3

Table of Contents
1. ABSTRACT ......................................................................................................................................................... 5
2. TERMI NOLOGY ................................................................................................................................................ 5
3. SCOPE .................................................................................................................................................................. 5
4. COMPLI ANCE LEVELS ................................................................................................................................... 5
5. TESTI NG 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 REQUI REMENTS ............................................................................................ 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 REQUI REMENTS ............................................................................................ 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. TESTI NG SUMMARY ..................................................................................................................................... 32
9. REFERENCES .................................................................................................................................................. 35


MEF 18
Page 4

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
Page 5

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.
The key words MUST, MUST NOT, REQUI RED, SHALL, SHALL NOT, SHOULD, SHOULD
NOT, RECOMMENDED, MAY, and OPTI ONAL 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
Page 6

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.

MEF8
Structure-agnostic
Structure-aware
Emulation
Type
Application
Signaling
Embedded CAS
Basic service
Basic service with
separate signaling
(section 6.5)
Embedded CAS
Basic service
Basic service with
separate signaling
(section 6.5)
Octet-aligned
(section 6.3.1.1)

Raw encapsulation
(section 6.3.1)
Structure-locked
(section 6.3.2)
Structure-indicated
(section 6.3.3)

Encapsulation
Type
Sole mandatory mode
in MEF8
Mandatory for
structure-locked
encapsulation mode
Mandatory for
structure-indicated
encapsulation mode

Section numbers relate to MEF8

Figure 5-1: MEF8 Operating Modes


MEF 18
Page 7

5.2 GENERI C 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
Page 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.

TDM
Tester
Emulated
Network
Mgmt.
Station
CESoETH
DUT
TDM
Tester
TDM Eth Eth TDM
CESoETH
DUT
Mgmt.
Interface
Mgmt.
Interface
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
Page 9

6. Tests for Mandatory Requirements
6.1 ENCAPSULATI ON 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 I dentifier and Frame Sequencing
ABSTRACT TEST CASES FOR CESoETH I MPLEMENTATI ON AGREEMENT
Test Name Test Case 1: Emulated Circuit Identifier and Sequencing
Test Definition
ID
MEF8.R1,R17-R18
Reference
document
MEF 8
Test Type Conformance
Test Status Mandatory
Requirement
Description
R1. Each TDM-bound IWF at a given MAC address MUST have a unique ECID value.
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
Configuration
Generic Test Bed 1, with at least one CESoETH IWF connected at the MEF UNI.
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
Page 10

6.1.2 CESoETH control word
Test Name Test Case 2: R bit of the CESoETH Control Word and its Usage
Test Definition
ID
MEF8.R4-R7
Reference
document
MEF 8
Requirement
Description
R4. A TDM-bound IWF SHALL enter a Loss of Frames State (LOFS) following detection of
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
Configuration
Generic Test Bed 2 as shown in Figure 5-3. Network emulator required.
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.
Remarks


MEF 18
Page 11

Test Name Test Case 3: L bit and M bits of the CESoETH Control Word and their Usage
Test Definition
ID
MEF8.R8,R10,R14
Reference
document
MEF 8
Requirement
Description
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.
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
Configuration
Generic Test Bed 1 as shown in Figure 5-2.
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.
Remarks


MEF 18
Page 12

Test Name Test Case 4: L bit and M bits of the CESoETH Control Word and their Usage
Test Definition
ID
MEF8.R16
Reference
document
MEF 8
Requirement
Description
R16. A TDM-bound IWF MUST silently discard a CESoETH frame where the M field is set
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
Configuration
Generic Test Bed 1 as shown in Figure 5-2.
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.
Remarks


MEF 18
Page 13

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
Test Name Test Case 5: Structure Agnostic Emulation
Test Definition
ID
MEF8.R30-R31
Reference
document
MEF 8
Requirement
Description
R30. A CES IWF MUST support structure-agnostic emulation, as defined in section 6.3.1 of
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
Configuration
Generic Test Bed 2 as shown in Figure 5-3. Ethernet sniffer required to monitor CESoETH
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
Page 14

Test Procedure TDM testers generate framed or unframed TDM circuit for emulation by the CESoETH IWFs.
Circuits to contain a standard 2
20
-1 PRBS pattern
1
O.150 (as defined in ) 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)
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). 2
20
-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
Page 15

6.3 SYNCHRONI SATION
This section describes the testing of the synchronisation requirements, as described in MEF 8, Section 6.4. It covers
requirements R47 and R48.
Test Name Test Case 6: Synchronization Test
Test Definition
ID
MEF8.R47-R48
Reference
document
MEF 8
Requirement
Description
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.
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
Configuration
Uses the test bed described in [G.8261], Appendix VI.2.2 (Figure VI.4), with the CESoETH
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
Page 16

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
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
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
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 2
20
O.150 -1 PRBS pattern (as defined in ) 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.
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
Page 17

6.4 DEFECTS, PERFORMANCE MONI TORI NG 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
Test Name Test Case 7: Effect of Stray Frames.
Test Definition
ID
MEF8.R57,R60
Reference
document
MEF 8
Requirement
Description
R57. The CES IWF MUST only accept frames that contain the correct Ethernet destination
address field and ECID value for that IWF.
R60. When a stray frame
1
Test Object
is detected by a Circuit Emulation Inter-working Function (CES
IWF), it MUST be discarded.
Verify that only genuine CESoETH frames are accepted by the CES IWF, and that all stray
frames are discarded.
Test-Bed
Configuration
Generic Test Bed 2 as shown in Figure 5-3. Network emulator must have the ability to inject stray
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 2
20
O.150 -1 PRBS sequence (as defined in ).
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,
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
Page 18

Test Name Test Case 8: Verification of lost frame detection in the presence of stray frames
Test Definition
ID
MEF8.R63
Reference
document
MEF 8
Requirement
Description
R63. The mechanisms for detection of lost frames (e.g. expected next sequence number) MUST
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
Configuration
Generic Test Bed 2 as shown in Figure 5-3. Network emulator must have the ability to corrupt the
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 2
20
O.150 -1 PRBS sequence (as defined in ).
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,
Variables
Remarks


MEF 18
Page 19

Test Name Test Case 9: Verification of discarding of out-of-sequence CESoETH frames
Test Definition
ID
MEF8.R66
Reference
document
MEF 8
Requirement
Description
R66. Out-of-sequence CESoETH frames that cannot be re-ordered MUST be discarded, and
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
Configuration
Generic Test Bed 2 as shown in Figure 5-3. Network emulator must have the ability to delay and
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 2
20
O.150
-1 PRBS sequence
(as defined in ).
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.
Remarks


MEF 18
Page 20

Test Name Test Case 10: Compensation for Lost CESoETH Frames
Test Definition
ID
MEF8.R67
Reference
document
MEF 8
Requirement
Description
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.
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
Configuration
Generic Test Bed 2 as shown in Figure 5-3. Network emulator is required, with the ability to drop
Ethernet frames.
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.
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
Remarks


MEF 18
Page 21

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 J itter Buffer Overrun and Underrun Defects
Test Name Test Case 11: Detection of Jitter Buffer Overruns
Test Definition
ID
MEF8.R78-R79
Reference
document
MEF 8
Requirement
Description
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.
Test Object Verify that a CESoETH IWF detects jitter buffer overruns, and discards the CESoETH frames
accordingly.
Test-Bed
Configuration
Generic Test Bed 1, as shown in Figure 5-2, with the TDM generator replaced by a loopback
(TDM out connected to TDM in).
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
Page 22

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
N 1
received packets. The DUT may play up to
N
1
of valid CES frames.
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
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
Page 23

Test Name Test Case 12: Verification of CESoETH implementation rule
Test Definition
ID
MEF8.R83
Reference
document
MEF 8
Requirement
Description
R83. CESoETH implementations supporting DS1 circuit using ESF framing MUST NOT
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
Configuration
Generic Test Bed 2 as shown in Figure 5-3. No network emulator is required, merely a cable
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
Remarks


MEF 18
Page 24

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
Page 25

7.1 TESTS FOR OCTET ALI GNED PAYLOAD OF DS1 CI RCUI TS
Test Name Test Case 13: Octet Aligned Payload for Structure Agnostic Emulation of DS1 Circuits
Test Definition
ID
MEF8.R32-R33
Reference
document
MEF 8
Test Status Dependent (Mandatory for Octet-Aligned Payload support)
Requirement
Description
R32. The TDM-bound IWF MUST NOT assume any alignment with the underlying DS1
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
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 2
20
-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.
Remarks


MEF 18
Page 26

7.2 TESTS FOR STRUCTURE-LOCKED ENCAPSULATI ON
Test Name Test Case 14: Structure Aware Emulation using Structure-Locked Encapsulation
Test Definition
ID
MEF8.R34-R36,R39
Reference
document
MEF 8
Test Status Dependent (Mandatory for Structure-Locked Encapsulation support)
Requirement
Description
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).
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
Configuration
frames.
CESoETH IWFs configured for Structure-Locked Encapsulation of either DS1 or E1.


MEF 18
Page 27

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)
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 2
20
-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.
Remarks


MEF 18
Page 28

7.3 TESTS FOR STRUCTURE-I NDI CATED ENCAPSULATI ON
Test Name Test Case 15: Structure Aware Emulation using Structure-Indicated Encapsulation
Test Definition
ID
MEF8.R45
Reference
document
MEF 8
Test Status Dependent (Mandatory for Structure-Indicated Encapsulation support)
Requirement
Description
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.
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
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 2
20
-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.
Remarks


MEF 18
Page 29

7.4 TDM APPLI CATI ON SI GNALI NG
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
Test Name Test Case 16: Signaling Frame Format Requirements
Test Definition
ID
MEF 8.R49-R51
Reference
document
MEF 8
Test Status Dependent (Mandatory for TDM Application Signaling support)
Requirement
Description
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.
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
Configuration
Generic Test Bed 1 as shown in Figure 5-2. TDM Tester must be capable of generating CAS
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
Remarks


MEF 18
Page 30

7.4.2 Channel associated Signaling (CAS) Frames
Test Name Test Case 17: CAS Signaling Frame Format Requirements
Test Definition
ID
MEF 8.R53-R55
Reference
document
MEF 8
Test Status Dependent (Mandatory for TDM Application Signaling support)
Requirement
Description
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 below):

Volume (6 bits) Duration (16 bits)
0 7 8 9 10 15 16 31
E Event code (8 bits) R
not required set to zero ABCD signaling value
(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
Configuration
Generic Test bed 1 as shown in Figure 5-2. TDM Tester must be capable of generating CAS
signaling events.


MEF 18
Page 31

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)
Remarks


MEF 18
Page 32

8. Testing Summary
Requirement Description
Level
(mandatory/
dependent/
optional)
Test
Case
No.
Test reference Comments
MEF8.R1 ECID attribute Mandatory 1 MEF8.R1,R17-R18
MEF8.R2
ECID reserved field
transmit
Optional None
MEF8.R3
ECID reserved field
reception
Optional None
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
MEF8.R7
R bit change of state
detection
Mandatory 2 MEF8.R4-R7
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
MEF8.R11
L bit payload
suppression
Optional None
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
MEF8.R15 M field support Optional None
Depends on DUT
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


MEF 18
Page 33

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


MEF 18
Page 34

Level
(mandatory/
dependent/
optional)
Test
Case
No.
MEF8.R49 Generic TDM Signaling Dependent 16 MEF8.R49-R51
Generic TDM
Signaling is an
optional means of
carrying signaling
(e.g. CAS) for
structure-aware
operation.
MEF8.R52 Generic TDM Signaling Optional None
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
MEF8.R76
Malformed Frames
Alarm
Optional None
MEF8.R77
Malformed Frames
Alarm
Optional None
MEF8.R78 Jitter Buffer Overrun Mandatory 11 MEF8.R78-R79


MEF 18
Page 35

Level
(mandatory/
dependent/
optional)
Test
Case
No.
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
MEF8.R85 Bandwidth provisioning Optional None
Requirement on
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
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,
MEF 8 Implementation Agreement for the Emulation of PDH Circuits over Metro Ethernet
Networks, MEF 8, October 2004,
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

Ethernet Access Services Definitions

MEF 33


MEF 33

Ethernet Access Services Definition

J anuary 2012


MEF 33

Disclaimer
or otherwise:
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
accelerating industry cooperation on Metro Ethernet technology. The MEF does not, expressly
or otherwise, endorse or promote any specific products or services.


MEF 33
The Metro Ethernet Forum2012. Any reproduction of this document, or any portion thereof, shall
Page i

Table of Contents
1. ABSTRACT ...............................................................................................................................................................1
2. TERMI NOLOGY ......................................................................................................................................................1
3. SCOPE ........................................................................................................................................................................6
4. COMPLI ANCE LEVELS .........................................................................................................................................6
5. ETHERNET SERVI CE DEFI NI TI ON FRAMEWORK (NORMATI VE) ..........................................................7
5.1 ETHERNET ACCESS (E-ACCESS) SERVICE TYPE ...................................................................................................8
6. SERVI CE DEFI NI TI ONS (NORMATI VE) ...........................................................................................................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 MaximumCE-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. APPENDI X A: EFFECT OF I NTER-FRAME OVERHEAD ON CI R (I NFORMATI VE) ............................ 24
9. APPENDI X B: USE CASES (I NFORMATI VE) .................................................................................................. 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
Page ii

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
Page 1

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 Ethernet
Private Line
Access
EPL
Access EPL service uses a Point-to-Point OVC to associate one
OVC End Point at a UNI and one OVC End Point at an ENNI.
One UNI can support only a single instance of the Access EPL
service.
This
document
Access Ethernet
Virtual Private Line
Access
EVPL
Access EVPL service uses a Point-to-Point OVC to associate one
OVC End Point at a UNI and one OVC End Point at an ENNI.
One UNI can support one or more Access EVPL instances.
This
document
Access Provider AP An Operator MEN that offers the Ethernet Access Service type.
This
document
Bandwidth Profile
A Bandwidth Profile is a characterization of the lengths and
arrival times for Service Frames at a reference point.
MEF 10.2
[2]
Bandwidth profile per
CoS I D
A bandwidth profile applied on a per-Class of Service basis.
[2]
OVC Endpoint
A bandwidth profile applied on a per-OVC Endpoint basis.
MEF 26
[8]
UNI
A bandwidth profile applied on a per-UNI basis.
[2]
Broadcast Service
Frame

A Service Frame that has the broadcast destination MAC
address.
[2]
CE-VLAN CoS I D Customer Edge VLAN CoS. Also C-tag PCP. [2]
CE-VLAN CoS I D
Value Preservation
(OVC)

CE-VLAN CoS ID Value Preservation describes a relationship
between the format and certain field values of the frame at one
External Interface and of the corresponding frame at another
External Interface
[8]
CE-VLAN I D Customer Edge VLAN ID [2]


MEF 33
Page 2

CE-VLAN I D
Preservation (OVC)

CE-VLAN ID Preservation describes a relationship between the
format and certain field values of the frame at one External
Interface and of the corresponding frame at another External
Interface
[8]
OVC End Point Map
at the UNI
An association of CE-VLAN IDs with OVCs at a UNI.
[8]
CE-VLAN Tag Customer Edge VLAN Tag [2]
Class of Service
Frame Set
CoS
A set of Service Frames that have a commitment from the
Service Provider subject to a particular set of performance
objectives.
MEF 23.1
[16]
Class of Service
I dentifier for Service
Frames (UNI )

The mechanism and/or values of the mechanism to be used to
identify the CoS Name that applies to the frame at a given UNI.

[8]
Class of Service
I dentifier for ENNI
Frames (ENNI )

The mechanism and/or values of the parameters in the
mechanism to be used to identify the CoS Name that applies to
the frame at a given ENNI that maps to an OVC End Point.
[16]
Class of Service
Frame Set

A set of Service or ENNI Frames that have a commitment from
the Operator or Service Provider subject to a particular set of
performance objectives.
[16]
Class of Service Label
A CoS Name that is standardized in MEF 23.1. Each CoS Label
identifies four Performance Tiers where each Performance Tier
contains a set of performance objectives and associated
parameters.
[16]
Class of Service Name
A designation given to one or more sets of performance
objectives and associated parameters by the Service Provider or
Operator.
[16]
Color Mode CM
CM is a Bandwidth Profile parameter. The Color Mode
property is employed by the Bandwidth Profile. It takes a value
of color-blind or color-aware only.
[2]
Color-aware

A Bandwidth Profile property where a pre-determined level of
Bandwidth Profile compliance for each Service or ENNI Frame
is taken into account when determining the level of compliance
[2], [8]
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.
[2], [8]
Color I dentifier for
Service Frame (UNI )

mechanism used to identify the Color that applies to the frame at
a given UNI. A particular Color ID value may indicate Color
instance of Green or Yellow for a Service Frame. PCP and
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.

[16]


MEF 33
Page 3

Color I dentifier for
ENNI Frames (ENNI )

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 ID value may indicate Color instance of Green or Yellow
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.
[16]
Committed Burst Size CBS
CBS is a Bandwidth Profile parameter. It limits the maximum
number of bytes available for a burst of Frames sent at the EI
speed to remain CIR-conformant.
[2]
Committed
I nformation Rate
CIR
CIR is a Bandwidth Profile parameter. It defines the average rate
in bits/s of Frames at an EI up to which the network delivers
Frames, and is committed to meeting the performance objectives
defined by the CoS Service Attribute.
[2]
Coupling Flag CF
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.
[2]
Customer Edge CE Equipment on the Subscriber side of the UNI. [2]
Customer Edge
VLAN CoS

The Priority Code Point bits in the IEEE 802.1Q Customer
VLAN Tag in a Service Frame that is either tagged or priority
tagged.
[2]
Customer Edge
VLAN I D

The identifier derivable from the content of a Service Frame that
allows the Service Frame to be associated with an EVC at the
UNI.
[2]
E-Access Service Type
Ethernet services that use an OVC with at least one UNI OVC
End Point and one ENNI OVC End Point.
This
document
Egress Bandwidth
Profile

A service attribute that specifies the length and arrival time
characteristics of egress Frames at the egress EI.
[2]
Egress Service Frame A Service Frame sent from within a MEN to an EI. [2]
E-LAN Service
An Ethernet service type that is based on a Multipoint-to-
Multipoint EVC.
MEF 6.1
[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
Operator MENs that are operated as separate administrative
domains
MEF 4 [6]
ENNI Frame

The first bit of the Destination Address to the last bit of the
Frame Check Sequence of the Ethernet Frame transmitted across
the ENNI
[8]
ENNI MTU

MTU of an ENNI frame at the ENNI [8]
E-Tree Service
An Ethernet service type that is based on a Rooted-Multipoint
EVC.
[1]
Ethernet Access
Provider

Operator of the MEN providing the OVC-based Ethernet service
between a UNI and an ENNI.
This
document
Ethernet Virtual
Connection
EVC
An association of two or more UNIs that limits the exchange of
Service Frames to UNIs in the Ethernet Virtual Connection.
[2]
EVC MTU Size The maximum sized Service Frame allowed for an EVC. [2]
EVPL Ethernet Virtual Private Line [1]


MEF 33
Page 4

Excess Burst Size EBS
EBS is a Bandwidth Profile parameter. It limits the maximum
number of bytes available for a burst of Frames sent at the EI
speed to remain EIR-conformant.
[2]
Excess I nformation
Rate
EIR
EIR is a Bandwidth Profile parameter. It defines the average rate
in bits/s of Frames up to which the network may deliver Frames
but without any performance objectives.
[2]
External I nterface EI Either a UNI or an ENNI [8]
Frame Short for Ethernet Frame [2]
Frame Delay FD
The time elapsed from the reception of the first bit of the ingress
frame at EI
1
until the transmission of the last bit of the
corresponding egress frame at EI
2
.
MEF
26.0.3
[17]
Frame Delay Range FDR
The difference between the observed percentile of delay at a
target percentile and the observed minimum delay for the set of
frames in interval T.
[2]
Frame Delay
Performance

A measure of the delays experienced by different Service or
ENNI Frames belonging to the same CoS Frame Set.
[17]
Frame Delay Range
Performance
A measure of the extent of delay variability experienced by
different Service or ENNI Frames belonging to the same CoS
Frame Set.
[17]
Frame Loss Ratio
Performance
FLR
between the ingress EI
1
and the egress EI
2
. Frame Loss Ratio is
expressed as a percentage.
[17]
I ngress Bandwidth
Profile

A characterization of ingress Frame arrival times and lengths at
the ingress EI and a specification of disposition of each Frame
based on its level of compliance with the characterization.
[2]
I ngress Service Frame
A Service Frame sent from an EI into the Service Provider
network.
[2]
I nter-Frame Delay
Variation
IFDV
The difference in delay of two Service or ENNI Frames
belonging to the same CoS Frame Set.
[17]
I nter-Frame Delay
Variation
Performance

A measure of the variation in the delays experienced by different
Service or ENNI Frames belonging to the same CoS Frame Set.
[17]
Layer 2 Control
Protocol Service
Frame
L2CP
Frame
A Service Frame that is used for Layer 2 control, e.g., Spanning
Tree Protocol.
[2]
Layer 2 Control
Protocol Tunneling

The process by which a Layer 2 Control Protocol Service Frame
is passed through the Service Provider network without being
processed and is delivered unchanged to the proper UNI(s).
[2]
Maximum Number of
OVCs per UNI

The maximum number of OVCs that may be on a UNI. This
document
Maximum Number of
CE-VLAN I Ds per
OVC

An integer that indicates the quantity of CE-VLANs that can be
mapped to a single OVC at that UNI. A value =1 indicates that
UNI can only map single CE-VLANs to an OVC. A value >1
indicates that up to that limit can be mapped to a single OVC.
This
document
Mean Frame Delay
Performance
MFD
The arithmetic mean, or average of delays experienced by
different Service or ENNI Frames belonging to the same CoS
Frame Set.
[17]
MEN Metro Ethernet Network [6]


MEF 33
Page 5

Metro Ethernet
Network
MEN The Service Providers network providing Ethernet services.
[6]
Maximum
Transmission Unit
MTU
The maximum sized Service Frame allowed for an Ethernet
service.
[1]
Multicast Service
Frame
A Service Frame that has a multicast destination MAC address.
[2]
Multipoint-to-
Multipoint EVC

[2]
Operator Virtual
Connection
OVC
Operator Virtual Connection, an association of OVC End Points [8]
OVC End Point

An association of an OVC with a specific External Interface i.e.,
UNI, ENNI
[8]
OVC I dentifier 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]
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.
[2]
Service Frame
An Ethernet frame transmitted across the UNI toward the Service
Provider or an Ethernet frame transmitted across the UNI toward
the Subscriber.
[2]
Service Level
Agreement
SLA
The contract between the Subscriber or Operator and Service
Provider specifying the agreed to service level commitments and
related business agreements.
Adopted
from [2]
and [8]
Service Level
Specification
SLS
The technical specification of the service level being offered by
the Service Provider to the Subscriber or Operator.
Adopted
from [2]
and [8]
A UNI service attribute in which the UNI can be in more than
one EVC instance.
[2]
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 I D 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-
byte field that, when present in an Ethernet frame, appears
immediately 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
IEEE Std
802.1ad
[5]
UNI MTU Size The maximum sized Service Frame allowed at the UNI. [2]


MEF 33
Page 6

Unicast Service
Frame
A Service Frame that has a unicast destination MAC address.
[2]
User Network
I nterface
UNI
The physical demarcation point between the responsibility of the
Service Provider and the responsibility of the Subscriber.
[2]
VLAN
Virtual LAN IEEE
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.

The key words MUST, MUST NOT, REQUI RED, SHALL, SHALL NOT,
SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTI ONAL in this
document are to be interpreted as described in RFC 2119 [4]. All key words use upper case, bold
text.


MEF 33
Page 7

Items that are REQUI RED (contain the words MUST or MUST NOT) will be labeled as [Rx]
NOT) will be labeled as [Dx] for desirable. Items that are OPTI ONAL (contain the words MAY
or OPTI ONAL) 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
Page 8

Service Type Port-Based VLAN-Based
E-Access
(point-to-point
OVC)
Access Ethernet Private Line
(Access EPL)
Access Ethernet Virtual Private Line
(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.

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.
Point - to - Point OVC
Metro Ethernet
Network
ENNI UNI
Point - to -
Metro Ethernet
Network
UNI


MEF 33
Page 9

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

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
Supported by Access
Provider s Wholesale
Service:
Service Provider
Offers MEF 6.1
Service:
Access-EPL
(Port-Based)
Access-EVPL
(VLAN-
Based)
P
o
r
t
-
b
a
s
e
d EPL X
EP-LAN X
V
L
A
N
-
b
a
s
e
d EVPL X
EVP-LAN X


MEF 33
Page 10

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
Page 11

[R2] An Access EPL Service instance MUST assign UNI Service Attributes and
values according to Table 4.

UNI Identifier No additional constraints fromdefinition in MEF 10.2 [2]
Physical Medium No additional constraints fromdefinition in MEF 10.2 [2]
Speed No additional constraints fromdefinition in MEF 10.2 [2]
Mode No additional constraints fromdefinition in MEF 10.2 [2]
MAC Layer No additional constraints fromdefinition in MEF 10.2 [2]
UNI MTU Size No additional constraints fromdefinition in MEF 10.2 [2]
and priority tagged Frames
MUST be a value from 1 4094.
Maximum number of OVCs
per UNI
MUST be 1 [new attribute defined below in Section 6.1.1.1]
UNI
MUST NOT specify
1

UNI
MUST NOT specify
Table 4: UNI service attributes and parameters for the Access EPL service
6.1.1.1 MaximumNumber 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
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
Page 12

OVC per UNI Service
Attribute
Possible Values
UNI OVC Identifier No additional constraints fromdefinition 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
Service Frames
The CoS Identifier for Service Frames MUST be the OVC End Point;
that OVC MUST have a single CoS Name.
Required, MUST specify <CIR, CBS, EIR, EBS, CM, CF>; MUST
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
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
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].
UNI
Not used.
MUST NOT specify
UNI
MUST NOT specify
Table 5: OVC per UNI Service Attributes for Access EPL service.
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

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
Page 13

OVC Service Attribute Possible Values
OVC Identifier No additional constraints fromdefinition in MEF 26 [8]
OVC End Point List Exactly 2, one OVC End Point at the UNI, one at the ENNI.
Maximum Number of UNI
OVC End Points
MUST be 1
Maximum Number ENNI
OVC End Points
MUST be 1
OVC Maximum
MUST be an integer number of bytes >or =to 1526; see Section 7.2.9 in
[8].
CE-VLAN CoS ID Value
Preservation
MUST be Yes
S-VLAN ID Preservation N/A as only one ENNI in the service instance
S-VLAN CoS ID Value
Preservation
N/A as only one ENNI in the service instance
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 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
Page 14

Service Attribute Name
Possible Values
OVC End Point Identifier No additional constraints fromdefinition in MEF 26 [8]
ENNI Frames
The CoS Identifier for ENNI Frames MUST be the OVC End Point to
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}.
OVC End Point
3

allow configuration to support CIR
2
values up to 70% of the ENNI
speed, in the following increments:
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.
color aware
profile.

Identifier
Not used.
End Point
MUST NOT specify.

Identifier
MUST NOT specify.
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
Page 15

[R6] An Access EPL Service instance MUST assign ENNI Service Attributes and

Name
Possible Values
Operator ENNI Identifier No additional constraints fromdefinition in MEF 26 [8]
Physical Layer No additional constraints fromdefinition in MEF 26 [8]
Frame Format No additional constraints fromdefinition in MEF 26 [8]
Number of Links No additional constraints fromdefinition in MEF 26 [8]
Protection Mechanism No additional constraints fromdefinition in MEF 26 [8]
ENNI Maximum
No additional constraints fromdefinition in MEF 26 [8]
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
OVCs
Maximum Number of
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
(Normati ve)
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
Page 16

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 I Ds 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
Page 17

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

UNI Identifier No additional constraints fromdefinition in MEF 10.2 [2]
Physical Medium No additional constraints fromdefinition in MEF 10.2 [2]
Speed No additional constraints fromdefinition in MEF 10.2 [2]
Mode No additional constraints fromdefinition in MEF 10.2 [2]
MAC Layer No additional constraints fromdefinition in MEF 10.2 [2]
UNI MTU Size No additional constraints fromdefinition in MEF 10.2 [2]
and priority tagged Frames
MUST be specified if untagged / priority tagged frames are to
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
per UNI
MUST be 1 [attribute defined in Section 6.1.1.1]
Maximum number of CE-
VLAN IDs per OVC
The OVC Endpoint Map MUST support a value =1
The OVC Endpoint Map SHOULD support a value >1.
UNI
MUST NOT specify
4

UNI
MUST NOT specify
Table 9: UNI service attributes and parameters for the Access EVPL service
6.2.3 OVC per UNI Service Attributes and Parameter Values
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
Page 18

[R9] An Access EVPL Service instance MUST assign OVC per UNI Service
Attributes and values according to Table 10.
OVC per UNI Service
Attribute
Possible Values
UNI OVC Identifier No additional constraints fromdefinition 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)
Service Frames
The CoS Identifier for Service Frames MUST be the OVC End Point to
which the Service Frame is mapped; that OVC MUST have a single CoS
Name.
allow configuration to support CIR values up to 70% of the UNI speed
5
,
in the following increments:
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.
color blind
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].
UNI
Not used.
MUST NOT specify
UNI
MUST NOT specify
Table 10: OVC per UNI Service Attributes for Access EVPL service.
Table 11 provides the OVC service attributes, parameters, and values for the Access EVPL
service.

5


MEF 33
Page 19

[R10] An Access EVPL Service instance MUST assign OVC Service Attributes and

OVC Service Attribute Possible Values
OVC Identifier No additional constraints fromdefinition in MEF 26 [8]
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
End Points
MUST be 1
Maximum Number ENNI OVC
End Points
MUST be 1
OVC Maximum Transmission
Unit Size
MUST be an integer number of bytes >or =to 1526; see Section
7.2.9 in [8].
CE-VLAN CoS ID Value
Preservation
MUST be Yes
S-VLAN ID Preservation N/A as only one ENNI in the service instance
S-VLAN CoS ID Value
Preservation
N/A as only one ENNI in the service instance
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
Multicast Frame Delivery Deliver Unconditionally or Deliver Conditionally. If Delivered
Broadcast Frame Delivery Deliver Unconditionally or Deliver Conditionally. If Delivered
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
Page 20

Service Attribute Name
Possible Values
OVC End Point Identifier No additional constraints fromdefinition in MEF 26 [8]
ENNI Frames
The CoS Identifier for ENNI Frames MUST be the OVC End Point to
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}.
OVC End Point
6

allow configuration to support CIR values up to 70% of the ENNI
speed
7
, in the following increments:
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.
color aware
profile.

Identifier
Not used.
End Point
MUST NOT specify.

Identifier
MUST NOT specify.
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 33
Page 21

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

Name
Possible Values
Operator ENNI Identifier No additional constraints fromdefinition in MEF 26 [8]
Physical Layer No additional constraints fromdefinition in MEF 26 [8]
Frame Format No additional constraints fromdefinition in MEF 26 [8]
Number of Links No additional constraints fromdefinition in MEF 26 [8]
Protection Mechanism No additional constraints fromdefinition in MEF 26 [8]
ENNI Maximum
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
OVCs
Maximum Number of
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
Page 22

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, J anuary 2010.
[9] MEF Technical Specification MEF 20, User Network Interface (UNI) Type 2
Implementation Agreement, J uly 2008.
[10] MEF Technical Specification MEF 30, Service OAM Fault Management
Implementation Agreement, J anuary 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
Page 23

[13] IEEE P802.1AB-REV/D6.0-2009. IEEE Standard for Local and metropolitan Area
Networks - Station and Media Access Control Connectivity Discovery J une 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, J anuary 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
Page 24

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
Page 25

Figure 7. Resulting Layer 1 bit rates for different MEF CI R 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.
60.00
70.00
80.00
90.00
100.00
50 250 450 650 850 1050 1250 1450 1650 1850
S
e
r
v
i
c
e

F
r
a
m
e

M
b
/
s

Frame Size, bytes
Maximum MEF Service Frame Bit Rate
Achievable on 100 Mb/s Interface


MEF 33
Page 26

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
Page 27

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.
EPL Service Attribute
(End to End)
Value Access EPL
Attribute
Value SP OVC
Attribute
Value
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
Frames map to
one EVC
OVC Endpoint
Map at UNI A
All CE-VLAN ID
values mapto
single OVC
OVC Endpoint
Map at UNI C
All CE-VLAN ID
values mapto
single OVC
4 N/A N/A ENNI Endpoint
Map
OVC Endpoint
E =SVLAN ID
158
ENNI Endpoint
Map
OVC Endpoint
F =SVLAN ID
158
5 Ingress bandwidth profile
per EVC
CIR=100 Mb/s,
CBS =12K,
EIR, EBS=0;
CM=blind;
Ingress
bandwidth
profile per OVC
EP at UNI A
CIR=100 Mb/s,
CBS =12K,
EIR, EBS=0;
CM=blind;
CF=0
Ingress
bandwidth
profile per OVC
EP at UNI C
CIR=100 Mb/s,
CBS =12K,
EIR, EBS=0;
CM=blind;
CF=0
6 N/A N/A Ingress
bandwidth
profile per OVC
EP at ENNI
CIR should
reflect S-tag
overhead, rest
same as UNI
Ingress
bandwidth
profile per OVC
EP at ENNI
CIR should
reflect S-tag
overhead, rest
same as UNI
7 CE-VLAN ID, CoS
preservation
MUST be yes CE-VLAN ID,
CoS
preservation
CoS
preservation
MUST be yes
8 CoS ID based on EVC,
value=M
CoS ID based
S-tagPCP
All PCP values
=M
CoS ID based
S-tagPCP
All PCP values
=M
9 EVC Performance MFD=80 ms
for Label=M,
PT=Continental
OVC
Performance
MFD=10 OVC
Performance
MFD =50


MEF 33
Page 28

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.
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
Page 29

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.

EP-LAN Service
Attribute (End to
End)
Value Access EPL
Attribute
Value SP OVC
Attribute
Value
1 EVC Type Multipoint to
Multipoint
OVC Type Point to Point OVC Type Multipoint to
Multipoint
2 All to One Bundling Yes N/A N/A
3 CE-VLAN ID to EVC
Map
All Service
Frames map to
one EVC
OVC Endpoint
Map at UNI A
All CE-VLAN
ID values map
to single OVC
OVC Endpoint
Map at UNIs C
& D
All CE-VLAN
ID values map
to single OVC
Map
OVC Endpoint
E =SVLAN
ID 158
ENNI Endpoint
Map
OVC Endpoint
F =SVLAN
ID 158
5 Ingress bandwidth
profile per EVC
CIR=100 Mb/s,
CBS =12K, EIR,
EBS=0;
CM=blind;
Ingress
bandwidth profile
per OVC EP at
UNI A
CIR=100
Mb/s, CBS =
12K, EIR,
EBS=0;
CM=blind;
CF=0
Ingress
bandwidth
profile per
OVC EP at
UNIs C & D
CIR=100
Mb/s, CBS =
12K, EIR,
EBS=0;
CM=blind;
CF=0
6 N/A N/A Ingress
bandwidth profile
per OVC EP at
ENNI
CIR should
reflect S-tag
overhead, rest
same as UNI
Ingress
bandwidth
profile per
OVC EP at
ENNI
CIR should
reflect S-tag
overhead, rest
same as UNI
7 CE-VLAN ID, CoS
preservation
CoS preservation
CoS
preservation
MUST be yes
value=M
CoS ID based S-
tagPCP
All PCP values
=M
CoS ID based
S-tagPCP
All PCP values
=M
9 EVC Performance MFD=80 ms for
Label=M,
PT=Continental,
S={all ordered
UNI pairs}
OVC
Performance
MFD=10
S={all ordered
OVC EP pairs
per OVC}
OVC
Performance
MFD =50
S={all ordered
OVC EP pairs
per OVC}


MEF 33
Page 30

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:

Table 16. Change in EP-LAN Attributes in hairpin switching example.

EP-LAN Service
Attribute (End to
End)
Value Access EPL
Attribute
Value SP OVC
Attribute
Value
Map
OVC Endpoint
E =SVLAN
ID 158
OVC Endpoint
G =SVLAN
ID 455
ENNI Endpoint
Map
OVC Endpoint
F =SVLAN ID
158
OVC Endpoint
H =SVLAN ID
455


MEF 33
Page 31

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.
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
Page 32

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.

EVPL Service
Attribute (End to
End)
Value Access
EVPL
Attribute
Value SP OVC
Attribute
Value
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
Map
Specifies what CE-
VLAN ID maps to
each EVC
OVC Endpoint
Map at UNI A
OVC Endpoint
a =CE-VLAN
ID 12
OVC Endpoint
b =CE-VLAN
ID 42
OVC Endpoint
Map at UNI C &
E
OVC Endpoint
c =CE-VLAN
ID 12
OVC Endpoint
e =CE-VLAN
ID 42
Map
OVC Endpoint
S =SVLAN ID
158
OVC Endpoint
U =SVLAN ID
455
ENNI Endpoint
Map
OVC Endpoint
T =SVLAN ID
158
OVC Endpoint
V =SVLAN ID
455
5 Ingress bandwidth
profile per EVC
CIR=100 Mb/s,
CBS =12K, EIR,
EBS=0; CM=blind;
Ingress
bandwidth
profile per OVC
EP at UNI A
CIR=100 Mb/s,
CBS =12K,
EIR, EBS=0;
CM=blind;
CF=0
Ingress
bandwidth
profile per OVC
EP at UNI C
CIR=100 Mb/s,
CBS =12K,
EIR, EBS=0;
CM=blind;
CF=0
6 N/A N/A Ingress
bandwidth
profile per OVC
EP at ENNI
CIR should
reflect S-tag
overhead, rest
same as UNI
Ingress
bandwidth
profile per OVC
EP at ENNI
CIR should
reflect S-tag
overhead, rest
same as UNI
7 CE-VLAN ID, CoS
preservation
MUST be YES or
NO
CE-VLAN ID,
CoS
preservation
CoS
preservation
MUST be YES
or NO
value=M
CoS ID based
S-tagPCP
All PCP values
=M
CoS ID based
S-tagPCP
All PCP values
=M
9 EVC Performance MFD=80 ms for
Label=M,
PT=Continental
OVC
Performance
MFD=10 OVC
Performance
MFD =50


MEF 33
Page 33

Figure 12. Access aggregation to Layer 3 services using Access EPL or Access EVPL.

MEF On The GO 1.0.120617V2

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

MEF On The GO 1.0.120617V2

Загружено:

Авторское право:

Доступные форматы

Home About Contact

Ethernet Academy Training Services MEF

, ). Another parameter is the objective

, expressed in time units,

. Finally, given a One-way Mean Frame Delay Performance objective , expressed in

, the Inter-Frame Delay Variation Performance SHALL be defined as

One-way Frame Delay Range Objective corresponding to

be the number of ingress frames that meet the following conditions:

, the SLS MUST define the Availability

: HLI Count Objective for S, T, and a given Class of Service Identifier

: CHLI Count Objective for S, T, and a given Class of Service Identifier

, the SLS MUST define the HLI Per-

, and the CHLI Perform-

Вам также может понравиться