Documente Academic
Documente Profesional
Documente Cultură
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
MEF-CECPs
View the current listing
of certified MEF-CECPs
Schedule an exam
Schedule your exam to take it
For more information on the MEF Professional Certification program online, or at a testing center.
click here.
If you have questions regarding the MEF specifications, you should join
the experts at the Ethernet Academy and participate in the Forums and
Discussion Groups.
Contact Us
Copyright 2011-2012 Metro Ethernet Forum Copyright 2011-2012 Ethernet Academy
Home About Contact
The fundamental concepts of Carrier Ethernet, Carrier Ethernet services and Download PDF
services types (E-Line, E-LAN and E-Tree) are introduced as well as the
concepts of private and virtual Carrier Ethernet services.
Download a pdf for
offline viewing.
Reference Documents
MEF 6.1
1 Services Definitions
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Carrier Ethernet services are designed to be delivered over all deployed 2.1.1 IEEE-based transport
technologies
transport infrastructures. This section explains the capabilities and relative
advantages of each transport technology in order to deploy a given Carrier 2.1.1.1 Bridging
Ethernet service in the most effective way possible. 2.1.1.2 Provider Bridging (PB)
2.1.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
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
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
A key benefit of Carrier Ethernet is its ability to provide consistent, cost- 3.1.1 HFC (DOCSIS)
efficient, high-performance services delivered to users who are connected 3.1.2 PON
over the widest variety of access networks in any location. 3.1.3 Packet Radio
All the access infrastructures described in this section have significant 3.1.4 PDH
This section highlights the relative capabilities of each access technology so Download PDF
that both Subscribers and Service Providers can understand better how to
request and implement Carrier Ethernet services.
Download a pdf for
offline viewing.
Reference Documents
IEEE 802.3
IEEE 802.16
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
This section describes the basic constructs and definitions of Ethernet services 4.1 Subscribers, Service Providers
and Operators
including the following:
4.2 EVC, OVC, UNI, ENNI and CEN
Subscriber (MEN)
Service Provider 4.3 Service Models
Operator
Carrier Ethernet Network (CEN) Download PDF
User Network Interface (UNI)
External Network to Network Interface (ENNI)
Ethernet Virtual Circuit (EVC) Download a pdf for
Operator Virtual Circuit (OVC) offline viewing.
Reference Documents
MEF 10.2
MEF 13
MEF 26.1
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
The Carrier Ethernet Service Definition Framework provides a model for 5.1
specifying Carrier Ethernet services. Carrier Ethernet Service types are generic 5.2 UNI Attributes
constructs used to create a broad range of services. Each Carrier Ethernet 5.3 EVC per UNI Attributes
service type has a set of Carrier Ethernet service attributes that define the
5.4 EVC Attributes
service characteristics. These Ethernet Service Attributes in turn have a set of
parameters associated with them that provide various options for the 5.4.1 L2CP per MEF 6.1.1
different service attributes as shown in the following figure: 5.5 ENNI Attributes
5.9
Figure 5.F1 - Type-Attribute-Attribute Parameter
[Source: MEF 6.1, figure 1] 5.10 EVC Performance Attributes
MEF 13
MEF 20
MEF 26.1
IEEE 802.1AX
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
6 MEF Certification
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
This section of the MEF-CECP Study Guide explains which aspects of Carrier 7.2 Wholesale Access Services
Ethernet need to be taken into account when running popular applications. 7.3 Mobile Backhaul
This is not an exhaustive list but does provide examples of the main factors 7.3.1 EVPL in Mobile Backhaul
relevant for different applications.
7.3.2 MEF 22 Use Cases
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Reference Documents
MEF 6.1
MEF 8
MEF 10.2
MEF 22.1
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Circuit Emulation Service over Ethernet (CESoETH) is a technology that enables 9.1 Purpose and Need
transport of TDM services over a Carrier Ethernet Network (CEN) as well as 9.1.1 What is CESoETH
enabling packet-based clock synchronization over a CEN.
9.1.2 MEF 8 model
CESoETH is specified in MEF 8 "Implementation Agreement for the Emulation of < br/>
PDH Circuits over Metro Ethernet Networks".
9.2 CES Components
MEF 8 gives precise instructions for implementing interoperable CES solutions 9.2.1 Interface to Customer
that reliably transport TDM circuits across CENs while meeting the required 9.2.2 Generic Interworking
performance of circuit emulated TDM services as defined in ITU-T and ANSI Function (GIWF)
TDM standards. 9.2.3 Functional Layering
< br/>
This section:-
9.3 Service Definitions
Explains the concept of emulated TDM circuits over Ethernet
9.3.1 E-Line
Presents the MEF 8 model
9.3.2 UNI Attributes
Details the components required for the service
Details the specific UNI and EVC attributes of CES over Ethernet 9.3.3 EVC Attributes
Explains the concept of packet-based sychronization and its 9.3.4 EVC per UNI Attributes
implementation over Carrier Ethernet
< br/>
9.4 Synchronization
9.4.1.2 NTP
9.4.1.3 1588 v2
9.4.2 SyncE
Download PDF
Reference Documents
MEF 8
MEF 22.1
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
10.2.0 Domains
10.2.1 Constructs
10.2.2 MEF 17
10.2.2.1 Model
< br/>
10.3.1 Definition
10.3.2 Procedures
< br/>
10.4 Performance Management
10.4.1 Definition
10.4.2 Procedures
10.4.3.3 Availability
< br/>
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Disclaimer
This MEF Study Guide is designed to provide as much useful information as possible for those learning about MEF-
standardized Carrier Ethernet, and specifically for those individuals planning to take MEF Professional Certification exams
such as MEF-CECP. The MEF makes every effort to keep the MEF Study Guide as up to date and as comprehensive as
possible. However, the MEF disclaims all responsibility for the accuracy and completeness of the MEF Study Guide and
disclaims all responsibility for any consequences whatsoever resulting from the use of the MEF Study Guide. Also, the MEF
does not provide any assurance that use of this MEF Study Guide will ensure that MEF-CECP examinees answer MEF-CECP
certification exams correctly or pass the exam.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Carrier
Describe the advantages of Ethernet 5921
2.4 specific Carrier Ethernet Access 802.1Q-2009
transport technologies. Reference 5960
Presentation
Mobile
G.8031
Describe service protection Backhaul
2.5 802.1Q-2009
mechanisms. Reference G.8032
Presentation
MEF White
Paper:
Compare and contrast
Ethernet
3.2 specific Carrier Ethernet
Services and
Access technologies.
Access
Technologies
Carrier
Ethernet
Access
Reference
Given a scenario, identify Presentation
which Carrier Ethernet 802.3-2005
3.3
Access Technology will meet MEF White 802.16-2009
the stated requirements. Paper:
Ethernet
Services and
Access
Technologies
MEF 10.2
5.5 Describe bandwidth profiles.
MEF 26
MEF 9
Describe what is covered by
6.3 MEF 9, MEF 14, and MEF 18 MEF 14
Certifications.
MEF 18
Carrier
Describe wholesale access
Ethernet
services, retail
Access
commercial/business
Reference
services, mobile backhaul
7.1 MEF 22 Presentation
services, Ethernet access to
IP services, and supporting
White Paper
legacy services over
Introduction
Ethernet.
to CESoE
Mobile
Backhaul
Reference
Presentation
Given a scenario, determine MEF 6.1
7.5 appropriate Ethernet
Carrier
services. MEF 8
Ethernet
Access
Reference
Presentation
Carrier
Define the purpose and need Ethernet
9.1 for Circuit Emulation over MEF 8 Access
Ethernet applications. Reference
Presentation
Carrier
Define the critical
Ethernet
components of circuit
9.2 MEF 8 Access
emulation over Ethernet
Reference
service.
Presentation
Global
Describe the basic MEF 10.2 Interconnect
10.3 mechanisms for performance Y.1731
Reference
management. MEF 17
Presentation
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Diagrams
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
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.
E-Access:
MEF 33
Ethernet
802.3-2005
IETF RFCs
Encapsulation Methods for
Transport of Ethernet over MPLS
RFC 4448
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Disclaimer
This MEF Study Guide is designed to provide as much useful information as possible for those learning about MEF-standardized Carrier
Ethernet, and specifically for those individuals planning to take MEF Professional Certification exams such as MEF-CECP.
The MEF makes every effort to keep the MEF Study Guide as up to date and as comprehensive as possible. However, the MEF disclaims
all responsibility for the accuracy and completeness of the MEF Study Guide and disclaims all responsibility for any consequences
whatsoever resulting from the use of the MEF Study Guide.
Also, the MEF does not provide any assurance that use of this MEF Study Guide will ensure that MEF-CECP examinees answer MEF-CECP
certification exams correctly or pass the exam.
Carrier
Describe the advantages of Ethernet 5921
2.4 specific Carrier Ethernet Access 802.1Q-2009
transport technologies. Reference 5960
Presentation
Mobile
Describe service protection Backhaul G.8031
2.5 802.1Q-2009
mechanisms. Reference
G.8032
Presentation
MEF White
Paper:
Compare and contrast specific
Ethernet
3.2 Carrier Ethernet Access
Services and
technologies.
Access
Technologies
Carrier
Ethernet
Access
Reference
Given a scenario, identify Presentation
which Carrier Ethernet Access 802.3-2005
3.3
Technology will meet the MEF White
802.16-2009
stated requirements. Paper:
Ethernet
Services and
Access
Technologies
Define Ethernet User-to-
Network Interface (UNI),
Ethernet External Network-to-
Network Interface (ENNI), MEF 10.2
4.1
Ethernet Virtual Connection
MEF 26
(EVC), Service Provider,
Operator, and Operator Virtual
Connection (OVC).
MEF 10.2
5.5 Describe bandwidth profiles.
MEF 26
MEF 6.1
Given a service scenario,
5.6 describe relevant service MEF 10.2
attribute settings/parameters.
MEF 26
MEF 9
Describe what is covered by
6.3 MEF 9, MEF 14, and MEF 18 MEF 14
Certifications.
MEF 18
Carrier
Describe wholesale access Ethernet
services, retail Access
commercial/business services, Reference
7.1 mobile backhaul services, MEF 22 Presentation
Ethernet access to IP services,
and supporting legacy services White Paper
over Ethernet. Introduction
to CESoE
Mobile
Backhaul
Reference
Presentation
MEF 6.1
Given a scenario, determine
7.5
appropriate Ethernet services. Carrier
MEF 8
Ethernet
Access
Reference
Presentation
MEF 6.1
Given a scenario, recommend MEF 8
8.2 an Ethernet service to meet
end user specifications. MEF 10.2
MEF 22
Carrier
Define the purpose and need Ethernet
9.1 for Circuit Emulation over MEF 8 Access
Ethernet applications. Reference
Presentation
Carrier
Define the critical components Ethernet
9.2 of circuit emulation over MEF 8 Access
Ethernet service. Reference
Presentation
Global
MEF 10.2 Interconnect
Describe the basic mechanisms
10.3 Y.1731
for performance management. MEF 17 Reference
Presentation
MEF 6.1
Describe the basic metrics for
10.4
performance management. MEF 10.2
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
LAN Ethernet is also designed for use only over specific short distance
infrastructures (e.g. 100BaseT cabling), not over Wide Area Network Download a pdf for
offline viewing.
infrastructures (e.g. PDH, SONET/SDH, DOCSIS, PON, WDM etc.)
The different aspects of a true service are also not supported by the very
popular LAN Ethernet technology which does not guarantee levels of
availability (e.g. 5 nines), Classes of Service suited to different application Reference Documents
and user needs nor does it support the type of management capabilities
MEF 6.1
required for large network service delivery that is available with legacy WAN
technologies.
MEF-CECP Test Objectives
In order to combine the advantages of LAN Ethernet's large installed base and 1 Services Definitions
the familiarity of its technology with the requirements of multi-site users and
their service providers, the MEF began in 2001 to develop the specifications
Send Feedback
that today provide the basis for the use of Ethernet as a global networking
solution.
Name:
The MEF defined five key attributes that differentiate Carrier Ethernet from
Email:
LAN Ethernet, and which form the basis for the development of Carrier
Ethernet specifications by the MEF. Comments
Send Feedback
Standardized services
Scalability
Reliability
Service management
Quality of service
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.
Based on the goals of the 5 attributes and the specifications developed by the
MEF, Carrier Ethernet
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)
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
E-Line
E-LAN Download a pdf for
E-Tree offline viewing.
These Carrier Ethernet service types are fundamental to the Carrier Ethernet
service model and are defined in MEF 6.1. All aspects of the MEF's technical,
marketing and certification work flow from the definitions and uses of E-Line, Reference Documents
E-LAN and E-Tree. Brief descriptions for these service types are provided
below, and are expanded upon in the remainder of this MEF-CECP Study MEF 6.1
Guide.
MEF-CECP Test Objectives
E-Line
1 Services Definitions
An E-Line is a point to point Ethernet service that connects exactly 2 UNIs.
Those 2 UNIs can communicate only with each other.
Send Feedback
Name:
Email:
Comments
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
Multipoint L2 VPNs
Transparent LAN services
Layer 2 VPNs (L2VPN)
Foundation for IPTV and Multicast networks
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.
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.
Multiple root UNIs are permitted in E-Trees in order to support mirror sites
(resiliency) and load sharing configurations.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Private services can be offered for any topology. Download a pdf for
offline viewing.
EPL: Ethernet Private Line for port-based point-to-point service. EPL
is the private variant of an E-Line
EP-LAN: Ethernet Private LAN for port-based multipoint-to-multipoint
service. EP-LAN is the private variant of an E-LAN Reference Documents
EP-Tree: Ethernet Private Tree for port-based rooted-multipoint
service. EP-Tree is the private variant of an E-Tree. MEF 6.1
The advantage of the private service approach is its simplicity. The MEF-CECP Test Objectives
disadvantage is its lack of scalability since it requires several ports on both
1 Services Definitions
the Customer Equipment (CE) and the switch/router at the provider edge.
To overcome this barrier to scalability, the MEF defined the virtual service Send Feedback
based on the concept of VLANs where each service is identified by one or
more VLAN IDs. Following IEEE 802.1Q, the VLAN tag is the C-Tag. Name:
A virtual service means that a UNI can deliver multiple services using a single Email:
physical port, and can be offered for any topology.
Comments
EVPL: Ethernet Virtual Private Line for VLAN-based point-to-point
service. EVPL is the virtual variant of an E-Line
EVP-LAN: Ethernet Virtual Private LAN for VLAN-based multipoint-to-
multipoint service. EVP-LAN is the virtual variant of an E-LAN Send Feedback
Service Multiplexing
EVC2 shares the same UNI port D with EVC1 and is used to deliver video
multicast to a different set of customers.
A single UNI can serve multiple Carrier Ethernet service types, as shown in
this example.
The headquarters (HQ) of the enterprise has 2 services sharing a single port on
its router:
EVPL connect the organization to its ISP. The traffic sent to the ISP carries C-
Tags as agreed with the Carrier Ethernet Network (CEN) service provider
EVP-LAN connects the HQ with 2 other branches, providing L2VPN between
these three sites.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
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.
Please note that the disclaimer for the MEF-CECP Study Guide applies equally to the PDF version as
well as to the online versions. By downloading this PDF document you are accepting this disclaimer.
'
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
MEF 6.1
Metro Ethernet Services Definitions Phase 2
Specification
MEF 6.1 is a specification document developed by the Technical Committee of the MEF.
Abstract:
"This document uses the service attributes and parameters that are defined in the MEF Technical Specification Ethernet
Services Attributes Phase 2 [2] and applies them to create different Ethernet services. This document defines three
generic service constructs called Ethernet Service types and specifies their associated service attributes and parameters
used to create Point-to-Point, Multipoint-to-Multipoint, and Rooted-Multipoint Ethernet services. This document also
defines the requirements for several Ethernet services that use these generic Ethernet Service types. In addition, an
informative appendix is provided showing examples of some of the defined services. This document supersedes and
replaces MEF 6, Ethernet Services Definitions - Phase 1 [1]."
Download
Reference Presentation
The MEF has prepared an overview presentation which explains the MEF 6.1 specification.
Download
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
1.1 Describe and distinguish between the service attributes of EPL, EVPL, EP- 1.1 Carrier Ethernet and LAN
LAN, EVP-LAN, EP-Tree, and EVP-Tree. Ethernet
Download PDF
Reference Documents
MEF 6.1
1 Services Definitions
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
It is important to understand which transport technologies enable which 2.1.3 Transparent Transport
Carrier Ethernet services and which attributes are required, as well as to 2.1.3.1 SONET/SDH
understand the differences in capabilities (e.g. transparency to L2CP,
2.1.3.2 OTN
topology) of these technologies. This is explained in the corresponding sections
on each technology. 2.1.3.3 WDM
For the sake of simplicity, the above technologies have been grouped under
the following categories: 2.2 Protection and Resiliency
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
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
2. Link Failure
2.1.2 MPLS based
3. Network Element (NE) Failure
2.1.2.1 VPWS
Since MEF services define interfaces only, we focus on the first two types of
2.1.2.2 VPLS
failures. It should be noted that NE failure handling is heavily dependent on
2.1.2.3 MPLS-TP
the transport technology of the specific network in question.
2.1.3.1 SONET/SDH
We focus our discussion on the external Interfaces - namely UNI and ENNI.
2.1.3.2 OTN
MEF 20 defines as a mandatory feature of UNI Type 2.2 the capability to
2.1.3.3 WDM
protect against a UNI-N port failure and/or protect against a failure of a
physical link crossing the UNI point.
2.2 Protection and Resiliency
The solution is LAG (Link Aggregation). The basic concept is having standby
links that can be used upon failure of a working (active) link. LAG enables the Download PDF
definition of a LAG group of at least 2 ports/2 physical links and considering
them as a single logical link. The UNI-N and UNI-C can be perceived as
connected over this single logical link. Note that one could connect 4 X 1GbE Download a pdf for
links and operate 3 of them as active links with one standby link. This would offline viewing.
yield a logical link of 3 Gbps between the UNI-N and UNI-C.
For ENNI the definition is stricter. LAG is defined for exactly 2 ports where
only one link is active and the second one is standby. The reason for this Reference Documents
limitation is the desire to have the service frames and SOAM frame traverse
the same link as each other, which cannot be guaranteed with LAG operating IEEE 802.1Q-2009
more than one active link (load sharing LAG). MEF recommends operating LAG IEEE 802.1ad-2005
with its control protocol LACP.
IEEE 802.1ah
ITU-T G.8031
ITU-T G.8032
ITU-T Y.1415
RFC 4448
2.2.F1 - UNI protection
RFC 4761
ENNI Protection is depicted in the following figure:
RFC 5921
RFC 5960
Service Protection deals with the need to ensure that the EVC/OVC can Email:
provide the service even if a specific link or node within the CEN fails. This
enables the Service Provider to offer high availability (e.g. five 9s Comments
Active:Standby EVC
In this approach, there are 2 EVCs with identical service attributes. At any
given time only one EVC is used for the service. At the ingress UNI a certain
logic is used to decide which of the 2 EVCs are in use.
2.2.F3 - Standby EVC in Mobile Backhaul
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.
This approach hides the internal resiliency mechanism from the end user who
will feel only a very short traffic disruption.
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:
The protocol also breaks loops and therefore make STP redundant.
The following figure illustrates virtual ring made out of a physical star:
MPLS FRR
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.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Provider Backbone Bridged with Traffic Engineering (PBB-TE) networks 2.1.1.4 Provider Backbone
Bridging - Traffic Engineering
All these networks require some form of layer 1/2 transport technology to (PBB-TE)
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
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
2.1.2.1 VPWS
2.1.2.2 VPLS
2.1.2.3 MPLS-TP
2.1.1.1.F1 - C-Tag Frame Format
2.1.3 Transparent Transport
The format of the C-Tag itself is provided below:
2.1.3.1 SONET/SDH
2.1.3.2 OTN
2.1.3.3 WDM
Download PDF
In a CEN (Carrier Ethernet Network) that is based on bridging, the ingress
bridge translates the incoming CE-VLAN ID to a specific tag defined for a
service. Each service is identified by a unique VLAN ID. In such a scenario, the
Download a pdf for
available VLAN IDs in the range 1 through 4094 must be shared and offline viewing.
coordinated between the subscribers and the CEN operator to ensure that the
same value is not used twice.
Obviously, subscribers cannot send untagged frames and frames with priority
tags across a CEN based on bridging since the egress bridge will not know how Reference Documents
to regenerate the tags and priorities in the frames forwarded to the
subscriber site. In addition, MAC learning is shared by subscriber bridges and IEEE 802.1Q-2009
the CEN's bridges, which again implies several limitations. This fact coupled IEEE 802.1ad-2005
with limited port filtering of the bridges makes support of E-Tree a significant IEEE 802.1ah
configuration challenge. In addition, such a network cannot support bundling,
IEEE 802.1Qay
as it is not possible to regenerate the original CE-VLAN IDs on an egress UNI
ITU-T G.8031
using a single C-Tag.
Since the CEN operates using bridges, it relies on xSTP (any variant of ITU-T G.8032
Spanning Tree Protocol) for loop prevention and resiliency. In the event of a ITU-T Y.1415
link failure, xSTP is used to find a new path through the CEN. This implies RFC 4448
that some subscriber L2CPs will not be tunneled through a CEN based on
RFC 4761
bridging.
RFC 5921
Using the C-Tag for service identification and dividing the applicable VLAN ID
range between the operator and the subscriber affects the number of services RFC 5960
that can be supported.
Also, there must be coordination between all participating UNIs of the CE- MEF-CECP Test Objectives
VLAN IDs used for each service. 2 Transporting Carrier Ethernet
The CoS ID for an EVC is identified by the PCP bits. No other field can Services
represent the CoS within the CEN. Therefore, if the PCP bits are used to set a
specific EVC CoS, then the CE-VLAN CoS preservation attribute cannot be set Send Feedback
to Yes.
In addition, the 8 possible values are shared between CoS ID and frame color. Name:
These values need to be transported through the CEN.
It is clear that only small scale CENs will be based on bridging, and where Email:
there are no ENNIs (since they require use of S-Tags).
Comments
The support for the various Ethernet services is summarized in the following
table:
Send Feedback
2.1.1.1.T1 - Bridging support for Carrier Ethernet Services
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
2.1.2.1 VPWS
The Double Tag Frame Format is shown below:
2.1.2.2 VPLS
2.1.2.3 MPLS-TP
2.1.3.2 OTN
The structure of the S-Tag is shown below:
2.1.3.3 WDM
Download PDF
2.1.1.2.F2 - S-Tag Format
Download a pdf for
The value of the S-VLAN ID can be 1 through 4094. offline viewing.
IEEE 802.1Q-2009
As shown in the figure above, the S-VLAN Priority field is 3-bit wide, allowing
for 8 possible values. The Drop Eligible Indicator can be used to represent a IEEE 802.1ad-2005
frame's color. When the DEI bit is clear, the frame is considered to be Green. IEEE 802.1ah
When the DEI bit is set, the frame is considered to be Yellow. IEEE 802.1Qay
The edge bridge of the PB network performs the mapping to an EVC or an ITU-T G.8031
OVC, where the EVC or OVC is identified by an S-VLAN ID. It is also possible to ITU-T G.8032
add an S-Tag to ingress C-Tagged frame, thereby preserving the Subscriber's ITU-T Y.1415
original C-VLAN ID. This is also true in the case of an untagged frame.
RFC 4448
PB supports all six MEF-defined services (EPL, EVPL, EP-LAN, EVP-LAN, EP- RFC 4761
Tree and EVP-Tree). PB inherently supports service multiplexing by allowing RFC 5921
service providers to map C-VLANs to S-VLANs at a port being used for the UNI.
RFC 5960
PB relies on the bridges within the CEN (Carrier Ethernet Network) for
multicast operations required by E-LAN and E-Tree services. MEF-CECP Test Objectives
Name:
Email:
Comments
Send Feedback
2.1.1.2.T1 - Provider Bridging Support for Carrier Ethernet Services
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
A PBB network (PBBN) can be a service provider's CEN that provides 2.1.2.1 VPWS
connectivity between UNIs for Subscribers through EVCs. Similarly, a PBB 2.1.2.2 VPLS
network could be an operator's network that provides connectivity from ENNI- 2.1.2.3 MPLS-TP
to-ENNI or from ENNI-to-UNI for service providers through OVCs.
2.1.3 Transparent Transport
The concept of MAC-in-MAC was introduced in PBB. MAC-in-MAC allows the
2.1.3.1 SONET/SDH
service provider to fully encapsulate the customer 802.1Q frame within
another MAC, which abstracts the service provider from the Subscriber's 2.1.3.2 OTN
address and VLAN information. 2.1.3.3 WDM
At the ingress to the PBB network, a second MAC header is inserted by the
bridge. With this technique, the Subscriber's frame is kept intact and
2.2 Protection and Resiliency
unaltered from end-to-end throughout the provider's backbone network. The
backbone bridges can only interpret the outermost MAC header information.
Download PDF
Furthermore, a new Tag type called the I-SID (Backbone Service Instance
Identifier) was introduced by PBB. The I-SID provides 24 bits for identifying
services, which enables the PBB network (PBBN) to uniquely identify up to 16
Download a pdf for
million service instances. This is equivalent to the scalability provided by offline viewing.
MPLS. In fact, the number of services per link is even higher than 16M. This is
because a link can serve multiple destination B_DA, each of which supports
16M services. Therefore, in practice, the number of services per link in PBB is
unlimited. Reference Documents
PBB introduces two new types of tags: the Backbone VLAN Tag (B-Tag) and IEEE 802.1Q-2009
the Backbone Service Instance Tag (I-Tag). The B-Tag is identical to an S-Tag, IEEE 802.1ad-2005
but is the tag that Backbone Bridges within the PBBN use to make traffic
IEEE 802.1ah
forwarding decisions. The I-Tag encapsulates the Subscriber's MAC information
IEEE 802.1Qay
and identifies the service instance through the I-SID. The I-SID is a 24-bit field
that is used to uniquely identify up to 16 million service instances. ITU-T G.8031
ITU-T G.8032
The frame format is depicted below:
ITU-T Y.1415
RFC 4448
RFC 4761
RFC 5921
RFC 5960
On ingress, each service frame is parsed in order to identify the correct 2 Transporting Carrier Ethernet
EVC/OVC to which it is mapped. A new MAC header is then added accordingly. Services
The CEN (Carrier Ethernet Network) then forwards the frame through the
PBBN according to the backbone header. Forwarding is performed exactly as Send Feedback
in PB (Provider Bridging). Bridges learn (backbone) addresses, flood when an
unknown address is identified, and use the same xSTP-based resiliency Name:
mechanisms as in PB.
Email:
The B-Tag (which is identical to an S-Tag is format and TPID) has 3 bits of PCP
Comments
for CoS identification and can use the DEI bit for color marking within the
CEN, which is necessary for ENNI color forwarding.
One of the following actions can be performed on the value of the B-Tag's
PCP: - mapped from the original S-Tag - set to the EVC/OVC attributes -
Send Feedback
mapped from the original frame's DSCP header. This enables PBB to support
up to 8 CoSs per EVC/OVC.
PBB provides the same connectivity properties of a PB. Therefore PB can
support E-LINE, E-LAN and E-Tree with same constraints as in PB networks. In
other words, in PBB networks, there is limited transparency for EPL due to
L2CP filtering by the ingress bridges. Also, there is the need to add leaf-to-
leaf filtering in an E-Tree since this is not an intrinsic PB or PBB cabability.
The support for the various Ethernet services is summarized in the following
table:
2.1.1.3.T1 - Provider Backbone Bridging Support for Carrier Ethernet Services
PBB forwarding is based on spanning tree. In some cases the forwarding tables
can be adjusted to provide a specific path between B_SA and B_DA. PBB
service resiliency is based on RSTP and MSTP. Pre-defined backup paths are
not supported and therefore, convergence time depands on the topology and
RSTP message rate. Port protection for UNI or ENNI can be supported using
LAG.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
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
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
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
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
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
between LERs (Label Edge Routers). These LERs or PEs (Provider Equipment) 2.1.1.4 Provider Backbone
Bridging - Traffic Engineering
in Carrier Ethernet terminology provide the UNI-N functionality. In such a
(PBB-TE)
case, the CEN (Carrier Ethernet Network) provides Ethernet services to CEs
(Customer Equipment) attached to the PEs. 2.1.2 MPLS based
In other deployments, the network is a CEN where some external interfaces 2.1.2.1 VPWS
are ENNIs. In such a case, the PW is between the ENNI-N and a UNI-N or 2.1.2.2 VPLS
between two ENNI-Ns. 2.1.2.3 MPLS-TP
Multiple PWs can be carried over a single LSP, and each PW can be configured Download PDF
to carry either one CoS (Class of Service) or multiple CoSs. Up to a maximum
of 8 CoSs can be carried over a given PW.
Download a pdf for
The following figure illustrates how a C-TAG frame sent from the CE is offline viewing.
Reference Documents
IEEE 802.1Q-2009
IEEE 802.1ad-2005
IEEE 802.1ah
IEEE 802.1Qay
ITU-T G.8031
ITU-T G.8032
2.1.2.1.F1 - VPWS
ITU-T Y.1415
RFC 4448
The tunnel label (LSP label) is a 20-bit field, yielding over 16 million unique
RFC 4761
labels over a link. Each LSP can carry one or more EVCs (Ethernet Virtual
Connection) or OVC (Operator Virtual Connection). Since an EVC or an OVC RFC 5921
can be mapped to a single PW or to multiple PWs, theoretically 16 million RFC 5960
EVCs and/or OVCs can be carried over a single LSP. This implies that an
almost unlimited number of Carrier Ethernet services can be implemented MEF-CECP Test Objectives
over a single VPWS.
2 Transporting Carrier Ethernet
Services
The MPLS network has a 3-bit CoS ID identifier called the EXP bits (also known
as the Traffic Class field in later RFCs). The EXP bits are used for CoS ID and
Send Feedback
color forwarding where applicable.
Up to eight CoSs can be delivered over MPLS LSPs. However, assuming that Name:
some CoSs need to also denote color, the effective number is five CoSs. MPLS
Email:
networks can support the 3-CoS model of MEF 23.
Comments
The ingress LER can tunnel almost any frame over a PW, with the exception of
PAUSE frames. It can support CE-VLAN ID and CE-VLAN CoS preservation.
Interworking with customer spanning tree is also specified. This means that
EPL and EVPL services can be provided over VPWS with transparent handling
Send Feedback
of L2CPs.
Multicast is not part of this transport technology. In the event that multicast
support is required, VPLS can be used (see next section).
Support for the various Ethernet services is summarized in the following table:
2.1.2.1.T1 - VPWS Support for Carrier Ethernet Services
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
2.1.1.1 Bridging
Resiliency is also provided by the MPLS LSP and PW layers which can be 2.1.2 MPLS based
considered to be independent of the VPLS service instance. Services are 2.1.2.1 VPWS
denoted in the same manner as for VPWS, as is CoS ID. 2.1.2.2 VPLS
2.1.2.3 MPLS-TP
Each PE includes a logical element called a VSI (Virtual Switch Instance). The
VSI emulates an IEEE 802.1Q Bridge. In other words, the VSI handles C-TAG 2.1.3 Transparent Transport
frames, learns the customer MAC addresses and makes the forwarding 2.1.3.1 SONET/SDH
decision. Once a destination or set of destinations is determined, the 2.1.3.2 OTN
appropriate frame is encapsulated with the tunnel and PW headers. When
2.1.3.3 WDM
there is a need to multicast or broadcast, the ingress PE replicates the frames
and sends a copy to each egress PE. In this manner, the service "virtually
bridges" the customer end-points, simulating a private LAN. 2.2 Protection and Resiliency
Download PDF
Multiple VPLS instances - one per service or L2VPN - can use the same
network infrastructure.
Download a pdf for
offline viewing.
VPLS provides support for all 6 MEF-defined Carrier Ethernet service types.
The L2CP handling capabilities are virtually the same as for provider bridging,
as both incorporate a bridge component that handles customer C-TAG frames.
Reference Documents
The CEN (Carrier Ethernet Network) does not use xSTP (variants of Spanning IEEE 802.1Q-2009
Tree Protocol) for forwarding or resiliency. The Customer xSTP is not tunneled
IEEE 802.1ad-2005
across the VPLS-based CEN.
IEEE 802.1ah
IEEE 802.1Qay
E-Tree is naturally supported by VPLS. The concept of hub (root) and spoke
ITU-T G.8031
(leaf) is also part of the VPLS standard.
ITU-T G.8032
ITU-T Y.1415
Support for the various Ethernet services is summarized in the following table:
RFC 4448
RFC 4761
RFC 5921
RFC 5960
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
MPLS-TP uses the same packet format as MPLS, as well as uses LSPs (Label 2.1.1.4 Provider Backbone
Bridging - Traffic Engineering
Switched Paths) and PWs (pseudowires)
(PBB-TE)
2.1.3.1 SONET/SDH
MPLS-TP also provides extensive OAM support, including Y.1731 FM (Fault
Management) and PM (Performance Management). Unlike MPLS, MPLS-TP does 2.1.3.2 OTN
not use IP routing, so MPLS-TP CENs can be purely layer 2 networks. 2.1.3.3 WDM
MPLS supports point-to-point LSPs and also point-to-multipoint LSPs. Unlike 2.2 Protection and Resiliency
MPLS, the forward and reverse directions of traffic are carried over the same
network path at all times. Download PDF
E-LANs and E-Trees can be implemented by running VPLS over MPLS-TP based Download a pdf for
LSPs and PWs. offline viewing.
Due to the fact that MPLS-TP uses the same frame format as MPLS, the
scalability of services and CoS identification is the same. Refer to MPLS over Reference Documents
VPWS for more details.
IEEE 802.1Q-2009
EPL services can be provided over MPLS-TP with transparent handling of L2CPs
IEEE 802.1ad-2005
in a similar fashion to that supported by VPWS.
IEEE 802.1ah
Support for the various Ethernet services is summarized in the following table: IEEE 802.1Qay
ITU-T G.8031
ITU-T G.8032
ITU-T Y.1415
RFC 4448
RFC 4761
RFC 5921
RFC 5960
Send Feedback
Name:
Email:
Comments
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
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
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
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
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
IEEE 802.1ad-2005
IEEE 802.1ah
IEEE 802.1Qay
ITU-T G.8031
ITU-T G.8032
ITU-T Y.1415
2.1.3.1.F2 - Encapsulation of an Ethernet frame inside GFP-F frame RFC 4448
All of the encapsulation techniques (e.g. GFP, POS) are not aware of the RFC 4761
Ethernet frame structure. This means that any L2CP frame can be tunneled RFC 5921
through a SONET/SDH-based E-Line service. Also, no MAC learning, forwarding
RFC 5960
or filtering is performed by these network elements.
Comments
Each SONET/SDH link can support several EVCs. However, the number of
services that can be supported is limited due to the static bandwidth
allocation mechanism of SONET/SDH. Each such SONET/SDH path has no CoS
Send Feedback
awareness or VLAN tag awareness.
SONET/SDH technology is suitable only for E-Line services. It can provide some
sort of service multiplexing using external ADM device for delivering EVPLs.
Resiliency is inherently supported by this transport network, which provides
sub-50 msec service restoration that is transparent to the Ethernet layer.
Support for the various Ethernet services is summarized in the following table:
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Ethernet over OTN provides the same resiliency as SONET/SDH but with more 2.1.3 Transparent Transport
flexible bandwidth allocation. It is fully transparent to the Ethernet frame, 2.1.3.1 SONET/SDH
meaning any L2CP frame can be tunneled over the OTN-based network. No
2.1.3.2 OTN
MAC learning, forwarding or filtering is performed.
Support for EVPL is limited and requires specific mapping and depends on the 2.1.3.3 WDM
topology.
Support for the various Ethernet services is summarized in the following table: Download PDF
Download a pdf for
offline viewing.
Reference Documents
IEEE 802.1Q-2009
IEEE 802.1ad-2005
IEEE 802.1ah
IEEE 802.1Qay
ITU-T G.8031
ITU-T G.8032
ITU-T Y.1415
RFC 4448
RFC 4761
RFC 5921
RFC 5960
2.1.3.2.T1 - OTN Support for Carrier Ethernet Services MEF-CECP Test Objectives
2 Transporting Carrier Ethernet
Services
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
2.1.3.1 SONET/SDH
2.1.3.2 OTN
2.1.3.3 WDM
2.1.3.3.F1 - WDM
The WDMs cannot decipher the CoS Identifier and VLAN tag information 2.2 Protection and Resiliency
contained within an Ethernet frame, so all Ethernet frames associated with a
particular service are transported by the same photonic channel. Only physical Download PDF
layer failures can be detected and acted upon with this technology, and
recovery is performed without intervention from the Ethernet MAC layer.
Download a pdf for
offline viewing.
Reference Documents
IEEE 802.1Q-2009
IEEE 802.1ad-2005
IEEE 802.1ah
IEEE 802.1Qay
ITU-T G.8031
ITU-T G.8032
ITU-T Y.1415
RFC 4448
RFC 4761
RFC 5921
RFC 5960
2.1.3.3.T1 - WDM Support for Carrier Ethernet Services 2 Transporting Carrier Ethernet
Services
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
IEEE 802.1Q-2005
Virtual LANs (VLAN)
The 802.1Q-2005 standard developed by IEEE is a useful reference for understanding the topic of Virtual LANs (VLAN) in
the context of Carrier Ethernet networks. The standards document is not available directly from the MEF but may be
obtained from IEEE.
Other relevant links for VLANs can be found at the Wikipedia page on the topic.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
IEEE 802.1ad-2005
Provider Bridges
The 802.1ad-2005 standard developed by IEEE is a useful reference for understanding how Carrier Ethernet services can be
transported over Provider Bridge networks. The standards document is not available directly from the MEF but may be
obtained directly from IEEE.
Other relevant links for Provider Bridges can be found at the Wikipedia page on the topic.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
IEEE 802.1ah-2008
Provider Backbone Bridges
The 802.1ah-2008 standard developed by IEEE is a useful reference for understanding how Carrier Ethernet services can be
transported over Provider Backbone Bridge networks. The standards document is not available directly from the MEF but
may be obtained from the IEEE.
Other relevant links for Provider Backbone Bridges can be found at the Wikipedia page on the topic.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
IEEE 802.1Qay
Provider Backbone Bridging - Traffic Engineering (PBB-TE)
The 802.1Qay standard developed by IEEE is a useful reference for understanding how Carrier Ethernet services can be
transported over PBB-TE networks. The standards document is not available directly from the MEF but may be obtained
directly from IEEE.
Other relevant links for PBB-TEs can be found at the Wikipedia page on the topic.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
ITU-T G.8031
Ethernet Protection Switching
The G.8031 recommendation developed by ITU-T is a useful reference for understanding Ethernet Protection Switching in
the context of Carrier Ethernet networks. The document can be downloaded here.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
ITU-T G.8032
Ethernet Ring Protection Switching
The G.8032 recommendation developed by ITU-T is a useful reference for understanding Ethernet Ring Protection
Switching in the context of Carrier Ethernet networks. The document can be downloaded here.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
ITU-T Y.1415
Ethernet-MPLS Interworking
The Y.1415 recommendation developed by ITU-T is a useful reference for understanding Ethernet interworking with MPLS
in the context of Carrier Ethernet networks. The document can be downloaded here.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
This IETF Request For Comments (RFC) provides useful background information on the transport of Carrier Ethernet
services over MPLS networks.
Abstract:
" An Ethernet pseudowire (PW) is used to carry Ethernet/802.3 Protocol Data Units (PDUs) over an MPLS network. This
enables service providers to offer "emulated" Ethernet services over existing MPLS networks. This document specifies the
encapsulation of Ethernet/802.3 PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a
"point-to-point Ethernet" service."
More links relating to Ethernet pseudowires over MPLS can be found at the Wikipedia page on this topic.
Document download
Wikipedia
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
This IETF Request For Comments (RFC) provides useful background information on the transport of Carrier Ethernet
services over VPLS networks.
Abstract:
"Virtual Private LAN Service (VPLS), also known as Transparent LAN Service and Virtual Private Switched Network service,
is a useful Service Provider offering. The service offers a Layer 2 Virtual Private Network (VPN); however, in the case of
VPLS, the customers in the VPN are connected by a multipoint Ethernet LAN, in contrast to the usual Layer 2 VPNs, which
are point-to-point in nature. This document describes the functions required to offer VPLS, a mechanism for signaling a
VPLS, and rules for forwarding VPLS frames across a packet switched network."
More links relating to VPLS can be found at the Wikipedia page on this topic.
Document download
Wikipedia
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
This IETF Request For Comments (RFC) provides useful background information on the transport of Carrier Ethernet
services over MPLS-TP networks.
Abstract:
"This document specifies an architectural framework for the application of Multiprotocol Label Switching (MPLS) to the
construction of packet-switched transport networks. It describes a common set of protocol functions -- the MPLS
Transport Profile (MPLS- TP) -- that supports the operational models and capabilities typical of such networks, including
signaled or explicitly provisioned bidirectional connection-oriented paths, protection and restoration mechanisms,
comprehensive Operations, Administration, and Maintenance (OAM) functions, and network operation in the absence of a
dynamic control plane or IP forwarding support. Some of these functions are defined in existing MPLS specifications,
while others require extensions to existing specifications to meet the requirements of the MPLS-TP. This document
defines the subset of the MPLS-TP applicable in general and to point-to-point transport paths. The remaining subset,
applicable specifically to point-to-multipoint transport paths, is outside the scope of this document. This document is a
product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication
Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire
Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport
network as defined by the ITU-T."
More links relating to MPLS-TP can be found at the Wikipedia page on this topic.
Document download
Wikipedia
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
This IETF Request For Comments (RFC) provides useful background information on the transport of Carrier Ethernet
services over MPLS networks.
Abstract:
"The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the
construction and operation of packet-switched transport networks. This document specifies the subset of these functions
that comprises the MPLS-TP data plane: the architectural layer concerned with the encapsulation and forwarding of
packets within an MPLS-TP network. This document is a product of a joint Internet Engineering Task Force (IETF) /
International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS
Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the
capabilities and functionalities of a packet transport network.."
More links relating to MPLS-TP can be found at the Wikipedia page on this topic.
Document download
Wikipedia
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
engineering extensions (PBB-TE), Ethernet over SONET/SDH, Carrier Ethernet 2.1.1 IEEE-based transport
technologies
over MPLS VPWS, Carrier Ethernet over MPLS VPLS, Carrier Ethernet over MPLS
TP, Carrier Ethernet over OTN, and Carrier Ethernet over WDM. 2.1.1.1 Bridging
2.1.3.1 SONET/SDH
2.1.3.2 OTN
2.1.3.3 WDM
Download PDF
Download a pdf for
offline viewing.
Reference Documents
IEEE 802.1Q-2009
IEEE 802.1ad-2005
IEEE 802.1ah
IEEE 802.1Qay
ITU-T G.8031
ITU-T G.8032
ITU-T Y.1415
RFC 4448
RFC 4761
RFC 5921
RFC 5960
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
3.1.2 PON
Carrier Ethernet services are designed to be delivered over all the commonly
available packet access infrastructures deployed today including: 3.1.3 Packet Radio
3.1.4 PDH
HFC (DOCSIS)
3.1.5 Fiber
PON
Packet Radio 3.1.6 Bonded Copper
Reference Documents
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
3.1.2 PON
Reach, Rates and Triple Play
3.1.3 Packet Radio
Hybrid fiber-coaxial (HFC) is an industry term for a broadband network which
3.1.4 PDH
combines optical fiber and coaxial cable. It has been commonly employed by
3.1.5 Fiber
MSO/cable TV operators since the early 1990s.
3.1.6 Bonded Copper
The fiber optic network extends from the cable operators' master/regional 3.2 Comparisons
head-end, to a neighborhoods hub site, and finally to a fiber optic node
3.3 Examples
which serves anywhere from 25 to 2,000 homes. A master head-end will
usually have satellite dishes for reception of distant video signals as well as IP
Download PDF
aggregation routers. Some master head-ends also house telephony equipment
for providing telecommunications services to the community.
By using frequency division multiplexing, an HFC network may carry a variety Download a pdf for
offline viewing.
of services, including analog TV, digital TV (standard definition and HDTV),
VoD, telephony, and high-speed data.
Send Feedback
3.1.1.F1 - Carrier Ethernet and HFC
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
3.1.2 PON
Reach, Rates and Triple Play
3.1.3 Packet Radio
Passive Optical Networking (xPON) is a point-to-multipoint optical access
3.1.4 PDH
architecture that facilitates broadband communications between an optical
3.1.5 Fiber
line terminal (OLT) at the central office and multiple remote optical network
units (ONUs) over a purely passive optical-distribution network with a reach of 3.1.6 Bonded Copper
approximately 40 km (25 miles). PON supports from 1 to 128 users per single 3.2 Comparisons
strand of fiber. 3.3 Examples
IEEE 802.3
IEEE 802.16
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
3.1.2 PON
Reach, rates, licensed and unlicensed
3.1.3 Packet Radio
Where wireline services are not available or practical, delivering Ethernet
3.1.4 PDH
over a point-to-point wireless access network can make a previously
3.1.5 Fiber
unattainable connection practical. Also, where mobility is required, broadband
wireless services from mobile service providers may provide an effective 3.1.6 Bonded Copper
3.3 Examples
Terrestrial Microwave
A microwave link uses microwave frequencies (above 1 GHz) for line of sight Download PDF
radio communications (32 to 48 KM, 20 to 30 miles) between two directional
antennas. This is also known as point-to-point (PtP) Microwave. Microwave
link transceivers are now available with standard Ethernet interfaces that can Download a pdf for
offline viewing.
be used to deliver Carrier Ethernet services. The distance and throughput that
can be achieved is a function of frequency and antenna size. For example,
100 Mbps Fast Ethernet can be achieved reliably over 13 KM (8 miles) at 11
GHz but will perform poorly over 24 KM (15 miles) due to rain fade at that Reference Documents
frequency. 100 Mbps Fast Ethernet can be achieved reliably up to 48 KM (30
miles) at 6 GHz. MEF Reference Presentation: Access
Technologies
The use of microwave links avoids the need to install cables between
MEF White Paper: Access
communication equipment. Microwave links may be set up over licensed Technologies
frequencies (filed and protected by government agencies) or over unlicensed IEEE 802.3
frequencies (through the use of low power within unlicensed regulatory limits)
IEEE 802.16
Broadband Wireless
MEF-CECP Test Objectives
EVDO (Evolution of Existing Systems for Data Only) is a commonly available
upgraded service of cellular providers with CDMA (Code Division Multiple 3 Carrier Ethernet Access
Technologies
Access) systems. EVDO Rev. A allows for a maximum data transmission rate of
approximately 3.1 Mbps on the forward (downstream) channel. The EVDO Rev.
Send Feedback
A system uses the same reverse channel which limits the uplink data
transmission rate to approximately 1.8 Mbps. The EVDO system has an
Name:
upgraded packet data transmission control system that allows for bursty data
transmission rather than for more continuous voice data transmission.
Email:
GSM (Global System for Mobile)
Comments
GSM is the most popular standard for mobile phones in the world. Its
promoter, the GSM Association, estimates that 80% of the global mobile
market uses the standard. Release '97 of the standard added packet data
capabilities, by means of General Packet Radio Service (GPRS). The latest Send Feedback
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.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
3.1.2 PON
An alternative to SONET/SDH nor Dark Fiber facilities are used by Service
Providers that have found that an existing PDH network - consisting of 3.1.3 Packet Radio
traditional DS1/E1, DS3 and E3 standard circuits - enable the Service Provider 3.1.4 PDH
to deliver Carrier Ethernet to locations that would otherwise be unreachable. 3.1.5 Fiber
3.2 Comparisons
T1 at 1.544 Mbps and E1 at 2.048 Mbps have been the dominant access
technologies for business voice and data services for decades. From their 3.3 Examples
These lines reach nearly every business in the modern world. Ethernet can be
transported over T1 and E1 as a single link or bonded group of links allowing
Reference Documents
service providers to deliver Ethernet at rates from 1 Mbps up to 16 Mbps.
Bonding brings with it the additional benefit of resiliency - a feature
MEF Reference Presentation: Access
demanded by many enterprise customers. Because there are multiple links Technologies
involved in the access method, it is inherently protected against interruptions MEF White Paper: Access
of one or more of those links (for example, a destruction of a facility by a Technologies
backhoe or an excavator). IEEE 802.3
There are three standardized methods for delivering Carrier Ethernet over IEEE 802.16
T1/E1 lines:-
MEF-CECP Test Objectives
multilink point-to-point protocol (MLPPP)
3 Carrier Ethernet Access
GFP/VCAT Technologies
G.bond or EFM
Send Feedback
While each technology has its strengths, they all deliver comparable
performance and are available from many equipment vendors.
Name:
Ethernet over DS3/E3
Email:
Just as T1/E1 is a desirable access technology for delivering Ethernet service,
DS3 and E3 circuits provide another alternative using readily available Comments
transport technology. Using DS3 and E3 circuits and circuit bonding, the
service provider can offer Carrier Ethernet services at flexible rates from 1
Mbps 130 Mbps. Ethernet over DS3/E3 is not only used as a retail service
access technology, but is often used as a low-cost infrastructure alternative Send Feedback
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:
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
3.1.2 PON
For applications where it is available or where the bandwidth requirements
dictate it, delivering Ethernet over optical fiber is an excellent choice. With 3.1.3 Packet Radio
virtually unlimited bandwidth support, noise immunity and the ability to 3.1.4 PDH
traverse long distances, optical fiber can provide the performance for the 3.1.5 Fiber
applications of today and those envisioned for tomorrow.
3.1.6 Bonded Copper
Active Ethernet 3.2 Comparisons
One of the most common Ethernet over Fiber architectures is point-to-point, 3.3 Examples
Active fiber deployments are an excellent choice for service providers when
the customer is in an on-net building in a dense metropolitan area or in a new Download a pdf for
infrastructure build-out. Fiber optics as an access medium is also preferred offline viewing.
by the active interface hardware. Using standard optics, 2 km-150 km (1.25 IEEE 802.3
94 mile) distances can be easily be achieved. IEEE 802.16
Send Feedback
Name:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
3.1.2 PON
Ethernet in the First Mile over Copper (EFMCu) allows fast deployment of
resilient symmetrical Ethernet Access/Backhaul links over existing voice-grade 3.1.3 Packet Radio
copper infrastructure, providing a very economical alternative to fiber. There 3.1.4 PDH
are two standardized EFMCu technologies: 3.1.5 Fiber
Long reach 2BASE-TL, delivering a minimum of 2 Mbit/s and a 3.1.6 Bonded Copper
maximum of 5.69 Mbit/s over distances of at least 2700 m, using 3.2 Comparisons
standard G.SHDSL.bis technology over a single copper pair. This 3.3 Examples
bandwidth is symmetrical.
Short reach 10PASS-TS, delivering a minimum of 10 Mbit/s over Download PDF
distances of at least 750 m (2460 ft), using VDSL technology over a
single copper pair. This bandwidth is asymmetrical, where uplink
bandwidth is around 1-2 Mbps. Download a pdf for
offline viewing.
Extensions to these standard technologies developed by some equipment
vendors have enabled Service Providers to improve on the rate/reach curves
provided by standard implementations.
Reference Documents
Both EFMCu technologies support an optional aggregation or bonding of
multiple copper pairs (up to 32), providing higher bandwidth, longer reach MEF Reference Presentation: Access
and improved resiliency. The aggregate bandwidth, in excess of 100 Mbps, for Technologies
downlink traffic, offered by copper bonding solutions meet the needs of most MEF White Paper: Access
bandwidth-intensive Carrier Ethernet applications. Technologies
IEEE 802.3
IEEE 802.16
Send Feedback
Name:
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
3.1.2 PON
Benefits of HFC (DOCSIS) for Carrier Ethernet services
3.1.3 Packet Radio
HFC permits the addition of high-speed data transfer to an existing Cable TV
3.1.4 PDH
(CATV) system. It is employed by many cable television operators to provide
3.1.5 Fiber
Internet access and Business Services over their existing (HFC) infrastructure.
3.1.6 Bonded Copper
With its large coverage and available performance, HFC/DOCSIS technology is 3.2 Comparisons
a valuable asset for Cable TV/MSO providers to deliver Ethernet-based
3.3 Examples
services to the SOHO/SMB and high-speed Internet access to residential
customers.
Download PDF
Benefits of PON for Carrier Ethernet services
PONs immediate benefit is the increase in the bandwidth delivered to the Download a pdf for
residential and SME/SMB subscriber compared to legacy twisted pair offline viewing.
technologies. Other benefits of PON include:
One major benefit of using fiber optic access technology is its ability to
future-proof bandwidth and distance requirements. Fiber offers easy
scalability to meet and adapt to the increasing customer needs.
Send Feedback
Beyond its bandwidth capacity, fiber also offers additional benefits such as
being able to transmit over greater distances and its inherent immunity to
noise and interference.
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.
Each technology has different rate capabilities. Note that some offer only
limited uplink bandwidth. The following table summarizes the bandwidth per
each access technology:
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
3.1.2 PON
When investigating access technologies for a specific scenario, the following
considerations should be taken: 3.1.3 Packet Radio
3.1.4 PDH
Existance of legacy lines
3.1.5 Fiber
Availability of fiber
Required bandwidth 3.1.6 Bonded Copper
Use case 1
Download a pdf for
When planning Carrier Ethernet service for a small office/home office (SoHo) offline viewing.
that is located in a new neighborhood, it is likely that there is fiber to the
premise already available. Since this is a residential area, it is also quite
possible that HFC is in place. However, HFC has limited upload bandwidth,
which can be sufficient if the SoHo only requires access to Internet services. Reference Documents
A higher symmetrical bandwidth service would be offered via direct active
MEF Reference Presentation: Access
fiber.
Technologies
IEEE 802.3
A SoHo requires access to Internet services. This SoHo is located in an urban
location. It is likely that there is no fiber to the premise and digging fiber is IEEE 802.16
not feasible from a cost and time perspective. More probable options include
Ethernet over bonded copper, or wireless Internet access services through MEF-CECP Test Objectives
WiMAX or LTE technologies. 3 Carrier Ethernet Access
Technologies
Use case 3
Send Feedback
A remote farm requires services for enabling video delivery and weather
information. Since the requirement is for high bandwidth of 20 Mbps, the Name:
solution would be packet microwave which is ideal for remote locations. Such
rates would exclude 3G/CDMA access, leaving WiMax or Point-to-Point Email:
microwave as possible alternatives.
Comments
Case Study Ubiquitous Ethernet Services in Action
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.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
The presentation gives comprehensive overview of how Ethernet services can be delivered over various First Mile
infrastructures including HFC, PON, wireless, PDH, Fiber and bonded copper.
Download
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Abstract:
"This MEF white paper provides an overview of the various access technologies (also referred to as first-mile or last-
mile technologies) that are used to deliver MEF-compliant Carrier Ethernet services. The goal of this white paper is to
illustrate the fact that Service Providers who wish to deliver a ubiquitous Carrier Ethernet service can and should deploy
a number of available access technologies to ensure they can reach all of their business customers locations."
Download
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
IEEE 802.3-2005
Ethernet
The 802.3 standard developed by IEEE is a useful reference for understanding how Carrier Ethernet services can be
transported over IEEE-based networks. The standards document is not available directly from the MEF but may be
obtained from IEEE.
Other relevant links for Ethernet technology can be found at the Wikipedia page on the topic.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
IEEE 802.16
Air Interface for Fixed and Mobile Broadband Wireless Access Systems
The 802.16 standard developed by IEEE is a useful reference for understanding how Carrier Ethernet services can be
transported over wireless networks. The standards document is not available directly from the MEF but may be obtained
from the IEEE.
Other relevant links for wireless networks can be found at the Wikipedia page on the topic.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
3.1.2 PON
3.2 Describe the advantages of specific Carrier Ethernet Access technologies.
3.1.3 Packet Radio
3.3 Given a scenario, identify which Carrier Ethernet Access Technology will 3.1.4 PDH
meet the stated requirements.
3.1.5 Fiber
3.2 Comparisons
3.3 Examples
Download PDF
Reference Documents
IEEE 802.3
IEEE 802.16
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Download PDF
Subscriber is the organization purchasing and/or using Ethernet Services and
is also known as the end-user. The Subscriber describes the connectivity that
it requires and the traffic specifications in terms of guaranteed bandwidth
Download a pdf for
(CIR) and Excess Bandwidth (EIR). The Service Provider then offers the offline viewing.
Ethernet service(s) and provides (optionally) service performance metrics for
the guaranteed traffic.
The Service Provider is in charge of assembling and managing the UNI-to-UNI Comments
service. This includes aspects of the service such as billing, technical support,
performance monitoring and reporting to the subscriber.
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.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
EVC, OVC, UNI, ENNI and CEN (MEN) 4.1 Subscribers, Service Providers
and Operators
Definition of UNI, UNI-N and UNI-C per MEF 10.2
4.2 EVC, OVC, UNI, ENNI and CEN
(MEN)
This section describes the basic constructs and definitions of Ethernet
4.3 Service Models
services.
The User Network Interface (UNI) is the physical interface or port that is the Download PDF
demarcation between the Subscriber and the Service Provider.
The network that provides the Ethernet services is called the Carrier Ethernet Download a pdf for
Network (CEN). Note that some earlier MEF specifications refer to CEN as MEN offline viewing.
(Metro Ethernet Network) The name was changed by the MEF since Carrier
Ethernet Networks can span any geography from metro through to
intercontinental and are not limited to just metro areas.
Reference Documents
MEF 10.2
The basic service model as described in MEF 10.2 is depicted below:
MEF 13
MEF 26.1
Figure 4.2.F1 - Basic Service Model per MEF 10.2 Send Feedback
[Source: MEF 10.2 Figure 1]
The UNI is the demarcation point where the Customer Edge (CE) connects to Name:
the network.
Email:
The functionality of UNI-C (UNI Customer side) is located on the Subscriber
site whereas the functionality of UNI-N (UNI Network side) is located on the Comments
Service Provider site closest to that of the Subscriber.
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.
1. UNI Type 1: Defined by MEF 11. This is a basic UNI with manual
configuration of UNI-N and UNI-C.
UNI type 2 is further divided into UNI type 2.1 and UNI type 2.2.
Mandatory Features
Optional Features
Link OAM
Protection
E-LMI
Mandatory Features
Definition of 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)
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
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.
The UNI is the demarcation point between the Subscriber and the Service
Provider.
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 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 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:
The OVC connects OVC end points which can reside at External Interfaces (UNI
or ENNI) OVCs are the building blocks for creating EVCs in multi-CEN
scenarios. OVCs provide separation between different services supported for
an SP by the Operator. It also provides the preservation of S-tag and C-tag
where required.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
MEF 13
MEF 26.1
The Operator may have only limited knowledge of the UNI-to-UNI service, or Send Feedback
may know nothing at all about it in the case of the Operator that provides
transit CENs for several services. Name:
Note that the Service Provider may well also be an Operator of a CEN. In such
Email:
cases, the Service Provider/Operator contacts another CEN operator in order
to extend the Service Provider's reach to locations outside the Service Comments
Provider's coverage areas ('offnet coverage')
The Service Provider may be a virtual entity that stitches together Ethernet
services out of services the Service Provider buys from several CEN operators. Send Feedback
"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."
However, frames exchanged between the CE and the CEN's edge device
attached to it for the management of the UNI link (e.g. LACP, Link OAM) are
NOT service frames.
Service Frames are in the format defined by IEEE 802.3-2005 (except for
allowing larger frames like Jumbo frames). The Service Frame consists of the
first bit of the Destination MAC Address through the last bit of the Frame
Check Sequence.
MEF 26 defines the term ENNI Frame as any Ethernet (per IEEE 802.3-2005)
frame exchanged between two CEN Operators across an ENNI interface.
Note that ENNI Frame could be a service frame or could be an OAM frame of
the ENNI link.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
MEF 10.2
Ethernet Services Attributes Phase 2
MEF 10.2 is a specification document developed by the Technical Committee of the MEF that specifies the service
attributes of E-Line, E-LAN and E-Tree.
Abstract:
"The attributes of Ethernet Services observable at a User Network Interface (UNI) and from User Network Interface to
User Network Interface (UNI to UNI) are defined. In addition, a framework for defining specific instances of Ethernet
Services is described. This document supersedes and replaces MEF 10 [7]."
Download
Reference Presentation
The MEF has prepared an overview presentation which explains the MEF 10.2 specification.
Download
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
MEF 13
User Network Interface (UNI) Type 1 Implementation Agreement
MEF 13 is a specification document developed by the Technical Committee of the MEF that provides an Implementation
Agreement for UNI Type 1.
Abstract:
"This document specifies an implementation agreement for MEF User to Network Interface (UNI) Type 1. The main
objective of this version is to specify the MEF UNI characteristics and operation in manual configuration mode. This
allows existing Ethernet devices (switch, router, workstation, etc) acting as CEs to be instantly compliant to this IA with
no additional software or hardware upgrades. The main functionality of this version is to allow data-plane Ethernet
connectivity between the UNI-C and UNI-N. This document references MEF UNI Requirements and Framework [4] for all
concepts, constructs and terminology. The UNI Type 1 mode provides bare minimum data-plane connectivity services with
no control-plane or management-plane capabilities."
Download
Reference Presentation
The MEF has prepared an overview presentation which explains the MEF 13 Implementation Agreement.
Download
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
MEF 26.1
Metro Ethernet Services Definitions Phase 2
Specification
MEF 26.1 is a specification document developed by the Technical Committee of the MEF that defines the External Network
Network Interface (ENNI)
Abstract:
"The Metro Ethernet Network Architecture Framework specifies a reference point that is the in- terface between two
Metro Ethernet Networks (MENs), where each Operator MEN is under the control of a distinct administrative authority.
This reference point is termed the External Network Network Interface or ENNI.1 The ENNI is intended to support the
extension of Ethernet services across multiple Operator MENs. This Technical Specification specifies:
The requirements at the ENNI reference point as well as the interface functionality in sufficient detail to ensure
interoperability between two Operator MENs in- cluding Link OAM.
The connectivity attributes UNI to UNI, UNI to ENNI, and ENNI to ENNI such that multiple Operator MENs can be
interconnected and the Ethernet services and attributes in MEF 6.1 [9] and MEF 10.2 [5] can be realized."
Download
Reference Presentation
The MEF has prepared an overview presentation which explains the MEF 26.1 specification.
Download
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Reference Documents
MEF 10.2
MEF 13
MEF 26.1
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
5.9
Download PDF
Reference Documents
MEF 6.1
MEF 10.2
MEF 13
MEF 20
MEF 26.1
IEEE 802.1AX
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
In this Section
Attributes of Carrier Ethernet Services
5 Attributes of Carrier Ethernet
Services
Study Guide Section 5.2 5.1
UNI Service Attributes 5.2 UNI Attributes
This topic area describes the various UNI service attributes as specified in 5.3 EVC per UNI Attributes
5.9
Download PDF
Reference Documents
MEF 6.1
MEF 10.2
MEF 13
Table 5.2.T1 - UNI Service Attributes
[Source: MEF 6.1, Table 3] MEF 20
MEF 26.1
Essentially, all PHYs defined by IEEE 802.3-2005 are supported with the
Name:
exceptions of 1000BASE-PX-D and 1000BASE-PX-U, since Link OAM is not
supported for these PHYs. Email:
UNI Type 1 supports only a sub-set of the list. Please refer to MEF 13 for Comments
details.
UNI Type 2 (MEF 20) added almost all of the PHYs defined in IEEE 802.3
excluding 1000BASE-PX-D and 1000BASE-PX-U (xPON). 1000BASE-PX-D and Send Feedback
1000BASE-PX-U were excluded since Link OAM (which is mandatory for UNI
Type 2) is not supported on these PHYs.
The UNI MTU (Maximum Transmission Unit) Size service attribute specifies the
maximum Service Frame size (in bytes) allowed at the UNI. The UNI MTU Size
MUST be specified to have a value greater than or equal to 1522. When a
frame larger than the UNI MTU Size arrives at the UNI, it must be dropped. An
MTU size of 1522 bytes allows for a C-tagged frame of maximum frame size,
as defined by IEEE 802.3-2005.
Note that the maximal size of an untagged frame according to IEEE 802.3-
2005 is 1518 bytes.
However, MEF recognizes that a larger frame may be needed for the purposes
of encapsulation and tunneling. Furthermore, it allows the support of Jumbo
frames by setting a large value (e.g 9300 bytes).
The UNI MTU Size (and the EVC MTU Size) is a key service attribute. Some
service Providers do offer a larger MTU size for their subscribers. For
example, when using FCoE (Fiber-Channel over Ethernet) the MTU size would
need to be set to slightly above 2,048 bytes.
Note that some switches may drop any frame that is larger than the MTU
configured on their interface. This is acceptable behavior, as such a frame
can be passed. However, if the frame is dropped, it is not counted against the
Frame Loss Ratio performance attribute.
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.
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.
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.
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:
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.
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:
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.
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.
Layer 2 Control Protocols (L2CP) are various Ethernet control protocols such as
Spanning Tree BPDUs, LACP, PAUSE Frames, etc.
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 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.
MEF 6.1.1 lists L2CP Protocols and Associated Ethertypes and Subtypes as
shown in the table below:
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:
Note that while MEF 6.1 included requirements for All Bridges, the All LANs
Bridge Management Group Address (01-80-C2-00-00-10) has been officially
deprecated in 802.1Q-2005, sub-clause 8.13.7. In the unlikely event that a
Subscriber uses this MAC Destination Address, MEF services are expected to
treat them as Data Service Frames.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
The map defines which value(s) of CE-VLAN ID are mapped to each of the
Download PDF
EVCs.
Each CE-VLAN ID can be mapped to at most one EVC. The CE-VLAN ID / EVC
map is the basis for service identification, which is relevant for all virtual Download a pdf for
offline viewing.
services (In private services, all CE-VLAN IDs are mapped to the single EVC)
The creation of the map depends on whether the CE-VLAN IDs are actual
VLANs of the Subscriber's LANs, or are only added by the Customer Equipment
in order to map to the appropriate EVC to the ingress service with which the
Reference Documents
frame is associated.
MEF 6.1
Note that the map can vary between UNIs associated with the same EVC. This
can happen when CE-VLAN IDs are not preserved, and instead are translated MEF 10.2
by the Service Provider. MEF 13
MEF 20
More than one CE-VLAN ID can be mapped to an EVC only if Bundling is set to
Yes at that UNI. MEF 26.1
IEEE 802.1AX
Any value of CE-VLAN ID not assigned to an EVC at a UNI must be dropped.
IEEE 802.3 clause 43
Send Feedback
Figure 5.3.F1 - Mapping CE-VLAN IDs to EVCs
[Source: MEF 10.2, Figure 9] Name:
Comments
Send Feedback
In this example the UNI attribute CE-VLAN ID for untagged and priority tagged
Service Frames is set to 17
Another example:
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
5.9
Note that Private/Virtual is deduced by the UNI attributes.
5.10 EVC Performance Attributes
An arbitrary string - unique across the CEN - for the EVC supporting the
service instance. Download a pdf for
offline viewing.
UNI List
The UNI List for an EVC is a list of pairs of the form <UNI Identifier, UNI
Reference Documents
Type>. One pair per UNI is associated with a particular EVC. UNI Type can be
Root or Leaf. For EVC types of Point-to-Point or Multipoint-to-Multipoint, it
MEF 6.1
must be Root.
MEF 10.2
MEF 13
MEF 26.1
Any integer 2 is allowed. It must be 2 for Point-to-Point EVC.
IEEE 802.1AX
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:
Delivery rule can be one of three. Note, however, that frames with invalid
FCS (CRC) MUST be dropped.
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.
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.
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.
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.
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.
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.
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
A CoS ID may include several priorities, but these are treated as one CoS by
the CEN.
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:
L2CP Any L2CP protocol that is tunneled through this EVC can be set to a
different defined CoS ID. For example, the three-CoS model specified in MEF
23 suggest the following mapping: High PCP 5 Medium PCP 2, 3 Low PCP
0, 1 (note: this includes untagged frames as they are mapped together with
priority tagged frames). PCP 6 and 7 can be mapped to another, non-standard
CoS ID.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Download PDF
Reference Documents
MEF 6.1
MEF 10.2
Figure 5.4.1.F1 - L2CP Handling Logic (Source MEF 6.1.1 figure A)
MEF 13
MEF 20
STEP 1 MEF 26.1
IEEE 802.1AX
Step 1 in the handling logic means that depending on the service type,
specific MAC DA's must be tunneled through the EVC. IEEE 802.3 clause 43
For private services - EPL (non-transparent option), EP-LAN and EP-Tree - MEF-CECP Test Objectives
which are delivered over a packet-aware network (e.g. IEEE 802.1 or MPLS
5 Key UNI, ENNI, OVC, and EVC
based) the following table applies:
Service Attributes
Send Feedback
Name:
Email:
Figure 5.4.1.T1 - L2CP Handling for Private Service
Comments
For virtual services - EVPL, EVP-LAN, EVP-Tree - the rule is:
For 01-80-C2-00-00-01 through 01-80-C2-00-00-0F Must not Tunnel (Go to Step
2)
Send Feedback
STEP 2
For each service type, there is a specific table stating whether to Peer or
Discard the frame
Private Services
Here, the processing rules for the private services are described.
Note that the rules are similar to the ones for EPL with the following changes:
Virtual Services
The same rules apply for all 3 virtual service types as shown in the table
below:
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:
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Download PDF
Each link in an ENNI MUST be one of the following physical layers in full Download a pdf for
duplex mode as defined in IEEE Std 802.3 2005 : 1000Base-SX, 1000Base-LX, offline viewing.
1000Base T, 10GBASE-SR, 10GBASE-LX4, 10GBASE-LR, 10GBASE-ER, 10GBASE-
SW, 10GBASE-LW, 10GBASE-EW. Note that the physical layer at one ENNI
supported by the Operator CEN can be different than the physical layer at
Reference Documents
another ENNI supported by the Operator CEN.
Each ENNI Frame MUST have the standard Ethernet format with one of the tag MEF 6.1
configurations specified in the table below. [DA = Destination Address, SA = MEF 10.2
Source Address, ET = Ethertype/Length, S-Tag with Tag Protocol Identification MEF 13
Field (TPID) = 0x88A8, C-Tag with TPID = 0x8100.]
MEF 20
MEF 26.1
IEEE 802.1AX
Comments
ENNI Resiliency
The Protection Mechanism defines the resiliency scheme at the ENNI. There
Send Feedback
are 3 alternatives:
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.
An upper bound to the number of OVC end points that can be associated with
an OVC at this ENNI. If set to 1, then Hairpin Switching cannot be supported
at the ENNI, as it requires 2 OVC end points.
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:
1. When the ingress frame has S-VLAN ID that is NOT in the map, it must
not be forwarded.
2. An S-VLAN ID value cannot appear more than once in the table.
3. Ingress frame with no S-Tag must not be mapped to OVC end point.
When the ingress frame has S-VLAN ID that is NOT in the map, it must not be
forwarded. An S-VLAN ID value cannot appear more than once.
End-Point Bundling
When multiple S-VLAN ID values are mapped to a single OVC end point, the
End Point map is said to have Bundling. Remember that this is quite similar to
UNI bundling of CE-VLAN IDs. When Bundling is set, S-VLAN ID Preservation
and CE-VLAN ID Preservation MUST be Yes. Bundling is useful when multiple
EVCs are tunneled via a single OVC transit tunnel. In such a case, different
EVCs may use the same MAC address ranges and the Operator should provision
for such a scenario.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
A string of at most 45 bytes that uniquely identifies the OVC within a given 5.5 ENNI Attributes
A list of OVC End Point Identifiers. The Maximum Number of ENNI OVC End
MEF-CECP Test Objectives
Points is the upper bound on the number of OVC End Points that are at an
ENNI that can be associated by an OVC. This must be an integer greater or 5 Key UNI, ENNI, OVC, and EVC
Service Attributes
equal to 1.
Send Feedback
the ENNI MTU size. When an ENNI frame is larger than the OVC MTU that is Comments
mapped to an OVC, then the frame must be discarded. It may or may not
consume tokens from the ingress BWP.
Note that when an EVC that spans multiple CENs is set with a specific MTU
Send Feedback
size, then each OVC that is part of the EVC should have its MTU set to at
least the MTU size of the EVC.
CE-VLAN ID preservation
(*) 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.
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:
Color forwarding
Frame Delivery
Similar to EVCs, OVCs also have three attributes to govern frame delivery
rules. These are:
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.
In some E-LAN scenarios, the SP may want to limit the consumed bandwidth
over an OVC (for example tunnel to a UNI) and thus would like to avoid
flooding for unknown addresses.
SLS
The Service Level Specification (SLS) consists of definitions of delivery
performance attributes for frames between External Interfaces, e.g. delay,
loss. For each performance attribute, the SLS also contains a quantitative
objective. When the frame delivery performance level meets or exceeds the
objective for each performance attribute, the SLS is said to be met. The SLS
that applies to a given ENNI or Service Frame is based on the Class of Service
Identifier for the frame. When an ENNI Frame is not sufficiently compliant
with an ingress Bandwidth Profile that applies to it, the SLS does not apply to
the frame. Details of ENNI and OVC SLS are expected in future versions of MEF
26.x or MEF 23.x.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
ENNI (Service Provider CEN - Operator CEN) towards a different UNI attached 5.9
to the Operator CEN. In this example, the Service Provider CEN provides the 5.10 EVC Performance Attributes
switching capability between the Operator's two UNIs facing the Subscriber.
Download PDF
Note that hairpin switching cannot occur at a UNI.
Reference Documents
MEF 6.1
IEEE 802.1AX
The figure below shows an example of the use of OVC End Points for Hairpin
IEEE 802.3 clause 43
Switching. In this example, there is one multipoint EVC that associates UNI
Aa, UNI Ab, and UNI B. Operator A has two OVCs. One associates the OVC End
MEF-CECP Test Objectives
Point A4 at UNI Aa and the OVC End Point A1 at the ENNI. The other OVC
associates the OVC End Point A3 at UNI Ab and the OVC End Point A2 at the 5 Key UNI, ENNI, OVC, and EVC
Service Attributes
ENNI. Operator B has one OVC that associates the OVC End Points B1 and B2
at the ENNI and the OVC End Point B3 at UNI B. At the ENNI, the End Point
Send Feedback
Maps are such that ENNI frames mapped to A1 by Operator A are mapped to
B1 by Operator B and similarly for A2 and B2. With this configuration, a
Name:
Service Frame sent from UNI Aa to UNI Ab will pass through the Operator B
MEN where it will be hairpin switched from B1 to B2. Likewise, a similar path
Email:
will be followed by a Service Frame sent from UNI Ab to UNI Aa.
Comments
Send Feedback
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:
Word of caution:
Improper use of hairpin switching can result in a data loop between two
Operator CENs at a single ENNI. It is up to the Service Provider and Operators
to ensure that such loops do not occur.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
A Class of Service Identifier is a set of one or more S-Tag PCP values. Each 5.8 Bandwidth Profiles
Class of Service Identifier indicates a single Class of Service instance. The Class 5.9
of Service that applies to an ingress S-Tagged ENNI Frame that is mapped to 5.10 EVC Performance Attributes
the OVC End Point is the Class of Service identified by the Class of Service
Identifier that contains the S-Tag PCP value in the frame. For example, the S- Download PDF
Tag PCP values 0, 1, 2, and 3 could constitute a Class of Service Identifier that
indicates the silver service while the S-Tag PCP values 4, 5, 6, and 7 could
constitute a different Class of Service Identifier that indicates the gold Download a pdf for
service. In this example, an S-Tagged ENNI Frame with S-Tag PCP value = 3 offline viewing.
would be given the silver service. Note that in case of S-tag bundling, the map
is independent of the S-VLAN ID. The following rules apply:
Each PCP value must be mapped to exactly one COS ID Reference Documents
One CoS ID can be set to 100% discard
CoS ID can have different maps between different OVC end points, as MEF 6.1
long as they are associated with different OVCs MEF 10.2
Frame color can be marked in one of two methods: DEI bit or S-tag PCP MEF 13
values. According to MEF 23, the following values are recommended for a 3 MEF 20
CoS model: MEF 26.1
IEEE 802.1AX
For green color or when color is marked using DEI bit:
IEEE 802.3 clause 43
For yellow color or when color is marked using PCP bits: Name:
Email:
Comments
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.
Ingress BWP per OVC End Point enables similar BWP as for Ingress BWP per
UNI. It can be used for example to enforce a rate limit into the network over
an external interface.
The following figure depicts ingress BWP per OVC end point:
Figure 5.7.F1 Bandwidth Profile per OVC
Each Ingress BWP must include suitable parameters <CIR, CBS, EIR, EBS, CF,
CM>. CM must be set to color aware.
Egress BWP
An Egress Bandwidth Profile (BWP) can be applied per OVC end point or per
CoS ID per OVC End point per ENNI.
Each Egress BWP must include suitable parameters <CIR, CBS, EIR, EBS, CF,
CM>.
CM must be set to color aware. This is the only change compared to MEF 10.2
definitions for Egress BWP at the UNI. The Egress Bandwidth Profile per OVC
End Point at a UNI describes egress policing by the Operator CEN on all egress
Service Frames mapped to a given OVC End Point at a UNI.
Note that each egress ENNI frame can be subject to at most one BWP.
The Egress Bandwidth Profile per OVC End Point describes egress policing by
the Operator on all egress ENNI Frames that are mapped to a given OVC End
Point.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Red Frames not conforming to the BWP are dropped, either because
the rate exceeds the sum of CIR and EIR, or because there are
insufficient yellow tokens to admit a frame that is within EIR/EBS .
Reference Documents
There are two types of bandwidth profiles:
MEF 6.1
Ingress Bandwidth Profile limits the rates of frames entering the MEF 10.2
CEN.
MEF 13
Egress Bandwidth Profile limits the rate of frames egressing the CEN
and thus protecting overload towards the egress CE. MEF 20
MEF 26.1
Bandwidth Profile can be applied in three forms:
IEEE 802.1AX
However, the algorithm is the same for all three forms. 5 Key UNI, ENNI, OVC, and EVC
Service Attributes
At a given UNI, at most one ingress BWP can be applied and at most one
egress BWP can be applied to a given service frame. This means that one Send Feedback
cannot define an ingress BWP per UNI in addition to an ingress BWP per EVC.
Name:
The three BWP forms are illustrated below:
Email:
Comments
Send Feedback
Figure 5.8.F1 - Ingress Bandwidth Profile Per Ingress UNI
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.
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 Algorithm
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.
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.
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.
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
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
Now two ingress BWPs should be set - one per each CoS ID
Consider EVP-LAN service servicing 10 UNIs If the SP would like to ensure that
the UNI link is not flooded, it should set the egress BWP to the desired rate.
Note that in such a case, coloring the frame may not be meaningful, so CIR=0,
CBS=0 and EIR=desired rate with some reasonable EBS is the suggested
solution.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
5.9
Download PDF
Reference Documents
MEF 6.1
MEF 10.2
MEF 13
MEF 20
MEF 26.1
IEEE 802.1AX
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
The Performance attributes are per CoS ID. They must be specified for at 5.7 OVC End Point per ENNI
Attributes
least one CoS ID, but some of the attributes can be set to N/S (Not
specified). 5.8 Bandwidth Profiles
5.9
In general, all service performance attributes are measured during some time
5.10 EVC Performance Attributes
interval T (e.g. 5 minutes, 2 hours, etc.).
For E-Line, there are 2 ordered pairs (UNI1, UNI2) and (UNI2, UNI1).
Download a pdf for
For E-LAN and E-Tree, measurement can be performed on any sub-set of the offline viewing.
ordered pairs.
For E-Tree, each pair must include at least one root UNI.
Reference Documents
Frames are counted against the performance attribute only if they meet all
the following criteria:
MEF 6.1
The egress frame results from an ingress frame where both UNIs MEF 10.2
(ingress and egress) belong to the ordered set. MEF 13
The first bit of the frame must arrive to the egress UNI during the
MEF 20
time interval T.
MEF 26.1
The ingress BWP had compliance level of green.
IEEE 802.1AX
Note that Unicast, Multicast, Broadcast and L2CP frames can all be used for
IEEE 802.3 clause 43
performance measurement.
Email:
Comments
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.
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:
This performance attribute is not Jitter which has a different definition and is
not appropriate for packet-based services.
The difference in the arrival times of the first bit of each Service
Frame at the ingress UNI was exactly D t.
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.
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.
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.
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
For Multipoint EVC, the Availability is calculated as the maximum value over
all ordered pairs belonging to the sub-set of all possible ordered pairs.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
MEF 20
User Network Interface (UNI) Type 2 Implementation Agreement
MEF 20 is a specification document developed by the Technical Committee of the MEF that provides an Implementation
Agreement for UNI Type 2.
Abstract:
"This document specifies an Implementation Agreement (IA) for MEF User to Network Interface (UNI) Type 2. This
Implementation Agreement adds new functionalities to MEF UNI Type 1 [MEF13], such as E-LMI based on [MEF16], Link
OAM based on clause 57 of [IEEE 802.3], Service OAM based on [ITU-T Y.1731] and [IEEE 802.1ag] and Protection using
Link Aggregation based on clause 43 of [IEEE 802.3].."
Download
Reference Presentation
The MEF has prepared an overview presentation which explains the MEF 20 Implementation Agreement.
Download
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
IEEE 802.1AX-2008
Link Aggregation
The 802.1AX-2008 standard developed by IEEE is a useful reference for understanding the topic of Link Aggregation in the
context of Carrier Ethernet networks. The standards document is not available directly from the MEF but may be obtained
from IEEE.
Other relevant links for Link Aggregation can be found at the Wikipedia page on the topic.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
The 802.3 standard (clause 43) developed by IEEE is a useful reference for understanding Ethernet Link Aggregation in the
context of Carrier Ethernet. The standards document is not available directly from the MEF but may be obtained from
IEEE.
Other relevant links for Ethernet Link Aggregation technology can be found at the Wikipedia page on the topic.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
5.7 Define and describe the components of a Service Level Specification and
the relationship to Service Level Agreement. Download PDF
5.8 Define and describe ENNI attributes (e.g., physical interfaces, Frame
format, Ingress/egress Bandwidth Profiles, End Point Map, ENNI protection). Download a pdf for
offline viewing.
5.9 Define and describe OVC attributes (e.g., CE-VLAN ID Preservation, CoS ID
Preservation, Relationship between Service Level Agreement and Service Level
Specification, Class of Service, hairpin switching).
Reference Documents
5.10 Define and describe the Carrier Ethernet protection mechanisms.
MEF 6.1
MEF 10.2
MEF 13
MEF 20
MEF 26.1
IEEE 802.1AX
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
The purpose of these three certification programs is to provide the 6.2 Definitions, IAs, ATSs, Test
Plans
Subscribers, Service Providers and Operators with a neutral reference point for
compliance with and knowledge of Carrier Ethernet specifications. 6.3 Testing and Certification Process
Services RFPs need to be less complex. MEF certification (e.g. MEF 9 and MEF Name:
14) in an RFP replace longform descriptions of Subscriber requirements.
Email:
Services certification also streamlines the interconnection services between
different Service Providers and Operators. Comments
As of March 2012, there are over 60 Service Providers around the world that
have demonstrated their commitment to Carrier Ethernet standardization
through MEF certification of their services. Similarly, more than 80 Equipment
Vendors with products certified as supporting Carrier Ethernet services in
compliance with MEF specifications.
The names of these certified Service Providers and Equipment Vendors can be
found at the MEF Certification Registry together with the respective serviecs
and products.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Definitions, Implementation Agreements, Abstract Test Suites and Plans 6.2 Definitions, IAs, ATSs, Test
Plans
The MEF produces three types of technical documents: 6.3 Testing and Certification Process
The IA typically quantify specific parameters and attributes called out in the
TS so that consistent, interoperable implementation can occur. The IA is
mainly used to define interfaces and system behavior. Examples of IAs include Reference Documents
MEF 20 and MEF 23.
The ATS comprises a series of tests to be used to measure conformance to 6 MEF Certification
specific MEF specifications - which can be Technical Specifications or
Implementation Agreements. The purpose of the ATS is to form the basis of Send Feedback
test plans such as those used in the MEF Certification Programs. Examples of
ATSs include MEF 9, MEF 14 and MEF 18 Name:
Test Plan
Email:
The MEF Certification Test Lab uses one or more ATSs to create a separate
Comments
Test Plan where each set of tests in the plan are based on specific test cases
in the ATS. In some cases, there will be a reference to the source TS or IA
that specified the requirement or capability that is being verified. A MEF
member that schedules certification of a service or device by the MEF Send Feedback
Certification Test Lab will receive the Test Plan as part of the preparation
process before undertaking the certification test.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
An Equipment Vendor can apply to have a service or device certified by the 6.4 Certification for SPs
MEF Certification Test Lab if it is a MEF member in good standing. The MEF 6.5 Certification for Vendors
member approaches the MEF approved test lab (Iometrix) at
certification@iometrix.com for more information on pricing and scheduling. Download PDF
The testing and certification process takes place directly between the MEF
member and Iometrix. The MEF's responsibility is to develop the underlying
Technical Specifications, Implementation Agreements, Abstract Test Suites Download a pdf for
and to approve the Test Plan developed by Iometrix. offline viewing.
Test plans, configuration guides and engineering support are made available Reference Documents
by Iometrix to Equipment Vendors at all stages of the vendor's preparation for
certification testing.
MEF-CECP Test Objectives
Testing takes place at the Iometrix facilities in San Francisco, California or
6 MEF Certification
under special arrangement at the vendor's facilities. Tests are typicall
scheduled at least one month in advance for a one week period at mutually
agreed dates. Send Feedback
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.
The number of sites selected for the service testing depends on the Carrier
Ethernet service. For EPL services, two sites are selected. For EVPL and E-LAN
services, three sites are selected. The sites selected will be readily accessbile
central offices distributed across the service coverage areas: Metro, regional
or national for domestic services; transnational, continental and
transcontinental for international services.
Tests are performed remotely from the Iometrix test control center using
probes supplied by Iometrix and installed by the Service Provider at each site
with a remote access connection. The IRU, AC powered probes are equipped
to test multiple services simultaneously and are attached to the Subscriber
side of the UNIs to verify end-to-end service delivery.
The time to complete a full cycle of MEF 9 and MEF 14 tests is typically two
weeks exclusive of service provisioning and troubleshooting.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Service provider members of the MEF seeking to certify one or more of their 6.4 Certification for SPs
EPL, EVPL and E-LAN services as conforming to MEF 9, MEF 14 and/or MEF 18 6.5 Certification for Vendors
specifications within the Carrier Ethernet 1.0 generations framework can apply
to the MEF Certification Test Lab (Iometrix) to schedule and prepare for Download PDF
independent, streamlined testing of their service(s).
The testing and certification in Carrier Ethernet 1.0 (MEF 9 and MEF 14) is
Download a pdf for
based on a 'Certification by ATS' model. This means that a single ATS is used offline viewing.
as the basis for each certification. MEF 9 is the Abstract Test Suite used as
the basis of the test plan for conformance to EPL, EVPL and E-LAN functional
specifications. MEF 14 is the Abstract Test Suite used as the basis of the test
plan for conformance to performance specifications for EPL, EVPL and E-LAN. Reference Documents
To date, over 60 Service Providers have certified well over 200 Carrier
Ethernet services as conforming with MEF 9 and/or MEF 14. MEF-CECP Test Objectives
6 MEF Certification
Carrier Ethernet 2.0 (E-Line, E-LAN, E-Tree and E-Access)
Carrier Ethernet 2.0 Certification becomes available in 2012. This 2.0 Send Feedback
certification transitions the industry from 'Certification by ATS' to
'Certification by Service'. Instead of certifying a service as conforming to a Name:
particular MEF ATS, the certification verifies that the service conforms to the
Email:
relevant sections of a range of Abstract Test Suites as described in the Carrier
Ethernet 2.0 Certification Blueprint.
Comments
Key Words
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Equipment vendor members of the MEF seeking to certify one or more of their 6.4 Certification for SPs
equipment products as conforming to MEF 9, MEF 14 and/or MEF 18 6.5 Certification for Vendors
specifications within the Carrier Ethernet 1.0 generations framework can apply
to the MEF Certification Test Lab (Iometrix) to schedule and prepare for Download PDF
independent, streamlined testing of their product(s).
The testing and certification in Carrier Ethernet 1.0 (MEF 9, MEF 14 and MEF
Download a pdf for
18) is based on a 'Certification by ATS' model. This means that a single ATS is offline viewing.
used as the basis for each certification. MEF 9 is the Abstract Test Suite used
as the basis of the test plan for conformance to EPL, EVPL and E-LAN
functional specifications. MEF 14 is the Abstract Test Suite used as the basis
of the test plan for conformance to performance specifications for EPL, EVPL Reference Documents
and E-LAN. MEF 18 is the Abstract Test Suite used as the basis of the test plan
for conformance to functional and performance specifications for circuit
MEF-CECP Test Objectives
emulation of TDM circuits over Carrier Ethernet networks.
6 MEF Certification
To date, over 80 Service Providers have certified nearly 1,000 Carrier Ethernet
services as conforming with MEF 9, MEF 14 and/or MEF 18.
Send Feedback
Carrier Ethernet 2.0 (E-Line, E-LAN, E-Tree and E-Access)
Name:
Carrier Ethernet 2.0 Certification becomes available in 2012. This 2.0
Email:
certification transitions the industry from 'Certification by ATS' to
'Certification by Service'. Instead of certifying a product as conforming to a
Comments
particular MEF ATS, the certification verifies that the product enables the
delivery of a service (E-Line, E-LAN, E-Tree and/or E-Access) conforming to
the relevant sections of a range of Abstract Test Suites as described in the
Carrier Ethernet 2.0 Certification Blueprint. Send Feedback
Key Words
MEF 9; MEF 14; MEF 18; ATS; E-Line; E-LAN; E-Tree; E-Access
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
6.3 Describe what is covered by MEF 9, MEF 14, and MEF 18 Certifications. 6.4 Certification for SPs
Reference Documents
6 MEF Certification
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
When connecting to the Internet, the CEN can provide the connectivity 7.6 Frame Relay/ATM Replacement
required to the ISP's POP facilitating any required bandwidth with the 7.7 WDM Private Network
granularity, manageability and service performance supported by Carrier Replacement
Ethernet. Likewise, when a subscriber wants to connect to an application such
as a VoIP gateway, this too can be delivered over Carrier Ethernet. One of the Download PDF
benefits to the Subscribers is that the same CEN Service Provider that provides
services for corporate interconnectivity can also provide the Internet
connectivity. Download a pdf for
offline viewing.
There are two Ethernet services that are appropriate for this application:
MEF 8
The EVPL is simpler from an implementation point of view, but has scalability
issues, requiring many EVPLs. Also, the bandwidth is not shared between MEF 10.2
subscribers, which may be a problem for large deployments in view of the MEF 26.1
fact that Internet access is often bursty and used at different times of the MEF 28
day by different subscribers.
MEF Reference Presentation: Access
Technologies
In the following example an ISP named Turbo 2000 Internet Access Inc. is
MEF Reference Presentation: Mobile
connected to three enterprises for Internet Access. Each customer connects to
Backhaul
the ISP's POP using EVPL with CE-VLAN ID of 2000. This enables the customer
MEF White Paper: CESoE
to use the same UNI port for other services (e.g. Disaster Recovery, L2VPN,
etc.) using different CE-VLAN ID(s).
MEF-CECP Test Objectives
Send Feedback
Name:
Figure 7.1.F1: Example - Turbo 2000 Internet Access, Inc.
Email:
In this example, assume that Customer 1 has purchased a 300 Mbps downlink
service and 100 Mbps uplink service for connecting to the ISP over an Comments
unprotected UNI that will be used for another service too. The service has a
single CoS, with the following performance objectives measured over a 1 hour
period:
Send Feedback
The appropriate EVC attributes for the EVPL connecting Customer 1 to the ISP
POP are:
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
The UTA service is very transparent. The Access SP provides a transparent EPL
with no service awareness. At the VUNI, the incoming service frames are Reference Documents
mapped to different EVCs based on the UNI CE-VLAN ID/EVC map.
MEF 6.1
The following figure illustrates this service set-up:
MEF 8
MEF 10.2
MEF 26.1
MEF 28
Comments
Send Feedback
Figure 7.2.F3
The UTA OVC End Point attributes at the RUNI have some additional
constraints which are described in the following table:
Table 7.2.T1
The UTA OVC attributes have some additional constraints which are described
in the following table:
Table 7.2.T2
The ENNI has only a single additional constraint: At an ENNI in the VUNI
Provider CEN, the End Point Type within an End Point Map for ENNI frames
mapped to a VUNI must the value of VUNI
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Figure: 7.3.F1
[Source: MEF 22, Figure 1] MEF-CECP Test Objectives
More complex scenarios involving multiple CEN domains are possible. Note 7 Target Applications for Carrier
Ethernet Services
that the CEN SP provides a service to a mobile operator and not to end users
(mobile users).
Send Feedback
For a GSM network with 3G and 3.5G (known as HSPA) technology, each NodeB
is connected to a single RNC location, which may encompass several co- Name:
located RNCs. NodeBs do not communicate directly one with the other (note
that in LTE this is no longer the case). Therefore, there are two suitable Email:
Carrier Ethernet services:
Comments
Figure: 7.3.F2
[Source: MEF 22, Figure 8]
Figure: 7.3.F3
[Source: MEF 22, Figure 11]
The mobile network has several classes of service for different applications
that use the network. The following table describes MEF 22 recommended
mapping between the 3GPP classes and the CEN CoSs:
Table: 7.3.T1
[Source: MEF 22, Table 2]
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Download PDF
The solution is implemented by implementing a CESoETH service between the MEF 6.1
two locations. MEF 8
MEF 10.2
MEF 26.1
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Reference Documents
MEF 28
The need for more bandwidth at a lower price, and with a more sophisticated
MEF Reference Presentation: Access
and dynamic service provisioning, presents the opportunity for a Carrier Technologies
Ethernet Service Provider to offer a very attractive alternative.
MEF Reference Presentation: Mobile
Backhaul
The customer can buy one of the following two services and replace the
current Network Edge with a switch/Customer Edge: MEF White Paper: CESoE
1. 3 EVPLs, each having ingress BWP per EVC with CIR=2 Mbps, CBS=20 MEF-CECP Test Objectives
Kbytes and possibly also allowing for some additional traffic using EIR=2
7 Target Applications for Carrier
Mbps, EBS=20 Kbytes Ethernet Services
2. Single EVP-LAN with ingress BWP of 4 Mbps CIR. The choice of EVP-LAN
enables the enterprise to consider buying additional services like Send Feedback
Internet access. For this reason, the Service Provider facilitates the
addition of new Carrier Ethernet services over the same UNI. Name:
The first alternative is depicted below, where a site requires a single UNI port
Email:
for the 2 EVPLs:
Comments
Send Feedback
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:
All other CE-VLAN IDs are not expected and therefore will be dropped.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
UNI-N and at the RAN BS UNI-N to the EVC connecting the RAN BS and 7.6 Frame Relay/ATM Replacement
RAN NC. This implies that each RAN NC UNI can distinguish up to four 7.7 WDM Private Network
thousand distinct RAN BSs. Replacement
At the RAN NC side, the CE-VLAN ID assignment is performed at the
UNI-C. At the RAN BS side the CE-VLAN ID assignment can be either Download PDF
performed at the UNI-C or at the UNI-N depending on which option
(described later in this paragraph) is selected.
Bundling is disabled, which means that all traffic types are sent on Download a pdf for
offline viewing.
the same CE-VLAN ID.
Multiple Classes of Service can be supported. They are differentiated
through either PCP or DSCP marking. CoS ID is identified by
<EVC+PCP> or <EVC+DSCP>. In this use case CoS ID preservation is Reference Documents
enabled and 4 classes of service are supported.
MEF 6.1
The table below shows an example of how Carrier Ethernet services can be
delivered in the mobile backhaul according to the assumptions made for the MEF 8
present use case. MEF 10.2
MEF 26.1
MEF 28
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:
The symbol * indicates the CE-VLAN ID value used at the UNI for both
untagged and priority tagged frames.
The CoS ID Preservation attribute should be enabled for each option in order
to simplify configuration.
Note that the CoS ID per <EVC> model can also be supported by this use case
if the assumption to use a single EVP Line per RAN BS that supports multiple
services is removed. According to this new assumption each RAN BS can
support multiple EVP Lines whereby mobile traffic classes may be grouped into
different EVCs. Each EVP Line is mapped to a unique CE-VLAN ID and so each
CE-VLAN ID identifies a specific set of services between the RAN NC and a
specific RAN BS.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Send Feedback
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.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Carrier Ethernet provides scalable, efficient and easy to manage solutions for
enabling all of these services and applications. Download a pdf for
offline viewing.
For example, the following use case features a fashion retailer with over 200
store locations.
Limited bandwidth on legacy dial-up network required sending sales and stock
Reference Documents
information in batch up-loads overnight. This delayed fulfilling restocking,
resulting in the inability to quickly meet customer demand and poor MEF 6.1
utilization of resources. Security is a constant issue, but the CCTV is
MEF 8
essentially an offline and reactive service.
MEF 10.2
The goals of the project in this use case are to increase capacity, improve
MEF 26.1
network resiliency and scalability, provide the flexibility to simplify addition
MEF 28
and removal of new stores matching retail environment and reduce cost by
converging voice and data networks via VoIP and to improve security and fight MEF Reference Presentation: Access
Technologies
stock shrinkage with national central CCTV monitoring ability.
MEF Reference Presentation: Mobile
The low cost solution is based on a mixture of enabling transport technologies. Backhaul
The EP-Tree service type is implemented to ensure separation between the MEF White Paper: CESoE
divisional operations under the supervision of the corporate headquarters. This
solution is based on standardized, certified, Ethernet Business Services. MEF-CECP Test Objectives
Send Feedback
Name:
Email:
In this use case the following attributes should be set at the HQ UNI:
Figure 7.4.T1
Figure 7.4.T2
Figure 7.4.T3
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.
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.
Figure: 7.4.T4
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Download PDF
At each location, the router identifies the destination of each packet, based
on IP or MAC addresses, and forwards the packet to the correct port. Each of
these connections can be configured to, for example, 2 Gbps. For each
Reference Documents
connection there is full transparency, as the WDM network is packet unaware
and VLAN unaware. The disadvantage of this private solution is the need to MEF 6.1
install and manage the WDM links and also may not be feasible for long-haul
MEF 8
scenarios. This solution requires leasing dark fiber facilities from an Operator,
which is typically a very expensive offering, making this solution even less MEF 10.2
attractive for long-haul applications. Also, this type of solution cannot scale MEF 26.1
easily as the enterprise adds more locations. MEF 28
Carrier Ethernet offers a comparable solution where all locations are MEF Reference Presentation: Access
Technologies
connected using an EP-LAN service, which enables the relatively simple and
MEF Reference Presentation: Mobile
fast addition of new sites as the enterprise grows. It provides the same
Backhaul
transparency as a WDM network and supports any-to-any communication
MEF White Paper: CESoE
supporting new services like shared storage, video distribution etc.
Send Feedback
Name:
Example Comments
All three UNI ports will be configured to All-to-One bundling and therefore
require no VLAN configuration. Furtheremore, this service can now provide
multiple CoSs, each with its own bandwidth profile and performance
Send Feedback
requirements. In order to facilitate the legacy service example of 2 Gbps
between each 2 locations, the following bandwidth profile can be set:
CIR = 4 Gbps
CBS = 1 Mbytes
CIR = 4 Gbps
CBS = 1 Mbytes
L2CP processing will be set to tunnel to the EVC all types of L2CPs in order to
provide the same transparency as the WDM private network previously
provided. Best of all, this Carrier Ethernet service does not require the
customer to lease costly dark-fiber services between locations.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
MEF 8
Implementation Agreement for the Emulation of PDH Circuits over Metro Ethernet Networks
MEF 8 is a specification document developed by the Technical Committee of the MEF that provides an Implementation
Agreement for emulation of TDM services over Carrier Ethernet.
Abstract:
"This document provides an implementation agreement for the emulation of TDM services belonging to the Plesiochronous
Digital Hierarchy (PDH) across a Metro Ethernet Network. Specifically it covers emulation of Nx64 kbit/s, DS1, E1, DS3
and E3 circuits. Generically this is referred to as Circuit Emulation Services over Ethernet (CESoETH)."
Download
Reference Presentation
The MEF has prepared an overview presentation which explains the MEF 8 specification.
Download
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
MEF 28
External Network Network Interface (ENNI) Support for UNI Tunnel Access and Virtual UNI
Technical Specification
MEF 28 is a specification document developed by the Technical Committee of the MEF that defines the External Network
Network Interface (ENNI) support for UNI Tunnel Access and Virtual UNI.
Abstract:
"The External Network Network Interface (ENNI) is a reference point that describes the interface between two Metro
Ethernet Networks (MENs) [Editor: Carrier Ethernet Networks (CENs)] and is intended to support the transparent
extension of Ethernet services across multiple Network Operator MENs [Editor: CENs], where each Network Operator MEN
[Editor: CEN] is under the control of a distinct administrative authority. This Technical Specification extends the ENNI by
defining the UNI Tunnel Access (UTA) which associates a Virtual UNI (VUNI), a remote UNI, and at least one supporting
OVC."
Download
Reference Presentation
The MEF has prepared an overview presentation which explains the MEF 28 specification.
Download
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
This presentation provides an overview of how Carrier Ethernet is used to maximize operational use of mobile backhaul
connectivity for cellular base stations.
Download
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Abstract:
"This paper provides an introduction to Circuit Emulation Services over Ethernet (CESoE) enabling the support of
synchronous services such as T1/E1 over an asynchronous Ethernet infrastructure. The paper discusses the benefits of
CESoE to service providers offering Ethernet access services, as well as to subscribers to those services in various
applications. Finally, the paper discusses the current activities of the MEF in standardizing and promoting CESoE."
Download
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Reference Documents
MEF 6.1
MEF 8
MEF 10.2
MEF 26.1
MEF 28
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Each location connects to the SP's network using a switch that maps incoming
traffic flows to ATM/FR PVC (Permanent Virtual Circuit) having fixed CIR and
burst setting, with no ability for bandwidth sharing between different
Reference Documents
applications of the subscriber.
MEF 6.1
In most cases the service offered was point-to-point.
MEF 8
Note: ATM supported LANE (LAN Emulation) but this was never a widely used
MEF 10.2
service.
MEF 22.1
The network that realized the service was often TDM-based, providing very MEF White Paper: CESoE
predictable bandwidth and delay performance and high level of fault IETF RFC 4448
management and resiliency. However, these legacy networks were expensive
to manage, had a relatively limited bandwidth that could be allocated to a MEF-CECP Test Objectives
single service, and had relatively high price points.
8 Comparing and Positioning Carrier
Carrier Ethernet provides a much more scalable, cost-effective alternative. Ethernet Services
In CE, the subscriber can map traffic to the services based on CE-VLAN IDs Send Feedback
and can have bandwidth profiles that enable sharing of bandwidth between
different service instances. Name:
CE also enables the introduction of E-LAN and E-Tree services which could not Email:
be supported efficiently over ATM or FR.
Comments
Both technologies require no IP coordination with the SP as the forwarding
and mapping to the services are not based on IP routing.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Many core networks are built over IP/MPLS both nationally and internationally. Download PDF
These L3 services are non-standard, and there is currently no Standards Reference Documents
Development Organization that is attempting to create standards for such
services. In contrast to L3VPN, Ethernet services are built on the concept of MEF 6.1
Ethernet based forwarding, hence can be referred to as L2VPN. When we MEF 8
consider L3VPN Vs. L2VPN the following comparison can be made:
MEF 10.2
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Assuming that the customer has a symmetrical service of 4 Mbps using 2xE1s IETF RFC 4448
to connect two locations, then the most appropriate Ethernet service to start
with would be an EPL, which provides the most transparent service. In such a MEF-CECP Test Objectives
case the following UNI Attributes are recommended: 8 Comparing and Positioning Carrier
Ethernet Services
All-to-One Bundling = Yes (which means Bundling=No, Service
Multiplexing = No)
Send Feedback
Ingress Bandwidth Profile per UNI
EBS=0 Comments
L2CP Processing Tunnel all L2CPs
Where a single EVC with single CoS ID is planned, the following EVC Attributes
are recommended:
Send Feedback
No bandwidth profile
Conditional delivery Deliver Unconditionally for Unicast, Multicast,
Broadcast
Service Performance will be set to target the performance
guaranteed to the subscriber
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
MEF 22.1
Mobile Backhaul Implementation Agreement Phase 2
MEF 22.1 is a specification document developed by the Technical Committee of the MEF that provides an Implementation
Agreement for Mobile Backhaul.
Abstract:
"This document identifies the requirements for MEF Ethernet Services and MEF External Interfaces (EIs such as UNIs) for
use in Mobile Backhaul networks based on MEF specifications. In addition, new interface and service attributes have been
specified where needed. The services and requirements in this Implementation Agreement are based on the services
defined in MEF 6.1 [3] as well as the attributes in MEF 10.2 [7], in MEF 10.2.1 [8] and this IA. The aim is to be flexible
to support a wide range of Ethernet service based mobile network deployments."
Download
Reference Presentation
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Download PDF
Reference Documents
MEF 6.1
MEF 8
MEF 10.2
MEF 22.1
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Since the 1960's when TDM was first developed for wide area networks, a huge 9.1.1 What is CESoETH
installed-base of TDM circuits and equipment ports (T1/E1, T3/E3 etc.) has 9.1.2 MEF 8 model
emerged throughout the world supporting both voice communications and also < br/>
data networking.
9.2 CES Components
However, with the advent of the Internet, packet-based networking (Carrier 9.2.1 Interface to Customer
Ethernet, IP, MPLS) for both data networking and voice communications has
9.2.2 Generic Interworking
overtaken TDM, becoming the primary approach to digital networking in wide Function (GIWF)
area networks. 9.2.3 Functional Layering
The original purpose of TDM was to enable multiplexed voice calls over a < br/>
single physical circuit. Voice calls require minimum end-to-end delay (latency) 9.3 Service Definitions
and delay variation to achieve reasonable voice quality. This purpose was
9.3.1 E-Line
achieved by designing TDM in such a way that clock synchronization between
9.3.2 UNI Attributes
both ends of the circuit could be achieved via the TDM circuit, as well as
guaranteed and permanent transmission and receipt of TDM frames based on 9.3.3 EVC Attributes
the synchronized clocks - whether or not actual traffic is contained within the 9.3.4 EVC per UNI Attributes
TDM frames. This translates into low latency and delay variation at the < br/>
expense of bandwidth and flexibility.
9.4 Synchronization
Packet-based networking originally provided cost effective networking with 9.4.1 Packet Based
high bandwidth capabilities and flexibility, but without the guarantee of low Synchronization Methods
latency and delay variation required for voice calls and some data 9.4.1.1 Adaptive Clock Recovery
applications. However, with the advent of Carrier Ethernet, and the 9.4.1.2 NTP
improvement of the underlying transport infrastructures, it is now feasible to
9.4.1.3 1588 v2
guarantee low latency and delay variation in packet-based networks enabling
9.4.2 SyncE
the transport of all types of applications including voice and clock
synchronization.
Download PDF
With almost 50 years of deployment of equipment with TDM-ports (e.g. PBXs,
telephone switching centers, mobile backhaul equipment), there is still a need
to connect TDM equipment, albeit over packet-based networks rather than Download a pdf for
offline viewing.
TDM circuits.
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Circuit Emulation Service over Ethernet (CESoETH) is a technology for 9.1.1 What is CESoETH
transporting TDM services over a Carrier Ethernet Network (CEN) 9.1.2 MEF 8 model
< br/>
CESoETH tunnels TDM traffic through a CEN where the packet network
emulates a circuit-switched network, re-creating the TDM circuit at the far 9.2 CES Components
end such that the CEN is invisible to TDM source and destination equipment. 9.2.1 Interface to Customer
CESoETH runs on a standard Ethernet point-to-point service (E-Line). CESoETH
9.2.2 Generic Interworking
can be referred to as TDM emulation over packet network. Function (GIWF)
9.3.1 E-Line
support CESoETH service can be used to support other Ethernet services which
are packet based. However, this is achieved using a separate EVC. Download PDF
Download a pdf for
offline viewing.
Reference Documents
MEF 8
MEF 22.1
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
MEF 8 is the Implementation Agreement for Circuit Emulation over a Carrier 9.1.1 What is CESoETH
Ethernet Network (CEN) 9.1.2 MEF 8 model
< br/>
The TDM service is carried over an E-Line. A single E-Line can support multiple
TDM services. The Subscriber connects to the Service Provider network via a 9.2 CES Components
TDM interface. However a CEN supports only Ethernet UNIs. A component is 9.2.1 Interface to Customer
defined to convert TDM to Ethernet. This component is called Generic
9.2.2 Generic Interworking
Interworking Function (GIWF) Function (GIWF)
9.3.1 E-Line
< br/>
Figure 9.1.2.F1 9.4 Synchronization
It should be noted that this schematic drawing may be realized using a single 9.4.1 Packet Based
Synchronization Methods
network element at the CEN's edge which presents a TDM interface and has an
internal Carrier Ethernet UNI. The Carrier Ethernet UNI is a standard MEF UNI. 9.4.1.1 Adaptive Clock Recovery
9.4.1.2 NTP
From that point on, the transport network is 'unaware' that a TDM service is
9.4.1.3 1588 v2
being carried over the EVC/OVC.
9.4.2 SyncE
In order to provide the level of transparency and the constant bit-rate
required by TDM services, this specific EVC is not shared with other traffic. Download PDF
However, the same UNI can be used to support other services between these
customer locations, using separate EVCs and utilizing the service multiplexing
Download a pdf for
capabilities of MEF services. offline viewing.
It should be noted that similar techniques are used by IETF solutions for
carrying TDM traffic over MPLS or IP networks using pseudowires.
Reference Documents
When two Subscribers need a TDM service to access a PSTN, each customer
will have its own T-Line over an EVPL to the PSTN. If the 2 locations also
MEF 8
require communication between themselves, a third (not shown in the figure)
MEF 22.1
T-Line is created. This service scenario is depicted in the figure below:
MEF Reference Presentation: Access
Technologies
Send Feedback
Name:
Email:
Comments
Figure 9.1.2.F1
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
CESoETH requires several architectural components in addition to the 9.1.1 What is CESoETH
implementation of TDM to Ethernet conversion. This section describes the 9.1.2 MEF 8 model
various components and their use in the implementation of a Carrier Ethernet- < br/>
based TDM service.
9.2 CES Components
< br/>
9.3.1 E-Line
< br/>
9.4 Synchronization
9.4.1.2 NTP
9.4.1.3 1588 v2
9.4.2 SyncE
Download PDF
Reference Documents
MEF 8
MEF 22.1
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
The Subscriber of CESoETH is presented a TDM interface by the Service 9.1.1 What is CESoETH
Provider. TDM services may be transported in two ways:- 9.1.2 MEF 8 model
< br/>
structure-agnostic (where any underlying structure is ignored by the
transport mechanism) 9.2 CES Components
structure-aware (where the underlying structure is exploited by the 9.2.1 Interface to Customer
transport mechanism)
9.2.2 Generic Interworking
Function (GIWF)
MEF Specifications supports the following interfaces:
9.2.3 Functional Layering
DS1 at 1.544 Mbit/s as defined in ANSI [T1.102] and [T1.107] < br/>
E1 at 2.048 Mbit/s as defined in ITU-T Recommendations [G.702] and
9.3 Service Definitions
[G.704]
N x 64kbit/s data (i.e. 64 kbit/s, 128 kbit/s, 192 kbit/s) as defined in 9.3.1 E-Line
The TDM data (and optionally clock) is converted and mapped to packets for < br/>
transport over a CEN. This operation is performed by the GIWF. After this 9.4 Synchronization
conversion from TDM to packet, there is a standard MEF ETH UNI - the point
9.4.1 Packet Based
at which the ETH service starts. Synchronization Methods
At the egress of the ETH service, the GIWF regenerates the TDM stream. 9.4.1.1 Adaptive Clock Recovery
9.4.1.2 NTP
Note that the ETH service that carries the CES data is managed and
9.4.1.3 1588 v2
maintained from UNI to UNI. However, the specific statistics that are
delivered for CESoETH are measured between GIWFs. 9.4.2 SyncE
Download PDF
Reference Documents
MEF 8
MEF 22.1
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
The Circuit Emulation Interworking Functional, also known as the Generic 9.1.1 What is CESoETH
Inter-Working Function (GIWF), is defined as the adaptation function that 9.1.2 MEF 8 model
interfaces the CES application to the Ethernet layer. GIWF handles the < br/>
emulation of the service presented at the CES TDM Interface. The CES GIWF is
9.2 CES Components
responsible for all the functions required for the emulated service to function
including: 9.2.1 Interface to Customer
The details of these functions are detailed in section 6 of MEF 8 but are 9.3.3 EVC Attributes
outside the scope of this study guide. 9.3.4 EVC per UNI Attributes
< br/>
The GIWF has two interfaces:
9.4 Synchronization
Customer facing - CES TDM Interface
9.4.1 Packet Based
ETH UNI facing - CES Payload (i.e. packetised TDM payload, CES Synchronization Methods
control word, optional RTP header)
9.4.1.1 Adaptive Clock Recovery
9.4.1.2 NTP
9.4.1.3 1588 v2
9.4.2 SyncE
Download PDF
Reference Documents
MEF 8
MEF 22.1
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Circuit Emulation Services over Ethernet (CESoETH) uses a point-to-point 9.1.1 What is CESoETH
connection between two GIWFs. Essentially it uses the CEN as an intermediate 9.1.2 MEF 8 model
network (or virtual wire) between two TDM networks. This is handled as an < br/>
application layer function in terms of the layered network model defined in
9.2 CES Components
MEF 8. The GIWF provides the adaptation of the CES application to the
Ethernet services layer. 9.2.1 Interface to Customer
< br/>
CES Application Data
9.3 Service Definitions
Adaptation Function
9.3.1 E-Line
Ethernet Service Layer
9.3.2 UNI Attributes
< br/>
TDM Payload
9.4 Synchronization
RTP (Optional) 9.4.1 Packet Based
Synchronization Methods
CESoETH Control Word
9.4.1.1 Adaptive Clock Recovery
Emulated Circuit Identifier
9.4.1.2 NTP
VLAN Tags 9.4.1.3 1588 v2
Reference Documents
MEF 8
MEF 22.1
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
< br/>
9.3 Service Definitions
9.3.1 E-Line
< br/>
9.4 Synchronization
9.4.1.2 NTP
9.4.1.3 1588 v2
9.4.2 SyncE
Download PDF
Reference Documents
MEF 8
MEF 22.1
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Only E-Lines can be used for CESoETH. This is because the E-Line is the single 9.1.1 What is CESoETH
Carrier Ethernet service type for point-to-point connections, and CESoETH is 9.1.2 MEF 8 model
inherently a point-to-point service. In other words, only E-Lines connect < br/>
exactly two customer TDM interfaces over a CEN.
9.2 CES Components
Subscribers can choose between using an E-Line EPL (private service) and an 9.2.1 Interface to Customer
EVPL (virtual service) An EPL is chosen where only one Carrier Ethernet
9.2.2 Generic Interworking
service is required on the UNI (i.e. CESoETH) EVPL is chosen when more than Function (GIWF)
one Carrier Ethernet service is required on the UNI (e.g. CESoETH and Internet 9.2.3 Functional Layering
access; two CESoETH etc.)
< br/>
Altough EPL provides higher transparency in terms of L2CP processing, this is 9.3 Service Definitions
not relevant for CESoETH, which does not make use of L2CP.
9.3.1 E-Line
Note that the UNI-N in this case is a regular UNI-N supporting Ethernet 9.3.2 UNI Attributes
services. However, the UNI-C is internal to the GIWF since the customer has a 9.3.3 EVC Attributes
TDM interface to the network.
9.3.4 EVC per UNI Attributes
9.4 Synchronization
Point-to-point service
Guaranteed bitrate in known quantum (2 Mbps for E1, 1.5 for T1, 9.4.1 Packet Based
Synchronization Methods
etc.)
Single class of service 9.4.1.1 Adaptive Clock Recovery
9.4.1.2 NTP
Specific service performance targets to support service QoS similar to
TDM networks, meaning: 9.4.1.3 1588 v2
Reference Documents
MEF 8
MEF 22.1
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
A UNI that is an end-point to a CESoETH service is a regular UNI with no 9.1.1 What is CESoETH
specific additional requirements imposed on the UNI. Either UNI type (1, 2.1, 9.1.2 MEF 8 model
2.2) can be used. Some specific UNI attributes should be set specifically in < br/>
order to facilitate the CESoETH service. The table below lists and explains the
9.2 CES Components
additional requirements of the various UNI attributes:
9.2.1 Interface to Customer
9.4.1.2 NTP
All to One Bundling No if Service Multiplexing was set to
Yes Yes if Service Multiplexing was 9.4.1.3 1588 v2
set to No
9.4.2 SyncE
CE-VLAN ID for untagged and No Aditional Requirement
Priorty Tagged frames
Download PDF
Maximum Number of EVC No Aditional Requirement
L2CP Processing Pass to EVC all L2CPs, expect for Reference Documents
PAUSE frames PAUSE cannot be
used along side with guaranteed bit- MEF 8
rate applications
MEF 22.1
MEF Reference Presentation: Access
Technologies
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
The EVC that carries CESoETH can be an EPL or an EVPL. It carries non-VLAN 9.1.1 What is CESoETH
traffic and therefore VLAN and CoS preservation are irrelevant. Since CESoETH 9.1.2 MEF 8 model
uses no L2CP it implies that all L2CP can be discarded by the EVC. < br/>
The major issue to consider is the service performance attributes for this 9.2 CES Components
single CoS ID service. 9.2.1 Interface to Customer
The Delay and Delay Variation are to be set according to the specific 9.2.2 Generic Interworking
Function (GIWF)
requirements of the customers, but must be kept to a minimum.
9.2.3 Functional Layering
The following table lists the EVC attributes and the suggested settings for < br/>
such an EVC:
9.3 Service Definitions
9.4.1.2 NTP
Multicast Service frame Delivery Deliver unconditionally
9.4.1.3 1588 v2
Broadcast Service frame Delivery Deliver unconditionally
9.4.2 SyncE
L2CP Processing Discard all L2CPs
Availability 99.95%
Reference Documents
Note that the exact values for service performance may be dictated by the
MEF 8
appropriate TDM standard or the service requirement that the Subscriber has.
MEF 22.1
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
The major issue to consider when setting the EVC per UNI attributes for 9.1.1 What is CESoETH
CESoETH is the ingress bandwidth profile (BWP) The service must guarantee 9.1.2 MEF 8 model
CIR at a rate that matches the TDM traffic CBR. Because the packetization < br/>
process adds additional overhead and because the BWP counts also the ETH
9.2 CES Components
headers in some cases, the CIR could be set a little higher compared to the
TDM nominal bitrate. 9.2.1 Interface to Customer
CF and CM are not relevant in such a case. 9.3.4 EVC per UNI Attributes
< br/>
The following table lists the EVC per UNI attributes and the suggested settings
9.4 Synchronization
for such an EVC:
9.4.1 Packet Based
Synchronization Methods
EVC per UNI Service Attribute Recommended Value
9.4.1.1 Adaptive Clock Recovery
UNI EVC ID No Additional Requirement
9.4.1.2 NTP
CE-VLAN ID / EVC Map No Additional Requirement 9.4.1.3 1588 v2
Ingress Bandwidth Profile per CIR = 2.2Mbps for E1 service 9.4.2 SyncE
EVC CBS=3x1522 = 4566 bytes EIR=0,
EBS=0 CF=0, CM=0
Download PDF
Ingress Bandwidth Profile per CoS Must not specify
ID
Egress Bandwidth Profile per EVC Must not specify Download a pdf for
offline viewing.
Egress Bandwidth Profile per CoS Must not specify
ID
Reference Documents
MEF 8
MEF 22.1
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Synchronization is the means of keeping all digital equipment in a 9.1.1 What is CESoETH
communications network operating at the same specified clock rate. 9.1.2 MEF 8 model
Differences in timing at nodes within a network cause the receiving node to < br/>
either drop or reread information sent to it. This is referred to as 'clock slip'.
9.2 CES Components
For example, if the sender operates with a clock rate faster than the
receiver's clock rate, the receiver cannot keep up with the incoming traffic. 9.2.1 Interface to Customer
When the receiver cannot keep up with the sender, it will periodically drop 9.2.2 Generic Interworking
some of the information sent to it resulting in reduced voice quality or Function (GIWF)
retransmission of data if the source can support this. 9.2.3 Functional Layering
< br/>
To achieve the required synchronization of the TDM nodes across the
asynchronous Ethernet network, a clock recovery mechanism must be 9.3 Service Definitions
employed at the receiver side of a CESoETH connection. Clock recovery 9.3.1 E-Line
mechanisms need to withstand the potential Frame Delay, Inter-Frame Delay 9.3.2 UNI Attributes
Variation (IFDV) and frame loss of Ethernet networks yet still comply with
9.3.3 EVC Attributes
strict synchronization standard requirements. Variations of recovered clocks
9.3.4 EVC per UNI Attributes
must be maintained within the range of a few nano-seconds to a few micro-
seconds (depending on the TDM services) even though Carrier Ethernet < br/>
Networks (CENs) may introduce frame delay variation in the order of 9.4 Synchronization
milliseconds.
9.4.1 Packet Based
Synchronization Methods
The different sync parameters are illustrated below:
9.4.1.1 Adaptive Clock Recovery
9.4.1.2 NTP
9.4.1.3 1588 v2
9.4.2 SyncE
Download PDF
Reference Documents
The following table specifies for each mobile technology which parameters are
required to be synchronized:
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Packet-based methods use a master-slave mechanism where a master 9.1.1 What is CESoETH
distributes timing to the slaves via packets that carry timestamps. The master 9.1.2 MEF 8 model
has access to an accurate reference, such as GPS and this source clock is < br/>
distributed from a Primary Reference Clock (PRC).
9.2 CES Components
< br/>
9.3.1 E-Line
< br/>
9.4 Synchronization
9.4.1.2 NTP
9.4.1.3 1588 v2
9.4.2 SyncE
Download PDF
Reference Documents
MEF 8
MEF 22.1
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Adaptive Clock Recovery (ACR) is a method with several variants and 9.1.1 What is CESoETH
implementations. In all of them, ACR reconstructs (recovers) the original clock 9.1.2 MEF 8 model
from the actual payload of the data stream. In other words, a synchronous < br/>
clock is derived from an asynchronous packet stream.
9.2 CES Components
This is achieved by having the clock source send bits at a constant rate and 9.2.1 Interface to Customer
aggregated into packets. However, these packets experience variable delay
9.2.2 Generic Interworking
over the CEN. As long as the packets arrive with a high probability (meaning Function (GIWF)
very low FLR) and within bounds on delay and inter-frame delay variation, 9.2.3 Functional Layering
averaging functions can be employed to find the original clock rate.
< br/>
From the CEN's point of view, these packets can be carried in a dedicated EVC 9.3 Service Definitions
or could have a CoS with stringent performance objective within an EVC that
9.3.1 E-Line
carries other traffic.
9.3.2 UNI Attributes
These two approaches are illustrated below: 9.3.3 EVC Attributes
< br/>
9.4 Synchronization
9.4.1.2 NTP
9.4.1.3 1588 v2
9.4.2 SyncE
Download PDF
Reference Documents
MEF 8
MEF 22.1
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Network Time Protocol (NTP) is one of the oldest Ethernet protocols still in 9.1.1 What is CESoETH
use. It was originally designed over 25 years ago. 9.1.2 MEF 8 model
NTPv3 is defined in RFC 1305. < br/>
NTPv4, which is backwards compatible with NTPv3, is defined in RFC 5905.
9.2 CES Components
NTPv4 offers several improvements over previous versions of NTP - one of 9.2.1 Interface to Customer
them being to extend the potential accuracy to tens of microseconds. NTPv4
9.2.2 Generic Interworking
can usually maintain time to within 10-20 milliseconds over the public Function (GIWF)
Internet and can achieve microsecond accuracy or better in local area 9.2.3 Functional Layering
networks (under ideal conditions)
< br/>
The main issue with NTP is that its accuracy can degrade substantially during 9.3 Service Definitions
periods of network congestion. NTP packets are carried over UDP/IP/ETH
9.3.1 E-Line
transport which is then encapsulated depending on the CEN transport
9.3.2 UNI Attributes
technology. Therefore, NTPv4 requires a dedicated CoS ID with stringent
performance objectives for Frame Loss Ratio, Frame Delay and Frame Delay 9.3.3 EVC Attributes
Variation. 9.3.4 EVC per UNI Attributes
< br/>
NTP is quite simple in its operation: The NTP client polls the NTP server at
regular intervals and the server responds with a time stamp. The disadvantage 9.4 Synchronization
of using NTP for precise timing applications is that there is no allowance to 9.4.1 Packet Based
account for network delays other than through multiple poll time averaging Synchronization Methods
techniques and buffering. So NTP, even in the latest implementation, does 9.4.1.1 Adaptive Clock Recovery
not meet the higher precision requirements for 3G/4G mobile backhaul. 9.4.1.2 NTP
9.4.1.3 1588 v2
9.4.2 SyncE
Download PDF
Reference Documents
MEF 8
MEF 22.1
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
The Precision Time Protocol (PTP) specified in IEEE standard 1588v2 is the 9.1.1 What is CESoETH
latest in packet-based timing technology. Originally designed to provide 9.1.2 MEF 8 model
precise timing for critical industrial automation applications, it is now < br/>
providing the highest level of accurate frequency, phase and time of day to
9.2 CES Components
wireless backhaul networks.
9.2.1 Interface to Customer
PTP overcomes the Ethernet NTP latency and delay variation issues, providing
9.2.2 Generic Interworking
an unprecedented accuracy in the nanosecond range. The effects of network Function (GIWF)
latency are greatly reduced by using a technique whereby the master and 9.2.3 Functional Layering
slave communicate with one another to cancel out a measured delay between
< br/>
the two nodes.
9.3 Service Definitions
The IEEE1588 standard makes several assumptions about the network being
9.3.1 E-Line
used (e.g. multicast support) but the key assumptions that affect clock
9.3.2 UNI Attributes
accuracy are:
9.3.3 EVC Attributes
1. The transmission delays are almost constant over time (or at least
9.3.4 EVC per UNI Attributes
change slowly)
< br/>
2. The transmission delays are symmetrical between master and slave
(i.e. time to travel from master to slave is the same as from slave to 9.4 Synchronization
master) 9.4.1 Packet Based
Synchronization Methods
When carried over a Carrier Ethernet Network (CEN), 1588v2 requires a
9.4.1.1 Adaptive Clock Recovery
dedicated CoS or even a dedicated EVC with stringent requirements on Frame
9.4.1.2 NTP
Loss Ratio, Frame Delay and Inter-frame Delay Variation.
9.4.1.3 1588 v2
PTP Network Components
9.4.2 SyncE
The following figure shows an example PTP synchronization network topology.
Download PDF
Reference Documents
Figure 9.4.1.3.F1 - PTP Synchronization Network Topology
MEF 22.1
This is the primary reference source within a PTP sub-domain. The
MEF Reference Presentation: Access
Grandmaster clock has a high-precision time source, which can be a GPS Technologies
reference or an atomic clock.
IEEE 1588 boundary clocks are an effective way to reduce packet delay Name:
variation. A boundary clock runs the PTP protocol and is synchronized to the
Email:
master clock. The boundary clock, in turn, acts as a master clock to all slaves
within the same network. Comments
Delay_Resp messages.
Transparent Clocks
Transparent clocks were added to version 2 of the 1588 standard as an
improved method of forming cascaded topologies where each clock does not
depend on the quality of the preceding clocks. Rather than acting as a multi-
port ordinary clock as boundary clocks do, transparent clocks update a newly
introduced time-interval field within PTP event messages. This 64-bit time-
interval correction field allows for switch delay compensation to a potential
accuracy of less than ne picosecond.
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.
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.
PTP Operation
The BMC node (grandmaster clock) then synchronizes all other nodes (slave
clocks) in the network. The BMC algorithm is then run continuously to quickly
adjust for changes in network configuration. So, if the BMC node is removed
from the network or is determined by the BMC algorithm to no longer have
the highest quality clock, the algorithm determines the new BMC node.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
The IEEE 802.3-2008 standard specifies that transmit clocks can operate with 9.1.1 What is CESoETH
a frequency accuracy of up to +/-100 ppm. 9.1.2 MEF 8 model
< br/>
The Synchronous Ethernet (SyncE) approach provides a mechanism to deliver a
network traceable physical layer clock over IEEE 802.3 PHYs with EEC as 9.2 CES Components
specified in ITU-T G.8262 [33]. The SyncE model follows the same approach 9.2.1 Interface to Customer
that was adopted for traditional TDM (PDH/SDH) synchronization (i.e. utilizing
9.2.2 Generic Interworking
the physical layer line signals) and implemented with similar engineering rules Function (GIWF)
and principles. Synchronous Ethernet has also been designed specifically to 9.2.3 Functional Layering
inter-work with the existing SONET/SDH synchronization infrastructure.
< br/>
Note that Synchronous Ethernet is used to deliver frequency, but not phase or 9.3 Service Definitions
time of day.
9.3.1 E-Line
The following figure proivdes an example of synchronization using Synchronous 9.3.2 UNI Attributes
Ethernet: 9.3.3 EVC Attributes
< br/>
9.4 Synchronization
9.4.1.2 NTP
Figure 9.4.2.F1 - Synchronization using Synchronous Ethernet
[Source: MEF 22.1, Figure 22] 9.4.1.3 1588 v2
The architectural aspects of Synchronous Ethernet are defined in ITU-T 9.4.2 SyncE
G.8261. SyncE provides the capability to provide an Ethernet clock that is
traceable to a primary reference clock (PRC) as defined in ITU-T G.811. Download PDF
It should be noted that SyncE requires all network elements in the network to
be upgraded to support SyncE. Therefore SyncE might only be practical for Reference Documents
use in small network domains, while a hybrid solution complemented by a
packet-based synchronization method would be required to extend its reach. MEF 8
MEF 22.1
MEF Reference Presentation: Access
Technologies
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
9.4 Define the EVC service attributes required for emulated circuits. < br/>
< br/>
9.3.1 E-Line
< br/>
9.4 Synchronization
9.4.1.2 NTP
9.4.1.3 1588 v2
9.4.2 SyncE
Download PDF
Reference Documents
MEF 8
MEF 22.1
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
10.2.2 MEF 17
10.2.2.1 Model
< br/>
10.3.1 Definition
10.1.F1 - SOAM relationship between standards
10.3.2 Procedures
< br/>
10.4 Performance Management
10.4.1 Definition
10.4.2 Procedures
10.4.3.3 Availability
< br/>
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
10.2.2.1 Model
end-to-end Ethernet connectivity faults.
10.2.2.2 Maintenance Entities
Ethernet OAM runs over bridged networks in the Ethernet service layer, as
< br/>
opposed to link layer OAM that is specified by IEEE 802.3 for cases where the
link is Ethernet. 10.3 Fault Management
10.3.1 Definition
IEEE 802.1ag and ITU-T Y.1731 define joint constructs and terminology. It
10.3.2 Procedures
enables defining levels of hierarchical administrative domains, performing the
CFM procedures within each domain independently. 10.3.2.1 Continuity Check
Message
The following procedures and packet formats are defined: 10.3.2.2 Loopback Message
10.4.3.3 Availability
< br/>
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
1. AIS (Alarm Indication Signal): Generated when an end-point detects loss 10.2.1 Constructs
of connectivity 10.2.1.1 MEP, MIP, MEG, MEG
2. Lock: Used to verify connectivity problems in out-of-service mode Level
3. Test: Used to test the connectivity out-of-service. It can be used as 10.2.2 MEF 17
part of RFC 2544 or ITU-T Y.1564 testing 10.2.2.1 Model
4. Delay Measurements: Using DMM/DMR procedure 10.2.2.2 Maintenance Entities
5. Loss Measurement: Using LMM/LMR procedure
< br/>
Some messages use unicast MAC DA and some use reserved multicast DA, 10.3 Fault Management
which is treated as L2CP. For multicast, the MAC DA address is defined as
10.3.1 Definition
follows:
10.3.2 Procedures
There are two types of frames: Class 1 and Class 2 10.3.2.1 Continuity Check
Message
Class 1 - used by CCM - uses MAC DA of 01-c2-80-00-00-30 through 01-c2-80-
10.3.2.2 Loopback Message
00-00-3x, where MEG level is represented by x
10.3.2.3 Link Trace Message
Class 2 - used by LBM and LTM - uses MAC DA of 01-c2-80-00-00-3y through < br/>
01-c2-80-00-00-3F, where y=8+MEG level
10.4 Performance Management
10.4.1 Definition
10.4.2 Procedures
10.4.3.3 Availability
< br/>
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
10.2.2 MEF 17
10.2.2.1 Model
< br/>
10.3.1 Definition
10.3.2 Procedures
< br/>
10.4 Performance Management
10.4.1 Definition
10.4.2 Procedures
10.4.3.3 Availability
< br/>
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
The following figure illustrates an OAM domain: A single CEN to which 4 CEs 10.3.2 Procedures
are attached: 10.3.2.1 Continuity Check
Message
< br/>
10.4 Performance Management
10.4.1 Definition
10.4.2 Procedures
10.2.0.F1 - SOAM Domain 10.4.2.0 Frame Delay
[Source: MEF30, Figure 2]
10.4.2.1 Delay Measurement
Message
10.4.3.3 Availability
< br/>
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
ME (Maintenance Entity) represents an OAM entity that requires management. < br/>
An ME is essentially an association between two maintenance end points 10.2 Framework
within an OAM Domain, where each maintenance end point corresponds to a
10.2.0 Domains
provisioned reference point that requires management.
10.2.1 Constructs
The MEs that are relevant for E-Lines are shown in the figure below: 10.2.1.1 MEP, MIP, MEG, MEG
Level
10.2.2 MEF 17
10.2.2.1 Model
< br/>
10.2.1.F2 - SOAM Maintenance Entities 10.3 Fault Management
[Source: MEF 17, Figure 1]
10.3.1 Definition
Subscriber ME is the OAM Domain that connects the Customer Equipment of
10.3.2 Procedures
the Subscriber. For E-LAN and E-Tree, there will typically be more than two
such end-points. 10.3.2.1 Continuity Check
Message
EVC ME is the OAM domain that connects the UNI-Ns of a given EVC. 10.3.2.2 Loopback Message
10.4.3.3 Availability
< br/>
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
A MEG consists of the maintenance entities (ME) that belong to the same < br/>
service inside a common Service OAM domain.
10.2 Framework
For a Point-to-Point EVC, a MEG contains a single ME. 10.2.0 Domains
For a Multipoint-to-Multipoint EVC of n UNIs, a MEG contains n*(n- 10.2.1 Constructs
1)/2 MEs.
10.2.1.1 MEP, MIP, MEG, MEG
Note that IEEE 802.1ag uses the terminology of MA (Maintenance Association). Level
10.2.2.1 Model
MEP (MEG End Point)
10.2.2.2 Maintenance Entities
A MEP is a provisioned OAM reference point which can initiate and terminate
< br/>
proactive OAM frames. A MEP can also initiate and react to diagnostic OAM
frames. A MEP is represented by a triangle symbol as shown in the SOAM 10.3 Fault Management
Constructs section. 10.3.1 Definition
A Point-to-Point EVC has two MEPs, one at each end-point of the ME 10.3.2 Procedures
(i.e. each UNI-N) 10.3.2.1 Continuity Check
Message
A Multipoint-to-Multipoint EVC of n UNIs has n MEPs, one at each
end-point 10.3.2.2 Loopback Message
A Point-to-Point OVC has two MEPs, one at each end-point of the ME 10.3.2.3 Link Trace Message
(each External Interface associated with the OVC)
< br/>
10.4 Performance Management
MIP (MEG Intermediate Point) 10.4.1 Definition
A MEG Intermediate Point (MIP) is a provisioned OAM reference point which is 10.4.2 Procedures
capable of reacting to diagnostic OAM frames initiated by MEPs. A MIP does 10.4.2.0 Frame Delay
not initiate proactive or diagnostic OAM frames. A MIP is represented by a
10.4.2.1 Delay Measurement
circle symbol as shown in the SOAM Constructs section. The number of MIPs Message
in a Point-to-Point EVC or Multipoint-to-Multipoint EVC is dependent on the 10.4.2.2 Loss Measurement
specific deployments. MIPs are used for Fault Management. Message
When Subscribers, Service Providers, and Network Operators share a given < br/>
MEG Level space, allocation of MEG Levels can be negotiated among the
10.5 CoS Implementation
different parties involved. Agreement - MEF 23
A default allocation of MEG Levels is such that:- 10.5.1 Ethernet Network Section
Service OAM frames for a Subscriber ME use MEG Level 7, 6 or 5 10.5.2 CoS Label Model
Service OAM frames for an EVC ME use MEG Level 3 or 4 as the EVC 10.5.3 Performance Parameters
ME belongs to a Service Provider OAM Domain
< br/>
Operator MEs use MEG Levels 2, 1, or 0.
The MEG Levels used for UNI ME and NNI ME will default to 0. 10.6 Performance Management
Implementation
This default allocation of MEG Level space between Subscribers, Service 10.6.1 Multi-CoS EVC
Providers and Operators can be changed according to mutual agreement of
10.6.2 Relationship to Bandwidth
the parties. Profile
MEF 30 specifies the following default MEG Level allocation per ME: 10.6.3 Interconnect via ENNI
Download PDF
Reference Documents
MEF 10.2
10.2.1.1.F1 - Default MEG Levels
[Source: MEF30, Table 3] MEF 17
MEG levels are allocated in a hierarchical manner to enable the following MEF Reference Presentation:
Interconnect
capabilities:
ITU-T Y.1731
From a given MEG level point of view, higher level MEGs are passed
transparently, but lower level MEGs are not allowed to pass MEF-CECP Test Objectives
A MEP at a given MEG Level must consume OAM frames with this MEG
10 Service OAM
level
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
10.2.1 Constructs
MEF 17 addresses the following specific functional areas of Service OAM:
10.2.1.1 MEP, MIP, MEG, MEG
Fault Management : detection, verification, localization and Level
notification of faults 10.2.2 MEF 17
Performance Monitoring (including performance parameter 10.2.2.1 Model
measurements)
10.2.2.2 Maintenance Entities
Auto-discovery (including discovering service aware network elements
within provider networks) < br/>
Intra-provider and inter-provider Service OAM 10.3 Fault Management
10.3.1 Definition
The reader should note that provisioning aspects of Ethernet services and
CENs are not addressed in MEF 17. 10.3.2 Procedures
< br/>
10.4 Performance Management
10.4.1 Definition
10.4.2 Procedures
10.4.3.3 Availability
< br/>
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
< br/>
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
< br/>
10.2.2.1.F2 - SOAM Maintenance Entities 10.4 Performance Management
[Source: MEF 30, Figure 1]
10.4.1 Definition
A network element (NE) that implements UNI-N functionality, for example the
10.4.2 Procedures
NE denoted as 2 in the figure, has a MEP at MEG level 4 for each EVC instance
that associates that UNI. 10.4.2.0 Frame Delay
This means that service frames and SOAM will have the same EVC headers as 10.4.4 Measurement in E-Line, E-
LAN, E-Tree
the service frames.
< br/>
This requirement leads to the requirement of deterministic and controlled
10.5 CoS Implementation
assignment of flows to shared links in a LAG. Agreement - MEF 23
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
< br/>
Test ME
10.3 Fault Management
The Test ME is assigned to the Service Provider for isolation of problems
10.3.1 Definition
reported by the subscriber. The Test ME uses MEPs placed in the subscriber's
equipment, at the UNI-C, and at least one MEP within the Service Provider's 10.3.2 Procedures
network. The Test ME is not active at all times, but is used on an on-demand 10.3.2.1 Continuity Check
basis. Message
10.4.2 Procedures
Operator ME
10.4.2.0 Frame Delay
An Operator ME is intended to provide the most complete view of the OVC.
10.4.2.1 Delay Measurement
The MEPs in the Operator ME are placed as close to the external interfaces Message
associated by this OVC as possible. This ME is used to perform performance
10.4.2.2 Loss Measurement
monitoring of the OVC and can also be used for OVC fault management. This Message
ME is confined to a single CEN and is used only for cases where an ENNI exists. 10.4.3 Computation Methods
ENNI ME is used to monitor the ENNI link between two ENNI-Ns. OAM messages < br/>
use the active link to ensure that they monitor the same physical link used for 10.5 CoS Implementation
ENNI frames. Since the ENNI link is a wire and not a network, performance Agreement - MEF 23
monitoring is less relevant. However fault monitoring activities are important 10.5.1 Ethernet Network Section
for this ME. 10.5.2 CoS Label Model
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
10.2 Framework
10.2.0 Domains
10.2.1 Constructs
10.2.2 MEF 17
10.2.2.1 Model
< br/>
10.3.1 Definition
10.3.2 Procedures
< br/>
10.4 Performance Management
10.4.1 Definition
10.4.2 Procedures
10.4.3.3 Availability
< br/>
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
ENNI) across a defined OAM Domain, where that domain can be a large 10.2 Framework
network (or subnetwork), or a simple link. SOAM FM uses the protocols 10.2.0 Domains
described in IEEE 802.1ag and ITU-T Y.1731. It provides end-to-end Ethernet
10.2.1 Constructs
connectivity management, mechanisms to detect, verify, isolate and report
10.2.1.1 MEP, MIP, MEG, MEG
faults that affect the external interfaces or the EVC/OVCs. The following
Level
sections describe the use of FM procedures and mechanisms with the
10.2.2 MEF 17
appropriate parameter settings that meet the requirements for fault
management of Ethernet services in the CEN. 10.2.2.1 Model
< br/>
10.4 Performance Management
10.4.1 Definition
10.4.2 Procedures
10.4.3.3 Availability
< br/>
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
10.2 Framework
Continuity Check Message
Loopback Message 10.2.0 Domains
10.2.2 MEF 17
10.2.2.1 Model
10.2.2.2 Maintenance Entities
< br/>
10.3.1 Definition
10.3.2 Procedures
< br/>
10.4 Performance Management
10.4.1 Definition
10.4.2 Procedures
10.4.3.3 Availability
< br/>
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
10.2.2.1 Model
Protection switching: 10 msec or 3.33 msec
10.2.2.2 Maintenance Entities
Availability measurement: 1 or 10 seconds < br/>
CCMs can be administratively turned on and off, but compliant NEs must 10.3 Fault Management
support CCMs. 10.3.1 Definition
10.3.2 Procedures
CCMs can be sent at any MEG Level, depending on the ME they monitor
(Subscriber ME, EVC ME, Operator ME, etc). 10.3.2.1 Continuity Check
Message
CCMs sent by the Subscriber ME must be set with the CE-VLAN ID that maps to 10.3.2.2 Loopback Message
the monitored EVC. Such frames are subject to the Bandwidth Profile and are 10.3.2.3 Link Trace Message
considered to be Service Frames.
< br/>
For SP ME, CCMs are carried using the same transport path and identifiers as 10.4 Performance Management
service frames for that EVC. Such frames may be subject to the EVC BWP, but
10.4.1 Definition
in some implementations, these CCMs are sent after the Ingress Bandwidth
10.4.2 Procedures
Profile point in order to reduce the risk of them being dropped. In such a
case, and when color forwarding is used, they are marked as green frames. 10.4.2.0 Frame Delay
When CCMs are sent for a given ME, this ME can have the following 10.4.3.1 Inter-Frame Delay
Variation
Connectivity Status values:
10.4.3.2 Frame Loss Ratio
Active : A ME Connectivity Status of active implies that Service OAM 10.4.3.3 Availability
frames can be exchanged between the MEPs in both directions.
10.4.4 Measurement in E-Line, E-
Not Active : A ME Connectivity Status of not active implies that LAN, E-Tree
Service OAM frames cannot be exchanged in both directions between
< br/>
the MEPs of the ME.
10.5 CoS Implementation
A Multipoint-to-Multipoint MEG can have the following Connectivity Status Agreement - MEF 23
values: 10.5.1 Ethernet Network Section
Not Active : A MEG Connectivity Status of not active implies that each < br/>
ME in the MEG has a Connectivity Status of not active.
10.6 Performance Management
Partially Active : A MEG Connectivity Status of partially active implies Implementation
that there exist at least one active ME and one not active ME in the 10.6.1 Multi-CoS EVC
MEG.
10.6.2 Relationship to Bandwidth
Profile
The following figure illustrates CCMs monitoring 3 MEs:
10.6.3 Interconnect via ENNI
Subscriber ME (green line) between 2 MEPs at the CE. Used by the subscriber
in order to monitor the end to end connectivity between its locations. Download PDF
SP ME (blue line) between 2 MEPs at the UNI-N Operator. Note that in this
example, the EVC monitoring crosses 2 CENs. These CCMs can be used for EVC
Download a pdf for
availability measurement and thus are expected to be sent at 1 or 10 second offline viewing.
intervals.
Operator ME (orange line) between 2 MEPs at the OVC end points. Each of
the 2 CEN Operators run CCMs on its own operated OVC. These CCMs can be Reference Documents
used for OVC availability measurement and thus are expected to be sent at 1
or 10 second intervals. MEF 10.2
MEF 17
Note that these CCMs are constantly being sent. Once the Operator identifies
a fault, the Operator needs to isolate the fault. That is understand which MEF Reference Presentation:
Interconnect
network element or link has failed. In order to do so, the Operator can start
a Loopback or Linktrace procedure. ITU-T Y.1731
10 Service OAM
Send Feedback
10.3.2.1.F1 - Example use of SOAM CCM
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
10.2.2.1 Model
The LBM uses Unicast MAC DA of the destination MIP/MEP, but it can also use
the same multicast MAC used by CCMs. It is recommended to use the highest 10.2.2.2 Maintenance Entities
CoS ID for an LBM - the one that yields the lowest possible loss for that < br/>
Ethernet service (EVC or OVC). An LBM is usually 64 bytes long, but can be
10.3 Fault Management
extended to any value up to the MTU size using specific TLVs.
10.3.1 Definition
The LBR is identical to the LBM except that the MAC DA and MAC SA are 10.3.2 Procedures
swapped. The following figure illustrates LBR sent by the SP ME in order to
10.3.2.1 Continuity Check
verify that the NE implementing ENNI-N at the far CEN is operating. An LB Message
session starts from the MEP at the UNI-N on the left destined for the ENNI-N 10.3.2.2 Loopback Message
in Operator 2's network. Once it replies the SP knows that the NE and the
10.3.2.3 Link Trace Message
OVC to it are functional.
< br/>
10.4 Performance Management
10.4.1 Definition
10.4.2 Procedures
10.4.3.3 Availability
< br/>
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
< br/>
10.3.1 Definition
10.3.2 Procedures
10.3.2.3.F1 - SOAM LTM
10.3.2.1 Continuity Check
In this example, an LTM procedure is issued from MEP1. MIP1 and MIP2 reply, Message
but MIP3 does not reply. 10.3.2.2 Loopback Message
The failure is between MIP2 and MIP3, or at the NE implementing MIP3. 10.3.2.3 Link Trace Message
< br/>
There is no sense in sending messages to MIP4 and MEP2 as they will not pass
10.4 Performance Management
through.
10.4.1 Definition
The LTM frames should be sent with same CE-VLAN ID that maps to the
10.4.2 Procedures
monitored EVC, that way it is guaranteed that the LTM passes the same path
10.4.2.0 Frame Delay
as the monitored EVC's service frames.
10.4.2.1 Delay Measurement
Message
10.4.3.3 Availability
< br/>
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
10.2.0 Domains
10.2.1 Constructs
10.2.2 MEF 17
10.2.2.1 Model
< br/>
10.3.1 Definition
10.3.2 Procedures
< br/>
10.4 Performance Management
10.4.1 Definition
10.4.2 Procedures
10.4.3.3 Availability
< br/>
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
In the context of the MEF PM framework, a PM Solution is a collection of 10.2.2.2 Maintenance Entities
interdependent and related requirements of the components that implement < br/>
that solution. A PM Solution uses PM Functions which are capabilities that are
10.3 Fault Management
specified for performance monitoring purposes (e.g. Single-Ended Delay,
10.3.1 Definition
Single-Ended Synthetic Loss). A PM Function is associated with an ITU-T PM
Tool which is a specific tool that is described in ITU-T Y.1731 (e.g. Single- 10.3.2 Procedures
Ended ETH-SLM). A PM Session is an instantiation of a PM Solution between a 10.3.2.1 Continuity Check
given pair of MEPs using a given CoS over a given (possibly indefinite) period of Message
< br/>
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
10.2.1 Constructs
10.2.2 MEF 17
10.2.2.1 Model
< br/>
10.3.1 Definition
10.3.2 Procedures
< br/>
10.4 Performance Management
10.4.1 Definition
10.4.2 Procedures
10.4.3.3 Availability
< br/>
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
10.2.1 Constructs
10.2.2 MEF 17
10.2.2.1 Model
10.4.2.0.F1 - Frame Delay for Service Frame
10.2.2.2 Maintenance Entities
Note that this definition of Frame Delay for a Service Frame is the one-way
< br/>
delay that includes the delays encountered as a result of transmission across
the ingress and egress UNIs as well as that introduced by the CEN. 10.3 Fault Management
10.3.1 Definition
When the UNIs are not Time-synchronized, measuring this one-way frame
10.3.2 Procedures
delay is not possible using the ETH-DM procedure. Therefore, an
10.3.2.1 Continuity Check
approximation is to take 1/2 of the two-way delay between the 2 UNIs.
Message
MEF 10.2 defines three performance attributes for One-Way Frame Delay: 10.3.2.2 Loopback Message
The Performance objectives are given for a time interval T (e.g. 15 minutes). 10.4.2 Procedures
The Frame Delay measurements are done much more frequently (e.g. 1 per 10.4.2.0 Frame Delay
second) This yields several (900 in this example) data points per time interval 10.4.2.1 Delay Measurement
T. These data points can be used to derive a distribution or some statistical Message
function. 10.4.2.2 Loss Measurement
Percentile: if the x th percentile (e.g 95 th ) of the distribution over T Message
Mean: the statistical mean over all samples for time interval T 10.4.3 Computation Methods
Range: The difference between two pre-defined percentiles (e.g. 90th 10.4.3.0 Frame Delay
percentile to 20th percentile).
10.4.3.1 Inter-Frame Delay
Variation
Example:
10.4.3.2 Frame Loss Ratio
Assume an E-Line service with single CoS ID. 10.4.3.3 Availability
The SLS specified for Frame Delay is that for any given 1-hour the 95th 10.4.4 Measurement in E-Line, E-
LAN, E-Tree
percentile will be 50 msec.
< br/>
The Service Provider measures the Frame Delay every 1 second between 2
10.5 CoS Implementation
MEPs in the EVC ME. Agreement - MEF 23
The reader can refer to section 6.9.2 of MEF 10.2 for formal definitions of < br/>
these performance attributes. The computation method above is applicable 10.6 Performance Management
for E-Line. Implementation
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
10.2.0 Domains
The procedure involves the sender MEP sending a DMM (Delay Measurement
10.2.1 Constructs
Message) once per time interval (e.g. 1 second, 10 seconds, 1 minute). The
remote MEP responds with DMR (Delay Measurement Reply). 10.2.1.1 MEP, MIP, MEG, MEG
Level
Assuming that the 2 MEPs are not time-synchronized, then only two-way 10.2.2 MEF 17
measurements can be taken. In other words, each MEP performs its own 10.2.2.1 Model
measurements based on differences in the time between sending the DMM and
10.2.2.2 Maintenance Entities
receiving the DMR.
< br/>
Note that MIPs are transparent to this procedure.
10.3 Fault Management
These messages MUST traverse the same path as the service frames belonging 10.3.1 Definition
to the monitored EVC/OVC. The CoS ID of the DMM is set to match the 10.3.2 Procedures
monitored CoS ID.
10.3.2.1 Continuity Check
Message
When several CoS IDs are to be measured, a separate procedure is run for
10.3.2.2 Loopback Message
each CoS ID.
10.3.2.3 Link Trace Message
When using DMM/DMR PDUs, DMM frames are sent from a Controller MEP to a
< br/>
Responder MEP which, in turn, responds with DMR frames. Controller to
Responder measurements and Responder to Controller measurements are also 10.4 Performance Management
known as forward and backward measurements, respectively. With optional 10.4.1 Definition
time-of-day (ToD) clock synchronization one-way FD can be measured. Two- 10.4.2 Procedures
way FD and IFDV measurements and one-way IFDV measurements can always
10.4.2.0 Frame Delay
be taken and do not require ToD clock synchronization. For FD, if ToD
10.4.2.1 Delay Measurement
synchronization is not accurate enough for PM functions, the one-way metrics Message
of MEF 10.2 [12] and MEF 10.2.1 [13] can be estimated by dividing the two-
10.4.2.2 Loss Measurement
way measurement by 2, although this introduces considerable statistical bias Message
for delay metrics other than MFD (Mean Frame Delay).
10.4.3 Computation Methods
10.4.3.3 Availability
Each DMM message sent contains the following information in the DMM PDU: < br/>
Upon receiving DMM, the far end has the following variable: 10.5.1 Ethernet Network Section
When two-way measurements are conducted, the remote MEP copies the 10.6 Performance Management
TxTimeStampf from the DMM to the DMR. The process should be completed as Implementation
fast as possible and should not involve the CPU of the NE, where possible. 10.6.1 Multi-CoS EVC
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
in turn responds with LMR frames. LMM PDUs can be sent to the unicast 10.2.2.1 Model
address of the Responder MEP at the MEG Level of the ME. 10.2.2.2 Maintenance Entities
For each ME for which an LM procedure is configured, a MEP maintains two < br/>
local counters for each peer MEP (MEP in its MEG) and for each CoS ID. 10.3 Fault Management
10.3.1 Definition
TxFCl: Counter for in-profile data frames transmitted towards the
peer MEP. 10.3.2 Procedures
RxFCl: Counter for in-profile data frames received from the peer 10.3.2.1 Continuity Check
MEP. Message
< br/>
10.4 Performance Management
10.4.1 Definition
10.4.2 Procedures
10.4.2.2.F1 - SOAM Loss Measurement
10.4.2.0 Frame Delay
Note that MIPs are transparent to this procedure.
10.4.2.1 Delay Measurement
Message
These messages MUST traverse the same path as the service frames belonging
to the monitored EVC/OVC. The CoS ID of the LMM is set to match the 10.4.2.2 Loss Measurement
Message
monitored CoS ID.
10.4.3 Computation Methods
When several CoS IDs are to be measured, a separate procedure is run for 10.4.3.0 Frame Delay
each CoS ID.
10.4.3.1 Inter-Frame Delay
Variation
It should be possible to administratively configure the following information in
10.4.3.2 Frame Loss Ratio
the LMM PDU:
10.4.3.3 Availability
TxFCf Copied from the local TxFCl
10.4.4 Measurement in E-Line, E-
LAN, E-Tree
The Refector MEP generates LMR in return for any valid LMM received. The
LMR PDU contains: < br/>
< br/>
Upon reception of the LMR, the Probe MEP performs the FLR calculation for
10.6 Performance Management
both ends for the time interval t 1 -t 0 (Where t 1 is the current time and t 0
Implementation
is the last sample time).
10.6.1 Multi-CoS EVC
Number of Frame Lost (local) = |TxFCf(t 1 ) TxFCf(t 0 )| - 10.6.2 Relationship to Bandwidth
|RxFCf(t 1 ) RxFCf(t 0 )| Profile
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
10.2.2.1 Model
10.2.2.2 Maintenance Entities
< br/>
10.3.1 Definition
10.3.2 Procedures
< br/>
10.4 Performance Management
10.4.1 Definition
10.4.2 Procedures
10.4.3.3 Availability
< br/>
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
The One-way Frame Delay for an egress Service Frame at a given UNI in the < br/>
EVC is defined as the time elapsed from the reception at the ingress UNI of 10.2 Framework
the first bit of the corresponding ingress Service Frame until the transmission
10.2.0 Domains
of the last bit of the Service Frame at the given UNI. This delay definition is
10.2.1 Constructs
illustrated in the following figure:
10.2.1.1 MEP, MIP, MEG, MEG
Level
10.2.2 MEF 17
10.2.2.1 Model
< br/>
Frame Delay for Service Frame
10.3 Fault Management
Note that this definition of Frame Delay for a Service Frame is the one-way 10.3.1 Definition
delay that includes the delays encountered as a result of transmission across
10.3.2 Procedures
the ingress and egress UNIs as well as that introduced by the CEN.
10.3.2.1 Continuity Check
When the UNIs are not Time-synchronized, measuring this one-way frame Message
delay is not possible using the ETH-DM procedure. Therefore, an 10.3.2.2 Loopback Message
approximation is to take 1/2 of the two-way delay between the 2 UNIs. 10.3.2.3 Link Trace Message
MEF 10.2 defines three performance attributes for One-Way Frame Delay: < br/>
10.4 Performance Management
One-way Frame Delay Performance corresponding to a percentile of
10.4.1 Definition
the distribution
One-way Mean Frame Delay 10.4.2 Procedures
One-way Frame Delay Range 10.4.2.0 Frame Delay
10.4.3.3 Availability
Example:
10.4.4 Measurement in E-Line, E-
LAN, E-Tree
Assume an E-Line service with single CoS ID.
< br/>
The SLS specified for Frame Delay is that for any given 1-hour the 95th
10.5 CoS Implementation
percentile will be 50 msec. Agreement - MEF 23
The Service Provider measures the Frame Delay every 1 second between 2 10.5.1 Ethernet Network Section
percentile is no greater than 50 msec, the SLS is met. 10.6 Performance Management
Implementation
The reader can refer to section 6.9.2 of MEF 10.2 for formal definitions of 10.6.1 Multi-CoS EVC
these performance attributes. The computation method above is applicable
10.6.2 Relationship to Bandwidth
for E-Line. Profile
For E-LAN and E-tree an additional step is required. Please refer to 10.6.3 Interconnect via ENNI
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
10.2.1 Constructs
Note: MEF 10 and 10.1 refer to Inter-Frame Delay Variation as Frame Delay
Variation. 10.2.1.1 MEP, MIP, MEG, MEG
Level
Note: The term Jitter is not an appropriate term to be substituted for Frame 10.2.2 MEF 17
Delay Variation. 10.2.2.1 Model
The Inter-Frame Delay Variation Performance is defined as the P-percentile of 10.2.2.2 Maintenance Entities
the absolute values of the difference between the Frame Delays of all < br/>
Qualified Service Frame pairs that satisfy the following conditions:
10.3 Fault Management
The difference in the arrival times of the first bit of each Service Frame at 10.3.1 Definition
the ingress UNI was exactly some (small) time value t . 10.3.2 Procedures
The concept is depicted below:
10.3.2.1 Continuity Check
Message
< br/>
10.4.3.1.F1 - Inter-Frame Delay Variation Performance 10.4 Performance Management
10.4.1 Definition
Assuming that for a given EVC and for a specific CoS ID, ETH-DM procedure is
executed every 1 second (having D t = 1 second), the absolute value 10.4.2 Procedures
difference between 2 consecutive readings is the measured value. At the end 10.4.2.0 Frame Delay
of the time interval T, a percentile is calculated and is compared with the 10.4.2.1 Delay Measurement
objective. For the SLS, an Inter-Frame Delay Variation metric MUST specify a Message
set of parameters and an objective. The parameters and objective for an 10.4.2.2 Loss Measurement
Inter-Frame Delay Variation Performance metric are given in the following Message
< br/>
The separation between frame pairs for which Inter-Frame
Dt 10.5 CoS Implementation
Delay Variation Performance is defined
Agreement - MEF 23
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
10.2.2 MEF 17
Let denote the number of ingress Service Frames at UNI i whose first 10.2.2.1 Model
bit arrived at UNI i during the time interval T, whose Ingress Bandwidth 10.2.2.2 Maintenance Entities
Profile compliance was Green, and that should have been delivered to UNI j
< br/>
according to the Service Frame Delivery service attributes. Note that each
10.3 Fault Management
Service Frame can be a Unicast, Multicast, Broadcast or L2CP
10.3.1 Definition
10.3.2 Procedures
Let denote the number of such Service Frames delivered to UNI j.
10.3.2.1 Continuity Check
Message
< br/>
Define
10.4 Performance Management
The following figure provides an example: 10.4.1 Definition
10.4.2 Procedures
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
If the previous sequence was defined as available, and if the frame loss is 10.2.2.1 Model
high for each small time interval in the current sequence, then the current 10.2.2.2 Maintenance Entities
sequence is defined as unavailable. Otherwise the current sequence is defined
< br/>
as available.
On the other hand, if the previous sequence was defined as unavailable, and 10.3 Fault Management
if frame loss is low for each small time interval in the current sequence, then 10.3.1 Definition
the current sequence is defined as available. Otherwise, the current sequence 10.3.2 Procedures
is defined as unavailable.
10.3.2.1 Continuity Check
Message
< br/>
10.4 Performance Management
10.4.1 Definition
10.4.2 Procedures
10.4.3.3.F1 -Availability for Small Time Intervals
[Source: MEF 10.2.1, Figure B] 10.4.2.0 Frame Delay
The Availability for a particular Class of Service instance from UNI i to UNI j 10.4.2.1 Delay Measurement
Message
for a time interval T excludes the small time intervals that occur during a
Maintenance Interval (MI). An MI is a time interval agreed to by the Service 10.4.2.2 Loss Measurement
Message
Provider and Subscriber during which the service may not perform well or at
10.4.3 Computation Methods
all. Examples of a Maintenance Interval include:
10.4.3.0 Frame Delay
A time interval during which the Service Provider may disable the
10.4.3.1 Inter-Frame Delay
service for network maintenance such as equipment replacement Variation
A time interval during which the Service Provider and Subscriber may 10.4.3.2 Frame Loss Ratio
perform joint fault isolation testing, and
10.4.3.3 Availability
A time interval during which the Service Provider may change service
10.4.4 Measurement in E-Line, E-
features and making the changes may disrupt the service.
LAN, E-Tree
The reader can refer to section 6.9.7 of MEF 10.2.1 for formal definitions of < br/>
these performance attributes. The computation method above is applicable 10.5 CoS Implementation
for E-Line. For E-LAN and E-tree an additional step is required, please refer to Agreement - MEF 23
Measurement in E-Line, E-LAN and E-Tree. 10.5.1 Ethernet Network Section
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
10.3.1 Definition
For a Rooted-Multipoint EVC, S must be such that all ordered pairs in S
contain at least one UNI that is designated as a Root. This is required since 10.3.2 Procedures
two leaf UNIs cannot communicate with each other. For each UNI pair within 10.3.2.1 Continuity Check
the sub-set S, the procedures are carried out and summarized every time Message
10.4.1 Definition
10.4.2 Procedures
10.4.3.3 Availability
< br/>
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
10.2.1 Constructs
Ethernet service interoperability and consistency between Operators
a common CoS set for Subscribers to utilize and 10.2.1.1 MEP, MIP, MEG, MEG
Level
support of key applications
10.2.2 MEF 17
The Scope and applicability of the Class of Service Implementation Agreement: 10.2.2.1 Model
10.3.2 Procedures
< br/>
CENs are still free to implement a subset or superset of the CoS Download PDF
MEF 10.2
MEF 17
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
10.2.2.1 Model
< br/>
10.3.1 Definition
10.3.2 Procedures
10.4.3.3 Availability
< br/>
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
< br/>
Only the PCP and DSCP CoS ID components are specified with values. All CPO
requirements refer to UNI-to-UNI, UNI-to-ENNI and ENNI-to-ENNI performance 10.3 Fault Management
in MEF 23.1. 10.3.1 Definition
FD, MFD, IFDV, FDR and FLR CPOs are specified normatively as one of the 10.3.2 Procedures
following: 10.3.2.1 Continuity Check
Message
1. Numeric values expressed in milliseconds (ms) for FD, MFD, IFDV and
10.3.2.2 Loopback Message
FDR. FLR is expressed as a decimal number representing a percentage.
10.3.2.3 Link Trace Message
2. Unspecified performance for a particular CPO for a given CoS Label via
N/S < br/>
In MEF 23 (CoS IA Phase 1), CPOs were expressed in relative terms. In 10.4 Performance Management
contrast, inn MEF 23.1 (CoS IA Phase 2) CPOs are expressed using values. 10.4.1 Definition
10.4.2 Procedures
In Phase 2, the Phase 1 CoS Model table is divided into several ???
10.4.2.0 Frame Delay
Since MEF 23.1 supports a Three CoS Label Model and its subsets, there is a 10.4.2.1 Delay Measurement
need to interwork or map between the subsets. Message
10.4.3.3 Availability
This model, as shown in Table 2, Table 3 and Table 4, specifies three MEF CoS
Labels denoted by CoS Labels H, M and L. There is no restriction on how 10.4.4 Measurement in E-Line, E-
LAN, E-Tree
Operators may use the PCP (i.e., 4, 6,7) and DSCP values not specified.
< br/>
Table 2 introduces the CoS Labels and specifies the Bandwidth Profile
10.5 CoS Implementation
constraints and CoS ID types in Phase 2. Agreement - MEF 23
Table 3 provides the PCP and DSCP values used for per frame Color ID when 10.5.1 Ethernet Network Section
CoS ID type is EVC or OVC EP. 10.5.2 CoS Label Model
Table 4 identifies the PCP and DSCP values to be used to identify the CoS 10.5.3 Performance Parameters
Label and per frame Color ID when CoS ID type is PCP or DSCP. < br/>
Note that the EVC or OVC part of the CoS Identifier is not explicitly shown for 10.6 Performance Management
Implementation
these cases. Furthermore, Table 4 does not include a separate column for
identifying the CoS Label when the CoS Identifier of the CoS Frame Set is only 10.6.1 Multi-CoS EVC
EVC or OVC EP, e.g., PCP values are not relevant to CoS ID or may not be 10.6.2 Relationship to Bandwidth
present as in the case of an EVC with only untagged frames. Profile
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
while the case of CIR > 0 will require conformance with CPOs.
Email:
Comments
Send Feedback
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.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
10.2.1 Constructs
From a Service OAM Performance Monitoring (SOAM-PM) point of view, these
10.2.1.1 MEP, MIP, MEG, MEG
parameter values provide a basis for how the measurements are made for the Level
CoS Frame Sets. In Phase 2, parameters associated with each performance
10.2.2 MEF 17
metric are stated separately for each CoS Label due to variances in
10.2.2.1 Model
Percentiles, though the values are uniform across PTs.
10.2.2.2 Maintenance Entities
In MEF 23.1 the scope of CPOs is limited to Point-to-Point EVC/OVC types -
< br/>
Multipoint will be addressed in a later phase. There is no requirement that
parameters be uniform across CoS Labels, PTs, EVC/OVC types or between 10.3 Fault Management
performance metrics with similar parameters. Parameters may not be 10.3.1 Definition
specified (i.e., N/S) in MEF 23.1 when the associated CPOs are not specified 10.3.2 Procedures
(i.e., N/S).
10.3.2.1 Continuity Check
Message
< br/>
10.4 Performance Management
10.4.1 Definition
10.4.2 Procedures
< br/>
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Note that in the case of an EVC that comprises multiple OVCs, the EVC CPOs
in Tables 6, 7, 8 and 9 may not be met even if CoS Label mapping is aligned.
For example, when there is insufficient alignment of CBS between Operators
and/or insufficient shaping at the ENNI.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
10.2.2 MEF 17
10.2.2.1 Model
< br/>
10.3.1 Definition
10.3.2 Procedures
< br/>
10.4 Performance Management
10.4.1 Definition
10.4.2 Procedures
10.4.3.3 Availability
< br/>
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
10.2.0 Domains
10.2.1 Constructs
10.2.2 MEF 17
10.2.2.1 Model
10.6.1.T1 - Example CoS Performance Objectives
10.2.2.2 Maintenance Entities
All objectives are specified over time interval T of 60 minutes. Assuming that
< br/>
this exemplary EVC is an E-Line, there will be two MEPs in this EVC ME - one
at each UNI-N. In order to measure one-way Inter-Frame Delay Variation, 10.3 Fault Management
each of the MEPs will trigger ETH-DM procedure every 1 second for each of 10.3.1 Definition
the CoS. MEP A will send 3 ETH-DM with the CE-VLAN ID of the EVC and with: 10.3.2 Procedures
procedure is executed at each MEP only for 2 CoS (H and M). We also see that 10.4.2.2 Loss Measurement
Message
Availability is not computed since it was not specified as a performance
objective for this service instance. 10.4.3 Computation Methods
10.4.3.3 Availability
< br/>
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
10.3.2 Procedures
< br/>
10.4 Performance Management
10.4.1 Definition
10.4.2 Procedures
10.4.3.3 Availability
< br/>
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
10.2.0 Domains
10.2.1 Constructs
10.2.2 MEF 17
10.2.2.1 Model
10.6.3.F1 - E-Line
10.2.2.2 Maintenance Entities
Calculating the performance objectives for each OVC in order to meet specific
< br/>
EVC performance objectives is made challenging by the fact that the
percentiles and FLR are not additive. 10.3 Fault Management
10.3.1 Definition
Future versions of MEF 23 and MEF SOAM PM specifications are expected to
10.3.2 Procedures
provide solutions for this use case.
10.3.2.1 Continuity Check
Message
< br/>
10.4 Performance Management
10.4.1 Definition
10.4.2 Procedures
10.4.3.3 Availability
< br/>
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
MEF 17
Service OAM Requirements & Framework - Phase 1
Abstract:
"OAM (Operations, Administration and Maintenance) can be used to manage network infrastructures and services
provided across these network infrastructures. This document provides requirements and framework for Service OAM
within MEF compliant Metro Ethernet Networks (MENs). Service OAM requirements represent expectations of Service
Providers in managing Ethernet Services within the MENs and Subscribers in managing Ethernet Services across the MENs.
Service OAM framework describes the high-level constructs used to model different MEN and Service components that are
relevant for OAM. The framework also describes the relationship between Service OAM and the architectural constructs
of Ethernet Services (ETH), Transport Service (TRAN) and Application Service (APP) Layers as identified in [MEF 4]."
Download
Reference Presentation
The MEF has prepared an overview presentation which explains the MEF 17 specification.
Download
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
This presentation provides an overview of the work of the MEF relating to the interconnection of Carrier Ethernet
networks from more than one service provider/operator to create an end-to-end Carrier Ethernet service.
Download
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
ITU-T Y.1731
OAM Functions and Mechanisms
The Y.1731 recommendation developed by ITU-T is a useful reference for understanding Service OAM in the context of
Carrier Ethernet networks. The document can be downloaded here.
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
10.2 Describe the basic mechanisms for fault management. 10.1.1 IEEE 802.1ag Overview
10.2.0 Domains
10.2.1 Constructs
10.2.2 MEF 17
10.2.2.1 Model
< br/>
10.3.1 Definition
10.3.2 Procedures
< br/>
10.4 Performance Management
10.4.1 Definition
10.4.2 Procedures
10.4.3.3 Availability
< br/>
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
IEEE 802.1AX
Link Aggregation
Specification
MEF 6.1 is a specification document developed by the Technical Committee of the MEF.
Abstract:
"This document uses the service attributes and parameters that are defined in the MEF Technical Specification Ethernet
Services Attributes Phase 2 [2] and applies them to create different Ethernet services. This document defines three
generic service constructs called Ethernet Service types and specifies their associated service attributes and parameters
used to create Point-to-Point, Multipoint-to-Multipoint, and Rooted-Multipoint Ethernet services. This document also
defines the requirements for several Ethernet services that use these generic Ethernet Service types. In addition, an
informative appendix is provided showing examples of some of the defined services. This document supersedes and
replaces MEF 6, Ethernet Services Definitions - Phase 1 [1]."
Download
Reference Presentation
The MEF has prepared an overview presentation which explains the MEF 6.1 specification.
Download
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
IEEE 802.1AX
Link Aggregation
Specification
MEF 6.1 is a specification document developed by the Technical Committee of the MEF.
Abstract:
"This document uses the service attributes and parameters that are defined in the MEF Technical Specification Ethernet
Services Attributes Phase 2 [2] and applies them to create different Ethernet services. This document defines three
generic service constructs called Ethernet Service types and specifies their associated service attributes and parameters
used to create Point-to-Point, Multipoint-to-Multipoint, and Rooted-Multipoint Ethernet services. This document also
defines the requirements for several Ethernet services that use these generic Ethernet Service types. In addition, an
informative appendix is provided showing examples of some of the defined services. This document supersedes and
replaces MEF 6, Ethernet Services Definitions - Phase 1 [1]."
Download
Reference Presentation
The MEF has prepared an overview presentation which explains the MEF 6.1 specification.
Download
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
MEF 9
Abstract Test Suite for Ethernet Services at the UNI
MEF 9 is a specification document developed by the Technical Committee of the MEF that provides an Abstract Test Suite
for testing Ethernet Services at the UNI.
Abstract:
"This document defines the requirements and corresponding test procedures that determine the readiness of a Metro
Ethernet Network (MEN) to deliver various Ethernet Services, such as Ethernet Line (E-Line) and Ethernet LAN (E-LAN)
services. Requirements are derived from Metro Ethernet Forum Technical Committee documents."
Download
Reference Presentation
The MEF has prepared an overview presentation which explains the MEF 9 ATS.
Download
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
MEF 14
Abstract Test Suite for Traffic Management Phase 1
MEF 14 is a specification document developed by the Technical Committee of the MEF that provides an Abstract Test Suite
for testing traffic management at the UNI.
Abstract:
"This document defines the requirements and corresponding test procedures for Service Performance and Bandwidth
Profile Service Attributes that may be specified as part of a Service Level Specification (SLS) for an Ethernet Service.
Requirements are derived from Metro Ethernet Forum Technical Committee documents."
Download
Reference Presentation
The MEF has prepared an overview presentation which explains the MEF 14 Abstract Test Suite.
Download
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
MEF 18
Abstract Test Suite for Circuit Emulation Services over Ethernet
MEF 18 is a specification document developed by the Technical Committee of the MEF that provides an Abstract Test Suite
for testing circuit emulation services over Ethernet based on MEF 8.
Abstract:
"This document describes a set of test procedures for evaluating the conformance of equipment for delivering Circuit
Emulation Services over Ethernet (CESoETH) to the MEF 8 Implementation Agreement."
Download
Reference Presentation
The MEF has prepared an overview presentation which explains the MEF 6.1 specification.
Download
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Download
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Figure 1.1.F1: 5 Attributes of Carrier Figure 1.1.F2: Typical Carrier Figure 1.2.F1: E-Line Carrier
Ethernet Ethernet Network Ethernet service type
Figure 1.2.F2: E-LAN Carrier Ethernet Figure 1.2.F3: E-Tree Carrier Ethernet Figure 1.3.F1: Example EVP-Tree
service type service type
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
2.1.3.1.F2 -
Encapsulation of an
Ethernet frame inside
GFP-F frame
2.1.3.1.T1 - SONET/SDH Support for 2.1.3.2.T1 - OTN Support for Carrier
Carrier Ethernet Services Ethernet Services
2.1.3.3.F1 - WDM
2.1.3.3.T1 - WDM
Support for Carrier
Ethernet Services
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
3.1.3.F1 - Carrier Ethernet over 3.1.3.F2 - Access Technologies for 3.1.4.F1 - Carrier Ethernet over
Packet Wireless Carrier Ethernet Mobile Backhaul DS3/E3
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Figure 4.1.F1 - Subscribers, Service Figure 4.2.F1 - Basic Service Model Figure 4.2.F2 - UNI-C and UNI-N
Providers and Operators per MEF 10.2
Figure 4.2.F3 - EPL EVC Figure 4.2.F4 - ENNI Figure 4.2.F5 - EVC and multiple OVCs
Figure 4.2.F7 - UNI Entities Figure 4.2.F6 - ENNI-Ns Figure 4.3.F1 - MEF 26 Model
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Figure 5.3.F1 - Mapping CE-VLAN IDs to Figure 5.3.T1 - Mapping CE-VLAN IDs
EVCs to EVCs
Figure 5.3.F2 - Mapping CE-VLAN IDs to Figure 5.4.F1 - Preserving Customer Figure 5.4.F2 - CE-VLAN ID
EVCs VLAN-IDs Preservation Example
Figure 5.4.T1 - Protocols Figure 5.4.T2 - EVCs and CoS ID Figure 5.5.F1 - Operator to Operator
example ENNI
Figure 5.5.T1 - ENNI Frame Tags Figure 5.6.1.F2 - Service Frame in Figure 5.6.T1 - Correspondence
Hairpin Switching between Ingress and Egress
Figure 5.6.T2 - Correspondence Ingress Figure 5.6.T3 - CE-VLAN CoS Figure 5.7.T1 - H, M, L - Green Color
to Egress 2 Preservation
Figure 5.7.T2 - H, M, L - Yellow Color Figure 5.7.T3 - Ingress Bandwidth Figure 5.7.F1 Bandwidth Profile per
Profile Compliance OVC
Figure 5.8.F1 - Ingress Bandwidth Profile Figure 5.8.F2 - Ingress Bandwidth Figure 5.8.F3 - Ingress Bandwidth
Per Ingress UNI Per EVC Profile Per CoS ID
Figure 5.8.F7 - Burst Threshold Figure 5.8.F8 - EP-LAN Application Figure 5.8.T1 - Example EP-LAN
Attributes
Figure 5.10.F1. - One way frame delay Figure 5.10.F2 - Inter frame delay Figure 5.10.F3 - Frame loss ratio
variation
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Figure 7.1.F1: Example - Turbo 2000 Table 7.1.T1: Example - UNI Service Table 7.1.T2: Example - EVC Service
Attributes
Internet Access, Inc. Attributes
Table 7.1.T3: Example - EVC per UNI Figure 7.2.F1 Figure 7.2.F3
Service Attributes
Table 7.3.1.T1 - EVC per EVP-Line Table 7.3.1.T2 - EVC ID at RAN NC Figure 1 (7.3.2.F1) - Generic
UNI-NI Interworking Function with Legacy
MBH Network
Figure 2 (7.3.2.F2) - Generic Figure 3 (7.3.2.F3) - UNI with MBH Figure 4 (7.3.2.F4) - UNI without
Legacy Network Legacy MBH Network
Interworking Function without Legacy
Network
Figure 7.6.F2 - Carrier Ethernet Figure 7.6.T1 - Table of CE-VLAN ID Figure 7.7.F1 - 3 E-Lines replace WDM
replacing ATM-FR per EVC
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
Figure 9.1.2.F1
Figure 9.1.2.F1
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
10.4.1.F1 - Performance
monitoring definition
10.5.2.T2 Class of
Service Label Model
10.5.2.T3 Class of
Table 3
Service Label Model
Table 4
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
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
provided showing use cases of some of the defined services."
Download
Reference Presentation
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Technical Specification
MEF 6.1
April, 2008
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the
following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is
authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
Disclaimer
The information in this publication is freely available for reproduction and use by any recipient
and is believed to be accurate as of its publication date. Such information is subject to change
without notice and the Metro Ethernet Forum (MEF) is not responsible for any errors. The MEF
does not assume responsibility to update or correct any information in this publication. No
representation or warranty, expressed or implied, is made by the MEF concerning the
completeness, accuracy, or applicability of any information contained herein and no liability of
any kind shall be assumed by the MEF as a result of reliance upon such information.
The information contained herein is intended to be used without modification by the recipient or
user of this document. The MEF is not responsible or liable for any modifications to this
document made by any other party.
The receipt or any use of this document or its contents does not in any way create, by implication
or otherwise:
(a) any express or implied license or right to or under any patent, copyright, trademark or
trade secret rights held or claimed by any MEF member company which are or may be
associated with the ideas, techniques, concepts or expressions contained herein; nor
(b) any warranty or representation that any MEF member companies will announce any
product(s) and/or service(s) related thereto, or if such announcements are made, that
such announced product(s) and/or service(s) embody any or all of the ideas,
technologies, or concepts contained herein; nor
(c) any form of relationship between any MEF member companies and the recipient or
user of this document.
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the
following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is
authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
Table of Contents
1. ABSTRACT ...............................................................................................................................................................1
2. TERMINOLOGY......................................................................................................................................................1
3. SCOPE........................................................................................................................................................................6
3.1 SCOPE OF FUTURE PHASES ...................................................................................................................................6
4. COMPLIANCE LEVELS.........................................................................................................................................7
5. INTRODUCTION .....................................................................................................................................................7
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page i
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
List of Figures
Figure 1: Ethernet Service Definition Framework........................................................................................................8
Figure 2: E-Line Service type using Point-to-Point EVC...........................................................................................10
Figure 3: E-LAN Service type using Multipoint-to-Multipoint EVC.........................................................................12
Figure 4: E-Tree Service type using Rooted-Multipoint EVC....................................................................................14
Figure 5: E-Tree Service type using Multiple Roots ..................................................................................................15
Figure 6: Ethernet Private Line (EPL) Service ...........................................................................................................17
Figure 7: Ethernet Virtual Private Line (EVPL) Service............................................................................................20
Figure 8: Ethernet Private LAN (EP-LAN) Service ...................................................................................................23
Figure 9: Ethernet Virtual Private LAN (EVP-LAN) Service ....................................................................................26
Figure 10: Ethernet Private Tree (EP-Tree) Service...................................................................................................28
Figure 11: Ethernet Virtual Private Tree (EVP-Tree) Service....................................................................................31
Figure 12: Example of Transport-Oriented Private Data Network Interconnect Using the EPL Service...................45
Figure 13: Example of Transport-Oriented Public Data Network Interconnect Using the EPL Service. ...................47
Figure 14: Example of Video Broadcast Delivery Using the EP-Tree Service ..........................................................50
Figure 15: Example of Distance Learning and Business Data Using EVP-LAN and EVP-Tree Services .................52
List of Tables
Table 1: Terminology and Definitions Table................................................................................................................6
Table 2: Ethernet Services ............................................................................................................................................8
Table 3: UNI service attributes and parameter values for all service types ..................................................................9
Table 4: E-Line Service type EVC per UNI service attributes and parameter values ................................................11
Table 5: E-Line Service type EVC service attributes and parameter values ..............................................................11
Table 6 : E-LAN Service type EVC per UNI service attributes and parameter values................................................13
Table 7: E-LAN Service type EVC service attributes and parameter values..............................................................14
Table 8 : E-Tree Service type EVC per UNI service attributes and parameter values ................................................16
Table 9: E-Tree Service type EVC service attributes and parameter values ..............................................................16
Table 10: UNI service attributes and parameters for the EPL service ........................................................................18
Table 11: EVC per UNI service attributes and parameters for the EPL service .........................................................18
Table 12: EVC service attributes and parameters for the EPL service .......................................................................19
Table 13: Differences in EPL from EPL in MEF 6 ....................................................................................................19
Table 14: UNI service attributes and parameters for EVPL service ...........................................................................21
Table 15: EVC per UNI service attributes and parameters for EVPL service ............................................................21
Table 16: EVC service attributes and parameters for the EVPL service ....................................................................22
Table 17: Differences in EVPL from EVPL in MEF 6...............................................................................................22
Table 18: UNI service attributes and parameters for the EP-LAN service .................................................................24
Table 19: EVC per UNI service attributes and parameters for the EP-LAN service..................................................24
Table 20: EVC service attributes and parameters for the EP-LAN service ................................................................25
Table 21: UNI service attributes and parameters for the EVP-LAN service ..............................................................26
Table 22: EVC per UNI service attributes and parameters for the EVP-LAN service ...............................................27
Table 23: EVC service attributes and parameters for the EVP-LAN service .............................................................28
Table 24: UNI service attributes and parameters for the EP-Tree service..................................................................29
Table 25: EVC per UNI service attributes and parameters for the EP-Tree service...................................................30
Table 26: EVC service attributes and parameters for the EP-Tree service.................................................................31
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page ii
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
Table 27: UNI service attributes and parameters for the EVP-Tree service...............................................................32
Table 28: EVC per UNI service attributes and parameters for the EVP-Tree service................................................32
Table 29: EVC service attributes and parameters for the EVP-Tree service ..............................................................33
Table 30: List of Standardized Layer 2 Control Protocols .........................................................................................33
Table 31: L2CP Processing Requirements for the EPL Service .................................................................................35
Table 32: L2CP Processing Requirements for the EVPL Service ..............................................................................35
Table 33: L2CP Processing Requirements for the EP-LAN Service ..........................................................................36
Table 34: L2CP Processing Requirements for the EVP-LAN Service .......................................................................36
Table 35: L2CP Processing Requirements for the EP-Tree Service...........................................................................37
Table 36: L2CP Processing Requirements for the EVP-Tree Service ........................................................................37
Table 37: MEF and IEEE 802.1 terms for L2CP Processing Options ........................................................................42
Table 38: EVC Performance Attributes and Parameters per CoS Offering................................................................43
Table 39: L2CP Attribute and Parameters per Service Offering ................................................................................44
Table 40: UNI attributes for the Private Data Networking example using EPL Service ............................................45
Table 41: EVC per UNI attributes for the private data networking example using EPL Service ...............................46
Table 42: EVC service attributes for the private data networking example using the EPL Service ...........................46
Table 43: UNI attributes for the Private Data Networking example using EPL Service ............................................48
Table 44: EVC per UNI attributes for the public data networking example using EPL Service ................................48
Table 45: EVC service attributes for the public data networking example using the EPL Service ............................49
Table 46: UNI attributes for the video broadcast example using EP-Tree Service ....................................................50
Table 47: EVC per UNI attributes for the video broadcast example using EP-Tree Service .....................................51
Table 48: EVC service attributes for the video broadcast example using EP-Tree Service .......................................51
Table 49: UNI attributes for the distance learning, business data example ................................................................52
Table 50: EVC per UNI attributes for the distance learning, business data example .................................................53
Table 51: EVC attributes for the distance learning, business data example ...............................................................54
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page iii
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
1. Abstract
This document uses the service attributes and parameters that are defined in the MEF Technical
Specification Ethernet Services Attributes Phase 2 [2] and applies them to create different
Ethernet services. This document defines three generic service constructs called Ethernet
Service types and specifies their associated service attributes and parameters used to create
Point-to-Point, Multipoint-to-Multipoint, and Rooted-Multipoint Ethernet services. This
document also defines the requirements for several Ethernet services that use these generic
Ethernet Service types. In addition, an informative appendix is provided showing examples of
some of the defined services. This document supersedes and replaces MEF 6, Ethernet Services
Definitions - Phase 1 [1].
2. Terminology
This section defines the terms used in this document. In many cases, the normative definitions to
terms are found in other documents. In these cases, the third column is used to provide the
reference that is controlling.
Term Definition Reference
All to One A UNI attribute in which all CE-VLAN IDs are associated [2]
Bundling with a single EVC.
Availability A measure of the percentage of time that a service is useable. [2]
Performance
A characterization of Service Frame arrival times and [2]
lengths at a reference point and a specification of the
Bandwidth Profile disposition of each Service Frame based on its level of
compliance with the Bandwidth Profile. In this document
the reference point is the UNI.
Bandwidth profile [2]
A bandwidth profile applied on a per-Class of Service basis.
per CoS ID
Bandwidth profile [2]
A bandwidth profile applied on a per-EVC basis.
per EVC
Bandwidth profile [2]
A bandwidth profile applied on a per-UNI basis.
per UNI
Broadcast Service A Service Frame that has the broadcast destination MAC [2]
Frame address.
A UNI attribute in which more than one CE-VLAN ID can [2]
Bundling
be associated with an EVC.
CBS Committed Burst Size [2]
CE Customer Edge [2]
CE-VLAN CoS Customer Edge VLAN CoS [2]
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 1
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 2
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 3
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 4
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 5
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
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.
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 6
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
4. Compliance Levels
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT,
SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this
document are to be interpreted as described in RFC 2119 [6]. All key words use upper case, bold
text.
5. Introduction
Ethernet has its origins in providing network connectivity and was not originally used to provide
wide area services. With the introduction of Metro Ethernet services, Service Providers started
using this Ethernet connectivity technology to provide Ethernet services. While the IEEE
802.3 Ethernet protocol is still used, service-related attributes and parameters need to be added in
order to create an Ethernet service.
This document uses the service attributes and parameters that are defined in the MEF Technical
Specification Ethernet Services Attributes Phase 2 [2] and applies them to create different
Ethernet services. This document defines three generic service constructs called Ethernet
Service types and specifies their associated service attributes and parameters used to create
Point-to-Point, Multipoint-to-Multipoint, and Rooted-Multipoint Ethernet services. This
document also defines the requirements for several Ethernet services that use these generic
Ethernet Service types.
The Phase 2 Ethernet services described in this document are from a Subscriber perspective and
are defined based on the service attributes that might appear in a Service Level Agreement
(SLA) or Service Level Specification (SLS). The services are instantiated at an UNI with IEEE
compliant Ethernet interfaces interconnecting the customer equipment to the Service Provider
network. These services, however, are agnostic of the underlying network infrastructure within
the Metro Ethernet Network (MEN) and may be supported over a combination of network
technologies in the Service Providers network that could include: MPLS, RPR, SONET, VLAN
switching, WDM, etc.
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 7
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
More than one Ethernet Service is defined for each of the three Ethernet Service types. These
are differentiated by the method for service identification used at the UNIs. Services using All to
One Bundling UNIs (port-based) are referred to as Private, while services using UNIs that are
that are Service Multiplexed (VLAN-based), are referred to as Virtual Private. This
relationship is shown in Table 2 below.
Port-Based VLAN-Based
Service Type
(All to One Bundling) (EVC identified by VLAN ID)
E-Line Ethernet Private Line Ethernet Virtual Private Line
(point-to-point EVC) (EPL) (EVPL) 1
E-LAN Ethernet Private LAN Ethernet Virtual Private LAN
(multipoint-to-multipoint EVC) (EP-LAN) (EVP-LAN)
E-Tree Ethernet Private Tree Ethernet Virtual Private Tree
(rooted multipoint EVC) (EP-Tree) (EVP-Tree)
Table 2: Ethernet Services
Please note that although some of the service names used in Table 2 and throughout this
document are the same as names used in ITU-T G.8011.1 [13] and G.8011.2 [14], namely EPL
and EVPL, the definitions of those services are different due to the fact that the ITU
recommendations take a network view instead of the services view used in this document.
Table 3 below specifies the UNI service attributes, parameters, and values that are common for
all Ethernet service types. The first column of this table identifies the UNI service attributes, as
defined in [2]. The entries in the second column specify the UNI requirements, regardless of the
1
EVPL as specified in this document is different from EVPL as was specified in [1]. In this document, EVPL cannot
have All to One Bundling at the UNIs while in [1] All to One Bundling was allowed at the UNIs in EVPL.
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 8
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
number of EVCs present on the UNI. These requirements allow for options for certain UNI
attributes, e.g., physical medium, speed, maximum number of EVCs, application of ingress and
egress bandwidth profiles, and layer 2 control protocol processing. Please note that such options
may be different at each UNI in the EVC.
UNI Service Attribute Requirement
UNI Identifier Arbitrary text string to identify the UNI.
Physical Medium UNI Type 2 Physical Interface [5] except for PON interfaces 2
10 Mbps, 100 Mbps, 10/100 Mbps Auto-negotiation, 10/100/1000
Speed
Mbps Auto-negotiation, 1 Gbps, or 10 Gbps.
Mode Full Duplex
MAC Layer IEEE 802.3-2005 [5]
UNI MTU Size MUST be 1522.
Service Multiplexing Yes or No. MUST be No if All to One Bundling is Yes.
Bundling Yes or No. MUST be No if All to One Bundling is Yes.
Yes or No. MUST be No if Bundling or Service Multiplexing is
All to One Bundling
Yes.
CE-VLAN ID for untagged MUST specify CE-VLAN ID for untagged and priority tagged
and priority tagged Service Service Frames in the range of 1-4094. This requirement does not
Frames apply for services with all to one bundling at the UNI.
Maximum number of
MUST be an integer 1.
EVCs
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR,
Ingress Bandwidth Profile
EBS, CM, CF>. MUST NOT be combined with any other type of
Per UNI
ingress bandwidth profile.
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR,
Egress Bandwidth Profile
EBS, CM, CF>. MUST NOT be combined with any other type of
Per UNI
egress bandwidth profile.
Layer 2 Control Protocols For each protocol, MUST specify one of: Peer, Discard, Pass to
Processing EVC, or Peer and Pass to EVC.
Table 3: UNI service attributes and parameter values for all service types
The following subsections define each of the three service types. Section 7 normatively defines
the Ethernet services.
2
MEF does not support Ethernet services over PON interfaces.
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 9
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
Point-to-Point EVC
UNI UNI
Metro Ethernet
Network
The E-Line Service type UNI service attributes, parameters, and values can be found in Table 3.
The E-Line Service type EVC per UNI service attributes, parameters, and values can be found in
Table 4 below. The first column of this table comes from [2]. The entries in the second column
define the E-Line Service type.
EVC per UNI Service
E-Line Service type Requirement
Attribute
A string formed by the concatenation of the UNI ID and the EVC
UNI EVC ID
ID.
MUST specify the mapping table of CE-VLAN IDs to the EVC at
CE-VLAN ID / EVC Map
the UNI.
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR,
Ingress Bandwidth Profile
EBS, CM, CF>. MUST NOT be combined with any other type of
Per EVC
ingress bandwidth profile.
OPTIONAL. If supported, MUST specify CoS ID per [2],
Ingress Bandwidth Profile section 6.8, and MUST specify <CIR, CBS, EIR, EBS, CM, CF>
Per CoS Identifier for each CoS. MUST NOT be combined with any other type of
ingress bandwidth profile.
Egress Bandwidth Profile
MUST NOT specify 3 .
Per EVC
3
For E-Line services, it is expected that an Ingress Bandwidth Profile will be applied at the ingress UNI such that
traffic on the EVC is already controlled; therefore, there is no need to apply an Egress Bandwidth Profile per EVC
or CoS at the egress UNI.
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 10
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 11
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
Any Ethernet Service that is based upon a Multipoint-to-Multipoint EVC SHALL be designated
as an Ethernet LAN (E-LAN) Service type. The E-LAN service type is illustrated in Figure 3
below.
Multipoint-to-Multipoint EVC
UNI
UNI
UNI
UNI
Metro Ethernet
Network
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.
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 13
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
Root UNI
Leaf UNI
Leaf UNI
In more sophisticated forms, an E-Tree Service type may support two or more Root UNIs. In
this scenario, each Leaf UNI can exchange data only with the Root UNIs. As well, the Roots can
communicate with each other. In such a service, redundant access to the Root can also be
provided, effectively allowing for enhanced service reliability and flexibility. This service is
depicted in Figure 5 below.
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 14
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
Rooted-
Multipoint EVC
To Leaf UNIs
The E-Tree service type UNI Service Attributes and requirements can be found in Table 3.
The E-Tree service type EVC per UNI service attributes and requirements can be found in Table
8 below. The first column of this table comes from [2]. The entries in the second column define
the E-Tree Service type.
EVC per UNI
E-Tree EVC per UNI Service type Requirement
Service Attribute
UNI EVC ID A string formed by the concatenation of the UNI ID and the EVC ID.
CE-VLAN ID / EVC MUST specify the mapping table of CE-VLAN IDs to the EVC at the
Map UNI.
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR, EBS, CM,
Ingress Bandwidth
CF> [2]. MUST NOT be allowed if any other ingress bandwidth
Profile Per EVC
profile is applied at this UNI for this EVC.
OPTIONAL. If supported, MUST specify CoS ID per [2], section 6.8,
Ingress Bandwidth
and MUST specify <CIR, CBS, EIR, EBS, CM, CF> for each CoS.
Profile Per CoS
MUST NOT be combined with any other type of ingress bandwidth
Identifier
profile.
OPTIONAL. If supported, MUST specify <CIR, CBS, EIR, EBS, CM,
Egress Bandwidth
CF> [2]. MUST NOT be combined with any other type of egress
Profile Per EVC
bandwidth profile.
OPTIONAL. If supported, MUST specify CoS ID per [2], section 6.8,
Egress Bandwidth
and MUST specify <CIR, CBS, EIR, EBS, CM, CF> for each CoS.
Profile Per CoS
MUST NOT be combined with any other type of egress bandwidth
Identifier
profile.
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 15
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
Table 8 : E-Tree Service type EVC per UNI service attributes and parameter values
The E-Tree service type EVC service attributes, parameters, and values can be found in Table 9
below. The first column of this table comes from [2]. The entries in the second column define
the E-Tree Service type.
EVC Service Attribute E-Tree EVC Service type Requirement
EVC Type MUST be Rooted-Multipoint
An arbitrary string, unique across the MEN, for the EVC supporting
EVC ID
the service instance.
MUST provide the list of UNI Identifiers and type for each UNI
UNI List associated with the EVC. The number of Root UNIs in the list
MUST be 1. The number of Leaf UNIs in the list MUST be 0 4 .
Maximum Number of
MUST be 2
UNIs
EVC MTU size MUST be minimum of UNI MTU sizes.
CE-VLAN ID
MUST be either Yes or No
Preservation
CE-VLAN CoS
MUST be either Yes or No
Preservation
Unicast Service Frame Deliver Unconditionally or Deliver Conditionally. If Delivered
Delivery Conditionally, MUST specify the delivery criteria.
Multicast Service Frame Deliver Unconditionally or Deliver Conditionally. If Delivered
Delivery Conditionally, MUST specify the delivery criteria.
Broadcast Service Frame Deliver Unconditionally or Deliver Conditionally. If Delivered
Delivery Conditionally, MUST specify the delivery criteria.
Layer 2 Control Protocol
Processing (only applies For each protocol passed to the EVC, MUST specify one of: Tunnel
for L2CPs passed to the or Discard
EVC)
At least one CoS is REQUIRED. MUST specify CoS ID, per
section 6.8 of [2]. MUST list values for each of the following
EVC Performance attributes {Frame Delay, Frame Delay Variation, Frame Loss Ratio,
and Availability} for each CoS, where Not Specified (N/S) is an
acceptable value.
Table 9: E-Tree Service type EVC service attributes and parameter values
7. Service Definitions (Normative)
An Ethernet service is defined by specifying service attribute parameter values for a given
Ethernet Service type. This section defines the required service attributes and related parameter
values for the Ethernet services specified in this Technical Specification. If any of the Ethernet
4
An E-Tree service may have no leaves, for example, during times when leaf UNIs are being added or removed.
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 16
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
services in this section are offered, the normative text for each service attribute is applied. Note
that other variations of these Ethernet services are also possible.
UNI UNI
For cases where EVC speed is less than the UNI speed, the CE is expected to shape traffic to the
Ingress Bandwidth Profile of the service such that all of its traffic, including certain L2CPs that
require delivery for proper operation, is not discarded by the service.
Table 10 provides the UNI service attributes, parameters, and values for the Ethernet Private
Line.
UNI Service Attribute Service Attribute Parameters and Values
UNI Identifier Arbitrary text string to identify the UNI.
Physical Medium UNI Type 2 Physical Interface [5] except for PON interfaces
10 Mbps, 100 Mbps, 10/100 Mbps Auto-negotiation,
Speed
10/100/1000 Mbps Auto-negotiation, 1 Gbps, or 10 Gbps
Mode MUST be Full Duplex
MAC Layer IEEE 802.3-2005 [5]
UNI MTU Size MUST be 1522
Service Multiplexing MUST be No
Bundling MUST be No
All to One Bundling MUST be Yes
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 17
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
5
See Ingress Bandwidth Profile per EVC service attribute in Table 11.
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 18
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 19
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
An Ethernet Virtual Private Line (EVPL) is created using an E-Line Service type. An EVPL can
be used to create services similar to the Ethernet Private Line (EPL) with some notable exceptions.
First, an EVPL allows for service multiplexing at the UNI. This capability allows more than one
EVC to be supported at the UNI where the EPL does not allow this. Second, an EVPL need not
provide as much transparency of Service Frames as with an EPL. Because service multiplexing is
permitted, some Service Frames may be sent to one EVC while other Service Frames may be sent to
other EVCs.
Service
Multiplexing
Blue
EVC
Yellow Green
EVC EVC
Metro Ethernet
Network
Service
Multiplexing
Blue
EVC
Yellow Green
EVC EVC
Metro Ethernet
Network
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 20
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 21
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 22
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
MP2MP EVC
Metro Ethernet
Network
MP2MP EVC
Metro Ethernet
Network
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 23
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 24
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
Bundling may or may not be used on the UNIs in the Multipoint-to-Multipoint EVC. As such,
CE-VLAN tag preservation and tunneling of certain Layer 2 Control Protocols may or may not
be provided. Figure 9 below shows the basic structure of EVP-LAN service. In this example,
the customer uses an EVP-LAN Service (red EVC) for providing multipoint data connectivity,
and an EVPL Service (blue EVC) for accessing value-add services from one of the UNIs.
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 25
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
Value-add
Service
P2P EVC
MP2MP EVC
Metro Ethernet
Network
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 26
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 27
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
RMP EVC
Metro Ethernet
Network
RMP EVC
Metro Ethernet
Network
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 28
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 29
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 30
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
Table 26: EVC service attributes and parameters for the EP-Tree service
7.6 ETHERNET VIRTUAL PRIVATE TREE SERVICE
Some subscribers desire access to certain applications or content services from well-defined
access points within their own (or an external) network. In this case it is necessary to
interconnect the participating UNIs in a Rooted-Multipoint connection to the well-defined access
(or root) point. One or more of the Subscribers UNIs may also support other services, e.g.,
EVPL or EVP-LAN. For such cases, the EVP-Tree service is used.
Bundling may or may not be used on the UNIs in the Rooted-Multipoint EVC. As such, CE-
VLAN tag preservation and tunneling of certain Layer 2 Control Protocols may or may not be
provided. Figure 11 below shows the basic structure of EVP-Tree service. In this example, a
customer has EVP-LAN service (red EVC) providing data connectivity among three UNIs, while
using EVP-Tree service (green EVC) for providing video broadcast from a video hub location.
Metro Ethernet
Network
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 31
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
Within the context of this document, a Layer 2 Control Protocol is identified by one of the
following MAC Destination Addresses:
MAC DAs Layer 2 Control Protocol
01-80-C2-00-00-00 through 01-80-C2-00-00-0F Bridge Block of protocols
01-80-C2-00-00-20 through 01-80-C2-00-00-2F GARP Block of protocols
Table 30: List of Standardized Layer 2 Control Protocols
For each service, protocols are configured to tunnel, peer, or discard at the UNI.
Classification of which L2CP frames to tunnel will examine only the MAC Destination Address
(DA) of the Service Frame. Note that for cases in which more than one protocol uses the same
MAC DA (e.g., LACP and Link OAM), then the required action related to tunneling is the same.
Since multiple protocols may share the same MAC DA, classification of which L2CP frames to
peer will examine both the MAC DA and the protocol identifiers (e.g. Ethertype, Slow-protocol
sub-type).
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 33
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
In this section, Discard means that the MEN will discard ingress L2CP frames of a given
<protocol, DA> pair and will not generate that <protocol, DA> pair on egress from the MEN.
Peer means that the MEN will actively participate with the protocol if the DA is as specified.
These L2CPs are: LACP/LAMP, Link OAM, Port Authentication, and E-LMI,. Tunnel means
that frames are transparently passed to a given EVC for transport across the MEN to the
destination UNI(s).
If a given protocol uses a MAC Destination Address (DA) other than that specified in the
following subsections, and outside the block of the reserved MAC DAs (16 bridge block, 16
GARP block), then it SHOULD be treated as normal data.
If a given protocol uses a MAC DA other than that specified in the following subsections, but
within the block of the reserved MAC DAs (16 bridge block, 16 GARP block), then the
requirements are left for further study.
These recommendations are designed to be consistent with a standard Provider Bridge [10]
implementation. The Provider Bridge specification allows for subscribers that may want to
deviate from these recommendations by providing a default set of standard destination MAC
addresses that could be used to determine either peering or tunneling for a specific L2CP. See
Section 11, for more discussion of how the MEF terminology maps to IEEE 802.1 terminology
with respect to L2CP processing.
The tables in the following subsections summarize the Layer 2 Control Protocol (L2CP)
Processing requirements for the indicated services. For an ingress Service Frame with the given
destination MAC address and the given protocol, the required actions for the service are
specified together with the applicability of the requirement, i.e., whether it applies to all UNIs in
the EVC or is applied on a per-UNI basis.
Please note that while [1] included requirements for All Bridges, requirements for this protocol
are not included in this document. The All LANs Bridge Management Group Address (01-80-
C2-00-00-10) has been officially deprecated in 802.1Q-2005, subclause 8.13.7. In the unlikely
event that a customer may use this MAC DA, MEF services are expected to treat them as normal
service frames.
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 34
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
SHOULD SHOULD
PAUSE[5] 01-80-C2-00-00-01 All UNIs in the EVC
Discard Discard
Option 1: Per UNI
SHOULD Peer SHOULD
LACP/LAMP[5] 01-80-C2-00-00-02 Option 2: All UNIs in
or Discard Tunnel
the EVC
Option 1: Per UNI
SHOULD Peer SHOULD
Link OAM[5] 01-80-C2-00-00-02 Option 2: All UNIs in
or Discard Tunnel
the EVC
Option 1: Per UNI
SHOULD Peer SHOULD
Port Authentication[7] 01-80-C2-00-00-03 Option 2: All UNIs in
or Discard Tunnel
the EVC
Option 1: Per UNI
SHOULD Peer
E-LMI[9] 01-80-C2-00-00-07 MUST Tunnel Option 2: All UNIs in
or Discard
the EVC
SHOULD
LLDP[8] 01-80-C2-00-00-0E MUST Tunnel All UNIs in the EVC
Discard
01-80-C2-00-00-20
MUST Discard
GARP[4]/MRP[17] Block through MUST Tunnel All UNIs in the EVC
or Tunnel
01-80-C2-00-00-2F
Table 31: L2CP Processing Requirements for the EPL Service
8.2 L2CP REQUIREMENTS FOR ETHERNET VIRTUAL PRIVATE LINE (EVPL) SERVICE
Table 32 specifies the L2CP processing requirements for EVPL service. The first column
identifies the standard protocol, and the second column identifies the MAC DA used to carry that
protocol data unit. The third column specifies the required action, and the fourth column
specifies the applicability, i.e., whether the action taken must be the same at all UNIs in the
EVC, or the action taken can be different on different UNIs in the EVC.
Protocol MAC DA L2CP Requirement Applicability
STP[3]/RSTP[3]/MSTP[4] 01-80-C2-00-00-00 MUST Peer or Discard All UNIs in the EVC
PAUSE[5] 01-80-C2-00-00-01 MUST Discard All UNIs in the EVC
LACP/LAMP[5] 01-80-C2-00-00-02 MUST Peer or Discard Per UNI
Link OAM[5] 01-80-C2-00-00-02 MUST Peer or Discard Per UNI
Port Authentication[7] 01-80-C2-00-00-03 MUST Peer or Discard Per UNI
E-LMI[9] 01-80-C2-00-00-07 MUST Peer or Discard Per UNI
LLDP[8] 01-80-C2-00-00-0E MUST Discard All UNIs in the EVC
01-80-C2-00-00-20
MUST Peer, Tunnel or
GARP[4]/MRP[17] Block through Per UNI
Discard
01-80-C2-00-00-2F
Table 32: L2CP Processing Requirements for the EVPL Service
8.3 L2CP REQUIREMENTS FOR ETHERNET PRIVATE LAN (EP-LAN) SERVICE
Table 33 specifies the L2CP processing requirements for EP-LAN service. The first column
identifies the standard protocol, and the second column identifies the MAC DA used to carry that
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 35
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
protocol data unit. The third column specifies the required action, and the fourth column
specifies the applicability, i.e., whether the action taken must be the same at all UNIs in the
EVC, or the action taken can be different on different UNIs in the EVC.
Protocol MAC DA L2CP Requirement Applicability
SHOULD Tunnel
STP[3]/RSTP[3]/MSTP[4] 01-80-C2-00-00-00 All UNIs in the EVC
MAY Discard
PAUSE[5] 01-80-C2-00-00-01 MUST Discard All UNIs in the EVC
LACP/LAMP[5] 01-80-C2-00-00-02 MUST Peer or Discard Per UNI
Link OAM[5] 01-80-C2-00-00-02 MUST Peer or Discard Per UNI
Port Authentication[7] 01-80-C2-00-00-03 MUST Peer or Discard Per UNI
E-LMI[9] 01-80-C2-00-00-07 MUST Peer or Discard Per UNI
LLDP[8] 01-80-C2-00-00-0E MUST Discard All UNIs in the EVC
01-80-C2-00-00-20
MUST Peer, Tunnel or
GARP[4]/MRP[17] Block through Per UNI
Discard
01-80-C2-00-00-2F
Table 33: L2CP Processing Requirements for the EP-LAN Service
8.4 L2CP REQUIREMENTS FOR ETHERNET VIRTUAL PRIVATE LAN (EVP-LAN) SERVICE
Table 34 specifies the L2CP processing requirements for EVP-LAN service. The first column
identifies the standard protocol, and the second column identifies the MAC DA used to carry that
protocol data unit. The third column specifies the required action, and the fourth column
specifies the applicability, i.e., whether the action taken must be the same at all UNIs in the
EVC, or the action taken can be different on different UNIs in the EVC.
Protocol MAC DA L2CP Requirement Applicability
STP[3]/RSTP[3]/MSTP[4] 01-80-C2-00-00-00 MUST Peer or Discard All UNIs in the EVC
PAUSE[5] 01-80-C2-00-00-01 MUST Discard All UNIs in the EVC
LACP/LAMP[5] 01-80-C2-00-00-02 MUST Peer or Discard Per UNI
Link OAM[5] 01-80-C2-00-00-02 MUST Peer or Discard Per UNI
Port Authentication[7] 01-80-C2-00-00-03 MUST Peer or Discard Per UNI
E-LMI[9] 01-80-C2-00-00-07 MUST Peer or Discard Per UNI
LLDP[8] 01-80-C2-00-00-0E MUST Discard All UNIs in the EVC
01-80-C2-00-00-20
MUST Peer, Tunnel or
GARP[4]/MRP[17] Block through Per UNI
Discard
01-80-C2-00-00-2F
Table 34: L2CP Processing Requirements for the EVP-LAN Service
8.5 L2CP REQUIREMENTS FOR ETHERNET PRIVATE TREE (EP-TREE) SERVICE
Table 35 specifies the L2CP processing requirements for EP-Tree service. The first column
identifies the standard protocol, and the second column identifies the MAC DA used to carry that
protocol data unit. The third column specifies the required action, and the fourth column
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 36
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
specifies the applicability, i.e., whether the action taken must be the same at all UNIs in the
EVC, or the action taken can be different on different UNIs in the EVC.
Protocol MAC DA L2CP Requirement Applicability
SHOULD Tunnel 6
STP[3]/RSTP[3]/MSTP[4] 01-80-C2-00-00-00 All UNIs in the EVC
MAY Discard
PAUSE[5] 01-80-C2-00-00-01 MUST Discard All UNIs in the EVC
LACP/LAMP[5] 01-80-C2-00-00-02 MUST Peer or Discard Per UNI
Link OAM[5] 01-80-C2-00-00-02 MUST Peer or Discard Per UNI
Port Authentication[7] 01-80-C2-00-00-03 MUST Peer or Discard Per UNI
E-LMI[9] 01-80-C2-00-00-07 MUST Peer or Discard Per UNI
LLDP[8] 01-80-C2-00-00-0E MUST Discard All UNIs in the EVC
01-80-C2-00-00-20
MUST Peer, Tunnel or
GARP[4]/MRP[17] Block through Per UNI
Discard
01-80-C2-00-00-2F
Table 35: L2CP Processing Requirements for the EP-Tree Service
8.6 L2CP REQUIREMENTS FOR ETHERNET VIRTUAL PRIVATE TREE (EVP-TREE) SERVICE
Table 36 specifies the L2CP processing requirements for EVP-Tree service. The first column
identifies the standard protocol, and the second column identifies the MAC DA used to carry that
protocol data unit. The third column specifies the required action, and the fourth column
specifies the applicability, i.e., whether the action taken must be the same at all UNIs in the
EVC, or the action taken can be different on different UNIs in the EVC.
Protocol MAC DA L2CP Requirement Applicability
STP[3]/RSTP[3]/MSTP[4] 01-80-C2-00-00-00 MUST Peer or Discard All UNIs in the EVC
PAUSE[5] 01-80-C2-00-00-01 MUST Discard All UNIs in the EVC
LACP/LAMP[5] 01-80-C2-00-00-02 MUST Peer or Discard Per UNI
Link OAM[5] 01-80-C2-00-00-02 MUST Peer or Discard Per UNI
Port Authentication[7] 01-80-C2-00-00-03 MUST Peer or Discard Per UNI
E-LMI[9] 01-80-C2-00-00-07 MUST Peer or Discard Per UNI
LLDP[8] 01-80-C2-00-00-0E MUST Discard All UNIs in the EVC
01-80-C2-00-00-20
MUST Peer, Tunnel or
GARP[4]/MRP[17] Block through Per UNI
Discard
01-80-C2-00-00-2F
Table 36: L2CP Processing Requirements for the EVP-Tree Service
6
Since not all CEs in an E-Tree service will see all BPDUs, undesirable behavior can ensue. Service Providers
should be careful to warn Subscribers about attaching bridges to such a service and expecting STP work properly.
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 37
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
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.
Subscriber MD: The Subscriber MD, typically at levels 5-7, are allocated for the Subscriber
to use for managing the service within the Subscribers domain, e.g., from CE to CE.
Service Provider MD: The Service Provider MD, typically at levels 3-4, are allocated for the
Service Provider to use for managing the service within the Service Providers domain, e.g.,
from UNI-to-UNI.
Operator MD: The Operator MD, typically at levels 1-2, are allocated for the Operator to use
for managing the service from within the Operators domain.
UNI Maintenance Entity (UNI ME): The UNI ME, typically at level 0, is allocated for
managing the UNI link.
For the purpose of this section, only the Subscriber MD is considered. The Service Provider and
Operator MDs do not cross the UNI, hence are not involved in the definitions of the Ethernet
Services. In addition, requirements for the UNI ME will be addressed in future MEF
Implementation Agreements.
The Service Provider and Subscriber SHOULD agree on the allocation of one or more
Subscriber MD levels for a given Ethernet service.
Since the higher MD levels have wider scope, the agreed Subscriber MD levels MUST be higher
than any MD-levels used by the Service Provider to monitor that EVC.
For example, a Service Provider and Subscriber could agree on two Subscriber MD levels and,
therefore, agree on MD levels 6 and 7 for use by the Subscriber. This would leave MD level 5
for possible use by the Service Provider, in addition to the Service Provider MD levels outlined
before.
Also, a Service Provider MAY configure MIPs in the MEN at the lowest agreed Subscriber MD
level.
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 38
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
Requirements for the agreed upon Subscriber MD levels are specified in the following
subsections for each of three protocols: Continuity Check, Link Trace, and Loopback.
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).
The Subscriber MD Link Trace (LT) function allows the Subscriber to trace the path for a given
EVC across the entire service using a LT Message (LTM), which is sent on demand from one
MEP towards a target MEP (or a target MIP). If a MIP is configured inside the MEN at the same
MD level as set in the LTM, the MIP would respond with a LT Response (LTR) to the source
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 39
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
MEP, and relay the original LTM towards the target, with the TTL field decremented. We refer
to this process as peering. If there is no MIP configured inside the MEN, then the LTM is
expected to be tunneled through the service.
The MAC Destination Addresses reserved for LTs at MD levels 0-7 are specified in IEEE
802.1ag [11].
There are two sets of requirements for LT. The first scenario is where one or more MIPs are
configured in the MEN at an agreed Subscriber MD level. The other is the case where a MIP is
not configured in the MEN at an agreed Subscriber MD level.
For any of the Ethernet services defined in this document where at least one MIP is configured
inside the MEN at an agreed Subscriber MD level, a LT message at an agreed upon Subscriber
MD level with the corresponding MAC Destination Address MUST be peered or discarded. For
link trace, peering means that the MIP responds and the LT message is forwarded per the Service
OAM standards.
For any of the Ethernet services defined in this document where a MIP is not configured in the
MEN at an agreed Subscriber MD level, a LT message at an agreed upon Subscriber MD level
with the corresponding MAC Destination Address MUST be tunneled.
The Subscriber MD Loopback (LB) function allows the Subscriber to ping a target MEP or MIP
using an LB Message (LBM), which is sent on demand from one MEP towards the target MEP
or MIP. If a MIP is configured inside the MEN at the same MD level as set in the LBM, and if
the target for the LBM is the MIP itself, then the MIP would respond with a LB Response (LBR)
to the source MEP. We refer to this process as peering. If there is no MIP configured inside the
MEN, or if the target for the LBM is not any of the MIPs inside the MEN, then the LBM is
expected to be tunneled through the service.
An LBM may be sent with a unicast or multicast DA. In the case of multicast LBM, the MAC
DA values are the same as those for CCM. An LBR always uses a unicast DA. For cases where
a multicast DA is used in the LBM frame, the target is all MEPs in the MD. Any MIP along the
path is expected to ignore (relay) such a frame.
There are three sets of requirements for LB. The first scenario is where the Subscriber uses a
unicast MAC DA for the target and one or more MIPs are configured in the MEN at an agreed
Subscriber MD level. The second case is where the Subscriber uses a unicast MAC DA for the
target and a MIP is not configured in the MEN at an agreed Subscriber MD level. The third case
is where the Subscriber uses a multicast MAC DA for the target, regardless of whether there is a
MIP at an agreed Subscriber MD level or not configured in the MEN.
For any of the Ethernet services defined in this document where the Subscriber uses a unicast
MAC DA for the target and at least one MIP is configured inside the MEN at an agreed
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 40
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
Subscriber MD level, a LB message at an agreed upon Subscriber MD level with a target unicast
DA equal to the MAC address of a MIP in the MEN MUST be peered or discarded. Such a
control mechanism could be used by a Service Provider to minimize the impact of LBMs on the
MEN. A LB message at an agreed upon Subscriber MD level with a target unicast DA not equal
to the MAC address of any MIP inside the MEN MUST be tunneled.
For any of the Ethernet services defined in this document where the Subscriber uses a unicast
MAC DA for the target and a MIP is not configured inside the MEN at an agreed Subscriber MD
level, a LB message at an agreed upon Subscriber MD level MUST be tunneled.
For any of the Ethernet services defined in this document where the Subscriber uses a multicast
MAC DA for the target, a LB message at an agreed upon Subscriber MD level with the
corresponding MAC DA MUST be tunneled.
10. References
[1] MEF Technical Specification MEF 6, Ethernet Services Definitions - Phase I, June 2004
[2] MEF Technical Specification, MEF 10.1, Ethernet Services Attributes - Phase 2,
November 2006
[3] IEEE 802.1D-2004, Part 3: Media Access Control (MAC) Bridges
[4] IEEE 802.1Q 2005, Virtual Bridged Local Area Networks
[5] IEEE 802.3-2005, Part 3: Carrier sense multiple access with collision detection
(CSMA/CD) access method and physical layer specifications
[6] RFC 2119, Key words for use in RFCs to Indicate Requirement Levels, S. Bradner
[7] IEEE 802.1X 2004, Port-Based Network Access Control
[8] IEEE 802.1AB-2005, Station and Media Access Control, Connectivity Discovery
[9] MEF Technical Specification MEF 16, Ethernet Local Management Interface, January
2006
[10] IEEE 802.1ad-2005, Virtual Bridged Local Area Networks Amendment 4: Provider
Bridges
[11] IEEE 802.1ag-2007, Virtual Bridged Local Area Networks Amendment 5: Connectivity
Fault Management
[12] MEF Technical Specification MEF 4, Metro Ethernet Network Architecture Framework -
Part 1: Generic Framework, May 2004
[13] ITU-T Recommendation G.8011.1/Y.1307.1, Ethernet Private Line
[14] ITU-T Recommendation G.8011.2/Y.1307.2, Ethernet Virtual Private Line Service
[15] ITU-T Recommendation Y.1731, OAM functions and mechanisms for Ethernet based
networks
[16] MEF Technical Specification MEF 17, Service OAM Requirements & Framework
Phase 1, April 2007
[17] IEEE 802.1ak-2007, Virtual Bridged Local Area Networks, Amendment 07: Multiple
Registration Protocol
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 41
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
MEF defines these options in terms of service attributes, i.e., what the Subscriber can expect
end-to-end across the network. On the other hand, IEEE 802.1 defines terms local to a bridge
function, e.g., a Provider Bridge S-VLAN component must forward (relay) Subscriber spanning
tree frames. Since networks can be composed of different types of network elements, some of
which may be bridges and some not, there is a need for MEF terms to characterize the service
attributes, while understanding the Provider Bridge terms.
Some of the requirements in Section 8 of this document assume alignment with the IEEE
802.1ad, Provider Bridges [10] specification. This subsection is intended to provide a mapping
of MEF L2CP terms to IEEE 802.1 bridge terminology with respect to Layer 2 Control Protocol
(L2CP) processing options for the various L2CPs identified in this specification.
As defined in [2], MEF allows for three L2CP processing options for each L2CP. These are
briefly described below:
Peer means that the MEN will participate in the protocol.
Tunnel means that an ingress L2CP frame at a given UNI gets delivered unchanged to
each of the destination UNIs. The requirement is that all UNIs in the EVC must tunnel
the same protocols. In 802.1 terms, the L2CP is forwarded through the bridge relay.
Discard means that the MEN will ignore the L2CP frame, i.e., it will not participate in
the protocol and it will not forward the frame.
Table 37 summarizes the correlation of terms:
MEF Term IEEE 802.1 Term
Peer Participate
Tunnel Forward (relay)
Discard Not forward, Not participate
Table 37: MEF and IEEE 802.1 terms for L2CP Processing Options
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 42
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
Table 38 is used for defining an example of the EVC performance attributes, parameters, and
values associated with each of the Classes of Service offered by ACME. For simplicity, it is
assumed that the values for the performance parameters shown below apply to all Ethernet
services, i.e., E-Line, E-LAN, and E-Tree services. In actuality, Service Providers may offer
different CoS and associated performance attribute objectives for the three service types. Also,
since the objective values can be controversial and have wide variance among Service Providers,
actual numbers are not used for the objective values.
Table 38 is used as a reference for Ethernet Services in each of the examples in the following
subsections.
Example of Turbo-Charged Ethernet Services offered by the ACME Service Provider
EVC Performance Class of Service Offering
Parameters
Attribute Krypton Argon Neon
CoS ID (Priority Code Point
N/A PCP=5 PCP=4 PCP=0
value)
Subset of ordered UNI
All All All
pairs (S)
Frame Delay (FD) FD Objective X ms Y ms (Y>X) Z ms (Z>Y)
Percentile (P) 95% 95% 95%
Time interval (T) 1 hour 1 hour 1 hour
Subset of ordered UNI
All All All
pairs (S)
FDV objective Q ms N/S N/S
Frame Delay Variation (FDV)
Percentile (P) 95% N/S N/S
Time interval (T) 1 hour N/S N/S
Pair interval (t) 100 ms N/S N/S
Subset of ordered UNI
All All All
pairs (S)
Frame Loss Ratio (FLR)
FLR Objective A% B% (B>A) C% (C>B)
Time interval (T) 1 hour 1 hour 1 hour
Subset of UNI pairs (S) All All All
Availability Objective % % (< ) % (< )
Time interval (T) 1 month 1 month 1 month
Number of consecutive
1 1 1
small time intervals (n)
Availability
Small time interval (t) 2 minutes 2 minutes 2 minutes
Unavailability frame loss
50% 75% 100%
ratio threshold (Cu)
Availability frame loss
0% 25% 50%
ratio threshold (Ca)
Table 38: EVC Performance Attributes and Parameters per CoS Offering
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 43
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
In Table 38, the value All in the Subset of ordered UNI pairs entries, means that all possible
ordered pairs of UNIs are included in the offering. The reader is directed to [2] for precise
definitions of the CoS attributes and parameters.
Table 39 is used for defining the Layer 2 Control Protocol (L2CP) processing options used by a
given Service Provider at a UNI. Different L2CP processing options are used for All-to-One
Bundled (port-based services) and Service Multiplexed (VLAN-based services) UNIs. This table
is used as a reference for each of the examples in the following subsections. It is assumed that
the L2CP protocol and MAC address pair specified in Section 8 of this document is the one used
for the indicated protocol.
Port-based Services
Layer 2 Control Protocol VLAN-based Services
PB1 PB2
Spanning Tree Protocols Tunnel Tunnel Discard
PAUSE (802.3x) Discard Discard Discard
Discard (unprotected Tunnel
Discard (unprotected UNI)
LACP/LAMP UNI)
Peer (protected UNI)
Peer (protected UNI)
Link OAM Peer Tunnel Peer
Port Authentication (802.1x) Discard Tunnel Discard
E-LMI Peer Tunnel Peer
LLDP Discard Tunnel Discard
GARP/MRP Tunnel Tunnel Discard
Table 39: L2CP Attribute and Parameters per Service Offering
Since the subscriber wishes to manage its own packet network infrastructure the EPL service
must be configured to be highly transparent to the subscriber traffic. Transparency here implies
expectations for minimal interaction with clients data frames, including associated management
and control traffic between the subscribers routers and switches. It also implies expectations for
minimal flow variability to be introduced into the clients data stream (i.e., circuit-like
forwarding).
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 44
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
The service architecture is illustrated in Figure 12 below. The red dots represent the MEN UNIs
and the red dash represents the EVC instance that realizes the EPL service.
Site A
U1
EPL1 EVC
Capacity = CIR Site B
Port Rate = CIR
U2
Metro Ethernet
Port Rate = CIR
Network
Figure 12: Example of Transport-Oriented Private Data Network Interconnect Using the EPL
Service
The traffic pattern is that the subscriber data, management and control frames are sent from UNI
to UNI over a symmetric path. Routing/switching equipment on the subscriber side may send
their own L2 control messages without interference from the MEN.
In the case where the Service Provider wishes to have redundancy, a back-up EVC may be used
with some redundancy protocol to ensured that only one of the EVCs is active at any time.
Alternatively, two similar EPL services may be instantiated between Sites A and B and allow for
client-side protection (e.g., via LAG directly between switches on the subscriber site). For this
case the suggested UNI attributes are depicted in Table 40.
UNI Service Attribute UNI 1 UNI 2
UNI Identifier U1 U2
Physical Medium 1000BASE-SX 1000BASE-LX
Speed 1 Gbps 1 Gbps
Mode FDX FDX
MAC Layer IEEE 802.3-2005 IEEE 802.3-2005
UNI MTU Size 1522 1522
Service Multiplexing No No
Bundling No No
All to One Bundling Yes Yes
CE-VLAN ID for untagged and priority
NA NA
tagged Service Frames
Maximum number of EVCs 1 1
Ingress Bandwidth Profile Per UNI N/A N/A
Egress Bandwidth Profile Per UNI N/A N/A
L2CP Processing Table 39, PB2 Table 39, PB2
Table 40: UNI attributes for the Private Data Networking example using EPL Service
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 45
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
Table 41 provides the EVC per UNI attributes for the Private Data Networking example.
UNI Service Attribute UNIs 1 UNI 2
UNI EVC ID U1_EPL1 U2_EPL1
All Service Frames at the UNI All Service Frames at the UNI
CE-VLAN ID / EVC Map
map to a single EPL EVC map to a single EPL EVC
Ingress Bandwidth Profile Per EVC N/A N/A
CoS ID = EVC CoS ID = EVC
Ingress Bandwidth Profile Per CoS ID CIR=1Gbps, CBS=1522, EIR=0, CIR=1Gbps, CBS=1522, EIR=0,
EBS=0, color blind, CF=0 EBS=0, color blind, CF=0
Egress Bandwidth Profile Per EVC N/A N/A
Egress Bandwidth Profile Per CoS ID N/A N/A
Table 41: EVC per UNI attributes for the private data networking example using EPL Service
Table 42 provides the EVC attributes for the private data networking example.
EVC Service Attribute EVC_1
EVC Type Point-to-Point
EVC ID EPL1
UNI List {U1, U2}
Maximum Number of UNIs 2
EVC MTU size 1522
CE-VLAN ID Preservation Yes
CE-VLAN CoS Preservation Yes
Unicast Service Frame Delivery Deliver Unconditionally
Multicast Service Frame Delivery Deliver Unconditionally
Broadcast Service Frame Delivery Deliver Unconditionally
Layer 2 Control Protocols Processing Table 39, PB2
Service Performance Krypton CoS
Table 42: EVC service attributes for the private data networking example using the EPL Service
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 46
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
Since the subscriber does not wish to manage its own packet network infrastructure there is little
expectation for data flow symmetry or transparency. The service interfaces at the UNIs may
operate at different rates, bandwidth allocation traffic at each UNI may also be asymmetric. Non-
essential traffic may be forwarded according to resource availability (i.e., statistical
multiplexing).
The service architecture is illustrated in Figure 13 below. The red dots represent the MEN UNIs
and the red dash represents the EVC instance that realizes the EPL service.
Site A
U3
EPL2 EVC
Capacity = X Site B
Port Rate = Y
U4
Figure 13: Example of Transport-Oriented Public Data Network Interconnect Using the EPL
Service.
The traffic pattern is that the subscriber data, management and control frames are sent from UNI
to UNI over a potentially asymmetric path. Different levels of performance applicable depending
on the traffic type (potentially indicated via PCP marking). Non-essential L2 control messages
are typically discarded.
In the case where the Service Provider wishes to have redundancy, a back-up EVC may be used
with some redundancy protocol to ensure that only one of the EVCs is active at any time. The
UNI link may also be protected via link aggregation. For this case the suggested UNI attributes
are depicted in Table 43.
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 47
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
Table 44 provides the EVC per UNI attributes for the Private Data Networking example.
UNI Service Attribute UNI 3 UNI 4
UNI EVC ID U3_EPL2 U4_EPL2
All Service Frames at the UNI All Service Frames at the UNI
CE-VLAN ID / EVC Map
map to a single EPL EVC map to a single EPL EVC
Ingress Bandwidth Profile Per EVC N/A N/A
PCP = 5: PCP = 5:
CIR=20Mbps, CBS=10k, CIR=30 Mbps, CBS=10k,
EIR=0, EBS=0, color blind, EIR=0, EBS=0, color blind,
CF=0 CF=0
Ingress Bandwidth Profile Per CoS ID
PCP = 0: PCP = 0:
CIR=10Mbps, CBS=50k, CIR=5 Mbps, CBS=10k,
EIR=0, EBS=0, color blind, EIR=10 Mbps, EBS=50K, color
CF=0 blind, CF=0
Egress Bandwidth Profile Per EVC N/A N/A
Egress Bandwidth Profile Per CoS ID N/A N/A
Table 44: EVC per UNI attributes for the public data networking example using EPL Service
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 48
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
Table 45 provides the EVC attributes for the public data networking example.
EVC Service Attribute EVC_1
EVC Type Point-to-Point
EVC ID EPL2
UNI List {U3, U4}
Maximum Number of UNIs 2
EVC MTU size 1522
CE-VLAN ID Preservation Yes
CE-VLAN CoS Preservation Yes
Unicast Service Frame Delivery Deliver Unconditionally
Multicast Service Frame Delivery Deliver Unconditionally
Broadcast Service Frame Delivery Deliver Unconditionally
Layer 2 Control Protocols Processing Table 39, PB1
CoS ID=5: Krypton CoS
Service Performance
CoS ID=0: Neon CoS
Table 45: EVC service attributes for the public data networking example using the EPL Service
12.3 EXAMPLE: ETHERNET PRIVATE TREE (EP-TREE) SERVICE FOR VIDEO BROADCAST
One example of using the EP-Tree service is for a video broadcast application. In this scenario,
a video head-end is located in a POP (this UNI is designated as a Root) providing a service to
multiple subscribers (each connected to a UNI designated as a Leaf). The service might offer
multiple broadcast channels.
In the case where all channels are to be delivered to each of the subscribers, this service is uni-
directional (no traffic from Leaf to Root). In this mode, scalability is enhanced compared to E-
Line services.
However, if each subscriber needs just a subset of the available channels, then each location
(connected to a Leaf UNI) may receive a specific channel. The signaling of the desired channel
could be done via a standard multicast protocol (IGMPv3 for example).
We denote these cases as A and B, respectively. The service architecture is illustrated in Figure
14 below. The blue dots represent Root UNIs and the red dots represent Leaf UNIs for this
EVC.
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 49
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
U1 (Root )
U2 (Root )
RMP_123
(EVC)
U3 (Leaf)
Metro Ethernet
U4 (Leaf) Network U502 (Leaf)
Figure 14: Example of Video Broadcast Delivery Using the EP-Tree Service
The traffic pattern is that the video content is sent from the video head-end towards the receiving
subscribers, while each such subscriber may send control messages to the video head-end.
In the case where the Service Provider wishes to have redundancy, two Root UNIs may be used
with some redundancy protocol ensuring that only one of them transmits data into the EVC.
For this case the suggested UNI attributes are depicted in Table 46.
UNI Service Attribute Root UNIs Leaf UNIs
U1 (primary),
UNI Identifier U3 U502
U2 (back-up)
Physical Medium 1000BASE-LX 100BASE-TX
Speed 1 Gbps 100 Mbps
Mode FDX FDX
MAC Layer IEEE 802.3-2005 IEEE 802.3-2005
UNI MTU Size 1522 1522
Service Multiplexing No No
Bundling No No
All to One Bundling Yes Yes
CE-VLAN ID for untagged and priority
1 (but not significant) 1 (but not significant
tagged Service Frames
Maximum number of EVCs 1 1
7 CIR=1 Mbps, CBS=10KB, EIR=0,
Ingress Bandwidth Profile Per UNI N/A 8
EBS=0, color blind, CF=0
Egress Bandwidth Profile Per UNI N/A N/A
L2CP Processing Table 39, PB1 Table 39, PB1
Table 46: UNI attributes for the video broadcast example using EP-Tree Service
7
Video source may be considered trusted and constant bit rate.
8
Minimal traffic from Leaf to Root.
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 50
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
Table 47 provides the EVC per UNI attributes for the video broadcast example.
UNI Service Attribute UNIs 1 & 2 UNIs 3 502
UNI EVC ID U1_RMP123, U2_RMP123 U1_RMP123, ... U502_RMP123
All Service Frames at the UNI All Service Frames at the UNI
CE-VLAN ID / EVC Map map to a single Rooted- map to a single Rooted-
Multipoint EVC Multipoint EVC
Ingress Bandwidth Profile Per EVC N/A N/A
Ingress Bandwidth Profile Per CoS ID N/A N/A
Egress Bandwidth Profile Per EVC N/A N/A
Egress Bandwidth Profile Per CoS ID N/A N/A
Table 47: EVC per UNI attributes for the video broadcast example using EP-Tree Service
Table 48 provides the EVC attributes for the video broadcast example.
EVC Service Attribute EVC_1
EVC Type Rooted-Multipoint
EVC ID RMP_123
UNI List {U1, Root/U2, Root/U3, Leaf/U4, Leaf/.../U502, Leaf}
9
Maximum Number of UNIs 502
EVC MTU size 1522
CE-VLAN ID Preservation Yes
CE-VLAN CoS Preservation Yes
Unicast Service Frame Delivery Deliver Unconditionally
Deliver Conditionally: only deliver content subscribed to on a given Leaf
Multicast Service Frame Delivery
UNI
Broadcast Service Frame Delivery Deliver Unconditionally
Layer 2 Control Protocols Processing Table 39, PB1
EVC Performance (for all ordered
UNI pairs where at least one UNI in Krypton CoS
each pair is of type Root).
Table 48: EVC service attributes for the video broadcast example using EP-Tree Service
9
502 allows for up to 500 video receivers (Leaf UNIs) in this service instance
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 51
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
Since the same UNIs are used for both services, service multiplexing is required at each UNI,
and separate bandwidth profiles are needed to ensure that the services do not adversely affect
each other. For the E-LAN service, bundling is required to ensure CE-VLAN ID transparency in
the range indicated in Table 50. For the E-Tree service, bundling is not required. Figure 15
below shows this example. The blue dots represent Root UNIs and the red dots represent Leaf
UNIs for the two EVCs. Each EVC has a single Class of Service, Neon for MP_111 and
Krypton for RMP_333.
U1
U2
RMP_333
U3
EVP-Tree Service
U4 U50
MEN
MP_111
EVP-LAN Service
Figure 15: Example of Distance Learning and Business Data Using EVP-LAN and EVP-Tree
Services
The suggested UNI attributes are shown in Table 49 below.
UNI Service Attribute UNIs 1 & 2 UNIs 3 50
UNI Identifier U1, U2 U3 U50
Physical Medium 1000BASE-LX 100BASE-TX
Speed 1 Gbps 100 Mbps
Mode FDX FDX
MAC Layer IEEE 802.3-2005 IEEE 802.3-2005
UNI MTU Size 1522 1522
Service Multiplexing Yes Yes
Bundling Yes Yes
All to One Bundling No No
CE-VLAN ID for untagged and priority
1 1
tagged Service Frames
Maximum number of EVCs 10 5
Ingress Bandwidth Profile Per UNI N/A N/A
Egress Bandwidth Profile Per UNI N/A N/A
L2CP Processing Table 39, VLAN-based Table 39, VLAN-based
Table 49: UNI attributes for the distance learning, business data example
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 52
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
The suggested EVC per UNI attributes are shown in Table 50 below. For table simplicity, only
UNI 1 and UNI 50 are shown. It is expected that attributes for UNI 1 and 2 are similar and that
UNIs 3-50 are similar to each other.
UNIs 1 & 2 UNIs 3-50
EVC per UNI Service Attribute
EVC_1 EVC_2 EVC_1 EVC_2
UNI EVC ID U1_MP111 U1_RMP333 U50_MP111 U50_RMP333
CE-VLAN ID / EVC Map 11-3999 4000 11-3999 4000
CIR (Mbps) 20 N/A 20 N/A
CBS (KB) 50 N/A 50 N/A
Ingress Bandwidth
Profile Per CoS ID of EIR (Mbps) 20 N/A 20 N/A
EVC for Neon CoS EBS (KB) 50 N/A 50 N/A
on EVC_1
CM Color Blind N/A Color Blind N/A
CF 0 N/A 0 N/A
CIR (Mbps) N/A 10 N/A 10
CBS (KB) N/A 20 N/A 20
Ingress Bandwidth
Profile Per CoS ID of EIR (Mbps) N/A 0 N/A 0
EVC for Krypton EBS (KB) N/A 0 N/A 0
CoS on EVC_2
CM N/A Color Blind N/A Color Blind
CF N/A 0 N/A 0
CIR (Mbps) 20 N/A 20 N/A
CBS (KB) 70 N/A 70 N/A
Egress Bandwidth EIR (Mbps) 20 N/A 20 N/A
Profile Per CoS ID of
EVC for Neon CoS EBS (KB) 70 N/A 70 N/A
CM Color Blind N/A Color Blind N/A
CF 1 N/A 1 N/A
CIR (Mbps) N/A 10 N/A 1
CBS (KB) N/A 20 N/A 15
Egress Bandwidth
Profile Per CoS ID of EIR (Mbps) N/A 0 N/A 0
EVC for Krypton EBS (KB) N/A 0 N/A 0
CoS
CM N/A Color Blind N/A Color Blind
CF N/A 0 N/A 0
Table 50: EVC per UNI attributes for the distance learning, business data example
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 53
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Services Definitions, Phase 2 MEF 6.1
The suggested EVC service attributes and parameter values are shown in Table 51 below for
each of the EVCs in this example.
EVC Service Attribute EVC-1 EVC_2
EVC Type Multipoint-to-Multipoint Rooted-Multipoint
EVC ID MP_111 RMP_333
{U1, Root/U2, Root/U3,
UNI List {U1, Root/U2, Root/.../U50, Root}
Leaf/.../U50, Leaf}
Maximum Number of UNIs 100 50
EVC MTU size 1522 1522
CE-VLAN ID Preservation Yes No
CE-VLAN CoS Preservation Yes No
Deliver Conditionally: for known D-
MACs only to destination UNI; for
Unicast Service Frame Delivery unknown D-MACs, deliver Deliver Unconditionally
unconditionally to all destination
UNIs
Deliver Conditionally: only deliver
Multicast Service Frame Delivery Deliver Unconditionally content subscribed to on a given Leaf
UNI
Broadcast Service Frame Delivery Deliver Unconditionally Deliver Unconditionally
Layer 2 Control Protocols
Table 39, VLAN-based Table 39, VLAN-based
Processing
Neon CoS (for all ordered UNI pairs) Krypton CoS (for all ordered UNI
EVC Performance pairs where at least one UNI in each
pair is of type Root)
Table 51: EVC attributes for the distance learning, business data example
MEF 6.1 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall Page 54
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
RFC 4448
"Encapsulation Methods for Transport of Ethernet over MPLS
Networks", April 2006
Canonical URL:
http://www.rfc-editor.org/rfc/rfc4448.txt
This document is also available in this non-normative format: TXT.PDF.
Status:
PROPOSED STANDARD
Updated by:
RFC 5462
Authors:
L. Martini, Ed.
E. Rosen
N. El-Aawar
G. Heron
Stream:
IETF
Source:
pwe3 (int)
Please refer here for any errata for this document. To submit a new errata report, go to the main errata
page.
Abstract
An Ethernet pseudowire (PW) is used to carry Ethernet/802.3 Protocol Data Units (PDUs) over an
MPLS network. This enables service providers to offer "emulated" Ethernet services over existing
MPLS networks. This document specifies the encapsulation of Ethernet/802.3 PDUs within a
pseudowire. It also specifies the procedures for using a PW to provide a "point-to-point Ethernet"
service. [STANDARDS-TRACK]
Please refer here for any errata for this document. To submit a new errata report, go to the main errata
page.
Abstract
Virtual Private LAN Service (VPLS), also known as Transparent LAN Service and Virtual Private
Switched Network service, is a useful Service Provider offering. The service offers a Layer 2 Virtual
Private Network (VPN); however, in the case of VPLS, the customers in the VPN are connected by a
multipoint Ethernet LAN, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature.
This document describes the functions required to offer VPLS, a mechanism for signaling a VPLS, and
rules for forwarding VPLS frames across a packet switched network. [STANDARDS-TRACK]
Please refer here for any errata for this document. To submit a new errata report, go to the main errata
page.
Abstract
This document specifies an architectural framework for the application of Multiprotocol Label
Switching (MPLS) to the construction of packet-switched transport networks. It describes a common set
of protocol functions -- the MPLS Transport Profile (MPLS-TP) -- that supports the operational models
and capabilities typical of such networks, including signaled or explicitly provisioned bidirectional
connection-oriented paths, protection and restoration mechanisms, comprehensive Operations,
Administration, and Maintenance (OAM) functions, and network operation in the absence of a dynamic
control plane or IP forwarding support. Some of these functions are defined in existing MPLS
specifications, while others require extensions to existing specifications to meet the requirements of the
MPLS-TP.
This document defines the subset of the MPLS-TP applicable in general and to point-to-point transport
paths. The remaining subset, applicable specifically to point-to-multipoint transport paths, is outside the
scope of this document.
This document is a product of a joint Internet Engineering Task Force (IETF) / International
Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an
MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3)
architectures to support the capabilities and functionalities of a packet transport network as defined by
the ITU-T. This document is not an Internet Standards Track specification; it is published for
informational purposes.
Please refer here for any errata for this document. To submit a new errata report, go to the main errata
page.
Abstract
The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the set of MPLS protocol functions
applicable to the construction and operation of packet-switched transport networks. This document
specifies the subset of these functions that comprises the MPLS-TP data plane: the architectural layer
concerned with the encapsulation and forwarding of packets within an MPLS-TP network.
This document is a product of a joint Internet Engineering Task Force (IETF) / International
Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an
MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3)
architectures to support the capabilities and functionalities of a packet transport network.
[STANDARDS-TRACK]
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.
Introduction
Industry forums and standards bodies like the MEF,
Corporate IT managers are exploring ways to add
IEEE, ITU-T and IETF have developed the necessary
network capacity while maintaining or reducing their
extensions to the original Ethernet protocol, making it
recurring operating expenses. Increasingly,
suitable for service provider applications. For its part,
businesses are moving away from traditional TDM,
the MEF has documented numerous technical
Frame Relay or ATM circuits and turning to Carrier
requirements for building and managing feature-rich
Ethernet Services to address these apparently
business-class Ethernet services. In addition, the
conflicting needs. Service providers have responded
MEF has developed a successful certification program
with rich offerings that combine heretofore unmatched
to verify that equipment and services satisfy these
scalability and flexible bandwidth options with reliability
requirements.
and quality of service previously only available with
old-school telecom circuits.
MEF 2009. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with
permission of the MEF." No user of this document is authorized to modify any of the information contained herein. 4/09 v1 1 of 11
MEF White Paper: Delivering Ubiquitous Ethernet Services using the Worlds Access Technologies
The Carrier Ethernet technology and market have Ubiquity Requires Multiple Access Technology
evolved to the point where purpose-built hardened Solutions
equipment is now used to deliver MEF-certified
services. The MEF technical work resulted in the With the evolution from best-effort Ethernet services
formal definition of the carrier-class Ethernet that has to higher-performing MEF-certified services, the
come to be known simply as Carrier Ethernet. The primary obstacle confronting Ethernet service delivery
customer base for Ethernet services has also evolved is the difficulty expanding the Ethernet service footprint
from large Enterprises located in fiber-rich and making it available ubiquitously. Or, at a
metropolitan centers to those with globally distributed minimum, making it available to the locations where
operations and mid-sized businesses in suburban and business users want to purchase it.
rural settings.
The need for ubiquitous Ethernet service delivery has
This last point is critical: this shift in the market has driven the development and deployment of a variety of
created opportunities and advantages for service access technologies, each optimized for different
providers who can offer ubiquitous coverage in a cost- access situations. Rarely can carriers find a single
effective and timely manner. access technology that can address all the access
requirements of their region. This problem is even
This paper focuses on informing the reader about the more pronounced when carriers follow customers out-
applications and individual advantages of currently of-region into other carriers territories.
available access technologies. The primary audience
of this paper is the service provider who is interested Fortunately, it is now possible to deliver a consistent
in delivering an Ethernet service without boundaries. MEF-certified Ethernet service over a variety of access
However, businesses who are consumers of Carrier architectures using MEF-certified equipment from
Ethernet services may also find it informative. multiple vendors. Some of the technologies used to
deliver MEF-certified services include the following
A Growing Opportunity with Real-World access alternatives:
Challenges
Ethernet over Fiber (Active Fiber, PON,
According to data from Vertical Systems, Carrier SONET/SDH)
Ethernet Services grew 41% in 2008 and will be a 31 Ethernet over PDH (T1/E1, DS3/E3)
billion dollar worldwide market by 2012. Carrier Ethernet over Copper (EFMCu)
Ethernet has been globally embraced by more than 50 Wireless Ethernet (WiMAX, Broadband Wireless,
service providers and 100 equipment manufacturers. Microwave)
This figure is growing at an annual rate of 40%. Ethernet over HFC/DOCSIS
The number one challenge facing service providers The network drawing on the following page illustrates
today is the difficulty of providing access to all their an access architecture that uses several of these
customer locations. While tremendous investments technologies. When properly deployed, the only
have been made to build out their fiber plant, no single difference among the Ethernet services delivered
provider can deliver on-net access to wide area across this variety of access technologies is the
Ethernet services with the same coverage as their maximum bandwidth that can be transported over
traditional services. The good news is that service each technology. The underlying service definitions
providers and equipment vendors have been actively and SLAs can be identical, providing the end user with
working together to tackle these challenges. a seamless Ethernet experience even while a variety
of different access technologies are in play.
MEF 2009. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with
permission of the MEF." No user of this document is authorized to modify any of the information contained herein. 4/09 v1 2 of 11
MEF White Paper: Delivering Ubiquitous Ethernet Services using the Worlds Access Technologies
Each of the access technologies illustrated above have their strengths in certain applications. The table below
describes these applications at an introductory level. The sections that follow will provide greater detail on the
advantages of each individual technology.
Benefits of Ethernet over SONET/SDH (EoS) wherever fiber has been pulled. In addition, modern
Delivering Ethernet services over SONET/SDH allows circuit bonding protocols, such as virtual
the service provider to leverage infrastructure that is concatenation (VCAT), have helped make Ethernet
already in place using familiar transport technology. services over SONET/SDH available at fractions of
SONET/SDH networks have traditionally been the line rate, eliminating stranded capacity and
regarded as the gold standard for resiliency. This further driving down costs.
well-understood technology is widely available
MEF 2009. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with
permission of the MEF." No user of this document is authorized to modify any of the information contained herein. 4/09 v1 5 of 11
MEF White Paper: Delivering Ubiquitous Ethernet Services using the Worlds Access Technologies
(2460 ft), using VDSL technology over a single With Ethernet over Copper, service providers,
copper pair. governments and private enterprises have a cost-
effective solution for extending their Ethernet
Extensions to these standard technologies networks without having to deploy fiber.
developed by some equipment vendors have
enabled some service providers to improve on the Eliminating the need to install fiber optic cable
rate/reach curves provided by the standard removes a fundamental barrier that has inhibited
implementations. the adoption of Ethernet in the public network.
Using the multi-pair bonding service providers can
Both EFMCu technologies support an optional offer high performance (10-100 Mbps) service over
aggregation or bonding of multiple copper pairs (up a reliable infrastructure with resiliency built right in.
to 32), providing higher bandwidth, longer reach EFMCu using multi-pair bonding provides the
and improved resiliency. The aggregate bandwidth, subscriber with a fiber-like experience and gives the
in excess of 100 Mbps, offered by copper bonding service provider the ability to universally offer
solutions meet the needs of most bandwidth- Ethernet services over both fiber and copper media.
intensive Metro Ethernet applications.
Ethernet over Copper can also lower recurring
Benefits of Ethernet over Copper operational costs for CLECs or ILECs who are
Using the existing voice-grade copper infrastructure operating as CLECs in out-of-region territories.
keeps deployment costs to a minimum, as there is Using EFMCu, carriers can deliver Ethernet
no requirement for new cabling inside or outside the services over leased dry copper, which is typically
residence or business. much less expensive than alternatives.
By reducing service provider capital expenditures EFMCu is an attractive access solution for both
for implementation, EFMCu serves as the easiest, residential and business users and is spectrally
lowest-cost, and immediately deployable solution compatible with other legacy PSTN/ISDN, T1/E1
for providing feature-rich, high-speed access and and DSL services so they can co-exist in the same
services to subscribers. cables.
Wireless Ethernet
Where wireline services are not available or Microwave links may be licensed (filed and
practical, delivering Ethernet over a point-to-point protected by government agencies) or may be
wireless access network can make a previously unlicensed (through the use of low power within
infeasible connection practical. Also, where unlicensed regulatory limits).
mobility is required, broadband wireless services
from mobile service providers may provide an Broadband Wireless
excellent connectivity option. EVDO (Evolution of Existing Systems for Data
Only) is a common upgraded service of cellular
Terrestrial Microwave providers with CDMA (Code Division Multiple
A microwave link uses microwave frequencies Access) systems. EVDO Rev. A allows for a
(above 1 GHz) for line of sight radio maximum data transmission rate of approximately
communications (20 to 30 miles) between two 3.1 Mbps on the forward (downstream) channel.
directional antennas. Microwave link transceivers The EVDO Rev. A system uses the same reverse
are now available with standard Ethernet interfaces channel which limits the uplink data transmission
that can be used to deliver carrier Ethernet rate to approximately 1.8 Mbps. The EVDO system
services. The distance and throughput that can be has an upgraded packet data transmission control
achieved is a function of frequency and antenna system that allows for bursty data transmission
size. For example, 100 Mbps Fast Ethernet can be rather than for more continuous voice data
achieved reliably over 8 miles at 11 GHz but will transmission.
perform poorly over 15 miles due to rain fade at that
frequency. 100 Mbps Fast Ethernet can be GSM (Global System for Mobile) is the most
achieved reliably up to 30 miles at 6 GHz. popular standard for mobile phones in the world. Its
promoter, the GSM Association, estimates that 80%
The use of microwave links avoids the need to of the global mobile market uses the standard.
install cables between communication equipment. Release '97 of the standard added packet data
MEF 2009. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with
permission of the MEF." No user of this document is authorized to modify any of the information contained herein. 4/09 v1 6 of 11
MEF White Paper: Delivering Ubiquitous Ethernet Services using the Worlds Access Technologies
capabilities, by means of General Packet Radio WiMax was created by the WiMAX Forum and is a
Service (GPRS). The latest version of packet data wireless point-to-multi-point data transmission
communications are UMTS (Universal Mobile technology that is based on the IEEE 802.16
Telecommunications System) and HSDPA/HSPA+ standards. With its latest version, 802.16e adds
(High-Speed Downlink Packet Access/ High-Speed mobility and better support for quality of service as
Packet Access). These technologies enable well as symmetrical transmission capability of
download speeds of up to 42 Mbps (22 Mbps in typically 40 Mbps for fixed and 15 Mbps for mobile
upload). One of the main advantages of HSPA+ is implementation. As a "last mile" broadband wireless
its optional all-IP capability that is using native access, WiMAX can be used in the following
Ethernet connection to the base station. applications: replacement to legacy T1/E1, delivery
of triple-play services, backhaul technology for Wi-
LTE (Long Term Evolution or 3GPP) is the name Fi hotspots and mobile backhaul and for mobile
given to a project within the Third Generation emergency response services.
Partnership Project to improve the UMTS mobile
phone standard to cope with future technology Free Space Optics (FSO)
evolutions. Goals include improving spectral FSO is an alternative to the radio frequency
efficiency, lowering costs, improving services, wireless technologies previously described. While
making use of new spectrum and re-farmed the most common use of optical transmission is
spectrum opportunities, and better integration with through fiber optic cable, FSO enables service
other open standards. Being based on an all-IP providers to connect two points at a medium to long
infrastructure and native Ethernet connectivity, LTE distance (from an access perspective) through the
should provide 100 Mbps peak download rates. air and provide Gigabit Ethernet speeds. As light is
used instead of electro-magnetic signal, there is no
WiMAX (Worldwide Interoperability for need to purchase expensive radio spectrum,
Microwave Access). making FSO a complement to copper and fiber
communications.
MEF 2009. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with
permission of the MEF." No user of this document is authorized to modify any of the information contained herein. 4/09 v1 7 of 11
MEF White Paper: Delivering Ubiquitous Ethernet Services using the Worlds Access Technologies
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.
Integrating diverse access media and protocols into a seamless Ethernet services network is facilitated by work
at the MEF. MEF specifications on UNI Type 1 and Ethernet service definitions ensure that there are
commonly accepted service parameters and hardware interfaces to connect Ethernet ports anywhere on the
network. OAMP work by the MEF ensures that Cardoso has the management tools necessary to monitor
network performance and diagnose network issues. Cardoso uses E-LAN configurations to separate traffic into
VLANS to ensure data integrity.
Rexon Masseys work is only possible with high-speed, real-time data input and analysis. Ethernet services
provide the necessary platform for gathering this data on a cost-effective heterogeneous network. Cooperation
among Masseys service providers ensures they can collect data wherever they have customers.
MEF 2009. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with
permission of the MEF." No user of this document is authorized to modify any of the information contained herein. 4/09 v1 8 of 11
MEF White Paper: Delivering Ubiquitous Ethernet Services using the Worlds Access Technologies
Summary
In conclusion, in order to realize the full potential of an Ethernet service offering, and in order to maximize the
revenue from these services, delivering ubiquitous Ethernet is critical. Only by doing so can service providers
deliver services everywhere, to all customer locations, using the technology that is best suited for each
application.
Follow up or Questions
Please send any question or comment to the following email address: access@metroethernetforum.net.
Your email will be treated confidentially within the Access Technologies Working group. We will respond within
one cycle of our bi-weekly working group meetings.
E-Line, E-LAN and MEF 6.1 Metro Ethernet Services Definitions Phase 2
E-Tree Services MEF 10.1 Ethernet Services Attributes Phase 2
PDH/Circuit MEF 3: Circuit Emulation Service Definitions, Framework and Requirements
emulation MEF 8: Implementation Agreement for the Emulation of PDH Circuits
Mobile Backhaul MEF 22: Carrier Ethernet for Mobile Backhaul Implementation Agreement
MEF 9: Ethernet Services at the UNI
Test/Certification
MEF 14: Traffic Management
Carrier Ethernet
Technology Alternatives Applicable Standards
Access Method
Active Fiber - IEEE 802.3-2005
- ITU-T X.86 encapsulation
Ethernet over SONET/SDH
Ethernet over - ITU-T G.707 and G.7043 (GFP-VCAT)
Fiber - IEEE 802.3-2005 (EPON)
Passive Optical Network - IEEE 802.3av (10GEPON)
- ITU-T G.984 (GPON)
- RFC1990 (Multilink PPP) and RFC3518 (BCP)
Bonded T1/E1 - ITU-T G.7041 and G.7043 (GFP-VCAT)
Ethernet over - ITU-T G.998.2 (G.bond)
PDH - ITU-T X.86 encapsulation with optional link aggregation
DS3/E3 and bonded
- ITU-T G.7041 and G.7043 (GFP-VCAT)
DS3/E3
- ITU-T G.998.2 (G.bond)
- IEEE 802.3-2005 2BASE-TL using ITU-T G.991.2
2BASE-TL
Ethernet over (G.SHDSL.bis)
Copper - IEEE 802.3-2005 10PASS-TS using ITU-T G.993.1
10PASS-TS
(VDSL)
Terrestrial microwave - IEEE 802.3-2005 user interface
WiMAX - IEEE 802.16
- 3GPP Rel. 7 (HSDPA/HSPA+)
Wireless Ethernet Broadband wireless - 3GPP Rel. 8 (LTE)
- CDMA2000 EV-DO rev.A TIA-856 (EVDO)
Free space optics - IEEE 802.3-2005 user interface
WiFi - IEEE 802.11
Hybrid Fiber Coax DOCSIS - DOCSIS 1.x, 2.x, 3.0, EuroDOCSIS
MEF 2009. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with
permission of the MEF." No user of this document is authorized to modify any of the information contained herein. 4/09 v1 9 of 11
MEF White Paper: Delivering Ubiquitous Ethernet Services using the Worlds Access Technologies
Glossary of Abbreviations
3GPP Third Generation Partnership Project ITU-T International Telecommunication Union
(Standardization body developing GSM Telecommunication Standardization
technologies) Sector
3GPP2 Third Generation Partnership Project 2 LAN Local Area Network
(Standardization body developing LLDP Link Layer Discovery Protocol
CDMA technologies) LTE Long Term Evolution
ADM Add Drop Multiplexer MEF New name for entity formerly known as
ARP Address Resolution Protocol Metro Ethernet Forum
ATM Asynchronous Transfer Mode MLPPP Multi-Link Point-To-Point Protocol
BCP Bridging Control Protocol MSO Multiple Service Operator (Comcast,
BPDU Bridge Protocol Data Unit COX, Time Warner Cable, etc)
BWA Broadband Wireless Access NID Network Interface Device
CDMA Code Division Multiple Access OAM Operations, Administration and
CFM Connectivity Fault Management Maintenance
CLEC Competitive Local Exchange Carrier OLO Other Licensed Operator
CWDM Coarse Wave Division Multiplexing OLT Optical Line Termination
DOCSIS Data over Cable Service Interface PDH Plesiochronous Digital Hierarchy
Specification QoS Quality of service
DS3 Digital Signal level 3 RFI Request for Information
DSL Digital Subscriber Line (as in xDSL) RFP Request for Proposal
E1 European PDH signal level 1 RFQ Request for Quotation
E3 European PDH signal level 3 SDH Synchronous Digital Hierarchy
EFM Ethernet in the First Mile SHDSL Single-Pair High-Speed Digital
EFMCu Ethernet in the First Mile Copper Subscriber Line
E-LAN Ethernet-LAN Service SLA Service Level Agreement
E-Line Ethernet Point-to-Point SLO Service Level Objectives
EoS Ethernet over SONET/SDH SLS Service Level Specifications
EPL Ethernet Private Line SMB Small and Medium Business
EPON Ethernet Passive Optical Network SOHO Small Office, Home Office
EVC Ethernet Virtual Connection SONET Synchronous Optical NETwork
EVDO Evolution of Existing Systems for Data T1 Telecommunications level 1
Only TDM Time Division Multiplexing
EVPL Ethernet Virtual Private Line UMTS Universal Mobile Telecommunications
FSO Free Space Optics System
GFP Generic Framing Protocol UNI User to Network Interface
GPRS General Packet Radio Service VCAT Virtual Concatenation
GSM Global System for Mobile VDSL Very High Speed Digital Subscriber Line
HFC Hybrid Fiber Coax VLAN Virtual LAN
HSDPA High-Speed Downlink Packet Access VoD Video on Demand
HSPA High-Speed Packet Access WiMAX Worldwide Interoperability for Microwave
IEEE Institute of Electrical & Electronics Access
Engineers WDM Wave Division Multiplexing
IETF Internet Engineering Task Force
ILEC Incumbent Local Exchange Carrier
MEF 2009. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with
permission of the MEF." No user of this document is authorized to modify any of the information contained herein. 4/09 v1 10 of 11
MEF White Paper: Delivering Ubiquitous Ethernet Services using the Worlds Access Technologies
Disclaimer
The information in this publication is believed to be accurate as of its publication date. Such information is
subject to change without notice and the MEF is not responsible for any errors. The MEF does not assume any
responsibility to update or correct any information in this publication. Notwithstanding anything to the contrary,
neither The MEF nor the publisher make any representation or warranty, expressed or implied, concerning the
completeness, accuracy, or applicability of any information contained in this publication. No liability of any kind
shall be assumed by the MEF or the publisher as a result of reliance upon any information contained in this
publication.
About the Metro Ethernet Forum
The MEF is a non-profit organization dedicated to accelerating the worldwide adoption of Carrier Ethernet. The
MEF comprises leading service providers, local exchange carriers, cable operators, network equipment
manufacturers and other prominent networking companies that share an interest in Carrier Ethernet. As of
March 2009, the MEF has 154 members.
Contributors
Contributor Company
Jon Collins Transition Networks
Eric Doricko Calix
D. Mark Durrett Overture Networks
Fred Ellefson ADVA Optical Networking
Bruno Giguere EXFO
Craig Goodwin Adtran
Richard Goss Verizon
Mannix OConnor Hitachi
Eric Vallone Actelis Networks
MEF 2009. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with
permission of the MEF." No user of this document is authorized to modify any of the information contained herein. 4/09 v1 11 of 11
Technical Specification
MEF 10.2
27 October 2009
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Disclaimer
The information in this publication is freely available for reproduction and use by any recipient
and is believed to be accurate as of its publication date. Such information is subject to change
without notice and the Metro Ethernet Forum (MEF) is not responsible for any errors. The MEF
does not assume responsibility to update or correct any information in this publication. No
representation or warranty, expressed or implied, is made by the MEF concerning the
completeness, accuracy, or applicability of any information contained herein and no liability of
any kind shall be assumed by the MEF as a result of reliance upon such information.
The information contained herein is intended to be used without modification by the recipient or
user of this document. The MEF is not responsible or liable for any modifications to this
document made by any other party.
The receipt or any use of this document or its contents does not in any way create, by implication
or otherwise:
a) any express or implied license or right to or under any patent, copyright, trademark or
trade secret rights held or claimed by any MEF member company which are or may be
associated with the ideas, techniques, concepts or expressions contained herein; nor
b) any warranty or representation that any MEF member companies will announce any
product(s) and/or service(s) related thereto, or if such announcements are made, that such
announced product(s) and/or service(s) embody any or all of the ideas, technologies, or
concepts contained herein; nor
c) any form of relationship between any MEF member companies and the recipient or user
of this document.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
Table of Contents
1. Abstract................................................................................................................................ 1
2. Terminology......................................................................................................................... 1
3. Scope..................................................................................................................................... 5
5. Introduction ......................................................................................................................... 6
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page i
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
List of Figures
Figure 1 Ethernet Services Model................................................................................................ 7
Figure 2 Point-to-Point EVCs ...................................................................................................... 8
Figure 3 Multipoint-to-Multipoint EVC ...................................................................................... 9
Figure 4 Rooted-Multipoint EVC ................................................................................................ 9
Figure 5 - Frame Delay for Service Frame ................................................................................... 17
Figure 6 Inter-Frame Delay Variation Definition ...................................................................... 22
Figure 7 Examples of the Calculation of I (S k ) ........................................................................ 27
Figure 8 Example of Service Multiplexing on UNI A ............................................................... 31
Figure 9 Example of a CE-VLAN ID/EVC Map....................................................................... 33
Figure 10 Example of CE-VLAN ID/EVC Maps at Two UNIs ................................................ 34
Figure 11 Example of Bundling................................................................................................. 35
Figure 12 Example of a Simple Description of Bundling.......................................................... 35
Figure 13 The Bandwidth Profile Algorithm ............................................................................. 38
Figure 14 Ingress Bandwidth Profile per Ingress UNI .............................................................. 39
Figure 15 Ingress Bandwidth Profile per EVC .......................................................................... 40
Figure 16 Ingress Bandwidth Profile per Class of Service Identifier ........................................ 40
Figure 17 Egress Bandwidth Profile per Egress UNI ................................................................ 43
Figure 18 Egress Bandwidth Profile per EVC ........................................................................... 43
Figure 19 Ethernet Service Framework ..................................................................................... 46
Figure 20 CE-VLAN ID/EVC Map Notation ............................................................................ 51
Figure 21 Example 1: CE-VLAN ID Preservation = Yes with All to One Bundling................ 51
Figure 22 Example 2: CE-VLAN ID Preservation = Yes with Bundling on EVC2.................. 51
Figure 23 CE-VLAN ID/EVC Map Notation ............................................................................ 52
Figure 24 Example 3: CE-VLAN ID Preservation = No ........................................................... 53
Figure 25 Untagged UNIs .......................................................................................................... 54
Figure 26 Use of a Rooted-Multipoint EVC .............................................................................. 55
Figure 27 Redundant Higher Layer Service Access .................................................................. 55
Figure 28 Periodic Algorithm .................................................................................................... 56
Figure 29 New Frame Algorithm............................................................................................... 57
Figure 30 Multipoint EVC Example .......................................................................................... 58
List of Tables
Table 1 List of Standardized Layer 2 Control Protocols ........................................................... 11
Table 2 CE-VLAN ID Preservation for a Service Frame .......................................................... 13
Table 3 CE-VLAN ID Preservation Service Attribute for an EVC ........................................... 13
Table 4 One-way Frame Delay Performance Parameters .......................................................... 20
Table 5 Inter-Frame Delay Variation Parameters ...................................................................... 23
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page iii
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page iv
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
1. Abstract
The attributes of Ethernet Services observable at a User Network Interface (UNI) and from User
Network Interface to User Network Interface (UNI to UNI) are defined. In addition, a framework
for defining specific instances of Ethernet Services is described. This document supersedes and
replaces MEF 10 [7].
2. Terminology
All to One Bundling A UNI attribute in which all CE-VLAN IDs are associated with
a single EVC.
Availability Performance A measure of the percentage of time that a service is useable.
Broadcast Service Frame A Service Frame that has the broadcast destination MAC
address.
Bundling A UNI attribute in which more than one CE-VLAN ID can be
associated with an EVC.
CBS Committed Burst Size
CE Customer Edge
CE-VLAN CoS Customer Edge VLAN CoS
CE-VLAN ID Customer Edge VLAN ID
CE-VLAN ID Preservation An EVC attribute in which the CE-VLAN ID of an egress
Service Frame is identical in value to the CE-VLAN ID of the
corresponding ingress Service Frame.
CE-VLAN ID/EVC Map An association of CE-VLAN IDs with EVCs at a UNI.
CE-VLAN Tag Customer Edge VLAN Tag
CF Coupling Flag
CIR Committed Information Rate
Class of Service A set of Service Frames that have a commitment from the
Service Provider to receive a particular level of performance.
Class of Service Identifier Information derivable from a) the EVC to which the Service
Frame is mapped, b) the combination of the EVC to which the
Service Frame is mapped and a set of one or more CE-VLAN
CoS values, c) the combination of the EVC to which the
Service Frame is mapped and a set of one or more DSCP
values, or d) the combination of the EVC to which the Service
Frame is mapped and a set of one or more tunneled Layer 2
Control Protocols.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 1
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
CM Color Mode
Color Mode CM is a Bandwidth Profile parameter. The Color Mode
parameter indicates whether the color-aware or color-blind
property is employed by the Bandwidth Profile. It takes a value
of color-blind or color-aware only.
Color-aware A Bandwidth Profile property where a pre-determined level of
Bandwidth Profile compliance for each Service Frame is taken
into account when determining the level of compliance for each
Service Frame.
Color-blind A Bandwidth Profile property where a pre-determined level of
Bandwidth Profile compliance for each Service Frame, if
present, is ignored when determining the level of compliance
for each Service Frame.
Committed Burst Size CBS is a Bandwidth Profile parameter. It limits the maximum
number of bytes available for a burst of Service Frames sent at
the UNI speed to remain CIR-conformant.
Committed Information CIR is a Bandwidth Profile parameter. It defines the average
Rate rate in bits/s of Service Frames up to which the network
delivers Service Frames and meets the performance objectives
defined by the CoS Service Attribute.
CoS Class of Service
Coupling Flag CF is a Bandwidth Profile parameter. The Coupling Flag allows
the choice between two modes of operation of the rate
enforcement algorithm. It takes a value of 0 or 1 only.
Customer Edge Equipment on the Subscriber side of the UNI.
Customer Edge VLAN CoS The Priority Code Point bits in the IEEE 802.1Q Customer
VLAN Tag [10] in a Service Frame that is either tagged or
priority tagged.
Customer Edge VLAN ID The identifier derivable from the content of a Service Frame
that allows the Service Frame to be associated with an EVC at
the UNI.
Customer Edge VLAN Tag The IEEE 802.1Q Customer VLAN Tag [10] in a tagged
Service Frame.
Data Service Frame A Service Frame that is Unicast, Multicast, or Broadcast.
EBS Excess Burst Size
Egress Bandwidth Profile A service attribute that specifies the length and arrival time
characteristics of egress Service Frames at the egress UNI.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 2
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
Egress Service Frame A Service Frame sent from the Service Provider network to the
CE.
EIR Excess Information Rate
E-LAN Service Ethernet LAN Service
E-Line Service Ethernet Line Service
Ethernet LAN Service An Ethernet Service Type distinguished by its use of a
Multipoint-to-Multipoint EVC.
Ethernet Line Service An Ethernet Service Type distinguished by its use of a Point-to-
Point EVC.
Ethernet Virtual An association of two or more UNIs that limits the exchange of
Connection Service Frames to UNIs in the Ethernet Virtual Connection.
EVC Ethernet Virtual Connection
EVC Maximum The maximum sized Service Frame allowed for an EVC.
Transmission Unit Size
Excess Burst Size EBS is a Bandwidth Profile parameter. It limits the maximum
number of bytes available for a burst of Service Frames sent at
the UNI speed to remain EIR-conformant.
Excess Information Rate EIR is a Bandwidth Profile parameter. It defines the average
rate in bits/s of Service Frames up to which the network may
deliver Service Frames but without any performance objectives.
FD Frame Delay
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 3
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
Ingress Bandwidth Profile A characterization of ingress Service Frame arrival times and
lengths at the ingress UNI and a specification of disposition of
each Service Frame based on its level of compliance with the
characterization.
Ingress Service Frame A Service Frame sent from the CE into the Service Provider
network.
IFDV Inter-Frame Delay Variation
Inter-Frame Delay The difference in delay of two Service Frames belonging to the
Variation same CoS instance.
Inter-Frame Delay A measure of the variation in the delays experienced by
Variation Performance different Service Frames belonging to the same CoS instance.
Layer 2 Control Protocol A Service Frame that is used for Layer 2 control, e.g., Spanning
Service Frame Tree Protocol.
Layer 2 Control Protocol The process by which a Layer 2 Control Protocol Service
Tunneling Frame is passed through the Service Provider network without
being processed and is delivered unchanged to the proper
UNI(s).
Maximum Number of UNIs The maximum number of UNIs that may be in an EVC.
Mean Frame Delay The arithmetic mean, or average of delays experienced by
Performance different Service Frames belonging to the same CoS instance.
MNU Maximum Number of UNIs
Multicast Service Frame A Service Frame that has a multicast destination MAC address.
Multipoint-to-Multipoint An EVC with two or more UNIs. A Multipoint-to-Multipoint
EVC EVC with two UNIs is different from a Point-to-Point EVC
because one or more additional UNIs can be added to it.
Ordered Pair of UNIs A directional UNI pair of the form <Ingress UNI, Egress UNI>,
selected from the UNI list for the EVC of interest.
Point-to-Point EVC An EVC with exactly 2 UNIs.
Qualified Set of Service The set of frames that comply with specific criteria, such as the
Frames arrival time at the Ingress UNI and Bandwidth Profile
compliance, on which a performance attribute is based.
Rooted-Multipoint EVC A multipoint EVC in which each UNI is designated as either a
Root or a Leaf. Ingress Service Frames at a Root UNI can be
delivered to one or more of any of the other UNIs in the EVC.
Ingress Service Frames at a Leaf UNI can only be delivered to
one or more Root UNIs in the EVC.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 4
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
Scheduled Downtime A time interval agreed upon by both the Subscriber and Service
Provider during which a service may be disabled by the Service
Provider.
Service Frame An Ethernet frame transmitted across the UNI toward the
Service Provider or an Ethernet frame transmitted across the
UNI toward the Subscriber.
Service Level Agreement The contract between the Subscriber and Service Provider
specifying the agreed to service level commitments and related
business agreements.
Service Level Specification The technical specification of the service level being offered by
the Service Provider to the Subscriber.
Service Multiplexing A UNI service attribute in which the UNI can be in more than
one EVC instance.
Service Provider The organization providing Ethernet Service(s).
SLA Service Level Agreement
SLS Service Level Specification
Subscriber The organization purchasing and/or using Ethernet Services.
UNI User Network Interface
Unicast Service Frame A Service Frame that has a unicast destination MAC address.
UNI Maximum The maximum sized Service Frame allowed at the UNI.
Transmission Unit Size
Unscheduled Downtime A time interval not agreed upon by both the Subscriber and
Service Provider during which the Service Provider determines
that the service is not usable.
User Network Interface The physical demarcation point between the responsibility of
the Service Provider and the responsibility of the Subscriber.
3. Scope
This document describes Ethernet Service attributes. The Ethernet Services are modeled from the
point of view of the Subscribers equipment referred to as the Customer Edge (CE) that is used
to access the service. The basic elements of Ethernet Services are defined. In addition, a number
of Service Attributes are defined that may be offered as part of an Ethernet Service including the
definition of Service Level Specification. This document supersedes and replaces MEF 10,
Ethernet Services Attributes Phase 1 [7].
The goals of this Technical Specification are two-fold. The first goal is to provide sufficient
technical specificity to allow a Subscriber to successfully plan and integrate Ethernet Services
into his or her overall networking infrastructure. The second goal is to provide enough detail so
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 5
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
that Customer Edge equipment vendors can implement capabilities into their products so that
they can be used to successfully access Ethernet Services. It follows as a corollary that vendors
of Service Provider network equipment will make use of this information for implementing
functions that complement the functions in the CE.
This specification includes the following topics that are in addition or changes to the material of
[7]:
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).
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).
4. Compliance Levels
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119[1]. All key words must be in upper
case, bold text.
5. Introduction
This document provides the model and framework for Ethernet Services. The model is built on
the reference model as shown in Figure 1.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 6
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
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.
A fundamental aspect of Ethernet Services is the Ethernet Virtual Connection (EVC). An EVC is
an association of two or more UNIs. These UNIs are said to be in the EVC. A given UNI can
support more than one EVC via the Service Multiplexing attribute as described in Section 7.4.
1
Multiplexing traffic from multiple Subscribers onto a single link can be a valuable function but is an internal MEN
function and is not visible at the UNI.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 7
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
An ingress Service Frame that is mapped to the EVC (see Section 7.6) can be delivered to one or
more of the UNIs in the EVC other than the ingress UNI. It MUST NOT be delivered back to
the ingress UNI. 2 It MUST NOT be delivered to a UNI not in the EVC. An EVC is always bi-
directional in the sense that ingress Service Frames can originate at any UNI in an EVC.
There are three types of EVC. They are as described in Sections 6.1.1, 6.1.2.1, and 6.1.2.2.
In a Point-to-Point EVC, exactly two UNIs MUST be associated with one another. An ingress
Service Frame mapped (see Section 7.7) to the EVC at one UNI MUST NOT result in an egress
Service Frame at a UNI other than the other UNI in the EVC. The rules under which a Service
Frame is delivered to the destination UNI are specific to the particular service definition. Figure
2 illustrates two Point-to-Point EVCs.
EVC1
EVC2
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.
In a Multipoint-to-Multipoint EVC, the rules under which a frame is delivered to a UNI in the
EVC are specific to the particular service definition. Typically, a single broadcast or multicast
ingress Service Frame (as determined from the destination MAC address) at a given UNI would
be replicated in the Metro Ethernet Network and a single copy would be delivered to each of the
other UNIs in the EVC. This kind of delivery would also typically apply to a Service Frame for
which the MEN has not yet learned an association of the destination MAC address with an EVC,
UNI pair. Figure 3 illustrates a Multipoint-to-Multipoint EVC.
2
There may be frames that are not Service Frames that should be delivered back to the ingress UNI. An example
might be a loop-back frame. These kinds of frames are beyond the scope of this Technical Specification.
3
A Multipoint-to-Multipoint EVC with two UNIs is different from a Point-to-Point EVC because one or more
additional UNIs can be added to the Multipoint-to-Multipoint EVC.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 8
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
In a Rooted-Multipoint EVC, one or more of the UNIs MUST be designated as a Root and each
of the other UNIs MUST be designated as a Leaf. An ingress Service Frame mapped to the EVC
at a Root UNI MAY be delivered to one or more of the other UNIs in the EVC. An ingress
Service Frame mapped to the EVC at a Leaf UNI MUST NOT result in an egress Service Frame
at another Leaf UNI but MAY result in an egress Service Frame at some or all of the Root UNIs.
The rules under which a frame is delivered to a UNI in the EVC are specific to the particular
service definition. Typically, a single broadcast or multicast ingress Service Frame (as
determined from the destination MAC address) at a Root UNI would be replicated in the Metro
Ethernet Network and a single copy would be delivered to each of the other UNIs in the EVC.
This kind of delivery would also typically apply to a Service Frame for which the MEN has not
yet learned an association of the destination MAC address with an EVC, UNI pair. Figure 4
illustrates a Rooted-Multipoint EVC with one Root UNI.
Leaf
Root
Leaf
Known unicast
The EVC ID is an arbitrary string administered by the Service Provider that is used to identify an
EVC within the MEN. The EVC ID MUST be unique across all EVCs in the MEN. It is intended
for management and control purposes. The EVC ID is not carried in any field in the Service
Frame. As an example, the Acme Service Provider might use EVC-0001898-ACME-
MEGAMART to represent the 1898th EVC in the MEN and the customer for the EVC is
MegaMart.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 9
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
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.
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.
Given that there are several Layer 2 protocols used for various control purposes, it is important
that Metro Ethernet Networks be able to process such information effectively. 4 A Service Frame
whose destination MAC address is one of the addresses listed in Table 1, MUST be treated as
Layer 2 Control Protocol Service Frame.
Some Layer 2 Control protocols share the same destination MAC address and are identified by
additional fields such as the Ethertype and a protocol identifier. Therefore, disposition of Service
Frames carrying Layer 2 Control Protocols MAY be different for different protocols that use the
4
This capability will be especially important for Subscribers who choose to deploy IEEE 802.1D [8] or IEEE
802.1Q [9] bridges (as opposed to routers) as CEs.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 10
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
same destination MAC address. [5] contains some recommendations for the delivery of specific
Layer 2 Control protocols.
A Service Provider MAY define additional addresses for identifying Layer 2 Control protocols
in addition to those in Table 1.
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.
Deliver Unconditionally: No matter what the content (assuming correct FCS) of the
Service Frame, it is delivered across the other (egress) UNI(s). This might be the
behavior of a Point-to-Point EVC.
Deliver Conditionally: The Service Frame is delivered across an egress UNI if certain
conditions are met. An example of such a condition is that the destination MAC address
is known by the Metro Ethernet Network to be at the destination UNI. Another
example is broadcast throttling where some Service Frames with the broadcast
destination MAC address are dropped to limit the amount of such traffic. When this
option is in force the conditions MUST be specified.
Tunnel: This applies only to Layer 2 Control Protocol Service Frames. See Section 6.7.
More details about the disposition of Layer 2 Control Protocol Service Frames are presented in
Sections 6.7 and 7.13.
5
Hexadecimal canonical format
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 11
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
Note that this is a description of the ideal service. Service Frames that should be delivered might
be discarded due to network failure or congestion conditions. See the EVC Related Performance
Service Attributes in Section 6.8.
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.
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.
A Service Frame is defined to have its CE-VLAN ID Preserved when the relationship between
the ingress Service Frame and its corresponding egress Service Frame(s) is as described in Table
2.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 12
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
An EVC with the CE-VLAN ID Preservation Service Attribute MUST preserve the CE-VLAN
ID for Service Frames as described in Table 3.
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.
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.
In some cases, it is desirable to carry Layer 2 Control Protocols across the Service Provider
network. This is called Layer 2 Control Protocol tunneling because the frame MUST be passed
through the Service Provider network without being processed 7 and delivered to the proper UNI
6
Note that in the case of a Multipoint EVC, a single ingress Service Frame can result in more than one egress
Service Frame.
7
For example, the Subscribers Ethernet information can be encapsulated in another frame separate from the control
protocol frame.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 13
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
or UNIs. The tunneling capability can be extremely useful, for example, when the Subscriber
chooses to attach bridges to all UNIs and thus BPDUs need to be carried across the Network.
When a Layer 2 Control Protocol is tunneled, the Service Frame at each egress UNI MUST be
identical to the corresponding ingress Service Frame.
For a given EVC at a given UNI, the Service Provider defines which Layer 2 Control Protocols
will be tunneled via the EVC and which will be discarded. If a Service Frame carrying a Layer 2
Control Protocol is tunneled, it MUST be tunneled on the EVC that is identified by the CE-
VLAN/EVC Map for the CE-VLAN ID indicated by the Service Frame carrying the Layer 2
Control Protocol. 8 See Section 7.7.
Note that if a Layer 2 Control Protocol is to be tunneled, then all UNIs in the EVC MUST be
configured to pass the Layer 2 Control Protocol to the EVC. See Section 7.13.3.
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.
In this case, all ingress Data Service Frames mapped to the EVC SHALL have the same Class of
Service Identifier.
As an example, consider EVC 1 and EVC 2 at a UNI. Data Service Frames on EVC 1 have a first
Class of Service Identifier that indicates gold service. Data Service Frames on EVC 2 have a
second Class of Service Identifier that indicates silver service. All tunneled Layer 2 Control
Protocols on EVC 1 also have the first Class of Service Identifier thus indicating gold service.
All tunneled Layer 2 Control Protocols on EVC 2 have a third Class of Service Identifier that
indicates platinum service.
8
Tunneling of BPDUs when Service Multiplexing is in effect at a UNI can lead to undesirable behavior. For
example, if bridges are attached to all UNIs, then tunneled BPDUs will not reach all of the bridges and the Spanning
Tree Protocol will not operate properly.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 14
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
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.
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.
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
The EVC Related Performance Service Attributes specify the Service Frame delivery
performance. Four performance attributes are considered in this specification. These are Frame
Delay Performance, Inter-Frame Delay Variation Performance, Frame Loss Ratio Performance,
and Availability Performance.
9
In IP version 4, the DSCP is contained in the TOS field. In IP version 6, the DSCP is contained in the Traffic Class
Octet.
10
For example, Service Frames carrying a BPDU could be assigned one Class of Service Identifier while Service
Frames carrying a GARP protocol message could be assigned a different Class of Service Identifier.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 15
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
Performance Attributes apply to Qualified Service Frames, which are frames that meet the
following criteria for a given ordered pair of UNIs and a given Class of Service:
Each Service Frame MUST be the first egress Service Frame at the same UNI j resulting
from an ingress Service Frame at the other UNI i of the ordered pair. The Service Frame
MAY be a Unicast (see Section 6.5.1.1), Multicast (see Section 6.5.1.2), Broadcast (see
Section 6.5.1.3), or Layer 2 Control Protocol (see Section 6.5.1.4) Service Frame. Note
that a single ingress Service Frame can result in multiple egress Service Frames, e.g., a
Multicast Service Frame.
The first bit of each Service Frame MUST arrive at the ingress UNI within the time
interval T,
Each Service Frame MUST have the Class of Service Identifier for the Class of Service
instance in question, and
Each ingress Service Frame MUST have an Ingress Bandwidth Profile compliance of
Green.
Such Service Frames are elements of the set of Qualified Service Frames for an Ordered Pair of
UNIs and a given Class of Service on an EVC.
Performance Attributes MUST NOT apply to Service Frames with the level of conformance
determined to be Yellow or Red. Typically, the Frame Loss Ratio Performance will be degraded
for Service Frames determined to be Yellow. Service Frames determined to be Red will be
discarded. (See Section 7.11.2.5.)
For a given EVC and Class of Service instance, Performance Objectives MAY be specified over
any given subset of the Ordered Pairs of UNIs (describing transmission direction) on the EVC.
Once a subset of UNI pairs is defined, then all attributes in this section SHALL have
performance objectives applying to that subset. Section 10.4 provides examples on how to
structure these metrics to be UNI-oriented and EVC-oriented.
Values of the Service Frame delay, delay variation, and loss performance during periods of
unavailable time MUST NOT be used to determine Service Frame delivery compliance. A
process MUST be established to exclude all performance during unavailable periods from
comparison with Service Frame performance objectives.
The assessment of all performance attributes SHOULD account for unexpected arrival
phenomena, such as frame duplication, or frames arriving in a different order from that observed
on ingress, and the presence of these phenomena alone do not necessarily exclude a Service
Frame from the set of Qualified Service Frames.
NOTE The contents of this section in [13] have been deleted, and the scope of Section 6.9.2
has been broadened to cover the Point-to-Point EVC case.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 16
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
This section defines three performance attributes: the One-way Frame Delay Performance
corresponding to a percentile of the distribution, the One-way Mean Frame Delay, and the One-
way Frame Delay Range.
The One-way Frame Delay for an egress Service Frame at a given UNI in the EVC is defined as
the time elapsed from the reception at the ingress UNI of the first bit of the corresponding
ingress Service Frame until the transmission of the last bit of the Service Frame at the given
UNI. This delay definition is illustrated in Figure 5.
CE CE
Metro Ethernet
time Network
first bit in
UNI to UNI
Frame
Delay
last bit out
Note that this definition of Frame Delay for a Service Frame is the one-way 11 delay that includes
the delays encountered as a result of transmission across the ingress and egress UNIs as well as
that introduced by the MEN.
There MAY be multiple Frame Delay Performance Objectives defined for a particular Class of
Service instance on an EVC. Each such metric is based on a subset of the ordered pairs of UNIs
in the EVC for a time interval T. Each Frame Delay Performance metric SHALL be defined as
follows:
Let the UNIs in the EVC be numbered from 1 to m. And let S be a subset of the ordered
UNI pairs in the EVC. That is S { i, j | i = 1,..., m, j = 1,..., m, i j}.
i, j
Let dT represent the P-Percentile of one-way delay for all Qualified Service Frames
delivered to UNI j resulting from an ingress Service Frame at UNI i. If there are no such
egress Service Frames at UNI j resulting from ingress Service Frames at UNI i, then
d T = Undefined.
i, j
11
One-way delay is difficult to measure and therefore one way delay may be approximated from two way
measurements. However these techniques are beyond the scope of this document.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 17
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
Then the One-way Frame Delay Performance metric SHALL be defined as the maximum
value of all of the values dT for i, j S , unless all dT are Undefined in which case
i, j i, j
Let d Tyx = d Ty d Tx
i, j i, j i, j
represent the difference between Percentiles Py and Px (where
Py > Px and i and j are the same pair in each term) of one-way delay for all Qualified
Service Frames delivered to UNI j resulting from an ingress Service Frame at UNI i. If
there are no such egress Service Frames at UNI j resulting from ingress Service Frames at
UNI i, then d Txy = Undefined.
i, j
Then the One-way Frame Delay Range Performance metric SHALL be defined as the
maximum value of all of the values of the difference d Tyx = d Ty d Tx for i, j S ,
i, j i, j i, j
i, j
unless all dTxy are Undefined in which case the performance is Undefined.
Let T
i, j
represent the arithmetic mean of one-way delay for all Qualified Service
Frames delivered to UNI j resulting from an ingress Service Frame at UNI i. If there are
no such egress Service Frames at UNI j resulting from ingress Service Frames at UNI i,
then T = Undefined.
i, j
Then the One-way Mean Frame Delay Performance metric SHALL be defined as the
maximum value of all of the values T for i, j S , unless all T are Undefined in
i, j i, j
To restate the Frame Delay definition mathematically, let the UNIs in the EVC be numbered
i, j
from 1 to m and let DT be the set of one-way Frame Delay values for all Qualified Service
i, j
Frames at UNI j resulting from an ingress Service Frame at UNI i. DT can be expressed as
DT
i, j
{
= d1
i, j
, d2
i, j i, j
}
,..., d N i , j , where d k
i, j
is the one-way Frame Delay of the kth Service Frame.
i, j
Define dT for P > 0 as
( ) if N
N i, j
100
min d | P I d, dk
i, j
1
=
i, j
dT N i, j k =1
i, j
Undefined otherwise
where,
1 if d d k
I (d , d k ) = .
0 otherwise
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 18
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
i, j
dT is the minimal delay during the time internal T that P percent of the frames do not exceed.
i, j
Note that when P>0, only values of d within DT will satisfy P(100/N<i,k>)I(d,dk).
Then a one-way Frame Delay Performance metric for an EVC can be expressed as
d T ,S =
{
max d T i , j | i, j S and where N i , j > 0
.
}
Undefined when all N i , j = 0 | i, j S
The One-way Frame Delay attribute permits specification of multiple values for P, (P0, P1, P2,
) and corresponding objectives ( d0 , d1 , d2 , ). Another parameter is the objective
i, j i, j i, j
for the difference between the delay performance of two selected percentiles, Px and Py ,
expressed as
(d d Tx ) if N i , j > 0
i, j i, j
d Tyx = Ty
i, j
Undefined if N i , j = 0
Then a one-way Frame Delay Range Performance metric for an EVC can be expressed as
d TyxS =
{
max d Tyxi , j | i, j S and where N i , j > 0
.
}
Undefined when all N i , j = 0 | i, j S
T i , j
( )
1 N i, j i, j
d if N i, j > 0
= N i , j k =1 k
Undefined if N =0
i, j
Then a One-way Mean Frame Delay Performance metric for an EVC can be expressed as
TS =
{
max T i , j | i, j S and T i , j where N i , j > 0
.
}
Undefined when all N i , j = 0 | i, j S
The parameters of a One-way Frame Delay Performance metric are given in Table 4.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 19
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
Parameter Description
T The time interval
S Subset of the ordered UNI pairs of the EVC
Px A specific percentile of the Frame Delay Performance, Px > 0
Py Another specific percentile of the Frame Delay Performance, where Py > Px
d x One-way Frame Delay Performance Objective corresponding to Px
d y
One-way Frame Delay Performance Objective corresponding to Py
One-way Frame Delay Range Objective corresponding to the Frame Delay
d yx
Performance at Px and Py d Tyx = (d Ty d Tx ) where Py > Px
i, j i, j i, j
Given T, S, Px , and a one-way Frame Delay Performance objective d x , expressed in time units,
the one-way Frame Delay Performance SHALL be defined as met over the time interval T for
the subset S if and only if d T ,S d x . Further, given Py and a One-way Frame Delay Performance
objective d y , expressed in time units, the objective for one-way Frame Delay Range between Px
and Py SHALL be defined as met over the time interval T for the subset S if and only if
d d . Finally, given a One-way Mean Frame Delay Performance objective , expressed in
TyxS yx
time units, the Frame Delay Performance SHALL be defined as met over the time interval T if
and only if TS .
Recall that if any of the above Service Frame Performance attributes are Undefined for time
interval T and ordered pair i, j , then the performance for that ordered pair SHALL be
excluded from calculations on the performance of pairs in S. For a given set S, if the Service
Performance is Undefined for all ordered pairs, then the performance for S SHALL be defined
as compliant.
For a Point-to-Point EVC, S MAY include one or both of the ordered pairs of UNIs in the EVC.
For a Multipoint-to-Multipoint EVC, S MAY be any subset of the ordered pairs of UNIs in the
EVC.
For a Rooted-Multipoint EVC, S MUST be such that all ordered pairs in S contain at least one
UNI that is designated as a Root.
NOTE The contents of this section in [13] have been deleted, and the scope of Section 6.9.4
has been broadened to cover the Point-to-Point EVC case.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 20
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
Inter-Frame Delay Variation (IFDV) is the difference between the one-way delays of a pair of
selected Service Frames. This definition is borrowed from RFC3393 [6] where IP packet delay
variation is defined. For a particular Class of Service Identifier and an ordered pair of UNIs in
the EVC, IFDV Performance is applicable to Qualified Service Frames.
NOTE Earlier documents refer to Inter-Frame Delay Variation as Frame Delay Variation.
The Inter-Frame Delay Variation Performance SHALL be defined as the P-percentile of the
absolute values of the difference between the Frame delays of all Qualified Service Frame pairs
that satisfy the following conditions:
The difference in the arrival times of the first bit of each Service Frame at the ingress
UNI was exactly t.
This definition is in agreement with the IP packet delay variation definition given in [6] where
the delay variation is defined as the difference between the one-way delay of two packets
selected according to some selection function and are within a given interval [T1, T2].
Inter-Frame Delay Variation Performance depends on the choice of the value for t. Values for
both t and T typically should be chosen to achieve a reasonable level of statistical accuracy.
The choice of the value for t can be related to the application timing information. As an
example for voice applications where voice frames are generated at regular intervals, t may be
chosen to be few multiples of the inter-frame time.
Let ai be the time of the arrival of the first bit of the ith Service Frame at the ingress UNI, then
the two frames i and j are selected according to the selection criterion:
{a j ai = t and j > i}
Let ri be the time frame i is successfully received (last bit of the frame) at the egress UNI, then
the difference in the delays encountered by frame i and frame j is given by d i d j . Define
With d j being the delay of the jth frame, a positive value for d i d j implies that the two frames
are closer together at the egress UNI while a negative value implies that the two frames are
further apart at the egress UNI. If either or both frames are lost or not delivered due to, for
example, FCS violation, then the value d ij is not defined and does not contribute to the
evaluation of the Inter-Frame Delay Variation.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 21
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
Figure 6 shows a depiction of the different times that are related to Inter-Frame Delay Variation
Performance.
i i+1 j j+1
ai aj
Ingress
t Time
ri rj
Egress
di dj
For a particular Class of Service instance, Inter-Frame Delay Variation Performance metrics
MAY be specified over any given subset of two or more UNIs on an EVC. Each such metric is
based on a subset of the ordered pairs of UNIs in the EVC for a time interval T. Each Inter-
Frame Delay Variation Performance metric SHALL be defined as follows:
Let the UNIs in the EVC be numbered from 1 to m. And let S be a subset of the ordered
UNI pairs in the EVC. That is S { i, j | i = 1,..., m, j = 1,..., m, i j}.
~ i, j
Let dT be the P-percentile of the absolute value of the difference between the Frame
Delays of all Qualified Service Frame pairs whose difference in the arrival times of the
first bit of each Service Frame in the pair at UNI i was exactly t .
If there are no such pairs of Service Frames for UNI i and UNI j, then
~ i, j
d T = Undefined .
Then the Inter-Frame Delay Variation Performance metric SHALL be the maximum of
~ i, j ~ i, j
the values dT for i, j S , unless all dT are Undefined in which case the
performance is Undefined.
To restate the definition mathematically, let the UNIs in the EVC be numbered from 1 to m. And
let S be a subset of the ordered UNI pairs in the EVC. That is
Let
= {d1 , d 2 ,..., d N i , j }
i, j i, j i, j i, j
VT
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 22
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
be the set of all absolute value of delay variations for all eligible pairs of Qualified Service
Frames from UNI i to UNI j where the difference in the arrival times of the first bit of each
Service Frame at the ingress UNI was exactly t. Define
N
100 i , j
~ i, j
d T
min d | P
= I (d , d k
i, j
) if N i , j 1
N i , j k =1
Undefined otherwise
where;
1 if d d
I (d , d ) = .
0 otherwise
Then an Inter-Frame Delay Variation Performance metric for an EVC can be expressed as
~
d T , S =
{
max d~T i , j | i, j S and where N i , j 1
.
}
Undefined when all N i , j = 0 | i, j S
For the SLS, an Inter-Frame Delay Variation metric MUST specify a set of parameters and an
objective. The parameters and objective for an Inter-Frame Delay Variation Performance metric
are given in Table 5.
Parameter Description
T The interval
S Subset of the ordered UNI pairs of the EVC
P Inter-Frame Delay Variation Performance percentile
The separation between frame pairs for which Inter-Frame Delay
t
Variation Performance is defined
d Inter-Frame Delay Variation Performance Objective
Given T, S, P, t, and d , the Inter-Frame Delay Variation Performance SHALL be defined as
~
met over the time interval T for the subset S if and only if dT , S d .
Recall that if the Inter-Frame Delay Variation is Undefined for time interval T and ordered pair
i, j , then the performance for that ordered pair SHALL be excluded from calculations on the
performance of pairs in S. For a given set S, if the Service Performance is Undefined for all
ordered pairs, then the performance for S SHALL be defined as compliant.
For a Point-to-Point EVC, S MAY be include one or both of the ordered pairs of UNIs in the
EVC.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 23
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
For a Multipoint-to-Multipoint EVC, S MAY be any subset of the ordered pairs of UNIs in the
EVC.
For a Rooted-Multipoint EVC, S MUST be such that all ordered pairs in S contain at least one
UNI that is designated as a Root.
NOTE Section 6.9.7 refers to this section for the definition of the frame loss ratio flr (ti ) of a
Point-to-Point EVC. For the purposes of the Availability Performance, the Frame Loss Ratio
Performance (defined in detail in Section 6.9.6) SHALL be defined as follows:
flr (t i ) = FLRti ,S =
{
max FLRt | i, j S and where I t 1
i
i, j
i
i, j
}
0 when all I ti = 0 | i, j S
i, j
where the set of ordered pairs, S, contains both ordered pairs of UNIs in the Point-to-Point EVC.
NOTE The contents of this section in [13] have been deleted, and the scope of Section 6.9.6
has been broadened to cover the Point-to-Point EVC case.
There MAY be multiple One-way Frame Loss Ratio Performance metrics defined for a
particular Class of Service instance on an EVC. Each such metric is based on a subset of the
ordered pairs of UNIs in the EVC for a time interval T. Each One-way Frame Loss Ratio
Performance metric SHALL be defined as follows:
Let the UNIs in the EVC be numbered from 1 to m. And let S be a subset of the ordered
UNI pairs in the EVC. That is S { i, j | i = 1,..., m, j = 1,..., m, i j}.
i, j
Let I T denote the number of ingress Service Frames at UNI i whose first bit arrived at
UNI i during the time interval T, whose Ingress Bandwidth Profile compliance was
Green, and that should have been delivered to UNI j according to the Service Frame
Delivery service attributes (see Sections 6.5.2, 6.7, and 7.13). Each Service Frame can be
a Unicast (see Section 6.5.1.1), Multicast (see Section 6.5.1.2), Broadcast (see Section
6.5.1.3), or Layer 2 Control Protocol (see Section 6.5.1.4) Service Frame.
i, j
Let ET denote the number of such Service Frames delivered to UNI j.
I Ti , j ETi , j
100 if I Ti , j 1
=
i, j
Define FLRT i
IT , j .
Undefined otherwise
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 24
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
Then the One-way Frame Loss Ratio Performance metric SHALL be defined as
{
max FLRTi , j | i, j S and where I Ti , j 1
FLRT ,S = .
}
Undefined when all I T = 0 | i, j S
i, j
For the SLS, a One-way Frame Loss Ratio Performance metric entry MUST specify a set of
parameters and an objective. The parameters and objective of a One-way Frame Loss Ratio
Performance metric are given in Table 6.
Parameter Description
T The time interval
S Subset of the ordered UNI pairs
L One-way Frame Loss Ratio Performance
objective
Table 6 One-way Frame Loss Ratio Performance Parameters
Given T, S, and a One-way Frame Loss Ratio Performance objective, the One-way Frame Loss
Performance SHALL be defined as met over the time interval T for the subset S if and only if
FLRT , S L .
Recall that if the One-way Frame Loss Ratio Performance is Undefined for time interval T and
ordered pair i, j , then the performance for that ordered pair SHALL be excluded from
calculations on the performance of pairs in S. For a given set S, if the Service Performance is
Undefined for all ordered pairs, then the performance for S SHALL be defined as compliant.
For a Point-to-Point EVC, S MAY include one or both of the ordered pairs of UNIs in the EVC.
For a Multipoint-to-Multipoint EVC, S MAY be any subset of the ordered pairs of UNIs in the
EVC.
For a Rooted-Multipoint EVC, S MUST be such that all ordered pairs in S contain at least one
UNI that is designated as a Root.
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.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 25
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
is defined as unavailable. Otherwise the current sequence is defined as available. On the other
hand, if the previous sequence was defined as unavailable, and if frame loss is low for each small
time interval in the current sequence, then the current sequence is defined as available.
Otherwise, the current sequence is defined as unavailable. The formal definition follows.
The Availability for a particular Class of Service instance on a Point-to-Point EVC for a time
interval T is based on the following four parameters:
Ca , a loss ratio threshold which if not exceeded suggests availability with Ca Cu , and
n , the number of consecutive small time intervals, t , over which to assess availability.
Suppose the time interval T = [t0 ,t1 ] and define ti = [t0 + (i 1)t , t0 + it ], for i = 1,2,..., n .
Define sets of n consecutive small time intervals as S k = {t(k 1)n +1 , t(k 1)n + 2 ,..., t kn }. Also define
flr (ti ) to be the Frame Loss Ratio defined in Section 6.9.5 with ti replacing T. Let
T = {ti | ti T } . Let K be the largest integer such that ti T , ti S K . In other words, S K
~ ~
Define the function Ds (k ) to indicate if a sequence of small time intervals includes Scheduled
Downtime:
Scheduled Downtime is a time interval agreed upon by both the Subscriber and Service Provider
during which a service may be disabled by the Service Provider.
Define the function Du (k ) to indicate if a sequence of small time intervals includes Unscheduled
Downtime:
Unscheduled Downtime is a time interval not agreed upon by both the Subscriber and Service
Provider during which the Service Provider determines that the service is not usable. The method
by which the Service Provider determines that Unscheduled Downtime is occurring is beyond
the scope of this document. When Unscheduled Downtime is occurring, the Service Provider
may notify the Subscriber via the Ethernet Local Management Interface.[11]
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 26
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
Let M be the number of sequences that contain Scheduled Downtime and no Unscheduled
Downtime. These sequences are excluded when considering availability.
Finally define an indicator function I (S k ) as follows whose value is 1 if the service is available
during S k and 0 otherwise:
0 if Du (1) = 1
I (S1 ) =
1 otherwise
0 if Du (k ) = 1
1 if (Du (k ) = 0 ) and (Ds (k ) = 1)
I (S k ) = for k = 2,..., K .
U (k ) if ( Du (k ) = 0 ) and ( Ds (k ) = 0 ) and ( I (S k 1 ) = 1)
A(k ) otherwise
Note that any S k that has Unscheduled Downtime is defined as unavailable and thus
Unscheduled Downtime overrides Scheduled Downtime during an interval S k .
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 27
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
100 K
AT = K M I ( S k ) M if M < K .
k =1
100 otherwise
For the SLS, an Availability Performance metric MUST specify a set of parameters and an
objective as shown in Table 7.
Parameter Description
T The time interval
t A time interval much smaller than T
Cu Unavailability frame loss ratio threshold
Ca Availability frame loss ratio threshold with Ca Cu
n Number of consecutive small time intervals for assessing availability
A Availability Performance objective
Table 7 Availability Performance Parameters for a Point-to-Pointe EVC
There MAY be multiple Availability Performance metrics specified for a particular Class of
Service instance on a Multipoint EVC. Each such metric is based on a subset of the pairs of
UNIs in the Multipoint EVC and for a time interval T. Each Availability Performance metric
SHALL be defined as follows: Let the UNIs in the EVC be numbered from 1 to m. And let S be
a subset of the UNI pairs in the EVC. That is S { i, j | i = 1,..., m, j = 1,...m, j > i}.
Let Ca be a loss ratio threshold which if not exceeded suggests availability with Ca Cu .
Let n be the number of small time intervals, t , over which to assess availability.
i, j
Let AT be denote the availability between UNI i and UNI j defined in Section 6.9.7 as
if there was a Point-to-Point EVC between UNI i and UNI j.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 28
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
Parameter Description
T The time interval
S Subset of the UNI pairs
t A time interval much smaller than T
Cu Unavailability frame loss ratio threshold
Ca Availability frame loss ratio threshold with Ca Cu
n Number of consecutive small time intervals for assessing availability
A Availability Performance objective
Table 8 Availability Performance Parameters for a Multipoint EVC
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.
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.
This section describes attributes at each UNI. These attributes fall into two types:
12
The MTU Size for an EVC will be constrained by the MTU size of the network equipment used to carry the frame
including the network equipment supporting each UNI. The method of calculating the MTU Size is beyond the
scope of this specification.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 29
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
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.
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.
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.
The protocols running at the UNI MUST support the IEEE 802.3 2005 [2] frame formats with
the possible exception that the information field MAY be larger than 1500 bytes. (See Sections
6.10 and 7.4.) This attribute is independent of the EVCs at the UNI.
13
An exception might be wireless when the service requires stringent requirements on packet loss.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 30
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
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.
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.
At the given UNI, the EVC for a Service Frame MUST be identified by the Customer Edge
VLAN ID (CE-VLAN ID). There are 4095 CE-VLAN IDs numbered 1 through 4095. The CE-
VLAN ID for a Service Frame with an IEEE 802.1Q Customer VLAN Tag [10] MUST be the
14
Since the UNI is dedicated to a single Subscriber, only one Subscriber can access the EVCs at the UNI.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 31
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
value of the VLAN ID, if not 0, in the tag. Untagged and priority tagged 15 Service Frames
MUST have the same CE-VLAN ID and that value MUST be configurable to any value in the
range 1, 2, , 4094. When the CE-VLAN ID Preservation Service Attribute is not in force for
an EVC to which the CE-VLAN ID for untagged and priority tagged Service Frames is mapped,
egress Service Frames for this EVC at the given UNI MUST be untagged. When CE-VLAN ID
Preservation Service Attribute is in force for an EVC to which the CE-VLAN ID for untagged
and priority tagged Service Frames is mapped, the format of an egress Service Frame for this
EVC at the given UNI depends on the format of the corresponding ingress Service Frame at a
UNI other than the given UNI in the EVC as described in Section 6.6.1.
More than one CE-VLAN ID MAY point to the same EVC as described in Section 7.9.
Note that certain of the VLAN ID values in IEEE 802.1Q Customer VLAN Tags [10] are
reserved for special purposes in IEEE 802.1Q bridges and thus the number of VLANs in a
subscriber network is less than 4095. Nevertheless, Service Frames with any VLAN ID value as
well as untagged Service Frames can exist at the UNI. Consequently the CE-VLAN ID can have
4095 values. However, less than 4095 EVCs MAY be supported at a UNI. See Section 7.7.
The 4095 CE-VLAN IDs always exist at each UNI and are independent of the EVCs at the UNI.
The CE-VLAN ID configured for untagged and priority tagged Service Frames is also
independent of the EVCs at the UNI.
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.
At each UNI there MUST be a mapping of each CE-VLAN ID to at most one EVC. The
mapping of one or more CE-VLAN IDs to an EVC is an attribute associated with the EVC at the
UNI. The collection of all of these mappings is called the CE-VLAN ID/EVC Map. Note that a
given CE-VLAN ID MAY not be mapped to any EVC. In the simple case, when the Bundling
and All to One Bundling attributes (as defined in Sections 7.9 and 7.10) are not invoked, exactly
one CE-VLAN ID MUST be mapped to at most one EVC. Figure 9 is an example of a CE-
VLAN ID/EVC Map. In this example and all of the following examples, the entry in the EVC
column can be any suitable identifier for the EVC, e.g., the EVC ID (Section 6.1.2.2) or the UNI
EVC ID (Section 7.6.2).
15
A priority tagged Service Frame is a Service Frame with an IEEE 802.1Q [9] tag in which the VLAN ID in the tag
equals 0.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 32
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
CE-VLAN ID EVC
47 EVC1
1343 EVC2
17 16 EVC3
47 EVC1
EVC2
1343
untagged and EVC3
priority tagged, 17 UNI
In this example, an ingress Service Frame with CE-VLAN ID 47 is transported according to the
properties and attributes of EVC1. An untagged or priority tagged ingress Service Frame is
transported according to the properties and attributes of EVC3. An egress frame coming from
EVC2 is given CE-VLAN ID 1343.
When an instance of the CE-VLAN ID/EVC Map does not contain an entry for a given CE-
VLAN ID, any ingress Service Frame at the UNI with this CE-VLAN ID MUST be discarded by
the MEN. Also, an egress Service Frame MUST NOT have a CE-VLAN ID with this value at
the UNI while using this instance of the CE-VLAN ID/EVC Map.
In some scenarios, it may be necessary for the Subscriber and the Service Provider to agree upon
the CE-VLAN ID/EVC Map at the UNI. One way to implement this is to have the Service
Provider dictate the mapping. This is what is frequently done with the mapping between DLCIs
and permanent virtual connections for Frame Relay. Also note that for a given UNI, the CE-
VLAN ID/EVC Map may be constrained by the range of CE-VLAN ID values that can be
supported by the CE and the range of CE-VLAN ID values that can be supported by the Service
Provider. 17
CE-VLAN ID values MAY only be significant at a given UNI. Restated, the CE-VLAN
ID/EVC mapping for a given EVC at a UNI MAY be different from the mapping at another UNI
in the EVC. Figure 10 shows valid CE-VLAN ID/EVC Maps for three EVCs between two UNIs.
Note that when the CE-VLAN ID Preservation attribute (Section 6.6.1) applies to an EVC, the
16
In this example, the CE-VLAN ID for untagged and priority tagged Service Frames is configured to 17.
17
In a future Technical Specification, dynamic EVC setup via a signaling protocol across the UNI may be specified.
In that case, it may be desirable to specify the range of CE-VLAN ID values supported by the Service Provider as a
UNI attribute. In this phase of this Technical Specification, resolving the CE-VLAN ID/EVC Map is assumed to be
done administratively and thus this specifying of a CE-VLAN ID range is not needed.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 33
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
mappings for the EVC are identical as is the case for EVC1 in Figure 10. (Otherwise the CE-
VLAN ID cannot be preserved).
UNI A UNI B
CE-VLAN ID EVC CE-VLAN ID EVC
47 EVC1 47 EVC1
1343 EVC2 1716 EVC2
187 EVC3 1343 EVC3
47 EVC2
EVC1 47
1343 untagged and priority tagged, 17
187 EVC3 1343
UNI A UNI B
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.
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.
When a UNI has the Bundling attribute, it MUST be configurable so that more than one CE-
VLAN ID can map to a particular EVC at the UNI. The Bundling service attribute is independent
of the EVCs at the UNI. An EVC with more than one CE-VLAN ID mapping to it MUST have
the CE-VLAN ID Preservation Service Attribute (see Section 6.6.1) and the list of CE-VLAN
IDs mapped to the EVC MUST be the same at each UNI in the EVC. Figure 11 shows an
example of Bundling. In this example, UNI A and UNI B have the bundling attribute as seen
from the mapping for EVC1. (EVC1 has the CE-VLAN ID Preservation attribute.). Note that
Bundling is compatible with Service Multiplexing. In Figure 11, UNI A and UNI B are examples
of Service Multiplexing and Bundling on the same UNI.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 34
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
UNI B
47,48,49
EVC1 EVC2 1
113 EVC3 47
UNI A UNI C
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.
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:
All UNIs in the EVC must have the All to One Bundling Service Attribute
All to One Bundling is a special case of Bundling but it is sufficiently important to be called out
as a separate attribute.
Table 10 shows the valid combinations of the bundling and Service Multiplexing attributes.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 35
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
Valid Valid Valid Valid Valid
Combination Combination Combination Combination Combination
1 2 3 4 5
Service Multiplexing
Bundling
All to One Bundling
Table 10 Valid Combinations of Service Multiplexing, Bundling, and All to One Bundling
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.
Committed Information Rate (CIR) expressed as bits per second. CIR MUST be 0.
Committed Burst Size (CBS) expressed as bytes. When CIR > 0, CBS MUST be greater
than or equal to the largest Maximum Transmission Unit size among all of the EVCs that
the Bandwidth Profile applies to. See Section 6.10.
Excess Information Rate (EIR) expressed as bits per second. EIR MUST be 0.
Excess Burst Size (EBS) expressed as bytes. When EIR > 0, EBS MUST be greater than
or equal to the largest Maximum Transmission Unit size among all of the EVCs that the
Bandwidth Profile applies to. See Section 6.10.
Coupling Flag (CF) MUST have only one of two possible values, 0 or 1.
Color Mode (CM) MUST have only one of two possible values, color-blind and
color-aware.
Each Service Frame is classified to determine which, if any, Bandwidth Profile is applicable to
the Service Frame. 18 Operation of the Bandwidth Profile algorithm is governed by the six
parameters, <CIR, CBS, EIR, EBS, CF, CM>. The algorithm declares each Service Frame to be
compliant or non-compliant relative to the Bandwidth Profile. The level of compliance is
expressed as one of three colors, Green, Yellow, or Red. 19
The Bandwidth Profile algorithm is said to be in color aware mode when each Service Frame
already has a level of compliance (i.e., a color) associated with it and that color is taken into
account in determining the level of compliance by the Bandwidth Profile algorithm. The
Bandwidth Profile algorithm is said to be in color blind mode when the color (if any) already
associated with each Service Frame is ignored by the Bandwidth Profile Algorithm. Color blind
mode support is REQUIRED for Bandwidth Profiles. Color aware mode is OPTIONAL for
Bandwidth Profiles. The color mode of operation MUST be determined using the parameter CM.
Since the coupling Flag has negligible effect in color blind mode (CM = color-blind), a service
definition that uses color blind operation MAY be defined without specifying the value of the
coupling flag.
The Bandwidth Profile algorithm is shown in Figure 13. For a sequence of Service Frames,
{t j , l j }, j 0, t j +1 t j , with arrival times at the reference point t j and lengths l j , the level of
compliance color assigned to each Service Frame MUST be defined according to the algorithm
in Figure 13. For this algorithm, Bc (t0 ) = CBS and Be (t0 ) = EBS . Bc (t ) and Be (t ) can be viewed
as the number of bytes in the Committed and Excess token buckets respectively at a given time t.
18
Recall that a Service Frame is defined as any Ethernet Frame transmitted across the UNI and thus a Layer 2
Control Protocol Ethernet frame is a Service Frame and thus can be subject to a Bandwidth Profile.
19
The categorization of a Service Frame does not imply any change to the content of the frame. Certain approaches
to network implementation may mark frames internal to the MEN but such procedures are beyond the scope of
this Technical Specification.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 37
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
Service Frame of length l j arrives at time t j ( j 1)
Bc (t j ) = min CBS , Bc (t j 1 ) + (t j t j 1 )
CIR
8
O (t j ) = max 0, Bc (t j 1 ) + (t j t j 1 ) CBS
CIR
8
Be (t j ) = min EBS , Be (t j 1 ) + (t j t j 1 ) + CF O(t j )
EIR
8
Note that the algorithm in Figure 13 does not define an implementation of any network
equipment. In fact, since the behavior is described with real numbers for representing time,
exactly implementing the behavior is theoretically impossible. However, an implementation
should be such that over any time interval [t j , t k ] the amount of traffic declared green, WG and
the amount of traffic declared yellow, WY are lower bounded below by the values:
WG Bc (t j ) + (t k t j )
CIR
8
WY Be (t j ) + (t k t j )
EIR
8
The Coupling Flag CF is set to either 0 or 1. The choice of the value for CF has the effect of
controlling the volume of the Service Frames that are declared Yellow. When CF is set to 0, the
long term average bit rate of Service Frames that are declared Yellow is bounded by EIR. When
CF is set to 1, the long term average bit rate of Service Frames that are declared Yellow is
bounded by CIR + EIR depending on volume of the offered Service Frames that are declared
Green. In both cases the burst size of the Service Frames that are declared Yellow is bounded by
EBS.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 38
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
The Ingress Bandwidth Profile is used to regulate the amount of ingress traffic at a particular
UNI. An Ingress Bandwidth Profile is defined for ingress Service Frames at the particular UNI.
In other words, the sequence {t j , l j }, j 0, to which the algorithm of Section 7.11.1 is applied is
based on ingress Service Frames at a UNI. There are three Ingress Bandwidth Profile models as
described in Sections 7.11.2.1, 7.11.2.2, and 7.11.2.3.
In this model, a single Ingress Bandwidth Profile MUST be applied to all ingress Service Frames
at the UNI. Figure 14 illustrates an example of the application of ingress policing with an Ingress
Bandwidth Profile per ingress UNI. In the example of Figure 14, ingress Service Frames for the
three EVCs would all be subject to a single Ingress Bandwidth Profile. The Ingress Bandwidth
Profile per Ingress UNI manages bandwidth non-discriminately for all EVCs at the UNI, i.e.
some EVCs may get more bandwidth while others may get less.
The Ingress Bandwidth Profile per Ingress UNI service attribute is independent of the EVCs at
the UNI.
EVC1
Bandwidth Profile
UNI EVC2 per Ingress UNI
EVC3
In this model, a single Ingress Bandwidth Profile MUST be applied to all ingress Service Frames
for an instance of an EVC at the UNI. Thus, if a UNI has 3 Ethernet Virtual Connections, there
could be 3 Ingress Bandwidth Profiles, one for each EVC. Figure 15 illustrates an example of the
application of Ingress Bandwidth Profiles per EVC. In this example, EVC1 could have CIR=15
Mbps, EVC2 could have CIR = 10 Mbps, and EVC3 could have CIR = 20 Mbps.
The Ingress Bandwidth Profile per EVC service attribute is associated with each EVC at the
UNI.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 39
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
7.11.2.3 Ingress Bandwidth Profile per Class of Service Identifier Service Attribute
In this model, a single Ingress Bandwidth Profile MUST be applied to all ingress Service Frames
with a specific Class of Service Identifier. Class of Service Identifiers are specified in Section
6.8. Refer to the example in Figure 16. In this example, there are three Class of Service
Identifiers within EVC1, each with a separate Ingress Bandwidth Profile.
The Ingress Bandwidth Profile per Class of Service Identifier service attribute is associated with
each EVC at the UNI.
CE-
CE-VLAN CoS 0,1,2,3 Ingress Bandwidth Profile per CoS ID
EVC1 CE-
CE-VLAN CoS 4,5 Ingress Bandwidth Profile per CoS ID
CE-
CE-VLAN CoS 6,7
Ingress Bandwidth Profile per CoS ID
UNI
EVC2
Multiple models of Ingress Bandwidth Profile application MAY exist simultaneously at a UNI.
However, a UNI MUST be configured such that only a single Ingress Bandwidth Profile applies
to any given ingress Service Frame. This means that:
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 40
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
If there is a per UNI Ingress Bandwidth Profile, then there cannot be any other Ingress
Bandwidth Profiles at that UNI.
If there is a per EVC Ingress Bandwidth Profile on an EVC, then there cannot be any per
Class of Service Ingress Bandwidth Profiles for instances of CoS on that EVC.
For example, in the configuration of Figure 16, there cannot be an Ingress Bandwidth Profile for
EVC1. Note also for the configuration in Figure 16, that it is possible to configure a per-EVC
Ingress Bandwidth Profile for EVC2 but there happens to not be an Ingress Bandwidth Profile for
EVC2 in this example.
The disposition of a given Service Frame with respect to delivery to an egress UNI is dependent
on the Service Frames level of compliance to the Ingress Bandwidth Profile that is applied to it.
This is called the Ingress Bandwidth Profile compliance level and it has three possible values:
Green, Yellow, or Red. Table 11 defines how the Ingress Bandwidth Profile compliance is
related to the disposition of the Service Frame. In this table, Not Applied identifies the case
where no Ingress Bandwidth Profile was applied to the Service Frame in question.
The disposition of each Service Frame for delivery to each egress UNI MUST be as described in
Table 11.
Ingress Bandwidth
Service Frame Disposition
Profile Compliance
Red Discard
Deliver to the egress UNI according to the Service Attributes of the
Yellow
service instance but SLS performance objectives do not apply.
Green Deliver to the egress UNI according to the Service Attributes of the
Not Applied service instance and SLS performance objectives apply.
Table 11 Service Frame Disposition for Each Egress UNI
The behavior described in Table 11 is based on the arrival of the Service Frame at its ingress
UNI. It does not mandate or constrain in any way the implementation within the Service Provider
network.
From Table 11 it is clear that the better the level of Ingress Bandwidth Profile compliance the
better the performance of the service. In order to increase the level of Ingress Bandwidth Profile
compliance a Subscriber may choose to shape traffic in the CE (see Section 10.3).
An Egress Bandwidth Profile is used to regulate the amount of egress traffic at a particular UNI.
An Egress Bandwidth Profile is defined for a particular UNI and applies to all or a subset of all
egress Service Frames at the UNI in question.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 41
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
The reference point for an Egress Bandwidth Profile is the egress UNI. An Egress Bandwidth
Profile describes arrival times and lengths of Service Frames that will be observed at the egress
UNI when an Egress Bandwidth Profile is in operation in the Service Provider network. This
description is given in terms of what would happen if an observer at the egress UNI applied the
algorithm of Section 7.11.1 to egress Service Frames. This observer would see traffic after it had
been subject to rate limiting and/or shaping in the Service Provider network and thus would have
certain characteristics. These characteristics are described in terms of the behavior of the
algorithm of Section 7.11.1 when run by the observer.
Consider a sequence of egress Service Frames subject to an Egress Bandwidth Profile with
parameters <CIR, CBS, EIR, EBS, CF, CM> and with arrival times and lengths at the egress
UNI, {t j , l j }, j 0 . If the algorithm of Section 7.11.1 is applied to these Service Frames, the
result for each Service Frame SHALL be to declare the Service Frame either Green or Yellow.
The implication is that the regulation of the Service Frames in the Service Provider network is
such that all Service Frames that would determined to be Red by the observer are discarded
before reaching the egress UNI. It is important to reiterate that this description of Egress
Bandwidth Profile does not mandate or constrain in any way the implementation in the Service
Provider network.
There are three Egress Bandwidth Profile models as described in Sections 7.11.3.1, 7.11.3.2, and
7.11.3.3.
In this model, a single Egress Bandwidth Profile MUST be applied to the sequence consisting of
all egress Service Frames at the UNI. The Egress Bandwidth Profile per Egress UNI manages
bandwidth non-discriminately for all EVCs at the egress UNI, i.e. some EVCs may get more
bandwidth while others may get less. Figure 17 portrays this model of Egress Bandwidth Profile.
The Egress Bandwidth Profile per Egress UNI service attribute is independent of the EVCs at the
UNI.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 42
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
In this model, a single Egress Bandwidth Profile is defined for an EVC at the egress UNI. It
MUST be applied to the egress Service Frames that are mapped to the EVC in question. Figure
18 illustrates an Egress Bandwidth Profile for EVC1.
The Egress Bandwidth Profile per EVC service attribute is associated with each EVC at the UNI.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 43
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
7.11.3.3 Egress Bandwidth Profile per Class of Service Identifier Service Attribute
In this model, a single Egress Bandwidth Profile is defined for a specific Class of Service
Identifier that is defined at the egress UNI. It MUST be applied to the egress Service Frames
with the Class of Service Identifier in question. As an example, consider an Egress UNI with two
EVCs with each EVC having 3 Class of Service Identifiers. With this model, there can be up to
six Egress Bandwidth Profiles.
The Egress Bandwidth Profile per Class of Service Identifier service attribute is associated with
each EVC at the UNI.
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.
There are four alternatives for processing a given Layer 2 Control Protocol (see Table 1) at a
UNI as described in the following subsections. The UNI Layer 2 Control Protocol Processing
service attribute is independent of the EVCs at the UNI.
7.13.1 Discard
When this alternative is in force, the MEN MUST discard all ingress Service Frames carrying
the Layer 2 Control Protocol and the MEN MUST NOT generate any egress Service Frames
carrying the Layer 2 Control Protocol. Note that when this alternative is in force for the Layer 2
Control Protocol, the Layer 2 Control Protocol cannot be processed by an EVC. See Section 6.7.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 44
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
7.13.2 Peer
When this alternative is in force, the MEN MUST act as a peer of the CE in the operation of the
Layer 2 Control Protocol. From the CE point of view, the MEN is a single device that is running
the Layer 2 Control Protocol.
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.
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 or more parameter values associated with each Ethernet Service Attribute.
The Service Framework associates a service with the UNI characteristics at which the Service is
offered to the Subscriber and with the EVC supporting the service. The Ethernet Service
Attributes are what define the UNI and EVC characteristics.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 45
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
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.
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.
For each Service Attribute there can be one or more parameters that specify the attribute.
Parameters can have various types of values including:
Integer
Bandwidth
Protocol
Character String.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 46
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
For a particular Ethernet Service Type, there are two types of Service Attributes, those that apply
to a UNI as described in Section 7 and those that apply to an EVC as described in Section 6. The
UNI and EVC per UNI Service Attributes are listed in Table 12 along with the type of parameter
value for the attribute. For a given instance of a service, a table like that of Table 12 MUST be
specified for each UNI in the EVC associated with the service.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 47
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
20
There are interdependencies among the values of these parameters as per the IEEE 802.3 Standard.[2]
21
Must be No if All to One Bundling is Yes.
22
Must be No if Bundling is Yes or Service Multiplexing is Yes.
23
Must be No if Ingress Bandwidth Profile Per Ingress UNI is not No.
24
Must be No if Ingress Bandwidth Profile Per EVC is not No.
25
Must be No if Egress Bandwidth Profile Per Egress UNI is not No.
26
Must be No if Egress Bandwidth Profile Per EVC is not No.
27
If Peer and Pass to EVC, the method for identifying that a Service Frame is to be peered or passed to the EVC
must be specified.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 48
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
The EVC Service Attributes are listed in Table 13 along with the type of parameter value for the
attribute. For a given instance of a service, a table like that of Table 13 MUST be specified for
the EVC associated with the service.
9. References
[1] Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, RFC 2119,
March 1997. (Normative)
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 49
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
Specific requirements Part 3: Carrier sense multiple access with collision detection
(CSMA/CD) access method and physical layer specifications, 9 December 2005.
(Normative)
[3] IEEE Std 802.3ae 2002, IEEE Standard for Information technology
Telecommunications and information exchange between systems Local and
metropolitan area networks Specific requirements Part 3: Carrier Sense Multiple
Access with Collision Detection (CSMA/CD) Access Method and Physical Layer
Specifications Amendment: Media Access Control (MAC) Parameters, Physical
Layers, and Management Parameters for 10 Gb/s Operation, 13 June 2002. (Normative)
[5] Metro Ethernet Forum, MEF 6, Ethernet Services Definitions - Phase 1, June 2004.
[6] C. Demichelis and P. Chimento, IP Packet Delay Variation Metric for IP Performance
Metric (IPPM), RFC 3393, November 2002.
[7] Metro Ethernet Forum MEF 10, Ethernet Services Attributes Phase 1, November 2004.
[8] IEEE Std 802.1D 2004, IEEE Standard for Local and Metropolitan Area Networks:
Media Access Control (MAC) Bridges, June 2004.
[9] IEEE Std 802.1Q 2003, IEEE Standards for Local and metropolitan area networks
Virtual Bridged Local Area Networks, 7 May 2003.
[10] IEEE Std 802.1ad 2005, IEEE Standard for Local and Metropolitan Area Networks
Virtual Bridged Local Area Networks Amendment 4: Provider Bridges, May 2006.
[11] Metro Ethernet Forum MEF 16, Ethernet Local Management Interface (E-LMI),
January 2006.
[12] Metro Ethernet Forum MEF 7, EMS-NMS Information Model, October 2004.
[13] Metro Ethernet Forum MEF 10.1, Ethernet Services Attributes Phase 2, November
2006.
This appendix contains examples of some of the attributes specified in this Technical
Specification. They are for illustrative purposes only. In the event of a conflict between the
material in this appendix and the main body of this text, the material in the main body is
controlling.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 50
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
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.
Figure shows the notation used for the CE-VLAN ID/EVC Maps in the examples in this sub-
section.
B B Tagged Tagged
Scenario A*: Untagged/Priority Tagged Service Frames are mapped to the EVC
Scenario B : Untagged/Priority Tagged Service Frames are not mapped to the EVC
28
When a UNI has the All to One Bundling or Bundling Attribute set to TRUE, CE-VLAN ID Preservation is
mandated to be yes.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 51
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
B B Tagged Tagged
Scenario A*: Untagged/Priority Tagged Service Frames are mapped to the EVC
Scenario B : Untagged/Priority Tagged Service Frames are not mapped to the EVC
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 52
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
INGRESS FRAMES (UNI E) INGRESS FRAMES (UNI F)
Frame A - Untagged Frame E - Untagged
Frame B - Priority Tagged EVC4 Frame F - Priority Tagged
Frame C - Tagged 40 Frame G - Tagged 44
Frame D - Tagged 42 Frame H - Tagged 46
UNI E UNI F
EGRESS FRAMES (UNI E) EGRESS FRAMES (UNI F)
Frame E - Untagged EVC Frame A - Untagged
CE-VLAN ID EVC CE-VLAN ID
Frame F - Untagged Frame B - Untagged
Frame G - Untagged Frame C - Untagged
40* EVC4 44* EVC4
72 EVC7 76 EVC7
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.
In connecting branch enterprise locations to a hub enterprise location, it is desirable to make the
configuration of the branch CEs simple. A similar objective applies to providing access to higher
layer services, e.g., Internet Access, where the configuration of the CE at the sites accessing the
29
Note that many L2CP Service Frames cannot be tunneled on EVC5 and EVC6 since Untagged/Priority Tagged
Service Frames are not mapped to the EVCs at UNIs H and J. See Section 6.7.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 53
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
service should be kept simple. Figure 25 shows an example of 3 UNIs (A, B, and C) where CEs
only capable of handling untagged Ethernet frames are attached. The CE-VLAN ID/EVC maps
are shown for each UNI. The asterisk indicates the CE-VLAN ID assigned to untagged/priority
tagged Service Frames.
A
EVC1
D
EVC2 B
C
EVC3
Consider an untagged ingress Service Frame at UNI A. It will be mapped to EVC1 and delivered
to UNI D. At UNI D, it will become a tagged egress Service Frame with VLAN ID 2065. A
tagged ingress Service Frame at UNI D with VLAN ID 2065 will be mapped to EVC1 and
delivered to UNI A. At UNI A, it will become an untagged (see Section 7.6.1) egress Service
Frame.
An example of the use of the Rooted-Multipoint EVC is shown in Figure 26. A higher layer
service is being provided via UNI D to three different customers at UNIs A, B, and C. By using a
Rooted-Multipoint EVC, all three customers can be reached by the higher layer service provider
at UNI D using a single EVC. Each customers CE can only send to the higher layer service CE
thus keeping each customer from seeing other customers traffic. Compared with the example
shown in Figure 25, this can save a large number of Point-to-Point EVCs when there are a large
number of customers. Note that the CEs do not necessarily have to send and receive tagged
Service Frames. In particular, the CEs at UNIs A and C do not need to send or receive tagged
Service Frames in this example.
A
Higher
Higher D
B Layer
Layer
EVC1 Service
Service C
Customers
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 54
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
EVCs UNI A UNI B UNI C UNI D
EVC UNIs CE-VLAN ID EVC CE-VLAN ID EVC CE-VLAN ID EVC CE-VLAN ID EVC
EVC1 A (Leaf) *17 EVC1 3379 EVC1 *1023 EVC1 2065 EVC1
B (Leaf)
C (Leaf)
D (Root)
The example shown in Figure 27 illustrates the use of service multiplexing and Multipoint-to-
Multipoint EVCs to provide redundant access to higher layer services. A Multipoint-to-
Multipoint EVC is used for each customer of the higher layer service. Higher layer service
routers are attached to two UNIs (C and D in the example) in each such EVC. Routing protocols
running among the two higher layer service routers and the customer router allow the customer
to access the higher layer service in a redundant fashion.
A
C Higher
Higher EVC1
Layer
Layer D Service
Service EVC2 B
Customers
Shaping is a procedure to reduce the burstiness of traffic. When done in the CE it is meant to
increase the level of Ingress Bandwidth Profile compliance (see Section 7.11.2.5). A shaper is
defined by a set of parameters. Those parameters should be chosen to ensure that the delay
introduced by shaping function is bounded within the acceptable limits and that the traffic
dropped at the shaper is kept to a minimum.
A shaper could be a single rate or a double rate shaper. A single rate shaper could consist of three
parameters CIR, CBS*, and CBS, in which:
CIR = the shaping rate of Green packets (average output rate of the shaper),
CBS = the shaping burst of Green packets (maximum output burst of the shaper)
CBS* = the accepted burst of Green packets (maximum buffer size for Green packets)
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 55
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
CBS* CBS, which means the shaper accepts larger burst at its input and generates
smaller bursts at its output.
A double rate shaper could consist of parameters CIR, CBS*, CBS, EIR, EBS*, and EBS, in
which, CIR, CBS*, and CBS are as defined above, and EIR, EBS*, and EBS are:
EIR = the shaping rate of Yellow packets (average output rate of the shaper),
EBS = the shaping burst of Yellow packets (maximum output burst of the shaper)
EBS* = the accepted burst of Yellow packets (maximum buffer size for Yellow packets)
EBS* EBS, which means the shaper accepts larger burst at its input and generates
smaller bursts at its output.
It is recommended that the CE shape the traffic it sends into the MEN, so that the output of the
shaper matches the CIR, CBS, EIR, and EBS parameters of the appropriate Bandwidth Profile.
For example, the CE could shape with a dual rate token bucket shaper using parameters CIR,
CBS*, CBS, EIR, EBS*, and EBS where EBS* = 0 and CBS* is the shapers buffer size. Define
the following notation:
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,
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.
The algorithm of Figure 29 is run every time a new frame is given to the shaper to process. This
algorithm will send Service Frames with an Ingress Bandwidth Profile compliance of Yellow if
necessary to try to make room in the buffer for the new frame.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 56
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
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.
The performance metric definitions for Multipoint EVCs provide a great deal of flexibility. This
section provides examples on how the subset of UNIs in the EVC can be used to define UNI-
oriented metrics (Section 10.4.1) and EVC-oriented metrics (Section 10.4.2). The Availability
Performance metric is used for these examples.
Both examples use the Multipoint EVC depicted in Figure 30. There are Classes of Service, 1
and 2 on the EVC. The important traffic paths for each CoS have been agreed to by Subscriber
and the Service Provider as shown in the figure.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 57
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
Multipoint EVC
UNI B UNI D
In this case, an Availability Performance metric is defined for each UNI for each Class of
Service. The metric is based on the ability to communicate between the UNI in question and the
other UNIs identified by the important traffic flows. Define the following subsets of UNI pairs:
S A,1 = { A, B , A, C , A, D , A, E }
S B ,1 = { B, A , B, C , B, D , B, E }
SC ,1 = { C , A , C , B }
S D ,1 = { D, A , D, B }
S E ,1 = { E , A , E , B }
S A, 2 = { A, C , A, E }
SC , 2 = { C , A , C , E }
S E ,2 = { E, C , E, A }
For this example, assume that T, t , Cu , Ca , and n, are used for all availability definitions.
Then using the definition in Section 6.9.8, AT , S A ,1 can be viewed as the availability of UNI A for
Class of Service 1 and this reflects the availability of the important point to point paths that UNI
A is a part of. Similarly, AT , SC , 2 can be viewed as the availability of UNI C for Class of Service 2.
Thus, the availability for each UNI for each Class of Service can be defined by selecting the
appropriate subset of UNI pairs.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 58
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Ethernet Services Attributes Phase 2
In this case an Availability Performance metric is defined for each Class of Service supported by
the EVC. Define the following subsets of UNI pairs:
S1 = { A, B , A, C , A, D , A, E , B, C , B, D , B, E }
S 2 = { A, C , A, E , C , E }
For this example, assume that T, t , Cu , Ca , and n, are used for both availability definitions.
Then using the definition in Section 6.9.8, AT ,S1 can be viewed as the availability of Class of
Service 1 on the EVC and AT ,S can be viewed as the availability of Class of Service 2 on the
2
EVC.
MEF 10.2 The Metro Ethernet Forum 2009. Any reproduction of this document, or any portion thereof, shall Page 59
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Technical Specification
MEF 13
November, 2005
MEF 13 The Metro Ethernet Forum 2005. Any reproduction of this document, or any portion thereof, shall
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Disclaimer
The information in this publication is freely available for reproduction and use by any recipient
and is believed to be accurate as of its publication date. Such information is subject to change
without notice and the Metro Ethernet Forum (MEF) is not responsible for any errors. The MEF
does not assume responsibility to update or correct any information in this publication. No re-
presentation or warranty, expressed or implied, is made by the MEF concerning the complete-
ness, accuracy, or applicability of any information contained herein and no liability of any kind
shall be assumed by the MEF as a result of reliance upon such information.
The information contained herein is intended to be used without modification by the recipient or
user of this document. The MEF is not responsible or liable for any modifications to this docu-
ment made by any other party.
The receipt or any use of this document or its contents does not in any way create, by implication
or otherwise:
(a) any express or implied license or right to or under any patent, copyright, trademark or trade
secret rights held or claimed by any MEF member company which are or may be associated
with the ideas, techniques, concepts or expressions contained herein; nor
(b) any warranty or representation that any MEF member companies will announce any prod-
uct(s) and/or service(s) related thereto, or if such announcements are made, that such an-
nounced product(s) and/or service(s) embody any or all of the ideas, technologies, or con-
cepts contained herein; nor
(c) any form of relationship between any MEF member companies and the recipient or user of
this document.
Implementation or use of specific Metro Ethernet standards or recommendations and MEF speci-
fications will be voluntary, and no company shall be obliged to implement them by virtue of par-
ticipation in the Metro Ethernet Forum. The MEF is a non-profit international organization acce-
lerating industry cooperation on Metro Ethernet technology. The MEF does not, expressly or
otherwise, endorse or promote any specific products or services.
MEF 13 The Metro Ethernet Forum 2005. Any reproduction of this document, or any portion thereof, shall
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
User Network Interface (UNI) Type 1 Implementation Agreement
Table of Contents
1. Abstract ................................................................................................................................ 1
2. Terminology......................................................................................................................... 1
3. Scope..................................................................................................................................... 2
3.1 Purpose .............................................................................................................................. 2
3.2 UNI Modes ........................................................................................................................ 2
3.2.1 Type 1 Manual Configuration .............................................................................................. 2
3.2.2 Type 2 Static Service Discovery .......................................................................................... 2
4. Compliance Levels .............................................................................................................. 2
MEF 13 The Metro Ethernet Forum 2005. Any reproduction of this document, or any portion thereof, shall Page i
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
User Network Interface (UNI) Type 1Implementation Agreement
1. Abstract
This document specifies an implementation agreement for MEF User to Network Interface (UNI)
Type 1. The main objective of this version is to specify the MEF UNI characteristics and opera-
tion in manual configuration mode. This allows existing Ethernet devices (switch, router,
workstation, etc) acting as CEs to be instantly compliant to this IA with no additional software or
hardware upgrades. The main functionality of this version is to allow data-plane Ethernet con-
nectivity between the UNI-C and UNI-N. This document references MEF UNI Requirements
and Framework [4] for all concepts, constructs and terminology. The UNI Type 1 mode pro-
vides bare minimum data-plane connectivity services with no control-plane or management-
plane capabilities..
2. Terminology
Term Definition
The user-priority bits of the IEEE 802.1Q Tag in a tagged Service Frame over
CE-VLAN CoS
UNI.
The identifier derivable from the content of a Service Frame that allows the
CE-VLAN ID
Service Frame to be associated with an EVC at the UNI.
CBS Committed Burst Size
CIR committed Information Rate
Ethernet Virtual Connection. An association of two or more UNIs that limits
EVC
the exchange of frames to UNIs in the Ethernet Virtual Connection
Frame Short for Ethernet frame.
Ingress The direction from the CE into the Service Provider network.
Layer 2 Control
A Service Frame that is used for Layer 2 control, e.g., Spanning Tree Proto-
Protocol Service
col.
Frame
Multicast Service
A Service Frame that has a multicast destination MAC address.
Frame
Multipoint EVC An EVC with two or more UNIs.
EBS Excess Burst Size
EIR Excess Information Rate
Point-to-Point
An EVC with exactly 2 UNIs.
EVC
An Ethernet frame transmitted across the UNI toward the Service Provider or
Service Frame
an Ethernet frame transmitted across the UNI toward the Subscriber.
Service Multip-
A UNI attribute in which the UNI can be in more than one EVC instance.
lexing
Service Provider The organization providing Ethernet Service(s).
Subscriber The organization purchasing and/or using Ethernet Services.
User Network Interface. The physical demarcation point between the respon-
UNI
sibility of the Service Provider and the responsibility of the Subscriber
Unicast Service
A Service Frame that has a unicast destination MAC address.
Frame
MEF 13 The Metro Ethernet Forum 2005. Any reproduction of this document, or any portion thereof, shall Page 1
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
User Network Interface (UNI) Type 1Implementation Agreement
3. Scope
3.1 Purpose
The purpose of this document is an Implementation Agreement for a manually configured Ether-
net UNI. This document is based on the MEF UNI Framework [4].
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.
4. Compliance Levels
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. All key words must be use upper case,
bold text
MEF 13 The Metro Ethernet Forum 2005. Any reproduction of this document, or any portion thereof, shall Page 2
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
User Network Interface (UNI) Type 1Implementation Agreement
5. Common Characteristics
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].
3. A Type 1 UNI-C MUST support transmission and reception of Untagged Ethernet frames
according to IEEE 802.3-2002 [1]. In addition it MAY support transmission and recep-
tion of Priority-tagged and/or VLAN Tagged service frames in compliance to 802.3-
2002.
4. A Type 1 UNI-N MUST support transmission and reception of Untagged, VLAN-tagged
and Priority-tagged Ethernet frames according to IEEE 802.3-2002 [1].
5. A Type 1 UNI-C MUST support transmission and reception of Ethernet frames that have
a minimum and maximum size as specified in IEEE 802.3-2002 [1].
6. A Type 1 UNI-N MUST support transmission and reception of Ethernet frames that have
a minimum and maximum size as specified in IEEE 802.3-2002 [1].
MEF 13 The Metro Ethernet Forum 2005. Any reproduction of this document, or any portion thereof, shall Page 3
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
User Network Interface (UNI) Type 1Implementation Agreement
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.
Note: This requirement is needed for temporary disconnection of customer service, without tear-
ing down the EVC.
10. A Type 1.1 UNI-N MUST be able to support per-UNI Ingress BW profiling based on [6].
11. A Type 1.1 UNI-C SHOULD be able to shape its traffic to the contracted BWP in order
to receive the contracted QoS commitments.
12. A Type 1.1 UNI-N MUST be able to support color-blind BW profiling in which
EIR=EBS=0 and CIR and CBS are non-zero.
13. A Type 1.1 UNI-N MUST allow configuration to modify CIR in the following granulari-
ties:
1Mbps steps up to 10Mpbs
5 Mbps steps beyond 10Mbps and up to 100Mbps
50 Mbps steps beyond 100Mpbs and up to 1Gbps
500 Mbps steps beyond 1Gbps
14. A Type 1.1 UNI-N SHOULD allow configuration to modify CIR in the following granu-
larities:
64 Kbps (DS0 rate) steps up to 1.422 Mbps (VC11 rate) or 1.932 Mbps (VC12 rate)
1.422 Mbps (VC11 rate) or 1.932 Mbps (VC12 rate) steps up to 50 Mbps
43.008 Mbps (VC3 rate) steps beyond 50 Mbps and up to 150 Mbps
133.12 Mbps (VC4 rate) steps beyond 150 Mbps
15. A Type 1.1 UNI-N MUST be able to at least support CBS values that are equal to or
greater than the 8xMTU = 8x1522 bytes =12176 bytes
MEF 13 The Metro Ethernet Forum 2005. Any reproduction of this document, or any portion thereof, shall Page 4
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
User Network Interface (UNI) Type 1Implementation Agreement
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
21. A Type 1.1 UNI-N MUST be able to support CE-VLAN CoS preservation.
22. A Type 1.1 UNI-N MUST be able to Tunnel Unicast, Multicast and Broadcast service
frames, except 802.3x PAUSE frames unconditionally.
MEF 13 The Metro Ethernet Forum 2005. Any reproduction of this document, or any portion thereof, shall Page 5
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
User Network Interface (UNI) Type 1Implementation Agreement
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].
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.
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].
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
29. A Type 1.2 UNI-N MUST be able to support per-UNI Ingress BW profiling [6].
30. A Type 1.2 UNI-N MUST be able support Per-EVC BW profiling [6].
MEF 13 The Metro Ethernet Forum 2005. Any reproduction of this document, or any portion thereof, shall Page 6
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
User Network Interface (UNI) Type 1Implementation Agreement
31. A Type 1.2 UNI-N SHOULD be able to support Per-CoS BW profiling [6].
Note1: Multiple models of BW profile may exist at a UNI Type 1.2. However, a UNI Type 1.2
is not required to apply more than one BW profile to each service frame.
Note 2: Best Effort service is also considered to need CIR and CBS, in which CIR=CBS=0.
32. A Type 1.2 UNI-C SHOULD be able to shape its traffic to the contracted BWP in order
to received the contracted QoS commitments
33. A Type 1.2 UNI-N MUST be able to support color-blind BW profiling to enforce CIR,
CBS, EIR and EBS.
34. A Type 1.2 UNI-N MUST allow configuration to modify CIR and EIR in the following
granularities:
1Mbps steps up to 10Mpbs
5 Mbps steps beyond 10Mbps and up to 100Mbps
50 Mbps steps beyond 100Mpbs and up to 1Gbps
500 Mbps steps beyond 1Gbps
35. A Type 1.2 UNI-N SHOULD allow configuration to modify CIR and EIR in the follow-
ing granularities:
64 Kbps (DS0 rate) steps up to 1.422 Mbps (VC11 rate) or 1.932 Mbps (VC12 rate)
1.422 Mbps (VC11 rate) or 1.932 Mbps (VC12 rate) steps up to 50 Mbps
43.008 Mbps (VC3 rate) steps beyond 50 Mbps and up to 150 Mbps
133.12 Mbps (VC4 rate) steps beyond 150 Mbps
36. A Type 1.2 UNI-N MUST be able to at least support CBS and EBS values that are equal
or greater than 8xMTU = 8x1522 bytes = 12176 bytes.
37. A Type 1.2 UNI-N SHOULD be able to discard the following L2 Control Protocols:
Spanning Tree Protocol (STP),
Rapid Spanning Tree Protocol (RSTP),
Multiple Spanning Tree Protocol (MSTP)
All LANs Bridge Management Group Block of Protocol
Generic Attribute Registration Protocol (GARP)
Link Aggregation Control Protocol (LACP)
Marker Protocol
Authentication (802.1x)
802.3x (PAUSE) frames
38. A type 1.2 UNI-N SHOULD not generate 802.3x (PAUSE) frames.
39. A Type 1.2 UNI-N SHOULD be configurable to peer the following L2 Control Protocols
Link Aggregation Control Protocol (LACP)
Marker Protocol
Authentication (802.1x)
MEF 13 The Metro Ethernet Forum 2005. Any reproduction of this document, or any portion thereof, shall Page 7
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
User Network Interface (UNI) Type 1Implementation Agreement
40. A Type 1.2 UNI-N MUST be able to support Point-to-point and Multipoint EVCs con-
currently.
42. A Type 1.2 UNI-N MUST be able to support CE-VLAN CoS preservation.
43. A Type 1.2 UNI-N MUST be able to Tunnel Multicast and Broadcast service frames that
are not listed in section 6.2.6 unconditionally.
44. A Type 1.2 UNI-N MUST be able to Tunnel all other Unicast service frames uncondi-
tionally
MEF 13 The Metro Ethernet Forum 2005. Any reproduction of this document, or any portion thereof, shall Page 8
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
User Network Interface (UNI) Type 1Implementation Agreement
7. References
Reference Reference Details
[1] IEEE 802.3 IEEE P 802.3 2002, Information technology Telecommunications
and information exchange between systems Local and metropolitan
area networks Specific requirements Part 3: Carrier sense multiple
access with collision detection (CSMA/CD) access method and physical
layer specifications, 8 March 2002. (Normative)
[2] IEEE 802.3ae IEEE 802.3ae-2002Information Technology - Local & Metropolitan
Area Networks - Part 3: Carrier Sense Multiple Access with Collision
Detection (CSMA/CD) Access Method and Physical Layer Specifica-
tions - Media Access Control Parameters, Physical Layers and Manage-
ment Parameters for 10 Gb/s Operation
[3]IEEE 802.1Q IEEE 802.1Q, 2003 Edition, IEEE Standards for Local and metropolitan
area networksVirtual Bridged Local Area Networks
[4]UNI-REQ-FRMK Metro Ethernet Forum, MEF 11, User Network Interface (UNI) Re-
quirements and Framework, November 2004
[5] MEF 6 Metro Ethernet Forum MEF 6, Ethernet Service Definition, June 2004.
[6] MEF 10 Metro Ethernet Forum MEF 10, Ethernet Services Attributes Phase 1,
November 2004.
MEF 13 The Metro Ethernet Forum 2005. Any reproduction of this document, or any portion thereof, shall Page 9
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Technical Specification
MEF 26.1
January 2012
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Disclaimer
The information in this publication is freely available for reproduction and use by any recipient
and is believed to be accurate as of its publication date. Such information is subject to change
without notice and the Metro Ethernet Forum (MEF) is not responsible for any errors. The MEF
does not assume responsibility to update or correct any information in this publication. No rep-
resentation or warranty, expressed or implied, is made by the MEF concerning the completeness,
accuracy, or applicability of any information contained herein and no liability of any kind shall
be assumed by the MEF as a result of reliance upon such information.
The information contained herein is intended to be used without modification by the recipient or
user of this document. The MEF is not responsible or liable for any modifications to this docu-
ment made by any other party.
The receipt or any use of this document or its contents does not in any way create, by implication
or otherwise:
a) any express or implied license or right to or under any patent, copyright, trademark or
trade secret rights held or claimed by any MEF member company which are or may
be associated with the ideas, techniques, concepts or expressions contained herein;
nor
b) any warranty or representation that any MEF member companies will announce any
product(s) and/or service(s) related thereto, or if such announcements are made, that
such announced product(s) and/or service(s) embody any or all of the ideas, tech-
nologies, or concepts contained herein; nor
c) any form of relationship between any MEF member companies and the recipient or
user of this document.
Implementation or use of specific Metro Ethernet standards or recommendations and MEF speci-
fications will be voluntary, and no company shall be obliged to implement them by virtue of par-
ticipation in the Metro Ethernet Forum. The MEF is a non-profit international organization ac-
celerating industry cooperation on Metro Ethernet technology. The MEF does not, expressly or
otherwise, endorse or promote any specific products or services.
(C) 2012. The Metro Ethernet Forum. All Rights Reserved.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
Table of Contents
1 Abstract ................................................................................................................................... 1
2 Terminology............................................................................................................................ 1
3 Scope....................................................................................................................................... 3
4 Key Concepts .......................................................................................................................... 4
4.1 Motivation and Service Model........................................................................................ 4
4.2 Design Goals................................................................................................................... 6
4.3 ENNI Reference Model .................................................................................................. 6
4.4 ENNI Frame.................................................................................................................... 7
4.5 Operator Virtual Connection........................................................................................... 7
4.6 Relationship between OVCs and EVC ........................................................................... 8
5 Compliance Levels.................................................................................................................. 9
6 Requirements for the ENNI .................................................................................................... 9
7 Operator Services Attributes................................................................................................. 10
7.1 ENNI Service Attributes ............................................................................................... 11
7.1.1 Operator ENNI Identifier...................................................................................... 12
7.1.2 Physical Layer....................................................................................................... 12
7.1.3 Frame Format........................................................................................................ 13
7.1.4 Number of Links ................................................................................................... 13
7.1.5 ENNI Resiliency Mechanisms.............................................................................. 14
7.1.6 ENNI Maximum Transmission Unit Size............................................................. 14
7.1.7 End Point Map ...................................................................................................... 15
7.1.7.1 Basic End Point Map ........................................................................................ 15
7.1.7.2 End Point Map Bundling .................................................................................. 17
7.1.8 Maximum Number of OVCs ................................................................................ 18
7.1.9 Maximum Number of OVC End Points per OVC ................................................ 18
7.2 OVC Service Attributes ................................................................................................ 18
7.2.1 OVC End Points.................................................................................................... 18
7.2.2 OVC End Point Roles and Forwarding Constraints ............................................. 18
7.2.3 Hairpin Switching ................................................................................................. 20
7.2.4 OVC Service Attributes ........................................................................................ 20
7.2.5 OVC Identifier ...................................................................................................... 22
7.2.6 OVC Type............................................................................................................. 22
7.2.7 OVC End Point List .............................................................................................. 23
7.2.8 Maximum Number of UNI OVC End Points ....................................................... 23
7.2.9 Maximum Number of ENNI OVC End Points ..................................................... 23
7.2.10 OVC Maximum Transmission Unit Size.............................................................. 23
7.2.11 CE-VLAN ID Preservation................................................................................... 24
7.2.12 CE-VLAN CoS Preservation ................................................................................ 27
7.2.13 S-VLAN ID Preservation...................................................................................... 27
7.2.14 S-VLAN CoS Preservation ................................................................................... 28
7.2.15 Color Forwarding.................................................................................................. 28
7.2.16 Service Level Specification .................................................................................. 29
7.2.16.1 One-way Frame Delay Performance for an OVC......................................... 31
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page i
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
List of Figures
Figure 1 Example of Multiple MEN Operators Supporting Ethernet Services ........................... 5
Figure 2 MEF external reference model ...................................................................................... 7
Figure 3 Examples of OVCs ........................................................................................................ 8
Figure 4 Example Relationship of OVCs to EVCs...................................................................... 9
Figure 5 Representation of ENNI-Ni ......................................................................................... 10
Figure 6 ENNI Ethernet Services Model ................................................................................... 11
Figure 7 End Point Map Example.............................................................................................. 15
Figure 8 Example of the two End Point Maps for a Given ENNI ............................................. 16
Figure 9 Inter-Frame Delay Variation Definition...................................................................... 36
Figure 10 Flowchart Definition of A i , j (t k ) ........................................................................... 42
Figure 11 Example of the Determination of A i , j (t k ) ............................................................ 43
Figure 12 Example of the Impact of a Maintenance Interval .................................................... 44
Figure 13 Hierarchy of Time Showing the Resiliency Attributes ............................................. 46
Figure 14 Determining and Counting Consecutive High Loss Intervals over T........................ 47
Figure 15 Example of Counting High Loss Intervals and Consecutive High Loss Intervals .... 48
Figure 16 Ingress Bandwidth Profile per OVC End Point......................................................... 55
Figure 17 The Bandwidth Profile Algorithm............................................................................. 62
Figure 18 Key to the Icons Used in the Examples..................................................................... 67
Figure 19 EVCs to the Hub Location ........................................................................................ 67
Figure 20 Details of the Operator Services Attributes for Example 1 ....................................... 68
Figure 21 EPLAN Connecting Four UNIs................................................................................. 69
Figure 22 Details of the Operator Services Attributes for Example 2 ....................................... 69
Figure 23 Example of Hairpin Switching .................................................................................. 71
Figure 24 Example of a Data Loop with Hairpin Switching ..................................................... 71
Figure 25 Details of the Operator Services Attributes for Example 3 ....................................... 72
Figure 26 Example of Using End Point Map Bundling............................................................. 73
Figure 27 CoS Identifiers for MEF 23.1 Conforming Operator MENs..................................... 74
Figure 28 CoS Identifiers for Square and Paper in Scenario Two............................................. 75
Figure 29 Subscriber View of the Rooted-Multipoint EVC ...................................................... 76
Figure 30 Rooted-Multipoint EVC using Trunk OVC End Points............................................ 76
Figure 31 Example End Point Maps .......................................................................................... 76
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page iii
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
List of Tables
Table 1 Acronyms and definitions............................................................................................... 3
Table 2 ENNI Service Attributes............................................................................................... 12
Table 3 ENNI Frame Formats.................................................................................................... 13
Table 4 Allowed Connectivity Between OVC End Point Roles................................................ 20
Table 5 OVC Service Attributes ................................................................................................ 22
Table 6 OVC CE-VLAN ID Preservation when All CE-VLAN IDs Map to the OVC at all of
the UNIs Associated by the OVC ......................................................................................... 25
Table 7 OVC CE-VLAN ID Preservation when not All CE-VLAN IDs Map to the OVC at all
of the UNIs Associated by the OVC..................................................................................... 26
Table 8 OVC CE-VLAN ID Preservation when none of the OVC End Points are at UNIs ..... 26
Table 9 OVC CE-VLAN CoS Preservation............................................................................... 27
Table 10 One-way Frame Delay Performance Parameters........................................................ 34
Table 11 Inter-Frame Delay Variation Parameters .................................................................... 38
Table 12 One-way Frame Loss Ratio Performance Parameters ................................................ 39
Table 13 Availability Performance Parameters for an OVC ..................................................... 45
Table 14 Resiliency Performance Parameters for an OVC ....................................................... 48
Table 15 MAC Addresses that Identify a Layer 2 Control Protocol ENNI Frame.................... 50
Table 16 Format Relationships for Tunneled L2CP Service and ENNI Frames ....................... 51
Table 17 OVC End Point per ENNI Service Attributes ............................................................ 52
Table 18 OVC per UNI Service Attributes................................................................................ 57
Table 19 ENNI Frame Disposition for Each Egress External Interface .................................... 64
Table 20 Abbreviations Used in the Examples.......................................................................... 66
Table 21 MEF 23.1 CoS Identifiers........................................................................................... 74
Table 22 CoS Identifiers for Scenario Two ............................................................................... 74
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page iv
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
1 Abstract
The Metro Ethernet Network Architecture Framework specifies a reference point that is the in-
terface between two Metro Ethernet Networks (MENs), where each Operator MEN is under the
control of a distinct administrative authority. This reference point is termed the External Network
Network Interface or ENNI.1 The ENNI is intended to support the extension of Ethernet services
across multiple Operator MENs. This Technical Specification specifies:
The requirements at the ENNI reference point as well as the interface functional-
ity in sufficient detail to ensure interoperability between two Operator MENs in-
cluding Link OAM.
The connectivity attributes UNI to UNI, UNI to ENNI, and ENNI to ENNI such
that multiple Operator MENs can be interconnected and the Ethernet services and
attributes in MEF 6.1 [9] and MEF 10.2 [5] can be realized.
2 Terminology
2
MEF 4 considers several types of External Interfaces. This document is limited to consideration of the UNI and
ENNI.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 2
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
Note that throughout this specification, UNI means a demarcation point and ENNI means a de-
marcation point. Functionality associated with an interface at the ENNI is denoted by ENNI-Ni.
3 Scope
This document is a revision of MEF 26 [16]. MEF 26 was the first phase of specifications for
interconnecting Operator MENs in order to support MEF Ethernet Services. MEF 26 includes:
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].
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].
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.
4 Key Concepts
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 4
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
UNI 2
ENNI
UNI 1
Operator B UNI 3
Operator A
ENNI
ENNI Operator D
Operator C
UNI 4
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:
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:
Operator Services Attributes: These requirements detail the connectivity attributes that are
supported by an Operator MEN. Such attributes can exist between UNIs as described in MEF
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 5
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
10.2 (Operator A in Figure 1), between ENNIs (Operators A and D in Figure 1), and between a
UNI and an ENNI (Operators A, B, and C in Figure 1). These attributes can be thought of as the
menu from which the Service Provider purchases, from each Operator, what is needed to instan-
tiate the UNI to UNI services purchased by the Subscriber.
It is highly desirable that the UNI to UNI service observed by the Subscriber, when multiple Op-
erator MENs are involved, be indistinguishable from the services that are obtained via a single
Operator MEN. However, practical considerations might prevent this.
MEF 10.2 specifies multiple UNI to UNI service attributes, e.g., EVC type, service multiplexing.
The Operator Service Attributes detailed in this document are intended to support most of these
attributes (see Section 3). Furthermore it is desirable that a given instance of an ENNI simultane-
ously supports all of the Operator Service Attributes but this capability is not mandated.
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.
An OVC can informally be thought of as an association of External Interfaces within the same
Operator MEN. This association constrains the delivery of frames in the sense that an egress
Service Frame or ENNI Frame mapped to a given OVC can only be the result of an ingress Ser-
vice Frame or ENNI Frame mapped to the given OVC.
In the case of an ENNI, an egress ENNI Frame with identical MAC and payload information can
result from an ingress ENNI Frame at the same interface. (This behavior is not allowed at a UNI
as specified in MEF 10.2 [5].) To describe this behavior, the OVC End Point is used which al-
lows multiple, mutually exclusive ways that an ENNI Frame can be mapped to a single OVC at
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 7
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
an ENNI. Section 7.2 defines the OVC as an association of OVC End Points. In turn each OVC
End Point is associated with either a UNI or an ENNI. For the scope of this document, at least
one OVC End Point associated by an OVC is at an ENNI.
Figure 3 shows an example of two OVCs. One OVC connects UNI A, UNI B, and the ENNI.
The other OVC connects UNI A and the ENNI but allows what is called Hairpin Switching (see
Section 7.2.3) via OVC Endpoints a and b at the ENNI.
UNI A Operator
d e MEN
f
UNI B
The formal definition and requirements that apply to OVCs are detailed in Section 7.2.
In this example, there is an EVC associating UNI Q and UNI S and it is constructed by concate-
nating OVC A2 in MEN A with OVC B2 in MEN B. The concatenation is achieved by properly
configuring the End Point Map attribute for ENNI AB in MEN A and the End Point Map attrib-
ute for ENNI AB in MEN B. (See Section 7.1.7 for the definitions and requirements for the End
Point Map.) These map attributes are configured such that an ENNI Frame at ENNI AB that is
mapped to OVC End Point x by MEN A is mapped to OVC End Point y by MEN B and vice
versa. An ingress Service Frame at UNI Q that is destined for UNI S will result in an egress
ENNI Frame at ENNI AB mapped to OVC End Point x in MEN A. When this frame is received
by MEN B as an ingress ENNI Frame, it will be mapped to OVC End Point y and then result in
an egress Service Frame at UNI S. The other EVCs in the example can be similarly instantiated
by configuring the End Point Maps as shown in the table. It is the responsibility of the Service
Provider responsible for an EVC to insure that the OVCs are correctly concatenated for the cor-
responding EVC.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 8
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
B3 B1
A1 A3 ENNI AB C1
A2
C4
B4
B2 ENNI BC
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.
ENNI-N1 ENNI-N2
ENNI
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.
UNI
UNI
Operator MEN
ENNI
ENNI
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:
OVC End Point per ENNI Service Attributes are presented in Section 7.3.
In the following sections, the term External Interface is used to denote either an ENNI or a
UNI.
The ENNI Service Attributes are summarized in Table 2 and described in detail in the following
sub-sections.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 11
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
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.
[R5] Each link in an ENNI MUST be one of the following physical layers in full du-
plex mode as defined in IEEE Std 802.3 2005[3]: 1000Base-SX, 1000Base-LX,
1000Base T, 10GBASE-SR, 10GBASE-LX4, 10GBASE-LR, 10GBASE-ER,
10GBASE-SW, 10GBASE-LW, 10GBASE-EW.
Note that the physical layer at one ENNI supported by the Operator MEN can be different than
the physical layer at another ENNI supported by the Operator MEN.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 12
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
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.]
[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.
An ENNI can be implemented with one or more physical links. This attribute specifies the num-
ber of such links. When there are two links, protection mechanisms are required, see Section 6.
Protection mechanisms for more than two links are beyond the scope of this specification.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 13
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
[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]
The ENNI Maximum Transmission Unit Size specifies the maximum length ENNI Frame in
bytes allowed at the ENNI.
[R14] The ENNI Maximum Transmission Unit Size MUST be at least 1526 bytes.
[D1] The ENNI Maximum Transmission Unit Size SHOULD be at least 2000 bytes.
[R15] When an ENNI Frame is larger than the MTU Size, the receiving Operator MEN
for this frame MUST discard it, and the operation of a Bandwidth Profile that ap-
plies to this is not defined.
The undefined operation of the Bandwidth Profile referred to in [R15] means that an ENNI
Frame discarded because it is larger than the OVC MTU Size can result in either a change or no
change in the state of the Bandwidth Profile algorithm.
The MTU is part of several attribute specifications. For example, UNI, ENNI, and OVC will
have MTU attributes. Please refer to Section 9 for global MTU requirements.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 14
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
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.
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.
[R16] For a given S-Tagged ENNI Frame, the End Point to which it is mapped MUST
be determined by the S-VLAN ID value in the S-Tag.
[R17] An S-VLAN ID value MUST be used in no more than one row of the map.
[R18] The End Point Type MUST be OVC End Point or VUNI End Point.3
As per the following requirement, an ingress S-Tagged ENNI Frame whose S-VLAN ID value is
not in the map is not to be forwarded by the receiving Operator MEN.
[R19] An ingress S-Tagged ENNI Frame that is not mapped to an existing End Point
MUST NOT be forwarded to an External Interface by the receiving Operator
MEN.
3
The definition of VUNI End Point and related requirements are in MEF 28 [20].
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 15
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
Note that [R19] does not preclude the receiving Operator MEN from acting as a peer for a L2CP
protocol carried in an S-Tagged ENNI Frame. For example, S-Tagged ENNI Frames could be
used for the ENNI Maintenance Entity Service OAM protocol.
In general the S-VLAN ID values in the End Point Map are local to an ENNI, e.g., OVC End
Points associated by the same OVC at different ENNIs within an Operator MEN may be identi-
fied by different S-VLAN ID values. In cases where it is desirable to constrain each OVC End
Point to be identified by the same S-VLAN ID value for a given OVC, the OVC is specified to
have S-VLAN ID Preservation with value yes (see Section 7.2.13).
[R20] An ENNI Frame without an S-Tag MUST NOT be mapped to an OVC End
Point.
[R20] does not necessarily mean that an untagged ENNI is to be discarded by the receiving Op-
erator MEN. For example, an untagged ENNI Frame carrying a Layer 2 Control Protocol might
be processed.
Note that at a given ENNI, each Operator MEN will have an End Point Map and these maps will
typically have differences. Figure 8 shows an example for two Operator MENs, A and B. In this
example, each Operator MEN is using a different scheme for identifying OVC End Points and
thus the maps differ in column 2. More examples of End Point Maps are in Section 10.
As described in Section 7.2.2, an OVC End Point always has one of three roles; Root, Leaf, or
Trunk. When an OVC End Point at an ENNI has the role of Trunk, two S-VLAN ID values map
to that OVC End Point in the End Point Map. One S-VLAN ID value identifies ENNI frames
that result from Service Frames that originated at a Root UNI, and the other S-VLAN ID value
identifies ENNI frames that result from Service Frames that originated at a Leaf UNI. (See Sec-
tion 6.1.2.2 of MEF 10.2 [5] for descriptions of Root UNI and Leaf UNI.) The Trunk Identifiers
attribute (see Section 7.3.2) specifies these S-VLAN ID values.
[R21] When the End Point Map contains an OVC End Point that has the OVC End Point
Role of Trunk, the End Point MAP MUST contain exactly one Root S-VLAN ID
value and one Leaf S-VLAN ID value that map to the OVC End Point.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 16
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
When multiple S-VLAN ID values map to a single OVC End Point in the End Point Map, and
the OVC associating that OVC End Point is not a Rooted-Multipoint OVC, the End Point Map is
said to have Bundling and the OVC is said to be Bundled. (See Section 7.2.6 for the definition of
Rooted-Multipoint OVC.) Note that these definitions are only relevant at an ENNI. When the
End Point Map has Bundling, any OVC (that is not a Rooted-Multipoint OVC) that associates an
OVC End Point for which the bundling applies has to have S-VLAN ID Preservation = Yes,
cannot have Hairpin Switching (see Section 7.2.2), and can only associate OVC End Points that
are at two ENNIs. The following requirements detail these properties.
[R22] A Bundled OVC MUST associate exactly two OVC End Points.
When there is Bundling, it is possible that frames originated by more than one Subscriber will be
carried by the OVC and thus there may be duplicate MAC addresses being used by multiple Sub-
scribers. To avoid the problems in the Operator MEN that can result from this duplication, MAC
Address learning can be disabled on the OVC. However, disabling MAC Address learning can
lead to poor efficiency when the OVC associates OVC End Points at more than two ENNIs. This
is the motivation for [R22]. Future phases of this specification may relax [R22].
[R23] A Bundled OVC MUST have its S-VLAN ID Preservation attribute set to Yes.
(See Section 7.2.13.)
Note that [R23] and [R47] mean that a Bundled OVC can associate at most one OVC End Point
at an ENNI.
[R24] A Bundled OVC MUST have its CE-VLAN ID Preservation attribute set to Yes.
(See Section 7.2.11.)
[R25] A Bundled OVC MUST have its CE-VLAN CoS Preservation attribute set to
Yes. (See Section 7.2.12.)
[R26] Each OVC End Point associated by a Bundled OVC MUST be at an ENNI.
[R27] Each End Point Map at the ENNIs where there is an OVC End Point associated
by a Bundled OVC MUST map the same list of S-VLAN ID values to the OVC
End Point associated by the Bundled OVC.
As an example of [R27], consider the End Point Map shown in Figure 7. S-VLAN ID values 158
and 166 both map to the OVC End Point, Gotham Central Exchange_12-1224. If the OVC as-
sociating this OVC End Point also associates an OVC End Point at another ENNI, call it Me-
tropolis East Exchange_08-1328, then the End Point Map at this other ENNI must map exactly
158 and 166 to Metropolis East Exchange_08-1328.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 17
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
The Maximum Number of OVCs provides an upper bound on the number of OVCs that the Op-
erator will support at the ENNI.
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.
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].
An OVC End Point has one of three possible Roles; Root, Leaf, or Trunk.
[R31] The OVC End Point Role of an OVC End Point at a UNI MUST have the value
either Root or Leaf.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 18
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
[R32] The OVC End Point Role of an OVC End Point at an ENNI MUST have the
value Root, Trunk, or Leaf.
Note that the OVC End Role will always have the value Root when the associating OVC is not
of the type Rooted-Multipoint. See Section 7.2.6 for the definition of OVC Type.
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.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 19
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
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.
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.
The OVC Service Attributes are summarized in Table 5 and described in detail in the following
sub-sections.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 20
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
4
Note that if the "Maximum Number of UNI OVC End Points" plus the "Maximum Number ENNI OVC End
Points" is less than 2, then the OVC is not capable of conveying frames across the Operator MEN.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 21
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
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.
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.
An OVC that can only associate two or more Root OVC End Points is defined to have OVC
Type of Multipoint-to-Multipoint.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 22
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
An OVC that associates exactly two Root OVC End Points is defined to have OVC Type of
Point-to-Point, and can be considered a special case of the Multipoint-to-Multipoint OVC Type.
Note that a Multipoint-to-Multipoint OVC that associates two Root OVC End Points differs from
a Point-to-Point OVC in that additional Root OVC End Points can be added to the OVC.
An OVC that can associate at least one Leaf or Trunk OVC End Point is defined to have OVC
Type of Rooted-Multipoint. Note that an OVC that associates only Leaf OVC End Points is not
useful since it cannot forward frames between External Interfaces. See Section 7.2.2.
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.
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.
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.
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.
The OVC Maximum Transmission Unit Size specifies the maximum length frame in bytes al-
lowed on the OVC.
[R39] The OVC Maximum Transmission Unit Size MUST be at least 1526 bytes.
[D2] The OVC Maximum Transmission Unit Size SHOULD be at least 2000 bytes.
[R40] When an ENNI Frame or a Service Frame is larger than the OVC MTU Size for
the OVC associating the OVC End Point to which it is mapped, the receiving Op-
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 23
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
erator for this frame MUST discard it, and the operation of a Bandwidth Profile,
if any, that applies to this frame is not defined.
The undefined operation of the Bandwidth Profile referred to in [R40] means that frame dis-
carded because it is larger than the OVC MTU Size can result in either a change or no change in
the state of the Bandwidth Profile algorithm.
[R41] The OVC Maximum Transmission Unit Size MUST be less than or equal to the
MTU Size of each External Interface where an OVC End Point exists that is asso-
ciated by the OVC.
The MTU is part of several attribute specifications. For example, UNI, ENNI, and OVC will
have MTU attributes. Please refer to Section 9 for global MTU requirements.
CE-VLAN ID Preservation describes a relationship between the format and certain field values
of the frame at one External Interface and the format and certain field values of the correspond-
ing frame at another External Interface. This relationship allows the CE-VLAN ID value of the
UNI Service Frame to be derived from the ENNI Frame and vice versa. OVC CE-VLAN ID
Preservation is used to achieve EVC CE-VLAN ID Preservation that is a key property of the
EPL and EP-LAN Service Types specified in MEF 6.1 [9]. See Sections 10.3 and 10.4 for exam-
ples of its use.
[R42] When an OVC has the CE-VLAN ID Preservation attribute with a value of Yes
and all of the UNIs with an OVC End Point associated by the OVC are such that
all CE-VLAN IDs map to the OVC End Point (see Section 7.5.2), then the rela-
tionship between the format of the frame at the ingress External Interface and the
corresponding frame at the egress External Interface MUST be as specified in
Table 6.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 24
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
Ingress
Ingress Egress
Frame For- Egress Frame Format
Interface Interface
mat
UNI Untagged UNI Untagged
UNI Untagged ENNI S-Tag only
C-Tagged with VLAN ID value equal to that of in-
UNI C-Tagged UNI
gress Service Frame at the UNI
S-Tag and C-Tag with the VLAN ID value in the C-
UNI C-Tagged ENNI Tag equal to the VLAN ID value in the C-Tag at the
UNI
C-Tagged with the VLAN ID value of the C-Tag
S-Tag and C-
ENNI UNI equal to that of the VLAN ID value in the C-Tag of
Tag
the ingress frame at the ENNI
ENNI S-Tag only UNI Untagged
S-Tag and C-Tag with the VLAN ID value in the C-
S-Tag and C-
ENNI ENNI Tag equal to the VLAN ID value in the C-Tag at the
Tag
ingress ENNI.
ENNI S-Tag only ENNI S-Tag only
Table 6 OVC CE-VLAN ID Preservation when All CE-VLAN IDs
Map to the OVC at all of the UNIs Associated by the OVC
[R43] When an OVC has the CE-VLAN ID Preservation attribute with a value of Yes
and not all of the UNIs with an OVC End Point associated by the OVC are such
that all CE-VLAN IDs map to the OVC End Point (see Section 7.5.2), then the re-
lationships between the format of the frame at the ingress External Interface and
the corresponding frame at the egress External Interface MUST be as specified in
Table 7.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 25
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
Ingress Egress
Ingress Frame Format Egress Frame Format
Interface Interface
C-Tagged with VLAN ID C-Tagged with VLAN ID value equal to
UNI value in the range 1, , UNI that of the ingress Service Frame at the
4094 UNI
C-Tagged with VLAN ID S-Tag and C-Tag with the VLAN ID
UNI value in the range 1, , ENNI value in the C-Tag equal to the VLAN
4094 ID value in the C-Tag at the UNI
S-Tag and C-Tag with
Tagged with the VLAN ID value of the
VLAN ID value in the C-
ENNI UNI C-Tag equal to that of the C-Tag of the
Tag in the range 1, ,
ingress frame at the ENNI
4094
S-Tag and C-Tag with S-Tag and C-Tag with the VLAN ID
VLAN ID value in the C- value in the C-Tag equal to the VLAN
ENNI ENNI
Tag in the range 1, , ID value in the C-Tag at the ingress
4094 ENNI.
Table 7 OVC CE-VLAN ID Preservation when not All CE-VLAN IDs Map to the OVC at
all of the UNIs Associated by the OVC
[R44] When an OVC has the CE-VLAN ID Preservation attribute with a value of Yes
and none of the End Points associated by the OVC are at UNIs, then the relation-
ships between the format of the frame at the ingress ENNI and the corresponding
frame at the egress ENNI MUST be as specified in Table 8.
Ingress Frame
Egress Frame Format
Format
S and C-Tag with the VLAN ID value in the C-Tag equal to the VLAN ID
S-Tag and C-Tag
value in the C-Tag at the ingress ENNI.
S-Tag only S-Tag only
Table 8 OVC CE-VLAN ID Preservation when none of the OVC End Points are at UNIs
Note that when a Service Frame is delivered from a UNI in one Operator MEN to a UNI in an-
other Operator MEN via an EVC supported by two or more OVCs with all OVCs having CE-
VLAN ID Preservation attribute = Yes, then the Service Frame will have CE-VLAN ID Preser-
vation as defined in Section 6.6.1 in MEF 10.2 [5]. Thus, the EVC that associates these two
UNIs will have the CE-VLAN ID Preservation Service Attribute = Yes as defined in Section
6.6.1 in [5]. Also note that CE_VLAN ID Preservation as defined in Section 6.6.1 in MEF 10.2
[5] only applies to tagged Service Frames when there is not All to One Bundling at the UNI and
thus Table 7 does not include the cases for untagged Service Frames at the UNI. See Table 2 and
Table 3 in Section 6.6.1 of MEF 10.2 [5]. Section 10 shows some examples of the use of CE-
VLAN ID Preservation in the construction of Ethernet Services.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 26
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
CE-VLAN CoS Preservation describes a relationship between the format and certain field values
of the frame at one External Interface and the format and certain field values of the correspond-
ing frame at another External Interface. This relationship allows the CE-VLAN CoS value of the
UNI Service Frame to be derived from the ENNI Frame and vice versa. OVC CE-VLAN CoS
Preservation is used to achieve EVC CE-VLAN CoS Preservation that is a key property of the
EPL and EP-LAN Service Types specified in MEF 6.1 [9] See Sections 10.3 and 10.4 for exam-
ples of its use.
[R45] When an OVC has the CE-VLAN CoS Preservation attribute with a value of Yes
the relationship between the format of the frame at the ingress External Interface
and the corresponding frame at the egress External Interface MUST be as speci-
fied in Table 9.
Ingress
Ingress Egress
Frame For- Egress Frame Format
Interface Interface
mat
C-Tagged with PCP value equal to that of ingress
UNI C-Tagged UNI
Service Frame
S-Tag and C-Tag with the PCP value in the C-Tag
UNI C-Tagged ENNI
equal to the PCP value in the C-Tag at the UNI
S-Tag and C- C-Tagged with the PCP value of the tag equal to that
ENNI UNI
Tag of the C-Tag of the ingress frame at the ENNI
S-Tag and C-Tag with the PCP value in the C-Tag
S-Tag and C-
ENNI ENNI equal to the PCP value in the C-Tag of the ingress
Tag
frame at the ingress ENNI
Table 9 OVC CE-VLAN CoS Preservation
Note that when a Service Frame is delivered from a UNI in one Operator MEN to a UNI in an-
other Operator MEN via two or more OVCs with CE-VLAN CoS Preservation, then the EVC
that associates these two UNIs will have the CE-VLAN CoS Preservation Service Attribute as
defined in Section 6.6.2 in [5].
[R46] When an OVC has the S-VLAN ID Preservation attribute with a value of Yes, an
egress ENNI Frame at an ENNI resulting from an ingress ENNI Frame at a differ-
ent ENNI MUST have an S-VLAN ID value identical to the S-VLAN ID value of
the ingress ENNI Frame.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 27
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
[R47] When an OVC has the S-VLAN ID Preservation attribute with a value of Yes, it
MUST associate at most one OVC End Point located at a given ENNI.
[R48] When an OVC has the S-VLAN ID Preservation attribute with a value of No, an
egress ENNI Frame mapped to an OVC End Point resulting from an ingress
ENNI Frame mapped to a different OVC End Point MUST have an S-VLAN ID
value that has a one-to-one association with the S-VLAN ID of the ingress service
frame.
Note that the S-VLAN ID Preservation attribute does not apply to frames exchanged between an
ENNI and a UNI.
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.
Color Forwarding describes the relationship between the color on an ingress frame into the Op-
erator Network and the color of the resulting egress ENNI Frame. When Color Forwarding is
Yes, the OVC cannot promote a frame from Yellow to Green. Promoting a frame from Yellow
to Green could have an undesired impact on the EVC performance. The newly promoted Green
frames are now competing with equal rights for resources as frames marked Green at the ingress
UNI. For this reason, this attribute is useful to prevent this behavior.
[R50] When the Color Forwarding attribute is Yes for an OVC, each egress ENNI
Frame mapped to an OVC End Point that is associated by the OVC MUST be
marked Yellow using one of the formats specified in Section 7.3.3 if the corre-
sponding ingress frame into the Operator MEN satisfied one or more of the fol-
lowing:
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 28
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
The corresponding ingress frame was a Service Frame that was declared
Yellow by an Ingress Bandwidth Profile and the Service Frame was mapped
to an OVC End Point at the UNI that is associated by the OVC,
The corresponding ingress frame was a Service Frame with a frame header
indicating Yellow as specified in MEF 23.1 [10] and the Service Frame was
mapped to an OVC End Point at the UNI that is associated by the OVC,
The corresponding ingress frame was an ENNI Frame that was declared
Yellow by an Ingress Bandwidth Profile and the ENNI Frame was mapped
to an OVC End Point at the ENNI that is associated by the OVC,
The corresponding ingress frame was an ENNI Frame with a frame header
indicating Yellow using one of the formats specified in Section 7.3.3 and the
ENNI Frame was mapped to an OVC End Point at the ENNI that is associ-
ated by the OVC.
[O2] When the Color Forwarding attribute is No, the Color marking of each egress
ENNI Frame mapped to an OVC End Point that is associated by the OVC MAY
be related to the Color of the corresponding ingress frame into the Operator Net-
work in any way.
Note that this attribute does not describe Color marking of an egress Service Frame at a UNI be-
cause a method for such marking is not specified in MEF 23.1 [10].
The OVC Related Performance Service Attributes specify the frame delivery performance be-
tween External Interfaces (EI). Eight performance metrics are detailed in this specification:
6. One-way Availability,
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 29
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
These are similar to the performance attributes for an EVC described in MEF 10.2 [5] and MEF
10.2.1[22] but more general because both the UNI and ENNI are covered in this document.
These Performance Service Attributes describe the performance experienced by the Service Pro-
vider who is the user of the OVC. Methods for the Operator and the Service Provider to monitor
the OVC performance to estimate this user experience are beyond the scope of this document.
An SLS can specify objectives for all or any subset of the OVC Performance Service Attributes.
[R51] If an SLS contains an objective for a given OVC Related Performance Service At-
tribute, then the SLS MUST specify the related parameters for that objective.
OVC Related Performance Service Attributes, with the exception of Availability5, apply to
Qualified Service Frames and Qualified ENNI Frames, called Qualified Frames.
[R52] An SLS MUST define Qualified Frames as follows for a given ordered pair of
OVC End Points <i,j>, a given time interval T, and a given Class of Service Iden-
tifier:
1. Each frame MUST ingress at the EI where OVC End Point i is located.
2. Each frame MUST map to OVC End Point i via the End Point Map. (See Section
7.1.7 for the descriptions of the End Point Map at the ENNI and Section 7.5.2 for
the description of the OVC End Point Map at the UNI.)
3. The first bit of each frame MUST arrive at the ingress EI within the time interval
T, and within a time interval t smaller than T that has been designated as part of
Available time (see Section 7.2.16.4),
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 a color identifier that indicates Green per the color indication
requirements of MEF 23[10].
5
Availability is used to define Qualified Frames via item 3 in the list.
6
When there is no color identifier, this bullet means that the Service Frame is treated as if it were declared Green.
An example is the use of the H Label as defined in MEF 23 [10] where a color identifier is not specified per Table 2
of [10] .
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 30
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
Recall that both OVC End Points in the ordered pair can be located at the same ENNI. See [O1]
and Section 7.2.3.
The assessment of all performance attributes needs to account for unexpected arrival phenomena,
such as frame duplication, or frames arriving in a different order from that observed on ingress,
and the presence of these phenomena alone do not necessarily exclude a frame from the set of
Qualified Frames. Details on how to monitor performance in the face of unexpected arrival phe-
nomena are beyond the scope of this document.
This section defines three performance attributes: the One-way Frame Delay Performance corre-
sponding to a percentile of the distribution, the One-way Mean Frame Delay, and the One-way
Frame Delay Range.
The One-way Frame delay for a frame that ingresses at EI1 and results in a frame that egresses at
EI2 is defined as the time elapsed from the reception of the first bit of the ingress frame at EI1
until the transmission of the last bit of the first corresponding egress frame at EI2. If the frame is
erroneously duplicated in the Operator MEN and multiple copies delivered to EI2, the delay is
based on the first such copy delivered.
Note that this definition of One-way Frame Delay for a frame is the one-way7 delay that includes
the delays encountered as a result of transmission across the ingress and egress EIs as well as
that introduced by the Operator MEN.
Note that when the path between two UNIs crosses one or more ENNIs, the UNI to UNI One-
way Frame Delay, as defined in MEF 10.2 does not equal the sum of the One-way Frame Delay
between each pair of EIs. This is because the sum will double count the time to transmit a frame
across each ENNI. To see this, note that the definition of delay, DO , between a UNI and an
ENNI on single Operator MEN can be expressed as DO = dU + d E + d M were d U is the time to
transmit the frame across the UNI, d E is the time to transmit the frame across the ENNI, and d M
is the queuing and transmission delay introduced by the Operator MEN. Now consider the case
where Operator MEN 1 and Operator MEN 2 are connected via an ENNI to affect an EVC be-
tween two UNIs, one on each Operator MEN. The delay between the UNIs is
dU 1 + d M 1 + d E + d M 2 + dU 2 . But
DO1 + DO 2 = dU 1 + d M 1 + dU 2 + d M 2 + 2d E dU 1 + d M 1 + d E + d M 2 + dU 2 .
Adding the two OVC delays overstates the UNI to UNI delay by d E .
7
One-way delay is difficult to measure and therefore one way delay may be approximated from two way measure-
ments. However these techniques are beyond the scope of this document.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 31
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
This effect will need to be taken into account when deriving the UNI to UNI delay performance
from the delay performance of each Operator MEN in the path of the frame. This derivation is
beyond the scope of this document.
[R53] For a given non-empty set of ordered pairs of OVC End Points, a time interval T,
and a given Class of Service Identifier, the SLS MUST define each Frame Delay
Performance metric as follows:
Let the OVC End Points associated by the OVC be numbered from 1 to m. And
let S be a non-empty subset of the ordered pairs of OVC End Points associated by
the OVC. That is S { i, j | i = 1,..., m, j = 1,..., m, i j}, S .
i, j
Let d Td represent the Pd -Percentile of one-way delay for all Qualified Frames
delivered to the egress EI where OVC End Point j is located resulting from an in-
gress frame at the EI where OVC End Point i is located. If there are no such
i, j
egress frames, then dTd = Undefined.
Then the One-way Frame Delay Performance metric MUST be defined as the
i, j i, j
maximum value of all of the defined values d Td for i, j S , unless all d Td
are Undefined in which case the performance is Undefined.
i, j i, j i, j i, j
Let dTR = dTr d min . dTr represents the Pr -Percentile of the one-way delay
for all Qualified Frames delivered to the egress EI where OVC End Point j is lo-
cated resulting from an ingress frame at the EI where OVC End Point i is located.
i, j
d min is the minimum of the one-way delays for all Qualified Frames delivered to
the EI where OVC End Point j is located resulting from an ingress frame at the EI
where OVC End Point i is located. If there are no such egress frames, then
i, j
dTR = Undefined.
Then the One-way Frame Delay Range Performance metric MUST be defined as
i, j
the maximum value of all of the defined values of dTR for i, j S , unless all
i, j
d TR are Undefined in which case the performance is Undefined.
i, j
Let T represent the arithmetic mean of one-way delay for all Qualified
Frames delivered to the EI where OVC End Point j is located resulting from an
ingress frame at the EI where OVC End Point i is located. If there are no such
i, j
egress frames, then T = Undefined.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 32
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
Then the One-way Mean Frame Delay Performance metric MUST be defined as
i, j
the maximum value of all of the defined values T for i, j S , unless all
T i , j are Undefined in which case the performance is Undefined.
To restate the Frame Delay definition mathematically, let the OVC End Points associated by the
i, j
OVC be numbered from 1 to m and let DT be the set of one-way Frame Delay values for all
Qualified Frames at the EI where OVC End Point j is located resulting from an ingress frame at
i, j i, j i, j i, j i, j
the EI where OVC End Point i is located. DT can be expressed as DT = d1 , d 2 ,..., d N i , j , { }
is the one-way Frame Delay of the kth frame. Define d Td
i, j i, j
where d k for Pd > 0 as
N
d
i, j min d | Pd
=
100 i , j
I d , dk (
i, j
) if N i, j
1
Td N i , j k =1
Undefined otherwise
1 if d d k
I (d , d k ) .
0 otherwise
i, j
d Td is the minimal delay during the time internal T that Pd percent of the frames do not ex-
ceed.
Then a One-way Frame Delay Performance metric for an OVC can be expressed as
{
max dTdi , j | i, j S and where N i , j > 0
dT , S = .
}
Undefined when all N i , j = 0 for all i, j S
The One-way Frame Delay attribute permits specification of multiple values for Pd , (P0, P1, P2,
) and corresponding objectives ( d , d , d
i, j i, j i, j
0 , ). 1 2
Another parameter is the objective for the difference between the delay Pr percentile delay and
i, j
d min = min d DT { i, j
} , expressed as
i, j
(d i , j d min
i, j
) if N i , j > 0
dTR = Tr
Undefined if N i , j = 0
where
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 33
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
N
d
i, j min d | Pr
=
100 i , j
(
I d , dk
i, j
) if N i, j
1
.
Tr N i , j k =1
Undefined otherwise
Then a One-way Frame Delay Range Performance metric for an OVC can be expressed as
dTR , S =
{
max dTRi , j | i, j S and where N i , j > 0
.
}
Undefined when all N i , j = 0 for all i, j S
i, j
Another One-way Frame Delay attribute is the arithmetic mean of DT , which can be expressed
as
1 N i, j i, j
T i , j
= N i , j k =1
( )
d k if N i , j > 0
Undefined if N =0
i, j
Then a One-way Mean Frame Delay Performance metric for an OVC can be expressed as
T , S =
{
max T i , j | i, j S and where N i , j > 0
.
}
Undefined when all N i , j = 0 for all i, j S
The parameters of a One-way Frame Delay Performance metric are given in Table 10.
Parameter Description
T The time interval
S Non-empty subset of the ordered pairs of OVC End Points associated by the OVC
COS ID The Class of Service Identifier
Pd A specific percentile for the Frame Delay Performance, Pd > 0
Pr A specific percentile for the Frame Delay Range Performance, Pr > 0
d One-way Frame Delay Performance Objective corresponding to Pd
d R
One-way Frame Delay Range Objective corresponding to Pr
One-way Mean Frame Delay Performance Objective
Table 10 One-way Frame Delay Performance Parameters
[R54] Given T, S, COS ID, Pd , and a one-way Frame Delay Performance objective d ,
expressed in time units, an SLS MUST define the one-way Frame Delay Per-
formance objective as met over the time interval T for the subset S if and only if
dT , S d or d T , S is Undefined.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 34
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
[R55] Given T, S, COS ID, Pr , and a One-way Frame Delay Range Performance objec-
tive d , expressed in time units, an SLS MUST define the one-way Frame Delay
R
Range Performance objective as met over the time interval T for the subset S if
and only if dTR , S dR or dTR , S is Undefined.
[R56] Given T, S, COS ID, a One-way Mean Frame Delay Performance objective ,
expressed in time units, the Frame Delay Performance MUST be defined by an
SLS as met over the time interval T if and only if T , S or T , S is Undefined.
Recall that if any of the above performance attributes are Undefined for time interval T and or-
dered pair i, j , then the performance for that ordered pair is to be excluded from calculations
on the performance of pairs in S.
[O3] For a Point-to-Point OVC, S MAY include one or both of the ordered pairs of
OVC End Points associated by the OVC.
[O4] For a Multipoint-to-Multipoint OVC, S MAY be any non-empty subset of the or-
dered pairs of OVC End Points associated by the OVC.
Inter-Frame Delay Variation (IFDV) is the difference between the one-way delays of a pair of
selected frames. This definition is borrowed from RFC33938 where IP packet delay variation is
defined.
Let ai be the time of the arrival of the first bit of the ith frame at the ingress EI, then the two
frames i and j are selected according to the selection criterion:
{a j ai = and j > i}
Let ri be the time frame i is successfully received (last bit of the frame) at the egress EI, then the
difference in the delays encountered by frame i and frame j is given by d i d j . Define
d ij = d i d j = (ri ai ) (r j a j ) = (a j ai ) (rj ri )
8
C. Demichelis and P. Chimento, IP Packet Delay Variation Metric for IP Performance Metric (IPPM), RFC 3393,
November 2002.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 35
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
With d j being the delay of the jth frame, a positive value for d i d j implies that the two frames
are closer together at the egress EI while a negative value implies that the two frames are further
apart at the egress EI. If either or both frames are lost or not delivered due to, for example, FCS
violation, then the value d ij is not defined and does not contribute to the evaluation of the Inter-
Frame Delay Variation.
Figure 9 shows a depiction of the different times that are related to Inter-Frame Delay Variation
Performance.
i i+1 j j+1
ai aj
Ingress
Time
ri rj
Egress
di dj
[R58] For a given non-empty set of ordered pairs of OVC End Points, a time interval T,
and a given Class of Service Identifier, the SLS MUST define the Inter-Frame
Delay Variation Performance metric as follows:
Let the OVC End Points associated by the OVC be numbered from 1 to m. And
let S be a non-empty subset of the ordered pairs of OVC End Points associated by
the OVC. That is S { i, j | i = 1,..., m, j = 1,..., m, i j}, S .
~ i, j
Let d T be the Pv -percentile of the absolute value of the difference between
the Frame Delays of all Qualified Frame pairs whose difference in the arrival
times of the first bit of each frame in the pair at EI where the OVC End Point i is
located was exactly .
If there are no such pairs of frames for OVC End Point i and OVC End Point j,
~ i, j
then d T = Undefined .
Then the Inter-Frame Delay Variation Performance metric MUST be the maxi-
~ i, j ~ i, j
mum of the defined values d T for i, j S , unless all d T are Undefined
in which case the performance is Undefined.
This definition is in agreement with the IP packet delay variation definition given in RFC3393
where the delay variation is defined as the difference between the one-way delay of two packets
selected according to some selection function and are within a given interval [T1, T2].
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 36
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
The choice of the value for can be related to the application timing information. As an ex-
ample for voice applications where voice frames are generated at regular intervals, may be
chosen to be few multiples of the inter-frame time.
To restate the definition mathematically, let the OVC End Points associated by the OVC be
numbered from 1 to m. And let S be a non-empty subset of the ordered pairs of the OVC End
Points associated by the OVC. That is
Let
i, j i, j i, j i, j
VT = {d1 , d 2 ,..., d N i , j }
be the set of all absolute value of delay variations for all eligible pairs of Qualified Frames from
the EI where OVC End Point i is located to the EI where OVC End Point j is located where the
difference in the arrival times of the first bit of each Service Frame at the ingress EI was exactly
. Define
N
100 i , j
~ i, j
d T
min d | Pv
= I ( d , d k
i, j
) if N i , j 1
N i , j k =1
Undefined otherwise
1 if d d
I (d , d ) .
0 otherwise
Then an Inter-Frame Delay Variation Performance metric for an OVC can be expressed as
~
dT , S =
{
max d~T i , j | i, j S and where N i , j 1
.
}
Undefined when all N i , j = 0 for all i, j S
The parameters of an Inter-Frame Delay Variation performance metric are given in Table 11.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 37
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
Parameter Description
T The time interval
S Non-empty subset of the ordered pairs of OVC End Points associated by the OVC
COS ID The Class of Service Identifier
Pv Inter-Frame Delay Variation Performance percentile, Pv > 0
The separation between frame pairs for which Inter-Frame Delay Variation Per-
formance is defined
(
d Inter-Frame Delay Variation Performance Objective
Recall that if the Inter-Frame Delay Variation is Undefined for time interval T and ordered pair
i, j , then the performance for that ordered pair is excluded from calculations on the perform-
ance of pairs in S.
[O5] For a Point-to-Point OVC, S MAY include one or both of the ordered pairs of
OVC End Points associated by the OVC.
[O6] For a Multipoint-to-Multipoint OVC, S MAY be any non-empty subset of the or-
dered pairs of OVC End Points associated by the OVC.
[R61] For a given non-empty set of ordered pairs of OVC End Points, a time interval T,
and a given Class of Service Identifier, the SLS MUST define the One-way
Frame Loss Ratio Performance metric as follows:
Let the OVC End Points associated by the OVC be numbered from 1 to m. And
let S be a non-empty subset of the ordered pairs of OVC End Points associated by
the OVC. That is S { i, j | i = 1,..., m, j = 1,..., m, i j}, S .
i, j
Let I T denote the number of ingress Qualified Frames at the EI where OVC
End Point i is located that should have been delivered to the EI where OVC End
Point j is located according to the frame Delivery service attributes (see Sections
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 38
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
7.2.17, 7.2.18, and 7.2.19). Each frame can be a Unicast, Multicast, or Broadcast
frame.
i, j
Let ET be the number of unique (not duplicate) egress frames where each frame
is the first egress frame at the EI where OVC End Point j is located that results
i, j
from a frame counted in I T .
I Ti , j ETi , j
100 if I Ti , j 1
=
i, j
Define FLRT IT
i, j .
Undefined otherwise
Then the One-way Frame Loss Ratio Performance metric MUST be defined as
{
max FLRTi , j | i, j S and where I Ti , j 1
FLRT , S = .
}
i, j
Undefined when all I T = 0 for all i, j S
The parameters of a One-way Frame Loss Ratio Performance metric are given in Table 12.
Parameter Description
T The time interval
S Non-empty subset of the ordered pairs of OVC End Points associated by the OVC
COS ID The Class of Service Identifier
L One-way Frame Loss Ratio Performance objective
Table 12 One-way Frame Loss Ratio Performance Parameters
[R62] Given T, S, COS ID, and a One-way Frame Loss Ratio Performance objective, the
One-way Frame Loss Performance objective MUST be defined by an SLS as met
over the time interval T for the subset S if and only if FLRT , S L or FLRT , S is
Undefined.
Recall that if the One-way Frame Loss Ratio Performance is Undefined for time interval T and
ordered pair i, j , then the performance for that ordered pair is to be excluded from calculations
on the performance of pairs in S.
[O7] For a Point-to-Point OVC, S MAY include one or both of the ordered pairs of
OVC End Points associated by the OVC.
[O8] For a Multipoint-to-Multipoint OVC, S MAY be any non-empty subset of the or-
dered pairs of OVC End Points associated by the OVC.
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.
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:
The definition of A i , j (t k ) is based on the frame loss ratio function flr i , j (t k ) which is de-
fined as follows.
i, j
Let I t be the number of ingress frames that meet the following conditions:
The first bit of each frame arrives at the EI where OVC End Point i is located within
the time interval t ,
Each frame should be delivered to the EI where OVC End Point j is located according
to the frame delivery service attributes (see Sections 7.2.17, 7.2.18, and 7.2.19). Each
frame can be a Unicast, Multicast, or Broadcast frame,
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 40
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
Each frame that is subject to an ingress Bandwidth Profile has an Ingress Bandwidth
Profile compliance of Green, and
Each frame that is not subject to an ingress Bandwidth Profile either has no color
identifier or a color identifier that corresponds to Green per the color indication re-
quirements of MEF 23 [10]
i, j
Let Et be the number of unique (not duplicate) egress frames where each frame is the first,
unerrored egress frame at the EI where OVC End Point j is located that results from a frame
i, j
counted in I t .
I it, j Eit, j
if I it, j 1
Then flr i , j (t ) = I it, j
.
0 otherwise
I~ i , j E i , j ~ i, j
t if I t 1
(t ) = I~ti , j
t
flr i , j
0 otherwise
~ i, j i, j
where I t = I t the number of frames discarded by the Service Provider, in order to con-
form to either the line rate of the EI where OVC End Point j is located or an egress Bandwidth
Profile (if one is used) at the EI where OVC End Point j is located. Such frame drops may occur
anywhere in the network, not just near the egress EI. One example of this could be where an
egress Bandwidth Profile is applied on a link within the network. Another example of this could
be where Green frames for this OVC and Class of Service Identifier that should be delivered to
the EI with OVC End Point j exceed the line rate on a link within the network, provided the line
rate of that link is greater than or equal to the line rate of the EI. Good traffic engineering princi-
ples would suggest dropping such excessive frames as close to the ingress as possible. This ad-
justment is meant to account for a focused overload of traffic sent to the EI where OVC End
Point j is located. The details of such an adjustment are beyond the scope of this document.
t 0 is the first short time interval agreed by Service Provider and the Operator at or after turning
up the association of OVC End Point i and OVC End Point j. A i , j (t k ) is defined in Figure 10
for k = 0,1,2,... .
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 41
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
Begin
No A i , j ( tk 1 ) = 1 Yes
or k = 0
/ *Tran siti on to Avai labl e if /* Chec k ava ilab ili ty o f pre vio us in terval* / /* Tran sitio n t o Unavai lab le
n ext n in terval s have low if ne xt n in tervals h ave hig h
l oss*/ lo ss* /
No Ye s
A i , j ( tk ) = 1
A i, j (tk ) = 0
In the event of a conflict between the above equations and Figure 10, the content of Figure 10 is
controlling.
The availability for t k is based on the frame loss ratio during the short interval and each of the
following n 1 short intervals and the availability of the previous short time interval. In other
words, a sliding window of width nt is used to define availability. This use of a sliding win-
dow is similar to that of ITU-T Y.1563. [23]
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 42
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
Figure 11 presents an example of the determination of the availability for the small time intervals
with a sliding window of 10 small time intervals.
t 0
nt nt
1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 11 1 1 1 1 1 1 1
Time
A i , j ( tk ) = 1 A i, j (t k ) = 0 A i , j ( tk ) = 1
n = 10
flr i , j ( t m ) > C
flr i , j (t m ) C
The Availability for a particular Class of Service Identifier from OVC End Point i to OVC End
Point j for a time interval T is based on the percentage of small time intervals that are Available.
However, the small time intervals that occur during a Maintenance Interval are not included in
the calculation of this percentage. A Maintenance Interval is a time interval agreed to by the Ser-
vice Provider and Operator during which the service may not perform well or at all. Examples of
a Maintenance Interval include:
A time interval during which the Operator may disable the service for network main-
tenance such as equipment replacement,
A time interval during which the Service Provider and Operator may perform joint
fault isolation testing, and
A time interval during which the Operator may change service features and making
the changes may disrupt the service.
Figure 12 shows an example of the elimination of short time intervals for a Maintenance Interval.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 43
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
Time
A i , j (tk ) = 1 A i , j ( tk ) = 0 A i, j (t k ) = 1
n = 10
flr i, j (tm )> C
flr i , j (t m ) C
Let WT = {k | t k T and t k does not intersect a Maintenance Interval} and let WT represent the
number of elements in the set WT . Then the Availability for a particular Class of Service Identi-
fier from OVC End Point i to OVC End Point j for a time interval T, expressed as percentage, is
defined by
100
= WT k
i, j A i , j (t k ) if WT > 0
AT WT .
100 otherwise
Note that the definition of WT means that the boundaries of T and the boundaries of a Mainte-
nance Interval do not have to align with the boundary of a t k . A t k that straddles the bound-
ary between two Ts is excluded from the definition of Availability Performance for each interval
T. A t k that straddles the boundary of a Maintenance Interval is also excluded from the defini-
tion of Availability Performance.
Let the OVC End Points associated by the OVC be numbered 1,2,..., m and let S be a non-empty
subset of the ordered pairs of OVC End Points, i.e.,
Then the Availability for a particular Class of Service Identifier for the set S is defined by
ATS = min AT { i, j
| i, j S . }
The parameters of a One-Way Availability Performance Metric are given in Table 13.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 44
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
Parameter Description
T The time interval
S Non-empty subset of the ordered OVC End Point pairs
COS ID The Class of Service Identifier
t A time interval much smaller than T
C Unavailability frame loss ratio threshold
n Number of consecutive small time intervals for assessing availability
A Availability Performance Objective expressed as a percentage
Table 13 Availability Performance Parameters for an OVC
[R64] Given T, S, COS ID, t , C, n, and A , the SLS MUST define the Availability
Performance objective as being met if and only if ATS A .
[O9] For a Point-to-Point OVC, S MAY include one or both of the ordered pairs of
OVC End Points associated by the OVC.
[O10] For a Multipoint-to-Multipoint OVC, S MAY be any non-empty subset of the or-
dered pairs of OVC End Points associated the OVC.
This section defines attributes for the Resiliency performance of an ordered pair of OVC End
Points, <i,j>. The definitions depend on the availability status of each t to determine whether
performance counts toward objectives. The Resiliency attributes are similar to the definitions of
Severely Errored Seconds (SES) and Consecutive SES in Section 9 and Annex B (respectively)
of ITU-T Recommendation Y.1563 [23], when t = 1 second.
Figure 13 illustrates how the two resiliency attributes, counts of High Loss Intervals and counts
of Consecutive High Loss Intervals fit into the hierarchy of time and other attributes.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 45
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
SLS Interval, T
Maintenance Interval
Unavailable Time Available Time
Time
Non-High Loss
High Loss Intervals
Intervals
A High Loss Interval (HLI) is a small time interval (having the same duration as the interval, t ,
defined in Section 7.2.16.4) with a high frame loss ratio. When sufficient HLIs are adjacent, the
interval is designated a Consecutive High Loss Interval (CHLI). Section 7.2.16.4 defines termi-
nology for Availability. This section re-uses that terminology and defines the following terms:
H i, j
(t k ) : the high loss state of t k ,
i, j
LT : Count of High Loss Intervals over T
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 46
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
For every t in T that does not intersect a Maintenance Interval, the frame loss ratio and Avail-
ability state determine the value of H i , j (t k ) , either 1 or 0 as defined above.
[R66] For the SLS, the count of High Loss Intervals over T MUST be determined by
LT = H i , j (t ) .
i, j
tT
Note that the counter for H may be implemented in post processing (e.g., in a Management Sys-
tem), outside the Network Element that is monitoring the frame loss rate of each t . This could
be necessary to correlate with t s in a Maintenance Interval (MI).
When counting CHLI, the threshold p is used similarly to the variable n for the window size in
the Availability attribute, and p < n.
[R67] For the SLS, the Consecutive High Loss Intervals over T MUST be determined
according to the flow chart in Figure 14.
Begin
i, j
BT = 0 /*C oun ter = 0 at st art of T*/
k = min{in teger | tk T }
No
H i, j
( tm ) = 1, m = k p + 1,..., k /*p consecutive High Loss
intervals?*/
Yes
Yes
H i, j
(t ) = 1,
k p
/*Exist ing cons ecutive run?*/
No
i, j i, j
BT = BT +1 /*Increm ent counter*/
k = k +1
No Yes
End t k T
Figure 15 shows an example that depicts the HLI and CHLI counting processes.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 47
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
t0 nt nt
A i , j ( tk ) 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 11 1 1 1 1 1 1 1
H i, j
(t k ) 0 0 0 1 1 1 1 0 1 1 1 0 1 0 0 0 10 0 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 0 10 1 0 0 0 0 Time
i,j 0 0 0 1 2 1
3 4 4 5 6 7 7 8 8 8 8 1
8 8 8 8 8 8 8 8 8 8 8 1
8 8 8 8 8 8 8 8 88 8 1
8 9 9 9 9 9
LT
i, j
BT 0 0 0 0 0 1 1 1 1 1 2 2 2 2 2 2 1
2 2 2 2 2 2 2 2 2 2 2 1
2 2 2 2 2 2 2 2 22 2 1
2 2 2 2 2 2
n = 10, p = 3
flr i , j ( t m ) > C
f lr i , j ( tm ) C
Figure 15 Example of Counting High Loss Intervals and Consecutive High Loss Intervals
Let the OVC End Points associated by the OVC be numbered 1,2,..., m and let S be a non-empty
subset of the ordered pairs of OVC End Points, i.e.,
Then the HLI and CHLI performance attributes for a particular Class of Service Identifier for the
set S and time interval T are defined by
LTS = max LT { i, j
}
| i, j S and BTS = max BT { i, j
| i, j S . }
The parameters of the One-Way Resiliency Performance metrics are given in Table 14.
Parameter Description
T The time interval
S Non-empty subset of the ordered OVC End Point pairs associated by the OVC
COS ID The Class of Service Identifier
t A time interval much smaller than T
C Unavailability frame loss ratio threshold
p Number of consecutive small time intervals for assessing CHLI where p < n
L HLI Performance Objective expressed as an integer
B Consecutive HLI Performance Objective expressed as an integer
Table 14 Resiliency Performance Parameters for an OVC
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 48
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
[R70] Given T, S, COS ID, t , C, p, L , and B , the SLS MUST define the HLI Per-
formance objective as being met if and only if LST L , and the CHLI Perform-
ance objective as being met if and only if B S B . T
[O11] For a Point-to-Point OVC, S MAY include one or both of the ordered pairs of
OVC End Points associated by the OVC.
[O12] For a Multipoint-to-Multipoint OVC, S MAY be any non-empty subset of the or-
dered pairs of OVC End Points associated the OVC so long as it is non-empty.
This attribute describes how ingress frames mapped to an OVC End Point at an External Inter-
face with a unicast destination MAC address are delivered to the other OVC End Points associ-
ated by the OVC9.
[R72] When the Unicast Frame Delivery is unconditional, all properly formatted in-
gress frames mapped to an OVC End Point at an External Interface with a unicast
destination MAC address MUST be delivered to all of the other OVC End Points
associated by the OVC provided [R33],[R34], [R35], and [R36] are satisfied.
[R73] When the Unicast Frame Delivery is conditional, a properly formatted ingress
frame mapped to an OVC End Point at an External Interface with a unicast desti-
nation MAC address is delivered to all or a subset of all of the other OVC End
Points associated by the OVC depending on certain conditions being met. When
conditional is in force, the conditions for delivery MUST be specified and such
conditions MUST satisfy [R33],[R34], [R35], and [R36].
An example of such a condition is that the destination MAC address is known by the Operator
MEN to be at the OVC End Point.
This attribute describes how ingress frames mapped to an OVC End Point at an External Inter-
face with a multicast destination MAC address are delivered to the other OVC End Points asso-
ciated by the OVC.9
[R74] When the Multicast Frame Delivery is unconditional, all properly formatted in-
gress frames mapped to an OVC End Point at an External Interface with a multi-
9
Assuming normal operation, e.g., valid FCS, no network congestion, and assuming that the frames comply with the
Bandwidth Profile if any.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 49
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
cast destination MAC address MUST be delivered to all of the other End Points
associated by the OVC provided [R33],[R34], [R35], and [R36] are satisfied.
[R75] When the Multicast Frame Delivery is conditional, a properly formatted ingress
frame mapped to an OVC End Point at an External Interface with a multicast des-
tination MAC address is delivered to all or a subset of all of the other OVC End
Points associated by the OVC depending on certain conditions being met. When
conditional is in force, the conditions for delivery MUST be specified and such
conditions MUST satisfy [R33],[R34], [R35], and [R36].
This attribute describes how ingress frames mapped to an OVC End Point at an External Inter-
face with the broadcast destination MAC address are delivered to the other End Points associated
by the OVC.9
[R76] When the Broadcast Frame Delivery is unconditional, all properly formatted
ingress frames mapped to an OVC End Point at an External Interface with the
broadcast destination MAC address MUST be delivered to all of the other OVC
End Points associated by the OVC provided [R33],[R34], [R35], and [R36] are
satisfied.
[R77] When the Broadcast Frame Delivery is conditional, a properly formatted in-
gress frame mapped to an OVC End Point at an External Interface with the broad-
cast destination MAC address is delivered to all or a subset of all of the other
OVC End Points associated by the OVC depending on certain conditions being
met. When conditional is in force, the conditions for delivery MUST be speci-
fied and such conditions MUST satisfy [R33],[R34], [R35], and [R36].
The Layer 2 Control Protocol Service Frame is described in MEF 10.2. [5]. An ENNI Frame
with a Destination MAC Address shown in Table 15 is defined to be a Layer 2 Control Protocol
ENNI Frame. Additional ways of denoting a Layer 2 Control Protocol ENNI Frame at a given
ENNI can be agreed to by the two Operators involved in the given ENNI.
MAC Addresses10
01-80-C2-00-00-00 through 01-80-C2-00-00-0F
01-80-C2-00-00-20 through 01-80-C2-00-00-2F
01-80-C2-00-00-10
Table 15 MAC Addresses that Identify a Layer 2 Control Protocol ENNI Frame
[R78] When a L2CP Service Frame or L2CP ENNI Frame is tunneled, the frame MUST
be delivered to all OVC End Points, other than the ingress OVC End Point, that
10
Hexadecimal canonical format
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 50
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
are associated by the OVC and the format relationships detailed in Table 16
MUST be maintained.
Note that [R98] mandates that an ingress Service Frame that is not mapped to an existing OVC
End Point is not to be tunneled.
Note that [R19] mandates that an ingress ENNI Frame that is not mapped to an existing OVC
End Point is not to be tunneled. In view of [R20], this means that an ingress L2CP ENNI Frame
that does not have an S-Tag is not to be tunneled because the Operator has no information on
which OVC to use to tunnel the frame.
11
The Frame Check Sequence in the egress frame might need to be recalculated.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 51
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
Trunk Identifiers For a Trunk OVC End Point, specifies <Root S-VLAN ID value, Leaf
the S-VLAN ID values used on the S-VLAN ID value> for Trunk
ENNI to distinguish frames originating OVC End Points; Not Applica-
at a Root UNI and frames originating at ble to Root or Leaf OVC End
a Leaf UNI Points
Class of Service The way that a Class of Service is de- The OVC associating the End
Identifiers termined for an ENNI Frame at each Point and non-overlapping sets
ENNI of values of the S-Tag Priority
Code Point
Ingress Bandwidth Ingress policing by the Operator MEN No or parameters as defined in
Profile Per OVC on all ingress ENNI Frames mapped to Section 7.6.1
End Point the OVC End Point
Ingress Bandwidth Ingress policing by the Operator MEN No or parameters as defined in
Profile Per ENNI on all ingress ENNI Frames with the Section 7.6.1
Class of Service Class of Service Identifier for the re-
Identifier ceiving Operator MEN
Egress Bandwidth Egress policing by the Operator MEN No or parameters as defined in
Profile Per End on all egress ENNI Frames mapped to Section 7.6.1
Point the OVC End Point
Egress Bandwidth Egress policing by the Operator MEN No or parameters as defined in
Profile Per ENNI on all egress ENNI Frames with the Section 7.6.1
Class of Service Class of Service Identifier for the re-
Identifier ceiving MEN
Table 17 OVC End Point per ENNI Service Attributes
The OVC End Point Identifier is a string administered by the Operator that is used to identify an
OVC End Point within the Operator MEN. It is intended for management and control purposes.
The OVC End Point Identifier is not carried in any field in the ENNI Frame.
[R79] The OVC End Point Identifier MUST be unique among all such identifiers for
OVC End Points supported by the Operator MEN.
[R80] The OVC End Point Identifier MUST contain no more than 45 bytes.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 52
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
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.
The delivery performance for an ingress ENNI Frame is dependent on the particular Class of
Service Identifier that applies to it. A Class of Service Identifier is a set of one or more S-Tag
PCP values.12 Each Class of Service Identifier indicates a single Class of Service Name as de-
fined in MEF 23.1[10]. The Class of Service Name that applies to an ingress S-Tagged ENNI
Frame that is mapped to the OVC End Point is the Class of Service identified by the Class of
Service Identifier that contains the S-Tag PCP value in the frame.
For example, the S-Tag PCP values 0, 1, 2, and 3 could constitute a Class of Service Identifier
that indicates the silver service while the S-Tag PCP values 4, 5, 6, and 7 could constitute a dif-
ferent Class of Service Identifier that indicates the gold service. In this example, an S-Tagged
ENNI Frame with S-Tag PCP value = 3 would be given the silver service.
Note that when multiple S-VLAN ID values are mapped to the same OVC End Point as with End
Point Map Bundling (see Section 7.1.7.2), the CoS Identifier for each ingress S-Tagged ENNI
Frame mapped to the given OVC End Point is independent of the S-VLAN ID value in the ENNI
Frame.
In general, at a given ENNI, each OVC End Point can have a different Class of Service Identifi-
ers attribute but the following requirements apply.
[R83] For each OVC End Point at an ENNI, each possible S-Tag PCP value MUST be
included in exactly one Class of Service Identifier.
[R83] means that the sets of S-Tag PCP values for the Class of Service Identifiers are disjoint
and their union equals the set of all S-Tag PCP values.
[O13] One of the Class of Service Identifiers MAY indicate 100% discard.
12
MEF 28 [20] introduces additional Class of Service Identifiers at the ENNI..
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 53
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
[O13] means that the Operator MEN can discard all S-Tagged Frames whose S-Tag PCP value
belongs to one of the Class of Service Identifiers.
[R84] At a given ENNI, all OVC End Points associated by the same OVC MUST have
the same Class of Service Identifiers.
[R84] means that if an OVC associates multiple OVC End Points at an ENNI, the Class of Ser-
vice Identifier for an ENNI Frame at this ENNI is independent of the particular OVC End Point
to which it is mapped. Instead the Class of Service Identifier is based on the OVC and the S-Tag
PCP value.
[D3] An Operator MEN SHOULD support the use of different Class of Service Identi-
fiers attributes for OVC End Points at an ENNI that are associated by different
OVCs.
[D3] means that it is recommended that an Operator MEN be able to map a given S-Tag PCP
value to a different class of service for OVC End Points at an ENNI that are associated by differ-
ent OVCs.
Either the Drop Eligible Indicator (DEI) bit or the S-Tag PCP can be used to indicate the ENNI
Frame Color and the following requirements apply.
[R85] Color indication for each ENNI Frame MUST conform to requirements [R4] and
[R5] of MEF 23.1 [10].
[R86] If the S-Tag PCP field is used to indicate Color for the ENNI Frame, then the
Class of Service Identifiers MUST map S-Tag PCP values to L, M, and H as per
[R10] of MEF 23.1 [10].
[R87] If the DEI bit is used to indicate Color for the ENNI Frame, then the Class of Ser-
vice Identifiers MUST map S-Tag PCP values to L, M, and H as per [R10] of
MEF 23.1 [10].
An egress ENNI Frame does not specify a Class of Service Identifier for the Operator MEN from
which it is being transmitted. The S-Tag PCP value for an egress ENNI Frame only indicates the
Class of Service Identifier for the frame with respect to the Operator MEN that is receiving it.
Thus it is the responsibility of the transmitting Operator MEN to set the appropriate S-Tag PCP
value such that the frame is given the appropriate Class of Service by the receiving Operator
MEN. Section 10.8 presents an example of setting Class of Service Identifiers at an ENNI.
Note that MEF 23.1 [10] contains additional requirements on Classes of Service and S-Tag PCP
values.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 54
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
The Ingress Bandwidth Profile per OVC End Point describes ingress policing by the Operator
MEN on all ingress ENNI Frames mapped to a given OVC End Point.
[R88] When the Ingress Bandwidth Profile per OVC End Point is in force for a given
OVC End Point, suitable parameters <CIR, CBS, EIR, EBS, CF, CM> as defined
in Section 7.6.1 MUST be specified and the algorithm of Section 7.6.1 MUST be
applied to all ingress ENNI Frames that are mapped to the given OVC End Point.
[R89] The Color Mode for the Bandwidth Profile Algorithm MUST be color-aware.
Figure 16 illustrates an example of the application of Ingress Bandwidth Profiles per OVC End
Point. In this example, OVC End Point1 could have CIR=15 Mbps, OVC End Point2 could have
CIR = 10 Mbps, and OVC End Point3 could have CIR = 20 Mbps.
The Egress Bandwidth Profile per OVC End Point describes egress policing by the Operator on
all egress ENNI Frames that are mapped to a given OVC End Point.
[R90] When the Egress Bandwidth Profile per OVC End Point is in force for a given
OVC End Point, suitable parameters <CIR, CBS, EIR, EBS, CF, CM> as defined
in Section 7.6.1 MUST be specified and all egress ENNI Frames mapped to the
given OVC End Point MUST have the property defined in 7.6.3.
[R91] The Color Mode for the Bandwidth Profile Algorithm MUST be color-aware.
The Ingress Bandwidth Profile per Class of Service Identifier describes ingress policing by the
Operator MEN on all ingress ENNI Frames with a given Class of Service Identifier.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 55
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
[R92] When the Ingress Bandwidth Profile per Class of Service Identifier is in force for
a given ENNI Class of Service Identifier, suitable parameters <CIR, CBS, EIR,
EBS, CF, CM> as defined in Section 7.6.1 MUST be specified and the algorithm
of Section 7.6.1 MUST be applied to all ingress ENNI Frames mapped to the
OVC End Point that have the given ENNI Class of Service Identifier.
The Egress Bandwidth Profile per Class of Service Identifier describes egress policing by the
Operator MEN on all egress ENNI Frames with a given Class of Service Identifier.
[R94] When the Egress Bandwidth Profile per Class of Service Identifier is in force for a
given ENNI Class of Service Identifier, suitable parameters <CIR, CBS, EIR,
EBS, CF, CM> as defined in Section 7.6.1 MUST be specified and all egress
ENNI Frames mapped to the OVC End Point with the given Class of Service
Identifier MUST have the property defined in Section 7.6.3.
[R95] The Color Mode for the Bandwidth Profile Algorithm MUST be color-aware.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 56
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
OVC End Point Map The CE-VLAN ID(s) that map to A list of one or more CE-VLAN
the OVC End Point at the UNI ID values
Class of Service Identi- The way that a Class of Service Non-overlapping sets of values of
fiers is determined for a frame at each C-Tag Priority Code Point values
UNI or DSCP values as specified in
Section 7.5.3
Ingress Bandwidth Pro- Ingress policing by the Operator No or parameters as defined in
file Per OVC End Point MEN on all ingress Service Section 7.11.1 in MEF 10.2 [5]
at a UNI Frames mapped to the OVC End
Point
Ingress Bandwidth Pro- Ingress policing by the Operator No or parameters as defined in
file Per Class of Ser- on all ingress Service Frames Section 7.11.1 in MEF 10.2 [5]
vice Identifier at a UNI with a given Class of Service
Identifier
Egress Bandwidth Pro- Egress policing by the Operator No or parameters as defined in
file Per OVC End Point on all egress Service Frames Section 7.11.1 in MEF 10.2 [5]
at a UNI mapped to the OVC End Point
Egress Bandwidth Pro- Egress policing by the Operator No or parameters as defined in
file Per Class of Ser- on all egress Service Frames Section 7.11.1 in MEF 10.2 [5]
vice Identifier at a UNI with a given Class of Service
Identifier
Table 18 OVC per UNI Service Attributes
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.
A Service Frame is mapped to the OVC End Point via the CE-VLAN ID of the Service Frame as
defined in Section 7.6.1 of MEF 10.2. [5]
[R97] The OVC End Point at the UNI for a Service Frame MUST be identified by the
value of CE-VLAN ID of the Service Frame.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 57
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
[R98] An ingress Service Frame that is not mapped to an existing OVC End Point or
EVC at the UNI MUST be discarded.
[O14] Multiple CE-VLAN IDs MAY map to a single OVC End Point.
[R99] Each CE-VLAN ID MUST have one of the following mutually exclusive proper-
ties; 1) it maps to one OVC End Point, 2) it maps to one EVC that associates
UNIs within the Operator MEN, 3) it does not map to either such an EVC or an
OVC End Point.
Note that this document is describing the attributes as agreed to by the Service Provider and Op-
erator and therefore there is awareness of an OVC End Point at a UNI. MEF 10.2 [5] describes
attributes as agreed to by the Subscriber and Service Provider for which OVC End Points are in-
visible. From the Subscribers viewpoint, at a UNI, each CE-VLAN ID either maps to an EVC or
it does not map to an EVC.
[R100] When an OVC associating the OVC End Point to which the CE-VLAN ID for
untagged and priority tagged Service Frames is mapped does not have the CE-
VLAN ID Preservation attribute in force, egress Service Frames mapped to this
OVC End Point at the given UNI MUST be untagged.
[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].)
[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.
[R103] When the Class of Service Identifier is based on Priority Code Point field, the
Class of Service Identifier for an ingress Data Service Frame at the UNI MUST
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 58
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
be determined by the OVC End Point and non-overlapping sets of values of the
PCP field in the C-Tag.
[R104] When the Class of Service Identifier is based on Priority Code Point field, if the
ingress frame does not contain a C-Tag, it MUST have the same Class of Service
Identifier as an ingress frame with Priority Code Point field = 0 in the C-Tag.
[R105] When the Class of Service Identifier is based on Priority Code Point field, the un-
ion of the sets of PCP field values MUST contain all of the possible values.
As an example, consider OVC End Point 1 and OVC End Point 2 at a UNI. C-Tagged Data Ser-
vice Frames mapped to OVC End Point 1 with Priority Code Point values 4, 5, 6, and 7 have a
first Class of Service Identifier that indicates gold service. C-Tagged Data Service Frames
mapped to OVC End Point 1 with Priority Code Point values 0 and 3 have a second Class of
Service Identifier that indicates silver service. C-Tagged Data Service Frames mapped to OVC
End Point 1 with Priority Code Point values 1 and 2 have a third Class of Service Identifier that
indicates Service Frame discard. Data Service Frames without a C-Tag mapped to OVC End
Point 1 also have the second Class of Service Identifier that indicates silver service. C-Tagged
Data Service Frames mapped to OVC End Point 2 with Priority Code Point value 7 have a fourth
Class of Service Identifier that indicates platinum service. All other Data Service Frames mapped
to OVC End Point 2 have a fifth Class of Service Identifier that indicates gold service.
[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.
The Ingress Bandwidth Profile per OVC End Point at a UNI describes ingress policing by the
Operator MEN on all ingress Service Frames mapped to a given OVC End Point at a UNI.
[R109] When the Ingress Bandwidth Profile per OVC End Point at a UNI is in force for a
given OVC End Point, suitable parameters <CIR, CBS, EIR, EBS, CF, CM> as de-
fined in Section 7.11.1 of [5] MUST be specified and the algorithm of Section
7.11.1 of [5] MUST be applied to all ingress Service Frames that are mapped to
the given OVC End Point.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 59
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
Note that the algorithm and parameters defined in Section 7.6.1 are identical to the algorithm and
parameters defined in 7.11.1 of [5] with the exception of the value of the CM parameter. At the
ENNI, CM is mandated to be color-aware by requirements [R89], [R91], [R93], and [R95]
while color awareness is optional at the UNI.
The Ingress Bandwidth Profile per Class of Service Identifier at a UNI describes ingress policing
by the Operator MEN on all ingress Service Frames with a given Class of Service Identifier at a
UNI.
[R110] When the Ingress Bandwidth Profile per Class of Service Identifier at a UNI is in
force for a given Class of Service Identifier, suitable parameters <CIR, CBS, EIR,
EBS, CF, CM> as defined in Section 7.11.1 of [5] MUST be specified and the al-
gorithm of Section 7.11.1 of [5] MUST be applied to all ingress Service Frames
with the given Class of Service Identifier.
Note that the algorithm and parameters defined in Section 7.6.1 are identical to the algorithm and
parameters defined in 7.11.1 of [5] with the exception of the value of the CM parameter. At the
ENNI, CM is mandated to be color-aware by requirements [R89], [R91], [R93], and [R95]
while color awareness is optional at the UNI.
The Egress Bandwidth Profile per OVC End Point at a UNI describes egress policing by the Op-
erator MEN on all egress Service Frames mapped to a given OVC End Point at a UNI.
[R111] When the Egress Bandwidth Profile per OVC End Point at a UNI is in force for a
given OVC End Point, suitable parameters <CIR, CBS, EIR, EBS, CF, CM> as de-
fined in Section 7.11.1 of [5] MUST be specified and when the algorithm of Sec-
tion 7.11.1 of [5] using these parameters is applied to these egress Service
Frames, the result for each Service Frame MUST be to declare the Service Frame
either Green or Yellow.
Note that the algorithm and parameters defined in Section 7.6.1 are identical to the algorithm and
parameters defined in 7.11.1 of [5] with the exception of the value of the CM parameter. At the
ENNI, CM is mandated to be color-aware by requirements [R89], [R91], [R93], and [R95]
while color awareness is optional at the UNI.
The Egress Bandwidth Profile per Class of Service Identifier at a UNI describes egress policing
by the Operator MEN on all egress Service Frames with a given Class of Service Identifier at a
UNI.
[R112] When the Egress Bandwidth Profile per Class of Service Identifier at a UNI is in
force for a given Class of Service Identifier, suitable parameters <CIR, CBS, EIR,
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 60
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
EBS, CF, CM> as defined in Section 7.11.1 of [5] MUST be specified and when
the algorithm of Section 7.11.1 of [5] using these parameters is applied to these
egress Service Frames, the result for each Service Frame MUST be to declare the
Service Frame either Green or Yellow.
Note that the algorithm and parameters defined in Section 7.6.1 are identical to the algorithm and
parameters defined in 7.11.1 of [5] with the exception of the value of the CM parameter. At the
ENNI, CM is mandated to be color-aware by requirements [R89], [R91], [R93], and [R95]
while this is not mandated at the UNI.
Many of the Bandwidth Profiles in this Technical Specification are based on the parameters and
algorithm described in Section 7.6.1.
[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.
[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.
Each ENNI Frame is classified to determine which, if any, Bandwidth Profile is applicable to the
ENNI Frame. Operation of the Bandwidth Profile algorithm is governed by the six parameters,
<CIR, CBS, EIR, EBS, CF, CM>. The algorithm declares each ENNI Frame to be compliant or
non-compliant relative to the Bandwidth Profile. The level of compliance is expressed as one of
three colors, Green, Yellow, or Red.
The Bandwidth Profile algorithm is in color aware mode when each ENNI Frame already has a
level of compliance (i.e., a color) associated with it and that color is taken into account in deter-
mining the level of compliance by the Bandwidth Profile algorithm.
The Bandwidth Profile algorithm is shown in Figure 17. For this algorithm, Bc (t0 ) = CBS and
Be (t 0 ) = EBS . Bc (t ) and Be (t ) can be viewed as the number of bytes in the Committed and Ex-
cess token buckets respectively at a given time t.
Bc t j = minCBS, Bc t j1 + t j t j1
CIR
( ) ( ) ( )
8
CIR
( ) ( )
O t j = max0, B c t j 1 + ( )
t j t j1 CBS
8
( ) ( ) EIR ( ) ( )
Be t j = minEBS, Be t j1 + t j t j 1 + CF O t j
8
No
No
The Coupling Flag CF is set to either 0 or 1. The choice of the value for CF has the effect of con-
trolling the volume of the ENNI Frames that are declared Yellow. When CF is set to 0, the long
term average bit rate of ENNI Frames that are declared Yellow is bounded by EIR. When CF is
set to 1, the long term average bit rate of ENNI Frames that are declared Yellow is bounded by
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 62
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
CIR + EIR depending on volume of the offered ENNI Frames that are declared Green. In both
cases the burst size of the ENNI Frames that are declared Yellow is bounded by EBS.
The Ingress Bandwidth Profile is used to regulate the amount of ingress traffic at a particular
ENNI. An Ingress Bandwidth Profile is defined for ingress ENNI Frames at the particular ENNI.
In other words, the sequence {t j , l j }, j 0, to which the algorithm of Section 7.6.1 is applied is
based on ingress ENNI Frames at an ENNI. There are two Ingress Bandwidth Profile attributes
as described in Sections 7.3.4, and 7.3.6.
[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.
The disposition of a given ENNI Frame with respect to delivery to an egress External Interface is
dependent on the ENNI Frames level of compliance to the Ingress Bandwidth Profile that is ap-
plied to it. This is called the Ingress Bandwidth Profile compliance level and it has three possible
values: Green, Yellow, or Red. Table 19 defines how the Ingress Bandwidth Profile compliance
is related to the disposition of the ENNI Frame. In this table, Not Applied identifies the case
where no Ingress Bandwidth Profile was applied to the ENNI Frame in question.
[R119] The disposition of each ENNI Frame for delivery to each egress External Inter-
face MUST be as described in Table 19.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 63
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
Ingress Bandwidth
ENNI Frame Disposition
Profile Compliance
Red Discard
Deliver to the egress External Interface according to the Service Attrib-
Yellow utes of the OVC associating the OVC End Point to which the frame is
mapped but SLS performance objectives do not apply.
Green Deliver to the egress External Interface according to the Service Attrib-
utes of the OVC associating the OVC End Point to which the frame is
Not Applied mapped and SLS performance objectives apply.
Table 19 ENNI Frame Disposition for Each Egress External Interface
The behavior described in Table 19 is based on the arrival of the ENNI Frame at its ingress
ENNI. It does not mandate or constrain in any way the implementation within the Operator
MEN.
An Egress Bandwidth Profile is used to regulate the amount of egress traffic at a particular
ENNI. An Egress Bandwidth Profile is defined for a particular ENNI and applies to all or a sub-
set of all egress ENNI Frames at the ENNI in question.
The reference point for an Egress Bandwidth Profile is the ENNI. An Egress Bandwidth Profile
describes arrival times and lengths of ENNI Frames that will be observed at the ENNI when an
Egress Bandwidth Profile is in operation in the Operator MEN. This description is given in terms
of what would happen if an observer at the ENNI applied the algorithm of Section 7.6.1 to egress
ENNI Frames. This observer would see traffic after it had been subject to rate limiting and/or
shaping in the Operator network and thus would have certain characteristics.
[R120] When a sequence of egress ENNI Frames with arrival times and lengths at the
ENNI, {t j , l j }, j 0 are subjected to an Egress Bandwidth Profile with parameters
<CIR, CBS, EIR, EBS, CF, CM>, the result of applying the algorithm of Section
7.6.1 to these frames MUST be to declare each ENNI Frame either Green or Yel-
low.
The implication is that the regulation of the ENNI Frames in the Operator MEN is such that all
ENNI Frames that would be determined to be Red by the observer are discarded before reaching
the egress ENNI. It is important to reiterate that this description of Egress Bandwidth Profile
does not mandate or constrain in any way the implementation in the Operator network.
There are two Egress Bandwidth Profile attributes (one per OVC End Point and one per CoS
Identifier) as described in Sections 7.3.5 and 7.3.7.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 64
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
[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.
[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.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 65
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
The MTU is part of several attribute specifications. For example, the UNI (defined in [5]), the
EVC (defined in [5]), the ENNI (defined in 7.1.6), and the OVC (defined in 7.2.10) all have an
MTU attribute.
In order for an EVC to operate properly with respect to its MTU Size, the Service Provider has to
ensure that EVC MTU Size is less than or equal to the MTU Size of each OVC used to imple-
ment the EVC.
When provisioning a new ENNI or adding an EVC using an existing ENNI, the ENNI Operators
and the Service Provider for the new EVC need to agree on MTU sizes which comply with the
following requirements:
[D6] The ENNI MTU size SHOULD be greater or equal to the MTU size of :
Each EVC MTU size crossing the ENNI plus 4 bytes (to accommodate the
potential addition, at the ENNI, of an S-TAG), and
[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.
Abbreviation Object
C-VID C-VLAN ID value
S-VID S-VLAN ID value
OEP OVC End Point Identifier value
Table 20 Abbreviations Used in the Examples
In addition, the figures accompanying the examples use the icons as shown in Figure 18.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 66
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
Operator MEN
1 Root OVC End Point
ENNI
UNI
OVC
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.
UNI 2
UNI 1
CE-VLAN ID EVC
EVC 1-3
45 EVC 1-2
765 EVC 1-3
37 EVC 1-4 UNI 3
EVC 1-4
CE-VLAN ID EVC
CE-VLAN ID EVC
33 EVC 1-4
Figure 20 shows Operator Services Attributes values that instantiate the EVPLs for this example
using four Operator MENs. The various ENNI End Point Maps are shown in the figure. To see
how this configuration works, consider a Service Frame that ingresses at UNI 1 and is destined
for UNI 4 via EVC 1-4. Such a Service Frame will have a CE-VLAN ID value = 37. Operator A
maps this frame to OVC End Point 11 and thus transmits a corresponding ENNI Frame with S-
VLAN ID value = 1024 across the ENNI with Operator D. Operator D maps this ENNI Frame to
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 67
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
OVC End Point 13 and thus transmits a corresponding ENNI Frame with S-VLAN ID value =
2022 across the ENNI with Operator C. Operator C maps this ENNI Frame to OVC End Point 15
and thus transmits a corresponding Service Frame with CE-VLAN ID value = 33 across UNI 4.
A similar sequence of events ensues for the other direction for EVC 1-4 and for the other EVCs
in this example.
S-VID O EP B
114 4 UNI 2
S-VID O EP 5
114 3
4
UNI 1
A 3
C-VID O EP
1 33 5
2 C-VID O EP
11 28 10
6
12 7 D C
UNI 3
13
C-VID O EP 9
8
45 1 10
765 2 14 15
37 11
S-VID O EP
1023 6
16 C-VID O EP
1024 12 UNI 4 33 16
S-VID O EP S-VID O EP S-VID O EP
1023 7 2023 8 2023 9
1024 13 2022 14 2022 15
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.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 68
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
UNI 2
UNI 1
CE-VLAN ID EVC
All EVC 1-2-3-4
UNI 3
CE-VLAN ID EVC
CE-VLAN ID EVC
All EVC 1-2-3-4
Figure 22 shows Operator Services Attributes values that instantiate the EPLAN for this example
using four Operator MENs. In order to support All to One Bundling, the OVC End Point Map at
each UNI maps all Service Frames to the OVC End Point, e.g., OVC End Point 5 at UNI 2. Each
OVC End Point Map at each ENNI maps to the OVC End Point with one S-VLAN ID value as
was the case with Example 1.
S-VID O EP B
114 4 UNI 2 Each OVC has CE-VLAN ID
Preservation and CE-CoS
S-VID O EP 5 Preservation in force.
114 3
A 4
UNI 1 3
C-VID O EP
1 All 5
C-VID O EP
All 10
6
7 D C
UNI 3
C-VID O EP
All 1 8 9 10
S-VID O EP
1023 6 16 C-VID O EP
UNI 4 All 16
S-VID O EP S-VID O EP S-VID O EP
1023 7 2023 8 2023 9
The OVC in the Operator MEN A has three OVC End Points as does the OVC in the Operator
MEN C. Consequently, if MAC address learning is done in the Operator MEN A, a unicast Ser-
vice Frame between UNI 1 and UNI 2 need not enter the Operator D and Operator C MENs.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 69
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
Similarly, if MAC address learning is done in Operator MEN C, a unicast Service Frame be-
tween UNI 3 and UNI 4 need not leave the Operator C MEN.
Each OVC has CE-VLAN ID Preservation and CE-CoS Preservation in force as specified in Sec-
tion 7.2.11 and Section 7.2.12. As an example to see how this works, consider an ingress Service
Frame at UNI 1 that has a C-Tag and is destined for UNI 4.
The resulting ENNI Frame at the ENNI between Operator MENs A and D will
have both an S-Tag (with S-VLAN ID value = 1023) and a C-Tag and that C-Tag
will have the same C-VLAN ID value and the same C-Tag PCP value as the
original C-Tag of the Service Frame.
The corresponding ENNI Frame at the ENNI between Operator MENs D and C
will have both an S-Tag (with S-VLAN ID value = 2023) and a C-Tag and that C-
Tag will have the same C-VLAN ID value and the same C-Tag PCP value as the
original C-Tag of the ENNI Frame at the ENNI between Operator MENs A and
D.
Finally, the corresponding egress Service Frame at UNI 4 will have just a C-Tag
and that C-Tag will have the same C-VLAN ID value and the same C-Tag PCP
value as the original C-Tag of the ENNI Frame at the ENNI between Operator
MENs C and D.
The result is that the C-VLAN ID values and C-Tag PCP values are the same for both ingress
and egress Service Frame. Using the tables in Section 7.2.11, it can be seen that an untagged in-
gress Service Frame results in an untagged egress Service Frame. (Note that MEF 10.2 [5] speci-
fies that CE-CoS Preservation does not apply to untagged Service Frames.) Consequently, the
EVC has CE-VLAN ID Preservation and CE-CoS Preservation in force.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 70
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
UNI Aa
A4
B
UNI B
A1 B1
A B3
A2 B2
A3
UNI Ab
S-VID O EP
S-VID O EP 2023 B1
2023 A1 1028 B2
1028 A2
Note that in this example, two OVCs are used in Operator MEN A to implement the single EVC.
A4
B
UNI B
A1 B1
A B3
A2 B2
A3
UNI Ab
S-VID O EP
S-VID O EP 2023 B1
2023 A1 1028 B2
1028 A2
Figure 25 shows Operator Services Attributes values that instantiate the EPLAN for this example
using four Operator MENs. As in the example of Section 10.3, the OVC End Point Map at each
UNI maps all Service Frames to the OVC End Point and each OVC has CE-VLAN ID Preserva-
tion and CE-CoS Preservation in force as specified in Section 7.2.11 and Section 7.2.12.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 71
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
S-VID O EP B
114 4 UNI 2 Each OVC has CE-VLAN ID
Preservation and CE-CoS
S-VID O EP 5 Preservation in force.
114 3
A 4
UNI 1 3
C-VID O EP
1 All 5
C-VID O EP
All 10
6
12 7 D C
UNI 3
13
C-VID O EP
All 1 8 9 10
14 15
S-VID O EP
1023 6
16 C-VID O EP
1024 12 UNI 4 All 16
S-VID O EP S-VID O EP S-VID O EP
1023 7 2023 8 2023 9
1024 13 2022 14 2022 15
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}.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 72
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
S-VID O EP B
114 4 UNI 2
C-VID O EP 9
45 1 8 10
765 2 15
37 11
S-VID O EP
1023 6 16 C-VID O EP
1024 12 UNI 4 33 16
S-VID O EP S-VID O EP S-VID O EP
1023 7 1023 8 1023 9
1024 7 1024 8 1024 15
Bundling Bundling
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 End Point Map in Operator MEN C is changed to map each S-VLAN ID
value 1023 and 1024 to an OVC End Point.
In the first scenario, both Operator MENs abide by Table 4 in MEF 23.1 [10] which means that
they would use the CoS Identifiers shown in Table 21. In this case, H in Operator MEN A would
map to H in Operator MEN B and vice versa. In the same way, M would map to M and L would
map to L. The result is that ENNI Frames would have the CoS Identifiers shown in Figure 27
where the arrows indicate the direction of flow at the ENNI.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 73
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
A B
S-Tag
CoS in A PCP Value CoS in B
5
H 5 H
3
M 3 M
1
L 1 L
In the second scenario, suppose that the Operator MENs had CoS Names and CoS Identifiers as
shown in Table 22.
In this case, the mappings between the CoS instances in each Operator MEN will determine the
use of CoS Identifiers at the ENNI. To see this, suppose that Square and Paper are mapped to-
gether. Then the ENNI Frames for Square and Paper would have the CoS Identifiers shown in
Figure 28. Because the CoS Identifier is set according to the CoS of the receiving Operator
MEN, the CoS Identifier in the ENNI Frame is different and depends on the direction of the
frame flow.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 74
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
A B
S-Tag
CoS in A PCP Value CoS in B
3
Square 4 Paper
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.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 75
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
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.
MEN B MEN C
OVC End Point Root S-VLAN Leaf S-VLAN OVC End Point Root S-VLAN Leaf S-VLAN
Identifier ID value ID value Identifier ID value ID value
ChinaBasin B123 56 57 China Basin C19 56 57
MEN A. The Hairpin Switching has the effect of including the UNIs in Operator MEN B and
Operator MEN C in the Rooted-Multipoint EVC. Note that Operator B and Operator C see only
Point-to-Point OVCs with Root OVC End Points at the UNIs and ENNIs. However, the Sub-
scriber and Service Provider recognize the role of each UNI in Operator MEN B and Operator
MEN C as either a Root UNI or a Leaf UNI.
Root UNI S Leaf UNI W Root UNI T
MEN B MEN C
MEN A
Figure 33 Subscriber View of the Rooted-Multipoint EVC with all Root UNIs in one Op-
erator MEN
Figure 34 shows an example of supporting the Rooted-Multipoint EVC of Figure 33 using just
Root and Leaf OVC End Points. All Root UNIs are in the Operator MEN A, and the other Op-
erator MENs have only Leaf UNIs. At each ENNI, all ENNI Frames going left to right originated
at a Root UNI and all ENNI Frames going right to left originated at a Leaf UNI. This allows the
use of Root and Leaf OVC End Points at the ENNIs, and a single S-VLAN ID value at the EN-
NIs. For example at ENNI AB, MEN A maps this single S-VLAN ID value to its Leaf OVC End
Point while MEN B maps this same S-VLAN ID value to its Root OVC End Point.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 77
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
In this figure, MEN A has a Leaf OVC End Point at ENNI AB because any ingress ENNI Frame
mapped to this OVC End Point is the result of an ingress Service Frame at a Leaf UNI. For the
same reason, MEN B has a Leaf OVC End Point at ENNI BC. MEN B has a Root OVC End
Point at ENNI AB because any ingress ENNI Frame mapped to this OVC End Point is the result
of an ingress Service Frame at a Root UNI. For the same reason, MEN C has Root OVC End
Point at ENNI BC.
Root UNI S Leaf UNI W
Root UNI T
MEN A MEN B MEN C
ENNI AB ENNI BC
Figure 34 Rooted-Multipoint EVC with all Root UNIs in one Operator MEN
Figure 36 shows an example of supporting this Rooted-Multipoint EVC using Trunk OVC End
Points at the ENNIs in Operator MEN A and Operator MEN C. Operator MEN B uses a Point-
to-Point Bundled OVC in this example. At each ENNI, MEN B maps the two Trunk Identifiers
values to the OVC End Point. In this case, Operator MEN B need not be aware of which S-
VLAN ID value represents frames originated at a Root UNI and which S-VLAN ID value repre-
sents frame originated at a Leaf UNI. Instead, MEN B simply passes the S-VLAN ID values un-
changed between the two ENNIs as mandated by [R23]. MEN A and MEN C need to understand
the significance of each Trunk Identifiers value.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 78
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
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.
Figure 38 shows and example of supporting this Rooted-Multipoint EVC using Hairpin Switch-
ing among the Trunk OVC End Points in MEN A. The configuration of this example would be
useful if MEN B could only support Point-to-Point OVCs. The Hairpin Switching in MEN A
provides the connectivity between the UNIs in MEN C and MEN D that MEN B is unable to
provide.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 79
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
Root UNI T
MEN C
Leaf UNI Y
ENNI BC
Root UNI S
MEN B
MEN A
ENNI AB
MEN D
Leaf UNI X ENNI BD
Leaf UNI Z
Root UNI U
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.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 80
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
[7] Metro Ethernet Forum, MEF 11, User Network Interface (UNI) Requirements and
Framework, November 2004.
[8] Metro Ethernet Forum, MEF 20, User Network Interface (UNI) Type 2 Implemen-
tation Agreement, July 2008.
[9] Metro Ethernet Forum, MEF 6.1, Ethernet Services Definitions - Phase 2, April
2008.
[10] Metro Ethernet Forum, MEF 23.1, Carrier Ethernet Class of Service Phase 2,
January 2012.
[11] Metro Ethernet Forum, MEF 17, Metro Ethernet Forum, Service OAM Require-
ments & Framework Phase 1, April 2007.
[12] IEEE Std 802.1ag 2007, IEEE Standard for Local and metropolitan Area Net-
works Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault
Management, December 2007.
[13] Metro Ethernet Forum, MEF 2, Metro Ethernet Forum, Requirements and
Framework for Ethernet Service Protection in Metro Ethernet Networks, February
2004.
[14] K. Nichols, S. Blake, F. Baker, and D. Black, RFC2474, Definition of the Differ-
entiated Services Field (DS Field) in the IPv4 and IPv6 Headers, December 1998.
[15] IEEE Std 802.1ah 2008, IEEE Standard for Local and metropolitan Area Net-
works Virtual Bridged Local Area Networks Amendment 7: Provider Backbone
Bridges, August 2008.
[16] Metro Ethernet Forum, MEF 26, External Network Network Interface (ENNI)
Phase 1, January 2010.
[17] Metro Ethernet Forum, MEF 26.0.1, Corrected Figure 10 for MEF 26, July 2010.
[18] Metro Ethernet Forum, MEF 26.0.2, OVC Layer 2 Control Protocol Tunneling
Amendment to MEF 26, July 2011.
[19] Metro Ethernet Forum, MEF 26.0.3, Service Level Specification Amendment to
MEF 26, October 2011.
[20] Metro Ethernet Forum, MEF 28, External Network Network Interface (ENNI)
Support for UNI Tunnel Access and Virtual UNI, October 2010.
[21] IEEE Std 802.1Q 2011, IEEE Standard for Local and metropolitan area net-
works--Media Access Control (MAC) Bridges and Virtual Bridged Local Area
Networks, 2011.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 81
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface (ENNI) Phase 2
[22] Metro Ethernet Forum, MEF 10.2.1, Performance Attributes Amendment to MEF
10.2, January 2011.
MEF 26.1 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 82
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Technical Specification
MEF 20
User Network Interface (UNI) Type 2
Implementation Agreement
July, 2008
UNI Type 2 Implementation Agreement
Disclaimer
The information in this publication is freely available for reproduction and use by any recipient
and is believed to be accurate as of its publication date. Such information is subject to change
without notice and the MEF (Metro Ethernet Forum) is not responsible for any errors. The MEF
does not assume responsibility to update or correct any information in this publication. No
representation or warranty, expressed or implied, is made by the MEF concerning the
completeness, accuracy, or applicability of any information contained herein and no liability of
any kind shall be assumed by the MEF as a result of reliance upon such information.
The information contained herein is intended to be used without modification by the recipient or
user of this document. The MEF is not responsible or liable for any modifications to this
document made by any other party.
The receipt or any use of this document or its contents does not in any way create, by implication
or otherwise:
(a) any express or implied license or right to or under any patent, copyright, trademark or trade
secret rights held or claimed by any MEF member company which are or may be
associated with the ideas, techniques, concepts or expressions contained herein; nor
(b) any warranty or representation that any MEF member companies will announce any
product(s) and/or service(s) related thereto, or if such announcements are made, that such
announced product(s) and/or service(s) embody any or all of the ideas, technologies, or
concepts contained herein; nor
(c) any form of relationship between any MEF member companies and the recipient or user of
this document.
MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page ii
following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is
authorized to modify any of the information contained herein.
UNI Type 2 Implementation Agreement
Table of Contents
1. ABSTRACT .....................................................................................................................................................2
2. TERMINOLOGY ............................................................................................................................................2
3. SCOPE..............................................................................................................................................................3
3.1 Purpose .............................................................................................................................................................3
3.2 UNI Types.........................................................................................................................................................3
3.2.1 UNI Type 1 ................................................................................................................................................3
3.2.2 UNI Type 2 ................................................................................................................................................4
3.2.3 UNI Type 3 ................................................................................................................................................4
4. COMPLIANCE LEVELS...............................................................................................................................4
5. CONVENTION................................................................................................................................................4
6. BACKWARD COMPATIBILITY .................................................................................................................4
7. SUPPORTING UNI TYPE 2 FUNCTIONALITIES ....................................................................................5
7.1 Supporting UNI Type 2.1 ................................................................................................................................5
7.2 Supporting UNI Type 2.2 ................................................................................................................................5
7.3 Supporting Subsets of UNI Type 2 Functionalities.......................................................................................5
8. UNI TYPE 2 DISCOVERY & CONFIGURATION.....................................................................................6
9. SUPPORTING E-LMI ....................................................................................................................................7
10. SUPPORTING ETHERNET OAM ...............................................................................................................8
10.1 Link OAM ........................................................................................................................................................8
10.2 Service OAM ....................................................................................................................................................9
10.2.1 Maintenance Entity Requirements ...........................................................................................................10
10.2.2 MEP Requirements..................................................................................................................................11
10.2.3 Continuity Check Requirements ..............................................................................................................12
10.2.4 Loopback Requirements ..........................................................................................................................13
11. SUPPORTING PROTECTION ...................................................................................................................15
12. SUPPORTING ENHANCED UNI ATTRIBUTES ....................................................................................16
13. L2CP AND SERVICE OAM HANDLING .................................................................................................17
14. APPENDIX A (TEST-MEG DEFINITION) ...............................................................................................19
15. APPENDIX B (UP-MEP AND DOWN-MEP DEFINITION) ...................................................................20
REFERENCES ..........................................................................................................................................................21
MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 1
following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is
authorized to modify any of the information contained herein.
UNI Type 2 Implementation Agreement
1. Abstract
This document specifies an Implementation Agreement (IA) for MEF User to Network Interface
(UNI) Type 2. This Implementation Agreement adds new functionalities to MEF UNI Type 1
[MEF13], such as E-LMI based on [MEF16], Link OAM based on clause 57 of [IEEE 802.3],
Service OAM based on [ITU-T Y.1731] and [IEEE 802.1ag] and Protection using Link
Aggregation based on clause 43 of [IEEE 802.3].
2. Terminology
Term Definition
AIS Alarm Indication Signal
BW Bandwidth
CCM Connectivity Check Message
CE Customer Equipment
CFM Connectivity Fault Management
CoS Class of Service
CoS ID Class of Service Identifier
DA Destination Address
A MEP in an 802.1 Bridge that sends frames away from the Bridge Relay Entity; see
Down-MEP
[IEEE 802.1ag]
E-LAN MEF Multipoint to Multipoint service; see [MEF 10.1]
E-LINE MEF Point-to-Point service; see [MEF 10.1]
E-LMI Ethernet Local Management Interface [MEF16]
Ethernet Virtual Connection: an association between two or more UNIs for the purpose
EVC
of delivering Ethernet services.
EVC ID The Identifier for an EVC
IA Implementation Agreement
GARP Generic Attribute Registration protocol
LACP Link Aggregation Control Protocol
LAG Link Aggregation Group
LB Loop Back
LBM Loopback Message
LBR Loopback Reply
Link OAM OAM specific to a single link as per clause 57 of [IEEE 802.3]
L2CP Layer 2 Control Protocols
MD Maintenance Domain
ME Maintenance Entity
MEG Maintenance Entity Group
MEG-Level Maintenance Entity Group Level
MEP MEG End Point
MEP ID Maintenance Entity End Point Identification
MIP Maintenance Entity Intermediate Point
MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 2
following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is
authorized to modify any of the information contained herein.
UNI Type 2 Implementation Agreement
Term Definition
MTU Maximum Transfer Unit
NE Network Element
OAM Operation Administration and Management
PDU Protocol Data Unit
RDI Remote Defect Indication
Rooted-Multipoint 'MEF Point to Multipoint service; see [MEF 10.1]
Service OAM
Service OAM is OAM used to monitor an individual Service; see [ITU-T Y.1731]
and [IEEE 802.1ag]
Subscriber-MEG The MEG at Subscriber Level
Test-MEG The MEG used by Service provider to test the connectivity to UNI-C.
TLV Type, Length, Value
User Network Interface. The UNI is a demarcation point between the responsibility
UNI
of the Service Provider and the responsibility of the Subscriber.
UNI ID The Identifier for a UNI
UNI-C Part of the UNI that is located at Customer Equipment
UNI-MEG UNI Maintenance Entity Group
UNI-N Part of the UNI that is located at Service Provider Equipment
A MEP in an IEEE 802.1 Bridge that sends frames toward the Bridge Relay Entity; see
Up-MEP
[IEEE 802.1ag]
3. Scope
3.1 PURPOSE
This document is an Implementation Agreement that defines the requirements for UNI Type 2.
UNI Type 2 is an enhancement to UNI Type 1 as defined in [MEF13], with added
functionalities. The new functionalities include capability for UNI-C to retrieve EVC status and
configuration information including associated service attributes from UNI-N via E-LMI as per
[MEF16]; capability for customer and service provider to check and diagnose the UNI
connectivity via Link OAM as per clause 57 of [802.3] and Service OAM as per [ITU-T Y.1731]
and [IEEE 802.1ag], and capability to protect UNI against port failure via Link Aggregation as
per clause 43 of [IEEE 802.3].
MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 3
following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is
authorized to modify any of the information contained herein.
UNI Type 2 Implementation Agreement
The UNI Type 3 mode of operation allows the UNI-C to request, signal and negotiate EVCs and
its associated Service Attributes to the UNI-N. UNI Type 3 is out of the scope of this
Implementation Agreement and is for further study.
4. Compliance Levels
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in IETF RFC 2119. All key words must be use
upper case, bold text.
5. Convention
UNI Type 2 is divided to two categories called UNI Type 2.1 and UNI Type 2.2. Throughout this
document the term UNI Type 2 applies to both UNI Type 2.1 and 2.2.
6. Backward Compatibility
[R1] A UNI-N Type 2 MUST support all the mandatory requirements of UNI-N Type 1.1 and
UNI-N Type 1.2 as per [MEF13], except for the mandatory requirements in Section 5.1 of
[MEF 13].
Note: Section 5.1 of [MEF 13] contains UNI Type 1.1 and UNI Type 1.2 PHYs that are only a
subset of the UNI Type 2.1 and UNI Type 2.2 PHYs described in this specification under [R78].
[R2] A UNI-N Type 2 SHOULD support all the optional requirements of UNI-N Type 1.1 and
UNI-N Type 1.2 as per [MEF13]
[R3] A UNI-C Type 2 MUST support all the mandatory requirements of UNI-C Type 1.1 and
UNI-C Type 1.2 as per [MEF13], except for the mandatory requirements in Section 5.1 of
[MEF 13].
MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 4
following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is
authorized to modify any of the information contained herein.
UNI Type 2 Implementation Agreement
Note: Section 5.1 of [MEF 13] contains UNI Type 1.1 and UNI Type 1.2 PHYs that are only a
subset of the UNI Type 2.1 and UNI Type 2.2 PHYs described in this specification under [R78].
[R4] A UNI-C Type 2 SHOULD support all the optional requirements of UNI-C Type 1.1 and
UNI-C Type 1.2 as per [MEF13]
[R5] A UNI-N and UNI-C Type 2.1 MUST support the following functionalities:
[R6] A UNI-N and UNI-C Type 2.2 MUST support the following functionalities:
[R7] A UNI-N Type 2 MUST be able to interoperate with each of the functionalities listed in
section 7.1 and 7.2 that is fully implemented by the UNI-C as per this Implementation
Agreement.
MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 5
following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is
authorized to modify any of the information contained herein.
UNI Type 2 Implementation Agreement
Note: A UNI-N Type 2 is not required to interoperate with any UNI-C Type 2 functionality listed
in 7.1 and 7.2, which is not fully implemented by UNI-C. For example UNI-N is not required to
interoperate the E-LMI protocol with a UNI-C that implements only a subset of the mandatory
UNI-C aspects of the E-LMI functionalities.
[R8] A UNI-C Type 2 MUST be able to interoperate with each of the functionalities listed in
section 7.1 and 7.2 that is fully implemented by the UNI-N as per this Implementation
Agreement.
Note: A UNI-C Type 2 is not required to interoperate with any individual UNI-N Type 2
functionality listed in section 7.1 and 7.2, which is not fully implemented by UNI-N. For
example UNI-C is not required to interoperate the E-LMI protocol with a UNI-N that
implements only a subset of the mandatory UNI-N aspects of the E-LMI functionalities.
[R10] A UNI-C Type 2 that supports E-LMI, MUST use the procedures outlined in section
5.6.11.1 of [MEF16] to determine whether E-LMI is operational at UNI-N or not.
[R11] A UNI-N Type 2 that supports Link OAM MUST use the Link OAM Discovery process
as outlined in clause 57.3.2.1 of [IEEE 802.3] to determine the peer UNI-C support of Link
OAM.
[R12] A UNI-C Type 2 that supports Link OAM MUST use the Link OAM Discovery process
as outlined in clause 57.3.2.1 of [IEEE 802.3] to determine the UNI-N support of Link OAM.
[R13] A UNI-N Type 2 that supports Link Aggregation MUST use LACP as defined in clause
43.3 of [IEEE 802.3] to agree with UNI-C on a Link Aggregation group.
[R14] A UNI-C Type 2 that supports Link Aggregation MUST use LACP as defined in 43.3 of
[IEEE 802.3] to agree with UNI-N on a Link Aggregation group.
[R15] A UNI-N Type 2 MUST be administratively configurable with the UNI-C MEP ID and
the MEG-Level corresponding to the UNI-MEG.
[R16] A UNI-C Type 2 MUST be administratively configurable with the UNI-N MEP ID and
MEG-Level corresponding to the UNI-MEG.
[R17] A UNI-C Type 2 MUST be administratively configurable with the MEG-Level for the
Test-MEG.
MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 6
following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is
authorized to modify any of the information contained herein.
UNI Type 2 Implementation Agreement
9. Supporting E-LMI
E-LMI is the Ethernet Local Management Interface, based on [MEF 16]. E-LMI support is
mandatory for UNI Type 2.2 and optional for UNI Type 2.1. The detail requirements are listed in
this section.
[R18] A UNI-N Type 2.1 that supports E-LMI and a UNI-N Type 2.2 MUST support all
mandatory UNI-N aspects of E-LMI as specified in [MEF 16].
[R19] A UNI-N Type 2.1 that supports E-LMI and a UNI-N Type 2.2 SHOULD support all
optional UNI-N aspects of E-LMI as specified in [MEF 16].
[R20] A UNI-C Type 2.1 that supports E-LMI and a UNI-C Type 2.2 MUST support all
mandatory UNI-C aspects of E-LMI as specified in [MEF 16].
[R21] A UNI-C Type 2.1 that supports E-LMI and a UNI-C Type 2.2 SHOULD support all
optional UNI-C aspects of E-LMI as specified in [MEF 16].
[R22] A UNI-N Type 2.1 that supports E-LMI and a UNI-N Type 2.2 SHOULD allow the
configuration of the Minimum Asynchronous Message Interval [MEF16] in the range from
0.5 to 3 seconds with the default of 1 second.
Note: Minimum Asynchronous Message Interval is used to specify minimum time interval
between asynchronous messages. Generally this interval is set to 1/10th of the UNI-Cs T391
in seconds.
[R23] A UNI-N Type 2.1 that supports E-LMI and a UNI-N Type 2.2 SHOULD allow the
configuration of the N393 Status Counter Parameter Threshold [MEF16] in the range from 2
to 10, with the default of 4.
Note: The N393 Status Counter Parameter Threshold is used to determine if E-LMI is
operational or not. This configurable parameter is a Threshold for the Count of Consecutive
Errors.
[R24] A UNI-N Type 2.1 that supports E-LMI and a UNI-N Type 2.2 SHOULD allow the
configuration of the T392 Polling Verification Timer (PVT) limit [MEF16] in the range from
5 to 30, with the default of 15. A UNI-N Type 2 SHOULD allow disabling the Polling
Verification Timer.
MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 7
following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is
authorized to modify any of the information contained herein.
UNI Type 2 Implementation Agreement
Link OAM support is Mandatory for UNI Type 2.2 and is optional for UNI Type 2.1. The detail
requirements are listed in this section.
[R25] For each physical link in the UNI, a UNI-N Type 2.1 that supports Link OAM and a UNI
Type 2.2 MUST support Active DTE mode capabilities as specified in clause 57.2.9 of
[IEEE 802.3].
[R26] For each physical link in the UNI, a UNI-C Type 2.1 that supports Link OAM and a UNI
Type 2.2 MUST support Passive DTE mode capabilities as specified in clause 57.2.9 of
[IEEE 802.3].
[R27] For each physical link in the UNI, a UNI-C Type 2.1 that supports Link OAM and a UNI
Type 2.2 MAY support Active DTE mode capabilities as specified in clause 57.2.9 of [IEEE
802.3].
[R28] For each physical link in the UNI, a UNI-N Type 2.1 that supports Link OAM and a UNI
Type 2.2 SHOULD support unidirectional OAM operation as per clause 57.2.12 of [IEEE
802.3], when the UNI is one of the 100BASE-X, 1000BASE-X (excluding 1000BASE-PX-D
and 1000BASE-PX-U), 10GBASE-R, 10GBASE-W and 10GBASE-X physical layers as
specified in clause 66 of [IEEE 802.3].
[R29] For each physical link in the UNI, a UNI-C Type 2.1 that supports Link OAM and a UNI
Type 2.2 SHOULD support unidirectional OAM operation as per clause 57.2.12 of [IEEE
802.3], when the UNI is one of the 100BASE-X, 1000BASE-X (excluding 1000BASE-PX-D
and 1000BASE-PX-U), 10GBASE-R, 10GBASE-W and 10GBASE-X physical layers as
specified in clause 66 of [IEEE 802.3].
[R30] For each physical link in the UNI, a UNI-N Type 2.1 that supports Link OAM and a UNI
Type 2.2 MUST be able to turn off the 802.3x (PAUSE) frame generation to enable proper
Link OAM operation over the UNI as per clause 57.1.5.3 of [IEEE 802.3].
[R31] For each physical link in the UNI, a UNI-C Type 2.1 that supports Link OAM and a UNI
Type 2.2 MUST be able to turn off the 802.3x (PAUSE) frame generation to enable proper
Link OAM operation over the UNI as per clause 57.1.5.3 of [IEEE 802.3].
MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 8
following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is
authorized to modify any of the information contained herein.
UNI Type 2 Implementation Agreement
Service OAM support is Mandatory for UNI Type 2.1 and 2.2. The detail requirements are listed
in this section.
A Maintenance Entity (ME) is a point-to-point relationship between two MEPs within a single
MEG. Note that a MEG includes all unique pairs of MEPs (MEs) in a Maintenance Domain. In
a point-to-point EVC, there is just one ME, while in a multi-point EVC, there is more than one
MEs.
Service OAM occurs at different MEG-Levels (the MEG-level is specified within Service OAM
frames). The following MEGs are functionally equivalent, but are defined at different MEG-
Levels:
UNI-MEG. The UNI-MEG runs between the UNI-N and the UNI-C at one specific
UNI, and the MEG is always point-to-point. This ME monitors the connectivity between
the Service Provider and the Subscriber.
Test-MEG. The Test-MEG runs between two or more UNI-Cs and is defined such that
the Service Provider can (temporarily or permanently) insert a Test-MEP on an existing
UNI-C or another location on an EVC as a test point from which the Service Provider
can test connectivity all of the way to any other UNI-C in the EVC. This MEG is for
Service Provider or Network Operator testing. For more details and explanation of Test-
MEG please refer to Appendix A.
Subscriber-MEG. The Subscriber-MEG runs between two or more UNI-Cs and provides
Subscriber monitoring for an end-to-end service between subscriber endpoints.
These MEGs are illustrated by Figure 1. Each MEG is an association of two or more provisioned
maintenance points that require management. The maintenance points are shown as triangles in
Figure 1 and are referred to as MEG End Points (MEPs). A Test-MEG, for example, could
consist of two Test MEPs as shown in Figure 1, but would generally consist of at least three
MEPs (the third being the Service Providers Test MEP).
MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 9
following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is
authorized to modify any of the information contained herein.
UNI Type 2 Implementation Agreement
Subscriber Subscriber
Equipment Operator A NEs Service Provider Operator B NEs Equipment
1 2 3 4 5 6 7 8
Subscriber MEG
Test MEG
EVC ME
Operator A Operator B MEG
UNI MEG E-NNI ME UNI ME
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.
[R32] A UNI-C Type 2 MUST be able to support a MEP instance on the Subscriber-MEG for
each configured EVC. The OAM frames on the Subscriber-MEG SHOULD be tagged and
use the smallest CE-VLAN ID mapped into that EVC.
[R33] A UNI-C Type 2 SHOULD be able to support a MEP instance on the Test-MEG for each
configured EVC. The OAM frames on the Test-MEG SHOULD be tagged and use the
smallest CE-VLAN ID mapped into that EVC.
MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 10
following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is
authorized to modify any of the information contained herein.
UNI Type 2 Implementation Agreement
[R34] A UNI-C Type 2 MUST be able to support a single MEP instance on the UNI-MEG,
regardless of whether any EVC is configured for that UNI or not. This UNI-MEG is called
the default UNI-MEG and MUST use Untagged OAM frames.
[R35] When the CE is an IEEE 802.1 Bridge, the MEPs corresponding to UNI-MEG and Test-
MEG on a UNI-C Type 2 SHOULD be Down-MEPs.
[R36] When the CE is an IEEE 802.1 Bridge, the MEPs corresponding to Subscriber-MEG on a
UNI-C Type 2 MAY either be Up-MEP or Down-MEP.
[R37] A UNI-N Type 2 MUST be able to support a single MEP instance on the UNI-MEG,
regardless of whether any EVC is configured for that UNI or not. This UNI-MEG, called the
default UNI-MEG MUST use Untagged OAM frames.
[R38] When the Service Provider equipment is an IEEE 802.1 Bridge, the MEP corresponding
to UNI-MEG on UNI-N Type 2 SHOULD be a Down-MEP.
UNI-C
Default UNI-C MEPs Default UNI-N MEPs
MEPss
Up or Down MEP Per EVC Subscriber ME
Subscriber-MEPs
Down MEPs
Down UNI ME
UNI-MEP
[R39] A UNI-C and UNI-N Type 2 MUST support a configurable MEG-Level for the MEPs.
The default MEG-Level values for the various MEGs SHOULD be "1" for the UNI-MEG,
5 for the Test-MEG, and 6 for the Subscriber-MEG.
MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 11
following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is
authorized to modify any of the information contained herein.
UNI Type 2 Implementation Agreement
[R40] A UNI-C and UNI-N Type 2 MEP implementation MUST be able to process received
Multicast CCM frames for each required MEG.
[R41] A UNI-C and UNI-N Type 2 MEP implementation MUST be able to process and
respond to both Unicast and Multicast LBM frames for each required MEG.
[R42] When CCM transmission is enabled for a MEP in a UNI-C and/or UNI-N Type 2
implementation, the MEP MUST be able to generate Multicast CCM frames.
[R43] A UNI-C and UNI-N Type 2 MEP implementation MUST be able to generate Unicast
LBM frames, and MAY be able to generate Multicast LBM frames.
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.
[R47] A UNI-C and UNI-N Type 2 MUST support a configurable priority for transmitted CCM
frames for Test-MEG and subscriber-MEG. The default value SHOULD be the CoS ID
supported by the EVC, which yields the lowest frame loss performance. Untagged UNI-MEG
CCM frames SHOULD be transmitted with the highest priority supported by the UNI.
The MEF has defined EVC ID and UNI ID attributes that are unique across the MEN, but has
not defined a maximum length or format. Therefore a limited length identifier is needed for each.
This identifier is referred to as the Representative Value. The Representative Value for each
EVC ID must be no more than 45 ASCII characters and it must have a one to one relationship
with the EVC ID. The Representative Value for each UNI ID must be no more than 45 ASCII
characters and it must have a one to one relationship with the UNI ID.
MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 12
following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is
authorized to modify any of the information contained herein.
UNI Type 2 Implementation Agreement
[R48] The Maintenance Association Identifier (MAID) is used by the CC function, and is
required to be unique across MEGs at the same MEG-Level. The MAID has two
components consisting of the MD Name and the Short MA Name. The MD Name SHOULD
use the "null" format and the Short MA Name SHOULD use the "text" format, allowing for
a maximum length of 45 ASCII characters for the Short MA Name. The Short MA Name is
provisioned and SHOULD default to a the Representative Value that is uniquely related, but
not necessarily equal, to the EVC ID or UNI ID as following:
a. The Representative Value of the UNI ID for the default UNI-MEG (i.e., the default
UNI-MEG using untagged OAM frames)
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.
MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 13
following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is
authorized to modify any of the information contained herein.
UNI Type 2 Implementation Agreement
The following requirements apply to the implementation of the loopback (LB) function as an
operation that runs on-demand on a MEP for service troubleshooting. These requirements define
default protocol values and the protocol options that are required for UNI Type 2
implementations.
For the purposes of this section, a loopback (LB) session is defined as a sequence that begins
with management initiating the transmission of N periodic loopback frames from a local-MEP
to a remote-MEP in the same MEG. The session ends normally when the last loopback response
is received or incurs a timeout. The session may be aborted by management.
[R53] Each LB session MUST have the ability to be administratively initiated and stopped.
The following requirements define the parameters that must be provided when initiating a LB
session.
[R54] For each LB session, the destination address MUST be configurable to any Unicast MAC
DA. Multicast destinations MAY be supported using the reserved CCM multicast MAC DA
in the range of 01-80-C2-00-00-30 to 01-80-C2-00-00-37 that corresponds to the MEG-Level
of the MEP.
[R55] For each LB session, the priority of LBM frames MUST be configurable. The default
priority value SHOULD be the CoS ID supported by the EVC, which yields the lowest frame
loss performance.
[R56] For each LB session, the number of LBM transmissions MUST be configurable. The
default value SHOULD be 3.
[R57] For each LB session, the interval between LBM transmissions MUST be configurable.
The default value SHOULD be 1 second.
[R58] For each LB session, the timeout after a LBM transmission, for an expected LBR result
MAY be configurable. The default value SHOULD be 5 seconds.
[R59] For each LB session, the size of the LBM frame MUST be configurable. This requires
that the optional Data TLV MUST be supported to allow for frames up to the maximum
MTU size. The default LBM frame size SHOULD be 64 bytes.
[R60] For each LB session, the following information MUST be maintained: counters for LBM
frames transmitted, LBR frames received (i.e., requests and responses), the percentage of lost
LBM or LBR frames (i.e., unanswered requests), the minimum, maximum, and average
round-trip latency.
MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 14
following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is
authorized to modify any of the information contained herein.
UNI Type 2 Implementation Agreement
[R61] A UNI-N Type 2.1 that supports UNI protection and a UNI-N Type 2.2 MUST support
Link Aggregation as specified in clause 43 of [IEEE 802.3], for UNI protection.
[R62] A UNI-C Type 2.1 that supports UNI protection and a UNI-C Type 2.2 MUST support
Link Aggregation.
[R63] A UNI-N Type 2.1 that supports Link Aggregation and a UNI Type 2.2 MUST support at
least two (2) links in the Link Aggregation group (LAG).
[R64] A UNI-C Type 2.1 that supports Link Aggregation and a UNI-C Type 2.2 MUST support
at least two (2) links in the Link Aggregation group (LAG).
[R65] A UNI-N Type 2.1 that supports Link Aggregation and a UNI-N Type 2.2 SHOULD
support Link Aggregation across multiple line cards.
Note: A line card can be defined as a field replaceable sub-unit of a larger modular system that
supports ports serving service frames, designed to be replaced without affecting the operation of
other sub-units. This would include a conventional line card, but would exclude, for example,
a daughter card which could not be replaced without removing the carrier card it is on. The
above requirement intends to enhance the protection level of the Network Element implementing
the UNI-N. Note that some NE might not have multiple line-cards.
[R66] When Link Aggregation of exactly two (2) links is implemented across line cards, one of
the links MAY be set to Active while the other be set to Standby using LACP, as per clause
43.4 of [IEEE 802.3], to simplify the bandwidth profile enforcement.
Note: Link OAM or Link level Service OAM should be used for the Standby link. To ensure
availability of the Standby link in case of failure of the Active link,
[R67] A UNI-N and UNI-C Type 2.1 that support Link Aggregation and a UNI-N and UNI-C
Type 2.2 SHOULD support LACP as per [IEEE 802.3]. When LACP is not supported other
methods such as shutting down the PHY laser MAY be supported to signal LAG change.
[R68] A UNI-N Type 2.1 that supports Link Aggregation and LACP and a UNI-N Type 2.2 that
supports LACP MUST have its LACP_Activity set to Active mode, to prevent the scenario
when both UNI-C and UNI-N are passive waiting for each other to initiate the
communication
MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 15
following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is
authorized to modify any of the information contained herein.
UNI Type 2 Implementation Agreement
[R69] A UNI-C Type 2.1 that supports Link Aggregation and LACP and a UNI-C Type 2.2 that
supports LACP MUST have its LACP_Activity set to Passive mode as default.
[R70] A UNI-N Type 2 MUST be able to support Per-UNI egress BW profiling of CIR as
specified in [MEF10.1], in the following granularities:
1Mbps steps up to 10Mpbs
5 Mbps steps beyond 10Mbps and up to 100Mbps
50 Mbps steps beyond 100Mpbs and up to 1Gbps
500 Mbps steps beyond 1Gbps
[R71] A UNI-N Type 2 MUST be able to support Per-EVC egress BW profiling of CIR as
specified in [MEF10.1], in the following granularities:
1Mbps steps up to 10Mpbs
5 Mbps steps beyond 10Mbps and up to 100Mbps
50 Mbps steps beyond 100Mpbs and up to 1Gbps
500 Mbps steps beyond 1Gbps
[R72] A UNI-N Type 2 MUST be able to support Per-CoS ID egress BW profiling of CIR as
specified in [MEF10.1], in the following granularities:
1Mbps steps up to 10Mpbs
5 Mbps steps beyond 10Mbps and up to 100Mbps
50 Mbps steps beyond 100Mpbs and up to 1Gbps
500 Mbps steps beyond 1Gbps
[R73] A UNI-N Type 2 MUST support an MTU size of 1522 Bytes as per [IEEE 802.3] and
SHOULD support an MTU size of 2000 Bytes as per [IEEE 802.3as]. It MAY support 9600
byte jumbo frames.
[R74] A UNI-C Type 2 MUST support an MTU size of 1522 Bytes as per [IEEE 802.3] and
SHOULD support an MTU size of 2000 Bytes as per [IEEE 802.3as]. It MAY support 9600
byte jumbo frames.
[R76] A UNI-N Type 2 SHOULD be able to take on the role of a "root" or "leaf" for each
Rooted-Multipoint EVC it supports.
MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 16
following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is
authorized to modify any of the information contained herein.
UNI Type 2 Implementation Agreement
[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.
For a given L2 Control Protocol or OAM there are four possibilities for processing:
1. Pass to EVC
2. Not pass to EVC (Filter)
Pass to EVC means the L2CP or OAM frames could be either Tunneled or Discarded by the
EVC depending on the service type. Filter means the L2CP or OAM frames could be either
Peered or Discarded depending on the service type. The decision to whether Discard or Peer
or Tunnel any L2CP or OAM is Service type dependent and orthogonal to the decision to
Pass to EVC or Filter, and is outside of the scope of this Implementation Agreement.
MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 17
following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is
authorized to modify any of the information contained herein.
UNI Type 2 Implementation Agreement
Specific L2CP and OAM handling rules for each Service should be taken from the MEFs
Ethernet Service Definition Implementation Agreements such as MEF6.1.
[R81] A UNI-N Type 2 MUST Filter all L2CP packets with the following Multicast MAC
DA:
01-80-C2-00-00-02 to 01-80-C2-00-00-0A
01-80-C2-00-00-0D
01-80-C2-00-00-0E
[R82] A UNI-N Type 2 SHOULD Filter PAUSE frames with the following Multicast MAC
DA:
01-80-C2-00-00-01
[R83] A UNI-N Type 2 MUST have the capability to be configured to either Pass to EVC or
Filter all packets with the following Multicast MAC DA:
01-80-C2-00-00-00
01-80-C2-00-00-0B
01-80-C2-00-00-0C
01-80-C2-00-00-0F
01-80-C2-00-00-20 to 01-80-C2-00-00-2F
01-80-C2-00-00-30 to 01-80-C2-00-00-3F
Several protocols may use the same Multicast MAC DA, for example, multiple protocols use the
slow multicast protocol address 01-08-C2-00-00-02. For decision to Peer or Discard,
additional fields within the service frame may be uses such as Ethertype, Subtype, code, etc.
MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 18
following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is
authorized to modify any of the information contained herein.
UNI Type 2 Implementation Agreement
To accomplish this testing, the UNI-C is required to implement two subscriber level MEPs - one
for actual customer testing, and another one for carrier testing to customer equipment. The MEP
dedicated to carrier testing at the UNI-C is referred to as the UNI-C Test MEP, and the group of
MEs between these UNI-C Test MEPs is referred to as the Test-MEG (made up of one or more
Test MEs, as in the standard MEG/ME relationship).
By default, the CC function is disabled on the UNI-C Test MEP. In order to test connectivity
and performance to such UNI-C Test MEP, the carrier must have access to an equivalent MEP,
referred to as the Carrier Test MEP, from which to source the OAM frames. Where and how to
place and utilize a MEP for testing is at the carrier's discretion.
This specification simply requires that the UNI-C implement the responder functionality in the
UNI-C Test MEP so the carrier has the option to utilize it for test functions.
The Carrier Test MEP may be a permanent or temporary creation depending upon the needs of
the carrier. It may utilize an existing UNI-C to perform these tests, or the Carrier Test MEP may
be placed at another location. This specification does not define or limit the placement or utility
of a Carrier Test MEP.
It is important to realize that the Carrier Test MEP utilized must obey the rules and procedures of
the OAM protocols. This Carrier Test MEP behaves no differently than any other MEP. In
particular, the Carrier Test MEP must have access to the data plane that is being measured (for
example, the EVC), and the MEP must provide filtering based on the MEG-Level to form a
boundary of the domain. It is therefore recommended that the carrier should take care in the
placement of Carrier Test MEP because if placed improperly it may have unintended
consequences - such as providing a barrier to other OAM domains.
MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 19
following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is
authorized to modify any of the information contained herein.
UNI Type 2 Implementation Agreement
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.
UNI-C UNI-N
1 2
Subscriber ME
Up MEP Test ME
UNI ME
Down MEP
MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 20
following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is
authorized to modify any of the information contained herein.
UNI Type 2 Implementation Agreement
References
Reference Reference Details
MEF 11 Metro Ethernet Forum UNI Requirements and Frame work, Nov 2004
MEF 13 Metro Ethernet Forum, UNI Type 1, Nov 2005
MEF 16 Metro Ethernet Forum, Ethernet Local Management Interface (E-LMI), Jan 2006
IEEE 802.1ag IEEE Virtual Bridged Local Area Networks, Amendment 5:Connectivity Fault
Management, 2007
IEEE 802.3 IEEE, Carrier sense multiple access with collision detection (CSMA/CD) access method
and physical layer specifications, Dec 2005
IEEE 802.3as IEEE, IEEE, Carrier sense multiple access with collision detection (CSMA/CD) access
method and physical layer specifications Amendment: frame format extensions, 2006
MEF 10.1 Metro Ethernet Forum, Ethernet Service Attributes, Phase 2
ITU-T Y.1731 ITU-T, OAM Functions and Mechanisms for Ethernet based networks, 2006
MEF 20 The Metro Ethernet Forum 2008. Any reproduction of this document, or any portion thereof, shall contain the Page 21
following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is
authorized to modify any of the information contained herein.
MEF 8
October 2004
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall contain the
following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is
authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
Disclaimer
The information in this publication is freely available for reproduction and use by any recipient and is believed to be
accurate as of its publication date. Such information is subject to change without notice and the Metro Ethernet
Forum (MEF) is not responsible for any errors. The MEF does not assume responsibility to update or correct any
information in this publication. No representation or warranty, expressed or implied, is made by the MEF
concerning the completeness, accuracy, or applicability of any information contained herein and no liability of any
kind shall be assumed by the MEF as a result of reliance upon such information.
The information contained herein is intended to be used without modification by the recipient or user of this
document. The MEF is not responsible or liable for any modifications to this document made by any other party.
The receipt or any use of this document or its contents does not in any way create, by implication or otherwise:
(a) any express or implied license or right to or under any patent, copyright, trademark or trade secret rights held or
claimed by any MEF member company which are or may be associated with the ideas, techniques, concepts or
expressions contained herein; nor
(b) any warranty or representation that any MEF member companies will announce any product(s) and/or service(s)
related thereto, or if such announcements are made, that such announced product(s) and/or service(s) embody
any or all of the ideas, technologies, or concepts contained herein; nor
(c) any form of relationship between any MEF member companies and the recipient or user of this document.
Implementation or use of specific Metro Ethernet standards or recommendations and MEF specifications will be
voluntary, and no company shall be obliged to implement them by virtue of participation in the Metro Ethernet
Forum. The MEF is a non-profit international organization accelerating industry cooperation on Metro Ethernet
technology. The MEF does not, expressly or otherwise, endorse or promote any specific products or services.
The Metro Ethernet Forum 2004. All Rights Reserved.
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page i
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
Table of Contents
1. ABSTRACT .......................................................................................................................................................... 1
2. TERMINOLOGY .................................................................................................................................................. 1
3. SCOPE ................................................................................................................................................................... 3
4. COMPLIANCE LEVELS ..................................................................................................................................... 3
5. SERVICE DESCRIPTION .................................................................................................................................... 3
6. INTERWORKING FUNCTION ........................................................................................................................... 3
6.1 ARCHITECTURE .............................................................................................................................................. 3
6.1.1 Functional Layering .............................................................................................................................. 3
6.1.2 Direction terminology ............................................................................................................................ 4
6.1.3 Functional Components and Interfaces ................................................................................................. 4
6.1.4 TDM Service Processor (TSP) ............................................................................................................... 5
6.1.5 Circuit Emulation Inter-working Function (CES IWF) ......................................................................... 6
6.1.6 Emulated Circuit De/Multiplexing Function (ECDX) ........................................................................... 6
6.1.7 Ethernet Flow Termination Function (EFTF) ....................................................................................... 6
6.2 ENCAPSULATION ............................................................................................................................................ 7
6.2.1 Ethernet Services Layer ......................................................................................................................... 7
6.2.2 Adaptation Function Headers ................................................................................................................ 7
6.3 PAYLOAD FORMATS ...................................................................................................................................... 13
6.3.1 Structure-Agnostic Emulation.............................................................................................................. 13
6.3.2 Structure-Aware Emulation using Structure-Locked Encapsulation ................................................... 14
6.3.3 Structure-Aware Emulation using Structure-Indicated Encapsulation................................................ 15
6.4 SYNCHRONIZATION ...................................................................................................................................... 15
6.5 TDM APPLICATION SIGNALING.................................................................................................................... 17
6.5.1 CE Signaling Frames ........................................................................................................................... 17
6.5.2 Channel Associated Signaling (CAS) Frames ..................................................................................... 17
6.5.3 Common Channel Signaling (CCS) Frames ........................................................................................ 18
6.6 CESOETH DEFECTS ..................................................................................................................................... 18
6.6.1 Misconnection ...................................................................................................................................... 19
6.6.2 Reordering and Loss of Frames ........................................................................................................... 19
6.6.3 Late Arriving Frames........................................................................................................................... 20
6.6.4 Malformed CESoETH Frames ............................................................................................................. 20
6.6.5 Jitter Buffer Overrun and Underrun Defects ...................................................................................... 20
6.7 PERFORMANCE MONITORING ....................................................................................................................... 21
6.7.1 Facility Data Link ................................................................................................................................ 21
6.7.2 Errored Data ....................................................................................................................................... 21
7. SERVICE INITIATION AND OPERATION ..................................................................................................... 22
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page ii
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
List of Figures
Figure 6-1: Functional Layering, and mapping onto encapsulation headers .................................................................4
Figure 6-2: Interworking function direction ..................................................................................................................4
Figure 6-3: Functional Components and Interface Types..............................................................................................5
Figure 6-4: Emulated Circuit Identifier (ECID) ............................................................................................................8
Figure 6-5: Structure of the CESoETH control word ....................................................................................................8
Figure 6-6: RTP Header Structure [RFC 3550] ........................................................................................................... 11
Figure 6-7: Synchronization Options for the TDM-bound IWF .................................................................................. 16
Figure 6-8: Encoding Format for CAS ABCD values from [RFC 2833] ................................................................. 18
Figure 8-1: Example TDM Virtual Private Line Configurations ................................................................................. 25
List of Tables
Table 6-1: Meaning of the Local TDM Failure Modification bits.................................................................................9
Table 6-2: Meaning of the Fragmentation bits ..............................................................................................................9
Table 8-1: Example Service Attributes for an EVPL or EPL service carrying CESoETH traffic ............................... 26
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page iii
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
1. Abstract
This document provides an implementation agreement for the emulation of TDM services belonging to the
Plesiochronous Digital Hierarchy (PDH) across a Metro Ethernet Network. Specifically it covers emulation of
Nx64 kbit/s, DS1, E1, DS3 and E3 circuits. Generically this is referred to as Circuit Emulation Services over
Ethernet (CESoETH).
2. Terminology
Term Definition
AAL1 ATM Adaptation Layer 1
AIS Alarm Indication Signal
ANSI American National Standards Institute
ATM Asynchronous Transfer Mode
CAS Channel Associated Signaling
CBS Committed Burst Size
CCS Common Channel Signaling
CE Customer Equipment
CES Circuit Emulation Services
CESoETH Circuit Emulation Services over Ethernet
CF Coupling Flag
CIR Committed Information Rate
CoS Class of Service
CRC Cyclic Redundancy Check (e.g. the 4-bit CRC-4 used to check data integrity of E1 circuits)
E-Line Ethernet Line Service
EBS Excess Burst Size
ECDX Emulated Circuit De/Multiplexing Function
ECID Emulated Circuit Identifier
EIR Excess Information Rate
EFTF Ethernet Flow Termination Function
EPL Ethernet Private Line
EVPL Ethernet Virtual Private Line
ES Errored Second
ESR Errored Second Ratio
ESF Extended Super Frame
EVC Ethernet Virtual Connection
FCS Frame Check Sequence
FDL Facility Data Link
FER Frame Error Ratio
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 1
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
Term Definition
IA Implementation Agreement
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
ITU-T International Telecommunication Union Telecommunication standardization sector
IWF Inter-Working Function
LOS Loss Of Signal
LOF Loss of Frame Alignment
LOFS Loss of Frames State
MAC Medium Access Control
MIB Management Information Base
MEN Metro Ethernet Network
MEN-bound The IWF receiving TDM data from the customers TDM-based equipment, and forwarding this
IWF data in the form of Ethernet frames into the MEN.
PDH Plesiochronous Digital Hierarchy.
PDH refers to the DS1/DS2/DS3 and E1/E3/E4 family of signals as defined by ITU-T and ATIS.
PDU Protocol Data Unit
PWE3 Pseudo-Wire Emulation Edge to Edge (an IETF working group)
RDI Reverse Defect Indication
RTP Real-time Transport Protocol (an IETF protocol, described in RFC 3550)
SF Super Frame
SSRC Synchronization Source (a field within the RTP protocol, RFC 3550)
Structure- Structure-agnostic emulation is the transport of unstructured TDM, or of structured TDM when
agnostic the structure is completely disregarded by the transport mechanism.
Structure- Structure-aware emulation is the transport of structured TDM taking at least some level of the
aware structure into account.
Structure- Encapsulation utilized for Structure-Aware TDM transport where TDM structure boundaries are
locked indicated by packet payload boundaries
Structure- Encapsulation utilized for Structure-Aware TDM transport where TDM structure boundaries are
indicated indicated by pointers
TALS TDM Access Line Service
TDM Time Division Multiplexing
(examples of TDM services include Nx64 kbit/s, DS1, DS3, E1, E3, OC3, STM1, OC12, STM3)
TDM-bound The direction of travel of CESoETH frames within the IWF receiving frames containing
emulated circuit data from the MEN, and forwarding TDM data to the customers TDM-based
equipment.
T-Line TDM Line Service
TSP TDM Service Processing
UNI User Network Interface
VLAN Virtual Local Area Network
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 2
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
3. Scope
The scope of this document is to address the transport of circuits carrying time division multiplexed (TDM) digital
signals over the MEN. It makes references to requirements and specifications produced by other standards
organizations (notably the ITU-T, ANSI, IETF PWE3 and ATM Forum), and adapts these to address the specific
needs of MEN. It is not in the scope of this document to duplicate any work of other related standardization bodies.
The scope of this document is limited to:
1. the essential agreements needed to create inter-operable equipment to reliably transport these TDM circuits
across Metro Ethernet Networks
2. the required performance of the underlying MEN to enable the provision of circuit emulated TDM services that
meet the existing TDM standards, as defined by ITU-T and ANSI
4. Compliance Levels
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD
NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in
[RFC 2119]. All key words must be used in upper case, bold text.
5. Service Description
This implementation agreement describes the detailed methods for transporting TDM circuits over the MEN, in
support of inter-operable implementations of the services described in section 6 of [MEF 3].
[MEF 3] described two main services:
the point-to-point T-Line service
the multi-point to point TALS (TDM Access Line Service).
Both of these services may be implemented using the methods described in this Implementation Agreement.
6. Interworking Function
6.1 ARCHITECTURE
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 3
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
Destination Address
Ethernet Services Layer Source Address
VLAN tags (optional)
Ethertype
Emulated Circuit Identifier (ECID)
Adaptation Function CESoETH Control Word
RTP (optional)
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 4
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
TDM Service CES TDM CES IWF Type CES Payload Adapted Ethernet
Interface Interface Payload Interface
TSP
Customer (optional) CES IWF
TDM IWF ECDX EFTF
Service (e.g. framing,
mux/demux) IWF
TDM Payload
FCS
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 5
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 6
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
In the TDM-bound direction, the EFTF takes in an Ethernet frame from the MEN, and checks the FCS, discarding
the frame if it is incorrect. It determines whether it contains CES payload from the Ethertype field, and forwards it
to its associated ECDX function, for passing to the appropriate CES IWF.
The interfaces to the EFTF consist of the following:
Adapted Payload (i.e. the CES Payload, plus the ECID and Etherype fields)
Ethernet Interface (standard IEEE 802.3 interface)
6.2 ENCAPSULATION
In common with IETF practice, the protocol descriptions in the following sections are in network byte order,
where bit 0 is the most significant bit, and the bytes are transmitted most significant byte first (i.e. left to right in the
figures shown in this document).
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 7
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
L M
Interpretation
bit 4 bit 6 bit 7
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 8
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
L M
Interpretation
bit 4 bit 6 bit 7
1 0 1 Reserved.
1 1 0 Reserved.
1 1 1 Reserved.
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
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 9
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
R8. For structure-agnostic emulation, an MEN-bound IWF MUST set the L bit to one when loss of signal
(LOS) is detected on the TDM service interface
R9. For structure-aware emulation, an MEN-bound IWF SHOULD set the L bit to one where the TDM circuit
indicates any of the following conditions:
a. Loss of Signal (LOS)
b. Alarm Indication Signal (AIS)
c. Loss of frame alignment (LOF)
R10. An MEN-bound IWF MUST clear the L bit as soon as the defect condition is rectified.
R11. A CESoETH frame with the L bit set to one MAY contain no TDM payload.
R12. For structure-agnostic emulation, on reception of CESoETH frames marked with the L bit set to one, the
TDM-bound IWF:
a. SHOULD discard the payload, and play out AIS code for the scheduled duration of the CESoETH
frame.
b. Depending on the application, and where the TDM payload has not been suppressed it MAY play out
the payload.
R13. For structure-aware emulation, on reception of CESoETH frames marked with the L bit set to one, the
TDM-bound IWF:
a. SHOULD discard the payload, and play out AIS for the scheduled duration of the CESoETH frame.
b. Depending on the application, it MAY generate trunk conditioning on the affected channels according
to [TR-NWT-000170].
c. Depending on the application, and where the TDM payload has not been suppressed it MAY play out
the payload.
Requirements relating to the M field:
R14. A CES IWF (of either direction) MUST correctly support the conditions described for which the value of the
M field equals 00. Support for any other condition is OPTIONAL.
R15. Where an MEN-bound IWF is not capable of detecting the conditions described in Table 6-1, it MUST clear
the M field to zero on frames to be transmitted into the MEN.
R16. A TDM-bound IWF MUST silently discard a CESoETH frame where the M field is set to a value it does
not support.
Requirements relating to the Sequence Number field:
R17. The SN field MUST be incremented by one for every CESoETH frame transmitted into the MEN with the
same ECID value, including those frames that are fragments of multiframe structures.
R18. The initial value of the SN field on setup of an emulated circuit SHALL be random.
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 10
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
0 1 2 3 4 7 8 9 15 16 31
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 11
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
R26. CESoETH implementations supporting RTP MUST support the use of absolute mode timestamps
generated using an 8 kHz clock. Other frequencies that are integer multiples of 8 kHz MAY be used.
R27. CESoETH implementations supporting differential mode MUST support the use of timestamps generated
using a 25 MHz clock. Other frequencies MAY be used providing they are:
a. Integer multiples of 8 kHz
b. Not an integer multiple of the clock frequency of the TDM circuit
R28. The synchronization source (SSRC) field MUST be generated and processed in accordance with the rules
established in [RFC 3550].
R29. The SSRC field MAY be used by the TDM-bound IWF for the detection of misconnections.
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 12
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 13
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
R33. CESoETH implementations supporting octet aligned DS1 MUST support a TDM payload size of 200 octets
(including padding). The use of any other payload size is OPTIONAL.
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 14
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
6.4 SYNCHRONIZATION
Synchronization is an important consideration in any circuit emulation scheme. Put simply, the clock used to play
out the data at the TDM-bound IWF must be the same frequency as the clock used to input the data at the MEN-
bound IWF, otherwise frame slips will occur over time. Architectures for synchronization and clock recovery are
discussed in more detail in [MEF 3].
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 15
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
Summarized, there are four basic options for the TDM clock to the TDM-bound IWF, shown in Figure 6-7::
use the clock from the incoming TDM line (TDM line timing)
use an external reference clock source (External timing)
use a free-running oscillator (Free run timing)
recovering the clock from the Ethernet interface (Ethernet line timing)
The last option, Ethernet line timing, covers all methods where information is extracted from the Ethernet,
including:
adaptive timing, where the clock is recovered from data in the CESoETH frames, and the arrival time of the
frames
differential timing, where the clock is recovered from a combination of data contained in the CESoETH
frames, and knowledge of a reference clock common to both the MEN-bound and TDM-bound IWFs. Such a
reference may be distributed by a variety of means.
For maximum applicability, it is recommended that CESoETH implementations should support at least TDM line,
external and adaptive timing. This will enable the implementation to be used in the majority of timing scenarios.
However, not every combination of timing options for the TDM-bound IWFs on either side of the MEN will yield
performance capable of meeting R47, so care must be taken to ensure the combinations chosen are appropriate.
External Timing
Reference
CESoETH IWF
Clock
MEN-bound
Data
IWF TDM Ext.
To TDM Line To MEN
(or TSP) Clock Clock Eth.
TDM-bound Line Clock
Data Recovery
IWF Data
Free
Run
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 16
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 17
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
R53. The payload of each signaling frame MUST comprise N 32-bit words (where N is the number of timeslots in
the service)
R54. The i-th word of the payload MUST contain the current ABCD value of the CAS signal corresponding to
the i-th timeslot, and MUST be encoded in accordance with [RFC 2833], section 3.14, table 6 (see Figure
6-8, below)
0 7 8 9 10 15 16 31
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).
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 18
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
6.6.1 Misconnection
Should a frame be wrongly directed to a CES IWF, it is possible for it to be mis-interpreted as a genuine CESoETH
frame, especially if the first word of the payload match a known emulated circuit ID value. In order to detect such
stray frames, the following rules should be applied:
R57. The CES IWF MUST only accept frames that contain the correct Ethernet destination address field and
ECID value for that IWF.
R58. The CES IWF SHOULD provide additional protection by checking the Ethernet source address field against
the known source address of the given emulated circuit ID.
R59. Where RTP is being used, further protection MAY be provided by checking the value of the SSRC field
against the known SSRC value of the given emulated circuit ID.
R60. When a stray frame is detected by a CES IWF, it MUST be discarded.
R61. If the percentage of stray frames persists above a defined level for a configurable period of time (by default,
2.5 seconds), the Misconnection alarm SHOULD be reported to the management system.
R62. The Misconnection alarm SHOULD be cleared if no stray frames have been detected for a configurable
period of time (by default, 10 seconds).
R63. The mechanisms for detection of lost frames (e.g. expected next sequence number) MUST NOT be affected
by reception of stray frames.
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 19
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 20
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
However, there may be occasions when the frame delay variation is abnormally large, and either overrun or
underrun conditions may occur. These conditions may also occur when the clock used for playout of the TDM data
from the jitter buffer is not at precisely the same frequency as the original TDM service clock presented to the
MEN-bound IWF.
The Jitter Buffer Overrun condition occurs when the jitter buffer at the TDM-bound IWF cannot accommodate the
newly arrived valid CESoETH frame in its entirety, e.g. due to insufficient storage space. The Jitter Buffer
Underrun condition occurs when there is no correctly received CESoETH payload ready to be played out on the
TDM interface, and replacement data must be played out instead. Primarily this occurs due to frames lost in the
MEN, or discarded due to error conditions, hence this is not usually identified separately.
The following requirements apply to the detection of jitter buffer defects:
R78. A CESoETH IWF MUST detect the Jitter Buffer Overrun conditions.
R79. If a CESoETH frame arrives that cannot be stored in the jitter buffer due to a jitter buffer overrun condition,
the TDM-bound IWF MUST discard the frame.
R80. If the percentage of frames causing Jitter Buffer Overruns persists above a defined level for a configurable
period of time (by default, 2.5 seconds), a Jitter Buffer Overrun alarm SHOULD be sent to the management
system.
R81. The Jitter Buffer Overrun alarm SHOULD be cleared if no cases of jitter buffer overrun have been detected
for a configurable period of time (by default, 10 seconds).
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 21
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
R84. A CESoETH implementation SHOULD be capable of monitoring the Frame Error Ratio (FER) performance
of the CESoETH connection.
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
3) Payload size
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 22
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
This is defined as the number of octets of TDM payload carried in each CESoETH frame. It is the same for
each direction of the emulated circuit.
For structure-aware, structure-locked encapsulation of N x 64kbit/s service with CAS (section 6.3.2), this
EXCLUDES the CAS sub-structure carried in the last frame of every structure.
For structure-indicated encapsulation (section 6.3.3), this parameter is 48 times the number of AAL1 PDUs per
CESoETH frame.
6) RTP
This boolean parameter specifies whether the RTP header is to be used or not.
9) Payload Type
The value to be used for the Payload Type field, as described in section 6.2.2.3.
The following additional parameters need to be assigned if generic TDM signaling (section 6.5) is used:
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 23
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
The following locally configured parameters are applicable to all defect alarms:
Duration of high defect level after which the relevant alarm is triggered (default is 2.5s)
Duration of low defect level after which the relevant alarm is cleared (default is 10s)
The following locally configured parameters are relevant to the triggering of the individual defect alarms:
Percentage of misconnection occurrences above which the Misconnection alarm is triggered (see R61)
Frame loss ratio above which the Loss of Frames alarm is triggered (see R69)
Percentage of late arriving frame occurrences above which the Late Frame alarm is triggered (see R72)
Percentage of malformed frame occurrences above which the Malformation alarm is triggered (see R76)
Percentage of jitter buffer overrun occurrences above which the Jitter Buffer Overrun alarm is triggered
(see R80)
The following locally configured parameters are relevant to the clearing of the individual defect alarms. The
remainder of the alarms are cleared by a period of absence of the alarm condition.
Frame loss ratio below which the Loss of Frames alarm is cleared (see R70)
Percentage of late arriving frame occurrences below which the Late Frame alarm is cleared (see R73)
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 24
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
8. MEN Requirements
8.1 MEN SERVICE TYPE
Both T-Line and TALS versions of the CESoETH service are run across point-to-point EVCs (i.e. across an E-
Line service type). In the simplest case of a pair of IWFs connected by an E-Line service, the Ethernet service
resembles an EPL (Ethernet Private Line). However, in many cases several IWFs may share an Ethernet UNI (and
in fact, several IWFs could also share an EVC). Therefore in general the Ethernet service required more closely
resembles an EVPL (Ethernet Virtual Private Line). Both the EPL and EVPL services are normatively described in
[MEF 6].
Figure 8-1 shows a typical configuration where several small sites may be connected to some larger sites over point-
to-point EVCs. Any service multiplexing is performed in the TDM domain as part of the TSP (TDM Service
Processing) function.
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 25
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
Table 8-1: Example Service Attributes for an EVPL or EPL service carrying CESoETH traffic
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 26
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 27
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
9. Management
9.1 ALARMS
Alarms relating to TDM defects must be raised by the first network element that detects the defect. For example, in
the case of loss of signal (LOS), this should be raised by the TDM service processor or physical layer device
connected to the TDM circuit. Hence the IWF is not required to generate alarms for TDM defects.
Alarms relating to defects in the MEN are specified in the relevant sections of this document (see section 6.6).
These include:
Misconnection alarm (section 6.6.1)
Loss of Frames alarm (section 6.6.2)
Late Frames alarm (section 6.6.3)
Malformed Frames alarm (section 6.6.4)
Jitter buffer overrun alarm (section 6.6.5)
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 28
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
10. References
Reference Reference Details
RFC 2119 Key words for use in RFCs to Indicate Requirement Levels, RFC 2119, S. Bradner, March
1997, http://www.ietf.org/rfc/rfc2119.txt
RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals, RFC 2833, H.
Schulzrinne, S. Petrack, May 2000, http://www.ietf.org/rfc/rfc2833.txt
RFC 3550 RTP: A Transport Protocol for Real-Time Applications, RFC3550, H. Schulzrinne et al,
September 2003, http://www.ietf.org/rfc/rfc3550.txt
RTP TYPES RTP Payload types (PT) for standard audio and video encodings Closed,
http://www.iana.org/assignments/rtp-parameters
G.702 Digital hierarchy bit rates, ITU-T Recommendation G.702, November 1988
G.704 Synchronous Frame Structures used at 1544, 6312, 2048, 8448 and 44736 Hierarchical Levels,
ITU-T Recommendation G.704, October 1998
G.705 Characteristics of plesiochronous digital hierarchy (PDH) equipment functional blocks, ITU-T
Recommendation G.705, October 2000
G.751 Digital multiplex equipments operating at the third order bit rate of 34 368 kbit/s and the fourth
order bit rate of 139 264 kbit/s and using positive justification, ITU-T Recommendation G.751,
November 1988
G.802 Interworking between networks based on different digital hierarchies and speech encoding
laws, ITU-T Recommendation G.802, November 1988
G.823 The control of jitter and wander within digital networks which are based on the 2048 kbit/s
hierarchy, ITU-T recommendation G.823, March 2000
G.824 The control of jitter and wander within digital networks which are based on the 1544 kbit/s
hierarchy, ITU-T recommendation G.823, March 2000
G.826 Error performance parameters and objectives for international, constant bit rate digital paths at
or above the primary rate, ITU-T Recommendation G.826, February 1999
G.827 Availability performance parameters and objectives for international, constant bit rate digital
paths at or above the primary rate, ITU-T Recommendation G.827, September 2003
G.1020 Performance Parameter Definitions for Quality of Speech and other Voiceband Applications
Utilising IP Networks, ITU-T Recommendation G.1020, November 2002
I.231.1 Circuit-mode 64 kbit/s unrestricted, 8 kHz structured bearer service, ITU-T Recommendation
I.231.1, November 1988
I.363.1 B-ISDN ATM Adaptation Layer specification: Type I AAL, ITU-T Recommendation I.363.1,
August 1996
Y.1413 TDM-MPLS Network Interworking User Plane Interworking, ITU-T Recommendation
Y.1413, March 2004
T1.102 Digital Hierarchy Electrical Interfaces, ANSI T1.102-1993
T1.107 Digital Hierarchy Formats Specifications, ANSI T1.107-2002
T1.403 Network and Customer Installation Interfaces DS1 Electrical Interface, ANSI T1.403-1999
T1.510 Network Performance Parameters for Dedicated Digital Services for Rates up to and including
DS3, ANSI T1.510-1999
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 29
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Implementation Agreement for the Emulation of
PDH Circuits over Metro Ethernet Networks
MEF 8 The Metro Ethernet Forum 2004. Any reproduction of this document, or any portion thereof, shall Page 30
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Technical Specification
MEF 28
October 2010
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Disclaimer
The information in this publication is freely available for reproduction and use by any recipient
and is believed to be accurate as of its publication date. Such information is subject to change
without notice and the Metro Ethernet Forum (MEF) is not responsible for any errors. The MEF
does not assume responsibility to update or correct any information in this publication. No
representation or warranty, expressed or implied, is made by the MEF concerning the
completeness, accuracy, or applicability of any information contained herein and no liability of
any kind shall be assumed by the MEF as a result of reliance upon such information.
The information contained herein is intended to be used without modification by the recipient or
user of this document. The MEF is not responsible or liable for any modifications to this
document made by any other party.
The receipt or any use of this document or its contents does not in any way create, by implication
or otherwise:
a) any express or implied license or right to or under any patent, copyright, trademark or
trade secret rights held or claimed by any MEF member company which are or may be
associated with the ideas, techniques, concepts or expressions contained herein; nor
b) any warranty or representation that any MEF member companies will announce any
product(s) and/or service(s) related thereto, or if such announcements are made, that such
announced product(s) and/or service(s) embody any or all of the ideas, technologies, or
concepts contained herein; nor
c) any form of relationship between any MEF member companies and the recipient or user
of this document.
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface Support for UTA and VUNI
Table of Contents
1 Abstract ................................................................................................................................... 1
2 Terminology............................................................................................................................ 1
3 Scope and Key Concepts ........................................................................................................ 2
3.1 UTA Components ........................................................................................................... 5
3.1.1 UTA OVC Component ............................................................................................... 5
3.1.2 Remote UNI Component ............................................................................................ 5
3.1.3 VUNI Component ....................................................................................................... 5
4 Compliance Levels.................................................................................................................. 5
5 Requirements for the UTA OVC Component ........................................................................ 6
5.1 UTA OVC ....................................................................................................................... 6
5.2 UTA OVC End Point at the Remote UNI ....................................................................... 7
5.3 UTA OVC End Point at the ENNI in the Network Operators MEN ............................. 8
5.3.1 Color Marking at the UTA OVC End Point at the ENNI in the Network Operators
MEN............................................................................................................................ 9
5.4 ENNI Service Attributes Supporting the UTA OVC .................................................... 10
6 Requirements for the Remote UNI Component.................................................................... 11
7 Requirements for the VUNI Component .............................................................................. 12
7.1 Virtual UNI (VUNI) Service Attributes ....................................................................... 12
7.2 ENNI Service Attributes Supporting the VUNI ........................................................... 13
7.3 Service Attributes for an OVC End Point associated by the VUNI ............................. 14
7.3.1 VUNI Class of Service Identifiers ............................................................................ 15
7.4 Bandwidth Profiles at the VUNI ................................................................................... 17
7.4.1 Ingress Bandwidth Profile per VUNI End Point Service Attribute .......................... 17
7.4.2 Egress Bandwidth Profile per VUNI End Point Service Attribute ........................... 17
7.4.3 Ingress Bandwidth Profile per OVC End Point associated by a VUNI Service
Attribute .................................................................................................................... 18
7.4.4 Ingress Bandwidth Profile per Class of Service Identifier per OVC End Point
associated by a VUNI Service Attribute ................................................................... 18
7.4.5 Egress Bandwidth Profile per OVC End Point associated by a VUNI Service
Attribute .................................................................................................................... 18
7.4.6 Egress Bandwidth Profile per Class of Service Identifier per OVC End Point
associated by a VUNI Service Attribute ................................................................... 18
7.4.7 Color Awareness at the VUNI .................................................................................. 19
8 Appendix A: Example: Multiple EVCs ................................................................................ 20
9 Appendix B: Multi-MEN UTA............................................................................................. 22
10 Appendix C: VUNI Implementation Example ..................................................................... 24
11 References ............................................................................................................................. 26
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page i
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface Support for UTA and VUNI
List of Figures
FIGURE 1 UNI TUNNEL ACCESS MODEL ......................................................................................................................2
FIGURE 2 EVCS IMPLEMENTED USING VUNI, UTA OVC, AND REMOTE UNI ...............................................................3
FIGURE 3 EXAMPLE WITH MULTIPLE VUNIS ASSOCIATED WITH A SINGLE ENNI .......................................................4
FIGURE 4 KEY TO THE ICONS USED IN THE EXAMPLES .............................................................................................20
FIGURE 5 EXAMPLE OF THE REMOTE UNI IN MULTIPLE EVCS ..................................................................................20
FIGURE 6 EXAMPLE MULTIPLE EVCS SUPPORTED BY UTA AND VUNI ......................................................................21
FIGURE 7 MULTI-MEN UNI TUNNEL ACCESS MODEL................................................................................................22
FIGURE 8 EXAMPLE MULTIPLE EVCS SUPPORTED BY A MULTI-MEN UTA ................................................................23
FIGURE 9 VUNI USING IEEE 802.1 C AND S COMPONENTS MODEL..........................................................................24
List of Tables
TABLE 1: ACRONYMS AND DEFINITIONS ......................................................................................................................2
TABLE 2: OVC SERVICE ATTRIBUTES CONSTRAINTS FOR UTA OVC ...............................................................................7
TABLE 3: OVC END POINT PER UNI SERVICE ATTRIBUTE CONSTRAINTS FOR UTA OVC END POINT AT THE REMOTE
UNI .................................................................................................................................................................8
TABLE 4: OVC END POINT PER ENNI SERVICE ATTRIBUTE CONSTRAINTS FOR AN OVC SUPPORTING UTA ..................9
TABLE 5: ENNI SERVICE ATTRIBUTE CONSTRAINTS FOR THE UTA NETWORK OPERATOR ..........................................10
TABLE 6: VUNI SERVICE ATTRIBUTE CONSTRAINTS FOR UTA .....................................................................................13
TABLE 7: ENNI SERVICE ATTRIBUTE CONSTRAINTS FOR VUNI PROVIDER ..................................................................14
TABLE 8: SERVICE ATTRIBUTES FOR OVC END POINTS ASSOCIATED BY THE VUNI.....................................................15
TABLE 9: ABBREVIATIONS USED IN THE EXAMPLES....................................................................................................20
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page ii
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface Support for UTA and VUNI
1 Abstract
The External Network Network Interface (ENNI) is a reference point that describes the interface
between two Metro Ethernet Networks (MENs) and is intended to support the transparent
extension of Ethernet services across multiple Network Operator MENs, where each Network
Operator MEN is under the control of a distinct administrative authority. This Technical
Specification extends the ENNI by defining the UNI Tunnel Access (UTA) which associates a
Virtual UNI (VUNI), a remote UNI, and at least one supporting OVC.
The requirements for the UNI Tunnel Access (UTA) in sufficient detail to ensure
interoperability between MENs.
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.
1
For this initial phase, the remote UNI is supported by a Network Operator MEN as a UNI with specific attribute
constraints (as described in this document) that is not aware of the EVC services. For future phases, an EVC service
aware remote UNI may be considered.
2
UTA is minimally supported by the UTA OVC within the Network Operator MEN that provides the remote UNI.
Future versions of UTA may additionally be supported by OVCs traversing intermediate providers in order to
extend the tunnel. See Appendix B.
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page 1
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface Support for UTA and VUNI
The VUNI in the VUNI Providers MEN has service attributes similar to those of a UNI, and is
paired with a remote UNI in the Network Operators MEN. The VUNI is associated with a
VUNI End Point at the VUNI Providers side of an ENNI. Its main function is to specify the
processing rules applicable to ENNI frames present in the VUNI Provider domain and associate
them with a given UTA instance.
3
While the remote UNI is shown in Figure 1 is adjacent to the CE, UTA also allows (but does not require) a
Service Provider to support UNI-UNI service level monitoring by placing a capability between the Remote UNI and
the CE (e.g., implemented within a network interface device) for Service Level verification.
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page 2
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface Support for UTA and VUNI
Figure 2 below shows an example of a UTA between a VUNI and remote UNI (UNI Y). In this
figure, EVC1, EVC2, and EVC3 are available to the Subscriber at the remote UNI. However, the
Network Operator supporting the remote UNI is not responsible for the management of the
EVCs across the Network Operators MEN. The Network Operator is responsible for
management of the UTA OVC between its side of the ENNI and the remote UNI, including the
service attributes of the remote UNI. For this initial phase, the remote UNI supports only very
basic service attributes and is not aware of the details of the services for the Subscriber, e.g., the
number of EVCs seen by the Subscriber.
Figure 2 EVCs Implemented Using VUNI, UTA OVC, and remote UNI4
In Figure 2, the CE at UNI Y participates in EVCs 1, 2, and 3. These EVCs have the Service
Provider agreed Bandwidth Profile Attributes, and CoS markings. At the remote UNI, Service
Frames of EVC 1, 2, and 3 are exchanged with the CE. Such frames may be C-tagged, priority
tagged, or untagged. The remote UNI is instantiated by the Network Operator as a UNI where
the Network Operator maps all Service Frames to the single OVC End Point supporting the UTA
OVC. A single bandwidth profile and CoS may be applied at this remote UNI OVC End Point.
At the UTA OVC End Point at the Network Operators side of the ENNI, an S-VLAN ID is used
to map ENNI Frames to the OVC End Point supporting the UTA, and applies a UTA specific
single bandwidth profile and CoS.
4
The OVC End Points associated by a VUNI in this figure represent the association of OVC A1, A2, and A3 with
the ENNI as specified in [MEF 26].
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page 3
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface Support for UTA and VUNI
In the VUNI Providers network, the relationship between the UTA OVC and the VUNI is
realized by an S-VLAN ID present at the ENNI, whose value is negotiated between the VUNI
Provider and the Network Operator. At the ENNI, when receiving an ENNI Frame, the VUNI
Provider maps (using the End Point Map) a single S-VLAN ID to a VUNI End Point associated
with a VUNI. The VUNI then maps frames based on their CE-VLAN ID to the appropriate OVC
End Point for OVCs A1, A2 and A3. In the reverse direction, the VUNI multiplexes frames from
OVCs A1, A2, and A3 into a tunnel denoted by a unique S-VLAN ID, which is associated with
the Network Operators UTA OVC. Note that A1, A2 and A3 have non-overlapping CE-VLAN
IDs at the VUNI.
Figure 3 provides an example that shows multiple VUNIs associated with a single ENNI.
This technical specification assumes the following business model: The Subscriber contracts
with a Service Provider (who either acts as the VUNI Provider, or contracts with the VUNI
Provider) to provide Ethernet Services among UNIs, including those UNIs outside of the Service
Providers serving area. That is, the EVC Service Level Specification (SLS) remains UNI to
UNI. The Service Provider, in turn, selects and contracts with one or more Network Operators to
provide one UTA OVC to reach each remote UNI. It is the responsibility of the Service Provider
to ensure the appropriate connectivity properties for each UTA such that the UNI-to-UNI service
features purchased by the Subscriber can be delivered.
A service arrangement involving one or more Intermediate Network Operators between the
VUNI Provider MEN and the Network Operator MEN supporting the remote UNI is a possible
extension to the service model; however, details around this Use Case are left as a For Future
Study (FFS) item. Appendix B provides a model along with some examples of how the multi-
MEN extensions may be realized.
5
The OVC End Points associated by each VUNI in this figure represent the association of OVCs with the ENNI as
specified in [MEF 26].
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page 4
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface Support for UTA and VUNI
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).
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.
This Specification details the behavior of the VUNI that is associated with the ENNI related to
the UTA at the Network Operators side of an ENNI (VUNI at the ENNI in Figure 1). The
VUNI attributes include: mapping of the VUNI to the End Point associated with the UTA OVC
at the opposite side of the ENNI; and mapping of ENNI Frames to one or more VUNI Provider
OVC End Points in support of Subscriber services.
4 Compliance Levels
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in RFC 2119.
Items that are REQUIRED (contain the words MUST or MUST NOT) will be labeled as [Rx]
for required. Items that are RECOMMENDED (contain the words SHOULD or SHOULD
NOT) will be labeled as [Dx] for desirable. Items that are OPTIONAL (contain the words MAY
or OPTIONAL) will be labeled as [Ox] for optional.
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page 5
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface Support for UTA and VUNI
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:
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.
[R1] A UTA OVC MUST assign OVC service attributes and values according to
Table 2.
[R2] An OVC End Point supporting the UTA at a remote UNI MUST assign
service attributes and values according to Table 3.
Note that because the OVC End Point at the remote UNI is a special constrained case of an OVC
End Point at a UNI, the UNI terminology of [MEF 26] refers to remote UNI in Table 3.
6
The value of the S-VLAN ID Preservation attribute does not affect the behavior of the UTA OVC.
7
The value of the S-VLAN ID COS Preservation attribute does not affect the behavior of the UTA OVC.
8
Color Forwarding is replaced by the color marking behavior for egress ENNI Frames as described in Section 5.3.1
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page 7
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface Support for UTA and VUNI
OVC End Point per UNI Service Additional Constraints for the UTA OVC End Point at the Remote
Attribute UNI
UNI OVC Identifier No additional constraints
OVC End Point Map All CE-VLAN ID values at the remote UNI MUST map to the
single OVC End Point
Class of Service Identifiers MUST provide only a single Class of Service Identifier9
Ingress Bandwidth Profile Per If an Ingress Bandwidth Profile per OVC End Point at a remote
OVC End Point at a UNI UNI is supported, it MUST be configured as color blind and
(remote UNI) MUST specify either CIR as ZERO or EIR as ZERO10. For
more information on this Bandwidth Profile, please see [MEF
10.2]
Ingress Bandwidth Profile Per MUST NOT specify
Class of Service Identifier at a
UNI (remote UNI)
Egress Bandwidth Profile Per MUST NOT specify
OVC End Point at a UNI
(remote UNI)
Egress Bandwidth Profile Per MUST NOT specify
Class of Service Identifier at a
UNI (remote UNI)
Table 3: OVC End Point per UNI Service Attribute Constraints for UTA OVC End Point
at the Remote UNI
As indicated in Table 3, all frames transported by the UTA OVC are mapped to a single class of
service. Therefore, if a service provider wants to support multiple EVCs with different
performance objectives on a single UTA OVC, then the service provider should select UTA
OVC performance objectives such that the UNI to UNI performance objectives of the most
demanding EVCs can be achieved.
5.3 UTA OVC End Point at the ENNI in the Network Operators MEN
The UTA OVC applies the OVC End Point per ENNI Service Attributes and Requirements as
defined in Section 7.3 of [MEF 26]. However some specific service attributes have been further
constrained and are described in the requirements below.11 In addition, the color marking
behavior for egress ENNI Frames at the UTA OVC End Point at the ENNI in the Network
Operators MEN is described in Section 5.3.1.
[R3] An OVC End Point supporting a UTA at an ENNI MUST assign service
attributes and values according to Table 4.
9
Class of Service Identifier should be based on the OVC End Point as described in Section 7.5.3.1 of [MEF 26]
10
Note, this implies a single color in that either all frames will be declared yellow, or all will be declared green,
respectively.
11
Note, this applies to the OVC End Point on the Network Operators side of the ENNI. The requirements for the
End Point at the VUNI Providers side of the ENNI are provided in Section 7.
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page 8
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface Support for UTA and VUNI
5.3.1 Color Marking at the UTA OVC End Point at the ENNI in the Network
Operators MEN
Since the Ingress Bandwidth Profile at the UTA OVC End Point at a remote UNI is defined to
declare Service Frames to be either Green/Red (since CIR>0, EIR=0) or Yellow/Red (since
CIR=0, EIR>0) (i.e., all resulting egress ENNI Frames must be the same color), there is no need
for the Network Operator to carry the ingress color marking result across the network to the
ENNI. Proper ENNI Frame color marking may be achieved by examining the Bandwidth Profile
information of the UTA OVC End Point at the remote UNI to identify the appropriate color
marking of each egress ENNI Frame mapped to the UTA OVC End Point at the Network
Operator ENNI. The Bandwidth Profile attribute of the UTA OVC End Point at the remote UNI
describes the color marking of each egress ENNI Frame (i.e. toward the VUNI provider) that is
mapped to the UTA OVC End Point at the ENNI by the ENNI End Point Map.
[R4] When there is an ingress Bandwidth Profile of the UTA OVC End Point at the
remote UNI with CIR > 0 and EIR = 0, each egress ENNI Frame mapped to
the corresponding UTA OVC End Point at the ENNI by the ENNI End Point
Map MUST be marked Green via the S-Tag as per [MEF 23].
[R5] When there is an ingress Bandwidth Profile of the UTA OVC End Point at the
remote UNI with CIR = 0 and EIR > 0, each egress ENNI Frame mapped to
the corresponding UTA OVC End Point at the ENNI by the ENNI End Point
Map MUST be marked Yellow via the S-Tag as per [MEF 23].
[O1] In the case where no ingress Bandwidth Profile is defined for the UTA OVC
End Point at the remote UNI, the Network Operator MAY set the color of the
egress ENNI Frame based on bilateral agreement with the Service Provider.
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page 9
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface Support for UTA and VUNI
For the UTA Network Operator, the ENNI Attributes as defined in Section 7.1 of [MEF 26] are
applied.
[R6] A Network Operator ENNI supporting the UTA related OVC End Point
MUST assign service attributes and values according to Table 5.
Constraints for the UTA Network Operator ENNI Service Attributes are summarized in Table 5.
ENNI Service Attribute Service Attribute Parameters and Constraints for the
UTA Network Operator
Operator ENNI Identifier No additional constraints
Physical Layer No additional constraints
Frame Format No additional constraints
Number of Links No additional constraints
Protection Mechanism No additional constraints
ENNI Maximum No additional constraints
Transmission Unit Size
End Point Map The End Point Type within an End Point Map for a UTA OVC
Component related OVC End Point at an ENNI MUST take the
value of OVC.
Maximum Number of No additional constraints
OVCs
Maximum Number of OVC No additional constraints
End Points per OVC
Table 5: ENNI Service Attribute Constraints for the UTA Network Operator
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page 10
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface Support for UTA and VUNI
The remote UNI reuses the UNI service attributes specified in Section 7.4 of [MEF 26].
As described by the OVC End Point Map attribute in Table 3, the remote UNI supporting the
UTA OVC is configured to support a single OVC End Point to which all CE VLAN IDs are
mapped at the remote UNI. A Bandwidth Profile is specified for the OVC End Point of the UTA
OVC at the remote UNI. For UTA, other Bandwidth Profiles may be configured, for example a
Bandwidth Profile for the VUNI as a whole (see Section 7.4). A separate Bandwidth Profile per
remote UNI is redundant and may cause additional undesired behavior; hence it is not to be
specified.
[R7] The remote UNI supporting the UTA OVC MUST NOT specify an Ingress
Bandwidth Profile per UNI.
[R8] The remote UNI supporting the UTA OVC MUST NOT specify an Egress
Bandwidth Profile per UNI.
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page 11
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface Support for UTA and VUNI
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.
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.
In order to describe the VUNI attributes, the concept of an ENNI CE-VLAN ID is defined for an
ENNI Frame that is mapped to a VUNI End Point as follows:
If an ENNI Frame is mapped to a VUNI End Point and the ENNI Frame has a C-Tag
whose VLAN ID value is not zero, then the ENNI CE-VLAN ID for the ENNI Frame is
the value of VLAN ID in the C-Tag.
If an ENNI Frame is mapped to a VUNI End Point and the ENNI Frame either has no C-
Tag or has a C-Tag whose VLAN ID value is zero, then the ENNI CE-VLAN ID is a
value in the range 1,2,,4094 that is agreed upon by both the Service Provider and the
Operator supporting the VUNI.12
[R9] A VUNI supporting the UTA MUST assign service attributes and values
according to Table 6.
Note, in Table 6, the Ingress Bandwidth Profile is applied to traffic that flows from the
Subscriber at the remote UNI to the VUNI Provider MEN, and the Egress Bandwidth Profile is
applied to traffic that flows from the VUNI Provider MEN to the Subscriber at the remote UNI.
12
The value also needs to be agreed upon between the Service Provider and the Subscriber.
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page 12
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface Support for UTA and VUNI
VUNI Service Attribute Service Attribute Parameters and Constraints for UTA
Arbitrary text string of no more than 45 bytes to identify the
VUNI. The VUNI Identifier MUST be unique among all VUNI
VUNI Identifier
Identifiers within the scope of all ENNIs supported by the VUNI
Provider MEN.
ENNI CE-VLAN ID value for MUST specify CE-VLAN ID value in the range of 1-4094.
ENNI Frames with no C-Tag
or a C-Tag whose VLAN ID
value is 0
Maximum number of related
OVC End Points in the VUNI MUST be an integer 1.
Provider MEN
Ingress Bandwidth Profile Per
(See Section 7.4.1)
VUNI
Egress Bandwidth Profile Per
(See Section 7.4.2)
VUNI
Table 6: VUNI Service Attribute Constraints for UTA
When VUNI attributes are enabled in support of the UTA, the ENNI Attributes as defined in
Section 7.1 of [MEF 26] are applied to describe the behavior of the ENNI, however a specific
attribute has been extended as described in the requirement below to allow for mapping of an S-
VLAN ID at the ENNI to a specific VUNI End Point.
[R10] A VUNI Provider ENNI supporting the UTA MUST assign service attributes
and values according to Table 7.
Constraints for the VUNI Provider ENNI Service Attributes are specified in Table 7.
13
These service attributes would remain the same in the case where an intermediate operator provides connectivity
to the network operator supporting the remote UNI as described in the Multi-MEN model provided in Appendix B.
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page 13
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface Support for UTA and VUNI
The VUNI End Point at the VUNI Provider ENNI is associated with a UTA and is indicated with
the End Point Type VUNI in the ENNI Service Attribute End Point Map, see Section 7.1.7.1 of
[MEF 26]. Multiple VUNI End Points can reside at a single ENNI.
[R11] At an ENNI, an End Point Map entry with an End Point Type of VUNI MUST
provide an association to a VUNI End Point by applying the End Point Map
entrys End Point Identifier to map ENNI frames with the given S-VLAN ID
Value to a VUNI End Point.
As per requirement [R16] of [MEF 26], the End Point Map at the ENNI uses the S-VLAN-ID of
a given S-Tagged ENNI Frame to determine the VUNI End Point to which an ENNI Frame is
mapped.
7.3 Service Attributes for an OVC End Point associated by the VUNI
There are attributes for each instance of an OVC End Point associated with a specific VUNI.15
These service attributes are based on the OVC per UNI Attributes as described in Section 7.5 of
[MEF 26].
[R12] A given OVC MUST associate at most one OVC End Point that is associated
by a specific VUNI.
14
This requirement extends the End Point Type as defined in [R18] of [MEF 26].
15
Note that the OVC(s) discussed in this section are in the VUNI Provider MEN, as opposed to the UTA OVC
Service Component that is in the Network Operator MEN.
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page 14
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface Support for UTA and VUNI
[R13] In the VUNI Provider MEN, once an ENNI frame received from the Network
Operators MEN is mapped to a specific VUNI End Point that identifies the
VUNI based on the S-VLAN ID Value in the ENNI End Point Map Service
Attribute, the VUNI OVC End Point Map MUST be applied to determine the
OVC End Point associated with the frames C-VLAN ID Value.
[R14] An OVC End Points service attributes for an OVC End Point that is
associated by a VUNI MUST be configured with values according to Table 8.
[R15] There MUST be three mutually exclusive ways to determine the Class of
Service Identifier from the content of a given ENNI Frame mapped to a VUNI
as described in Sections 7.3.1.1, 7.3.1.2, and 7.3.1.3.
Note that Sections 7.3.1.1, 7.3.1.2, and 7.3.1.3 describe Class of Service Identifiers for ingress
ENNI Frames mapped to a VUNI.
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page 15
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface Support for UTA and VUNI
[R16] When the Class of Service Identifier is based on OVC End Point, all ingress
ENNI Frames mapped to the same OVC End Point at the VUNI MUST have
the same Class of Service Identifier.
As an example, consider OVC End Point 1 and OVC End Point 2 associated by a VUNI. ENNI
Frames mapped to OVC End Point 1 have a first Class of Service Identifier that indicates gold
service. ENNI Frames mapped to OVC End Point 2 have a second Class of Service Identifier
that indicates silver service.
7.3.1.2 VUNI Class of Service Identifier Based on C-Tag Priority Code Point Field
[R17] When the Class of Service Identifier is based on C-Tag Priority Code Point
field, the Class of Service Identifier for an ingress ENNI Frame mapped to a
VUNI MUST be determined by the combination of the OVC End Point and
non-overlapping sets of values of the C-Tag Priority Code Point field.
[R18] When the Class of Service Identifier is based on C-Tag Priority Code Point
field, if the ingress ENNI frame does not contain a C-Tag, it MUST have the
same Class of Service Identifier as an ingress frame with C-Tag Priority Code
Point field = 0 in the C-Tag.
[R19] When the Class of Service Identifier is based on C-Tag Priority Code Point
field, the union of the sets of C-Tag PCP field values MUST contain all of the
possible values.
As an example, consider OVC End Point 1 and OVC End Point 2 associated by a VUNI. The
ENNI Frames mapped to OVC End Point 1 with C-Tag Priority Code Point values 4, 5, 6, and 7
have a first Class of Service Identifier that indicates gold service. The ENNI Frames mapped to
OVC End Point 1 with C-Tag Priority Code Point values 0 and 3 have a second Class of Service
Identifier that indicates silver service. The ENNI Frames mapped to OVC End Point 1 with C-
Tag Priority Code Point values 1 and 2 have a third Class of Service Identifier that indicates
Service Frame discard. VUNI-mapped ENNI Frames without a C-Tag that are mapped to OVC
End Point 1 also have the second Class of Service Identifier that indicates silver service. The
ENNI Frames mapped to OVC End Point 2 with C-Tag Priority Code Point value 7 have a fourth
Class of Service Identifier that indicates platinum service. All other VUNI mapped frames
mapped to OVC End Point 2 have a fifth Class of Service Identifier that indicates gold service.
[R20] When the Class of Service Identifier is based on DSCP, the Class of Service
Identifier for an ingress ENNI Frame mapped to a VUNI containing an IP
packet MUST be determined by the combination of the OVC End Point and
non-overlapping sets of values of the DSCP.
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page 16
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface Support for UTA and VUNI
[R21] When the Class of Service Identifier is based on DSCP, the union of the sets
of DSCP values MUST contain all of the possible DSCP values.
[R22] When the Class of Service Identifier is based on DSCP, each ingress ENNI
Frame mapped to a VUNI not containing an IP packet and mapped to a given
OVC End Point MUST have the same Class of Service Identifier with a value
agreed upon by the Subscriber and the Service Provider.
7.4.1 Ingress Bandwidth Profile per VUNI End Point Service Attribute
[R23] When an Ingress Bandwidth Profile per VUNI is in force, the algorithm and
parameters described in Section 7.6.1 of [MEF 26] MUST be applied to all
incoming ENNI Frames mapped to the VUNI End Point of the VUNI.
[R24] When an Ingress Bandwidth Profile per VUNI is in force, ingress ENNI
Frames mapped to the VUNI End Point of the VUNI MUST NOT be
subjected to any other type of ingress bandwidth profile.
Per Section 7.6.1 of [MEF 26], each ingress ENNI Frame can be the subject of at most one
ingress Bandwidth Profile. The Ingress Bandwidth Profile per VUNI manages bandwidth non-
discriminately for all OVCs supported by the VUNI.
7.4.2 Egress Bandwidth Profile per VUNI End Point Service Attribute
[R25] When an Egress Bandwidth Profile per VUNI is in force, suitable parameters
<CIR, CBS, EIR, EBS, CF, CM> as defined in Section 7.6.1 of [MEF 26]
MUST be specified and all egress ENNI Frames mapped to the given VUNI
End Point MUST have the property defined in 7.6.3 of [MEF 26].
[R26] When an Egress Bandwidth Profile per VUNI is in force, egress ENNI Frames
mapped to the VUNI End Point of the VUNI MUST NOT be subjected to any
other type of egress bandwidth profile.
The Egress Bandwidth Profile per VUNI, when present, manages bandwidth non-discriminately
for all OVCs supported by the VUNI. Therefore, some OVCs may get more bandwidth while
others may get less.
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page 17
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface Support for UTA and VUNI
7.4.3 Ingress Bandwidth Profile per OVC End Point associated by a VUNI Service
Attribute
The Ingress Bandwidth Profile per OVC End Point associated by a VUNI describes ingress
policing by the VUNI Provider MEN on all ingress ENNI Frames mapped to a given OVC End
Point associated by a VUNI.
[R27] When the Ingress Bandwidth Profile per OVC End Point associated by a
VUNI is in force for a given OVC End Point, suitable parameters <CIR, CBS,
EIR, EBS, CF, CM> as defined in Section 7.6.1 of [MEF 26] MUST be
specified and the algorithm of Section 7.6.1 of [MEF 26] MUST be applied to
all ingress ENNI Frames that are mapped to the given OVC End Point.
7.4.4 Ingress Bandwidth Profile per Class of Service Identifier per OVC End Point
associated by a VUNI Service Attribute
The Ingress Bandwidth Profile per Class of Service Identifier per OVC End Point associated by a
VUNI describes ingress policing by the VUNI Provider MEN on all ingress ENNI Frames with a
given Class of Service Identifier mapped to the OVC End Point associated by a VUNI.
[R28] When the Ingress Bandwidth Profile per Class of Service Identifier per OVC
End Point associated by a VUNI is in force, suitable parameters <CIR, CBS,
EIR, EBS, CF, CM> as defined in Section 7.6.1 of [MEF 26] MUST be
specified and the algorithm of Section 7.6.1 of [MEF 26] MUST be applied to
all ingress ENNI Frames mapped to the OVC End Point that have the given
Class of Service Identifier.
7.4.5 Egress Bandwidth Profile per OVC End Point associated by a VUNI Service
Attribute
The Egress Bandwidth Profile per OVC End Point associated by a VUNI describes egress
shaping by the VUNI Provider MEN on all egress ENNI Frames mapped to a given OVC End
Point associated by a VUNI.
[R29] When the Egress Bandwidth Profile per OVC End Point associated by a
VUNI is in force for a given OVC End Point, suitable parameters <CIR, CBS,
EIR, EBS, CF, CM> as defined in Section 7.6.1 of [MEF 26] MUST be
specified and all egress ENNI Frames mapped to the given OVC End Point
MUST have the property defined in 7.6.3 of [MEF 26].
7.4.6 Egress Bandwidth Profile per Class of Service Identifier per OVC End Point
associated by a VUNI Service Attribute
The Egress Bandwidth Profile per Class of Service Identifier per OVC End Point associated by a
VUNI describes egress shaping by the VUNI Provider MEN on all egress ENNI Frames with a
given Class of Service Identifier mapped to the OVC End Point associated by a VUNI.
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page 18
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface Support for UTA and VUNI
[R30] When the Egress Bandwidth Profile per Class of Service Identifier per OVC
End Point associated by a VUNI is in force, suitable parameters <CIR, CBS,
EIR, EBS, CF, CM> as defined in Section 7.6.1 of [MEF 26] MUST be
specified and all egress ENNI Frames mapped to the given OVC End Point
that have the Class of Service Identifier MUST have the property defined in
7.6.3 of [MEF 26].
[R31] When CM = "Color-Aware", the color marking for the ENNI frame MUST be
based on the C-Tag PCP or the DSCP as mandated in [MEF 23] for the M and
L CoS labels.
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page 19
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface Support for UTA and VUNI
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 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 6 shows how the UTA and a VUNI may be employed to instantiate the services in Figure
5. Note that the remote UNI A OVC End Point Map Service Attribute maps all CE-VLAN ID
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page 20
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface Support for UTA and VUNI
values to the OVC End Point (see Table 3), and the end point mapping at the VUNI associates
the C-VIDs with the OVCs supporting the Subscriber EVCs (see Table 8).
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page 21
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface Support for UTA and VUNI
This technical specification presented the base concepts behind the UTA model as applicable to
tunnels that traverse a single Network Operator. This appendix illustrates how the UNI tunnel
access model may be generalized to multi-MEN scenarios. Figure 7 provides a model showing
the context for the UTA among two Network Operators and the VUNI Provider. (See 802.1Qbc
for more details.)
UTA
VUNI / RUNI Service
Association Components
CE
UNI W
Virtual Remote
UNI Network Network UNI
Operator B Operator A
VUNI
Provider
CE
(Network Operator C) Tunnel Extension OVC UTA OVC
ENNI UNI Y
ENNI
UNI X CB BA
VUNI OVC CB OVC CB OVC BA OVC BA
CE End Point End Point End Point End Point End Point
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.
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page 22
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface Support for UTA and VUNI
Note that this extension to the UTA model will work well in conjunction with future definitions
of ENNI-to-ENNI OVC Services.
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page 23
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface Support for UTA and VUNI
C-VLAN component: A VLAN-aware bridge component that can recognize, insert, and remove
Customer VLAN tags.
S-VLAN component: A VLAN-aware bridge component that can recognize, insert, and remove
Service VLAN tags.
The example described in this section uses a C-VLAN component per Remote UNI. Figure 9
models the functions of an interface realizing the data path ENNI-N and VUNI functions.
Operator Edge Device Blocked Port Untagged and C-TAG only frames
S-Bridge or
MPLS or other C-Component S-Component
One physical link
SVLAN or Label 1 SVLAN-1
SVLAN or Label 2
or bundle
To Physical ports or switching fabric
VUNIB
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:
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page 24
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface Support for UTA and VUNI
An ENNI frame is received at the ENNI from the Network Operator that supports the UTA
OVC. If it is untagged, it is not mapped to a VUNI End Point (or OVC End Point). If there is an
S-TAG, the S-VLAN component maps the frame to the corresponding VUNI End Point based on
the S-VLAN ID value and removes the S-TAG.
The frame is sent to a C-VLAN component associated with the VUNI End Point. The C-VLAN
component will map the frame to one of its 4094 virtual ports based on the C-VLAN ID value.
The frame is received at the OVC End Point associated with the C-VLAN component virtual
port by an entity which performs further encapsulation. The nature of this encapsulation is
dependent on the VUNI Provider MEN and is out of the scope of this specification.
A frame associated with an OVC in the VUNI Provider MEN is received at an OVC End Point
associated by a VUNI. The frame is stripped of the overhead used internally in the VUNI
Provider MEN to identify the OVC End Point.16
The frame is received by C-VLAN Component which maps all the frames to the port connected
to its VUNI End Point.
The frame is sent to the S-VLAN Component which adds the S-TAG and sends the now
complete ENNI frame to the Network Operator MEN.
Note that a C-VLAN component is required to process L2CP PDUs according to the IEEE
802.1Q specifications.
16
It is assumed the VUNI Provider does not transport Service Frames natively in its MEN without encapsulating
them further in order to segregate the traffic from various OVCs.
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page 25
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
External Network Network Interface Support for UTA and VUNI
11 References
[MEF 10.2] Metro Ethernet Forum, MEF 10.2, Ethernet Services Attributes Phase 2,
October 2009.
[MEF 23] Metro Ethernet Forum, MEF 23, Metro Ethernet Forum, Implementation
Agreement: Carrier Ethernet Class of Service Phase 1, June 2009.
[MEF 26] Metro Ethernet Forum, MEF 26, External Network Network Interface (ENNI)
Phase 1, January 2010.
[IEEE P802.1Qbc] IEEE Draft Standard 802.1Qbc/D1.1 Virtual Bridged Local Area
Network Amendment: Provider Bridging Remote Customer Service
Interfaces, Draft 1.1, February 2010.
MEF 28 The Metro Ethernet Forum 2011. Any reproduction of this document, or any portion thereof, shall Page 26
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Embedded Secure Document
The file http://metroethernetforum.org/PDF_Documents/Introduction-to-CESoE.pdf is a secure document
that has been embedded in this document. Double click the pushpin to view.
Home About Contact
When connecting network elements in order to create a network, it is 9.1.1 What is CESoETH
common practice to consider and provision for various failures. Ideally, the 9.1.2 MEF 8 model
traffic should continue to flow even if a failure of a link or a port occurred. < br/>
< br/>
9.3.1 E-Line
9.3.2 UNI Attributes
Port protection 9.3.3 EVC Attributes
We focus our discussion on external Interfaces (UNI or ENNI). MEF 20 defined 9.3.4 EVC per UNI Attributes
as mandatory feature ofUNI type 2.2 the capability to protect against a UNI-N < br/>
port failure and / or protecting against a failure of a physical link crossing the
9.4 Synchronization
UNI point.
9.4.1 Packet Based
Synchronization Methods
UNI protection is depicted in the following figure:
9.4.1.1 Adaptive Clock Recovery
Figure: UNI Protection
9.4.1.2 NTP
ENNI protectionis depicted in the following figure: 9.4.1.3 1588 v2
It should be noted that some vendors do allow LAG between different line- Download PDF
cards or chassis and thus utilize LAG not only for port & link protection but
also for NE protection. However, there is no industry standard for this
solution. Download a pdf for
offline viewing.
Service protection
Service Protection deals with the need to ensure that the EVC / OVC can carry
provide the service even if specific link or node within the CEN fails.
Reference Documents
Figure: Active StandbyEVC
MEF 8
MEF 22.1
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Home About Contact
10.3.1 Definition
For a Rooted-Multipoint EVC, S must be such that all ordered pairs in S
contain at least one UNI that is designated as a Root. This is required since 10.3.2 Procedures
two leaf UNIs cannot communicate with each other. For each UNI pair within 10.3.2.1 Continuity Check
the sub-set S, the procedures are carried out and summarized every time Message
10.4.1 Definition
10.4.2 Procedures
10.4.3.3 Availability
< br/>
< br/>
Download PDF
Reference Documents
MEF 10.2
MEF 17
ITU-T Y.1731
10 Service OAM
Send Feedback
Name:
Email:
Comments
Send Feedback
Copyright 2011-2012 Metro Ethernet Forum Disclaimer Copyright 2011-2012 Ethernet Academy
Technical Specification
MEF 17
April 2007
MEF 17 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Disclaimer
The information in this publication is freely available for reproduction and use by any recipient
and is believed to be accurate as of its publication date. Such information is subject to change
without notice and the Metro Ethernet Forum (MEF) is not responsible for any errors. The MEF
does not assume responsibility to update or correct any information in this publication. No re-
presentation or warranty, expressed or implied, is made by the MEF concerning the complete-
ness, accuracy, or applicability of any information contained herein and no liability of any kind
shall be assumed by the MEF as a result of reliance upon such information.
The information contained herein is intended to be used without modification by the recipient or
user of this document. The MEF is not responsible or liable for any modifications to this docu-
ment made by any other party.
The receipt or any use of this document or its contents does not in any way create, by implication
or otherwise:
any express or implied license or right to or under any patent, copyright, trademark or trade se-
cret rights held or claimed by any MEF member company which are or may be associated with
the ideas, techniques, concepts or expressions contained herein; nor
any warranty or representation that any MEF member companies will announce any product(s)
and/or service(s) related thereto, or if such announcements are made, that such announced prod-
uct(s) and/or service(s) embody any or all of the ideas, technologies, or concepts contained here-
in; nor
any form of relationship between any MEF member companies and the recipient or user of this
document.
Implementation or use of specific Metro Ethernet standards or recommendations and MEF speci-
fications will be voluntary, and no company shall be obliged to implement them by virtue of par-
ticipation in the Metro Ethernet Forum. The MEF is a non-profit international organization acce-
lerating industry cooperation on Metro Ethernet technology. The MEF does not, expressly or
otherwise, endorse or promote any specific products or services.
MEF 17 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Service OAM Requirements & Framework
Table of Contents
1. Abstract ................................................................................................................................ 3
2. Terminology......................................................................................................................... 3
3. Scope..................................................................................................................................... 4
5. Introduction ......................................................................................................................... 5
List of Figures
Figure 1: MEN External Interfaces & Associated Reference Points .............................................. 5
Figure 2: MEN Layer Network Model ........................................................................................... 6
Figure 3: Generic Reference Model for Network/Service Management ........................................ 6
Figure 4: ETH Layer Interfaces and Reference Points ................................................................... 7
MEF 17 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 1
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Service OAM Requirements & Framework
MEF 17 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 2
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Service OAM Requirements & Framework
1. Abstract
OAM (Operations, Administration and Maintenance) can be used to manage network infrastruc-
tures and services provided across these network infrastructures. This document provides re-
quirements and framework for Service OAM within MEF compliant Metro Ethernet Networks
(MENs). Service OAM requirements represent expectations of Service Providers in managing
Ethernet Services within the MENs and Subscribers in managing Ethernet Services across the
MENs. Service OAM framework describes the high-level constructs used to model different
MEN and Service components that are relevant for OAM. The framework also describes the re-
lationship between Service OAM and the architectural constructs of Ethernet Services (ETH),
Transport Service (TRAN) and Application Service (APP) Layers as identified in [MEF 4].
2. Terminology
Term Definition
APP Application Layer
CLE Customer Located Equipment
COS Class of Service
CPE Customer Premise Equipment
E-LMI Ethernet Link Management Interface
EMS Element Management System
E-NNI External NNI
EoSONET Ethernet over SONET
ESCF Ethernet Subscriber Conditioning Function
ETH Ethernet Services Layer
EVC Ethernet Virtual Connection
FDV Frame Delay Variation
FLR Frame Loss Ratio
I-NNI Internal NNI
LANE ATM LAN Emulation
MAC Media Access Control
ME Maintenance Entity
MEG Maintenance Entity Group
MEN Metro Ethernet Networks
MEP MEG End Point
MIP MEG Intermediate Point
MPLS Multi-Protocol Label Switching
NDD Network Demarcation Device
NE Network Element
NI-NNI Network Interworking NNI
NMS Network Management System
NNI Network-Network Interface
OAM Operations, Administration and Maintenance
PW Pseudo Wire
MEF 17 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 3
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Service OAM Requirements & Framework
Term Definition
SI-NNI Service Interworking NNI
SLA Service Level Agreement
SLS Service Level Specification
SNI Service Node Interface
TRAN Transport Layer
TrCP Traffic Conditioning Point
UNI User-Network Interface
VPLS Virtual Private LAN Service
VPLS Virtual Private LAN Service
VPWS Virtual Private Wire Service
xSTP Spanning Tree Protocol (multiple variations)
3. Scope
The scope of this document is to provide requirements to be satisfied by the Service OAM me-
chanisms in MENs and to provide a framework for discussing and implementing those mechan-
isms. Provisioning aspects of the Ethernet Services and MENs are not considered in this docu-
ment. Also, this document is limited to specifying requirements and framework for OAM me-
chanisms among MEN network elements functioning at ETH Layer and does not account for
OAM interface between MEN network elements and NMS/EMS systems.
The specific functional areas of Services OAM addressed by this document include:
Fault Management (including detection, verification, localization and notification)
Performance Monitoring (including performance parameters measurements)
Auto-discovery (including discovering service aware NE within provider networks)
Intra-provider and inter-provider Service OAM
Service OAM mechanisms include support for OAM across a specific Class of Service (CoS)
instances when multiple CoS instances are supported within an Ethernet service and need to be
managed individually, specifically for the purposes of performance monitoring.
Detailed specifications of OAM mechanisms and/or protocols are outside the scope of this doc-
ument.
4. Compliance Levels
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. All key words must be in upper case,
bold text.
MEF 17 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 4
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Service OAM Requirements & Framework
5. Introduction
[MEF 4] introduces relevant interfaces and reference points that apply to Metro Ethernet Net-
works (MENs), as shown in Figure 1. Subscribers connect to MEN across a User-to-Network
Interface (UNI). Network Elements (NEs) inside MEN are interconnected via Internal Network-
to-Network Interfaces (NNIs) (I-NNIs-not shown in Figure 1). Two autonomous MENs may in-
terconnect at an External NNI (E-NNI). MENs may also interconnect with other transport net-
works via Network Interworking NNI (NI-NNI) or with other service networks via Service In-
terworking NNI (SI-NNI). Figure 5 uses relevant reference points to highlight Service OAM ap-
plicability.
Other L2/L2+
Services Networks
Subscriber
(e.g., ATM, FR, IP)
Service UNI
Interworking
NNI
MEN
UNI
Metro Service Provider Z1
Ethernet Network External
Subscriber (MEN) NNI External
NNI
Service Provider X Ethernet
Wide Area Network MEN
Network (E-WAN)
Interworking Service Provider Z2
Service Provider Y
NNI
Other L1
Transport Networks UNI
(e.g., SONET, SDH, OTN)
Subscriber
Network
Interworking
NNI
MEN
Service Provider X
Figure 2 introduces the MEN layered network model with the data, control and management
planes. These planes may be present for all three Layers of this model, namely Transport Service
Layer (TRAN Layer), Ethernet Service Layer (ETH Layer) and Application Service Layer (APP
Layer). This document focuses on the management plane of the Ethernet Services Layer.
MEF 17 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 5
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Service OAM Requirements & Framework
Figure 3 highlights a typical arrangement applied by Service Providers to manage their networks
and services offered across these networks. The focus of this document is to address the require-
ments and framework for Service OAM across the NEs. Network/service management using the
NMS-EMS management interface is addressed in [MEF 7] and NE management requirements
are provided in [MEF 15].
NMS
Environment
EMS-NMS Interface
EMS EMS
EMS-NE Interface
NE NE NE NE NE NE
MEF 17 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 6
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Service OAM Requirements & Framework
Subscriber
MEN Site B
Service
UNI-N
UNI-C
ETH
ETH
Subscriber Provider
X
Site A UNI
UNI
UNI-C
UNI-N
ETH
ETH
E-NNI
MEN
E-NNI
E-NNI
ETH
ETH
Service
Provider Subscriber
Y UNI Site C
UNI-N
UNI-C
ETH
ETH
Ethernet Services Layer
From the perspective of the ETH Layer OAM, only those components related to Ethernet ser-
vice-aware functions are relevant. An EVC is a logical construct in the ETH Layer which is used
to enable end-to-end Subscriber service instances across one or more MEN Service Providers
[MEF 12]. Section 8 introduces Maintenance Entity Groups (MEGs) across the Subscriber and
Service Provider networks, with specific focus on Service Provider MEGs that need to be ma-
naged via Services OAM.
7. OAM Domains
An OAM Domain is defined as a network or sub-network, operating at the ETH Layer and be-
longing to the same administrative entity, within which OAM frames can be exchanged.
Each Service Provider and/or Operator network is typically associated with an administrative
boundary. A service may be realized across a single or multiple (sub) network(s). An OAM Do-
main determines the span of an OAM flow across such administration boundaries. OAM Do-
mains can be hierarchical but must not partially overlap. This hierarchical view of OAM Do-
mains allows the following business relationships and accountability. The OAM Framework as
proposed in this document does not address overlapping OAM Domains.
A Subscriber OAM Domain may completely overlap multiple Service Providers OAM Domains
such that Service Providers OAM Domains remain transparent to Subscribers OAM Domain.
MEF 17 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 7
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Service OAM Requirements & Framework
A Service Provider OAM Domain may completely overlap multiple Network Operators OAM
Domains such that Network Operators OAM Domains remain transparent to Service Providers
OAM Domain.
8. OAM Components
Figure 5 highlights MEs typically involved in different OAM domains. These MEs correspond
purely to the ETH Layer. A ME is essentially an association between two maintenance end
points within an OAM Domain; where each maintenance end point corresponds to a provisioned
reference point that requires management.
The Subscriber OAM Domain consists of the ME marked Subscriber ME. The Service Pro-
vider OAM Domains consists of the ME marked EVC ME. If UNI between Subscriber and
Service Provider needs to be managed, a UNI ME can be realized as shown in the figure. If the
Service Provider utilizes facilities of two different Network Operators, each Network Operator
OAM Domain could consist of MEs marked as Operator A ME and Operator B ME. Simi-
larly, if the NNI between Network Operators needs to be managed, a NNI ME can be realized.
For the purposes of Service OAM, the focus of this framework is on UNI MEs, EVC MEs, and
Subscriber MEs that are associated with services. Other MEs shown in Figure 5 are outside the
scope of this document.
Note: Service OAM framework and requirements associated with E-NNI MEs, SNI MEs, etc. are
expected to be covered in future versions of this document.
Subscriber Subscriber
Equipment Operator A NEs Service Provider Operator B NEs Equipment
1 2 3 4 5 6 7 8
Subscriber ME
TrCP TrCP
ETH EVC ME
Operator A ME Operator B ME
UNI ME NNI ME UNI ME
TRAN
MEF 17 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 8
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Service OAM Requirements & Framework
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.
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.
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.
MEF 17 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 9
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Service OAM Requirements & Framework
When Subscriber, Service Providers, and Network Operators share the MEG Levels space, allo-
cation of MEG Levels can be negotiated among the different roles involved. A default allocation
of MEG Levels is such that Service OAM frames for a Subscriber ME use MEG Level 7, 6 or 5;
Service OAM frames for an EVC ME use MEG Level 3 or 4 as EVC ME belongs to a Service
Provider OAM Domain; and Operator MEs use MEG Levels 2, 1, or 0. The MEG Levels used
for UNI ME and NNI ME will default to 0. It may be noted that this default allocation of MEG
Level space between Subscribers, Service Providers and Operators could change based on a mu-
tual agreement among them.
Specific MEG Level assignments are outside the scope of this document.
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.
The following requirements are specifically stated for EVC MEGs and/or EVC MEs, as applica-
ble.
Note: Though requirements are stated specifically for EVC MEGs and/or EVC MEs, these are
also generally applicable to Subscriber MEGs and/or Subscriber MEs. Though requirements are
stated specifically for EVC MEGs and/or EVC MEs, these are also generally applicable to Sub-
scriber MEGs and/or Subscriber MEs and UNI MEs. Requirements applicable to UNI MEs are
for further study.
9.1 Discovery
Discovery allows a Service OAM capable NE to learn sufficient information (e.g. MAC ad-
dresses etc.) regarding other Service OAM capable NEs so that OAM frames can be exchanged
with those discovered NEs.
In context of EVCs, discovery allows Service OAM capable NEs to learn about other Service
OAM capable NEs that support the same EVCs. These NEs are expected to be at the edges of an
OAM domain within which the discovery is carried out.
MEF 17 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 10
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Service OAM Requirements & Framework
(R1) Service OAM MUST offer the capability for a service aware NE to discover other service-
aware NEs supporting the same EVC inside a Service Provider OAM Domain.
9.2 Connectivity
A ME can have the following Connectivity Status values:
Active: A ME Connectivity Status of active implies that Service OAM frames can be ex-
changed between the MEPs in both directions.
Not Active: A ME Connectivity Status of not active implies that Service OAM frames
cannot be exchanged in both directions between the MEPs of the ME.
(R2a) Service OAM MUST offer the capability to monitor the Connectivity Status of a ME.
(R2b) Service OAM MUST offer the capability to monitor the Connectivity Status of a MEG.
(R2c) Service OAM SHOULD offer the capability to detect a change in Connectivity Status
within a configurable time interval. This configurable time interval SHOULD be more than the
network restoration time, which is dependent on the MEN technology.
As an example of R2c, if a MEN is based on bridging technology and xSTP is used for network
restoration, then the configurable time interval for Connectivity Status monitoring of a ME or a
MEG ought to be more than the xSTP restoration time intervals.
Further, when a Connectivity Status becomes not active or partially active, it may be necessary
to verify and localize the fault. This is needed primarily to reduce operating costs by minimising
operational repair times and operational resources.
(R2d) Service OAM MUST offer the capability to verify the existence of a connectivity fault
inside a Service Provider OAM Domain.
(R2e) Service OAM MUST offer the capability to localize a connectivity fault inside a Service
Provider OAM Domain. Localization is expected to identify the MEP and MIP, or pair of MIPs,
in the Service Provider OAM Domain between which the EVC connectivity fault is present.
The determination of EVC status, as defined in [E-LMI], requires determination of the EVC
ME/MEG Connectivity Status and UNI ME/MEG Connectivity Status. Specific mechanisms
used to correlate the different Connectivity Status values are outside the scope of this document.
MEF 17 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 11
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Service OAM Requirements & Framework
(R2f) Service OAM frames for connectivity SHOULD be transmitted at the highest priority
permissible for the Service frames. This requirement is meant to ensure that Service OAM
frames for connectivity are less likely to be discarded in comparison to the Service frames upon
congestion.
(R2g) Service OAM SHOULD offer the capability to transmit Service OAM frames at any per-
missible priority.
The MEP Connectivity Status for a MEP in a Multipoint-to-Multipoint MEG can have one the
following values:
Fully Connected: A MEP Connectivity Status of fully connected implies that all MEs to
which the MEP belongs are active.
Isolated: A MEG Connectivity Status of isolated implies that all MEs to which the MEP
belongs are not active.
Partially Connected: A MEP Connectivity Status of partially connected implies that,
among all MEs to which the MEP belongs, at least one is active and at least one is not ac-
tive.
(R2h) Service OAM SHOULD offer capability to monitor the MEP Connectivity Status in a
Multipoint-to-Multipoint MEG.
(R2i) Service OAM SHOULD offer capability to detect a change in the MEP Connectivity Sta-
tus within a configurable time interval. This configurable time interval SHOULD be more than
the network restoration time interval, which is dependent MEN technology.
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.
(R3a) Service OAM MUST offer capability to estimate Frame Loss for Service Frames with the
level of Bandwidth Profile conformance determined to be Green and associated with a particular
CoS instance between the UNIs of a Point-to-Point EVC during a time interval T inside a Service
Provider OAM Domain. The level of accuracy is for further study.
MEF 17 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 12
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Service OAM Requirements & Framework
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.
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.
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.
(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.
(R7a) In hierarchical OAM Domains, Service OAM MUST offer the capability to prevent OAM
frames belonging to lower OAM Domain from leaking into higher OAM Domain.
MEF 17 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 14
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Service OAM Requirements & Framework
(R7b) In hierarchical OAM Domains, Service OAM MUST offer the capability to transparently
carry OAM frames belonging to higher OAM Domain across lower OAM Domain.
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.
(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 17 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 15
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Service OAM Requirements & Framework
[MEF 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.
[Y.1731] OAM Functions and Mechanisms for Ethernet based networks, May 2006.
MEF 17 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 16
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Service OAM Requirements & Framework
ETH
Layer Services Service OAM
Figure 6 highlights the two MEN Layers (i.e. ETH Layer and TRAN Layer) with the correspond-
ing OAM components belonging to Ethernet services and underlying networks. ETH Layer
represents services and is responsible for Service OAM. Ethernet services are carried across sin-
gle or multi-hop Ethernet networks represented by bridged network under TRAN Layer. The
NEs constituting the bridged networks are in turn connecting with transport links e.g. IEEE
802.3 compliant link, Ethernet PW, VPLS, EoSONET, etc.
The Service OAM work in MEF focuses on the ETH Layer, which corresponds to an EVC inside
a Service Provider OAM Domain. Besides MEF, ITU-T Q.5/13 and IEEE 802.1 are also working
on Ethernet OAM in Y.1731 and 802.1ag draft Recommendations respectively. The work in
ITU-T Q.5/13 and IEEE 802.1 is applicable to Subscriber, Service Provider and Network Opera-
tor OAM Domains.
ITU-T Q.5/13 and IEEE 802.1 work is not limited to Service OAM as it also covers Network
OAM for Ethernet based networks. IEEE 802.1ag focuses on a sub-set of Fault Management for
both enterprise and carrier networks. ITU-T Y.1731 accounts for both Fault Management and
Performance Monitoring specifically for carrier networks. ITU-T Q.5/13 and IEEE 802.1 Ether-
net OAM work is closely aligned to avoid duplication.
MEF 17 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 17
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Service OAM Requirements & Framework
Based on the transport link technology used to connect the NEs supporting bridging functionality
within Ethernet bridged networks, various link OAM techniques can be applied across the TRAN
Layer. E.g. IEEE 802.3ah has defined link level OAM for IEEE 802.3 compliant links. When
transport link emulates Ethernet over MPLS/IP as in IETF VPWS and VPLS, IETFs PW-OAM
and VPLS-OAM and ITU-T Y.1711 kind mechanisms can be applied to manage those emulated
transport links. If SONET/SDH technology is applied, OAM techniques being defined in ITU-T
Q.12/15 can be applied.
MEF 17 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 18
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of
this document is authorized to modify any of the information contained herein.
Technical Specification
MEF 18
May 2007
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 1
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
Disclaimer
The information in this publication is freely available for reproduction and use by any recipient and is believed to be
accurate as of its publication date. Such information is subject to change without notice and the Metro Ethernet
Forum (MEF) is not responsible for any errors. The MEF does not assume responsibility to update or correct any
information in this publication. No representation or warranty, expressed or implied, is made by the MEF
concerning the completeness, accuracy, or applicability of any information contained herein and no liability of any
kind shall be assumed by the MEF as a result of reliance upon such information.
The information contained herein is intended to be used without modification by the recipient or user of this
document. The MEF is not responsible or liable for any modifications to this document made by any other party.
The receipt or any use of this document or its contents does not in any way create, by implication or otherwise:
(a) any express or implied license or right to or under any patent, copyright, trademark or trade secret rights
held or claimed by any MEF member company which are or may be associated with the ideas,
techniques, concepts or expressions contained herein; nor
(b) any warranty or representation that any MEF member companies will announce any product(s) and/or
service(s) related thereto, or if such announcements are made, that such announced product(s) and/or
service(s) embody any or all of the ideas, technologies, or concepts contained herein; nor
(c) any form of relationship between any MEF member companies and the recipient or user of this
document.
Implementation or use of specific Metro Ethernet standards or recommendations and MEF specifications will be
voluntary, and no company shall be obliged to implement them by virtue of participation in the Metro Ethernet
Forum. The MEF is a non-profit international organization accelerating industry cooperation on Metro Ethernet
technology. The MEF does not, expressly or otherwise, endorse or promote any specific products or services.
The Metro Ethernet Forum 2007. All Rights Reserved.
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 2
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
Table of Contents
1. ABSTRACT ......................................................................................................................................................... 5
2. TERMINOLOGY ................................................................................................................................................ 5
3. SCOPE .................................................................................................................................................................. 5
9. REFERENCES .................................................................................................................................................. 35
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 3
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
List of Figures
Figure 5-1: MEF8 Operating Modes .............................................................................................................................6
Figure 5-2: Generic Test Bed 1 .....................................................................................................................................7
Figure 5-3: Generic Test Bed 2 .....................................................................................................................................8
List of Tables
Table 2-1: Terms and Abbreviations .............................................................................................................................5
Table 8-1: Requirement Status and Test Summary ..................................................................................................... 35
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 4
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
1. Abstract
This document describes a set of test procedures for evaluating the conformance of equipment for delivering Circuit
Emulation Services over Ethernet (CESoETH) to the MEF 8 Implementation Agreement.
2. Terminology
This document uses the terms defined in MEF8, plus the following additional terms:
Term Definition
DUT Device Under Test
MRTIE Maximum Relative Time Interval Error
PRBS Pseudo-Random Binary Sequence
3. Scope
The scope of this document is limited to the description of testing procedures for pass/fail assessment of
conformance with each of the operating modes in MEF 8. Conformance with MEF 8 should be viewed as a pre-
requisite for any interoperability testing. This document does not cover either interoperability tests or performance
evaluation.
4. Compliance Levels
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD
NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in
[RFC 2119]. All key words must be used in upper case, bold text.
The following convention is used to identify tests:
<doc reference>.Rn-Rp (e.g. MEF8.R1-R3) Test covers all requirements from Rn to Rp inclusive
<doc reference>.Rn,Rp (e.g. MEF8.R1,R3) Test covers only the requirements Rn and Rp, not those in-between
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 5
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
5. Testing Framework
5.1 MEF 8 CONFORMANCE
MEF 8 describes several operating modes for the implementation of CESoETH. Figure 5-1 shows these modes
using a tree diagram (section numbers given are from MEF 8). Only one mode is mandatory to claim conformance
with MEF 8, structure-agnostic emulation using a raw (i.e. non-octet-aligned) encapsulation. Several optional
operating modes are described in MEF 8, e.g. structure-aware emulation modes, and different signaling types.
Within each operating mode, a number of requirements are defined. Some of these requirements are mandatory (as
indicated by the key words MUST or SHALL), and some are optional (as indicated by the key words
SHOULD, MAY or OPTIONAL). There are three categories of requirements for MEF8 compliance:
Mandatory the mandatory requirements for the mandatory structure-agnostic emulation mode. These
requirements must be met to claim MEF 8 conformance.
Dependent the mandatory requirements for the optional modes. These requirements must be met to claim
MEF 8 conformance for those optional modes (i.e. their status is dependent on whether the
relevant operating mode is supported).
Optional these requirements describe permitted options. These requirements do not have to be met to
claim MEF 8 conformance.
Table 8-1 in section 8 lists each of the MEF 8 requirements, together with its category and the reference of the test
used to verify it. This specification defines tests for all the mandatory requirements in section 6, and dependent
requirements in section 7.
Embedded CAS
Structure-aware Mandatory for
Basic service structure-indicated
encapsulation mode
Basic service with
Structure-indicated
(section 6.3.3) separate signaling
(section 6.5)
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 6
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 7
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
Mgmt.
Station
Mgmt. Mgmt.
Interface Interface
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 8
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 9
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 10
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 11
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 12
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 13
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
Test Procedure TDM testers generate framed or unframed TDM circuit for emulation by the CESoETH IWFs.
Circuits to contain a standard 220-1 PRBS pattern 1 (as defined in O.150) to enable data integrity
verification.
Ethernet sniffer is used to monitor the CESoETH service frames flowing in both directions,
allowing verification that data frames contain the correct number of octets as defined in R31 for
both directions, and that the number of octets in payload does not change for the whole test
sequence.
TDM testers check the received PRBS pattern to verify correct payload transport from end-to-end
in both directions. Since this is a clean laboratory environment with no impairments applied,
there should be zero bit errors detected over a test lasting between ten and thirty minutes.
Repeat for different circuit types as appropriate for DUTs.
Units Payload size in octets
Bit Error Rate expressed as number of errored bits received/total number of bits received
Variables Type of TDM circuit (framed, unframed, DS1, E1, DS3, E3)
Results Pass or Fail
Remarks
1
The PRBS sequence length was chosen to be much larger than the packet length (2048 bits for a standard E1
circuit, 8192 bits for E3 or DS3). 220-1 is often used for error rate testing in PDH circuits, and is at least 128 times
longer than the longest packet. However it is short enough to allow the test procedure to be carried out in a
reasonable time frame, without waiting too long for the test analyzer to lock onto the sequence.
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 14
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
6.3 SYNCHRONISATION
This section describes the testing of the synchronisation requirements, as described in MEF 8, Section 6.4. It covers
requirements R47 and R48.
1
Since MEF8 was introduced in 2004, ITU-T recommendation G.8261 has been released (May 2006), specifying
tighter limits for the network wander allowed in circuit emulated segments of a TDM transmission path. However,
until MEF8 is formally changed, these tighter limits cannot be used for determining compliance with MEF8.
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 15
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
Test Procedure Follow selected test procedures as defined in [G.8261], Appendix VI.2, using Network Traffic
Model 2 only (see section VI.2.2.1.2 of G.8261 - this is closer to the expected traffic mix in a
general Metro Ethernet Network).
For each test, verify that the MRTIE (or MTIE as appropriate) is within G.823/G.824 traffic
interface mask over duration of tests. 1
Test Case 6a: Static Load Test/Sudden Changes in Network Load
Follow Test Case 2 defined in section V1.2.2.3 of G.8261, using Network Traffic Model 2.
Note that this will also cover the Static Load Test defined in Test Case 1 (section VI.2.2.2
of G.8261)
Test Case 6b: Slow Variation of Network Load
Follow Test Case 3 defined in section V1.2.2.4 of G.8261, using Network Traffic Model 2.
Test Case 6c: Temporary Network Outages
Follow Test Case 4 defined in section V1.2.2.5 of G.8261, using Network Traffic Model 2,
with network interruptions of 10 and 100s. This test should be repeated 10 times to verify
that the results are consistent.
Test Case 6d: Temporary Congestion
Follow Test Case 5 defined in section V1.2.2.6 of G.8261, using Network Traffic Model 2.
with network congestion periods of 10 and 100s. This test should be repeated 10 times to
verify that the results are consistent.
Test Case 6e: Routing Changes
Follow Test Case 6 defined in section V1.2.2.7 of G.8261, using Network Traffic Model 2.
Test Case 6f: Wander tolerance
Using the same network configuration as the previous tests but with no network load, apply
maximum input jitter and wander, as specified in G.823/G.824 to verify input jitter and
wander tolerance.
A standard 220-1 PRBS pattern (as defined in O.150) should be applied end-to-end during the
wander tolerance test to check data integrity (i.e. slips or bit errors) as stated in G.823/G.824.
Units MTIE measurement in s. Jitter measurement in ns.
Variables Type of circuit (DS1, E1, DS3 or E3) as supported by DUT.
Results Pass or Fail
Remarks
1
The tests should also verify compliance with the G.8261 masks for completeness, although these limits cannot be
used for determining compliance to MEF8.
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 16
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
6.4.1 Misconnection
ABSTRACT TEST CASES FOR CESoETH IMPLEMENTATION AGREEMENT
Test Name Test Case 7: Effect of Stray Frames.
Test Definition MEF8.R57,R60
ID
Reference MEF 8
document
Test Type Conformance
Test Status Mandatory
Requirement R57. The CES IWF MUST only accept frames that contain the correct Ethernet destination
Description address field and ECID value for that IWF.
R60. When a stray frame 1 is detected by a Circuit Emulation Inter-working Function (CES
IWF), it MUST be discarded.
Test Object Verify that only genuine CESoETH frames are accepted by the CES IWF, and that all stray
frames are discarded.
Test-Bed Generic Test Bed 2 as shown in Figure 5-3. Network emulator must have the ability to inject stray
Configuration frames into the data stream (it could be replaced by a CESoETH frame generator and L2 switch if
preferred).
Configure the CESoETH IWFs for structure-agnostic emulation of DS1, E1, DS3 or E3 circuits,
and the TDM tester to generate a standard 220-1 PRBS sequence (as defined in O.150).
Test Procedure TDM tester generates a PRBS sequence to verify data integrity throughout the test. Network
emulator injects stray frames into the Ethernet data stream containing a known data pattern (e.g.
all-ones, alternating one/zero, all-zeroes).
If IWF accepts a stray frame, this will cause bit errors in the TDM output which will be detected
by the TDM tester. If no errors are detected in the TDM output, all stray frames must have been
detected and discarded.
If the IWF supports a count of stray frames detected (not a mandatory feature in MEF8), this
should be compared against the number of stray frames generated by the network emulator.
Units Number of stray frames detected,
Bit Error Rate expressed as number of errored bits received/total number of bits received
Variables
Results Pass or Fail.
Remarks
1
A CESoETH frame where the source and/or destination MAC addresses do not agree with the values expected for
that ECID.
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 17
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 18
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 19
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 20
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 21
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
Test Procedure See Remarks at the bottom of the table for some details/explanations.
Ethernet Frame Generator produces a valid structure-agnostic CES stream with the normal
payload size towards the DUT at a default frames rate. The payload of the CES stream should
contain a predefined pattern (e.g. a 32 bits automatically incremented counter). The DUT will
send back the payload received from the IWF due to the external TDM loopback.
Ethernet Analyzer captures the received data, and verifies that it receives back the payload which
was sent towards the DUT. This will establish that the DUT is working correctly, and that there is
end-to-end transmission with no data loss.
Ethernet Frame Generator should then increase the rate at which CES frames are sent (reduce the
packetization latency) by the factor of N . Ethernet Analyzer shall establish that at some point of
time (after the jitter buffer fills up entirely) the DUT starts to replace the payload of at least
N 1 1
received packets. The DUT may play up to of valid CES frames.
N N
The test shall be continued for a time period of at least 10 seconds.
Repeat the test with different values of N.
Units N/A
Variables N=2, 3, 4, 5
Results Pass or Fail.
Remarks The Jitter Buffer Overrun condition occurs when the jitter buffer at the TDM-bound IWF cannot
accommodate the newly arrived valid CESoETH frame in its entirety, e.g. due to insufficient
storage space. For example, Jitter buffer overruns will happen if (due to delay variations or a
Denial of Service Attack) the frames arrive at a rate higher than the rate at which the frames
played out of the jitter buffer. This condition may be an indication that the jitter buffer is
incorrectly configured, and either needs to be increased in size, or its operating point adjusted
to accommodate these earlier packets.
Therefore the procedure used to test the overrun behavior is to send CES frames at a rate higher
than expected by IWF. The normal packetization for structure-agnostic CES (See MEF-8, R31) is
256 octets for E1, 192 octets for T1. Such frames therefore are sent at a rate 1000 per second (the
packetization latency of such CES stream is 1 ms). When testing equipment increases the rate of
CES frames sent to DUT, the jitter buffer can no longer accommodate all received frames and
shall start dropping them.
For example, if the frames arrive at the double of normal rate, the IFW will play the data out of
the jitter buffer at a normal rate, so half of arrived packets shall be dropped. There may be vendor
specific implementations which can try to bring the operating point back to the middle of the jitter
buffer (i.e. recalibrate the jitter buffer). Such implementations may drop more than half of the
arriving frames.
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 22
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 23
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 24
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 25
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 26
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
Test Procedure TDM testers generate framed DS1 or E1 circuits to each IWF with a pattern allowing each
timeslot to be uniquely identified (e.g. contain the timeslot number).
Configure IWF for structure-locked encapsulation of N x 64kbit/s basic service. Configure
with different numbers of timeslots in the CESoETH flow, and with default packetization latency
as defined in MEF 8 R39. At least the following numbers of timeslots should be picked:
1 timeslot (test for several different positions)
2 timeslots (test for several different positions and combinations)
4 timeslots (test for several different positions and combinations)
5 timeslots (test for several different positions and combinations)
24 timeslots (DS1) or 31 timeslots (E1)
Several values in between, using combinations of contiguous and non-contiguous timeslots
Ethernet sniffer is used to monitor the CESoETH service frames in each direction, and is used to
verify that:
The correct timeslots appear in the payload
The timeslots appear in the same order in the Ethernet payload as in the circuit
The CESoETH frames contain the correct payload length according to R39.
Repeat using the other TDM circuit type if supported by the DUT.
Repeat using a standard 220-1 PRBS pattern (as defined in O.150) in the TDM timeslots, to allow
TDM testers to verify data integrity.
Units N/A
Variables Number of timeslots per frame, timeslot combinations.
Input circuit type.
PRBS pattern or timeslot identification.
Results Pass or Fail.
Remarks
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 27
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 28
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 29
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
R55. Signaling frames MUST be sent three times at an interval of 5ms on any of the following
events:
a. Setup of the emulated circuit
b. A change in the signaling state of the emulated circuit.
c. Loss of Frames defect has been cleared
d. Remote loss of Frames indication has been cleared
Test Object Determine that a correct number of 32-bit words is forming the CAS Signaling frames, according
to the number of time-slots associated with the TDM-CAS flow.
Test-Bed Generic Test bed 1 as shown in Figure 5-2. TDM Tester must be capable of generating CAS
Configuration signaling events.
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 30
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
Test Procedure TDM Tester sets up a framed TDM circuit, and generates CAS signaling events at frequent
intervals. CESoETH IWF is configured for structure-aware operation with generic TDM
application signaling as described in MEF8 section 6.5.
Ethernet Testers monitors the CESoETH service frames generated by the DUT, and generates a
flow of CESoETH frames back to the and verifies that the CAS Signaling frames, associated
with the same CES flow:
consists of exactly N 32-bit words, where N stands for the number of timeslots in the
associated CESoETH service.
contains the correct ABCD code for the CAS signaling change just generated
are sent three times on each of the events listed in R55
Test repeated several times with different signaling events on different timeslots. Also repeated
with different values of N in the emulated circuit.
Units Number of valid frames
Variables Timeslots used for signaling events
Type of signaling event
Number of timeslots in emulated circuit (value of N)
Results Pass or Fail
Remarks
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 31
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
8. Testing Summary
Level
Test
(mandatory/
Requirement Description Case Test reference Comments
dependent/
No.
optional)
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 32
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
Level
Test
(mandatory/
Requirement Description Case Test reference Comments
dependent/
No.
optional)
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 33
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
Level
Test
(mandatory/
Requirement Description Case Test reference Comments
dependent/
No.
optional)
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 34
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Abstract Test Suite for Circuit Emulation Services
over Ethernet based on MEF 8
Level
Test
(mandatory/
Requirement Description Case Test reference Comments
dependent/
No.
optional)
9. References
Reference Reference Details
RFC 2119 Key words for use in RFCs to Indicate Requirement Levels, RFC 2119, S. Bradner,
March 1997, http://www.ietf.org/rfc/rfc2119.txt
RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals, RFC
2833, H. Schulzrinne, S. Petrack, 2000, http://www.ietf.org/rfc/rfc2833.txt
MEF 3 Circuit Emulation Service Definitions, Framework and Requirements in Metro
Ethernet Networks, MEF 3, April 13, 2004,
http://www.metroethernetforum.org/PDFs/Standards/MEF3.pdf
MEF 8 Implementation Agreement for the Emulation of PDH Circuits over Metro Ethernet
Networks, MEF 8, October 2004,
http://www.metroethernetforum.org/PDFs/Standards/MEF8.pdf
G.823 The control of jitter and wander within digital networks which are based on the 2048
kbit/s hierarchy, ITU-T recommendation G.823, March 2000
G.824 The control of jitter and wander within digital networks which are based on the 1544
kbit/s hierarchy, ITU-T recommendation G.823, March 2000
G.8261 Timing and Synchronisation aspects in Packet Networks, ITU-T recommendation
G.8261, June 2006
O.150 General Requirements for Instrumentation for Performance Measurements on Digital
Transmission Equipment, ITU-T recommendation O.150, May 1996
MEF 18 The Metro Ethernet Forum 2007. Any reproduction of this document, or any portion thereof, shall Page 35
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
Technical Specification
MEF 33
January 2012
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall contain the
following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is
authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
Disclaimer
The information in this publication is freely available for reproduction and use by any recipient
and is believed to be accurate as of its publication date. Such information is subject to change
without notice and the Metro Ethernet Forum (MEF) is not responsible for any errors. The MEF
does not assume responsibility to update or correct any information in this publication. No
representation or warranty, expressed or implied, is made by the MEF concerning the
completeness, accuracy, or applicability of any information contained herein and no liability of
any kind shall be assumed by the MEF as a result of reliance upon such information.
The information contained herein is intended to be used without modification by the recipient or
user of this document. The MEF is not responsible or liable for any modifications to this
document made by any other party.
The receipt or any use of this document or its contents does not in any way create, by implication
or otherwise:
a) any express or implied license or right to or under any patent, copyright, trademark or
trade secret rights held or claimed by any MEF member company which are or may be
associated with the ideas, techniques, concepts or expressions contained herein; nor
b) any warranty or representation that any MEF member companies will announce any
product(s) and/or service(s) related thereto, or if such announcements are made, that
such announced product(s) and/or service(s) embody any or all of the ideas,
technologies, or concepts contained herein; nor
c) any form of relationship between any MEF member companies and the recipient or
user of this document.
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall contain the
following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is
authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
Table of Contents
1. ABSTRACT ...............................................................................................................................................................1
2. TERMINOLOGY ......................................................................................................................................................1
3. SCOPE ........................................................................................................................................................................6
4. COMPLIANCE LEVELS .........................................................................................................................................6
5. ETHERNET SERVICE DEFINITION FRAMEWORK (NORMATIVE) ..........................................................7
5.1 ETHERNET ACCESS (E-ACCESS) SERVICE TYPE ...................................................................................................8
6. SERVICE DEFINITIONS (NORMATIVE) ...........................................................................................................9
6.1 ACCESS ETHERNET PRIVATE LINE SERVICE (ACCESS EPL) .................................................................................9
6.1.1 UNI Service Attributes and Parameter Values ..........................................................................................10
6.1.2 OVC per UNI Service Attributes and Parameter Values ...........................................................................11
6.1.3 OVC Service Attributes ..............................................................................................................................12
6.1.4 OVC End Point per ENNI Service Attributes.............................................................................................13
6.1.5 ENNI Service Attributes ............................................................................................................................14
6.2 ACCESS ETHERNET VIRTUAL PRIVATE LINE (ACCESS EVPL) SERVICE DEFINITION (NORMATIVE) ...................15
6.2.1 Maximum CE-VLAN IDs per OVC Attribute ............................................................................................16
6.2.2 UNI Service Attributes ...............................................................................................................................17
6.2.3 OVC per UNI Service Attributes and Parameter Values ...........................................................................17
6.2.4 OVC Service Attributes ..............................................................................................................................18
6.2.5 OVC End Point per ENNI Service Attributes.............................................................................................19
6.2.6 ENNI Service Attributes ............................................................................................................................20
6.3 SERVICE OAM FAULT MANAGEMENT (SOAM-FM) REQUIREMENTS FOR ACCESS EPL AND ACCESS EVPL
SERVICE 21
6.4 L2CP REQUIREMENTS FOR ACCESS EPL AND ACCESS EVPL SERVICE.............................................................22
7. REFERENCES ........................................................................................................................................................22
8. APPENDIX A: EFFECT OF INTER-FRAME OVERHEAD ON CIR (INFORMATIVE) ............................24
9. APPENDIX B: USE CASES (INFORMATIVE) ..................................................................................................25
9.1 EPL SERVICE......................................................................................................................................................25
9.2 EP-LAN SERVICE...............................................................................................................................................28
9.3 EP-LAN SERVICE WITH HAIRPIN SWITCHING BY SERVICE PROVIDER ...............................................................29
9.4 EVPL SERVICE ...................................................................................................................................................31
9.5 ACCESS TO LAYER 3 SERVICES...........................................................................................................................32
List of Figures
Figure 1. Scope of the E-Access Services Definition. ...................................................................................................6
Figure 2: Ethernet Service Definition Framework ........................................................................................................7
Figure 3: A point-to-point example of an E-Access Service type using OVC with UNI and ENNI OVC End Points.8
Figure 4: Overview of Access EPL Service ............................................................................................................... 10
Figure 5: Overview of Access EVPL Service............................................................................................................. 16
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page i
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
Figure 6. Length of an Ethernet frame as measured with and without the 20 byte inter-frame overhead. ................. 24
Figure 7. Resulting Layer 1 bit rates for different MEF CIR measured as Service Frames ........................................ 25
Figure 8. EPL Service as implemented across two networks using Access EPL, showing the Subscriber and Service
Provider POVs. .................................................................................................................................................... 26
Figure 9. EP-LAN Service as implemented across two networks using Access EPL, showing the Subscriber and
Service Provider Points of View. ......................................................................................................................... 28
Figure 10. EP-LAN example illustrating a Service Provider using hairpin switching between UNI A & B............... 30
Figure 11. EVPL Service as implemented across two networks using Access EVPL, showing the Subscriber and
Service Provider POVs. ....................................................................................................................................... 31
Figure 12. Access aggregation to Layer 3 services using Access EPL or Access EVPL. ........................................... 33
List of Tables
Table 1: Terminology and Definitions Table................................................................................................................6
Table 2: Services defined based on E-Access Service type ..........................................................................................8
Table 3. Example of typical pairings of Service Providers end to end services with supporting services from an
Access Provider. ....................................................................................................................................................9
Table 4: UNI service attributes and parameters for the Access EPL service .............................................................. 11
Table 5: OVC per UNI Service Attributes for Access EPL service. ......................................................................... 12
Table 6: OVC service attributes and parameters for the Access EPL service ............................................................ 13
Table 7: ENNI OVC End Point Service Attributes for the Access EPL service......................................................... 14
Table 8: ENNI Service Attributes for Access EPL Service. ........................................................................................ 15
Table 9: UNI service attributes and parameters for the Access EVPL service ........................................................... 17
Table 10: OVC per UNI Service Attributes for Access EVPL service. ..................................................................... 18
Table 11: OVC service attributes and parameters for the Access EVPL service........................................................ 19
Table 12: ENNI OVC End Point Service Attributes for Access EVPL Service. ........................................................ 20
Table 13: ENNI Service Attributes for Access EVPL Service. ................................................................................... 21
Table 14. Sample attributes for an EPL service. .......................................................................................................... 27
Table 15. Sample attributes for an EP-LAN service. ................................................................................................... 29
Table 16. Change in EP-LAN Attributes in hairpin switching example. ..................................................................... 30
Table 17. Sample attributes for an EVPL service. ....................................................................................................... 32
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page ii
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
1. Abstract
This document defines Ethernet Access Services, which are OVC-based Ethernet services in
contrast to the EVC-based services which are defined in MEF 6.1 Technical Specification
Ethernet Services Definitions[1]. This document uses the UNI service attributes and
parameters options defined in the MEF 6.1 and ENNI and OVC service attributes defined in
MEF 26 Technical Specification External Network Network Interface (ENNI) Phase 1 [8]
and applies them to create new Ethernet access services between a UNI and an ENNI. These new
carrier-to-carrier Ethernet access services enable Ethernet Service Providers to reach out-of-
franchise customer locations through an Ethernet Access Provider's network, and deliver E-Line
and E-LAN service types end to end. This document defines the UNI, OVC, OVC per UNI,
OVC End Point per ENNI, and ENNI requirements for point-to-point OVC-based Ethernet
services. In addition, an informative appendix is provided showing use cases of some of the
defined services.
2. Terminology
This section defines the terms used in this document. In many cases, the normative definitions to
terms are found in other documents. In these cases, the fourth column is used to provide the
reference that is controlling.
Term Abbrev. Definition Ref
Access EPL service uses a Point-to-Point OVC to associate one This
Access Ethernet Access OVC End Point at a UNI and one OVC End Point at an ENNI. document
Private Line EPL One UNI can support only a single instance of the Access EPL
service.
Access EVPL service uses a Point-to-Point OVC to associate one This
Access Ethernet Access
OVC End Point at a UNI and one OVC End Point at an ENNI. document
Virtual Private Line EVPL
One UNI can support one or more Access EVPL instances.
This
Access Provider AP An Operator MEN that offers the Ethernet Access Service type.
document
A Bandwidth Profile is a characterization of the lengths and MEF 10.2
Bandwidth Profile
arrival times for Service Frames at a reference point. [2]
Bandwidth profile per [2]
A bandwidth profile applied on a per-Class of Service basis.
CoS ID
Bandwidth profile per MEF 26
A bandwidth profile applied on a per-OVC Endpoint basis.
OVC Endpoint [8]
Bandwidth profile per [2]
A bandwidth profile applied on a per-UNI basis.
UNI
Broadcast Service A Service Frame that has the broadcast destination MAC [2]
Frame address.
CE-VLAN CoS ID Customer Edge VLAN CoS. Also C-tag PCP. [2]
CE-VLAN CoS ID Value Preservation describes a relationship [8]
CE-VLAN CoS ID
between the format and certain field values of the frame at one
Value Preservation
External Interface and of the corresponding frame at another
(OVC)
External Interface
CE-VLAN ID Customer Edge VLAN ID [2]
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 1
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 2
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 3
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 4
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 5
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
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.
4. Compliance Levels
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT,
SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this
document are to be interpreted as described in RFC 2119 [4]. All key words use upper case, bold
text.
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 6
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
Items that are REQUIRED (contain the words MUST or MUST NOT) will be labeled as [Rx]
for required. Items that are RECOMMENDED (contain the words SHOULD or SHOULD
NOT) will be labeled as [Dx] for desirable. Items that are OPTIONAL (contain the words MAY
or OPTIONAL) will be labeled as [Ox] for optional.
5. Ethernet Service Definition Framework (Normative)
The Ethernet Service Definition Framework defined in MEF 6.1 [1] provides a model for
specifying Ethernet services. Each Ethernet Service type has a set of Ethernet service attributes
that define the service characteristics. These Ethernet Service Attributes in turn have a set of
parameters associated with them that provide various options for the different service attributes.
Refer to Figure 2.
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 7
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
E-Access
(point-to-point Access Ethernet Private Line Access Ethernet Virtual Private Line
OVC) (Access EPL) (Access EVPL)
Table 2: Services defined based on E-Access Service type
UNI ENNI
Metro Ethernet
Network
Figure 3: A point-to-point example of an E-Access Service type using OVC with UNI and ENNI
OVC End Points
1. The services attributes used in Section 6 to specify the parameters of E-Access
services are taken from the noted sections of the following specifications: UNI
Service Attributes (defined in MEF 10.2 [2], Section 7)
2. OVC per UNI Service Attributes (defined in MEF 26 [8] Section 7.5)
3. OVC End Point per ENNI Service Attributes (defined in MEF 26 [8] Section 7.3)
4. OVC Service Attributes (defined in MEF 26 [8], Section 7.2)
5. ENNI Service Attributes (defined in MEF 26 [8], Section 7.1)
In each of these tables, if that service description makes no restrictions on an attribute it is noted
in the table cell.
An example of how E-Access Service types may be used as a component of a Service Providers
end-to-end service is shown in Table 3 below. The Access Services defined in this document
allow use of S-VLAN multiplexing of multiple E-Access Services at one ENNI, permitting
efficient aggregation while maintaining CE-VLAN ID preservation for all Subscribers traffic.
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 8
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
Supported by Access
Providers Wholesale
Service:
Service Provider Access-EPL Access-EVPL
Offers MEF 6.1 (Port-Based) (VLAN-
Service: Based)
EPL X
based based
VLAN- Port-
EP-LAN X
EVPL X
EVP-LAN X
Table 3. Example of typical pairings of Service Providers end to end services with supporting
services from an Access Provider.
Use Cases illustrating more specifically how Access EPL and Access EVPL Services can be
combined to form end to end services are shown in Appendix B.
[R1] An Access EPL service MUST use a Point-to-Point OVC that associates one
OVC End Point at a UNI and one OVC End Point at an ENNI
This service can provide a high degree of transparency for Frames between the EIs it
interconnects such that the Frames header and payload upon ingress at the UNI is delivered
unchanged to the ENNI, with the addition of an S-VLAN tag. The Frames header and payload
upon ingress at the ENNI is delivered unchanged to the UNI except for the removal of the S-
VLAN tag. (These actions presume that the FCS for the frame is recalculated when an S-VLAN
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 9
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
tag is inserted or removed.) Figure 4 below shows the basic structure and scope of Access EPL
service.
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 10
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
[R2] An Access EPL Service instance MUST assign UNI Service Attributes and
values according to Table 4.
[R3] An Access EPL Service instance MUST assign OVC per UNI Service
Attributes and values according to Table 5.
1
See Ingress Bandwidth Profile per OVC End Point at a UNI service attribute in Table 5.
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 11
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
[R4] An Access EPL Service instance MUST assign OVC Service Attributes and
values according to Table 6.
2
MEF Bandwidth Profile traffic parameters such as CIR count only Service Frame bits, not interframe gap or
preamble bits. Setting CIR above 76% of the physical layer speed of the EI has consequences, which are discussed
in more detail in Appendix A.
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 12
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
[R5] An Access EPL Service instance MUST assign OVC End Point at an ENNI
Service Attributes and values according to Table 7.
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 13
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
3
The ingress CIR for an OVC at the ENNI should be greater than the corresponding ingress CIR at the UNI due to
the presence of the added SVLAN tag (4 bytes) at the ENNI. As an example, if the average frame size was 200
bytes, the CIR should be increased by 2%.
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 14
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
[R6] An Access EPL Service instance MUST assign ENNI Service Attributes and
values according to Table 8.
6.2 Access Ethernet Virtual Private Line (Access EVPL) Service Definition
(Normative)
An Access Ethernet Virtual Private Line (Access EVPL) service is specified using an E-Access
Service type.
[R7] An Access EVPL service MUST use a Point-to-Point OVC that associates a
UNI OVC End Point and an ENNI OVC End Point.
An Access EVPL can be used to create services similar to the Ethernet Access Private Line
(Access EPL) with some notable exceptions. First, with Access EVPL a UNI can support
multiple service instances, including a mix of Access and EVC Services (see Figure 5, UNIs A &
B). Such configurations are not possible if Access EPL is offered at the UNI. Second, an Access
EVPL need not provide as much transparency of Service Frames as with an Access EPL, as the
OVC End Point map determines which CE-VLANs are mapped to OVCs or dropped. Because
multiple instances of EVCs and Access EVPLs are permitted, not all ingress Service Frames at
the UNI need be sent to the same destination.
This service can provide a high degree of transparency for Frames between the EIs it
interconnects such that the Frames header and payload upon ingress at the UNI is delivered
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 15
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
unchanged to the ENNI, with the addition of an S-VLAN tag. The Frames header and payload
upon ingress at the ENNI is delivered unchanged to the UNI except for the removal of the S-
VLAN tag. These actions presume that the FCS for the frame is recalculated when an S-VLAN
tag is inserted or removed. Figure 5 below shows the basic structure and scope of Access EVPL
service.
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 16
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
by any OVC End Point Map, but a value N > 1 indicates that up to N CE-VLAN IDs can be
mapped to an OVC (see Table 9 below).
6.2.2 UNI Service Attributes
Table 9 provides the UNI service attributes, parameters, and values for the Access EVPL
Service. Note that there are some differences between UNI attributes for OVC-based services
and those for EVC-based services. Some attributes, such as Service Multiplexing, Bundling, and
All-to-One-Bundling, are not relevant to the agreement between the Access Provider and the
Service Provider, and therefore are omitted from this table.
[R8] An Access EVPL Service instance MUST assign UNI Service Attributes and
values according to Table 9.
4
See Ingress Bandwidth Profile per OVC End Point at a UNI service attribute in Table 10.
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 17
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
[R9] An Access EVPL Service instance MUST assign OVC per UNI Service
Attributes and values according to Table 10.
OVC per UNI Service Possible Values
Attribute
UNI OVC Identifier No additional constraints from definition in MEF 26 [8].
OVC End Point Map MUST specify mapping table of CE-VLAN ID to OVC End Point.
MUST NOT contain all CE-VLAN ID values mapped to a single OVC
End Point. (This configuration is reserved for the Access EPL service)
Class of Service Identifier for The CoS Identifier for Service Frames MUST be the OVC End Point to
Service Frames which the Service Frame is mapped; that OVC MUST have a single CoS
Name.
Ingress Bandwidth Profile Per Required, MUST specify <CIR, CBS, EIR, EBS, CM, CF>; MUST
OVC End Point at a UNI allow configuration to support CIR values up to 70% of the UNI speed 5,
in the following increments:
1 10 Mb/s, increments of 1 Mb/s
10 100 Mb/s, increments of 10 Mb/s
100 1000 Mb/s, increments of 100 Mb/s
1 10 Gb/s, increments of 1 Gb/s.
These required CIR increments are subject to the limit imposed by the
UNI speed. For example, a 100 Mb/s UNI MUST support CIR values of
1 10 Mb/s in increments of 1 Mb/s, and 10 70 Mb/s in increments of
10 Mb/s.
MAY support other values of CIR.
MUST allow configuration of EIR = 0, EBS = 0, CF = 0, Color Mode =
color blind
MAY support other values of EIR, EBS, CF, and Color Mode.
MUST have CBS >= 12176 bytes
MUST NOT be combined with any other type of ingress bandwidth
profile.
When the ingress Bandwidth Profile of the OVC End Point at the UNI
has CIR > 0 and EIR = 0, each egress ENNI Frame MUST be marked
Green via the S-Tag as per [MEF 23].
Ingress Bandwidth Profile Per Not used.
Class of Service Identifier at a
UNI
Egress Bandwidth Profile Per MUST NOT specify
OVC End Point at a UNI
Egress Bandwidth Profile Per MUST NOT specify
Class of Service Identifier at a
UNI
Table 10: OVC per UNI Service Attributes for Access EVPL service.
6.2.4 OVC Service Attributes
Table 11 provides the OVC service attributes, parameters, and values for the Access EVPL
service.
5
MEF Bandwidth Profile traffic parameters such as CIR count only Service Frame bits, not interframe gap or
preamble bits. Setting CIR above 76% of the physical layer speed of the EI has consequences, which are discussed
in more detail in Appendix A.
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 18
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
[R10] An Access EVPL Service instance MUST assign OVC Service Attributes and
values according to Table 11.
[R11] An Access EVPL Service instance MUST assign OVC End Point at an ENNI
Service Attributes and values according to Table 12.
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 19
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 20
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
hairpin switching in Section 7.2.2 of MEF 26 [8]) by the Operator providing the Access EVPL
service.
[R12] An Access EVPL Service instance MUST assign ENNI Service Attributes and
values according to Table 13.
6.3 Service OAM Fault Management (SOAM-FM) Requirements for Access EPL
and Access EVPL Service
To enable uniform behavior of SOAM-FM for the Access EPL and Access EVPL Services
across all Access Providers, the appropriate requirements as detailed in the SOAM FM IA (MEF
30) [10] must be followed. Specifically:
[R13] The Access EPL and Access EVPL Services MUST be configurable to tunnel
all SOAM frames at the default Test and Subscriber MEG levels as defined in
the SOAM FM IA (MEF 30) [10] document, section 7.1.
If the Access Provider uses SOAM-FM in their network, they have available for their use the
Operator, UNI, and ENNI MEG levels as specified in the SOAM-FM IA [10], section 7.1.
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 21
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
6.4 L2CP Requirements For Access EPL And Access EVPL Service
Processing of L2CP frames is for further study. Until defined in a future revision of this
document, processing of L2CP frames is agreed to by the two parties involved in the Access
Service.
7. References
[1] MEF Technical Specification MEF 6.1, Ethernet Services Definitions - Phase 2, April,
2008.
[2] MEF Technical Specification, MEF 10.2, Ethernet Services Attributes - Phase 2,
October 2009.
[3] IEEE 802.3-2005, Part 3: Carrier sense multiple access with collision detection
(CSMA/CD) access method and physical layer specifications
[4] RFC 2119, Key words for use in RFCs to Indicate Requirement Levels, S. Bradner
[5] IEEE 802.1ad-2005, Virtual Bridged Local Area Networks Amendment 4: Provider
Bridges
[6] MEF Technical Specification MEF 4, Metro Ethernet Network Architecture Framework
- Part 1: Generic Framework, May 2004
[7] ITU-T Recommendation Y.1731, OAM functions and mechanisms for Ethernet based
networks
[8] MEF Technical Specification MEF 26, External Network to Network Interface (ENNI)
Phase 1, January 2010.
[9] MEF Technical Specification MEF 20, User Network Interface (UNI) Type 2
Implementation Agreement, July 2008.
[10] MEF Technical Specification MEF 30, Service OAM Fault Management
Implementation Agreement, January 2011.
[11] IEEE 802.1ag-2007, Virtual Bridged Local Area Networks Amendment 5: Connectivity
Fault Management.
[12] IEEE 802.1aj-2009. IEEE Standard for Local and metropolitan Area Networks Virtual
Bridged Local Area Networks Amendment 11: Two-Port Media Access Control (MAC)
Relay. - December 2009.
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 22
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
[13] IEEE P802.1AB-REV/D6.0-2009. IEEE Standard for Local and metropolitan Area
Networks - Station and Media Access Control Connectivity Discovery June 2009.
[14] IEEE P802.1X-REV/D4.5 IEEE Draft Standard for Local and metropolitan Area
Networks. Port-based Network Access Control. October 2009.
[15] MEF Technical Specification MEF 26.0.2, OVC Layer 2 Control Protocol Tunneling
Amendment to MEF 26, January 2011.
[16] MEF Technical Specification MEF 23.1, Carrier Ethernet Class of Service Phase 2,
(in progress) 2011.
[17] MEF Technical Specification MEF 26.0.3, Service Level Specification Amendment to
MEF 26, October 2011.
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 23
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
Figure 6. Length of an Ethernet frame as measured with and without the 20 byte inter-frame
overhead.
Since Bandwidth Profile traffic parameters such as CIR do not account for interframe gap or
preamble bits that are added by the Ethernet physical layer, a policed stream of MEF Service
Frames of constant size X, will result in a stream of physical layer frames of size X+20 bytes at a
UNI. Clearly the impact of this overhead inflation varies directly with frame size, from a low
of 1.3% for a 1518 byte frame, to a maximum of 31% for a 64 byte frame. The result of this
effect is shown in Figure 7 for a 100 Mb/s interface. The resulting curve shows that as the frame
size decreases, an increasing fraction of the line rate is consumed by overhead and the maximum
bits/sec of Service Frames transmitted drops sharply as the frame size decreases below 200
bytes.
The resulting caution from these observations is that provisioning a CIR greater than 76% of a
physical interface speed, will allow the possiblility that the maximum bits/sec of Service Frames
transmitted may be considerably less than the CIR value when traffic is comprised of a high
percentage of small frame sizes.
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 24
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
90.00
Service Frame Mb/s
80.00
70.00
60.00
50 250 450 650 850 1050 1250 1450 1650 1850
Frame Size, bytes
Figure 7. Resulting Layer 1 bit rates for different MEF CIR measured as Service Frames
The following figure shows the Subscriber and Service Provider Points of View (POV) for an
instance of EPL Service offered by the Service Provider using Access EPL Service in the Access
Provider Network.
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 25
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
Figure 8. EPL Service as implemented across two networks using Access EPL, showing the
Subscriber and Service Provider POVs.
An illustrative table below shows some of the attributes that must be specified as part of the end
to end service, color coded to show that they belong to the end to end service (red), the Access
Provider (blue), or the Service Provider (gray).
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 26
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
3 CE-VLAN ID to EVC Map All Service OVC Endpoint All CE-VLAN ID OVC Endpoint All CE-VLAN ID
Frames map to Map at UNI A values map to Map at UNI C values map to
one EVC single OVC single OVC
4 N/A N/A ENNI Endpoint OVC Endpoint ENNI Endpoint OVC Endpoint
Map E = SVLAN ID Map F = SVLAN ID
158 158
5 Ingress bandwidth profile CIR= 100 Mb/s, Ingress CIR= 100 Mb/s, Ingress CIR= 100 Mb/s,
per EVC CBS = 12K, bandwidth CBS = 12K, bandwidth CBS = 12K,
EIR, EBS=0; profile per OVC EIR, EBS=0; profile per OVC EIR, EBS=0;
CM=blind; EP at UNI A CM=blind; EP at UNI C CM=blind;
CF=0 CF=0
6 N/A N/A Ingress CIR should Ingress CIR should
bandwidth reflect S-tag bandwidth reflect S-tag
profile per OVC overhead, rest profile per OVC overhead, rest
EP at ENNI same as UNI EP at ENNI same as UNI
7 CE-VLAN ID, CoS MUST be yes CE-VLAN ID, MUST be yes CE-VLAN ID, MUST be yes
preservation CoS CoS
preservation preservation
8 CoS ID based on EVC, CoS ID based All PCP values CoS ID based All PCP values
value=M S-tag PCP =M S-tag PCP =M
9 EVC Performance MFD= 80 ms OVC MFD=10 OVC MFD = 50
for Label=M, Performance Performance
PT=Continental
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 27
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
Row 9 illustrates that the EVC Mean Frame Delay (MFD) performance for CoS Label = M, and
the Continental Performance Tier is 80 ms according to the MEF 23.1 [16]. The individual
OVCs have adequate performance to meet the end to end goal.
The following figure shows the Subscriber and Service Provider Points of View (POV) for an
instance of EP-LAN Service offered by the Service Provider using Access EPL Service in the
Access Provider Network.
Figure 9. EP-LAN Service as implemented across two networks using Access EPL, showing the
Subscriber and Service Provider Points of View.
An illustrative table below shows some of the attributes that must be specified as part of the end
to end service, color coded to show that they belong to the end to end service (red), the Access
Provider (blue), or the Service Provider (gray).
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 28
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
3 CE-VLAN ID to EVC All Service OVC Endpoint All CE-VLAN OVC Endpoint All CE-VLAN
Map Frames map to Map at UNI A ID values map Map at UNIs C ID values map
one EVC to single OVC &D to single OVC
4 N/A N/A ENNI Endpoint OVC Endpoint ENNI Endpoint OVC Endpoint
Map E = SVLAN Map F = SVLAN
ID 158 ID 158
5 Ingress bandwidth CIR= 100 Mb/s, Ingress CIR= 100 Ingress CIR= 100
profile per EVC CBS = 12K, EIR, bandwidth profile Mb/s, CBS = bandwidth Mb/s, CBS =
EBS=0; per OVC EP at 12K, EIR, profile per 12K, EIR,
CM=blind; UNI A EBS=0; OVC EP at EBS=0;
CM=blind; UNIs C & D CM=blind;
CF=0 CF=0
6 N/A N/A Ingress CIR should Ingress CIR should
bandwidth profile reflect S-tag bandwidth reflect S-tag
per OVC EP at overhead, rest profile per overhead, rest
ENNI same as UNI OVC EP at same as UNI
ENNI
7 CE-VLAN ID, CoS MUST be yes CE-VLAN ID, MUST be yes CE-VLAN ID, MUST be yes
preservation CoS preservation CoS
preservation
8 CoS ID based on EVC, CoS ID based S- All PCP values CoS ID based All PCP values
value=M tag PCP =M S-tag PCP =M
9 EVC Performance MFD= 80 ms for OVC MFD=10 OVC MFD = 50
Label=M, Performance S= {all ordered Performance S= {all ordered
PT=Continental, OVC EP pairs OVC EP pairs
S= {all ordered per OVC} per OVC}
UNI pairs}
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 29
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
Figure 10. EP-LAN example illustrating a Service Provider using hairpin switching between UNI A
& B.
The following table shows what attribute is different in the EP-LAN case with hairpin switching
show above:
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 30
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
The following figure shows the Subscriber and Service Provider Points of View (POV) for two
instances of EVPL Service offered by the Service Provider using Access EVPL Service in the
Access Provider Network.
Figure 11. EVPL Service as implemented across two networks using Access EVPL, showing the
Subscriber and Service Provider POVs.
An illustrative table below shows some of the attributes that must be specified as part of the end
to end EVPL service, color coded to show that they belong to the end to end service (red), the
Access Provider (blue), or the Service Provider (gray).
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 31
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
3 CE-VLAN ID to EVC Specifies what CE- OVC Endpoint OVC Endpoint OVC Endpoint OVC Endpoint
Map VLAN ID maps to Map at UNI A a = CE-VLAN Map at UNI C & c = CE-VLAN
each EVC ID 12 E ID 12
OVC Endpoint OVC Endpoint
b = CE-VLAN e = CE-VLAN
ID 42 ID 42
4 N/A N/A ENNI Endpoint OVC Endpoint ENNI Endpoint OVC Endpoint
Map S = SVLAN ID Map T = SVLAN ID
158 158
OVC Endpoint OVC Endpoint
U = SVLAN ID V = SVLAN ID
455 455
5 Ingress bandwidth CIR= 100 Mb/s, Ingress CIR= 100 Mb/s, Ingress CIR= 100 Mb/s,
profile per EVC CBS = 12K, EIR, bandwidth CBS = 12K, bandwidth CBS = 12K,
EBS=0; CM=blind; profile per OVC EIR, EBS=0; profile per OVC EIR, EBS=0;
EP at UNI A CM=blind; EP at UNI C CM=blind;
CF=0 CF=0
6 N/A N/A Ingress CIR should Ingress CIR should
bandwidth reflect S-tag bandwidth reflect S-tag
profile per OVC overhead, rest profile per OVC overhead, rest
EP at ENNI same as UNI EP at ENNI same as UNI
7 CE-VLAN ID, CoS MUST be YES or CE-VLAN ID, MUST be yes CE-VLAN ID, MUST be YES
preservation NO CoS CoS or NO
preservation preservation
8 CoS ID based on EVC, CoS ID based All PCP values CoS ID based All PCP values
value=M S-tag PCP =M S-tag PCP =M
9 EVC Performance MFD= 80 ms for OVC MFD=10 OVC MFD = 50
Label=M, Performance Performance
PT=Continental
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.
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 32
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.
Ethernet Access Services Definitions
Figure 12. Access aggregation to Layer 3 services using Access EPL or Access EVPL.
MEF 33 The Metro Ethernet Forum 2012. Any reproduction of this document, or any portion thereof, shall Page 33
contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user
of this document is authorized to modify any of the information contained herein.