Ethernet Interconnection Point (EIP)

Ethernet Interconnection Point (EIP)
Service Operations
Specification
MEF 54
Ethernet Interconnection Point (EIP):
An ENNI Implementation Agreement
March 2016
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF 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 MEF 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 and guidelines will be voluntary, and no company shall be obliged to
implement them by virtue of participation in the MEF Forum. The MEF is a non-profit
international organization accelerating industry cooperation on Metro Ethernet technology. The MEF does not, expressly or otherwise, endorse or promote any specific products
or services.
© MEF Forum 2016. All Rights Reserved.
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Table of Contents
1.
List of Contributing Member Companies ........................................................................ 3
2.
Abstract ................................................................................................................................ 3
3.
Terminology and Acronyms............................................................................................... 3
4.
Scope..................................................................................................................................... 9
5.
Introduction ....................................................................................................................... 11
5.1
Factors Contributing to Slow MEF E-Access Adoption ............................................... 13
5.2
Examples and Importance of TPIDS .............................................................................. 14
5.3
Learning About Interoperability from Actual Implementations ................................. 17
5.4
Illustrative Example of the Rapid Prototyping Process ................................................ 18
6.
Use Cases and Scenarios ................................................................................................... 19
6.1
Use Case 1 – Topology and Services Supported ............................................................. 19
6.1.1 Topology............................................................................................................................. 19
6.1.2 Services............................................................................................................................... 20
7.
Test Cases .......................................................................................................................... 20
7.1
Service Configuration Test Cases .................................................................................... 20
7.2
Future Service Configuration Test Cases ....................................................................... 21
7.3
L2CP Testing and Results ................................................................................................ 21
8.
Testing Environment ........................................................................................................ 23
8.1
Testing Summary .............................................................................................................. 23
9.
Compliance Levels – More Detail Regarding Test Results ........................................... 25
10.
Other Implementation Obstacles and Recommendations on how to Overcome ........ 26
10.1 Implementation Obstacles and Remediation – Tested in Lab ...................................... 26
10.2 Possible Implementation Obstacles and Remediation – Not Tested in Lab ................ 27
11.
Other EIP Items to Consider ........................................................................................... 28
11.1 EIP Location Planning – Where to Build? ..................................................................... 29
11.2 How Many EIPs Do We Need? ........................................................................................ 29
11.3 How Does an Operator Determine What Ethernet Services Are Available for Off-Net
Locations? .................................................................................................................................... 29
11.4 What Should an Operator Know About Ordering Ethernet Services? ....................... 29
11.5 “Special Construction,” “Entrance Facility,” and “Inside Wire” – What Does an
Operator Need to Know? ........................................................................................................... 30
11.6 Physical Equipment .......................................................................................................... 30
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page i
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
12.
References .......................................................................................................................... 31
13.
Acknowledgements ........................................................................................................... 32
14.
Appendix I – Test Cases for EIP Use Case 1 Phase 1 .................................................... 33
15.
Appendix II – Detailed L2CP Information – Based Upon Testing .............................. 77
List of Figures
Figure 1 – Interconnect Readiness ................................................................................................ 10
Figure 2 – History of TDM ........................................................................................................... 12
Figure 3 – Current Marketplace Interconnect Models .................................................................. 14
Figure 4 – TPID Mismatch Isolation ............................................................................................ 15
Figure 5 – TPID Limiting Operator .............................................................................................. 16
Figure 6 – Provisionable TPID - Bi-Lingual Operator ................................................................. 16
Figure 7 – Network Interconnection Evolution (TPID and Tagging Evolution Examples) ......... 18
Figure 8 – University of New Hampshire's Interoperability Lab (Full test matrix not depicted) . 19
Figure 9 – High Level Diagram of Use Case 1, Phase 1 .............................................................. 20
Figure 10 – High Level Diagram of Use Case 1, Phase 1 ............................................................ 22
Figure 11 – Operator 1 OVC Verification .................................................................................... 23
Figure 12 – Operator 2 OVC Verification .................................................................................... 23
Figure 13 – Service Provider EVC Verification ........................................................................... 24
Figure 14 – Summary of Test Results........................................................................................... 24
List of Tables
Table 1 – Contributing Member Companies .................................................................................. 3
Table 2 – Terminology and Acronyms ........................................................................................... 9
Table 3 – Existing MEF Specifications Used in this Document .................................................. 11
Table 4 – Implementation Obstacles – Tested in Lab................................................................... 26
Table 5 – Implementation Obstacles – Not Tested in Lab............................................................ 28
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page ii
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
1. List of Contributing Member Companies
The following Member companies of the MEF participated in the development of this document and have requested to be included in this list.
Member Company
AT&T
CenturyLink
Frontier
TelePacific
University of New Hampshire
Interoperability Lab
Verizon
Veryx Technologies
Windstream
Table 1 – Contributing Member Companies
2. Abstract
This document is intended to act as an Implementation Agreement for any Operator interested in connecting their Carrier Ethernet network to another Operator using an Ethernet
ENNI.
This Implementation Agreement draws heavily from MEF 26.1 “External Network Network
Interface (ENNI),” and MEF 33 “Ethernet Access Services Definitions,” but it doesn't
amend, change, or supersede them in any fashion. Rather, this document allows Operators to
follow practical guidelines to help them efficiently evolve their networks to meet full MEF
E-Access capabilities – either all at once, or in a series of steps.
In addition, this Implementation Agreement documents the results of a series of ENNI testing performed between a sample of US based Operators. The test results are intended to
help Operators understand and overcome a myriad of issues they may expect to encounter
when embarking on the establishment of ENNIs with an Operator adjacent to their footprint.
Specifically, when each Operator has different Ethernet Interconnection capabilities and
configurations.
3. Terminology and Acronyms
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, in other MEF or external documents. Emphasis is on
new terms created in this document.
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 3
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Term
All to One Bundling
Bandwidth Profile
Bundling
CBS
CE
CEN
CE-VLAN CoS
CE-VLAN CoS
Preservation
CE-VLAN ID
CE-VLAN ID
Preservation
CE-VLAN ID/EVC
Map
CE-VLAN Tag
CF
CfC
CHLI
CIR
CIRmax
Class of Service
Identifier
Class of Service
Name
MEF 54
Definition
A UNI Service Attribute in which all CE-VLAN IDs are
mapped to a single EVC.
A characterization of the lengths and arrival times for Service Frames at a reference point. Can also be a characterization of the lengths and arrival times for ENNI Frames at a
reference point.
A UNI Service Attribute in which more than one CE-VLAN
ID can be mapped to an EVC.
Committed Burst Size
Customer Edge
Carrier Ethernet Network. A network from a Service Provider or network Operator supporting the MEF service and
architecture models.
Customer Edge VLAN CoS
An EVC Service Attribute that, when Enabled, requires an
egress Service Frame resulting from an ingress Service
Frame that contains a CE-VLAN CoS to have the identical
CE-VLAN CoS.
Customer Edge VLAN ID
An EVC Service Attribute that, when Enabled, requires an
egress Service Frame resulting from an ingress Service
Frame to have an identical CE-VLAN ID.
An association of CE-VLAN IDs with EVCs at a UNI.
Reference
MEF 10.3
Customer Edge VLAN Tag
Coupling Flag
Call for Comments (MEF Voting Process)
MEF 10.3
MEF 10.3
This Document
MEF 10.3
MEF 10.3
MEF 10.3
Consecutive High Loss Interval
Committed Information Rate
The Bandwidth Profile parameter that limits the rate of tokens added to the committed token bucket.
The mechanism and/or values of the parameters in the mechanism to be used to identify the Class of Service Name that
applies to a Service Frame.
A designation given to one or more sets of performance objectives and associated parameters by the Service Provider.
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 23.1
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 4
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Term
CM
Color Identifier
Color Mode
Color-aware
Color-blind
Committed Burst
Size
Committed
In-formation Rate
CoS
CoS Name
Coupling Flag
Customer Edge
Customer Edge
VLAN Class of
Service
Customer Edge
VLAN ID
Customer Edge
VLAN Tag
Data Service
Frame
MEF 54
Definition
Color Mode
The mechanism and/or values of the parameters in the mechanism used to identify the Color that applies to the Service
Frame at a given UNI.
The Bandwidth Profile parameter that 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.
A Bandwidth Profile property where the level of compliance
for each Service Frame is dependent on the value of the
Frame's Color Identifier.
A Bandwidth Profile property where the level of compliance
for each Service Frame is not dependent on the value of the
Frame's Color Identifier.
The Bandwidth Profile parameter that limits the maximum
number of bytes available for a burst of Service Frames sent
at the UNI line rate that will be declared Green by the
Bandwidth Profile.
The Bandwidth Profile parameter that limits the average rate
in bits per second of Service Frames that will be declared
Green by the Bandwidth Profile.
Class of Service
A parameter used in Performance Metrics that specifies the
Class of Service Name for the metric
The Bandwidth Profile parameter that determines whether or
not overflow tokens not used for Service Frames declared
Green can be used as Yellow tokens.
Equipment on the Subscriber side of the UNI.
The Priority Code Point bits in the IEEE Std 802.1Q – 2011
Customer VLAN Tag in a Tagged Service Frame.
The identifier derivable from the content of a Service Frame
that allows the Service Frame to be mapped to an EVC at the
UNI.
The IEEE Std 802.1Q – 2011 Customer VLAN Tag in a
Tagged Service Frame.
A Service Frame that is neither a Layer 2 Control Protocol
Service Frame nor a SOAM Service Frame
Reference
MEF 10.3
MEF 23.1
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 5
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Term
Definition
DEI
Drop Eligible Indicator
DSCP
DTE
Differentiated Services Code Point
Data Termination Equipment
EBS
Egress Bandwidth
Profile
Egress
Equivalence
Class Identifier
Egress Service
Frame
EIP
Excess Burst Size
A Service Attribute that specifies the length and arrival time
characteristics of egress Service Frames at the egress UNI.
The mechanism and/or values of the parameters in the mechanism that can be used to specify an Egress Band-width Profile Flow for egress Service Frames.
A Service Frame sent from the Service Provider network to
the CE.
Ethernet Interconnect Point
EIR
EIR max
Excess Information Rate
The Bandwidth Profile parameter that limits the rate of tokens added to the excess token bucket.
Ethernet Local Management Interface
External Network Network Interface
E-LMI
ENNI
Envelope
A set of Bandwidth Profile Flows in which each Band-width
Profile Flow is assigned a unique rank between 1 (lowest)
and (highest).
Ethernet Synchronization Message Channel
ESMC
Ethernet
Interconnect Point
Ethernet Virtual
Connection
EVC
EVC Maximum
Service Frame
Size
MEF 54
A physical location where two or more Operators connect
their Ethernet networks by establishing either an ENNI
(MEF 33) or a non-standard NNI
An association of two or more UNIs that limits the exchange of Service Frames to UNIs in the Ethernet Virtual
Connection.
Ethernet Virtual Connection
An EVC Service Attribute that specifies the maximum size
of a Service Frame allowed for that EVC.
Reference
IEEE
802.1Q
RFC 2474
IEEE
802.3
2012
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
This document
MEF 10.3
MEF 10.3
MEF 16
MEF 4,
MEF
26.1
MEF 10.3
ITU
G.8264
This document
MEF 10.3
MEF 10.3
MEF 10.3
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 6
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Term
Excess Burst Size
Excess
Information Rate
FD
FDR
Frame
Frame Delay
Frame Delay
Range
High Loss Interval
HLI
IFDV
IA
Information Rate
Ingress
Band-width Profile
Ingress Service
Frame
Inter-Frame Delay
Variation
L2CP Service
Frame
LAG
Layer 2 Control
Protocol Service
Frame
Non Standard
NNI
MEF 54
Definition
The Bandwidth Profile parameter that limits the maximum
number of bytes available for a burst of Service Frames sent
at the UNI line rate that will be declared Yellow by the
Bandwidth Profile.
The Bandwidth Profile parameter that limits the average rate
in bits per second of Service Frames that will be declared
Yellow by the Bandwidth Profile.
Frame Delay
Frame Delay Range
Short for Ethernet frame.
The time elapsed from the transmission at the ingress UNI of
the first bit of the corresponding ingress Service Frame until
the reception of the last bit of the Service Frame at the egress
UNI.
The Frame Delay Performance minus the minimum Service
Frame delay.
A small time interval contained in T with a high frame loss
ratio.
High Loss Interval
Inter-Frame Delay Variation
Implementation Agreement
The average bit rate of Ethernet service frames at the measurement point starting with the first MAC address bit and
ending with the last FCS bit.
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.
A Service Frame sent from the Customer Equipment into the
Service Provider network.
The difference between the one-way delays of a pair of selected Service Frames.
Layer 2 Control Protocol Service Frame
Link Aggregation Group
A Service Frame that could be used in a recognized Layer 2
Control Protocol.
Any interconnection between two Operators that uses a
specification other than MEF 33.
Reference
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
This document
ITU
Y.1564
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
IEEE Std
802.1AX –
2008
MEF 10.3
This document
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 7
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Term
NNI
Operator
Definition
Network-to-Network Interface
The company who owns the Ethernet Service. Operator
provides connectivity services to the Service Provider that
in turn provides the UNI-to-UNI (end-to-end service) to the
Subscriber
Priority Code Point
PCP
Performance
Metric
Point-to-Point
EVC
Priority Tagged
Service Frame
A quantitative characterization of Service Frame delivery
quality.
An EVC with exactly 2 UNIs.
Subscriber
Tagged Service
Frame
TCI
A Service Frame with a TPID = 0x8100 following the
Source Address and the corresponding VLAN ID value is
0x000 in the tag following the TPID.
The first bit of the Destination MAC Address through the
last bit of the Frame Check Sequence of an IEEE 802.3
Packet transmitted across the UNI.
The technical specification of the service level being offered
by the Service Provider to the Subscriber.
A UNI Service Attribute in which the UNI can be in more
than one EVC instance.
The organization providing Ethernet Service(s).
Service Level Specification
A Service Frame whose MAC Destination Address does not
indicate it to be an L2CP Service Frame and whose
Ethertype = 0x8902.
The organization purchasing and/or using Ethernet Services.
A Service Frame that is either a VLAN Tagged Service
Frame or a Priority Tagged Service Frame.
Tag Control Information
TPID
Tag Protocol Identifier
UNI
UNI Line Rate
UNI Maximum
Service Frame
Size
User Network Interface
The MAC data rate at the UNI.
A UNI Service Attribute that specifies the maximum size of
a Service Frame allowed at the UNI.
Service Frame
Service Level
Specification
Service
Multiplexing
Service Provider
SLS
SOAM Service
Frame
MEF 54
Reference
Industry
term
MEF 26.1
IEEE Std
802.1Q –
2011
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
MEF 10.3
IEEE Std
802.1Q –
2011
IEEE Std
802.1Q –
2011
MEF 10.3
MEF 10.3
MEF 10.3
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 8
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Term
Untagged Service
Frame
User Network
Interface
VLAN Tagged
Service Frame
Definition
A Service Frame with the two bytes following the Source
Address field containing neither the value 0x8100 nor the
value 0x88a8
The physical demarcation point between the responsibility of
the Service Provider and the responsibility of the Sub-scriber
A Service Frame with a TPID = 0x8100 following the
Source Address and the corresponding VLAN ID value is
not 0x000 in the tag following the TPID
Reference
MEF 10.3
MEF 10.3
MEF 10.3
Table 2 – Terminology and Acronyms
4. Scope
The motivation for this Project is:








Help Operators understand why they should move to MEF E-Access Services
Help Operators understand they are on a journey (whether they realize it, or not) to
transform their network to Ethernet
Help Operators understand what hurdles they can expect on their journey towards
MEF E-Access Services
Help Operators understand how to move to MEF E-Access Services
Help Operators understand the interim steps they can take to put them on a path towards full MEF E-Access compliance if getting to MEF E-Access Services is not
obtainable in one step
To accelerate the ease and speed at which Operators can interconnect their current
networks to support MEF standard services
To facilitate the technology transition from TDM to Ethernet worldwide
To encourage increased deployment of MEF Ethernet services across a wider base of
network.
A pictorial representation of the current Ethernet interconnection marketplace is largely
composed of two types of Interconnections: "NNIs" and "ENNIs" as per Figure 1 below.
The term "NNI" (Network-to-Network Interface) is a generic term for any connection between two networks. There is wide interpretation to its meaning and it is not affiliated with
any specific standards, specific configurations, or specific transport types. Conversely, the
term "ENNI" (Ethernet Network Network Interface) is specifically defined by the MEF and
is not open to interpretation. The ENNI can only be an Ethernet Interconnection between
two networks with the specifications and configurations as per MEF E-Access (MEF 26.1,
MEF 33, MEF 51).
The importance of Figure 1 and Figure 2 cannot be overemphasized. In summary, there is a
global movement away from multiple legacy technologies including TDM, Frame Relay
and ATM towards Ethernet, yet most Operators (TDM and/or Ethernet) aren't even aware of
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 9
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Figure 1 – Interconnect Readiness
their need to move to a standardized way of connecting their current network to other Operators. Moreover, Operators may not understand the great flexibility of Ethernet services and
the added complexity required at Operator interconnections. The current process many Operators are using to interconnect with Ethernet is not scalable, and does not support the
complexity and features required for emerging the new technologies (S-Tag encapsulation at
the ENNI, multi-Operator ENNIs, etc.). When Operators interconnect in a non-standard
method both the processes for ordering services and the Ethernet services supported will be
impacted. In addition, non-standard interconnects will affect other operational functions including fault and performance.
The objective is to create an Implementation Agreement that is used in establishing a new
EIP (Ethernet Interconnect Point). In subsequent projects, associated "quote to cash" business processes will be developed. This project will include:


