Technical Specification

MEF 45

Multi-CEN L2CP

August, 2014

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the
following statement: "Reproduced with permission of the 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 con-
tained herein and no liability of any kind shall be assumed by the MEF as a result of reli-
ance upon such information.

The information contained herein is intended to be used without modification by the re-
cipient or user of this document. The MEF is not responsible or liable for any modifica-
tions 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 im-
plication or otherwise:

 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, con-
cepts or expressions contained herein; nor

 any warranty or representation that any MEF member companies will an-
nounce any product(s) and/or service(s) related thereto, or if such an-
nouncements are made, that such announced product(s) and/or service(s)
embody any or all of the ideas, technologies, or concepts contained herein;
nor

 any form of relationship between any MEF member companies and the re-
cipient or user of this document.

Implementation or use of specific Metro Ethernet standards or recommendations and

MEF specifications will be voluntary, and no company shall be obliged to implement
them by virtue of participation in the MEF Forum. The MEF is a non-profit international
organization accelerating industry cooperation on Metro Ethernet technology. The MEF
does not, expressly or otherwise, endorse or promote any specific products or services.

© The MEF Forum 2014. All Rights Reserved.

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

Table of Contents
1 List of Contributing Members ...........................................................................................1
2 Abstract ...............................................................................................................................1
3 Terminology ........................................................................................................................1
4 Compliance Level Definitions (MUST, SHOULD, MAY) .................................................2
5 Scope ...................................................................................................................................2
5.1 Comparison with MEF 6.1.1 ..........................................................................................3
6 Background information for L2CP ....................................................................................3
6.1 L2CP Frames and L2CP Addresses ................................................................................4
6.2 Bridge Reserved Addresses ............................................................................................4
6.3 MRP Reserved Addresses ..............................................................................................7
7 The L2CP Behavioral Model ..............................................................................................7
7.1 The L2CP Decision Point ...............................................................................................8
7.1.1 Discard ............................................................................................................................. 10
7.1.2 Peer .................................................................................................................................. 10
7.1.3 Pass .................................................................................................................................. 11
7.2 Subscriber/SP view of the L2CP Behavioral Model ...................................................... 11
7.3 Operator/SP view of the L2CP Behavioral Model......................................................... 13
7.3.1 L2CP Behavioral Model with a VUNI .............................................................................. 14
8 L2CP Service Attributes ................................................................................................... 15
8.1 L2CP Address Set Service Attribute ............................................................................. 15
8.2 L2CP Peering Service Attribute .................................................................................... 18
8.2.1 Requirements for peering specific Layer 2 Control Protocols ............................................ 20
8.3 ENNI Tagged L2CP Frame Processing Service Attribute ............................................. 21
9 L2CP Processing Requirements ....................................................................................... 22
9.1 UNI and VUNI L2CP Frame Processing Requirements ................................................ 22
9.1.1 UNI L2CP Frame Processing for EPL Option 2 L2CP Processing ..................................... 24
9.1.2 Example L2CP Frame evaluation at a UNI L2CP Decision Point ...................................... 25
9.2 ENNI L2CP Processing Requirements.......................................................................... 26
9.2.1 Example L2CP Frame evaluation at a ENNI L2CP Decision Point .................................... 28
10 Service Requirements for L2CP ................................................................................... 29
10.1 EVPL, EVP-LAN, and EVP-Tree Service Requirements .............................................. 29
10.2 EPL, EP-LAN, and EP-Tree Service Requirements ...................................................... 29
10.3 Access EVPL, Access EPL and UTA Service Requirements ........................................ 30
10.3.1 Access EVPL Service Requirements ................................................................................. 30
10.3.2 Access EPL Service Requirements.................................................................................... 30
10.3.3 UNI Tunnel Access (UTA) Service Requirements ............................................................ 31
10.4 VUNI L2CP Service Requirements .............................................................................. 32
10.5 vNID Service Requirements ......................................................................................... 33
10.5.1 vNID Case A Service Requirements ................................................................................. 33
10.5.2 vNID Case B Service Requirements.................................................................................. 34

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page i
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

11 References ...................................................................................................................... 35
Appendix A Summary of L2CP Service Attributes .......................................................... 37
Appendix B L2CP Examples / Use Cases .......................................................................... 38
B.1 Link Aggregation (LACP/LAMP) ................................................................................ 38
B.1.1 Peering LACP at a UNI .................................................................................................... 39
B.1.2 Peering LACP at a ENNI .................................................................................................. 39
B.1.3 LACP and EPL Option 2 L2CP processing ....................................................................... 40
B.1.4 Aggregation of EPL services ............................................................................................ 40
B.1.5 Configuring Link Aggregation for Active/Standby operation ............................................ 41

List of Figures
Figure 1 – Scope of Reserved MAC Addresses for an EPL..........................................................7
Figure 2 – L2CP Decision Point ..................................................................................................9
Figure 3 – L2CP Behavioral Model for Subscriber/SP ............................................................... 12
Figure 4 – L2CP Behavioral Model for Operator/SP ................................................................. 13
Figure 5 – L2CP Behavioral Model for Operator with a VUNI .................................................. 15
Figure 6 – Flow Chart for UNI and VUNI Decision Points ........................................................ 23
Figure 7 – Flow Chart for ENNI Decision Point ........................................................................ 27
Figure 8 – Basic Link Aggregation at a UNI.............................................................................. 39
Figure 9 – Basic Link Aggregation at an ENNI ......................................................................... 39
Figure 10 – Link Aggregation of EPL Services ......................................................................... 40
Figure 11 – Link Aggregation of EPL services with protected UNIs .......................................... 41

List of Tables
Table 1 – Terminology ................................................................................................................2
Table 2 – List of Standardized L2CP Destination MAC Addresses ..............................................4
Table 3 – Bridge Block of Reserved L2CP Addresses .................................................................6
Table 4 – Decision Point Service Attributes .............................................................................. 10
Table 5 – L2CP Address Sets .................................................................................................... 16
Table 6 – Example L2CP Peering Service Attribute .................................................................. 18
Table 7 – Selected Layer 2 Control Protocols ............................................................................ 19
Table 8 – EPL Option 2 L2CP Processing Requirements ........................................................... 24
Table 9 – EPL Option 2 L2CP Processing Recommendations.................................................... 25
Table 10 – UNI L2CP Service Attributes for Ethernet Virtual Private Services ......................... 29
Table 11 – UNI L2CP Service Attributes for Ethernet Private Services ..................................... 29
Table 12 – UNI L2CP Service Attribute for Access EVPL ........................................................ 30
Table 13 – OVC L2CP Service Attributes for Access EVPL ..................................................... 30
Table 14 – ENNI L2CP Service Attributes for Access EVPL .................................................... 30
Table 15 – UNI L2CP Service Attributes for Access EPL ......................................................... 31
Table 16 – OVC L2CP Service Attributes for Access EPL ........................................................ 31
Table 17 – ENNI L2CP Service Attributes for Access EPL ....................................................... 31
Table 18 – UNI L2CP Service Attributes for UTA .................................................................... 32
Table 19 – OVC L2CP Service Attributes for UTA ................................................................... 32
Table 20 – ENNI L2CP Service Attributes for UTA .................................................................. 32

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page ii
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

Table 21 – VUNI L2CP Service Attributes for VUNI Service ................................................... 32

Table 22 – OVC L2CP Service Attributes for VUNI Service ..................................................... 33
Table 23 – UNI L2CP Service Attribute for vNID Case A ......................................................... 33
Table 24 – OVC L2CP Service Attributes for vNID Case A ...................................................... 33
Table 25 – ENNI L2CP Service Attributes for vNID Case A ..................................................... 34
Table 26 – UNI L2CP Service Attributes for vNID Case B ....................................................... 34
Table 27 – OVC L2CP Service Attributes for vNID Case B ...................................................... 34
Table 28 – ENNI L2CP Service Attributes for vNID Case B ..................................................... 35
Table 29 – UNI L2CP Service Attributes .................................................................................. 37
Table 30 – OVC L2CP Service Attributes ................................................................................. 37
Table 31 – ENNI L2CP Service Attributes ................................................................................ 37
Table 32 – VUNI L2CP Service Attributes ................................................................................ 38
Table 33 – LACP Destination Addresses ................................................................................... 39

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page iii
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

1 List of Contributing Members

The following members of the MEF participated in the development of this document
and have requested to be included in this list.

Allstream Comcast
Bell Canada Huawei Technologies
Calix Infinera Corporation
Carrier Ethernet Academy Iometrix
Ciena Corporation KDDI
Cogeco Cable Inc. PLDT (Phillipines Long Distance Phone Company)
Colt RAD Data Communications

2 Abstract
This document specifies the service attributes and requirements for handling Layer 2
Control Protocol (L2CP) Frames in a Carrier Ethernet Network.

3 Terminology
This section defines the terms used in this document. In many cases, the normative defi-
nitions 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.

Terms defined in MEF 4 [16], MEF 6.2 [17], MEF 10.3 [19], and MEF 26.1 [24] are in-
cluded in this document by reference and, hence, not repeated in table below.

Term Definition Ref

An action taken at a L2CP Decision Point where a This
L2CP frame is neither delivered to a protocol entity, docu-
Discard nor delivered to the External Interface where the ment
L2CP Decision Point is located, nor propagated to
L2CP Decision Points at other External Interfaces.
Filter An action that prevents a frame from being propagat-
This
ed within a bridge or within a network. docu-
ment
Layer 2 Control The fundamental element of the L2CP Behavioral This
Protocol Decision Model that determines how a L2CP Frame is pro- docu-
Point cessed at an External Interface ment
Layer 2 Control A L2CP Service Frame or L2CP ENNI Frame This
Protocol Frame docu-
ment

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 1
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

Term Definition Ref

An action taken at a L2CP Decision Point where a This
L2CP frame is either delivered to the External Inter- docu-
face where the L2CP Decision Point is located, or ment
Pass
propagated to the L2CP Decision Points located at all
other External Interfaces associated by the EVC or
OVC.
An action taken at a L2CP Decision Point where a This
Peer L2CP frame is delivered to a protocol entity deter- docu-
mined by the Protocol Identifier in the L2CP Frame. ment
Table 1 – Terminology

4 Compliance Level Definitions (MUST, SHOULD, MAY)

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 [15]. All key words must be
in upper case, bold text.

Items that are REQUIRED (contain the words MUST or MUST NOT) are labeled as
[Rx] for required. Items that are RECOMMENDED (contain the words SHOULD or
SHOULD NOT) are labeled as [Dx] for desirable. Items that are OPTIONAL (contain
the words MAY or OPTIONAL) are labeled as [Ox] for optional.

5 Scope
This document specifies the processing of Layer2 Control Protocol (L2CP) Frames for
services spanning one or more Carrier Ethernet Networks (CEN). A L2CP Frame is de-
fined as any frame containing a destination address that is one of the 32 addresses re-
served for control protocols by IEEE Std 802.1Q-2011 [5] (see Table 2 of this document).
This does not include SOAM Frames, nor does it include proprietary or standardized con-
trol protocols that use other addresses for a destination address (these could be considered
for a future phase of the document).

The specification develops a behavior model of L2CP treatment for services delivered
across multiple CENs that supersedes the single CEN requirements in MEF 6.1.1 [18].
The model includes the attributes and basic requirements for passing, peering, or discard-
ing L2CP Frames at a UNI [19], VUNI [25], and ENNI [24], as well as detailed peering
requirements for selected protocols and/or services. The model is developed with a goal
of promoting interoperability by minimizing configuration and providing testable re-
quirements.

An informative annex summarizes relevant information about common protocols.

Requirements on customer equipment are not within the scope of this document. None-
theless, proper configuration of the customer equipment with respect to L2CP is neces-
sary to achieve proper operation of the protocols. Such configuration is typically proto-

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 2
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

