Validation Framework

MEF 3.0 Carrier Ethernet Key Standards

• MEF 91: Establishes the test requirements for subscriber and operator Carrier Ethernet services. MEF 91 is the blueprint for what is tested and identifies the underlying MEF services standards for both the subscriber and operator services.
• MEF 3.0 Certification Framework: Outlines the certification process, testing procedures, and criteria for verifying compliance with MEF 3.0 specifications, ensuring consistent quality and interoperability of certified products and services.
• MEF 6.3 Subscriber Ethernet Services Definitions: Includes the superseded MEF 6.2 foundational specification that establishes the service definitions for UNI attributes, EVC attributes, and bandwidth profiles for all the Carrier Ethernet service types.
• MEF 10.4 Subscriber Ethernet Services Attributes: Includes the superseded MEF 10.3 specification and establishes the foundational service attributes for E-Line, E-LAN, E-Tree, E-Access, and E-Transit service types. It defines service attributes, performance objectives, and management requirements for Carrier Ethernet services, including bandwidth profiles, service multiplexing, and Quality of Service (QoS) parameters.
• MEF 26.2 Operator Ethernet Services Attributes: Establishes the External Network-to-Network Interface (ENNI) attributes and requirements critical for multi-operator service delivery. It specifies how Operator Virtual Connections (OVCs) are managed over ENNIs spanning multiple operators. Additionally, it covers the performance objectives, traffic management, service multiplexing, and handling of OAM protocols at the ENNI.
• MEF 51 (.1) Operator Ethernet Service Definitions: Defines operator services based on the 26.2 service attributes, including OVC UNI or ENNI endpoint attributes. It establishes the O-Line, O-LAN, and O-Tree definitions and implementations.
• MEF 62 Managed Access E-Line (MAEL) Service: Standardizes the implementation and characteristics of point-to-point managed Access E-Line services based on MEF 51.
• MEF 65 Simplified Transit E-Line (STEL) Service: Formalizes the common use case of Transit E-Line services by constraining values of certain ENNI Common Attributes, ENNI Service Attributes, and Operator Ethernet Service Attributes defined in MEF 26.2.
• MEF 30.1 Service OAM Fault Management Implementation: Establishes a common foundation for implementing Service OAM (SOAM) fault management for Ethernet Services.
• MEF 35.1 (Service OAM Performance Monitoring): Standardizes SOAM Performance Monitoring (PM) implementation for Ethernet services, building from the MEF 17 framework.
• MEF 45.1 Layer 2 Control Protocols in Ethernet Services: Defines treatment requirements for Layer 2 Control Protocols (L2CP) frames within Carrier Ethernet services.
• MEF 23.2 (.1) Class of Service: MEF 23.2 standard and amended 23.2.1 standard for including bandwidth profile models with token sharing define the Class of Service attributes for Carrier Ethernet networks, ensuring service differentiation capabilities.
• MEF 48.1 Ethernet Service Activation Testing: Provides methodologies and requirements for Service Activation Testing (SAT) of Ethernet services.

Carrier Ethernet Subscriber Models

Metro Ethernet Forum (MEF) establishes the framework for service attributes and definitions within the Carrier Ethernet network. The subscriber delivery mechanisms included in this JVD follow those standardized models. The column on the right describes the common solutions for the type of service, with the majority featured in the validation.

Table 1: Carrier Ethernet Service Categories

Service Type	Service Description	Common VPN Types
	E-LINE for delivering point-to-point connections like Ethernet Private Lines (EPL) or Ethernet Virtual Private Lines (EVPL)	EVPN-VPWS EVPN-FXC L2Circuit VPLS VPWS
	E-LAN for delivering multipoint-to-multipoint connections like Ethernet Private LAN (EP-LAN) or Ethernet Virtual Private LAN (EVP-LAN).	EVPN-ELAN VPLS L2VPN
	E-TREE for delivering rooted-multipoint hub-and-spoke connections such as Ethernet Private Tree (EP-TREE) or Ethernet Virtual Private Tree (EVP-TREE).	EVPN-ETREE H-VPLS
	E-ACCESS for delivering wholesale point-to-point services connecting UNI to NNI as Access EPL or Access EVPL	EVPN-VPWS LSW L2CCC LSW

Key Service Attributes

MEF services attributes are further defined on the basis of major characteristics:

• Service Multiplexing: This attribute allows multiple Ethernet Virtual Connections (EVCs) to terminate on the same User Network Interface (UNI), enabling multiple distinct Ethernet services to share the same physical or virtual interface. If Service Multiplexing is enabled at the UNI, multiple EVCs can share the same interface. For example, EVC1 for Customer-A and EVC2 for Customer-B can be assigned the same physical interface while retaining local separation. To differentiate traffic for each service, MEF standards specify the use of Customer Edge VLAN (CE-VLAN) IDs to map incoming frames to the appropriate EVC. Each EVC maintains discrete service characteristics for performance, bandwidth, and Quality of Service (QoS) parameters. This approach optimizes network efficiency and flexibility, allowing service providers to deliver customized, on-demand services over common infrastructures without requiring a dedicated connection for each service.
• Bundling: This attribute allows multiple CE-VLANs to be grouped under a single Ethernet Service at the UNI. Different types of customer traffic, such as voice, data, and video, are carried over one EVC while maintaining distinct service characteristics for each CE-VLAN. Bundling enables service providers to manage multiple CE-VLANs within a single EVC, providing flexibility for differentiated traffic policies and performance requirements, making it ideal for delivering multiple traffic types from a single customer over a common interface.
• All-to-One Bundling: This attribute consolidates all CE-VLANs from a single UNI into a single EVC, simplifying service provisioning when per-VLAN differentiation is not necessary. All CE-VLANs share a unified service policy, inheriting the same QoS attributes applied to the EVC. Typically used with private Ethernet services, All-to-One Bundling enables secure, isolated connectivity between customer sites over common network infrastructure.
• An Ethernet Virtual Circuit (EVC): This attribute is a logical connection that links two or more Customer Edge (CE) devices across a service provider’s network. It forms the foundation for MEF-defined Ethernet services (for example, E-Line, E-LAN, and E-Tree). EVCs provide a logical path through which customer traffic flows, ensuring the traffic between specified CEs is isolated and follows defined performance characteristics like bandwidth and latency. MEF defines the following three main types of EVCs:
  • Point-to-Point (for example, E-Line)
  • Multipoint-to-Multipoint (for example, E-LAN)
  • Rooted Multipoint (for example, E-Tree)
• Customer Edge VLAN (CE-VLAN) ID(s): This attribute defines customer-assigned VLAN tags that are associated with an EVC at the service provider’s edge network. Depending on the service agreement and customer requirements, one or more CE-VLANs may be mapped to an EVC.
• EVC Data Service Frame Disposition Service Attribute (MEF 10.4/10.3): This attribute defines how Unicast, Multicast, and Broadcast traffic types are managed within the EVC. It specifies the treatment of frames, allowing flexible and policy-driven frame forwarding or discarding in compliance with the service’s requirements, including:
  • Delivered Unconditionally: Frames are forwarded to the destination without any conditions, ensuring that all valid frames are transmitted as expected.
  • Delivered Conditionally: Frames are forwarded based on specific conditions, such as matching service policies, VLAN IDs, or other predefined criteria. This may include forwarding frames to specific recipients for multicast or broadcast traffic.
  • Discarded: Frames are dropped if they do not meet certain criteria, such as invalid service parameters, improper frame tagging, or non-conformance with the service policy.

The updates from MEF 10.3 to MEF 10.4 signify a shift in design philosophy, moving from granular per-frame type service disposition attributes to a consolidated attribute utilizing a 3-tuple structure of frame handling within an EVC. The disposition settings (discard, delivery unconditionally, or delivery conditionally) remain unchanged but simplify overall management.

While the CE-VLAN construct remains central to the current implementation of MEF 3.0, as defined by MEF 10.3 technical specification, the modernized EVC EP Map Service Attribute and EVC EP Service Attribute introduced in MEF 10.4 reflect the continued evolution in the MEF framework, enveloping industry trends with greater flexibility. For more information on the EVC End Point (EVC EP) model, see MEF 10.4 Technical Specifications.

Reference: https://wiki.mef.net/display/CESG/Bundling+and+Service+Multiplexing

Table 2 explains MEF guidance for valid service multiplexing and bundling combinations, which are followed by this JVD. For more information, see MEF documentation.

• Service Multiplexing determines whether the UNI terminates one (disabled) or more (enabled) Ethernet services.
• Bundling is ‘Enabled’ when multiple CE-VLANs are supported on the UNI or ‘Disabled’ when each Ethernet Service includes a single CE-VLAN.
• All-to-One Bundling means that all CE-VLANs are associated with a single Ethernet service as a private UNI service. When bundling is ‘Disabled’, one or more virtual private services are enabled per UNI.

The MaaS JVD covers 19 use cases for delivering Metro Ethernet services, including:

• E-Line: Point-to-point connections like EPL and EVPL
• E-LAN: Multipoint-to-multipoint connections like EP-LAN and EVP-LAN
• E-Tree: Rooted multipoint hub-and-spoke connections like EP-TREE and EVP-TREE
• Access E-Line: Wholesale point-to-point services connecting UNI to NNI
• Internet Access: IP service connecting IPVC endpoints for dedicated Internet access

This JVD explains how the featured services, behaviors, and characteristics map to MEF definitions.

Test Bed

The Metro as a Service JVD leverages two foundational components: the physical infrastructure introduced in Metro EBS JVD and Iometrix Lab in the Sky. Figure 1 explains connectivity for building the metro fabric spine-and-leaf and multi-ring topologies with primary featured DUTs in this JVD.

Figure 1: Lab Topology Test Bed

Iometrix Lab in the Sky is a Network as a Service (NaaS) cloud-based testing infrastructure supporting a testing application that leverages virtual test probes utilizing x86 whitebox probes. The same infrastructure is used as a basis for MEF 3.0 certification testing. The Iometrix Lab in the Sky infrastructure consists of the following components.

Figure 2: Iometrix Infrastructure

Platforms / Devices Under Test (DUT)

Selected access platforms include ACX7024, ACX7100-48L, ACX710, ACX5448, and MX204 platforms. Aggregation or spine platforms include the ACX7100-32C in the metro fabric and ACX7509 with MX10003 routers as metro distribution routers in the ring architecture. The Metro edge gateway performs border leaf functions with the ACX7509 and ACX7100-32C, providing connectivity to the edge compute complexes. The metro core uses the PTX10001-36MR core and peering platform. The MX304 is ideally suited for the multi-services edge, supporting complex services termination and interconnect points.

The supported versions of Junos OS and Junos OS Evolved for all platforms is 23.2R2, where applicable.

Test Bed Configuration

JVD configurations are available at Juniper GitHub. Please contact your Juniper representative for any queries.