MEF 54
An "Implementation Agreement" of how the CENs will interconnect based on existing MEF specifications. This will involve developing a list of most commonly supportable configurations for existing networks, and a list of corresponding attributes.
The desired goal is full MEF compliant interconnects; the required output from this
project will be to identify the acceptable minimum set of capabilities that allow the
interconnects to support the MEF services in the identified Use Cases.
Project will use test cases from existing MEF ATS (Abstract Test Suite), other CE
2.0 test cases, and create new ones developed at University of New Hampshire Interoperability Lab (UNH IOL) specifically for interoperability testing. The test cases
will be used for lab verification of MEF Services and attributes supported in the included Use Cases, for adherence to the Implementation Agreement (does not include
verification of performance objectives in real networks.)
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 10
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
An important detail to nail down is what is the list of "existing MEF Specifications" that
will be used in this project as the basis for the EIP and our documentation of Service Attributes and test cases. The initial concept of EIP is based around the industry target provided
by MEF CE 2. 0 compliance to MEF E-Access Services; the CE 2.0 compliance was based
on the documents approved at the time and referred to within the document set.
Description
of Set of
Specifications
/
Access Services
End-toend
Service
ENNI
Interface
SOAM-FM
Test cases for Test
Access
cases
for
Services
ENNI
Issues
MEF
26.1
MEF 30
MEF 34; CE
2.0
test
cases
some
holes (L2CP);
but consensus
is to go with this
set of
documents
for IA;
address remaining issues as
needed, but
caution against
using documents
that are too
new for products to be available.
Rationale for
their use
2012 Set of
MEF Service
and Attribute
Specifications
This is the
target from
the point in
time the MEF
2.0 certification suite was
created
(2012); a stable industry
target that
Equipment
Vendors and
Service Providers have
been measured against
since
MEF 33;
MEF 6.1
refers to
MEF 6.1
(services),
MEF 10.2
(attributes),
20
(UNI type
2), MEF
23.1
(CoS), MEF
26.1 (ENNI),
MEF 30
(SOAM-FM)
MEF
37
(covers
MEF
26);
CE 2.0
test
cases
Table 3 – Existing MEF Specifications Used in this Document
5. Introduction
TDM technologies have dominated the global telecommunications landscape for decades.
However, there are inconsistent instances of TDM across the globe. While US and Canada
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 11
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Figure 2 – History of TDM
deployed "T1" services, much of the world deployed "E1." Furthermore, while TDM developed new technologies to enable more bandwidth, US and Canada deployed SONET
technology while most of the world deployed SDH technology.
The telecommunications industry has now entered the Era of Ethernet networking, and for
the first time in history, a globally recognized standard for networking is unfolding (Figure
2 below). What's most remarkable is the same technology is used in a LAN, Metro, or
WAN. Never before in the history of telecom has a single technology been so universal for
both customers (Subscribers), and Operators (Carriers). While the specific dates below are
debatable, the trend is not.
The global Ethernet market is now estimated to be approximately $50B and rapidly growing, and this market is divided into thousands of individual Operators across the globe. The
importance of interconnection for global businesses has never been greater, but covering a
world-wide footprint requires interconnecting these Operators with the high-speed, cost effective bandwidth that MEF Ethernet services can provide. To forward that goal, the MEF
has developed a number of specifications to standardize the way Operators can interconnect
their CENs, starting with the External Network Network Interface (ENNI, MEF 26) in 2010,
the Ethernet Access Services Definition (E-Access, MEF 33) in 2012, MEF Carrier Ethernet
2.0 Certification (2013), and continuing with MEF 51 (OVC Services Definitions). This sustained effort has paved the path toward standardized "plug-and-play" interconnection, but
the progress in the marketplace has been modest to date. While a small number of Operators
have gone to the effort and expense to achieve the full MEF certification for interconnection
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 12
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
– CE 2.0 Certification for E-Access Services, the rate of such certifications per quarter has
remained modest and the trend is flat.
As a result, the interconnection process between Operators is still dominated by the slow
and costly need to survey, evaluate, negotiate, configure, and test each new Operator's network before it is connected. The Operators leading this project now understand the reasons
behind this slow adoption of the MEF E-Access specification, and this Implementation
Agreement is designed to help the industry identify, and overcome these obstacles, resulting
in more Operators moving to E-Access compliance and at a quicker rate than witnessed today.
5.1 Factors Contributing to Slow MEF E-Access Adoption
The premise of this project is that the following factors contribute significantly to the above
picture:
1. Operators invested heavily in their Ethernet network infrastructure before the first
version of MEFs E-Access services were defined in MEF 33 (~2012), and therefore,
their network infrastructure may not have the functionality to fully meet the new
specifications. Specifically, they may need to upgrade their network hardware,
which could be a multi-million-dollar investment depending on the size of the Operator. (Older hardware may not support key features need to be instituted like S-Tag
encapsulation at the ENNI, Color Awareness, CoS mapping, CE-VLAN ID preservation, etc.)
2. In addition to network equipment, back office IT systems require substantial investment (multi-million depending on the size of the Operator) to accommodate the new
features required for E-Access. Specifically, the quote-to-cash IT systems upgrades
to support selling services across an ENNI could be a costly investment depending
on the Operator. For example, IT systems now need to track multiple TPID values
for the S-Tag (0x8100 and / or 0x88a8).
3. Operators may also have built out their first scalable Ethernet networks using Ethernet over SONET/ SDH to leverage their previous investment in TDM technology.
These platforms lack the functionality or upgrade path to enable MEF E-Access capabilities over a switched network.
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 13
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
The current market might be portrayed as a mixture of the following models:
Figure 3 – Current Marketplace Interconnect Models
The non-standard model (such as "Q-in-Q, etc.") represents networks using a "double C-tag"
interconnection, while the standard interconnection model represents the MEF E-Access
Services target. It is clear that both models will co-exist in the marketplace for many years,
while the relative populations will slowly change. The goal of this Implementation Agreement is to facilitate more rapid, systematic network interconnection strategies in such a
mixed environment.
5.2 Examples and Importance of TPIDS
As referenced in the examples below, Operators who have disparate TPID values cannot
create MEF ENNIs. They are forced to use non-standard interconnections that require a
great amount of testing and configuration between the two carriers. Each time the Operator
wants to create a new interconnection with one of the hundreds of other Operators touching
their footprint they need to start the process over again. Furthermore, if an Operator has a
customer (Subscriber) who has locations in two or more Operator footprints, the inconsistent implementations of interconnections can cause their network to not pass traffic correctly.
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 14
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
In Figure 4 below, Operator 5 moved to using a standard S-Tag encapsulation at the ENNI
(TPID 0x88a8) but the other Operators adjacent to its footprint did not. While Operator 5
moved to the new correct "industry standard" they are now isolated from connecting to the
Operators around them. Operator 5 is now an "Island" and cannot interconnect with other
Operators to create end-to-end services. In this instance moving to the standard actually
diminished their capacity to expand their Ethernet service.
Figure 4 – TPID Mismatch Isolation
In Figure 5 below both Operator 5 and Operator 3 have moved to the new MEF standard
and can now interconnect in an industry standard fashion and enjoy the benefits of E-Access
Services. However, they are still unable to connect with all the other Operators using nonstandard interconnections.
In Figure 6 below Operator 5 is able to create both MEF ENNIs and non-standard interconnections with the Operators adjacent to its footprint. Operator 5 has become "bi-lingual" and
has the greatest capacity to conduct business with either the thousands of Operators who use
non-standard interconnections, or the few who have moved to ENNIs. This is the best position for an Operator to be in while the market makes the transition to all Ethernet. Over
time, as more and more Operators adopt the MEF standard, Operators will eventually stop
creating non-standard interconnections.
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 15
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Figure 5 – TPID Limiting Operator
Figure 6 – Provisionable TPID - Bi-Lingual Operator
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 16
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
5.3 Learning About Interoperability from Actual Implementations
The MEF vision for Subscribers is a marketplace of many interconnected Operators offering
MEF standardized services that interoperate predictably, and can be compared using common terminology and measurement standards. However, with the current rate of MEF EAccess compliance, this vision is unlikely to be realized in the near future, leaving Operators today mired in the slow interconnect processes on the left of the continuum shown
above in Figure 1.
As an alternative, this project has proposed to learn from interconnecting a representative
portion of participating Operator's networks in a laboratory environment, to achieve the following objectives:
1. How to determine the maximum level of support for MEF services achievable given
the constraints of networks that may only meet a subset of Ethernet Access Services
Definition requirements.
2. Examine the challenges of using other MEF specifications such as Service OAM Fault Management (MEF 30.1) in cross - Operator deployments.
3. How to best inter-work MEF services from two Operators when there are mismatches in MEF Service Attributes values (such as CBS values, MTU values, CIR only
with CIR/EIR services, different CoS levels, different S-VLAN TPID values)
As Ethernet has evolved from a LAN to MAN to WAN services, Operators have been required to upgrade their backbones and IT support systems to keep pace. Figure 7 below attempts to provide a representation of how TPIDs and tagging have altered over time. While
the goal of this project is to help Operators reach full E-Access compliance, it's evident the
current global marketplace contains thousands of Operators that fit into one of the 4 stages
below. This project is creating a new stage, shown as "3.5", that helps Operators who cannot
reach Stage 4 (full E-Access compliance) in one step due to costs. While there is no market
data that accurately places the thousands of global Operators into the stages below, it is the
belief of the Operators leading this project that most fall into Stage 3.
Stage 3.5 allows for basic interconnection but does not allow Operators to take full advantage of the functionality that MEF E-Access brings (stage 4).
Each phase of the EIP project will use the rapid prototyping model to validate and refine an
initial set of Use Cases, Service Attribute specifications, and Test Cases until the project
feels that Stage 3.5 is ready for final documentation and a Letter Ballot. The series of Implementation Agreements will document the repeated cycle of:





MEF 54
Use Case development
Service Attribute values specification, and constrained ranges
Test case development based on the expected Use Case functionality
Laboratory testing with representative Operator networks in the IOL lab to verify the
expected Use Case functionality and interoperability
Feedback of lab testing results for refinement of Use Cases and Test Cases.
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 17
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
5.4 Illustrative Example of the Rapid Prototyping Process
To illustrate an example of the procedure in the above bullets:
Take the example of how to determine if a specific requirement, like 2-member LAG protection (active/standby) of the ENNI should be part of the Implementation Agreement (IA)
(it is optional for the MEF 26.1 specification).