col specific. One example is that if Link Aggregation is enabled at a UNI, both the cus-
tomer equipment and provider equipment need to use the same Destination Address in
Link Aggregation Control Protocol (LACP, [2]) frames. Another example is that if an
EP-LAN service passes Rapid Spanning Tree Protocol (RSTP, [4]) frames at all UNIs,
the service will look like shared media to the protocol, and therefore the customer equip-
ment should configure the RSTP port connected to the UNI as a port to shared media ra-
ther than a point-to-point link.

5.1 Comparison with MEF 6.1.1

This document supersedes MEF 6.1.1[18] for specifying L2CP processing requirements.
It maintains as much consistency with the requirements in MEF 6.1.1 as possible given
the expanded scope of covering multiple CENs. The primary differences from MEF
6.1.1 are:

 Rather than treat the L2CP processing within the CEN as a monolithic whole, this
document focuses on L2CP processing requirements at External Interfaces. This
allows specification of different processing requirements at different types of in-
terfaces and in different operator networks within the CEN. A notable conse-
quence of this is the avoidance of the word “Tunnel”, which is defined as a behav-
ior of the network and is difficult to use as a description of behavior at an inter-
face. In this document the word “Pass” is used for the analogous interface behav-
ior, and if all interfaces associated by a service Pass an L2CP frame then the end-
to-end service behavior is the same as “Tunnel”.

 This document does not suppose that service agreements between a Subscriber
and Service Provider or Operator and Service Provider will specify the treatment
of every imaginable Layer 2 Control Protocol. Rather, this document provides a
service attribute for listing which L2CP frames are to be Peered at a given Exter-
nal Interface. Treatment of L2CP Frames that are not Peered is determined algo-
rithmically, based largely on the type of interface and the Destination Address in
the L2CP Frame.

 Both this document and MEF 6.1.1 specify L2CP behavior that is consistent with
IEEE 802.1 L2CP processing rules, with the exception of EPL services with EPL
Option 2 L2CP processing. The specification of EPL Option 2 L2CP processing
in this document is taken directly from MEF 6.1.1, but updated to support a multi-
CEN environment. Recommendations are added for the processing of L2CP
Frames not covered by the MEF 6.1.1 specification of EPL Option 2 L2CP pro-
cessing.

 The treatment of L2CP Frames with MRP Addresses (section 6.3) is expanded to
allow (but not require) Peering of these protocols.

6 Background information for L2CP

The L2CP processing specified in this document is based largely on the IEEE 802.1Q [5]
specification for handling L2CP Frames. IEEE 802.1Q provides a mechanism for sepa-
MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 3
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

rating the Layer 2 control plane into multiple customer and provider control planes. It
allows a protocol to operate solely within a provider network, or solely within a customer
network, or to allow interaction between the customer and provider network. It addition-
ally provides a mechanism for customer L2CP Frames to pass transparently through a
provider network while maintaining isolation from the control plane of other customer
networks. It provides a set of forwarding rules, based on a set of reserved addresses, that
allow a L2CP Frame using one of those addresses to be properly forwarded or filtered
without requiring protocol-specific configuration. Most Layer 2 Control Protocols have
been defined to use these addresses and to operate according to the IEEE 802.1Q rules.
This document abstracts the IEEE 802.1Q rules for bridges to specifications for handling
L2CP Frames at the External Interfaces of a CEN. This provides a high probability that
control protocols, and the customer equipment using those protocols, will interoperate
with the CEN.

The remainder of this section provides background on the IEEE 802.1Q mechanisms for
handling L2CP Frames. The subsequent sections adapt this to a CEN model based on
service attributes and requirements for the External Interfaces of the CEN.

6.1 L2CP Frames and L2CP Addresses

This document defines an L2CP Frame as any frame with a Destination Address that is
from one of two blocks of multicast addresses, shown in Table 2, that have been reserved
by the IEEE 802.1 Working Group1. These addresses have special forwarding rules in
IEEE 802.1 Bridges that facilitate the deployment and operation of Layer 2 Control Pro-
tocols. While a protocol that affects the configuration or operation of a Layer 2 network
can use frames with ordinary unicast or multicast addresses, those protocols that are con-
sidered Layer 2 Control Protocols use these reserved addresses to take advantage of the
special forwarding rules. Note that although the MEF does not specify what Layer 2
technology is used within a CEN, non-802.1 technologies can adopt these forwarding
rules to assure correct operation of protocols using these addresses.

L2CP MAC Destination Addresses2 Description

01-80-C2-00-00-00 through 01-80-C2-00-00-0F Bridge Block of protocols
01-80-C2-00-00-20 through 01-80-C2-00-00-2F MRP Block of protocols
Table 2 – List of Standardized L2CP Destination MAC Addresses

6.2 Bridge Reserved Addresses

The IEEE 802.1 Bridge Reserved Addresses3 are shown in Table 3. The special forward-
ing rule for L2CP Frames with a Destination Address from this block is that a bridge, de-

1
MEF 10.3 allows a Service Provider to define additional addresses that result in frames containing those addresses
to be considered L2CP Frames. Such frames are beyond the scope of this document.
2
Hexadecimal canonical format
3
All LANs Bridge Management Group Address (01-80-C2-00-00-10) was deprecated in IEEE Std 802.1Q-2005
(subclause 8.13.7) and there are no longer any special filtering requirements for this address.
MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 4
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

pending on the bridge type, will filter the frame. That is, the bridge will not propagate
the frame from the ingress port to any other port of the bridge. The significance of this
rule is that a protocol entity in one device can send a frame intended to reach a peer pro-
tocol entity in a neighboring device and be confident that the frame will not propagate
beyond the neighboring device even if the neighbor does not actually recognize the pro-
tocol. This prevents the frame from propagating through the network to other devices
where the information could be misinterpreted. Many protocols, including Link Aggre-
gation Control Protocol (LACP, [2]), Link Layer Discovery Protocol (LLDP, [1]), Link
Operation Administration and Management (Link OAM, [12]), and others rely on this
forwarding behavior.

Different types of devices filter different subsets of the Bridge Reserved Addresses. End
Stations, bridges that do not recognize VLAN tags (MAC Bridges) and bridges that rec-
ognize and respond to C-VLAN tags (Customer Bridges and Provider Edge Bridges) ap-
ply the special forwarding rule to all of the addresses in the block. Bridges that recognize
and respond only to S-VLAN tags (Provider Bridges) apply the special forwarding rule to
a subset of these addresses as shown in Table 3. Two Port MAC Relays (TPMRs) apply
the special forwarding rule to a smaller subset of these addresses as shown in Table 3.
The different subsets allow a sending device to select the type of device intended to re-
ceive the frame by the choice of destination address. For example, a frame with the
Nearest Bridge address (01-80-C2-00-00-0E) will only traverse a single link before it is
filtered by the neighboring device. On the other hand a frame with the Nearest Customer
Bridge address (01-80-C2-00-00-00) will be forwarded through any TPMRs and Provider
Bridges, including an entire Provider Network, and will not be peered or discarded until it
reaches a Customer Bridge (or a device that does not forward layer2 frames such as a
server or router).

Filtered by:
Address Assignment
End Station, Provider Two Port
MAC Bridge, Bridge MAC Relay
Customer
Bridge, Pro-
vider Edge
Bridge
01-80-C2-00-00-00 Nearest Customer Bridge X
01-80-C2-00-00-01 IEEE MAC Specific Control Protocols X X X
01-80-C2-00-00-02 IEEE 802 Slow Protocols X X X
01-80-C2-00-00-03 Nearest non-TPMR Bridge X X
01-80-C2-00-00-04 IEEE MAC Specific Control Protocols X X X
01-80-C2-00-00-05 Reserved for Future Standardization X X
01-80-C2-00-00-06 Reserved for Future Standardization X X
01-80-C2-00-00-07 MEF Forum ELMI X X
01-80-C2-00-00-08 Provider Bridge Group X X

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 5
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

Filtered by:
Address Assignment
End Station, Provider Two Port
MAC Bridge, Bridge MAC Relay
Customer
Bridge, Pro-
vider Edge
Bridge
01-80-C2-00-00-09 Reserved for Future Standardization X X
01-80-C2-00-00-0A Reserved for Future Standardization X X
01-80-C2-00-00-0B Reserved for Future Standardization X
01-80-C2-00-00-0C Reserved for Future Standardization X
01-80-C2-00-00-0D Provider Bridge MVRP X
01-80-C2-00-00-0E Nearest Bridge, Individual LAN Scope X X X
01-80-C2-00-00-0F Reserved for Future Standardization X

Table 3 – Bridge Block of Reserved L2CP Addresses

In many cases a single network device can run multiple instances of the same protocol,
each transmitting and receiving frames with different destination addresses to communi-
cate with devices in different parts of a network. For example, consider running LLDP
between devices supporting the EPL service shown in Figure 1. The Customer Edge
(CE, [16]) equipment could run an instance of LLDP using the Nearest Bridge address to
communicate with Provider Edge (PE, [16]) equipment across a UNI, and another in-
stance of LLDP using the Nearest Customer Bridge address to communicate with CE
equipment at a remote UNI.
UNI
UNI

ENNI

CE PE PE PE PE CE

Scope of the “Nearest Bridge” address:

Scope of the “Nearest Customer Bridge” address:

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 6
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

Figure 1 – Scope of Reserved MAC Addresses for an EPL

In other cases a single protocol running in different regions of a network will use a differ-
ent address to maintain separation between protocol operation in the respective regions.
For example, RSTP running in the Subscriber network will use the Nearest Customer
Bridge address, and RSTP running in the CENs will use the Provider Bridge Group ad-
dress.

Note that each of the Bridge Reserved Addresses can be used by many different proto-
cols. Initially, when the number of L2CPs was small, the IEEE specified different ad-
dresses for use by each protocol. Unfortunately this implied the address was specific to
the protocol, and caused confusion as the number of L2CPs grew and the IEEE began to
specify the same address for use by several different protocols. It is important to recog-
nize that the Protocol Identifier 4 in an L2CP frame is what identifies the protocol. The
destination address determines the intended recipient device for the frame.

6.3 MRP Reserved Addresses

The IEEE 802.1 Multiple Registration Protocol (MRP) Addresses are a block of 16 ad-
dresses in the second row of Table 2. The special forwarding rule for any frame with one
of these addresses as a destination is that a bridge will Pass (section 7.1.3) the frame only
if it does not Peer (section 7.1.2) any protocol using this address. If the bridge Peers any
protocol using this address then it will either Peer the frame (if the Protocol ID matches
the Peered protocol) or Discard the frame (if the Protocol ID does not match the Peered
protocol). This forwarding rule allows a protocol entity to send a frame to the nearest
device that understands the protocol. Any intervening devices that do not understand the
protocol will forward the frame. This is in contrast with the Bridge Reserved address
forwarding rule which calls for some types of intervening devices that do not understand
the protocol to discard the frame. The MRP address forwarding rule is useful for proto-
cols such as Multiple MAC Registration Protocol (MMRP) that propagate information
hop by hop between devices that run the protocol, but are tolerant of intervening devices
that do not run the protocol.

7 The L2CP Behavioral Model

MEF specifications describe the characteristics of a service on a CEN in terms of attrib-
utes and requirements of the interfaces (UNI or ENNI) and the virtual connections (EVC
or OVC) used to construct the service. The purpose of the L2CP behavioral model is to
describe how the CEN handles L2CP Frames in these terms. Note that this model de-
scribes the behavior of the CEN per L2CP Frame, not per protocol.

The behavioral model needs to describe the behavior of the CEN from two distinctly dif-
ferent viewpoints. One is the Subscriber/SP viewpoint, from which the CEN is a mono-
lithic network observable only at the UNIs. The other is the Operator/SP viewpoint, from
which the overall network can be seen to consist (potentially) of multiple operator CENs
and is observable at ENNIs as well as at UNIs. If the model were only concerned with

4
The Protocol Identifier can be a LLC Address or an Ethertype, and in some cases may include a sub-type field.
MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 7
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

the Subscriber/SP viewpoint it would be sufficient to describe the overall behavior of the
network simply in terms of the end results observable at UNIs. It would not be important
to know specifically where in the network the actions occurred that resulted in the ob-
served behavior. From the Operator/SP viewpoint however, it is important to know
where actions are taken on L2CP Frames.

There are several reasons why it is important to know where actions are taken on L2CP
Frames on a service that spans multiple operator networks interconnected by ENNIs.
These include:

 In a multi-CEN network it is necessary to know which operator is responsible for

Peering or Discarding an L2CP Frame when that is the expected behavior from
the Subscriber/SP viewpoint. In some cases it might be the responsibility of the
operator with the ingress UNI, but in a scenario with a UNI Tunnel Access (UTA)
service, for example, it might make more sense for it to be the responsibility of
the operator with the VUNI [25].

 Clear identification of the actions expected from each Operator's network in a

multi-CEN service will enable MEF to specify certification guidelines that pro-
mote interoperability and facilitate CEN interconnect.

 A multi-CEN network has different types of interfaces (UNIs, ENNIs, and poten-
tially VUNIs), and the L2CP actions can be different depending on the interfaces
involved. For example, an ingress L2CP ENNI Frame might be delivered un-
changed as an egress L2CP ENNI Frame at an ENNI associated by the OVC, but
Peered or Discarded at an egress UNI.

 At an ENNI it can be necessary to specify how provider L2CP Frames are han-
dled, such as when Link Aggregation is used for link failure protection at an EN-
NI, and how the provider protocol frames are differentiated from customer proto-
col frames.

The L2CP Behavioral Model resolves these issues by describing behavior as ingress ac-
tions or egress action that take place at an external interface. It is important to recognize
that the model is a tool used to describe the expected behavior, not a specification of how
an operator network is implemented. An action that the model describes as an ingress
action at a UNI need not be implemented in the actual device that provides the physical
interface for the UNI. The only constraint on the operator or service provider is that the
externally observable behavior matches the behavior described by the model.

7.1 The L2CP Decision Point

The basic construct of the L2CP behavioral model is a Decision Point that determines
how an L2CP Frame is processed at an External Interface. Figure 2 shows the represen-
tation of this Decision Point in L2CP behavioral model diagrams. L2CP Frames that en-
ter the Decision Point from the External Interface will either be Passed to the EVC (or
OVC), or Peered by redirecting the frame to a Protocol Entity, or Discarded. The black

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 8
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

dots in Figure 2 represent these three options. L2CP Frames that enter the Decision Point
from the EVC (or OVC) will either be Passed to the External Interface, or Peered by redi-
recting the frame to a Protocol Entity, or Discarded. The white dots in Figure 2 represent
these three [Link] is one Decision Point for each UNI, ENNI and VUNI within a
CEN.

Protocol Frames generated by

a Protocol Entity
Entities
Frames propagated
Ingress

Peer
to Decision Points
L2CP Frames at other EIs
External Pass EVC or
Interface Pass OVC
Discard

Egress
Frames propagated
L2CP Frames
Decision from Decision Points
Point at other EIs

Figure 2 – L2CP Decision Point

The action taken for a given L2CP Frame at a given Decision Point depends upon the
Destination Address and the Protocol Identifier within the frame, and upon the config-
ured values of the L2CP Service Attributes. The service attributes used by an L2CP De-
cision Point are determined by the location of that Decision Point as summarized in Table
4.

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 9
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

Decision Point L2CP Service Attributes used by Decision Point

location

UNI  UNI L2CP Peering service attribute

 UNI L2CP Address Set service attribute

VUNI  VUNI L2CP Peering service attribute

 VUNI L2CP Address Set service attribute

ENNI  ENNI L2CP Peering service attribute

 ENNI Tagged L2CP Frame Processing service attribute
 OVC L2CP Address Set service attribute (for each OVC
with an OVC End Point at the ENNI)

Table 4 – Decision Point Service Attributes

The definitions and associated requirements of the L2CP Service Attributes are specified
in section 8. The detailed description of how the Decision Point determines the action
taken for a given L2CP Frame is specified in the flow charts and requirements in section
9. For the purposes of understanding the model it is sufficient to know that the three pos-
sible actions at a Decision Point are Discard, Peer5, or Pass6:

7.1.1 Discard

Discard means the L2CP Frame is neither Peered nor propagated toward any External
Interface (EI). As an ingress action at an EI this means the frame will not be propagated
to any EI. As an egress action at an EI this means the frame will not result in an egress
L2CP Frame at that EI.

7.1.2 Peer

Peer means the L2CP Frame is delivered to a protocol entity that participates in the spe-
cific Layer 2 Control Protocol determined by the Protocol Identifier (Ethertype or LLC
Address) in the frame. The protocol entity qualifies and potentially processes the frame
according to the specification of the particular protocol. (These protocol specifications
are typically published by other standards organizations, and are beyond the scope of this
document.) Qualifying the frame is protocol specific and can include validating the Des-
tination Address, VLAN ID, protocol identifier, version number length, TLV format, etc.
Processing the frame is also protocol specific and can include:

5
Note that “Peer” is used as a verb in the context of L2CP processing.
6
In MEF 10.2 there is a fourth option that is “Peer and Pass to the EVC”. In MEF 10.2 these were actions taken per
protocol, and for some protocols it was allowable to Peer some frames and Pass others depending on the destination
address. Since the model in this document specifies per frame behavior, the “Peer and Pass” option is not necessary.
MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 10
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

 changing local state information,

 invoking actions based on the contents of the frame,

 generating an egress L2CP Frame at the External Interface,

 generating a L2CP Frame that is propagated on an EVC or OVC to all External

Interfaces associated by that EVC or OVC or

 ignoring the frame (taking no action).

Note that the protocol entity typically does not process a L2CP Frame by generating an
identical L2CP Frame, however that behavior is not explicitly prohibited.

7.1.3 Pass

Pass means the L2CP Frame is handled in the same manner as a Data Frame with an mul-
ticast destination address. As an egress action at an EI this results in an egress L2CP
Frame at that EI. As an ingress action at an EI this results in the propagation of the frame
to the L2CP Decision Point at all other UNIs associated by the EVC (when all UNIs are
in a single CEN), or all other OVC End Points associated by the OVC (when not all UNIs
are in a single CEN), to which the L2CP Frame is mapped. The mechanism of mapping
of L2CP Frames to an EVC or OVC End Point is the same as the mapping of Data
Frames. The propagation of L2CP Frames within the CEN7 is subject to the same con-
straints as Data Frames8. For example:

 Frames at a UNI with a CE-VLAN ID that does not map to any EVC or OVC End
Point, and frames at a ENNI with an S-VID that does not map to any End Point,
are not propagated.

 For Rooted Multipoint EVCs [19] and OVCs [24], frames that ingress at a Leaf
are not propagated to another Leaf.

 Frames that are declared Red by an Ingress Bandwidth Profile or discarded in or-
der to comply with an Egress Bandwidth Profile are not propagated.

7.2 Subscriber/SP view of the L2CP Behavioral Model

Figure 3 shows the Subscriber/SP view of the L2CP Behavioral Model. This figure rep-
resents a simple case where there are two UNIs associated by a single EVC, but more
complex examples are easily constructed. There is a L2CP Decision Point for each
UNI. How the model is used to specify L2CP behavior can be seen by following a L2CP
frame through the network.
7
MEF does not mandate how the content of a Service Frame is forwarded within a CEN. For simplicity of dis-
course, we say that the frame (or a copy of the frame) is propagated but any method of forwarding the content of the
ingress frame is acceptable.
8
Note that the performance objectives for L2CP Frames may differ from Data Frames since L2CP Frames can map
to a different CoS Name than Data Frames.
MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 11
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

CEN

Protocol Protocol
Entities Entities
UNI UNI

UNI DP UNI DP

Figure 3 – L2CP Behavioral Model for Subscriber/SP

When an ingress L2CP Service Frame enters the network at one of the UNIs, it is evalu-
ated by a UNI L2CP Decision Point that determines whether the frame is to be Discarded,
Peered, or Passed. The Decision Point at the ingress UNI is referred to as the ingress De-
cision Point for the frame. If the determination of the ingress Decision Point is to Pass
the frame, it will be mapped to an EVC and the frame will be propagated to the L2CP
Decision Point at all other UNIs associated by that EVC. These Decision Points are re-
ferred to as the egress Decision Points for the frame, and the frame at this point is re-
ferred to as a potential egress frame. The egress Decision Point evaluates the potential
egress frame and determines whether it is to be Discarded, Peered, or Passed. If the
frame is Passed then it results in an egress L2CP Service Frame at that UNI.

The behavior observed between any pair of UNIs is the combination of the determina-
tions made by the ingress and egress Decision Points. If either Decision Point Discards
the frame then the ingress L2CP Service Frame does not result in an egress L2CP Service
Frame. If either Decision Point Peers the frame then the ingress L2CP Service Frame is
not delivered to any other EI, however there could be indirect protocol specific results of
the Peering that would be observable as described in Section 7.1.2. If both Decision
Points Pass the frame then the ingress L2CP Service Frame at one UNI can result in an
egress L2CP Service Frame at the other UNI. Note that an ingress L2CP Service Frame
that is Passed at all UNI Decision Points associated by an EVC results in the behavior
described as “Tunnel” in earlier MEF specifications.

The model can also be used to describe L2CP behavior not directly triggered by an in-
gress L2CP Service Frame at a UNI. For example, when there is a protocol entity for a
particular protocol at a UNI Decision Point, that protocol entity can generate frames that

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 12
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

are subsequently observed as egress L2CP Service Frames at that UNI. Some protocols
propagate information within the network by generating frames that are propagated to the
L2CP Decision Points at all other UNIs associated by the EVC. Unless these frames are
Passed at an egress UNI Decision Point they will never be observable as an egress L2CP
Service Frame, but in a multi-CEN network they could be observable at an ENNI.

7.3 Operator/SP view of the L2CP Behavioral Model

Figure 4 shows the Operator/SP view of the L2CP Behavioral Model. This figure repre-
sents a simple case where there are two UNIs associated by a single EVC that spans two
CENs via a single ENNI, but more complex examples are easily constructed. There are
Decision Points for each UNI and each ENNI in each CEN. How the model is used to
specify L2CP behavior can be seen by following a L2CP frame through the network.

CEN CEN
Protocol Protocol Protocol Protocol
Entities Entities Entities Entities
UNI ENNI UNI

UNI DP ENNI DP ENNI DP UNI DP

Figure 4 – L2CP Behavioral Model for Operator/SP

When an ingress L2CP Service Frame enters the network at one of the UNIs, it is evalu-
ated by a UNI L2CP Decision Point that determines whether the frame is to be Discarded,
Peered, or Passed. If the determination of the ingress Decision Point is to Pass the frame,
it will be mapped to an OVC and propagated to the L2CP Decision Point at all other
OVC End Points associated by that OVC. These Decision Points are referred to as the
egress Decision Points, and a frame at an egress decision point is referred to as a potential
egress frame. The egress Decision Point then evaluates the frame and determines wheth-
er it is to be Discarded, Peered, or Passed. If the frame is Passed at an egress ENNI Deci-
sion Point then it results in an egress L2CP ENNI Frame at that ENNI, which in turn re-
sults in an ingress L2CP ENNI Frame in the other operator network. The ingress L2CP
ENNI Frame is evaluated at an ENNI L2CP Decision Point, and the process described for
the first operator network repeats in the second operator network. The L2CP Frame can
be Peered or Discarded at any of the L2CP Decision Points, but as long as it is Passed it
continues to propagate just as a Data Frame would through the interconnected operator
networks.

Focusing on a single operator network, the behavior observed between any pair of Exter-
nal Interfaces is the combination of the determinations made by the ingress and egress
MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 13
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

Decision Points within that operator network. If either Decision Point Discards the frame
then the ingress L2CP Frame does not result in an egress L2CP Frame. If either Decision
Point Peers the frame then the ingress L2CP Frame does not result in an egress L2CP
Frame, however there could be indirect protocol specific results of the Peering that would
be observable. If both Decision Points Pass the frame then the ingress L2CP Frame at
one EI can result in an egress L2CP Frame at the other EI.

The behavior observed between any pair of UNIs associated by an EVC that spans multi-
ple operator networks is the combination of the determinations made by all of the L2CP
Decision Points encountered in each of the operator networks between the UNIs. The
L2CP service attributes in the Operator/SP agreements are specified such that the behav-
ior observed between the UNIs is the same as the behavior determined by the specifica-
tion of the L2CP service attributes in the Subscriber/SP agreement.

Note that L2CP Frames observed at ENNIs could have resulted from an ingress L2CP
Service Frames at one of the UNIs, or could have resulted from a L2CP frame generated
by a Protocol Entity in a operator network. The latter case includes frames associated
with provider Layer2 Control Protocols, used to control some aspect of the CEN opera-
tion, that are not associated with any customer Layer2 Control Protocols carried on a ser-
vice within the CEN. A typical example of a provider protocol is LACP running at an
ENNI to provide active and standby links for the ENNI. The L2CP behavioral model,
together with the service attributes, flow charts and requirements of sections 8 and 9, de-
termine the behavior related to both customer and provider L2CP Frames.

7.3.1 L2CP Behavioral Model with a VUNI

Figure 5 shows the L2CP Behavioral Model for a CEN with a VUNI. The figure shows a
simple case with a single VUNI at the ENNI and a single OVC End Point at the VUNI,
but more complex examples are easily constructed. At an ENNI with one or more VUNI
End Points in the End Point Map, there is a VUNI L2CP Decision Point for each VUNI
End Point in addition to the ENNI L2CP Decision Point.

CEN CEN
Protocol Protocol Protocol Protocol Protocol
Entities Entities Entities Entities Entities
UNI or
UNI ENNI ENNI

UNI DP ENNI DP ENNI DP VUNI DP UNI DP or

ENNI DP

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 14
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

Figure 5 – L2CP Behavioral Model for Operator with a VUNI

An ingress L2CP ENNI Frame with an S-VID that maps to a VUNI End Point is first
evaluated by the ENNI Decision Point and subsequently evaluated by the VUNI Decision
Point. Either Decision Point can Peer or Discard the frame. If it is Passed by both Deci-
sion Points then it is propagated, subject to the same propagation constraints as Data
Frames, to all other OVC End Points associated by the OVC.

An L2CP Frame received at another External Interface and propagated to an OVC End
Point at a VUNI is first evaluated by the VUNI Decision Point and subsequently evaluat-
ed by the ENNI Decision Point. Either decision point can Peer or Discard the frame. If it
is Passed by both Decision Points then it can result in an egress L2CP ENNI Frame.

8 L2CP Service Attributes

8.1 L2CP Address Set Service Attribute

The L2CP Address Set Service Attribute specifies the subset of the Bridge Reserved Ad-
dresses that are filtered (i.e. L2CP Frames with this destination address are Peered or
Discarded but not Passed) at a L2CP Decision Point. In the description of the Bridge Re-
served Addresses in section 6.2 it is noted that different types of 802.1 Bridges filter dif-
ferent subsets of these addresses. There is an MEF analog to this where different types of
MEF services filter the different subsets of these addresses.

Ethernet Virtual Private Services associate UNIs that are aware of C-VLAN tags and
therefore filter the same subset as a Provider Edge Bridge. Ethernet Private Services as-
sociate UNIs that are blind to C-VLAN tags and therefore generally filter the same subset
as a Provider Bridge. The service types are differentiated in the Subscriber/SP agreement
by the UNI All-to-One Bundling Service Attribute, however there are two problems with
using this same attribute to control which subset of Bridge Reserved Addresses are fil-
tered. One is that the UNI All-to-One Bundling Service Attribute is not included in the
Operator/SP agreement when a service spans multiple CENs. The other is that MEF Ser-
vice Definitions include a special case of L2CP processing that can be selected for EPL
services (known as EPL Option 2 L2CP processing) where yet a different subset of the
Bridge Reserved Addresses are filtered. The L2CP Address Set Service Attribute is in-
troduced to explicitly specify the subset of addresses to be filtered.

The values for the L2CP Address Set Service Attribute are defined as follows:

 C-VLAN Tag Aware (CTA), for VLAN-based services where the CE-
VLAN ID is used to map a frame to a service.

 C-VLAN Tag Blind (CTB), for Port-based services where the CE-VLAN
ID is not used to map a frame to a service.

 C-VLAN Tag Blind Option 2 (CTB-2), for point-to-point Port-based ser-

vices that support the EPL Option 2 L2CP processing

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 15
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

[R1] The value of a L2CP Address Set Service Attribute MUST be CTA or
CTB or CTB-2.

The subsets of the Bridge Reserved Addresses filtered for each of these values is defined
in Table 5. The application of Table 5 and the L2CP Address Set Service Attribute val-
ues is determined by the flow diagrams in sections 9.1 and 9.2. Use of the CTB-2 col-
umn is somewhat different than the CTA and CTB columns in that the EPL Option 2
L2CP processing in section 9.1.1 takes precedence over the flow diagrams.

L2CP Filtered by:

Destination 802.1Q Assignment
Address CTA CTB CTB-2
01-80-C2-00-00-00 Nearest Customer Bridge X
01-80-C2-00-00-01 IEEE MAC Specific Control Protocols X X X
01-80-C2-00-00-02 IEEE 802 Slow Protocols X X
01-80-C2-00-00-03 Nearest non-TPMR Bridge X X
01-80-C2-00-00-04 IEEE MAC Specific Control Protocols X X
01-80-C2-00-00-05 Reserved for Future Standardization X X
01-80-C2-00-00-06 Reserved for Future Standardization X X
01-80-C2-00-00-07 MEF Forum ELMI X X
01-80-C2-00-00-08 Provider Bridge Group X X
01-80-C2-00-00-09 Reserved for Future Standardization X X
01-80-C2-00-00-0A Reserved for Future Standardization X X
01-80-C2-00-00-0B Reserved for Future Standardization X
01-80-C2-00-00-0C Reserved for Future Standardization X
01-80-C2-00-00-0D Provider Bridge MVRP X
01-80-C2-00-00-0E Nearest Bridge, Individual LAN Scope X X
01-80-C2-00-00-0F Reserved for Future Standardization X

Table 5 – L2CP Address Sets

There is an L2CP Address Set Service Attribute for each UNI, VUNI, and OVC. The
OVC L2CP Address Set Service Attribute supplants the need for an ENNI L2CP Address
Set Service Attribute. Were it not for the need to support EPL services with EPL Option
2 L2CP processing at an ENNI then an ENNI would always have behavior corresponding
to an L2CP Address Set value of CTB. Having an L2CP Address Set per OVC allows
an ENNI to support EPL services with EPL Option 2 L2CP processing for OVCs sup-
porting such services.

The constraints on the UNI L2CP Address Set Service Attribute in a Subscriber/SP
agreement are specified in [R2] through [R4]:

[R2] When All-to-One Bundling is Disabled at a UNI the UNI L2CP Address
Set Service Attribute MUST have a value of CTA.

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 16
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

[R3] When All-to-One Bundling is Enabled at a UNI, and the service supported
at that UNI is not an EPL service with the EPL Option 2 L2CP processing,
the UNI L2CP Address Set Service Attribute MUST have a value of CTB.

[R4] When All-to-One Bundling is Enabled at a UNI, and the service supported
at that UNI is an EPL service with the EPL Option 2 L2CP processing, the
UNI L2CP Address Set Service Attribute MUST have a value of CTB-2.

The constraints on the UNI, VUNI, and OVC L2CP Address Set Service Attributes in an
Operator/SP agreement are specified in [R5] through [R9]:

[R5] When not all CE-VLAN IDs map to a single OVC End Point at a UNI the
UNI L2CP Address Set Service Attribute MUST have a value of CTA.

[R6] When not all CE-VLAN IDs map to a single OVC End Point at a VUNI
the VUNI L2CP Address Set Service Attribute MUST have a value of
CTA.

The condition of not all CE-VLAN IDs mapping to a single OVC End Point includes the
case where there are multiple OVC End Points at the UNI or VUNI as well as the case
where some CE-VLAN IDs do not map to any OVC End Point. When all CE-VLAN IDs
map to a single OVC End Point the UNI L2CP Address Set service attribute can take any
value. The value is only constrained when the OVC supports a service with EPL Option
2 L2CP processing:

[R7] When an OVC supports an EPL service with the EPL Option 2 L2CP pro-
cessing, the OVC L2CP Address Set Service Attribute MUST have a val-
ue of CTB-2.

[R8] When an OVC supports an EPL service with EPL Option 2 L2CP pro-
cessing, the OVC MUST only support EPL services with EPL Option 2
L2CP processing.

[R9] When an OVC has an OVC End Point at a UNI, the values of the UNI
L2CP Address Set Service Attribute and the OVC L2CP Address Set Ser-
vice Attribute MUST be the same.

Note that [R8] applies only to the case of multiple EVCs bundled into a point-to-point
OVC between two ENNIs. The rationale for [R8] is that if an EPL with EPL Option 2
L2CP processing is bundled with another service on an OVC, the result of [R7] is the
possibility that some tagged provider L2CP Frames will be Passed that should be Dis-
carded on the non-Option 2 service. Such behavior is contrary to the IEEE 802.1 architec-
ture, and could cause protocols depending upon the Discard action to fail.

Note that the implication of [R9] is that when an OVC associates OVC End Points at
multiple UNIs, the value of the UNI L2CP Address Set Service Attribute will be the same
at all of those UNIs.

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 17
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

Note that for any given UNI, the value of the UNI L2CP Address Set Service Attribute in
the Subscriber/SP agreement can be different than the value of the UNI L2CP Address
Set Service Attribute in the Operator/SP agreement.

8.2 L2CP Peering Service Attribute

The L2CP Peering Service Attribute is a list of Layer 2 Control Protocols that will be
Peered by a protocol entity at a UNI, VUNI, or ENNI. Each entry in the list specifies the
Protocol Identifier and the Destination Address in use by the protocol entity. An example
is shown in Table 6. Notice that the Protocol Identifier is either an LLC Address or an
Ethertype, and that it could have subtypes. The list specifies only the L2CP Frames that
are to be Peered. Any L2CP Frame that is not Peered will either be Discarded or Passed
as a result of the flow charts and requirements specified in Section 9.

When Link Aggregation is used at an EI, its purpose is to make the multiple physical
links appear to be a single logical link to the attached devices and thus a single EI to the
CEN. Most Layer 2 Control Protocols operate over the EI as a single logical link and
hence are agnostic to the individual physical link selected to carry the protocol frames,
however some (e.g. LLDP, ESMC) can operate over the individual physical links. It is
even possible that a protocol (e.g. ESMC) could operate on some, but not all, of the phys-
ical links. In this situation the entry in the L2CP Peering service attribute can include a
link identifier. If no link identifier is specified then the list entry will apply to all links.
Requirements on the format of the Link Identifier are beyond the scope of this document.

[R10] The L2CP Peering service attribute value MUST be an empty list, or a list
of entries identifying protocols to be Peered where each entry consists of
{Destination Address, Protocol Identifier} or {Destination Address, Pro-
tocol Identifier, Link Identifier}.

There is an L2CP Peering Service Attribute for each UNI, VUNI, and ENNI.

Protocol to be Peered Protocol Identifier L2CP

Destination
Address

Link Aggregation (LACP) Ethertype: 0x8809 01-80-C2-00-00-02

Subtypes: 01,02
Link OAM Ethertype: 0x8809 01-80-C2-00-00-02
Subtype: 03
E-LMI Ethertype: 0x88EE 01-80-C2-00-00-07
Spanning Tree (RSTP/MSTP) LLC Address: 0x82 01-80-C2-00-00-00

Table 6 – Example L2CP Peering Service Attribute

Table 7 contains a list of some Layer 2 Control Protocols and a reference to the standard that
specifies the protocol. The Protocol Identifiers and L2CP Destination Addresses in the table are

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 18
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

specified by the cited references. This document does not preclude the use of addresses other
than those listed in this table. The protocols may generate VLAN-tagged, priority-tagged, or un-
tagged frames as specified in the cited references.

L2CP
Layer 2 Control Protocol Protocol Identifier Destination Ref
Addresses

Link Aggregation Control/Marker Protocol (LACP) Ethertype: 0x8809 01-80-C2-00-00-00 [2][3]

Subtypes: 0x01, 0x02 01-80-C2-00-00-02
01-80-C2-00-00-03
802.3 Operations, Administration, and Maintenance Ethertype: 0x8809 01-80-C2-00-00-02 [12]
(Link-OAM) Subtype: 0x03
Ethernet Synchronization Messaging Channel Ethertype: 0x8809 01-80-C2-00-00-02 [14]
(ESMC) Subtype: 0x0A
Precision Time Protocol Peer-Delay (PTP) Ethertype: 0x88F7 01-80-C2-00-00-0E [13]
Ethernet Local Management Interface (E-LMI) Ethertype: 0x88EE 01-80-C2-00-00-07 [20]
Link Layer Discovery Protocol (LLDP) Ethertype: 0x88CC 01-80-C2-00-00-00 [1]
01-80-C2-00-00-03
01-80-C2-00-00-0E
Virtual Station Interface Discovery and Configura- Ethertype: 0x8940 01-80-C2-00-00-00 [9]
tion Protocol (VDP) Subtype: 0x0001
Port Extender Control and Status Protocol (PE-CSP) Ethertype: 0x8940 01-80-C2-00-00-03 [10]
Subtype: 0x0002
Port-Based Network Access Control Ethertype: 0x888E 01-80-C2-00-00-00 [11]
01-80-C2-00-00-03
01-80-C2-00-00-0E
802.3 MAC Control: PAUSE Etherype: 0x8808 01-80-C2-00-00-01 [12]
Subtype: 0x0001
802.3 MAC Control: Priority Flow Control (PFC) Etherype: 0x8808 01-80-C2-00-00-01 [7]
Subtype: 0x0101
802.3 MAC Control: Multipoint MAC Control Etherype: 0x8808 01-80-C2-00-00-01 [12]
Subtype: 0x0002-0x0006
802.3 MAC Control: Organization Specific Exten- Etherype: 0x8808 01-80-C2-00-00-01 [12]
sions Subtype: 0xFFFE
Rapid/Multiple Spanning Tree Protocol LLC Address: 0x42 01-80-C2-00-00-00 [4][5]
(RSTP/MSTP) 01-80-C2-00-00-08
Shortest Path Bridging (SPB) LLC Address: 0xFE 01-80-C2-00-00-2E [8]
01-80-C2-00-00-2F
Multiple MAC Registration Protocol (MMRP) Ethertype: 0x88F6 01-80-C2-00-00-20 [4][5]
Multiple VLAN Registration Protocol (MVRP) Ethertype: 0x88F5 01-80-C2-00-00-21 [5]
01-80-C2-00-00-0D
Multiple Stream Registration Protocol (MSRP) Ethertype: 0x22EA 01-80-C2-00-00-0E [5]
Multiple ISID Registration Protocol (MIRP) Ethertype: 0x8929 01-80-C2-00-00-00 [6]

Table 7 – Selected Layer 2 Control Protocols

All recommendations and requirements for EPL services with EPL Option 2 L2CP pro-
cessing are to either Discard or Pass L2CP Frames at all UNIs (section 9.1.1). Therefore
the following constraint is placed on the L2CP Peering service attribute:

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 19
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

[D1] When the UNI L2CP Address Set service attribute is CTB-2, the UNI
L2CP Peering Service Attribute SHOULD be an empty list.

For Ethernet Private Services other than EPL with EPL Option 2 L2CP processing, any
L2CP Frame with a Bridge Reserved Address in Table 5 but not in the CTB subset of
Table 5 is to be Passed at all Decision Points. Therefore the following constraints are
placed on the L2CP Peering service attribute:

[R11] When the UNI or VUNI L2CP Address Set service attribute is CTB, any
entry in the UNI or VUNI L2CP Peering Service Attribute MUST NOT
have a Destination Address that is in Table 5 but not in the CTB subset of
Table 5.

[R12] Any entry in the ENNI L2CP Peering service attribute MUST NOT have
a Destination Address that is in Table 5 but not in the CTB subset of Table
5.

8.2.1 Requirements for peering specific Layer 2 Control Protocols

MEF 10.3 requires Peering LACP when the UNI Resiliency service attribute has a value
of “2-Link Aggregation”.

[R13] When the value of the UNI Resiliency service attribute is “2-Link Aggre-
gation”, the UNI L2CP Peering service attribute at that UNI MUST list
LACP with a “Slow Protocols” destination address (01-80-C2-00-00-02),
and a Protocol Identifier consisting of the “Slow Protocols” Ethertype
value (0x8809) and the LACP and LAMP sub-types (01, 02).

MEF 26.1 requires Peering LACP when there are two physical links at the ENNI using
Link Aggregation as the protection mechanism.

[R14] When Link Aggregation is used as the protection mechanism for two
physical links at an ENNI, the ENNI L2CP Peering service attribute
MUST list LACP with a “Slow Protocols” destination address (01-80-C2-
00-00-02), and a Protocol Identifier consisting of the “Slow Protocols”
Ethertype value (0x8809) and the LACP and LAMP sub-types (01, 02).

MEF 10.3 requires Peering Link-OAM when the UNI Link-OAM service attribute is En-
abled.

[R15] When the UNI Link-OAM service attribute is Enabled, the UNI L2CP
Peering service attribute at that UNI MUST list Link-OAM with a “Slow
Protocols” destination address (01-80-C2-00-00-02), and a Protocol Iden-
tifier consisting of the “Slow Protocols” Ethertype value (0x8809) and the
Link-OAM sub-type (03).

MEF 10.3 requires Peering E-LMI when the UNI E-LMI service attribute is Enabled.

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 20
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

[R16] When the UNI E-LMI service attribute is Enabled, the UNI L2CP Peering
service attribute at that UNI MUST list E-LMI with a E-LMI destination
address (01-80-C2-00-00-07), and a Protocol Identifier consisting of the
E-LMI Ethertype value (0x88EE).

MEF 10.3 requires Peering ESMC when the UNI Synchronous Mode service attribute is
Enabled. The Synchronous Mode service attribute is a list of links at the UNI with an
Enabled or Disabled value for each link.

[R17] When the UNI Synchronous Mode service attribute is Enabled for a link
at a UNI, the UNI L2CP Peering service attribute at that UNI MUST list
ESMC with a “Slow Protocols” destination address (01-80-C2-00-00-02),
a Protocol Identifier consisting of the “Slow Protocols” Ethertype value
(0x8809) and the ESMC sub-type (0A).

[R18] When there are more than one link at the UNI and the UNI Synchronous
Mode service attribute is Enabled for some but not all links, the UNI
L2CP Peering service attribute at that UNI MUST have an ESMC entry
for each link that is Enabled and includes the Link Identifier.

8.3 ENNI Tagged L2CP Frame Processing Service Attribute

The ENNI Tagged L2CP Frame Processing Service Attribute reflects the capability of the
ENNI to process S-VLAN-tagged L2CP Frames in an 802.1 compliant manner. Alt-
hough almost all Layer 2 Control Protocols generate untagged L2CP Frames, some gen-
erate tagged L2CP Frames (e.g. MMRP). L2CP Frames will also be tagged at an ENNI
when they result from L2CP Service Frames that ingress at a UNI and are subsequently
Passed by L2CP Decision Points. The special forwarding rules for the Bridge and MRP
Reserved Addresses specified in 802.1Q and discussed in section 5 apply to both tagged
and untagged L2CP Frames, however the EPL with EPL Option 2 L2CP processing re-
quirements conflict with these rules. It can be difficult for some ENNI implementations
to apply the special forwarding rules for some OVCs but not for others. Therefore this
specification recommends applying the special forwarding rules to tagged frames on
OVCs supporting a service other than EPL with EPL Option 2 L2CP processing, but al-
lows implementations to simply Pass any tagged L2CP.

The allowed values for the ENNI Tagged L2CP Frame Processing Service Attribute are
“802.1 compliant” or “802.1 non-compliant”. A value of 802.1 compliant means the
ENNI will apply the special forwarding rules to tagged L2CP Frames that map to a VUNI
End Point or an OVC End Point supporting a service other than EPL with EPL Option 2
L2CP processing. A value of 802.1 non-compliant means the ENNI will Pass any tagged
L2CP Frames. There is a ENNI Tagged L2CP Frame Processing Service Attribute for
each ENNI.

[D2] An ENNI Tagged L2CP Frame Processing Service Attribute

SHOULD be 802.1 compliant.

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 21
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

When the value of the ENNI Tagged L2CP Processing Service Attribute is "802.1 non-
compliant," it is possible that some tagged provider L2CP Frames will be Passed that are
mandated to be Discarded by the IEEE 802.1 architecture. This could cause protocols
that depend upon the Discard action to fail.

9 L2CP Processing Requirements

9.1 UNI and VUNI L2CP Frame Processing Requirements

The flow chart in Figure 6 specifies the action taken on a L2CP Frame at a UNI or VUNI
L2CP Decision Point when the L2CP Address Set service attribute has a value of CTA or
CTB. When the L2CP Address Set service attribute has a value of CTB-2 the actions
taken at a UNI L2CP Decision Point are specified in 8.1.2.

The flow chart is used to determine both ingress actions in response to an Ingress L2CP
Service Frame, and egress actions in response to a potential egress L2CP Frame propa-
gated to this UNI from a Decision Point at another EI. L2CP Frames generated by a Pro-
tocol Entity at the UNI are not processed according to the flow chart.

At a UNI L2CP Decision Point the inputs to the flow chart are the UNI L2CP Address
Set and UNI L2CP Peering service attributes and the Destination Address and Protocol
Identifier in the L2CP Frame.

[R19] When the UNI L2CP Address Set is CTA or CTB, the flow chart in Figure
6 MUST be used to determine whether the action for a L2CP Frame at a
UNI Decision Point will be Peer, Pass, or Discard.

At a VUNI L2CP Decision Point the inputs to the flow chart are the VUNI L2CP Address
Set and VUNI L2CP Peering service attributes and the Destination Address and Protocol
Identifier in the L2CP Frame. At a VUNI L2CP Decision Point the S-tag in the L2CP
ENNI Frame is ignored, and if the action taken is Peer then the contents of the frame
without the S-tag are acted upon by the appropriate protocol entity.

[R20] When the VUNI L2CP Address Set is CTA or CTB, the flow chart in Fig-
ure 6 MUST be used to determine whether the action for a L2CP Frame at
a VUNI Decision Point will be Peer, Pass, or Discard.

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 22
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

L2CP Frame Received

A:
Do the Protocol Identifier and
Yes Peer
Destination Address match
an entry in the L2CP
Peering Attribute?

No

B:
Is the Destination Address Yes
in the Address Set specified by
the L2CP Address Set
Attribute?

No Discard

C:
Is the Destination Address
Yes
in the MRP Address Block and
matches the DA in any entry in the
L2CP Peering Attribute?

No

Pass

Figure 6 – Flow Chart for UNI and VUNI Decision Points

The first decision block in the flow chart (A) determines whether the L2CP Frame will be
Peered by comparing the Destination Address and Protocol Identifier in the L2CP Frame
with the list entries configured in the UNI (or VUNI) L2CP Peering service attribute.

If the L2CP Frame is not Peered, the second decision block (B) determines whether it
will be Discarded by comparing the Destination Address of the L2CP Frame with the
specific set of Reserved Addresses checked in the column of Table 5 that corresponds to
the configured value of the L2CP Address Set service attribute.

As described in section 6.3, the special forwarding rule for MRP Reserved Addresses is
that if any protocol using an MRP address is Peered, then no frames with that address
will be Passed. The first decision block (A) assures that frames with an MRP Address
and PID that are listed in the L2CP Peering service attribute will be Peered (and therefore
not Passed). The third decision block (C) assures that frames with that MRP Address but
a different PID will be Discarded (and therefore not Passed).

If the L2CP Frame is not Peered or Discarded then it will be Passed.

Recall from section 7.1.3 that a L2CP Frame that is Passed is still subject to the same
propagation constraints as a Data Frame, and in particular any L2CP Frame with an C-
VID value that does not map to any EVC or OVC End Point will not be propagated to
Decision Points at other External Interfaces.
MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 23
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

9.1.1 UNI L2CP Frame Processing for EPL Option 2 L2CP Processing

When the end-to-end service supported at a UNI is EPL with EPL Option 2 L2CP pro-
cessing, the L2CP Address Set service attribute value will be CTB-2. In this case Table 8
and Table 9 specify the action taken on a L2CP Frame at a UNI L2CP Decision Point.
Note that the EPL Option 2 L2CP processing has L2CP processing requirements that are
NOT in line with the current IEEE standards: 1588-2008 [13], 802.1Q-2011 [5],
802.1AB-2009 [1], and 802.1X-2010 [11].

The first column of Table 8 and Table 9 identifies the protocol requiring special action
for EPL Option 2 L2CP processing. The second column is the Protocl Identifier. The
third column is the Destination Address. The Fourth column specifies the required UNI
L2CP Decision Point action9 for a frame with matching Protocol Identifier and Destina-
tion Address.

[R21] If the value of the UNI L2CP Address Set service attribute is CTB-2, and
a L2CP Frame at a UNI L2CP Decision Point has a Destination Address
and Protocol Identifier matching an entry in Table 8, then the frame
MUST be processed as specified in Table 8.

Protocol Type Protocol Identifier L2CP L2CP Action

Destination
Address

STP[3]/RSTP[3]/MSTP[4] LLC Address: 0x42 01-80-C2-00-00-00 MUST Pass

E-LMI[9] Ethertype: 0x88EE 01-80-C2-00-00-07 MUST Pass10

LLDP[8] Ethertype: 0x88CC 01-80-C2-00-00-0E MUST Pass

PTP Peer Delay[13]5 Ethertype: 0x88F7 01-80-C2-00-00-0E MUST Pass

GARP[4]/MRP[17] Block any 01-80-C2-00-00-20 MUST Pass

through
01-80-C2-00-00-2F

Table 8 – EPL Option 2 L2CP Processing Requirements

[D3] If the value of the UNI L2CP Address Set service attribute is CTB-2,
then a L2CP Frame at a UNI L2CP Decision Point has a Destination

9
Table 8 and Table 9is the same as Table K of MEF 6.1.1 except that “Tunnel” has been replaced with “Pass” to
make the table consistent with actions taken by a L2CP Decision Point. Recall that when all Decision Points en-
countered by a L2CP Frame propagating through a network Pass the frame, the end-to-end result is the same as
“Tunnel” as defined in MEF 6.1.1.
10
When using EPL Option 2, it is recommended for the Subscriber to turn off E-LMI in the equipment that is at-
tached to the UNI. Trying to run E-LMI with EPL Option 2 in this equipment may lead to unpredictable results.
MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 24
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

Address and Protocol Identifier matching an entry in Table 9, then the

frame SHOULD be processed as specified in Table 9.

Protocol Type Protocol Identifier L2CP L2CP Action

Destination
Address

PAUSE[5] Etherype: 0x8808 01-80-C2-00-00-01 SHOULD Discard

Subtype: 0x0001
LACP/LAMP[5] Ethertype: 0x8809 01-80-C2-00-00-02 SHOULD Pass
Subtypes: 0x01, 0x02
Link OAM[5] Ethertype: 0x8809 01-80-C2-00-00-02 SHOULD Pass
Subtype: 0x03
Port Authentication[7] Ethertype: 0x888E 01-80-C2-00-00-03 SHOULD Pass
ESMC[14]8 Ethertype: 0x8809 01-80-C2-00-00-02 SHOULD Pass11
Subtype: 0x0A

Table 9 – EPL Option 2 L2CP Processing Recommendations

Table 8 and Table 9 only specify actions for selected combinations of Protocol Identifier
and Destination Address. It is recommended that the flow chart in Figure 6 be used to
determine the UNI Decision Point action for L2CP Frames with other combinations of
Protocol Identifier and Destination Address.

[D4] If the value of the UNI L2CP Address Set service attribute is CTB-2,
and an L2CP Frame at a UNI Decision Point has a combination of
Protocol Identifier and Destination Address not listed in Table 8 or
Table 9, the flow chart in Figure 6 SHOULD be used to determine
whether the action for a L2CP Frame at a UNI Decision Point will be
Peer, Pass, or Discard.

9.1.2 Example L2CP Frame evaluation at a UNI L2CP Decision Point

For example, consider an ingress L2CP Service Frame that is a Link Layer Discovery
Protocol (LLDP) frame with the Nearest Customer Bridge destination address (01-80-C2-
00-00-00) being evaluated by the L2CP Decision Point at a UNI.

If the UNI L2CP Address Set is CTB-2 then the LLDP frame will be processed according
to Table 8, however Table 8 does not have an entry for LLDP frames with this destina-
tion address. Therefore [D4] recommends the frame be processed according to the flow
chart in Figure 6. If the UNI L2CP Address set is CTA or CTB then the LLDP frame
will always be processed according the flow chart in Figure 6.

11
When using EPL Option 2, it is recommended for the Subscriber to turn off ESMC in the equipment that is at-
tached to the UNI. Trying to run ESMC with EPL Option 2 in this equipment may lead to unpredictable results.
Tunneled ESMC frames may not accurately represent the state of the timing attributes of the physical interface the
Subscriber interface is attached to.
MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 25
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

If this protocol with this destination address is listed in the UNI L2CP Peering service
attribute then the frame will be Peered as a result of decision block A. Note that [R11]
forbids this PID and DA combination from being listed when the L2CP Address Set is
CTB.

If the LLDP Frame was not Peered as a result of decision block A, then the evaluation
process continues with decision block B. If the UNI L2CP Address Set service attribute
value is CTA then, since the destination address is in the CTA subset of Table 5, the
LLDP Frame will be Discarded. If the UNI L2CP Address Set service attribute value is
CTB or CTB-2 then, since the destination address is not in the CTB or CTB-2 subset of
Table 5, the evaluation will continue with decision block C.

The LLDP frame will not be Discarded at decision block C since the destination address
is not an MRP address. Therefore if it is not Peered as a result of decision block A, or
Discarded as a result of decision block B, then the LLDP frame will be Passed.

9.2 ENNI L2CP Processing Requirements

The action taken on a L2CP Frame by an ENNI L2CP Decision Point is described by the
flow chart in Figure 7. The flow chart uses the configuration of the L2CP Peering, L2CP
Address Set and ENNI Tagged L2CP Frame Processing service attributes, and the Desti-
nation Address, Protocol Identifier and S-VID in the L2CP Frame, to determine whether
the action taken will be to Peer, Discard or Pass the L2CP Frame.

The flow chart is used to determine both ingress actions in response to an Ingress L2CP
ENNI Frame, and egress actions in response to a potential egress L2CP Frame propagat-
ed to this ENNI from another Decision Point. L2CP Frames generated by a Protocol En-
tity for the ENNI Decision Point are not processed according to the flow chart. For
egress actions, the potential egress frame is assumed to be S-VLAN tagged with an S-
VID value determined by the ENNI End Point Map.

[R22] The flow chart in Figure 7 MUST be used to determine whether the action
for a L2CP Frame at a ENNI Decision Point will be Peer, Pass, or Dis-
card.

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 26
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

L2CP Frame Received

C:
No A: Yes Does the S-VID map to an OVC Yes
Is the L2CP Frame End Point associated by an OVC
S-tagged with a with the OVC L2CP Address Set
non-zero S-VID? value of CTB-2?

No

D:
Is the ENNI Tagged L2CP
No
Frame Processing attribute value
802.1 compliant?

Yes

B: E:
Do the Protocol Identifier and Yes Yes Do the Protocol Identifier and
Destination Address match Peer Destination Address match
an entry in the ENNI L2CP an entry in the ENNI
Pass
Peering attribute? L2CP Peering attribute?
No No

Yes F:
Is the Destination Address
in the CTB Address Set?

No

G:
Discard Yes Is the Destination Address in
No
the MRP Address Block and matches
the DA in any entry in the ENNI
L2CP Peering attributes?

Figure 7 – Flow Chart for ENNI Decision Point

The first decision block in the flow chart (A) separates S-VLAN specific L2CP ENNI
Frames (S-tagged with S-VID not equal to zero), from L2CP Frames that are not specific
to a S-VLAN (without an S-tag, or with a priority-S-tag). The second decision block (B)
determines whether a Port-based L2CP Frame will be Peered by comparing the Destina-
tion Address and Protocol Identifier in the frame with the list entries configured in the
ENNI L2CP Peering service attribute. Since Port-based L2CP ENNI Frames cannot be
mapped to any OVC End Point or VUNI End Point they cannot be Passed. Therefore if
they are not Peered they are Discarded.

The third decision block (C) determines whether the L2CP Frame is associated with a S-
VID value that maps to an OVC End Point associated by an OVC supporting an EPL ser-
vice with EPL Option 2 L2CP processing. If so then the frame is Passed. Otherwise, in-
cluding the case where the L2CP Frame is associated with a S-VID that maps to a VUNI
End Point, processing continues with decision block (D).

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 27
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

The fourth decision block (D) determines whether the L2CP processing implementation
at the ENNI supports 802.1 compliant processing of tagged L2CP Frames (see section
[R18]). If not then the frame is Passed.

The fifth decision block (E) determines whether a L2CP Frame associated with a non-
zero S-VID will be Peered by comparing the Destination Address and Protocol Identifier
in the L2CP Frame with the list entries configured in the ENNI L2CP Peering service at-
tribute.

If the L2CP Frame is not Peered, the sixth decision block (F) determines whether it will
be Discarded by comparing the Destination Address of the L2CP Frame with the specific
set of Reserved Addresses checked in the CTB column of Table 5.

As described in section 6.3, the special forwarding rule for MRP Reserved Addresses is
that if any protocol using an MRP address is Peered, then no frames with that address
will be Passed. The fifth decision block (E) assures that frames with an MRP Address
and PID that are listed in the L2CP Peering service attribute will be Peered (and therefore
not Passed). The seventh decision block (G) assures that frames with that MRP Address
but a different PID will be Discarded (and therefore not Passed).

Otherwise the frame is Passed.

Recall from section 7.1.3 that a L2CP Frame that is Passed is still subject to the same
propagation constraints as a Data Frame, and in particular any L2CP Frame with an S-
VID value that does not map to any OVC End Point or VUNI End Point will not be prop-
agated to Decision Points at other External Interfaces.

9.2.1 Example L2CP Frame evaluation at a ENNI L2CP Decision Point

For a first example, consider the LLDP frame from the example in 7.1.1. Specifically
consider the case where the LLDP frame was Passed by the ingress UNI L2CP Decision
Point and propagated to an OVC End Point at an ENNI where it will be evaluated by an
egress ENNI L2CP Decision Point. Since all potential egress L2CP Frames at an ENNI
are associated with an OVC End Point that maps to a non-zero S-VID, the result of deci-
sion block A will be to proceed to decision block C.

If the OVC Address Set service attribute is CTB-2 then decision block C will cause the
frame to be Passed. Otherwise, if the ENNI implementation does not support processing
of tagged L2CP frames, then decision blocks D will cause the frame to be Passed. Oth-
erwise the processing continues with decision block E.

The address of the LLDP frame from the example in section 9.1.2 is the Nearest Custom-
er Bridge address. Since this address is not in the CTB subset of Table 5, there cannot be
an entry in the ENNI L2CP Peering service attribute that matches this frame (per [R11]).
Therefore the frame will not be Peered. Since the address is not in the CTB subset of Ta-
ble 5, nor is it an MRP address, the frame will not be discarded as a result of decision
blocks F or G. The final decision will be to Pass the frame.

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 28
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

Since the LLDP frame is Passed at the egress ENNI Decision Point, it will be transmitted
on the ENNI and evaluated at the ingress ENNI Decision Point in the other operator net-
work. The result of the ingress ENNI Decision Point evaluation will be the same as the
egress ENNI Decision Point evaluation, i.e. the frame will be Passed.

For a second example, consider an LLDP frame that is untagged at the ENNI. At an in-
gress ENNI Decision Point, decision block B will result in this frame being Peered if
there is a matching entry for the LLDP protocol in the ENNI L2CP Peering attribute, and
Discarded otherwise.

10 Service Requirements for L2CP

10.1 EVPL, EVP-LAN, and EVP-Tree Service Requirements

The Service Attribute and Parameter requirements pertaining to L2CP for EVPL, EVP-
LAN and EVP-Tree service types are shown in Table 10.

UNI Service
EVPL, EVP-LAN, EVP-Tree Service type Requirement
Attributes
L2CP Address Set [R23] MUST be CTA
L2CP Peering No additional constraints from section 8.2
Table 10 – UNI L2CP Service Attributes for Ethernet Virtual Private Services

10.2 EPL, EP-LAN, and EP-Tree Service Requirements

The Service Attribute and Parameter requirements pertaining to L2CP for EPL, EP-LAN
and EP-Tree service types are shown in Table 11.

UNI Service
EPL, EP-LAN, EP-Tree Service type Requirement
Attributes

[R24] EPL Option 1, EP-LAN, and EP-Tree: MUST

L2CP Address Set be CTB

[R25] EPL Option 2: MUST be CTB-2

EPL Option 1, EP-LAN, and EP-Tree: No additional con-

straints from section 7.2
L2CP Peering
[D5] EPL Option 2: The UNI L2CP Peering at-
tribute SHOULD NOT have any protocols
listed to be Peered.
Table 11 – UNI L2CP Service Attributes for Ethernet Private Services
MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 29
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

10.3 Access EVPL, Access EPL and UTA Service Requirements

10.3.1 Access EVPL Service Requirements

The Service Attribute and Parameter requirements pertaining to L2CP for Access EVPL
services are shown in Table 12, Table 13, and Table 14.

UNI Service
Access EVPL Service type Requirement
Attributes

[R26] MUST be CTA

L2CP Address Set
This is a consequence of [R5].
L2CP Peering No additional constraints from section 8.2
Table 12 – UNI L2CP Service Attribute for Access EVPL

OVC Service
Access EVPL Service type Requirement
Attributes

[R27] MUST be CTA

L2CP Address Set
This is a consequence of [R5] and [R9].
Table 13 – OVC L2CP Service Attributes for Access EVPL

ENNI Service
Access EVPL Service type Requirement
Attributes
L2CP Peering No additional constraints from section 8.2
ENNI Tagged L2CP
Frame Processing No additional constraints from section [R18]
Table 14 – ENNI L2CP Service Attributes for Access EVPL

10.3.2 Access EPL Service Requirements

The Service Attribute and Parameter requirements pertaining to L2CP for Access EPL
services are shown in Table 15, Table 16, and Table 17.

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 30
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

UNI Service
Access EPL Service type Requirement
Attributes

[R28] MUST be CTB or CTB-2

L2CP Address Set
Note that [R9] requires this to be the same value as the OVC
L2CP Address Set Attribute in Table 16.
L2CP Peering
No additional constraints from section 8.2
Table 15 – UNI L2CP Service Attributes for Access EPL

OVC Service
Access EPL Service type Requirement
Attributes

[R29] MUST be CTB or CTB-2.

[R30] MUST be CTB-2 when the UNI-to-UNI service

L2CP Address Set is EPL option 2.

Note that [R9] requires this to be the same value as the UNI
L2CP Address Set Attribute in Table 15.
Table 16 – OVC L2CP Service Attributes for Access EPL

ENNI Service
Access EPL Service type Requirement
Attributes
L2CP Peering No additional constraints from section 8.2
ENNI Tagged L2CP
Frame Processing No additional constraints from section [R18]
Table 17 – ENNI L2CP Service Attributes for Access EPL

Note that [R29] and [R30] allow the UNI and OVC L2CP Address Set for an Access
EPL service to be CTB-2 even when the end-to-end service is not EPL with EPL Option
2 L2CP processing, however this can compromise proper operation of many protocols,
including LACP, LLDP, Link-OAM, E-LMI, PTP Peer Delay and ESMC.

10.3.3 UNI Tunnel Access (UTA) Service Requirements

The Service Attribute and Parameter requirements pertaining to L2CP for UTA services
are shown in Table 18, Table 19, and Table 20.

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 31
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

UNI Service
UTA Service type Requirement
Attributes
L2CP Address Set [R31] MUST be CTB
L2CP Peering No additional constraints from section 8.2
Table 18 – UNI L2CP Service Attributes for UTA

OVC Service
UTA Service type Requirement
Attributes
L2CP Address Set [R32] MUST be CTB
Table 19 – OVC L2CP Service Attributes for UTA

ENNI Service
UTA Service type Requirement
Attributes
L2CP Peering No additional constraints from section 8.2
ENNI Tagged L2CP
Frame Processing No additional constraints from section [R18]
Table 20 – ENNI L2CP Service Attributes for UTA

10.4 VUNI L2CP Service Requirements

The Service Attribute and Parameter requirements pertaining to services including a
VUNI are shown in Table 21 and Table 22.

VUNI Service
VUNI Service type Requirement
Attributes

[R33] MUST be CTB when the VUNI supports an

EPL, EP-LAN, or EP-TREE.

L2CP Address Set [R34] MUST be CTA when the VUNI is supporting
EVPL, EVP-LAN, or EVP-TREE service(s).

Note that [R9] requires this to be the same value as the OVC
L2CP Address Set Attribute in Table 19.
L2CP Peering No additional constraints from section 8.2
Table 21 – VUNI L2CP Service Attributes for VUNI Service

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 32
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

OVC Service
VUNI Service type Requirement
Attributes

[R35] MUST be CTB when the VUNI supports an

EPL, EP-LAN, or EP-TREE.
L2CP Address Set
[R36] MUST be CTA when the VUNI is supporting
EVPL, EVP-LAN, or EVP-TREE service(s).
Table 22 – OVC L2CP Service Attributes for VUNI Service

10.5 vNID Service Requirements

10.5.1 vNID Case A Service Requirements

The Service Attribute and Parameter requirements pertaining to L2CP for vNID Case A
services are shown in Table 23, Table 24, and Table 25.

UNI Service
vNID Case A Service type Requirement
Attributes

[R37] MUST be CTA when not all CE-VLAN IDs

map to the same OVC End Point

This is a consequence of [R5].

L2CP Address Set
[R38] MUST be CTB or CTB-2 when all CE-VLAN
IDs map to the same OVC End Point

Note that [R9] requires this to be the same value as the OVC
L2CP Address Set Attribute in Table 24.
L2CP Peering No additional constraints from section 8.2
Table 23 – UNI L2CP Service Attribute for vNID Case A

OVC Service
vNID Case A Service type Requirement
Attributes

[R39] MUST be CTB-2 when the UNI-to-UNI service

is EPL option 2.
L2CP Address Set
Note that [R9] requires this to be the same value as the UNI
L2CP Address Set Attribute in Table 23.
Table 24 – OVC L2CP Service Attributes for vNID Case A

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 33
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

ENNI Service
vNID Case A Service type Requirement
Attributes
L2CP Peering No additional constraints from section 8.2
ENNI Tagged L2CP
Frame Processing No additional constraints from section [R18]
Table 25 – ENNI L2CP Service Attributes for vNID Case A

10.5.2 vNID Case B Service Requirements

The Service Attribute and Parameter requirements pertaining to L2CP for vNID Case B
services are shown in Table 26, Table 27, and Table 28.
UNI Service
vNID Case B Service type Requirement
Attributes

[R40] MUST be CTB or CTB-2

L2CP Address Set
Note that [R9] requires this to be the same value as the OVC
L2CP Address Set Attribute in Table 13.
L2CP Peering No additional constraints from section 8.2
Table 26 – UNI L2CP Service Attributes for vNID Case B

OVC Service
vNID Case B Service type Requirement
Attributes

[R41] MUST be CTB or CTB-2.

[R42] MUST be CTB-2 when the UNI-to-UNI service

L2CP Address Set is EPL option 2.

Note that [R9] requires this to be the same value as the UNI
L2CP Address Set Attribute in Table 26.
Table 27 – OVC L2CP Service Attributes for vNID Case B

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 34
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

ENNI Service
vNID Case B Service type Requirement
Attributes
L2CP Peering No additional constraints from section 8.2
ENNI Tagged L2CP
Frame Processing No additional constraints from section [R18]
Table 28 – ENNI L2CP Service Attributes for vNID Case B

Note that [R41] and [R42] allow the UNI and OVC L2CP Address Set for an Access
EPL service to be CTB-2 even when the end-to-end service is not EPL with EPL Option
2 L2CP processing, however this can compromise proper operation of many protocols,
including LACP, LLDP, Link-OAM, E-LMI, PTP Peer Delay and ESMC.

11 References
[1] IEEE Std 802.1AB – 2009, IEEE Standard for Local and metropolitan area net-
works – Station and Media Access Control Connectivity Discovery, 17 September
2009.

[2] IEEE Std 802.1AX – 2008, IEEE Standard for Local and metropolitan area net-
works – Link Aggregation, 3 November 2008.

[3] IEEE Std 802.1AXbk – 2012, IEEE Standard for Local and metropolitan area
networks – Link Aggregation Amendment 1: Protocol Addressing, 25 May 2012.

[4] IEEE Std 802.1D – 2004, IEEE Standards for Local and metropolitan area net-
works—Media Access Control (MAC) Bridges, 9 June 2004.

[5] IEEE Std 802.1Q – 2011, IEEE Standards for Local and metropolitan area net-
works—Media Access Control (MAC) Bridges and Virtual Bridge Local Area
Networks, 7 May 2003.

[6] IEEE Std 802.1Qbe – 2011, IEEE Standards for Local and metropolitan area net-
works—Media Access Control (MAC) Bridges and Virtual Bridge Local Area
Networks Amendment 15: Multiple I-SID Registration Protocol, 16 September
2011.

[7] IEEE Std 802.1Qbb – 2011, IEEE Standards for Local and metropolitan area net-
works—Media Access Control (MAC) Bridges and Virtual Bridge Local Area
Networks Amendment 17: Priority-based Flow Control, 30 September 2011.

[8] IEEE Std 802.1aq – 2012, IEEE Standards for Local and metropolitan area net-
works—Media Access Control (MAC) Bridges and Virtual Bridge Local Area
Networks Amendment 20: Shortest Path Bridging, 29 June 2012.

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 35
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

[9] IEEE Std 802.1Qbg – 2012, IEEE Standards for Local and metropolitan area net-
works—Media Access Control (MAC) Bridges and Virtual Bridge Local Area
Networks Amendment 21: Edge Virtual Bridging, 5 July 2012.

[10] IEEE Std 802.1BR-2012, IEEE Standards for Local and metropolitan area
networks – Virtual Bridged Local Area Networks – Bridge Port Extension, 16 Ju-
ly 2012.

[11] IEEE Std 802.1X – 2010, IEEE Standards for Local and metropolitan area
networks—Port Based Network Access Control, 6 February 2010.

[12] IEEE Std 802.3 – 2012, IEEE Standard for Ethernet, 28 December 2012.
(Normative)

[13] IEEE Std 1588TM-2008. IEEE Standard for a Precision Clock Synchroni-
zation Protocol for Networked Measurement and Control Systems - 27 March
2008, Annex F

[14] International Telecommunication Union, Recommendation G.8264-2008.

Distribution of Timing Through Packet Networks - October 10, 2008.

[15] Internet Engineering Task Force RFC 2119. Key words for use in RFCs to
Indicate Requirement Levels, March 1997.

[16] MEF Forum MEF 4, Metro Ethernet Network Architecture Framework:

Part 1 – Generic Framework, May 2004.

[17] MEF Forum MEF 6.1, Ethernet Services Definitions - Phase 2, April
2008.

[18] MEF Forum, MEF 6.1.1, Layer 2 Control Protocol Handling Amendment
to MEF 6.1, January 2012.

[19] MEF Forum MEF 10.3, Ethernet Services Attributes Phase 3, October
2013.

[20] MEF Forum MEF 16, Ethernet Local Management Interface (E-LMI),
January 2006.

[21] MEF Forum MEF 20, User Network Interface (UNI) Type 2 Implementa-
tion Agreement, July 2008.

[22] MEF Forum MEF 22.1, Mobile Backhaul Phase 2, January 2012.

[23] MEF Forum MEF 23.1, Carrier Ethernet Class of Service Phase 2, Janu-
ary 2012.

[24] MEF Forum MEF 26.1, External Network Network Interface (ENNI) –
Phase 2, January 2012.
MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 36
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

[25] MEF Forum MEF 28, External Network Network Interface (ENNI) Sup-
port for UNI Tunnel Access and Virtual UNI, October 2010.

[26] MEF Forum MEF 30, Service OAM Fault Management Implementation
Agreement, January 2011.

[27] MEF Forum MEF 33, Ethernet Access Services Definition, January 2012.

[28] MEF Forum MEF 35, Service OAM Performance Monitoring Implemen-
tation Agreement, April 2012.

Appendix A Summary of L2CP Service Attributes

The L2CP Service Attributes and Parameter Values are shown in Table 29, Table 30, Ta-
ble 31 and Table 32.

UNI Service
Parameter Values
Attributes
L2CP Address Set CTA or CTB or CTB-2

Empty list, or list of protocols to be Peered where each entry

L2CP Peering consists of {Destination Address, Protocol Identifier}or {Desti-
nation Address, Protocol Identifier, Link Identifier}
Table 29 – UNI L2CP Service Attributes

OVC Service
Parameter Values
Attributes
L2CP Address Set CTA or CTB or CTB-2
Table 30 – OVC L2CP Service Attributes

ENNI Service
Parameter Values
Attributes

Empty list, or list of protocols to be Peered where each entry

L2CP Peering consists of {Destination Address, Protocol Identifier}or {Desti-
nation Address, Protocol Identifier, Link Identifier}
ENNI Tagged L2CP
Frame Processing 802.1 compliant or 802.1 non-compliant
Table 31 – ENNI L2CP Service Attributes

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 37
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

VUNI Service
Parameter Values
Attributes
L2CP Address Set CTA or CTB

Empty list, or list of protocols to be Peered where each entry

L2CP Peering consists of {Destination Address, Protocol Identifier}or {Desti-
nation Address, Protocol Identifier, Link Identifier}
Table 32 – VUNI L2CP Service Attributes

Appendix B L2CP Examples / Use Cases

This annex provides a brief description of common protocols, and what it means to have
a Service Provider “Peer” the protocol at a UNI or ENNI.

B.1 Link Aggregation (LACP/LAMP)

Link Aggregation is a mechanism for making multiple point-to-point links between a pair
of devices appear to be a single logical link between those devices. Link Aggregation is
specified in IEEE Std 802.1AX12, Link Aggregation Control Protocol (LACP) [Link]
between exactly two peer devices for the purpose of creating, verifying, and monitoring
the logical link created by aggregating individual links. Specific L2CP frames, known as
Link Aggregation Control Protocol Data Units (LACPDUs), are exchanged between the
peer devices on each individual link in the aggregation. The protocol identifier used by
LACP is an Ethertype with a value of 0x8809 (the “Slow Protocols” Ethertype) and sub-
type values 01 and 02.

The operation of LACP affects the entire interface (UNI or ENNI) regardless of the num-
ber of services supported across that interface. LACP can be supported at each interface
independent of whether it is supported at any other interface.

The 802.1AX standard supports aggregation of physical links, chains of physical links
concatenated by Two Port MAC Relays (TPMRs), and virtual connections such as an
EPL service in a CEN. A port can support one, two, or all three of these types of aggre-
gation by running an instance of LACP for each type of aggregation. Each LACP in-
stance uses a different destination MAC address in LACPDUs so that the LACPDUs are
addressed to the appropriate peer LACP instance. The destination addresses specified by
IEEE Std 802.1AXbk-2012 for use by LACP are shown in Table 33. The 00-80-C2-00-
12
Link Aggregation was originally specified as clause 43 of IEEE Std 802.3 (originally as IEEE Std 802.3ad-2000
and subsequently incorporated into base 802.3 document). In 2008 the responsibility for maintaining the standard
was moved from the 802.3 working group to the 802.1 working group, so it was removed from IEEE Std 802.3-2008
and published as IEEE Std 802.1AX-2008. It has since been amended by 802.1AXbk-2012.
13
The Link Aggregation standard specifies two protocols: Link Aggregation Control Protocol (LACP) and Link
Aggregation Marker Protocol (LAMP). For the purposes of this document the label “LACP” includes both LACP
and LAMP, and the label “LACPDU” includes both LACPDUs (protocol subtype 01) and LAMPDUs (protocol
subtype 02). When a UNI or ENNI L2CP Service Attribute lists LACP as being peered, peering of LAMP is im-
plied.
MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 38
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

00-02 “Slow Protocols” is the default address for a single LACP instance, and was the
only address specified in the original Link Aggregation standard. LACPDUs are un-
tagged when generated by an LACP instance.

L2CP Reserved Assignment Used to aggregate:

Destination MAC
Address
01-80-C2-00-00-00 Nearest Customer Bridge virtual connections
01-80-C2-00-00-02 Slow Protocols physical links
01-80-C2-00-00-03 Nearest Non-TPMR Bridge chains of physical links

Table 33 – LACP Destination Addresses

B.1.1 Peering LACP at a UNI

MEF 10.3 requires peering of LACP on physical links for a UNI with two links. In this
case LACP is listed as being Peered in the UNI L2CP Peering Service Attribute. When
LACP is peered at a UNI, the Slow Protocols destination address is used ([R13]). This
provides the basic aggregation of two physical links shown in Figure 8.
UNI

CE PE LACPDUs use the Slow Protocols

destination address

Figure 8 – Basic Link Aggregation at a UNI

LACPDUs generated by a LACP instance at a UNI are untagged. A tagged LACPDU

with the Slow Protocols destination address is discarded by the protocol entity.

B.1.2 Peering LACP at a ENNI

MEF 26.1 requires peering of LACP on physical links for an ENNI with two links. In
this case LACP is listed as being Peered in the ENNI L2CP Peering Service Attribute.
When LACP is peered at an ENNI, the Slow Protocols destination address is used
([R14]). This provides the basic aggregation of two physical links shown in Figure 9.
ENNI

PE PE LACPDUs use the Slow Protocols

destination address

Figure 9 – Basic Link Aggregation at an ENNI

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 39
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

LACPDUs generated by a LACP instance at an ENNI are untagged. Ingress LACPDUs

at an ENNI that have an S-VLAN tag will not be delivered to a LACP protocol entity by
the processes and requirements specified in section 9. Any such frames that were not
generated in error will have resulted from ingress LACPDUs at a UNI. In the absence of
errors these frames either have the Nearest Customer Bridge destination address or are on
an EPL service with EPL Option 2 L2CP processing. In these cases the frames are
Passed by the processes and requirements specified in section 9. In all other cases S-
tagged LACPDUs are either Passed or Discarded by the processes and requirements spec-
ified in section 9.

B.1.3 LACP and EPL Option 2 L2CP processing

EPL Option 2 L2CP processing recommends that LACPDUs with the Slow Protocols
destination address are Passed at all UNIs. This conflicts with the requirement to use
Link Aggregation with LACP on a UNI with two links. Therefore if LACPDUs with the
Slow Protocols destination address are Passed at the UNI, the UNI can only have a single
link and LACP is not listed as being peered in the UNI L2CP Peering Service Attribute.
Conversely, if the UNI has two links then LACP is listed as being peered in the UNI
L2CP Peering Service Attribute and LACPDUs with the Slow Protocols destination ad-
dress are not Passed.

B.1.4 Aggregation of EPL services

Figure 10 shows an example of a Subscriber using Link Aggregation to aggregate EVCs.

Because Link Aggregation is only intended to operate on point-to-point links between the
same systems, these EVCs are point-to-point EVCs between All-to-One Bundled UNIs
(i.e. they are EPL services). In this case only the CEs need to be running LACP and the
PEs do not participate. Therefore LACP is not listed as being Peered in the UNI L2CP
Peering Service Attribute. The LACP instances in the CEs use the Nearest Customer
Bridge destination address so that the LACPDUs will pass through the CEN. If the EVCs
are EPL services with EPL Option 2 L2CP processing that Pass LACPDUs with the Slow
Protocols destination address, then the CE can use the Slow Protocols destination address
instead.

Aggregation of virtual connections

UNI

UNI

PE CE runs one instance of LACP

PE EPL A using the Nearest Customer
Bridge destination address (or,
CE CE if EPL Option 2 services, the
Slow Protocols destination
EPL B
PE address)
PE
UNI

UNI

Figure 10 – Link Aggregation of EPL Services

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 40
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.
 Multi-CEN L2CP

It is possible to aggregate EVCs where one or more of the UNIs are protected by Link Aggrega-
tion on the physical links as shown in Figure 11. In this case the CE runs two instances of
LACP, one using the Slow Protocols destination address and one using the Nearest Customer
Bridge destination address. LACP is listed as being Peered in the UNI L2CP Peering Service
Attribute, and the PE runs one instance of LACP using the Slow Protocols address. From the
Service Provider point of view this is no different than the basic Link Aggregation at a UNI
shown in Figure 8.

Aggregation of virtual connections

UNI
UNI

PE CE runs two instances of LACP,

PE EPL A one using the Slow Protocols
destination address and one
CE CE using the Nearest Customer
EPL B Bridge destination address
PE PE

UNI
UNI

Figure 11 – Link Aggregation of EPL services with protected UNIs

B.1.5 Configuring Link Aggregation for Active/Standby operation

MEF 10.3 and MEF 26.1 require that LACP at a UNI or ENNI operates in active/standby mode.
802.1AX will designate links in an aggregation as active or standby when device limitations pre-
vent all links from being active simultaneously, however there is no standard management object
that allows an operator to explicitly configure active/standby operation. Some devices have pri-
vate management objects that either specify active/standby operation directly, or allow setting
the maximum number of active links in an aggregation to one. In either of these cases the prima-
ry link can be designated by the setting of the port priority value. It is sufficient to configure ac-
tive/standby operation in just one of the devices in the aggregation, so at a UNI it is typically
configured in the PE.

An alternative way to achieve active/standby operation is to use a distribution algorithm that

transmits all frames on one link in the aggregation. Whether this distribution algorithm is sup-
ported, and how it is configured, is device specific.

MEF 45 © The MEF Forum 2014. Any reproduction of this document, or any portion thereof, shall contain the Page 41
following statement: "Reproduced with permission of the MEF Forum." No user of this document is
authorized to modify any of the information contained herein.