A draft of the Use Case with Service attributes might initially include this 2- member LAG as a proposed requirement for the IA due to the need for high reliability on
a 10G ENNI and the number of customers affected by an outage.
A test case would be developed to test LAG between the Operators equipment in the
Interop Test lab, to see how difficult it was to get this LAG configuration to work
between different equipment vendors.
The results of testing various combinations, and lessons learned, would be summarized to the project team, and then the team would vote in a Call for Comments
(CfC) ballot whether to include that Use Case requirement in the IA going forward.
The results of the testing (summarized for privacy) and the CfC vote on the issue become part of the ongoing documentation of the IA. Each Use Case requirement decision in the IA would be documented with testing results and a CfC vote.
Figure 7 – Network Interconnection Evolution (TPID and Tagging Evolution Examples)
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 18
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
6. Use Cases and Scenarios
This IA will continue to evolve over time as new Use Cases are tested. The first use case is
an EPL service created between two Operators. See Section 7 for a complete list of test
cases and Appendix 1 for details of test cases.
6.1 Use Case 1 – Topology and Services Supported
The University of New Hampshire's Interoperability Lab, in Durham, NH, has created an
industry first test-bed allowing 6 large Operators to perform interconnection testing. All 6
Operators are being tested with each other with rapid feedback being fed directly to their respective Labs via a secure connection. Only the University of New Hampshire knows the
results of each provider’s test and facilitates the role of an independent and neutral tester.
The participating companies are active contributors on the EIP project and each Operator
used their respective CE equipment to re-create their actual network configurations in the
Lab. More information about the trial can be found at: http://www.mef.net/eipproject
University of New Hampshire’s Interoperability Lab
Figure 8 – University of New Hampshire's Interoperability Lab (Full test matrix not depicted)
Specifically, the testing at the UNH Lab is representative of what customers (Subscribers)
want in the real world - an Ethernet Private Line connecting two locations located in two
different carriers (Operator's) network's as per Figure 9 below.
6.1.1 Topology
EIP UC-1 Phase 1 supports point-to-point Carrier Ethernet services traversing exactly two
Operator domains. The Service Provider delivering the Carrier Ethernet service to the Subscriber is also one of the two Operators.
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 19
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Figure 9 – High Level Diagram of Use Case 1, Phase 1
6.1.2 Services
The end-to-end Carrier Ethernet service supported in Phase 1 is EPL (port based) - in other
words, the EIP UC-1 Phase 1 supports a Service Provider delivering a MEF EPL Service
between the two Subscriber sites.
The EPL is comprised of only two Access EPLs - one in each Operator domain. While only
one EPL is shown in the diagram for clarity, this Use Case will support multiple EPL instances across the same ENNI.
7. Test Cases
Section 7 provides the high level list of test cases for Phase 1 of the EIP project. The details
of the test cases are located in Appendix 1 of this guideline (included in CfC#1).
7.1 Service Configuration Test Cases





MEF 54
Test Case 1 – Frame Format
o Verifies that the frame format specified in IEEE Std 802.3 – 2012 and VLAN
Tags as defined in IEEE Std 802.1Q-2014 are supported
Test Case 2 – Service Mapping and CE-VLAN ID Preservation
o Verifies that the EIP solution supports all-to-one bundling with CE-VLAN
ID preservation enabled
Test Case 3 – CE-VLAN CoS Preservation
o Verifies that the EIP solution supports CE-VLAN CoS preservation enabled
Test Case 4 – Unicast, Multicast, Broadcast Frame Delivery
o Verifies the unconditional delivery of unicast, multicast and broadcast frames
Test Case 5 – Service and ENNI Maximum Frame Size – Minimum Supported Value
o Verifies the support of Service and ENNI maximum frame sizes of at least
1522 bytes and 1526 bytes, respectively
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 20
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement






Test Case 6 – Service and ENNI Maximum Frame Size - Maximum Supported Value
o Verifies the maximum Service and ENNI Maximum Frame Size values supported
Test Case 7 – Service and ENNI Frames exceeding the maximum size allowed for
the service
o Verifies that the receiving Operator network discards frames whose length
exceed the configured Maximum Frame Size at the UNI and/or at the ENNI
Test Case 8 – Service OAM Connectivity Check Messages (CCM) transparency
o Verifies that the EIP solution is configurable to forward Subscriber CCM
frames at MEG levels 5 & 6
Test Case 9 – Service OAM Multicast Loopback Messages (LBM) transparency
o Verifies that the EIP solution is configurable to forward Subscriber multicast
LBM frames at MEG levels 5 & 6
Test Case 10 – Service OAM Unicast Loopback Messages (LBM/LBR) transparency
o Verifies that the EIP solution is configurable to forward Subscriber unicast
LBM and LBR frames at MEG levels 5 & 6
Test Case 11 – Service OAM LinkTrace Messages (LTM/LTR) transparency
o Verifies that the EIP solution is configurable to forward Subscriber LTM and
LTR frames at MEG levels 5 & 6
7.2 Future Service Configuration Test Cases




Test Case 14 – Ingress Bandwidth Profile per CoS ID – Committed Information Rate
o Verifies that when an Ingress Bandwidth Profile per CoS ID is applied at the
UNI or at the ENNI, the amount of traffic delivered at the egress UNI or
ENNI is within the CIR tolerance range of the calculated amount of traffic
accepted at the ingress UNI or ENNI, during a time interval t
Test Case 15 – Ingress Bandwidth Profile per CoS ID – Committed Burst Size
o Verifies that when an Ingress Bandwidth Profile per CoS ID is applied at the
UNI or at the ENNI, the amount of Green traffic delivered at the egress UNI
or ENNI is within the CBS tolerance range of the calculated amount of traffic
accepted at the ingress UNI or ENNI, during a time interval t
Test Case 16 – Service Performance with constant traffic
o Verifies that the EIP solution meets the performance objectives defined in
MEF 23.1 for Performance Tier 1, CoS Label H, while carrying constant traffic
Test Case 17 – Service Performance with bursty traffic
o Verifies that the EIP solution meets the performance objectives defined in
MEF 23.1 for Performance Tier 1, CoS Label H, while carrying bursty traffic
7.3 L2CP Testing and Results
L2CP is a highly complex issue with great variability amongst carriers (Operators) and we
decided to perform testing to provide insights for the industry. Many customers will use
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 21
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
routers as their CPE and therefore diminish the importance of the service needing to forward
L2CP frames. However, some customers are still looking for a native layer 2 Ethernet
handoff that will require detailed information regarding L2CP behavior. Preliminary testing
of L2CP, based on MEF 45, has started in this first phase of the EIP project. L2CP testing
is planned to be completed during the subsequent phases of the project, and the testing is being done in alignment with the flow charts depicted in MEF 45 figure 6 and 7. A high level
example of L2CP testing at the UNI is depicted in the figure 10 below. Test Cases 12 and 13
were dedicated to L2CP Option 1 and Option 2 as follows:


Test Case 12 – L2CP Handling – Option 1
o Verifies that the EIP solution is configurable to support MEF 45 EPL Option
1 requirements
Test Case 13 – L2CP Handling – Option 2
o Verifies that the EIP solution is configurable to support MEF 45 EPL Option
2 requirements
Figure 10 – High Level Diagram of Use Case 1, Phase 1
A detailed table of the complete L2CP testing results can be found in Appendix II in this
guideline.
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 22
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Figure 11 – Operator 1 OVC Verification
8. Testing Environment
Each EIP test case is to be executed in a three step process. Step 1 verifies the Operator 1
OVC from the UNI to the ENNI and from the ENNI to the UNI; whereas step 2 verifies the
Operator 2 OVC from the UNI to the ENNI and from the ENNI to the UNI. Step 1 and step
2 may be executed in parallel.
Once the first two steps are verified, the two Operator networks are directly interconnected
at the ENNI and step 3 is executed. Step 3 verifies the end-to-end EVC service composed of
the two Operators OVCs. The following figures provide high level interconnection views of
the three step process:
8.1 Testing Summary
The testing at UNH yielded clear and immediate results. As predicted, the most salient technical challenge to overcome when interconnecting Operator Ethernet networks is ensuring
that the TPID of the outer tags mapped at the ENNI match at the EIP. There was no way to
configure an Ethernet service operating with a TPID value of 0x8100 to work with an
Ethernet network operating with a TPID value of 0x88a8 and vice-versa. As you'll see in
some of the other results, some Ethernet attributes can be altered to allow specific Operator
interconnection, but TPID values must match. See Figure 13 below.
Figure 12 – Operator 2 OVC Verification
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 23
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Figure 13 – Service Provider EVC Verification
We discovered that different equipment can have subtle differences in the way it handles
TPIDs. For example, all the gear tested properly handled both TPID values (0x8100 and
0x88a8), but one vendor may treat the TPID differently, under certain circumstances, (ingress vs. egress, etc.). Even a single vendor may sometimes inspect a frame on ingress, but
not care about the TPID value on egress at the ENNI. This can explain why some Operators
may find inexplicable, and unpredictable, Ethernet failures when creating Interconnections.
It's incumbent upon the Operator to know how their equipment handles TPID values on ingress and egress – whether single tagged, or dual tagged. Therefore, our testing has led us to
reinforce MEF's guideline to purchase equipment that is CE 2.0 certified for E-Access.
As seen in Figure 14, the 11 test cases conducted at the UNH Lab all passed regardless if the
Operators were all using TPID 0x8100 or all using 0x88a8. Armed with this knowledge, an
Operator can now take the next step on their journey towards creating a MEF ENNI (Per
Figure 7). If they are only capable of supporting TPID 0x8100, they can move to stage 3.5
(in Figure 7). If an Operator is capable of supporting 88a8, they can move to Stage 4, but it
Figure 14 – Summary of Test Results
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 24
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
is highly recommended they ensure they understand what stage their neighboring Operators
are at because they may need to remain "Bilingual" for a period of time as per Figure 6.
Each Operators "next step" may look slightly different. Some Operators may just be making
the transition from single tagging to dual tagging (Stage 2 to Stage 3). It's not the stage that's
important, but rather an Operator's understanding of where they are on their interconnection
journey, and that they begin planning their next step. This EIP project hopes to continue
more testing of more complex interconnection configurations in 2016.
9. Compliance Levels – More Detail Regarding Test Results
The requirements that apply to the functionality of this document are specified in the following sections. Items that are REQUIRED (contain the words MUST or MUST NOT) will
be labeled as [Rx]. Items that are RECOMMENDED (contain the words SHOULD or
SHOULD NOT) will be labeled as [Dx]. Items that are OPTIONAL (contain the words
MAY or OPTIONAL) will be labeled as [Ox].
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 use upper case,
bold text to distinguish them from other uses of the words. Any use of these key words (e.g.,
may and optional) without [Rx], [Dx] or [Ox] is not normative.
Based upon the testing we are able to make the following statements to assist Operators on
their journey to creating standardized MEF ENNIs.
For two Operators interconnected at an EIP to deliver EPL service to a customer the following statements are applicable:
1. Both Operators must use the same TPID for outer tag at the EIP, either 0x8100 or
0x88a8 using different TPIDs for outer tag results in dropped traffic at the EIP
(Demonstrated in Test Case 1)
2. Both Operators must support the frame format specified in IEEE Std. 802.3-2012 at
the UNI (Demonstrated in Test Case 1)
3. Both Operators must support all-to-one bundling with CE-VLAN preservation enabled (Demonstrated in Test Case 2)
4. Both Operators must support CE-VLAN CoS preservation (Demonstrated in Test
Case 3)
5. Both Operators must support the unconditional delivery of unicast, multicast, and
broadcast frames (Demonstrated in Test Case 4)
6. Both Operators must support the min MTU size of 1522 at UNI and min MTU size
of 1526 at ENNI (Demonstrated in Test Case 5)
7. Service Provider must inform the customer of the lower MTU size of both Operators; this will be the MTU size supported in end-to-end service (Demonstrated in
Test Case 6)
8. Each Operator must discard frames whose length exceeds the configured OVC MTU
size (Demonstrated in Test Case 7)
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 25
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
9. Both Operators must forward Subscriber CCM frames at MEG level 5 & 6 (Demonstrated in Test Case 8)
10. Both Operators must forward Subscriber multicast LBM frames at MEG level 5 & 6
(Demonstrated in Test Case 9)
11. Both Operators must forward Subscriber unicast LBM and LBR frames at MEG level 5 & 6 (Demonstrated in Test Case 10)
12. Both Operators must forward Subscriber unicast LTM and LTR frames at MEG level 5 & 6 (Demonstrated in Test Case 11)
10. Other Implementation Obstacles and Recommendations on how to
Overcome
10.1 Implementation Obstacles and Remediation – Tested in Lab
Given the inherent variability in the 6 Operators at the UNH Lab we immediately encountered obstacles that were preventing us from interconnecting. For example, some Operators
are color-aware, and some color blind, and some Operators offer CIR only and some offer
CIR and EIR values. Realizing that we'd need to use the “crawl, walk, run” approach we
employed the following tactics to hurdle these obstacles.
Number Obstacle Encountered
1
One Operator is Color
Blind and the Other Operator is Color Aware
2
One Operator has an
MTU size larger than the
Other Operator
Remediation
We used CIR only service; and not
EIR
We sent traffic with the minimum
MTU supported
3
How do you ensure that
both Operators use the
same value for the Outer
VLAN at the Interconnect Point?
During the testing UNH, UNH tester
selected the VLAN value for outer
tag and communicated it to both Operators; each Operator configured the
outer VLAN value
4
Operators did not support
the same set of CIR
speeds so how do we deliver requested CIR for
customer EPL service?
UNH tested common set of customer
EPL CIR supported by both Operators access services
Result
All frames are either marked
green or red – no need for color
awareness
Picking the minimum MTU ensured that all the Operators
passed all their frames in both
directions (ingress and egress)
Since both Operators have assigned the same outer VLAN
value (“21” for example) the
frames flowed across the ENNI
(or Non-Standard Interconnection) to the other Operator
Customer gets the requested CIR,
or a CIR that’s acceptable for
their needs
Table 4 – Implementation Obstacles – Tested in Lab
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 26
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
10.2 Possible Implementation Obstacles and Remediation – Not Tested
in Lab
Given the extraordinarily high level of technical expertise assembled for this project, we
were able to make some general assumptions about how an Operator can overcome some
common obstacles. Note we did not have time to test these assumptions in this round of testing, but the EIP team felt we'd be remiss if we didn't share this information now with the industry.
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 27
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Number
Obstacle
1
One of the Operators
does not support the CIR
required by the customer
2
Customer desires an EPL
service with the bandwidth profile of certain
CIR (C) and EIR (E); one
of the Operators supports
EIR but the other does
not
3
Operators desire to support Color Aware service
at EIP
4
CoS offerings differ for
each Operator (one of the
Operators is Service Provider)
5
How to overcome the
impact of the additional
4-bytes due to the Stagging at the EIP on
bandwidth delivered for
the customer's EPL service?
The Operator's CBS values did not match at their
respective UNIs for a
given EPL CIR
6
Remediation
This Operator should use the next higher
CIR they support so the requested EPL
bandwidth is delivered to the customer
Operator who does not support EIR
should provision the service with CIR =
(C + E)
Expected Results
Customer gets the required
CIR
Both Operators must support the same
Color Aware mechanism at EIP (DEI or
.1p bit of the outer tag); this applies to EIP
based on 0x88a8 TPID or 0x8100 TPID
There are other requirements needed for Color
Aware service; however, the
matching Color Aware
mechanism at the EIP is a
must
The requested end-to-end
CoS offering to the customer is delivered.
The Service Provider is responsible for
the end-to-end service to the customer.
Service Provider reviews Access Provider
CoS options and chooses the appropriate
Access Provider CoS offering to deliver
end-to-end service.
Policer values at the ENNI must be appropriately set to compensate for the additional 4 bytes, or an Operator could increase the CIR values at the EIP.
Operators can agree to use the same CBS
values, or they can use shapers to shape
their traffic at the EIP to conform with the
bandwidth profile used by the peer Operator
Customer gets EPL with
CIR (C) and EIR (E)
Customer gets the requested
CIR
Operator traffic flows correctly with fewer dropped
frames
Table 5 – Implementation Obstacles – Not Tested in Lab
11. Other EIP Items to Consider
As Operators continue their journey towards standardized interconnections (ENNI) there are
other non-technical items they will want to consider. This section of the document is meant
to act as a "thought provoker" to help ensure all aspects of Ethernet Interconnections are being considered.
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 28
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
11.1 EIP Location Planning – Where to Build?
Generally speaking, Operators will build Interconnections for one of two reasons: Customer
demand, or TDM shut down. In either case, Operators should study their networks and determine where the demand is and what their existing Fiber plant and Ethernet capabilities
are in the area where they wish to build an Interconnect. Note many times high-speed TDM
services are delivered on fiber that can be repurposed to support Ethernet Interconnections.
And as demand for TDM-based services continues to diminish, the likelihood of having
"spare" fiber in an area saturated with TDM increases. Strategic planning, network grooming, and capacity planning can negate the need to lay new fiber.
11.2 How Many EIPs Do We Need?
If an Operator's network is not constrained by regulatory restrictions such as LATA boundaries, the answer is a matter of distance and the level of Service Level Specifications (SLS)
the Operator wants to support. Operators should review the MEFs Service Level Specifications and corresponding “Performance Tiers” to determine how many EIPs are needed.
Generally speaking, the better the performance desired, the more EIPs an Operator will need
to build to reduce the distance data will need to travel to reach off-net locations. If an Operator's network is constrained by LATA boundaries, and there are rules in place to prevent
Ethernet traffic from leaving a LATA, it's likely an Operator may need to build an EIP at
every LATA that has customers who need to reach off-net locations.
11.3 How Does an Operator Determine What Ethernet Services Are
Available for Off-Net Locations?
Unlike TDM-based services, there is no third party, industry-wide database that can be used
to determine Ethernet capabilities for off-net locations. The most popular way for making
these determinations is by independent mutual cooperation between Operators. By way of
illustration, AT&T uses an internal group called “Access Management” whose primary purpose is to create Interconnection agreements with other Operators. This team populates internal databases that can be used by AT&T to support off-net sales. One of the tricky parts
to this is the need to determine the entire path of COs an EVC must pass through to reach
the customer. However, this way of doing business is not optimal, and there are several
MEF efforts being worked to make this easier including the SOC’s “Ethernet Serviceability” Project, Product Catalog Project, and LSO Project. There is agreement in the MEF that
determining off-net availability will be addressed in the future via APIs.
11.4 What Should an Operator Know About Ordering Ethernet Services?
There is great variability in the global market regarding how Ethernet Operators order services from each other. Using AT&T as an example, they have many different ways, processes, and systems to conduct its Ethernet business. This is a result of the variability seen
in the market with the Operators they want/need to conduct business with on behalf of their
customers. By way of illustration, some larger companies prefer to send an ASR (Access
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 29
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Service Request) directly from their systems to AT&T's. Some Operators require a site survey before an order will be accepted (known as a "service inquiry"), some Operators fill out
an ASR and email to them, and some Operators are still faxing orders. This variability
drives cost and complexity into a business, and underscores the need for the industry to
move to a commonly accepted ordering process that is highly automated. The MEF's LSO
project can be used as the starting point to move the industry into the future. In the meantime, Operators need to know the ASR form, understand the fields, and determine how to
send it to other Operators.
11.5 “Special Construction,” “Entrance Facility,” and “Inside Wire” –
What Does an Operator Need to Know?
No Implementation Agreement would be complete without the mention of “Special Construction,” “Entrance Facility,” and “Inside Wire.” They are three terms loathed by customers, sales teams, and Product Managers around the globe. As an Ethernet Operator you’ll
need to know the terms and know how to pay for and/or correctly bill your customers.
 Special Construction Charge – The construction cost in order to get your Ethernet
network (typically fiber) to the closest network termination point nearest to your
customer (typically a manhole, or vault). This charge could range from a few hundred dollars to a few million depending on the distance and terrain covered.
 Entrance Facility Charge – The construction cost in order to get your Ethernet network extended from your closest point (manhole) into the customer’s building's
MPOE (Minimum point of Entry).
 Inside Wire Charge – The construction charge to get your Ethernet network extended from the buildings MPOE to your customers CPE.
Typically, these are all one-time costs that Operators incur when they need to lay new fiber
to reach a customer, and are typically passed on to the end user customer (Subscriber).
Some Operators insist customers pay these charges upfront, and some Operators can set up
financing that will allow customers to pay for these costs over time. As more and more fiber
is laid in the market, the need for these charges will, thankfully, diminish over time.
11.6 Physical Equipment
Operators will need to understand their physical Ethernet network equipment to ensure it's
capable of supporting an EIP and at which stage as per Figure 7. The state of the hardware
can determine if a non-standard interconnection using dual C-Tags (0x8100/0x8100) will be
used, or if a standard ENNI can be constructed using a C-Tag and an S-Tag
(0x8100/0x88a8). Further investigation will uncover compliance to other E-Access attributes such as Color Awareness, C-VLAN preservation, etc. Operators should specifically
check to ensure they have 4 key questions in mind:
1. What does my network switch chassis support?
2. What do the network cards in my chassis support?
3. What version of operating system is my network gear using and does it support my
needs?
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 30
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
4. What distance will my data travel to reach the other Operator's switch at the other
side of the Interconnection – are short range or long range optics needed, and/or
some kind of repeater?
12. References
MEF Forum, MEF 26.1 Technical Specification “External Network Network Interface
(ENNI)-Phase 2,” January 2012
MEF Forum, MEF 33 Technical Specification “Ethernet Access Services Definition,” January 2012
MEF Forum, MEF 12.2 Technical Specification “Carrier Ethernet Network Architecture
Framework Part 2: Ethernet Services Layer,” May 2014
MEF Forum, MEF 10.3 Technical Specification “Ethernet Service Attributes Phase 3,” October 2013
MEF Forum, MEF 4 Technical Specification “Metro Ethernet Architecture Framework –
Part 1: Generic Framework,” May 2004
RFC 2474 “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers,” 1998
ITU-T Y.1564 “Ethernet service activation test methodology,” 03/2011
ITU-T G.8264/Y.1364 “Distribution of timing information through packet networks,”
05/2014
IEEE Std 802.1AX-2008, IEEE Standard for Local and metropolitan area networks-Link
Aggregation, 3 November 2008
IEEE 802.1Q -2011, IEEE Standard for Local and Metropolitan Area Networks-Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks, 2011
IEEE Std 802.3-2012, IEEE Standard for Ethernet, 28 December 2012 (normative)
MEF Forum, MEF 10.1 Technical Specification “Ethernet Services Attributes Phase 1,”
November 2006
MEF Forum, MEF 23.1 Implementation Agreement “Carrier Ethernet Class of Service –
Phase 2,” January 2012
MEF Forum, MEF 16 Technical Specification “Ethernet Local Management Interface (ELMI),” January 2006
MEF Forum, MEF 6.1 Technical Specification “Ethernet Services Definitions – Phase 2,”
April 2008
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 31
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
MEF Forum, MEF 10.2 Technical Specification “Ethernet Services Attributes Phase 2,” 27
October 2009
MEF Forum, MEF 20 Technical Specification “User Network Interface (UNI) Type 2 Implementation Agreement,” July 2008
MEF Forum, MEF 30 Technical Specification “Service OAM Fault Management Implementation Agreement,” January 2011
MEF Forum, MEF 34 Technical Specification “Abstract Test Suite for Ethernet Access Services,” February 2012
MEF Forum, MEF 37 Technical Specification “Abstract Test Suite for ENNI,” January
2012
MEF Forum, MEF 6.2 Technical Specification “EVC Ethernet Services Definitions Phase
3,” August 2013
MEF Forum, MEF 45 Technical Specification “Multi-CEN L2CP,” August 2013
MEF Forum, MEF 30.1 Technical Specification “Service OAM Fault Management Implementation Agreement: Phase 2,” April 2013
IETF RFC 2119, Key words for use in RFCs to Indicate Requirement Levels, March 1997.
13. Acknowledgements
This document was prepared by contributions from the following members of the MEF Service Operations Committee:
 Dan Blemings, AT&T (Lead Editor)
 Elzbieta Napierala, AT&T (Editor)
 John Siwko, AT&T (Editor)
 Steve Holmgren, AT&T (Editor)
 Bruce Eldridge, CenturyLink (Editor)
 Lisa Partridge, Frontier (Editor)
 Bill Bjorkman, MEF (Editor)
 Lee Jorissen, TelePacific (Editor)
 Tim Sheehan, University of New Hampshire Interoperability Lab (Editor Test Cases)
 Steve Cole, Verizon (Editor)
 Michael Lefevre, Windstream (Editor)
 Isabelle Morency, Veryx Technologies (Editor Test Cases)
Member Company
Alcatel Lucent (Equipment and Personnel)
MEF 54
Participant in IOL Test Trial
Yes
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 32
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
AT&T (Personnel)
Yes
CenturyLink (Personnel)
Yes
Ciena (Equipment and Personnel)
Yes
Cisco (Equipment and Personnel)
Yes
Canoga Perkins (Equipment and Personnel)
Yes
Juniper (Equipment and Personnel)
Yes
Frontier (Personnel)
Yes
RAD (Equipment and Personnel)
Yes
TelePacific (Personnel)
Yes
University of New Hampshire Interoperability Lab
(Equipment, Personnel, and Facility)
Yes
Verizon (Personnel)
Yes
Veryx (Equipment and Personnel)
Yes
Windstream (Personnel)
Yes
14. Appendix I – Test Cases for EIP Use Case 1 Phase 1
This appendix contains a series of test cases to verify the service configuration and service
performance of the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1.
Test Case 1 – Frame Format
Interconnection
Partners
Operator 1 Name:


Requirements

Operator 2 Name:
At the UNI, the frame format MUST be as specified in IEEE Std 802.3-2012
An ENNI Frame can have zero or more VLAN tags. When an ENNI Frame has a single tag, that tag is an STag.
When an ENNI Frame has two tags, the outer tag is an S-Tag and the next tag is a C-Tag as defined in IEEE
Std 802.1Q-2014
References
EIP Use Case 1 – Service Attribute Values and Ranges
Test Purpose
Verify that the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 supports the frame format specified
in IEEE Std 802.3-2012 and VLAN Tags as defined in IEEE Std 802.1Q-2014
Step 1
Operator 1 – OVC Verification [UNI U1 to ENNI E1]
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 33
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Test Bed and
Service Mapping Step 1
UNI U1
1, 2…4095*
OVC End Point
* Mapping at the UNI U1 includes untagged and priority tagged frames
ENNI E1
100
Test Procedure
Step 1
OVC End Point
1.1
Tester T1 transmits C-tagged, untagged and priority tagged frames to the Operator 1 UNI U1
1.2
Tester T2 verifies that all the transmitted frames are received at the Operator 1 ENNI E1, encapsulated in the
outer tag mapped at the ENNI E1, and that the outer tag TPID value is 88a8
1.3
Tester T2 transmits C-tagged, untagged and priority tagged frames, encapsulated in the outer tag mapped at the
ENNI E1, to the Operator 1 ENNI E1
1.4
Tester T1 verifies that all the transmitted frames are received at the Operator 1 UNI U1 without the outer tag
and that the TPID value of the tagged frames is 0x8100
Operator 2 – OVC Verification [UNI U2 to ENNI E2]
Step 2
Test Bed and
Service Mapping Step 2
UNI U2
1, 2…4095*
OVC End Point
* Mapping at the UNI U2 includes untagged and priority tagged frames
ENNI E2
100
MEF 54
OVC End Point
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 34
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Test Procedure
Step 2
Step 3
2.1
Tester T3 transmits C-tagged, untagged and priority tagged frames to the Operator 2 UNI U2
2.2
Tester T2 verifies that all the transmitted frames are received at the Operator 2 ENNI E2, encapsulated in the
outer tag mapped at the ENNI E2, and that the outer tag TPID value is 0x88a8
2.3
Tester T2 transmits C-tagged, untagged and priority tagged frames, encapsulated in the outer tag mapped at the
ENNI E2, to the Operator 2 ENNI E2
2.4
Tester T3 verifies that all the transmitted frames are received at the Operator 2 UNI U2 without the outer tag,
and that the TPID value of the tagged frames is 0x8100
Service Provider EVC [UNI U1 to UNI U2]
Test Bed and
Service Mapping Step 3
UNI U1
1, 2…4095*
EVC
* Mapping at the UNI U1 includes untagged and priority tagged frames
UNI U2
1, 2…4095*
EVC
* Mapping at the UNI U2 includes untagged and priority tagged frames
Test Procedure
Step 3
Test Result
3.1
Disconnect tester T2 from ENNI E1 and from ENNI E2 and interconnect them directly
3.2
Tester T1 transmits C-tagged, untagged and priority tagged frames to the Operator 1 UNI U1
3.3
Tester T3 verifies that all the transmitted frames are received at the Operator 2 UNI U2 and that the TPID
value of the tagged frames is 8100
3.4
Tester T3 transmits C-tagged, untagged and priority tagged frames to the Operator 2 UNI U2
3.5
Tester T1 verifies that all the transmitted frames are received at the Operator 1 UNI U1 and that the TPID
value of the tagged frames is 8100
Test case passes if the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 supports the frame format
specified in IEEE Std 802.3-2012 and VLAN Tags as defined in IEEE Std 802.1Q-2014 as verified in steps 1.2, 1.4,
2.2, 2.4, 3.3, and 3.5

Test Traffic
and Frame Size

Comment
At the UNI: 10 x 80-byte unicast C-tagged frames, 10 x 80-byte unicast priority tagged frames and 10 x 80byte unicast untagged frames
At the ENNI: 10 x 84-byte unicast C-tagged frames encapsulated in the outer tag mapped at the ENNI, 10 x
84-byte unicast priority tagged frames encapsulated in the outer tag mapped at the ENNI and 10 x 84-byte
unicast untagged frames encapsulated in the outer tag mapped at the ENNI
Any nonconformance observed in either step 1.2, 1.4, 2.2, 2.4, 3.3, or 3.5 such as the TPID of the outer tag, will be
clearly identified and described in the test report
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 35
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Test Case 2 – Service Mapping and CE-VLAN ID Preservation
Interconnection
Partners
Operator 1 Name:





Requirements
Operator 2 Name:
The CE-VLAN ID/EVC map MUST map all CE-VLAN IDs
All-to-one bundling MUST be enabled
CE-VLAN ID preservation MUST be enabled
The OVC End Point map MUST align to the CE-VLAN ID/EVC map
The OVC CE-VLAN ID preservation attribute MUST align to the EVC CE-VLAN ID preservation attribute
References
EIP Use Case 1 – Service Attribute Values and Ranges
Test Purpose
Verify that the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 sup-ports all-to-one bundling with
CE-VLAN ID preservation enabled
Step 1
Operator 1 – OVC Verification [UNI U1 to ENNI E1]
Test Bed and
Service Mapping Step 1
UNI U1
1, 2…4095*
OVC End Point
* Mapping at the UNI U1 includes untagged and priority tagged frames
ENNI E1
100
Test Procedure
Step 1
Step 2
OVC End Point
1.1
Tester T1 transmits untagged, priority tagged, and C-tagged frames with all CE-VLAN IDs to the Operator 1
UNI U1
1.2
Tester T2 verifies that all the transmitted frames are received at the Operator 1 ENNI E1, encapsulated in the
outer tag mapped at the ENNI E1, and that all CE-VLAN IDs are preserved
1.3
Tester T2 transmits untagged, priority tagged, and C-tagged frames with all CE-VLAN IDs, encapsulated in the
outer tag mapped at the ENNI E1, to the Opera-tor 1 ENNI E1
1.4
Tester T1 verifies that all the transmitted frames are received at the Operator 1 UNI U1 without the outer tag
and that all CE-VLAN IDs are preserved
Operator 2 – OVC Verification [UNI U2 to ENNI E2]
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 36
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Test Bed and
Service Mapping Step 2
UNI U2
1, 2…4095*
OVC End Point
* Mapping at the UNI U2 includes untagged and priority tagged frames
ENNI E2
100
Test Procedure
Step 2
Step 3
OVC End Point
2.1
Tester T3 transmits untagged, priority tagged, and C-tagged frames with all CE-VLAN IDs to the Operator 2
UNI U2
2.2
Tester T2 verifies that all the transmitted frames are received at the Operator 2 ENNI E2, encapsulated in the
outer tag mapped at the ENNI E2, and that all CE-VLAN IDs are preserved
2.3
Tester T2 transmits untagged, priority tagged, and C-tagged frames with all CE-VLAN IDs, encapsulated in the
outer tag mapped at the ENNI E2, to the Opera-tor 2 ENNI E2
2.4
Tester T3 verifies that all the transmitted frames are received at the Operator 2 UNI U2 without the outer tag,
and that all CE-VLAN IDs are preserved
Service Provider EVC [UNI U1 to UNI U2]
Test Bed and
Service Mapping Step 3
UNI U1
1, 2…4095*
EVC
* Mapping at the UNI U1 includes untagged and priority tagged frames
UNI U2
1, 2…4095*
EVC
* Mapping at the UNI U2 includes untagged and priority tagged frames
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 37
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Test Procedure
Step 3
Test Result
3.1
Disconnect tester T2 from ENNI E1 and from ENNI E2 and interconnect them directly
3.2
Tester T1 transmits untagged, priority tagged, and C-tagged frames with all CE-VLAN IDs to the Operator 1
UNI U1
3.3
Tester T3 verifies that all the transmitted frames are received at the Operator 2 UNI U2 and that all CE-VLAN
IDs are preserved
3.4
Tester T3 transmits untagged, priority tagged, and C-tagged frames with all CE-VLAN IDs to the Operator 2
UNI U2
3.5
Tester T1 verifies that all the transmitted frames are received at the Operator 1 UNI U1 and that all CE-VLAN
IDs are preserved
Test case passes if the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 supports all-to-one bundling
with CE-VLAN ID preservation enabled as verified in steps 1.2, 1.4, 2.2, 2.4, 3.3, and 3.5

Test Traffic
and Frame Size

Comment
At the UNI: 10 x 80-byte unicast C-tagged frames of each CE-VLAN ID, 10 x 80-byte unicast priority
tagged frames and 10 x 80-byte unicast untagged frames
At the ENNI: 10 x 84-byte unicast C-tagged frames of each CE-VLAN ID encapsulated in the outer tag
mapped at the ENNI, 10 x 84-byte unicast priority tagged frames encapsulated in the outer tag mapped at the
ENNI and 10 x 84-byte unicast untagged frames encapsulated in the outer tag mapped at the ENNI
Any nonconformance observed in either step 1.2, 1.4, 2.2, 2.4, 3.3, or 3.5 will be clearly identified and described in
the test report
Test Case 3 – CE-VLAN CoS Preservation
Interconnection
Partners
Operator 1 Name:


Requirements
Operator 2 Name:
The CE-VLAN CoS preservation MUST be enabled for the EVC
The CE-VLAN CoS ID parameters and values of the OVC MUST align to the CE-VLAN CoS preservation
parameters and values of the EVC
References
EIP Use Case 1 – Service Attribute Values and Ranges
Test Purpose
Verify that the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 supports CE-VLAN CoS preservation enabled
Step 1
Operator 1 – OVC Verification [UNI U1 to ENNI E1]
Test Bed and
Service Mapping Step 1
UNI U1
1, 2…4095*
MEF 54
OVC End Point
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 38
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
* Mapping at the UNI U1 includes untagged and priority tagged frames
ENNI E1
100
Test Procedure
Step 1
OVC End Point
1.1
Tester T1 transmits C-tagged frames with all CE-VLAN CoS (PCP bits with values 0-7), to the Operator 1 UNI
U1
1.2
Tester T2 verifies that all the transmitted frames are received at the Operator 1 ENNI E1, encapsulated in the
outer tag mapped at the ENNI E1, and that all CE-VLAN CoS are preserved
1.3
Tester T2 transmits C-tagged frames with all CE-VLAN CoS (PCP bits with values 0-7), encapsulated in the
outer tag mapped at the ENNI E1, to the Operator 1 ENNI E1
1.4
Tester T1 verifies that all the transmitted frames are received at the Operator 1 UNI U1 without the outer tag
and that all CE-VLAN CoS are preserved
Operator 2 – OVC Verification [UNI U2 to ENNI E2]
Step 2
Test Bed and
Service Mapping Step 2
UNI U2
1, 2…4095*
OVC End Point
* Mapping at the UNI U2 includes untagged and priority tagged frames
ENNI E2
100
Test Procedure
Step 2
OVC End Point
2.1
Tester T3 transmits C-tagged frames with all CE-VLAN CoS (PCP bits with values 0-7), to the Operator 2 UNI
U2
2.2
Tester T2 verifies that all the transmitted frames are received at the Operator 2 ENNI E2, encapsulated in the
outer tag mapped at the ENNI E2, and that all CE-VLAN CoS are preserved
2.3
Tester T2 transmits C-tagged frames with all CE-VLAN CoS (PCP bits with values 0-7), encapsulated in the
outer tag mapped at the ENNI E2, to the Operator 2 ENNI E2
2.4
Tester T3 verifies that all the transmitted frames are received at the Operator 2 UNI U2 without the outer tag,
and that all CE-VLAN CoS are preserved
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 39
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Step 3
Service Provider EVC [UNI U1 to UNI U2]
Test Bed and
Service Mapping Step 3
UNI U1
1, 2…4095*
EVC
* Mapping at the UNI U1 includes untagged and priority tagged frames
UNI U2
1, 2…4095*
EVC
* Mapping at the UNI U2 includes untagged and priority tagged frames
Test Procedure
Step 3
Test Result
3.1
Disconnect tester T2 from ENNI E1 and from ENNI E2 and interconnect them directly
3.2
Tester T1 transmits C-tagged frames with all CE-VLAN CoS (PCP bit 0-7), to the Operator 1 UNI U1
3.3
Tester T3 verifies that all the transmitted frames are received at the Operator 2 UNI U2 and that all CE-VLAN
CoS are preserved
3.4
Tester T3 transmits C-tagged frames with all CE-VLAN CoS (PCP bit 0-7), to the Operator 2 UNI U2
3.5
Tester T1 verifies that all the transmitted frames are received at the Operator 1 UNI U1 and that all CE-VLAN
CoS are preserved
Test case passes if the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 supports CE-VLAN CoS
preservation enabled as verified in steps 1.2, 1.4, 2.2, 2.4, 3.3, and 3.5


Test Traffic
and Frame Size
Comment
At the UNI: 10 x 80-byte unicast C-tagged frames of each CE-VLAN CoS
At the ENNI: 10 x 84-byte unicast C-tagged frames of each CE-VLAN CoS encapsulated in the outer tag
mapped at the ENNI
Any nonconformance observed in either step 1.2, 1.4, 2.2, 2.4, 3.3, or 3.5 will be clearly identified and described in
the test report
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 40
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Test Case 4 – Unicast, Multicast, and Broadcast Frame Delivery
Interconnection
Partners
Operator 1 Name:

Requirements
Operator 2 Name:
Unicast, multicast, and broadcast frame delivery MUST be unconditional
References
EIP Use Case 1 – Service Attribute Values and Ranges
Test Purpose
Verify that the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 supports the unconditional delivery
of unicast, multicast, and broadcast frames.
Step 1
Operator 1 – OVC Verification [UNI U1 to ENNI E1]
Test Bed and
Service Mapping Step 1
UNI U1
1, 2…4095*
OVC End Point
* Mapping at the UNI U1 includes untagged and priority tagged frames
ENNI E1
100
Test Procedure
Step 1
Step 2
OVC End Point
1.1
Tester T1 transmits C-tagged frames with unicast, multicast, and broadcast destination addresses, up to the CIR
configured at the UNI, to the Operator 1 UNI U1
1.2
Tester T2 verifies that all the transmitted unicast, multicast, and broadcast frames are received at the Operator 1
ENNI E1, encapsulated in the outer tag mapped at the ENNI E1
1.3
Tester T2 transmits C-tagged frames with unicast, multicast, and broadcast destination addresses, encapsulated
in the outer tag mapped at the ENNI E1, up to the CIR configured at the ENNI, to the Operator 1 ENNI E1
1.4
Tester T1 verifies that all the transmitted unicast, multicast, and broadcast frames are received at the Operator 1
UNI U1 without the outer tag
Operator 2 – OVC Verification [UNI U2 to ENNI E2]
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 41
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Test Bed and
Service Mapping Step 2
UNI U2
1, 2…4095*
OVC End Point
* Mapping at the UNI U2 includes untagged and priority tagged frames
ENNI E2
100
Test Procedure
Step 2
Step 3
OVC End Point
2.1
Tester T3 transmits C-tagged frames with unicast, multicast, and broadcast destination addresses, up to the CIR
configured at the UNI to the Operator 2 UNI U2
2.2
Tester T2 verifies that all the transmitted unicast, multicast, and broadcast frames are received at the Operator 2
ENNI E2, encapsulated in the outer tag mapped at the ENNI E2
2.3
Tester T2 transmits C-tagged frames with unicast, multicast, and broadcast destination addresses, encapsulated
in the outer tag mapped at the ENNI E2, up to the CIR configured at the ENNI, to the Operator 2 ENNI E2
2.4
Tester T3 verifies that all the transmitted unicast, multicast, and broadcast frames are received at the Operator 2
UNI U2 without the outer tag
Service Provider EVC [UNI U1 to UNI U2]
Test Bed and
Service Mapping Step 3
UNI U1
1, 2…4095*
EVC
* Mapping at the UNI U1 includes untagged and priority tagged frames
UNI U2
1, 2…4095*
EVC
* Mapping at the UNI U2 includes untagged and priority tagged frames
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 42
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Test Procedure
Step 3
Test Result
3.1
Disconnect tester T2 from ENNI E1 and from ENNI E2 and interconnect them directly
3.2
Tester T1 transmits C-tagged frames with unicast, multicast, and broadcast destination addresses, up to the
CIR configured at the UNI to the Operator 1 UNI U1
3.3
Tester T3 verifies that all the transmitted unicast, multicast, and broadcast frames are received at the Operator
2 UNI U2
3.4
Tester T3 transmits C-tagged frames with unicast, multicast, and broadcast destination addresses, up to the
CIR configured at the UNI to the Operator 2 UNI U2
3.5
Tester T1 verifies that all the transmitted unicast, multicast, and broadcast frames are received at the Operator
1 UNI U1
Test case passes if the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 supports the unconditional
delivery of unicast, multicast, and broadcast frames as verified in steps 1.2, 1.4, 2.2, 2.4, 3.3, and 3.5

Test Traffic
and Frame Size

Comment
At the UNI: 10 x 80-byte unicast C-tagged frames, 10 x 80-byte multicast C-tagged frames, and 10 x 80-byte
broadcast C-tagged frames
At the ENNI: 10 x 84-byte unicast C-tagged frames encapsulated in the outer tag mapped at the ENNI, 10 x
84-byte multicast C-tagged frames encapsulated in the outer tag mapped at the ENNI and 10 x 84-byte
broadcast C-tagged frames encapsulated in the outer tag mapped at the ENNI
Any nonconformance observed in either step 1.2, 1.4, 2.2, 2.4, 3.3, or 3.5 will be clearly identified and described in
the test report
Test Case 5 – Service and ENNI Maximum Frame Size – Minimum Supported Value
Interconnection
Partners
Operator 1 Name:




Requirements
Operator 2 Name:
The UNI Maximum Frame Service Size MUST be at least 1522 bytes
The EVC Maximum Frame Service Size MUST be at least 1522 bytes
The ENNI MTU Size MUST be at least 1526 bytes
The OVC MTU Size MUST be at least 1526 bytes
References
EIP Use Case 1 – Service Attribute Values and Ranges
Test Purpose
Verify that the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 supports Service and ENNI maximum frame sizes of at least 1522 bytes and 1526 bytes respectively
Step 1
Operator 1 – OVC Verification [UNI U1 to ENNI E1]
Test Bed and
Service Mapping Step 1
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 43
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
UNI U1
1, 2…4095*
OVC End Point
* Mapping at the UNI U1 includes untagged and priority tagged frames
ENNI E1
100
Test Procedure
Step 1
OVC End Point
1.1
Tester T1 transmits C-tagged frames of 1522 bytes to the Operator 1 UNI U1
1.2
Tester T2 verifies that all the transmitted frames are received at the Operator 1 ENNI E1, encapsulated in the
outer tag mapped at the ENNI E1
1.3
Tester T2 transmits C-tagged frames encapsulated in the outer tag mapped at the ENNI E1, of size 1526 bytes to
the Operator 1 ENNI E1
1.4
Tester T1 verifies that all the transmitted frames are received at the Operator 1 UNI U1 without the outer tag
Operator 2 – OVC Verification [UNI U2 to ENNI E2]
Step 2
Test Bed and
Service Mapping Step 2
UNI U2
1, 2…4095*
OVC End Point
* Mapping at the UNI U2 includes untagged and priority tagged frames
ENNI E2
100
Test Procedure
Step 2
OVC End Point
2.1
Tester T3 transmits C-tagged frames of 1522 bytes to the Operator 2 UNI U2
2.2
Tester T2 verifies that all the transmitted frames are received at the Operator 2 ENNI E2, encapsulated in the
outer tag mapped at the ENNI E2
2.3
Tester T2 transmits C-tagged frames encapsulated in the outer tag mapped at the ENNI E2, of size 1526 bytes to
the Operator 2 ENNI E2
2.4
Tester T3 verifies that all the transmitted frames are received at the Operator 2 UNI U2 without the outer tag
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 44
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Step 3
Service Provider EVC [UNI U1 to UNI U2]
Test Bed and
Service Mapping Step 3
UNI U1
1, 2…4095*
EVC
* Mapping at the UNI U1 includes untagged and priority tagged frames
UNI U2
1, 2…4095*
EVC
* Mapping at the UNI U2 includes untagged and priority tagged frames
Test Procedure
Step 3
Test Result
3.1
Disconnect tester T2 from ENNI E1 and from ENNI E2 and interconnect them directly
3.2
Tester T1 transmits C-tagged frames of 1522 bytes to the Operator 1 UNI U1
3.3
Tester T3 verifies that all the transmitted frames are received at the Operator 2 UNI U2
3.4
Tester T3 transmits C-tagged frames of 1522 bytes to the Operator 2 UNI U2
3.5
Tester T1 verifies that all the transmitted frames are received at the Operator 1 UNI U1
Test case passes if the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 supports Service and ENNI
maximum frame sizes of at least 1522 bytes and 1526 bytes respectively as verified in steps 1.2, 1.4, 2.2, 2.4, 3.3, and
3.5


Test Traffic
and Frame Size
Comment
At the UNI: 10 x 1522-byte unicast C-tagged frames
At the ENNI: 10 x 1526-byte unicast C-tagged frames encapsulated in the outer tag mapped at the ENNI
Any nonconformance observed in either step 1.2, 1.4, 2.2, 2.4, 3.3, or 3.5 will be clearly identified and described in
the test report
Test Case 6 – Service and ENNI Maximum Frame Size – Maximum Supported Value
Interconnection
Partners
Operator 1 Name:




Requirements
Operator 2 Name:
The UNI Maximum Frame Service Size MUST be at least 1522 bytes
The EVC Maximum Frame Service Size MUST be at least 1522 bytes
The ENNI MTU Size MUST be at least 1526 bytes
The OVC MTU Size MUST be at least 1526 bytes
References
EIP Use Case 1 – Service Attribute Values and Ranges
Test Purpose
Verify the maximum Service and ENNI Maximum Frame Size values supported by the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 45
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Operator 1 – OVC Verification [UNI U1 to ENNI E1]
Step 1
Test Bed and
Service Mapping Step 1
UNI U1
1, 2…4095*
OVC End Point
* Mapping at the UNI U1 includes untagged and priority tagged frames
ENNI E1
100
Test Procedure
Step 1
OVC End Point
1.1
Operator 1 configures the Maximum Frame Size at the UNI U1 and ENNI E1 equal to the maximum supported
values
1.2
Tester T1 transmits C-tagged frames of size equal to the configured UNI Maximum Service Frame Size to the
Operator 1 UNI U1
1.3
Tester T2 verifies that all the transmitted frames are received at the Operator 1 ENNI E1, encapsulated in the
outer tag mapped at the ENNI E1
1.4
Tester T2 transmits C-tagged frames encapsulated in the outer tag mapped at the ENNI E1, of size equal to the
configured Maximum ENNI Frame Size to the Operator 1 ENNI E1
1.5
Tester T1 verifies that all of the transmitted frames are received at the Operator 1 UNI U1, without the outer tag
Operator 2 – OVC Verification [UNI U2 to ENNI E2]
Step 2
Test Bed and
Service Mapping Step 2
UNI U2
1, 2…4095*
OVC End Point
* Mapping at the UNI U2 includes untagged and priority tagged frames
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 46
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
ENNI E2
100
Test Procedure
Step 2
Step 3
OVC End Point
2.1
Operator 2 configures the Maximum Frame Size at the UNI U2 and ENNI E2 equal to the maximum supported
values
2.2
Tester T3 transmits C-tagged frames of size equal to the configured UNI Maximum Service Frame Size to the
Operator 2 UNI U2
2.3
Tester T2 verifies that all the transmitted frames are received at the Operator 2 ENNI E2, encapsulated in the
outer tag mapped at the ENNI E2
2.4
Tester T2 transmits C-tagged frames encapsulated in the outer tag mapped at the ENNI E2, of size equal to the
configured Maximum ENNI Frame Size to the Operator 2 ENNI E2
2.5
Tester T3 verifies that all of the transmitted frames are received at the Operator 2 UNI U2, without the outer tag
Service Provider EVC [UNI U1 to UNI U2]
Test Bed and
Service Mapping Step 3
UNI U1
1, 2…4095*
EVC
* Mapping at the UNI U1 includes untagged and priority tagged frames
UNI U2
1, 2…4095*
EVC
* Mapping at the UNI U2 includes untagged and priority tagged frames
Test Procedure
Step 3
Test Result
3.1
Disconnect tester T2 from ENNI E1 and from ENNI E2 and interconnect them directly
3.2
Tester T1 transmits C-tagged frames of size equal to the configured UNI Maximum Service Frame Size to the
Operator 1 UNI U1
3.3
Tester T3 verifies that all of the transmitted frames are received at the Operator 2 UNI U2
3.4
Tester T3 transmits C-tagged frames of size equal to the configured UNI Maximum Service Frame Size to the
Operator 2 UNI U2
3.5
Tester T1 verifies that all of the transmitted frames are received at the Operator 1 UNI U1
Test case passes if the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 supports the maximum Service and ENNI maximum frame size as verified in steps 1.3, 1.5, 2.3, 2.5, 3.3, and 3.5
Test Traffic
and Frame Size
MEF 54


At the UNI: 10 unicast C-tagged frames of each size specified in the test procedure
At the ENNI: 10 unicast C-tagged frames encapsulated in the outer tag mapped at the ENNI of each size
specified in the test procedure
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 47
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Comment
Any nonconformance observed in either step 1.3, 1.5, 2.3, 2.5, 3.3, or 3.5 will be clearly identified and described in
the test report
Test Case 7 – Service and ENNI Frames Exceeding the Maximum Size Allowed for the Service
Interconnection
Partners
Operator 1 Name:

Requirements


Operator 2 Name:
When an ENNI Frame or a Service Frame is larger than the OVC MTU Size of the OVC associating the
OVC End Point to which it is mapped, the receiving Operator for this frame MUST discard it, and the operation of a Bandwidth Profile, if any, that applies to this frame is not defined
An ingress Tagged Service Frame that is mapped to the EVC and whose length exceeds the EVC Maximum
Service Frame Size SHOULD be discarded
An ingress Untagged Service Frame that is mapped to the EVC and whose length exceeds the EVC Maximum Service Frame Size minus 4 SHOULD be discarded
References
EIP Use Case 1 – Service Attribute Values and Ranges
Test Purpose
Verify that the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 discards frames whose length exceed
the configured Maximum Frame Size at the UNI and/or at the ENNI
Step 1
Operator 1 – OVC Verification [UNI U1 to ENNI E1]
Test Bed and
Service Mapping Step 1
UNI U1
1, 2…4095*
OVC End Point
* Mapping at the UNI U1 includes untagged and priority tagged frames
ENNI E1
100
Test Procedure
Step 1
OVC End Point
1.1
Operator 1 configures the Maximum Frame Size at UNI U1 and ENNI E1
1.2
Tester T1 transmits C-tagged frames whose size exceed the configured UNI Maximum Service Frame Size, to
the Operator 1 UNI U1
1.3
Tester T2 verifies that none the transmitted frames are received at the Operator 1 ENNI E1
1.4
Tester T2 transmits C-tagged frames encapsulated in the outer tag mapped at the ENNI E1, whose size exceed
the configured Maximum ENNI Frame Size, to the Operator 1 ENNI E1
1.5
Tester T1 verifies that none of the transmitted frames are received at the Operator 1 UNI U1
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 48
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Operator 2 – OVC Verification [UNI U2 to ENNI E2]
Step 2
Test Bed and
Service Mapping Step 2
UNI U2
1, 2…4095*
OVC End Point
* Mapping at the UNI U2 includes untagged and priority tagged frames
ENNI E2
100
Test Procedure
Step 2
Step 3
OVC End Point
2.1
Operator 2 configures the Maximum Frame Size at UNI U2 and ENNI E2
2.2
Tester T3 transmits C-tagged frames whose size exceed the configured UNI Maximum Service Frame Size, to
the Operator 2 UNI U2
2.3
Tester T2 verifies that none the transmitted frames are received at the Operator 2 ENNI E2
2.4
Tester T2 transmits C-tagged frames encapsulated in the outer tag mapped at the ENNI E2, whose size exceed
the configured Maximum ENNI Frame Size, to the Operator 2 ENNI E2
2.5
Tester T3 verifies that none of the transmitted frames are received at the Operator 2 UNI U2
Service Provider EVC [UNI U1 to UNI U2]
Test Bed and
Service Mapping Step 3
UNI U1
1, 2…4095*
EVC
* Mapping at the UNI U1 includes untagged and priority tagged frames
UNI U2
1, 2…4095*
EVC
* Mapping at the UNI U2 includes untagged and priority tagged frames
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 49
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Test Procedure
Step 3
Test Result
3.1
Disconnect tester T2 from ENNI E1 and from ENNI E2 and interconnect them directly
3.2
Tester T1 transmits C-tagged frames whose size exceed the configured UNI Maximum Service Frame Size, to
the Operator 1 UNI U1
3.3
Tester T3 verifies that none of the transmitted frames are received at the Operator 2 UNI U2
3.4
Tester T3 transmits C-tagged frames whose size exceed the configured UNI Maximum Service Frame Size, to
the Operator 2 UNI U2
3.5
Tester T1 verifies that none the transmitted frames are received at the Operator 1 UNI U1
Test case passes if the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 discards frames whose length
exceed the configured Maximum Frame Size at the UNI and/or at the ENNI as verified in steps 1.3, 1.5, 2.3, 2.5, 3.3
and 3.5


Test Traffic
and Frame Size
Comment
At the UNI: 10 unicast C-tagged frames of each size specified in the test procedure
At the ENNI: 10 unicast C-tagged frames encapsulated in the outer tag mapped at the ENNI of each size
specified in the test procedure
Any nonconformance observed in either step 1.3, 1.5, 2.3, 2.5, 3.3, or 3.5 will be clearly identified and described in
the test report
Test Case 8 – Service OAM Connectivity Check Messages (CCM) Transparency
Interconnection
Partners
Operator 1 Name:

Requirements
Operator 2 Name:
Access EPL and EPL Services MUST be configurable to tunnel all SOAM frames at the default Test and
Subscriber MEG levels as defined in MEF 30, section 7.1
References
EIP Use Case 1 – Service Attribute Values and Ranges
Test Purpose
Verify that the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 is configurable to tunnel CCM
frames at MEG level 5 & 6
Step 1
Operator 1 – OVC Verification [UNI U1 to ENNI E1]
Test Bed and
Service Mapping Step 1
UNI U1
1, 2…4095*
OVC End Point
* Mapping at the UNI U1 includes untagged and priority tagged frames
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 50
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
ENNI E1
100
Test Procedure
Step 1
OVC End Point
1.1
Tester T1 transmits untagged or C-tagged CCM frames at MEG level 5 & 6 to the Operator 1 UNI U1
1.2
Tester T2 verifies that all the transmitted CCM frames at MEG level 5 & 6 are received at the Operator 1 ENNI
E1, encapsulated in the outer tag mapped at the ENNI E1
1.3
Tester T2 transmits untagged or C-tagged CCM frames at MEG level 5 & 6, encapsulated in the outer tag
mapped at the ENNI E1, to the Operator 1 ENNI E1
1.4
Tester T1 verifies that all the transmitted CCM frames at MEG level 5 & 6 are received at the Operator 1 UNI
U1, without the outer tag
Operator 2 – OVC Verification [UNI U2 to ENNI E2]
Step 2
Test Bed and
Service Mapping Step 2
UNI U2
1, 2…4095*
OVC End Point
* Mapping at the UNI U2 includes untagged and priority tagged frames
ENNI E2
100
Test Procedure
Step 2
Step 3
OVC End Point
2.1
Tester T3 transmits untagged or C-tagged CCM frames at MEG level 5 & 6 to the Operator 2 UNI U2
2.2
Tester T2 verifies that all the transmitted CCM frames at MEG level 5 & 6 are received at the Operator 2 ENNI
E2, encapsulated in the outer tag mapped at the ENNI E2
2.3
Tester T2 transmits untagged C-tagged CCM frames at MEG level 5 & 6, encapsulated in the outer tag mapped
at the ENNI E2, to the Operator 2 ENNI E2
2.4
Tester T3 verifies that all the transmitted CCM frames at MEG level 5 & 6 are received at the Operator 2 UNI
U2, without the outer tag
Service Provider EVC [UNI U1 to UNI U2]
Test Bed and
Service Mapping Step 3
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 51
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
UNI U1
1, 2…4095*
EVC
* Mapping at the UNI U1 includes untagged and priority tagged frames
UNI U2
1, 2…4095*
EVC
* Mapping at the UNI U2 includes untagged and priority tagged frames
Test Procedure
Step 3
Test Result
3.1
Disconnect tester T2 from ENNI E1 and from ENNI E2 and interconnect them directly
3.2
Tester T1 transmits untagged or C-tagged CCM frames at MEG level 5 & 6 to the Operator 1 UNI U1
3.3
Tester T3 verifies that all the transmitted CCM frames at MEG level 5 & 6 are received at the Operator 2 UNI
U2
3.4
Tester T3 transmits untagged or C-tagged CCM frames at MEG level 5 & 6 to the Operator 2 UNI U2
3.5
Tester T1 verifies that all the transmitted CCM frames at MEG level 5 & 6 are received at the Operator 1 UNI
U1
Test case passes if the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 is configurable to tunnel
CCM frames at MEG level 5 & 6 as verified in steps 1.2, 1.4, 2.2, 2.4, 3.3, and 3.5


Test Traffic
and Frame Size
Comment
At the UNI: 10 untagged or C-tagged CCM frames of each MEG level (untagged frames are preferred)
At the ENNI: 10 untagged or C-tagged CCM frames of each MEG level encapsulated in the outer tag
mapped at the ENNI (untagged frames are preferred)
Any nonconformance observed in either step 1.2, 1.4, 2.2, 2.4, 3.3, or 3.5 will be clearly identified and described in
the test report
Test Case 9 – Service OAM Multicast Loopback Messages (LBM) Transparency
Interconnection
Partners
Operator 1 Name:

Requirements
Operator 2 Name:
Access EPL and EPL Services MUST be configurable to tunnel all SOAM frames at the default Test and
Subscriber MEG levels as defined in MEF 30, section 7.1
References
EIP Use Case 1 – Service Attribute Values and Ranges
Test Purpose
Verify that the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 is configurable to tunnel multicast
LBM frames at MEG level 5 & 6
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 52
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Operator 1 – OVC Verification [UNI U1 to ENNI E1]
Step 1
Test Bed and
Service Mapping Step 1
UNI U1
1, 2…4095*
OVC End Point
* Mapping at the UNI U1 includes untagged and priority tagged frames
ENNI E1
100
Test Procedure
Step 1
OVC End Point
1.1
Tester T1 transmits untagged or C-tagged multicast LBM frames at MEG level 5 & 6 to the Operator 1 UNI U1
1.2
Tester T2 verifies that all the transmitted multicast LBM frames at MEG level 5 & 6 are received at the Operator 1 ENNI E1, encapsulated in the outer tag mapped at the ENNI E1
1.3
Tester T2 transmits untagged or C-tagged multicast LBM messages at MEG level 5 & 6, encapsulated in the
outer tag mapped at the ENNI E1, to the Operator 1 ENNI E1
1.4
Tester T1 verifies that all the transmitted multicast LBM frames at MEG level 5 & 6 are received at the Operator 1 UNI U1, without the outer tag
Operator 2 – OVC Verification [UNI U2 to ENNI E2]
Step 2
Test Bed and
Service Mapping Step 2
UNI U2
1, 2…4095*
OVC End Point
* Mapping at the UNI U2 includes untagged and priority tagged frames
ENNI E2
100
MEF 54
OVC End Point
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 53
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Test Procedure
Step 2
Step 3
2.1
Tester T3 transmits untagged or C-tagged multicast LBM frames at MEG level 5 & 6 to the Operator 2 UNI U2
2.2
Tester T2 verifies that all the transmitted multicast LBM frames at MEG level 5 & 6 are received at the Operator 2 ENNI E2, encapsulated in the outer tag mapped at the ENNI E2
2.3
Tester T2 transmits untagged or C-tagged multicast LBM frames at MEG level 5 & 6, encapsulated in the outer
tag mapped at the ENNI E2, to the Operator 2 ENNI E2
2.4
Tester T3 verifies that all the transmitted multicast LBM frames at MEG level 5 & 6 are received at the Operator 2 UNI U2, without the outer tag
Service Provider EVC [UNI U1 to UNI U2]
Test Bed and
Service Mapping Step 3
UNI U1
1, 2…4095*
EVC
* Mapping at the UNI U1 includes untagged and priority tagged frames
UNI U2
1, 2…4095*
EVC
* Mapping at the UNI U2 includes untagged and priority tagged frames
Test Procedure
Step 3
Test Result
3.1
Disconnect tester T2 from ENNI E1 and from ENNI E2 and interconnect them directly
3.2
Tester T1 transmits untagged or C-tagged multicast LBM frames at MEG level 5 & 6 to the Operator 1 UNI
U1
3.3
Tester T3 verifies that all the transmitted multicast LBM frames at MEG level 5 & 6 are received at the Operator 2 UNI U2
3.4
Tester T3 transmits untagged or C-tagged multicast LBM frames at MEG level 5 & 6 to the Operator 2 UNI
U2
3.5
Tester T1 verifies that all the transmitted multicast LBM frames at MEG level 5 & 6 are received at the Operator 1 UNI U1
Test case passes if the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 is configurable to tunnel multicast LBM frames at MEG level 5 & 6 as verified in steps 1.2, 1.4, 2.2, 2.4, 3.3, and 3.5

Test Traffic
and Frame Size

Comment
At the UNI: 10 untagged or C-tagged multicast LBM frames of each MEG level (untagged frames are preferred)
At the ENNI: 10 untagged or C-tagged multicast LBM frames of each MEG level encapsulated in the outer
tag mapped at the ENNI (untagged frames are preferred)
Any nonconformance observed in either step 1.2, 1.4, 2.2, 2.4, 3.3, or 3.5 will be clearly identified and described in
the test report
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 54
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Test Case 10 – Service OAM Unicast Loopback Messages (LBM/LBR) Transparency
Interconnection
Partners
Operator 1 Name:

Requirements
Operator 2 Name:
Access EPL and EPL Services MUST be configurable to tunnel all SOAM frames at the default Test and
Subscriber MEG levels as defined in MEF 30, section 7.1
References
EIP Use Case 1 – Service Attribute Values and Ranges
Test Purpose
Verify that the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 is configurable to tunnel unicast
LBM and LBR frames at MEG level 5 & 6
Step 1
Operator 1 – OVC Verification [UNI U1 to ENNI E1]
Test Bed and
Service Mapping Step 1
UNI U1
1, 2…4095*
OVC End Point
* Mapping at the UNI U1 includes untagged and priority tagged frames
ENNI E1
100
Test Procedure
Step 1
OVC End Point
1.1
Tester T1 transmits untagged or C-tagged unicast LBM and LBR frames at MEG level 5 & 6 to the Operator 1
UNI U1
1.2
Tester T2 verifies that all the transmitted unicast LBM and LBR frames at MEG level 5 & 6 are received at the
Operator 1 ENNI E1, encapsulated in the outer tag mapped at the ENNI E1
1.3
Tester T2 transmits untagged or C-tagged unicast LBM and LBR frames at MEG level 5 & 6, encapsulated in
the outer tag mapped at the ENNI E1, to the Operator 1 ENNI E1
1.4
Tester T1 verifies that all the transmitted unicast LBM and unicast LBR frames at MEG Level 5 & 6 are received at the Operator 1 UNI U1, without the outer tag
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 55
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Operator 2 – OVC Verification [UNI U2 to ENNI E2]
Step 2
Test Bed and
Service Mapping Step 2
UNI U2
1, 2…4095*
OVC End Point
* Mapping at the UNI U2 includes untagged and priority tagged frames
ENNI E2
100
Test Procedure
Step 2
Step 3
OVC End Point
2.1
Tester T3 transmits untagged or C-tagged unicast LBM and LBR frames at MEG level 5 & 6 to the Operator 2
UNI U2
2.2
Tester T2 verifies that all the transmitted unicast LBM and LBR frames at MEG level 5 & 6 are received at the
Operator 2 ENNI E2, encapsulated in the outer tag mapped at the ENNI E2
2.3
Tester T2 transmits untagged or C-tagged unicast LBM and LBR frames at MEG level 5 & 6, encapsulated in
the outer tag mapped at the ENNI E2, to the Operator 2 ENNI E2
2.4
Tester T3 verifies that all the transmitted unicast LBM and LBR frames at MEG level 5 & 6 are received at the
Operator 2 UNI U2, without the outer tag
Service Provider EVC [UNI U1 to UNI U2]
Test Bed and
Service Mapping Step 3
UNI U1
1, 2…4095*
EVC
* Mapping at the UNI U1 includes untagged and priority tagged frames
UNI U2
1, 2…4095*
EVC
* Mapping at the UNI U2 includes untagged and priority tagged frames
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 56
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Test Procedure
Step 3
Test Result
3.1
Disconnect tester T2 from ENNI E1 and from ENNI E2 and interconnect them directly
3.2
Tester T1 transmits untagged or C-tagged unicast LBM and LBR frames at MEG level 5 & 6 to the Operator 1
UNI U1
3.3
Tester T3 verifies that all the transmitted unicast LBM and LBR frames at MEG level 5 & 6 are received at
the Operator 2 UNI U2
3.4
Tester T3 transmits untagged or C-tagged unicast LBM and LBR frames at MEG level 5 & 6 to the Operator 2
UNI U2
3.5
Tester T1 verifies that all the transmitted unicast LBM and LBR frames at MEG level 5 & 6 are received at
the Operator 1 UNI U1
Test case passes if the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 is configurable to tunnel
unicast LBM and LBR frames at MEG level 5 & 6 as verified in steps 1.2, 1.4, 2.2, 2.4, 3.3, and 3.5

Test Traffic
and Frame Size

Comment
At the UNI: 10 untagged or C-tagged unicast LBM frames of each MEG level and 10 untagged or C-tagged
unicast LBR frames of each MEG level (untagged frames are preferred)
At the ENNI: 10 untagged or C-tagged unicast LBM frames of each MEG level encapsulated in the outer tag
mapped at the ENNI and 10 untagged or C-tagged unicast LBR frames of each MEG level encapsulated in
the outer tag mapped at the ENNI (untagged frames are preferred)
Any nonconformance observed in either step 1.2, 1.4, 2.2, 2.4, 3.3, or 3.5 will be clearly identified and described in
the test report
Test Case 11 – Service OAM LinkTrace Messages (LTM/LTR) Transparency
Interconnection
Partners
Operator 1 Name:

Requirements
Operator 2 Name:
Access EPL and EPL Services MUST be configurable to tunnel all SOAM frames at the default Test and
Subscriber MEG levels as defined in MEF 30, section 7.1
References
EIP Use Case 1 – Service Attribute Values and Ranges
Test Purpose
Verify that the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 is configurable to tunnel unicast
LTM and LTR frames at MEG level 5 & 6
Step 1
Operator 1 – OVC Verification [UNI U1 to ENNI E1]
Test Bed and
Service Mapping Step 1
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 57
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
UNI U1
1, 2…4095*
OVC End Point
* Mapping at the UNI U1 includes untagged and priority tagged frames
ENNI E1
100
Test Procedure
Step 1
OVC End Point
1.1
Tester T1 transmits untagged or C-tagged LTM and LTR frames at MEG level 5 & 6 to the Operator 1 UNI U1
1.2
Tester T2 verifies that all the transmitted LTM and LTR frames at MEG level 5 & 6 are received at the Operator
1 ENNI E1, encapsulated in the outer tag mapped at the ENNI E1
1.3
Tester T2 transmits untagged or C-tagged LTM and LTR messages at MEG level 5 & 6, encapsulated in the
outer tag mapped at the ENNI E1 to the Operator 1 ENNI E1
1.4
Tester T1 verifies that all the transmitted LTM and LTR frames at MEG level 5 & 6 are received at the Operator
1 UNI U1
Operator 2 – OVC Verification [UNI U2 to ENNI E2]
Step 2
Test Bed and
Service Mapping Step 2
UNI U2
1, 2…4095*
OVC End Point
* Mapping at the UNI U2 includes untagged and priority tagged frames
ENNI E2
100
Test Procedure
Step 2
OVC End Point
2.1
Tester T3 transmits untagged or C-tagged LTM and LTR frames at MEG level 5 & 6 to the Operator 2 UNI U2
2.2
Tester T2 verifies that all the transmitted LTM and LTR frames at MEG level 5 & 6 are received at the Operator
2 ENNI E2, encapsulated in the outer tag mapped at the ENNI E2
2.3
Tester T2 transmits untagged or C-tagged LTM and LTR frames at MEG level 5 & 6, encapsulated in the outer
tag mapped at the ENNI E2, to the Operator 2 ENNI E2
2.4
Tester T3 verifies that all the transmitted LTM and LTR frames at MEG level 5 & 6 are received at the Operator
2 UNI U2 without the outer tag
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 58
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Step 3
Service Provider EVC [UNI U1 to UNI U2]
Test Bed and
Service Mapping Step 3
UNI U1
1, 2…4095*
EVC
* Mapping at the UNI U1 includes untagged and priority tagged frames
UNI U2
1, 2…4095*
EVC
* Mapping at the UNI U2 includes untagged and priority tagged frames
Test Procedure
Step 3
Test Result
3.1
Disconnect tester T2 from ENNI E1 and from ENNI E2 and interconnect them directly
3.2
Tester T1 transmits untagged or C-tagged LTM and LTR frames at MEG level 5 & 6 to the Operator 1 UNI
U1
3.3
Tester T3 verifies that all the transmitted LTM and LTR frames at MEG level 5 & 6 are received at the Operator 2 UNI U2
3.4
Tester T3 transmits untagged or C-tagged LTM and LTR frames at MEG level 5 & 6 to the Operator 2 UNI
U2
3.5
Tester T1 verifies that all the transmitted LTM and LTR frames at MEG level 5 & 6 are received at the Operator 1 UNI U1
Test case passes if the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 is configurable to tunnel
LTM and LTR frames at MEG level 5 & 6 as verified in steps 1.2, 1.4, 2.2, 2.4, 3.3, and 3.5

Test Traffic
and Frame Size

Comment
At the UNI: 10 untagged or C-tagged LTM frames of each MEG level and 10 untagged or C-tagged LTR
frames of each MEG level (untagged frames are preferred)
At the ENNI: 10 untagged or C-tagged LTM frames of each MEG level encapsulated in the outer tag mapped
at the ENNI and 10 untagged or C-tagged LTR frames of each MEG level encapsulated in the outer tag
mapped at the ENNI (untagged frames are preferred)
Any nonconformance observed in either step 1.2, 1.4, 2.2, 2.4, 3.3, or 3.5 will be clearly identified and described in
the test report
Test Case 12 – L2CP Handling – Option 1
Interconnection
Partners
Operator 1 Name:
Requirements
MEF 54

Operator 2 Name:
Support of MEF 45 EPL Option 1
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 59
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
References
EIP Use Case 1 – Service Attribute Values and Ranges
Test Purpose
Verify that the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 supports MEF 45 EPL Option 1 requirements
Step 1
Operator 1 – OVC Verification [UNI U1 to ENNI E1]
Test Bed and
Service Mapping Step 1
UNI U1
1, 2…4095*
OVC End Point
* Mapping at the UNI U1 includes untagged and priority tagged frames
ENNI E1
100
Test Procedure
Step 1
OVC End Point
1.1
Configure the Operator 1 OVC service to support MEF 45 EPL Option 1
1.2
Tester T1 transmits untagged frames of each Layer 2 Control Protocol defined in MEF 45 to the Operator 1 UNI
U1
1.3
For each Layer 2 Control Protocol, tester T2 verifies if the frames are either Filtered (not received at the Operator 1 ENNI E1) or Passed (received encapsulated in the outer tag mapped at the Operator 1 ENNI E1)
1.4
Tester T2 transmits untagged frames of each Layer 2 Control Protocol defined in MEF 45 encapsulated in the
outer tag mapped at the ENNI E1 to the Operator 1 ENNI E1
1.5
For each Layer 2 Control Protocol, tester T1 verifies if the frames are either Filtered (not received at the Operator 1 UNI U1) or Passed (received without the outer tag at the Operator 1 UNI U1)
Operator 2 – OVC Verification [UNI U2 to ENNI E2]
Step 2
Test Bed and
Service Mapping Step 2
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 60
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
UNI U2
1, 2…4095*
OVC End Point
* Mapping at the UNI U2 includes untagged and priority tagged frames
ENNI E2
100
Test Procedure
Step 2
Step 3
OVC End Point
2.1
Configure the Operator 2 OVC service to support MEF 45 EPL Option 1
2.2
Tester T3 transmits untagged frames of each Layer 2 Control Protocol defined in MEF 45 to the Operator 2 UNI
U2
2.3
For each Layer 2 Control Protocol, tester T2 verifies if the frames are either Filtered (not received at the Operator 2 ENNI E2) or Passed (received encapsulated in the outer tag mapped at the Operator 2 ENNI E2)
2.4
Tester T2 transmits untagged frames of each Layer 2 Control Protocol defined in MEF 45 encapsulated in the
outer tag mapped at the ENNI E2 to the Operator 2 ENNI E2
2.5
For each Layer 2 Control Protocol, tester T3 verifies if the frames are either Filtered (not received at the Operator 2 UNI U2) or Passed (received without the outer tag at the Operator 2 UNI U2)
Service Provider EVC [UNI U1 to UNI U2]
Test Bed and
Service Mapping Step 3
UNI U1
1, 2…4095*
EVC
* Mapping at the UNI U1 includes untagged and priority tagged frames
UNI U2
1, 2…4095*
EVC
* Mapping at the UNI U2 includes untagged and priority tagged frames
Test Procedure
Step 3
3.1
Disconnect tester T2 from ENNI E1 and from ENNI E2 and interconnect them directly
3.2
Configure the Service Provider EVC to support MEF 45 EPL Option 1
3.3
Tester T1 transmits untagged frames of each Layer 2 Control Protocol defined in MEF 45 to the Operator 1
UNI U1
3.4
For each Layer 2 Control Protocol, tester T3 verifies if the frames are either Filtered (not received at the Operator 2 UNI U2) or Passed (received at the Operator 2 UNI U2)
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 61
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Test Result
3.5
Tester T3 transmits untagged frames of each Layer 2 Control Protocol defined in MEF 45 to the Operator 2
UNI U2
3.5
For each Layer 2 Control Protocol, tester T1 verifies if the frames are either Filtered (not received at Operator
1 UNI U1) or Passed (received at the Operator 1 UNI U1)
Test case passes if the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 supports MEF 45 EPL Option
1 requirements as verified in steps 1.3, 1.5, 2.3, 2.5, 3.4, and 3.6


Test Traffic
and Frame Size
Comment
At the UNI: 10 untagged frames of each of each Layer 2 Control Protocol defined in MEF 45
At the ENNI: 10 untagged of each Layer 2 Control Protocol defined in MEF 45 encapsulated in the outer tag
mapped at the ENNI
Any nonconformance observed in either step 1.3, 1.5, 2.3, 2.5, 3.4, or 3.6 will be clearly identified and described in
the test report
Test Case 13 – L2CP Handling – Option 2
Interconnection
Partners
Operator 1 Name:

Requirements
Operator 2 Name:
Support of MEF 45 EPL Option 2
References
EIP Use Case 1 – Service Attribute Values and Ranges
Test Purpose
Verify that the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 supports MEF 45 EPL Option 2 requirements
Step 1
Operator 1 – OVC Verification [UNI U1 to ENNI E1]
Test Bed and
Service Mapping Step 1
UNI U1
1, 2…4095*
OVC End Point
* Mapping at the UNI U1 includes untagged and priority tagged frames
ENNI E1
100
Test Procedure
Step 1
OVC End Point
1.1
Configure the Operator 1 OVC service to support MEF 45 EPL Option 2
1.2
Tester T1 transmits untagged frames of each Layer 2 Control Protocol defined in MEF 45 to the Operator 1 UNI
U1
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 62
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
1.3
For each Layer 2 Control Protocol, tester T2 verifies if the frames are either Filtered (not received at the Operator 1 ENNI E1) or Passed (received encapsulated in the outer tag mapped at the Operator 1 ENNI E1)
1.4
Tester T2 transmits untagged frames of each Layer 2 Control Protocol defined in MEF 45 encapsulated in the
outer tag mapped at the ENNI E1 to the Operator 1 ENNI E1
1.5
For each Layer 2 Control Protocol, tester T1 verifies if the frames are either Filtered (not received at the Operator 1 UNI U1) or Passed (received without the outer tag at the Operator 1 UNI U1)
Operator 2 – OVC Verification [UNI U2 to ENNI E2]
Step 2
Test Bed and
Service Mapping Step 2
UNI U2
1, 2…4095*
OVC End Point
* Mapping at the UNI U2 includes untagged and priority tagged frames
ENNI E2
100
Test Procedure
Step 2
Step 3
OVC End Point
2.1
Configure the Operator 2 OVC service to support MEF 45 EPL Option 2
2.2
Tester T3 transmits untagged frames of each Layer 2 Control Protocol defined in MEF 45 to the Operator 2 UNI
U2
2.3
For each Layer 2 Control Protocol, tester T2 verifies if the frames are either Filtered (not received at the Operator 2 ENNI E2) or Passed (received encapsulated in the outer tag mapped at the Operator 2 ENNI E2)
2.4
Tester T2 transmits untagged frames of each Layer 2 Control Protocol defined in MEF 45 encapsulated in the
outer tag mapped at the ENNI E2 to the Operator 2 ENNI E2
2.5
For each Layer 2 Control Protocol, tester T3 verifies if the frames are either Filtered (not received at the Operator 2 UNI U2) or Passed (received without the outer tag at the Operator 2 UNI U2)
Service Provider EVC [UNI U1 to UNI U2]
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 63
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Test Bed and
Service Mapping Step 3
UNI U1
1, 2…4095*
EVC
* Mapping at the UNI U1 includes untagged and priority tagged frames
UNI U2
1, 2…4095*
EVC
* Mapping at the UNI U2 includes untagged and priority tagged frames
Test Procedure
Step 3
Test Result
3.1
Disconnect tester T2 from ENNI E1 and from ENNI E2 and interconnect them directly
3.2
Configure the Service Provider EVC to support MEF 45 EPL Option 2
3.3
Tester T1 transmits untagged frames of each Layer 2 Control Protocol defined in MEF 45 to the Operator 1
UNI U1
3.4
For each Layer 2 Control Protocol, tester T3 verifies if the frames are either Filtered (not received at the Operator 2 UNI U2) or Passed (received at the Operator 2 UNI U2)
3.5
Tester T3 transmits untagged frames of each Layer 2 Control Protocol defined in MEF 45 to the Operator 2
UNI U2
3.6
For each Layer 2 Control Protocol, tester T1 verifies if the frames are either Filtered (not received at Operator
1 UNI U1) or Passed (received at the Operator 1 UNI U1)
Test case passes if the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 supports MEF 45 EPL Option
2 requirements as verified in steps 1.3, 1.5, 2.3, 2.5, 3.4, and 3.6


Test Traffic
and Frame Size
Comment
At the UNI: 10 untagged frames of each of each Layer 2 Control Protocol defined in MEF 45
At the ENNI: 10 untagged of each Layer 2 Control Protocol defined in MEF 45 encapsulated in the outer tag
mapped at the ENNI
Any nonconformance observed in either step 1.3, 1.5, 2.3, 2.5, 3.4, or 3.6 will be clearly identified and described in
the test report
Test Case 14 – Ingress Bandwidth Profile per CoS ID – Committed Information Rate
Interconnection
Partners
Operator 1 Name:
Requirements




MEF 54
Operator 2 Name:
The CoS ID for Data Service Frame MUST be per EVC
The Ingress Bandwidth profile (BWP) per CoS ID MUST specify CIR > 0, CBS > 0, EIR = 0, EBS = 0, CF
= X, CM = X
The Ingress BWP per OVC EP at the UNI MUST align to the Ingress BWP Per Cos ID
The Ingress BWP per OVC EP at the ENNI MUST specify CIR > 0, CBS > 0, EIR = 0, EBS = 0, CF = X,
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 64
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
CM = X
References
EIP Use Case 1 – Service Attribute Values and Ranges
Test Purpose
Verify that when an Ingress BWP per CoS ID with CIR > 0, CBS > 0, EIR = 0, and EBS = 0 is applied at the UNI or
at the ENNI, of the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1, the amount of Green traffic
delivered at the egress UNI or ENNI is within +/- 2% of the calculated amount of traffic accepted as Green at the ingress during a time interval T, provided that the ingress traffic is offered at a constant rate greater than CIR
Step 1
Operator 1 – OVC Verification [UNI U1 to ENNI E1]
Test Bed and
Service Mapping Step 1
UNI U1
1, 2…4095*
OVC End Point
* Mapping at the UNI U1 includes untagged and priority tagged frames
ENNI E1
100
OVC End Point
UNI U1 & ENNI E1 Ingress BWP
Test Procedure
Step 1
Step 2
CIR
CBS
EIR
CBS
CM
CF
>0Mbps
>0B
0Mbps
0B
X
X
1.1
Tester T1 transmits C-tagged frames of size S at a constant rate greater than the CIR to the Operator 1 UNI U1
during a time interval T
1.2
Tester T2 measures the number of C-tagged frames encapsulated in the outer tag mapped at ENNI E1, delivered
at the Operator 1 ENNI E1 and verifies that the amount of received Green traffic is within +/- 2% of the calculated amount of traffic accepted as Green over the time interval T
1.3
Tester T2 transmits C-tagged frames encapsulated in the outer tag mapped at the ENNI E1, of size S at a constant rate greater than CIR to the Operator 1 ENNI E1 during a time interval T
1.4
Tester T1 measures the number of C-tagged frames delivered at the Operator 1 UNI U1 and verifies that the
amount of received Green traffic is within +/- 2% of the calculated amount of traffic accepted as Green over the
time interval T
Operator 2 – OVC Verification [UNI U2 to ENNI E2]
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 65
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Test Bed and
Service Mapping Step 2
UNI U2
1, 2…4095*
OVC End Point
* Mapping at the UNI U2 includes untagged and priority tagged frames
ENNI E2
100
OVC End Point
UNI U2 & ENNI E2 ingress BWP
Test Procedure
Step 2
Step 3
CIR
CBS
EIR
CBS
CM
CF
>0Mbps
>0B
0Mbps
0B
X
X
2.1
Tester T3 transmits C-tagged frames of size S at a constant rate greater than the CIR to the Operator 2 UNI U2
during a time interval T
2.2
Tester T2 measures the number of C-tagged frames encapsulated in the outer tag mapped at ENNI E2, delivered
at the Operator 2 ENNI E2 and verifies that the amount of received Green traffic is within +/- 2% of the calculated amount of traffic accepted as Green over the time interval T
2.3
Tester T2 transmits C-tagged frames encapsulated in the outer tag mapped at the ENNI E2, of size S at a constant rate greater than CIR to the Operator 2 ENNI E2 during a time interval T
2.4
Tester T3 measures the number of C-tagged frames delivered at the Operator 2 UNI U2 and verifies that the
amount of received Green traffic is within +/- 2% of the calculated amount of traffic accepted as Green over the
time interval T
Service Provider EVC [UNI U1 to UNI U2]
Test Bed and
Service Mapping Step 3
UNI U1
1, 2…4095*
OVC End Point
* Mapping at the UNI U1 includes untagged and priority tagged frames
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 66
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
UNI U2
1, 2…4095*
OVC End Point
* Mapping at the UNI U2 includes untagged and priority tagged frames
UNI U1 & UNI U2 Ingress BWP
Test Procedure
Step 3
Test Result
CIR
CBS
EIR
CBS
CM
CF
>0Mbps
>0B
0Mbps
0B
X
X
3.1
Disconnect tester T2 from ENNI E1 and from ENNI E2 and interconnect them directly
3.2
Tester T1 transmits C-tagged frames of size S at a constant rate greater than the CIR to the Operator 1 UNI U1
during a time interval T
3.3
Tester T3 measures the number of C-tagged frames delivered at the Operator 2 UNI U2 and verifies that the
amount of received Green traffic is within +/- 2% of the calculated amount of traffic accepted as Green over
the time interval T
3.4
Tester T3 transmits C-tagged frames of size S at a constant rate greater than CIR to the Operator 2 UNI U2
during a time interval T
3.5
Tester T1 measures the number of C-tagged frames delivered at the Operator 1 UNI U1 and verifies that the
amount of received Green traffic is within +/- 2% of the calculated amount of traffic accepted as Green over
the time interval T
Test case passes if the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 supports Ingress BWP per
CoS ID with CIR>0, CBS>0, EIR=0, and EBS=0 as verified in steps 1.2, 1.4, 2.2, 2.4, 3.3, and 3.5
Test Traffic
and Frame Size



Comment





At the UNI: C-tagged frames of size S, where S can be a fixed frame size or an EMIX as defined in MEF 48,
at a rate function of the tested CIR at the UNI (fixed frame size is preferred)
At the ENNI: C-tagged frames of size S encapsulated in the outer tag mapped at ENNI, where S can be a
fixed frame size or an EMIX as defined in MEF 48, at a rate function of the tested CIR at the ENNI (fixed
frame size is preferred)
Any nonconformance observed in either step 1.2, 1.4, 2.2, 2.4, 3.3, or 3.5 will be clearly identified and described in the test report
The BWP is measured in terms of Service Frame or ENNI Frame traffic where the Service Frame or ENNI
Frame consists of the first bit of the Destination MAC Address through the last bit of the Frame Check Sequence
The length of the time interval T must be such that the number of bytes in CBS is negligible compared to the
total volume of traffic received over the duration of the test
Where the BWP verification is executed from the UNI to the ENNI or from the ENNI to the UNI, appending
or removing the outer Tag mapped at the ENNI adds or eliminates four bytes per frame. These need to be
subtracted or added when calculating the amount of traffic (in bytes) delivered to the egress UNI or ENNI
The +/- 2% CIR tolerance accounts for small fluctuations due to the MEF BWP algorithm implementation
across different chipsets
With fixed frame sizes, the test case is to be run 3 times; with 80-byte, 600-byte and 1500-byte frames
Test Case 15 – Ingress Bandwidth Profile per CoS ID – Committed Burst Size
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 67
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Interconnection
Partners
Operator 1 Name:


Requirements


Operator 2 Name:
The CoS ID for Data Service Frame MUST be per EVC
The Ingress Bandwidth profile (BWP) per CoS ID MUST specify CIR > 0, CBS > 0, EIR = 0, EBS = 0, CF
= X, CM = X
The Ingress BWP per OVC EP at the UNI MUST align to the Ingress BWP Per Cos ID
The Ingress BWP per OVC EP at the ENNI MUST specify CIR > 0, CBS > 0, EIR = 0, EBS = 0, CF = X,
CM = X
References
EIP Use Case 1 – Service Attribute Values and Ranges
Test Purpose
Verify that when an Ingress BWP per CoS ID with CIR > 0, CBS > 0, EIR = 0, and EBS = 0 is applied at the UNI or
at the ENNI, of the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1, the amount of Green traffic
delivered at the egress UNI or ENNI is within +/- 3 frames or +/- 5% of the calculated amount of traffic accepted as
Green at the ingress during a time interval T, provided that the ingress traffic is offered as a pattern of repeated bursts
and idle periods where each burst B is longer than necessary to empty the token bucket and each idle period I is longer
than necessary to fill the token bucket.
Step 1
Operator 1 – OVC Verification [UNI U1 to ENNI E1]
Test Bed and
Service Mapping Step 1
UNI U1
1, 2…4095*
OVC End Point
* Mapping at the UNI U1 includes untagged and priority tagged frames
ENNI E1
100
OVC End Point
UNI U1 & ENNI E1 Ingress BWP
Test Procedure
Step 1
CIR
CBS
EIR
CBS
CM
CF
>0Mbps
>0B
0Mbps
0B
X
X
1.1
Tester T1 transmits C-tagged frames of size S using an input traffic pattern of repeated bursts and idle periods
where each burst B is longer than necessary to empty the token bucket and each idle period I is longer than necessary to fill the token bucket, to the Operator 1 UNI U1 during a time interval T
1.2
Tester T2 measures the number of C-tagged frames encapsulated in the outer tag mapped at ENNI E1 delivered
at the Operator 1 ENNI E1 and verifies that the amount of received Green traffic is within +/- 3 frames or +/-
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 68
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
5% of the calculated amount of traffic accepted as Green over the time interval T
1.3
Tester T2 transmits C-tagged frames encapsulated in the outer tag mapped at the ENNI E1, of size S using an
input traffic pattern of repeated bursts and idle periods where each burst B is longer than necessary to empty the
token bucket and each idle period I is longer than necessary to fill the token bucket, to the Operator 1 ENNI E1
during a time interval T
1.4
Tester T1 measures the number of C-tagged frames delivered at the Operator 1 UNI U1 and verifies that the
amount of received Green traffic is within +/- 3 frames or +/- 5% of the calculated amount of traffic accepted as
Green over the time interval T
Operator 2 – OVC Verification [UNI U2 to ENNI E2]
Step 2
Test Bed and
Service Mapping Step 2
UNI U2
1, 2…4095*
OVC End Point
* Mapping at the UNI U2 includes untagged and priority tagged frames
ENNI E2
100
OVC End Point
UNI U2 & ENNI E2 ingress BWP
Test Procedure
Step 2
CIR
CBS
EIR
CBS
CM
CF
>0Mbps
>0B
0Mbps
0B
X
X
2.1
Tester T3 transmits C-tagged frames of size S using an input traffic pattern of repeated bursts and idle periods
where each burst B is longer than necessary to empty the token bucket and each idle period I is longer than necessary to fill the token bucket, to the Operator 2 UNI U2 during a time interval T
2.2
Tester T2 measures the number of C-tagged frames encapsulated in the outer tag mapped at ENNI E2 delivered
at the Operator 2 ENNI E2 and verifies that the amount of received Green traffic is within +/- 3 frames or +/5% of the calculated amount of traffic accepted as Green over the time interval T
2.3
Tester T2 transmits C-tagged frames encapsulated in the outer tag mapped at the ENNI E2, of size S using an
input traffic pattern of repeated bursts and idle periods where each burst B is longer than necessary to empty the
token bucket and each idle period I is longer than necessary to fill the token bucket, to the Operator 2 ENNI E2
during a time interval T
2.4
Tester T3 measures the number of C-tagged frames delivered at the Operator 2 UNI U2 and verifies that the
amount of received Green traffic is within +/- 3 frames or +/- 5% of the calculated amount of traffic accepted as
Green over the time interval T
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 69
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Step 3
Service Provider EVC [UNI U1 to UNI U2]
Test Bed and
Service Mapping Step 3
UNI U1
1, 2…4095*
OVC End Point
* Mapping at the UNI U1 includes untagged and priority tagged frames
UNI U2
1, 2…4095*
OVC End Point
* Mapping at the UNI U2 includes untagged and priority tagged frames
UNI U1 & UNI U2 Ingress BWP
Test Procedure
Step 3
Test Result
CIR
CBS
EIR
CBS
CM
CF
>0Mbps
>0B
0Mbps
0B
X
X
3.1
Disconnect tester T2 from ENNI E1 and from ENNI E2 and interconnect them directly
3.2
Tester T1 transmits C-tagged frames of size S using an input traffic pattern of repeated bursts and idle periods
where each burst B is longer than necessary to empty the token bucket and each idle period I is longer than
necessary to fill the token bucket, to the Operator 1 UNI U1 during a time interval T
3.3
Tester T3 measures the number of C-tagged frames delivered at the Operator 2 UNI U2 and verifies that the
amount of received Green traffic is within +/- 3 frames or +/- 5% of the calculated amount of traffic accepted
as Green over the time interval T
3.4
Tester T3 transmits C-tagged frames of size S using an input traffic pattern of repeated bursts and idle periods
where each burst B is longer than necessary to empty the token bucket and each idle period I is longer than
necessary to fill the token bucket, to the Operator 2 UNI U2 during a time interval T
3.5
Tester T1 measures the number of C-tagged frames delivered at the Operator 1 UNI U1 and verifies that the
amount of received Green traffic is within +/- 3 frames or +/- 5% of the calculated amount of traffic accepted
as Green over the time interval T
Test case passes if the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 supports Ingress BWP per
CoS ID with CIR>0, CBS>0, EIR=0, and EBS=0 as verified in steps 1.2, 1.4, 2.2, 2.4, 3.3, and 3.5
Test Traffic
and Frame Size
Comment
MEF 54


At the UNI: C-tagged frames of size S, where S can be a fixed frame size or an EMIX as defined in MEF 48,
at a rate function of the tested CIR and CBS at the UNI (fixed frame size is preferred)
At the ENNI: C-tagged frames of size S encapsulated in the outer tag mapped at ENNI, where S can be a
fixed frame size or an EMIX as defined in MEF 48, at a rate function of the tested CIR and CBS at the ENNI
(fixed frame size is preferred)

Any nonconformance observed in either step 1.2, 1.4, 2.2, 2.4, 3.3, or 3.5 will be clearly identified and de-
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 70
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement




scribed in the test report
The BWP is measured in terms of Service Frame or ENNI Frame traffic where the Service Frame or ENNI
Frame consists of the first bit of the Destination MAC Address through the last bit of the Frame Check Sequence
Where the BWP verification is executed from the UNI to the ENNI or from the ENNI to the UNI, appending
or removing the outer Tag mapped at the ENNI adds or eliminates four bytes per frame. These need to be
subtracted or added when calculating the amount of traffic (in bytes) delivered to the egress UNI or ENNI
The +/- 3 frames or +/- 5% CBS tolerance accounts for small fluctuations due to the MEF BWP algorithm
implementation across different chipsets
With fixed frame sizes, the test case is to be run 3 times; with 80-byte, 600-byte and 1500-byte frames
Test Case 16 – Service Performance with Constant Traffic
Interconnection
Partners
Operator 1 Name:



Requirements
Operator 2 Name:
The CoS ID for Data Service Frame MUST be per EVC
The OVC Service Level Specification MUST support MEF 23.1 PT-1 performance objectives for CoS H
The EVC performance MUST support MEF 23.1 PT-1 performance objectives for CoS H
References
EIP Use Case 1 – Service Attribute Values and Ranges
Test Purpose
Verify that the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 meets the performance objectives
defined in MEF 23.1 for Performance Tier 1, High Class of Service while carrying constant traffic.
Step 1
Operator 1 – OVC Verification [UNI U1 to ENNI E1]
Test Bed and
Service Mapping Step 1
UNI U1
1, 2…4095*
OVC End Point
* Mapping at the UNI U1 includes untagged and priority tagged frames
ENNI E1
100
OVC End Point
UNI U1 & ENNI E1 Ingress BWP
CIR
MEF 54
CBS
EIR
CBS
CM
CF
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 71
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
>0Mbps
Test Procedure
Step 1
>0B
0Mbps
0B
X
X
1.1
Tester T1 transmits C-tagged frames of size S at a constant rate equal to CIR to the Operator 1 UNI U1 during a
time interval T
1.2
Tester T2 measures the Information Rate, the Frame Delay, and the Frame Loss Ratio and calculates the Mean
Frame Delay, the Inter-Frame Delay Variation and the Frame Delay Range and verifies that the performance
objectives defined in MEF 23.1 for Performance Tier 1, High Class of Service are met
1.3
Tester T2 transmits C-tagged frames encapsulated in the outer tag mapped at the ENNI E1 of size S at a constant
rate equal to CIR to the Operator 1 ENNI E1 during a time interval T
1.4
Tester T1 measures the Information Rate, the Frame Delay, and the Frame Loss Ratio and calculates the Mean
Frame Delay, the Inter-Frame Delay Variation and the Frame Delay Range and verifies that the performance
objectives defined in MEF 23.1 for Performance Tier 1, High Class of Service are met
Operator 2 – OVC Verification [UNI U2 to ENNI E2]
Step 2
Test Bed and
Service Mapping Step 2
UNI U2
1, 2…4095*
OVC End Point
* Mapping at the UNI U2 includes untagged and priority tagged frames
ENNI E2
100
OVC End Point
UNI U2 & ENNI E2 ingress BWP
Test Procedure
Step 2
CIR
CBS
EIR
CBS
CM
CF
>0Mbps
>0B
0Mbps
0B
X
X
2.1
Tester T3 transmits C-tagged frames of size S at a constant rate equal to CIR to the Operator 2 UNI U2 during a
time interval T
2.2
Tester T2 measures the Information Rate, the Frame Delay, and the Frame Loss Ratio and calculates the Mean
Frame Delay, the Inter-Frame Delay Variation, and the Frame Delay Range and verifies that the performance
objectives defined in MEF 23.1 for Performance Tier 1, High Class of Service are met
2.3
Tester T2 transmits C-tagged frames encapsulated in the outer tag mapped at the ENNI E2 of size S at a constant
rate equal to CIR to the Operator 2 ENNI E2 during a time interval T
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 72
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
2.4
Step 3
Tester T3 measures the Information Rate, the Frame Delay, and the Frame Loss Ratio and calculates the Mean
Frame Delay, the Inter-Frame Delay Variation, and the Frame Delay Range and verifies that the performance
objectives defined in MEF 23.1 for Performance Tier 1, High Class of Service are met
Service Provider EVC [UNI U1 to UNI U2]
Test Bed and
Service Mapping Step 3
UNI U1
1, 2…4095*
OVC End Point
* Mapping at the UNI U1 includes untagged and priority tagged frames
UNI U2
1, 2…4095*
OVC End Point
* Mapping at the UNI U2 includes untagged and priority tagged frames
UNI U1 & UNI U2 Ingress BWP
Test Procedure
Step 3
Test Result
CIR
CBS
EIR
CBS
CM
CF
>0Mbps
>0B
0Mbps
0B
X
X
3.1
Disconnect tester T2 from ENNI E1 and from ENNI E2 and interconnect them directly
3.2
Tester T1 transmits C-tagged frames of size S at a constant rate equal to CIR to the Operator 1 UNI U1 during
a time interval T
3.3
Tester T3 measures the Information Rate, the Frame Delay, and the Frame Loss Ratio and calculates the Mean
Frame Delay, the Inter-Frame Delay Variation, and the Frame Delay Range and verifies that the performance
objectives defined in MEF 23.1 for Performance Tier 1, High Class of Service are met
3.4
Tester T3 transmits C-Tagged frames of size S at a constant rate equal to CIR to the Operator 2 UNI U2 during a time interval T
3.5
Tester T1 measures the Information Rate, the Frame Delay, and the Frame Loss Ratio and calculates the Mean
Frame Delay, the Inter-Frame Delay Variation, and the Frame Delay Range and verifies that the performance
objectives defined in MEF 23.1 for Performance Tier 1, High Class of Service are met
Test case passes if the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 meets the performance objectives defined in MEF 23.1 for Performance Tier 1, High Class of Service while carrying constant traffic as verified in
steps 1.2, 1.4, 2.2, 2.4, 3.3, and 3.5.
Test Traffic
and Frame Size
MEF 54

At the UNI: C-tagged frames of size S, where S can be a fixed frame size or an EMIX as defined in MEF 48,
at a rate function of the tested CIR at the UNI (fixed frame size is preferred)
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 73
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Comment

At the ENNI: C-tagged frames of size S encapsulated in the outer tag mapped at ENNI, where S can be a
fixed frame size or an EMIX as defined in MEF 48, at a rate function of the tested CIR at the ENNI (fixed
frame size is preferred)

Any non-conformance observed in either step 1.2, 1.4, 2.2, 2.4, 3.3, or 3.5 will be clearly identified and described in the test report
The performance objectives for PT-1 CoS H are as follows: FD ≤ 10 ms, MFD ≤ 7 ms, IFDV ≤ 3 ms, FDR ≤
5 ms, FLR ≤ 0.01%
The performance attributes must be measured and calculated as defined in MEF 10.2 section 6.9


Test Case 17 – Service Performance with Bursty Traffic
Interconnection
Partners
Operator 1 Name:



Requirements
Operator 2 Name:
The CoS ID for Data Service Frame MUST be per EVC
The OVC Service Level Specification MUST support MEF 23.1 PT-1 performance objectives for CoS H
The EVC performance MUST support MEF 23.1 PT-1 performance objectives for CoS H
References
EIP Use Case 1 – Service Attribute Values and Ranges
Test Purpose
Verify that the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 meets the performance objectives
defined in MEF 23.1 for Performance Tier 1, High Class of Service while carrying bursty traffic
Step 1
Operator 1 – OVC Verification [UNI U1 to ENNI E1]
Test Bed and
Service Mapping Step 1
UNI U1
1, 2…4095*
OVC End Point
* Mapping at the UNI U1 includes untagged and priority tagged frames
ENNI E1
100
OVC End Point
UNI U1 & ENNI E1 Ingress BWP
MEF 54
CIR
CBS
EIR
CBS
CM
CF
>0Mbps
>0B
0Mbps
0B
X
X
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 74
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Test Procedure
Step 1
1.1
Tester T1 transmits C-tagged frames of size S at an average rate up to CIR, using a test traffic profile which
exercises both configured CIR and CBS at the same time, to the Operator 1 UNI U1 during a time interval T
1.2
Tester T2 measures the Frame Delay and the Frame Loss Ratio and calculates the Mean Frame Delay, the InterFrame Delay Variation, and the Frame Delay Range and verifies that the performance objectives defined in
MEF 23.1 for Performance Tier 1, High Class of Service are met
1.3
Tester T2 transmits C-tagged frames encapsulated in the outer tag mapped at the ENNI E1, of size S at an average rate up to CIR, using a test traffic profile which exercises both configured CIR and CBS at the same time, to
the Operator 1 ENNI E1 during a time interval T
1.4
Tester T1 measures the Frame Delay and the Frame Loss Ratio and calculates the Mean Frame Delay, the InterFrame Delay Variation, and the Frame Delay Range and verifies that the performance objectives defined in
MEF 23.1 for Performance Tier 1, High Class of Service are met
Operator 2 – OVC Verification [UNI U2 to ENNI E2]
Step 2
Test Bed and
Service Mapping Step 2
UNI U2
1, 2…4095*
OVC End Point
* Mapping at the UNI U2 includes untagged and priority tagged frames
ENNI E2
100
OVC End Point
UNI U2 & ENNI E2 ingress BWP
Test Procedure
Step 2
CIR
CBS
EIR
CBS
CM
CF
>0Mbps
>0B
0Mbps
0B
X
X
2.1
Tester T3 transmits C-tagged frames of size S at an average rate up to CIR, using a test traffic profile which
exercises both configured CIR and CBS at the same time, to the Operator 2 UNI U2 during a time interval T
2.2
Tester T2 measures the Frame Delay and the Frame Loss Ratio and calculates the Mean Frame Delay, the InterFrame Delay Variation, and the Frame Delay Range and verifies that the performance objectives defined in
MEF 23.1 for Performance Tier 1, High Class of Service are met
2.3
Tester T2 transmits C-tagged frames encapsulated in the outer tag mapped at the ENNI E2, of size S at an average rate up to CIR, using a test traffic profile which exercises both configured CIR and CBS at the same time, to
the Operator 2 ENNI E2 during a time interval T
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 75
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
2.4
Step 3
Tester T3 measures the Frame Delay and the Frame Loss Ratio and calculates the Mean Frame Delay, the InterFrame Delay Variation, and the Frame Delay Range and verifies that the performance objectives defined in
MEF 23.1 for Performance Tier 1, High Class of Service are met
Service Provider EVC [UNI U1 to UNI U2]
Test Bed and
Service Mapping Step 3
UNI U1
1, 2…4095*
OVC End Point
* Mapping at the UNI U1 includes untagged and priority tagged frames
UNI U2
1, 2…4095*
OVC End Point
* Mapping at the UNI U2 includes untagged and priority tagged frames
UNI U1 & UNI U2 Ingress BWP
Test Procedure
Step 3
Test Result
CIR
CBS
EIR
CBS
CM
CF
>0Mbps
>0B
0Mbps
0B
X
X
3.1
Disconnect tester T2 from ENNI E1 and from ENNI E2 and interconnect them directly
3.2
Tester T1 transmits C-tagged frames of size S at an average rate up to CIR, using a test traffic profile which
exercises both configured CIR and CBS at the same time, to the Operator 1 UNI U1 during a time interval T
3.3
Tester T3 measures the Frame Delay and the Frame Loss Ratio and calculates the Mean Frame Delay, the
Inter-Frame Delay Variation, and the Frame Delay Range and verifies that the performance objectives defined
in MEF 23.1 for Performance Tier 1, High Class of Service are met
3.4
Tester T3 transmits C-tagged frames of size S at an average rate up to CIR, using a test traffic profile which
exercises both configured CIR and CBS at the same time, to the Operator 2 UNI U2 during a time interval T
3.5
Tester T1 measures the Frame Delay and the Frame Loss Ratio and calculates the Mean Frame Delay, the
Inter-Frame Delay Variation, and the Frame Delay Range and verifies that the performance objectives defined
in MEF 23.1 for Performance Tier 1, High Class of Service are met
Test case passes if the Carrier Ethernet solution specified in the EIP Use Case 1 Phase 1 meets the performance objectives defined in MEF 23.1 for Performance Tier 1, High Class of Service while carrying bursty traffic as verified in
steps 1.2, 1.4, 2.2, 2.4, 3.3, and 3.5
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 76
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
Test Traffic
and Frame Size



Comment


At the UNI: C-tagged frames of size S, where S can be a fixed frame size or an EMIX as defined in MEF 48,
at a rate function of the tested CIR and CBS at the UNI (fixed frame size is preferred)
At the ENNI: C-tagged frames of size S encapsulated in the outer tag mapped at ENNI, where S can be a
fixed frame size or an EMIX as defined in MEF 48, at a rate function of the tested CIR and CBS at the ENNI
(fixed frame size is preferred)
Any non-conformance observed in either step 1.2, 1.4, 2.2, 2.4, 3.3, or 3.5 will be clearly identified and described in the test report
The performance objectives for PT-1 CoS H are as follows: FD ≤ 10 ms, MFD ≤ 7 ms, IFDV ≤ 3 ms, FDR ≤
5 ms, FLR ≤ 0.01%
The performance attributes must be measured and calculated as defined in MEF 10.2 section 6.9
15. Appendix II – Detailed L2CP Information – Based Upon Testing
The results shown below are from the Rapid Prototype testing of Test case 13 “L2CP
Handling – Option 2” of this Ethernet Interconnection Points – Implementation Agreement. These results are from two of the Operators’ ENNI solutions tested in a standalone
fashion.
L2CP Handling Option 2
Destination
Address
Oper
A
802.1Q
Assignment
L2CP
Oper
B
Protocol Identifier
1.3
1.5
1.3
1.5
01-80-C200-00-00
Nearest Customer
Bridge
STP/RSTP/MSTP
LLC address
0x42
FWD
FWD
FILTER
FWD
01-80-C200-00-00
Nearest Customer
Bridge
LACP/LAMP
Ethertype:
0x8809
Subtypes: 0x01,
0x02
FWD
FWD
FILTER
FWD
01-80-C200-00-00
Nearest Customer
Bridge
LLDP
Ethertype:
0x88CC
FWD
FWD
FILTER
FWD
01-80-C200-00-00
Nearest Customer
Bridge
VDP
Ethertype:
0x8940
Subtypes:
0x0001
FWD
FWD
FILTER
FWD
01-80-C200-00-00
Nearest Customer
Bridge
Port-based Network
Access Control
Ethertype:
0x888E
FWD
FWD
FILTER
FWD
01-80-C200-00-00
Nearest Customer
Bridge
MIRP
Ethertype:
0x8929
FWD
FWD
FILTER
FWD
01-80-C200-00-01
IEEE MAC Specific
Control Protocols
Pause
Ethertype:
0x8808
Subtypes:
FILTER
FILTER
FILTER
FWD
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 77
Ethernet Interconnection Point (EIP): An ENNI Implementation Agreement
0x0001
01-80-C200-00-01
IEEE MAC Specific
Control Protocols
PFC
Ethertype:
0x8808
Subtypes:
0x0101
FWD
FWD
FILTER
FWD
01-80-C200-00-01
IEEE MAC Specific
Control Protocols
Multipoint MAC
Control
Ethertype:
0x8808 Subtypes:
0x0002-0x0006
FWD
FWD
FILTER
FWD
01-80-C200-00-01
IEEE MAC Specific
Control Protocols
Organization
Specific Extensions
Ethertype:
0x8808
Subtypes:
0xFFFE
FWD
FWD
FILTER
FWD
01-80-C200-00-02
IEEE 802 Slow
Protocols
LACP/LAMP
Ethertype:
0x8809
Subtypes: 0x01,
0x02
FWD
FWD
FILTER
FWD
01-80-C200-00-02
IEEE 802 Slow
Protocols
Link OAM
Ethertype:
0x8809
Subtype: 0x03
FWD
FWD
FILTER
FWD
01-80-C200-00-02
IEEE 802 Slow
Protocols
ESMC
Ethertype:
0x8809
Subtype: 0x0A
FWD
FWD
FILTER
FILTER
01-80-C200-00-03
Nearest nonTPMR Bridge
LACP/LAMP
Ethertype:
0x8809
Subtypes: 0x01,
0x02
FWD
FWD
FILTER
FWD
01-80-C200-00-03
Nearest nonTPMR Bridge
Port Authentication
Ethertype:
0x888E
FWD
FWD
FILTER
FWD
01-80-C200-00-03
Nearest nonTPMR Bridge
LLDP
Ethertype:
0x88CC
FWD
FWD
FILTER
FWD
01-80-C200-00-03
Nearest nonTPMR Bridge
PE-CSP
Ethertype:
0x8940
Subtypes:
0x0002
FWD
FWD
FILTER
FWD
01-80-C200-00-03
Nearest nonTPMR Bridge
Port-based Network
Access Control
Ethertype:
0x888E
FWD
FWD
FILTER
FWD
01-80-C200-00-04
IEEE MAC Specific
Control Protocols
FWD
FWD
FILTER
FWD
MEF 54
© MEF Forum 2016. Any reproduction of this document, or any portion thereof, shall contain the following statement: "Reproduced with permission of MEF Forum." No user of this document is authorized to
modify any of the information contained herein.
Page 78
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising