Considerations for Implementation of MEF Services

Written by Yoav Cohen

Content Disclaimer

Abstract

The Metro Ethernet Forum (MEF) has specified a framework for delivering Ethernet services over carrier grade networks. The framework specifies requirements for the network architectures, services and interfaces. The Ethernet Services are delivered from User Network Interface to User Network Interface (UNI to UNI). In addition, a set of standard Ethernet Services has been defined based on the framework. An Ethernet Service is defined in the framework by an abstract construct called the Ethernet Virtual Connection (EVC). The Service Framework associates a service instance with the UNI characteristics, at which the Service is offered, to the Subscriber and with the EVC supporting the service. The MEF Ethernet services, expressed through the EVC construct, are defined in a manner that is agnostic to the specific technologies implementing them. However, the most common technologies used for supporting MEF services may not always provide full transparency with their transport services. This document briefly discusses the requirement that the basic elements constituting the MEF framework specify for providing Carrier Class Ethernet Services. This is followed by highlighting some of the issues that need to be considered when implementing services that are required to comply with MEF specifications.

Introduction

The Transport Layer, also referred to as the TRAN Layer, provides connectivity between service-aware Ethernet endpoints. Various layer network technologies and interconnect approaches may be used to support the transport requirements for the Ethernet services layer. Sample transport layer networks include IEEE 802.3 PHY, IEEE 802.1 bridged networks, SONET/SDH High Order/Low Order Path networks, ATM VC, OTN ODUk, PDH DS1/E1, MPLS LSP, etc. Those transport layers are supported by their respective server layers; e.g., SDH STM-N Multiplex Section, ATM VP, OTN OTUk, PDH DS3/E3, MPLS LSP, IP, fiber, etc. A Transport layer, when used for implementing connectivity functionality required for supporting the MEF services, can essentially be based on any technology that supports Ethernet as its client layer.

Packet-oriented transport layers provide connectivity services that can basically be classified into two types, namely connectionless and connection oriented. In Connectionless technologies data is typically sent between end points without prior arrangement. In Connection Oriented technologies an end-to-end connection is established (by a control protocol or provisioned by a management system) prior to the transmission of data. More details on these technologies are provided later in the Connectionless and Connection Oriented sections, respectively.

The Metro Ethernet Forum (MEF) has specified a framework for delivering Ethernet services over carrier networks. The framework specifies requirements for the network architectures, services and interfaces. The Ethernet Services are delivered from User Network Interface to User Network Interface (UNI to UNI). In addition, a set of standard Ethernet Services has been defined based on the framework. An Ethernet Service is defined, in the framework, via an abstract construct called the Ethernet Virtual Connection (EVC). The Service Framework associates a service with the UNI characteristics, at which the Service is offered, to the Subscriber and with the EVC supporting the service. The MEF Ethernet services, expressed through the EVC construct, are defined in a manner that is agnostic to the specific technologies implementing them. However, the most common technologies used for supporting MEF services may not always provide full transparency with their transport services.

This document briefly discusses the requirements that the basic elements constituting the MEF framework, specify for providing Carrier Class Ethernet Services.This is followed by highlighting some of the issues that need to be considered when implementing services that are required to comply with MEF specifications.

The remainder of the document is organized as follows:

• The section MEF Network Architecture provides a brief overview of the MEF network architecture
• The section MEF Services Overview provides a brief overview of the MEF Services
• The section MEF Carrier Class Requirements discusses MEF Carrier Class requirements
• The section Technology Highlights discusses technology highlights
• The section Implementing MEF Services  discusses implications of implementing the MEF services
• The Summary section provides a summary

MEF Network Architecture

The Metro Ethernet Network (MEN) layer network model specified in the architecture framework, defines the MEN in terms of three layer network components: the Ethernet Services Layer supporting basic Layer 2 (L2) Ethernet data communication services; a set of one or more supporting Transport Services Layer(s) and, an optional Application Services Layer supporting applications carried on the basic L2 Ethernet services. The layered network model is based on a client/server relationship. In addition, each of these layer networks is composed of data, control and management plane components. This layer network view of a MEN (specified in [7]) is illustrated in Figure 1.

Figure 1: MEN Network Layer Model

MEF Services Overview

MEF Ethernet Services are defined as connectivity services provided by a Service Provider's Carrier Ethernet Networks (CENs) to Customer Edge (CE) devices.  The connectivity service is modeled by an Ethernet Virtual Connection (EVC). The EVC is defined as an association of two or more User Network Interfaces (UNIs) that limits the exchange of Service Frames to UNIs in the EVC.  An Ethernet Service [9] [10] consists of an Ethernet Service Type and is associated with one or more Bandwidth Profile(s) and supports one or more Classes of Service. A service is also associated with a list of Layer Two Control Protocols such as Spanning Tree Protocol or Link Aggregation Control Protocol and a set of actions that specify how they should be handled.

MEF Service

Ethernet Service Types can be used to create a broad range of Subscriber services. The service types are characterized by their required connectivity [10]. The following service types have been defined to date: Ethernet Line Service (E-Line Service) uses a Point-to-Point EVC. The Ethernet LAN Service (E-LAN Service) uses a Multipoint-to-Multipoint EVC.The Ethernet Tree Service (E-TREE Service) uses a Rooted-Multipoint EVC.

MEF E-Line Service

E-Line service types require Point-to-Point (P2P) connectivity, as illustrated in Figure 2. In a Point-to-Point EVC, exactly two UNIs must be associated with one another.  Ingress Service Frame to the EVC at one UNI can only result in an egress Service Frame at the associated UNI.

Figure 2 - Point-to-Point EVC.

MEF E-LAN Service

E-LAN service types require Multipoint-to-Multipoint (MP2MP) connectivity, as illustrated in Figure 3. In a Multipoint EVC, two or more UNIs are associated with one another. An ingress Service Frame mapped to the EVC at one of the UNIs can only result in an egress Service Frame at one or more of the associated UNIs.

Figure 3 - Multipoint-to-Multipoint EVC.

MEF E-Tree Service

E-Tree service types require Rooted-Multipoint (RMP) connectivity, as illustrated in Figure 4. In a Rooted-Multipoint EVC, one or more of the UNIs must be designated as a Root and each of the other UNIs must be designated as a Leaf. A single root has connectivity to all the leaves. An ingress Service Frame mapped to the EVC at a Root UNI may be delivered to one or more of the associated UNIs (either Root or Leaf) in the EVC. An ingress Service Frame mapped to the EVC at a Leaf UNI can only result in an egress Service Frame at one, some or all of the Root UNIs.

Figure 4 - Rooted-Multipoint EVC.

MEF Bandwidth Profiles

A Bandwidth Profile (BWP) bandwidth profile provides a method to characterize traffic flowing over the UNI reference point. Implementations can also use the BWP at the equipment's UNI interface to implement methods for rate enforcement and policing of Service Frames. Each BWP consist of the following main attributes of <CIR, CBS, EIR, EBS>. The ability of the service provider's network to monitor the bandwidth using the BWP allows the service providers to bill for the bandwidth usage and the delivered transport network performance in terms of delay and service availability.

From the subscriber's point of view, the Bandwidth Profiles specify the amount of 'committed' and 'excess' Ethernet Service Frames allowed into the service provider's network at the UNI.

Service frames sent, up to the 'committed' rate, are allowed into the service provider's network and delivered per the performance objectives specified in the Service Level Agreement (SLA) e.g. packet delay & loss objectives. These service frames are referred to as 'in-profile' or 'conformant' (to CIR/CBS).

Service frames sent, beyond the 'committed' rate but up to the 'excess' rate, are allowed into the service provider's network but are delivered without any performance guarantees. These service frames are also referred to as 'in-profile' or 'conformant' (to EIR/EBS).

Service frames sent above the 'excess' rate are referred to as 'out-of-profile' or 'non-conformant' to the bandwidth profile and hence are discarded. For more details see [9].

MEF Class of Service

The level of performance that the network will provide to a particular set of Service Frames is called a Class of Service (CoS). A CoS defines the level of performance in terms of performance objectives to be specified in the Service Level Agreement (SLA). A single CoS can be associated with a UNI where all service frames crossing the UNI receive the same level of performance, or with an EVC where all service frames mapped to an EVC receive the same level of performance. Multiple CoS (up to 8) can also be associated with an EVC. In this case service frames mapped to the EVC and specific CoS Instance identifier receive the same level of performance.

The CoS performance objectives are defined as Frame Delay (FD), Frame Delay Variation (FDV, aka Jitter), Frame Loss Ratio (FLR) Performance and Availability Performance [9].

MEF Carrier Class Requirements

In addition to the general requirements specified for MEF services and highlighted above, MEF has also defined requirements for extending the Ethernet services to have Carrier Class attributes. MEF has defined a Carrier Class Ethernet as ubiquitous, standardized carrier-class network and service with the following fundamental attributes that distinguish it from the familiar LAN based Ethernet.

• Standardized Services
• Scalability
• Reliability
• Service Manageability
• Quality of Service

Standardized Services

By standardizing a set of Ethernet Services, MEF enables the Service Providers and their enterprise subscribers to have a common understanding of the basic offered services. These services can be deployed over metro, regions, and world-wide areas. In addition, since the services are defined to be agnostic of the transport layer, service providers can offer them on their currently deployed infrastructure. This allows the service providers to save on both Capital Expenditure (CapEx) and Operational Expenditure (OpEx).

Scalability

Typical scaling vectors in Metro Ethernet Networks encompass dimensions such as the ability to provide services to millions of subscribers, the level of converged network supporting voice, video and data, the spanning breadth of Access, Metro & National networks and ability to scale bandwidth from 1 Mbps to 10 Gbps and beyond.

Reliability

Network Reliability refers to meeting the most demanding requirements for service quality and network availability. These requirements are partly derived from the requirements for supporting Carrier Class networks.

Survivability plays a critical role in the delivery of reliable services. Network survivability is the network's ability to restore traffic following a failure, hence extending the availability of the network. Guaranteed services demand, in turn, resilient networks that are capable of detecting failures very rapidly and immediately executing procedures for restoring the services in accordance with the terms of the SLA.

Various recovery schemes and processes have been defined in relevant Standard Development Organization (SDOs). They are mostly applicable for the network level.  These schemes are applied to recover from 'failed' or 'degraded' transport entities (links or nodes). Such actions are typically initiated by the detection of a defect or performance degradation, or by an external request (e.g., an operator request for manual control of protection switching). It is a common approach in the relevant SDOs to divide recovery schemes into protection switching and restoration mechanisms.

Protection switching assumes a pre-assigned capacity between nodes, where the simplest scheme has one dedicated protection entity for each working entity, while the most complex scheme has M protection entities shared between N working entities (M:N). Protection switching may be either unidirectional or bidirectional.

Restoration mechanisms do not pre-assign capacity for failure recovery. Upon a failure notification, the restoration process searches any capacity available between nodes to restore the services and typically involves re-routing of the services around the failed entity. The resources used for restoration may be pre-planned or executed on demand and recovery priority may be used to determine services recovery sequence. Some services may not be recovered in accordance with the SLA or are sacrificed to promote recovery of higher priority services.

Typically, protection actions are expected to be completed within time frames of tens of milliseconds, while restoration actions are normally completed in periods ranging from hundreds of milliseconds to a maximum of a few seconds.

At the ETH layer, fault and performance management are typically supported by the following mechanisms:

• Fault Management
  - Service OAM based on IEEE 802.1ag & ITU-T Y.1731
  - Link OAM based on IEEE 802.3ah (EFM)
• Performance Monitoring
  - Service OAM based on ITU-T Y.1731

Quality of Service (QoS)

The Quality of Service can be viewed as the extent to which the Service Provider provides services that match the customer requirements. The ability of the network to provide flexible network control is an important key in supporting QoS. The following examples list some of the attributes that allow the Service Provider to closely match the customer requirements from the network:

• Granularity of bandwidth per Classes of Service
• Service Level Agreements (SLAs) that deliver end-to-end performance matching the requirements for voice, video and data over converged business and residential networks
• Provisioning via SLAs that provide end-to-end performance based on CIR, frame loss, delay and delay variation characteristics

Technology Highlights

As described in the MEF Network Architecture section and depicted in the Network Layer Model (Figure 1), MEF Services are delivered over the transport (TRAN) Layer. Specific technologies aiming to implement the transport layer functionality must carefully evaluate the MEF architecture and services requirements allowing the MEF services to be fully overlaid over the specific technology's functional components.  A common distinction among the contemporary technologies providing transport services is between those providing connectionless and connection oriented transport services.A brief description of these technologies is provided below.

Connectionless (CL) Technologies

Connectionless forwarding technologies can be described as having some of the following characteristics:

• Data is forwarded between end points without prior arrangement inside the network.
• The device at one end of the communication transmits data to the other, without having to ensure that the recipient is available and ready to receive the data.
• Packets are routed individually. The packets contain destination addresses, which allow them to be delivered independently.
• Packets belonging to a particular traffic flow may be routed in a different way across the network.
• The route that packets are forwarded through between source and destination in "steady-state" can be calculated before traffic actually flows through the network. This is because the mechanisms for controlling the forwarding paths are standard and hence known in the industry. For example, a typical Ethernet based L2 forwarding devices e.g. bridges use loop prevention mechanisms such as Spanning Trees to control the forwarding paths while a L3 forwarding devices (e.g. routers) use routing protocols such as OSPF and IS-IS to control the forwarding paths. However all these protocols do not allow the ability  to force or constraint the routes through specific path i.e. include or exclude of nodes and links.
• It is hard to guarantee bandwidth end-to-end and control the performance attributes such as delay and delay variation to specific services, since (as noted above), data is sent between end points without prior arrangement inside the network.
• During failure, the traffic will typically be directed through a new route calculated in real time by the loop prevention mechanisms or routing protocols.

Examples of devices that employ connectionless forwarding are virtual LAN bridges supporting C-tags (IEEE 802.1Q), Provider Bridges (PBs) supporting S-tags (IEEE 802.1ad) and Provider Backbone Bridges (PBB) supporting MAC-in-MAC (IEEE 802.1ah).

These Ethernet based technologies require mechanisms to ensure that no loops occur in the forwarding path, since loops can be very disruptive to the traffic. The relevant SDOs have specified mechanisms that address this problem. Some of the mechanisms try reducing the minimum time it takes the networks to stabilize the routes after the internal topology changes occurring due to failures or other events, while other mechanisms control the number of hops frames could pass along a route. An example of mechanisms which create steady-state stable routes are the suite of Spanning Tree Protocols e.g. RSTP (IEEE 802.1Q-2006), MSTP (IEEE 802.1Q-2006). An example of mechanisms which limit the number of hops frames could pass along a route are Time To Live (TTL) mechanisms which check and decrement the TTL value as the frame passes along a route.

Connection Oriented (CO) Technologies

Connection Oriented technologies can be described as having some of the following characteristics:

• An end-to-end connection is established (by a control protocol or provisioned by a management system) prior to the transmission of data.
• Traffic flows are identified by a Connection Identifier. The destination will not accept traffic from unknown Connection Identifiers that were not configured to receive traffic from.
• Ability to provide End-to-end Bandwidth guarantees as well as ability to control delay and delay variation to specific services is a common procedure, since (as noted above), an end-to-end connection is established prior to the transmission of data.
• During failure, the traffic for each service will not be directed through a new route unless this route was provisioned before (i.e. a backup entity) or is signaled/restored during the failure.

CO technologies can be categorized into "circuit switching" (which typically switches L1 circuits) and "packet switching" technologies (which typically switch L2 "data units").

Examples of circuit switching technologies are SONET and SDH. Examples of frame switching technologies are PBB-TE (PBBs supporting Traffic Engineering, according to emerging IEEE 802.1Qay standard). Examples of devices that employ connection oriented packet forwarding are MPLS-TP compliant routers.

Implementing MEF Services

Although MEF services are defined in an abstract manner that is agnostic to the specific technology implementing them, these services impose specific requirements on the underlying technology. The service characteristics highlighted in the sections above require the implementers to carefully overlay them on top of the chosen technology's functional components.

Examples of general topics applying to all the service types which need special consideration are listed below. Some of the topics highlight potential conflicts that can arise between the MEF specifications and the technologies' specific standards:

• Ethernet based connectionless technologies, which rely on MAC learning and forwarding mechanisms, flood the unknown multicast and broadcast destination MAC addresses to all devices and ports in the broadcast domain (VLAN). The flooding of unknown destination MAC addresses continues until the "location" of the destination MAC addresses becomes known. Thus, this flooding, which can result in frames egressing UNIs which are not associated with the EVC, can violate the definition of an EVC (as noted in the Introduction section). Special mechanisms must be provided to mitigate or remove this problem.
• When implementing specific MEF CoS, attention must be given to ensure that the performance objectives are met. For example, the availability objective must be evaluated against the survivability mechanisms offered by the transport layer. These include protection and restoration mechanisms e.g. STP. The integration of these mechanisms should adhere to or provide better results than the required availability objectives.

The following sub-sections list some examples of topics pertaining to specific service types.

Implementation of E-Line Based Services

In general, the implementation of E-Line based services in both connectionless and connection oriented technologies creates point-to-point "virtual connections" between UNIs. Some connectionless technologies, such as PB, have a unique definition of how to handle standard user Layer Two Control Protocols (L2CPs). The S-Component of a standard Provider Bridge (IEEE 802.1ad) will filter frames whose destination address is in the range of 01-80-C2-00-00-01 through 01-80-C2-00-00-0A since they have a span of a single link. In contrast, some of the MEF defined services e.g. EPL, specifically require the network to provide transparent "wire" connectivity between customer entities for all user traffic, which includes also the L2CPs. The Provider Bridge behavior may in this case contradict MEF requirement.

Implementation of E-LAN Based Services

Implementation of E-LAN based services differs between connectionless and connection oriented technologies. All Ethernet based connectionless technologies provide as part of their basic functionality support for multipoint-to-multipoint connectivity at the ETH layer which is based on their support for MAC learning and forwarding. Connection oriented technologies need to support an additional mechanism which emulates the MAC learning and forwarding functionality. One such known solution encompassing the architecture and a set of mechanisms has been specified by the Internet Engineering Task Force (IETF) as Virtual Private LAN Services (VPLS). With VPLS a full mesh of Pseudo Wires (PWs) provides the connectivity for LAN emulation inside the network. The associated PWs on the network-facing side are treated as Ethernet "ports". This solution architecture was designed to not use any of the spanning tree protocols and hence a "split horizon" mechanism is used by which packets received from a PW at a VPLS instance will never be forwarded back into the network [11].

In order to provide good LAN emulation, the PWs composing the VPLS service must be highly available. This key characteristic is expressed by the amount of time where full-mesh connectivity of PWs is provided. A failure occurring in the network, which prevents the VPLS service from exhibiting full mesh connectivity, such as when PW connectivity fails, is known as "black hole" [12].  The "black hole" phenomenon causes Ethernet service frames sent on a failed PW to be discarded, degrading the overall service availability.

Another aspect needing consideration is the following: Typically E-LAN services require the forwarding mechanism to replicate broadcast, multicast and unknown unicast ingress service frames, sending them to all associated ports, or PWs in case of VPLS. This requirement can create scaling problems, for all technologies, when the number of involved UNIs in a given E-LAN service increases dramatically. One way to mitigate this problem in the case of VPLS is to create a hierarchy of networks. The "outer" networks act as aggregation network towards the "inner" i.e. core networks.  This allows a reduction in the number of UNIs participating in a single E-LAN service.

Implementation of E-TREE Based Services

E-TREE implementations typically create two asymmetric connectivity topologies at the transport layer. To provide connectivity from the root to the leaves, the Root UNI may implement MAC learning and forwarding mechanisms. To provide connectivity from a leaf to the root, the Leaf UNI implements P2P connectivity. In this implementation model, the connectivity from the root to the leaves can exhibit scaling problems similar to the case of the MP2MP connectivity.

One of the common features that an E-TREE service would support, but which MEF has not addressed yet, is the ability to create "closed groups" where the leaves register for the services. If no leaf has registered to receive a service, the "sub-tree" to that leaf is pruned, thereby conserving network resources.

Connectionless transport networks based on Ethernet, typically have such mechanisms "built-in" as part of the technology specification. An example of such a mechanism is Multiple Registration Protocol, (MRP). MRP allows participants in a MRP Application to register attributes with other participants in a Bridged Local Area Network. Two Applications are defined allowing registering VLANs (MVRP) and Group MAC addresses (MMRP). Other technologies may rely on mechanisms that operate at the Application layer such as Internet Group Management Protocol (IGMP).

Summary

MEF services are defined in an abstract manner that is agnostic to the specific technology implementing them. However, these services impose specific requirements on the underlying technology such as the MEF Carrier Class Requirements e.g., scalability and reliability and the need to confine flooding of MAC addresses only to UNIs associated with the given EVC, to name a few.

MEF Services are delivered over the TRAN Layer. Specific technologies aiming to implement the transport layer functionality must carefully evaluate the MEF architecture and services requirements. The services must be carefully overlaid over the specific technology's functional components.

MEF services can be implemented with both connectionless and connection oriented technologies. However, care must be taken to identify and mitigate potential conflicts between MEF requirements and the functional components of the selected technology.

References

[1]   IEEE 802.1D - 2004, “Media Access Control (MAC) Bridges.” June 2004.

[2]   IEEE 802.1Q - 2003, “Virtual Bridged Local Area Networks.” May 2003.

[3]   IEEE 802.1ah, "Virtual Bridged Local Area Networks, Provider Backbone Bridges"

[4]   IEEE 802.1Qay, "Virtual Bridged Local Area Networks, Provider Backbone Bridge Traffic Engineering"

[5]   ANSI T1.105 "Synchronous Optical Network (SONET) - Basic Description including Multiplex Structure, Rates, and Formats". 1991[6]   ITU-T Recommendation G.707, "Network node interface for the synchronous digital hierarchy (SDH)". 1993

[7]   Metro Ethernet Forum, MEF 4, “MEN Architecture Framework – Part 1: Generic Framework.” May 2004.

[8]   Metro Ethernet Forum, MEF 12, "Metro Ethernet Network Architecture Framework Part 2: Ethernet Services Layer", April 2005.

[9]   Metro Ethernet Forum, MEF 10.1, “Ethernet Services Attributes, Phase 2.” November 2006.

[10]  Metro Ethernet Forum, MEF 6.1, “Ethernet Services Definition, Phase 2.” June 2008.

[11] IETF RFC 4664, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", L. Andersson, E. Rosen.

[12] IETF RFC 4379, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", K. Kompella, G. Swallow.

About the Author

Written by:

Yoav Cohen

 

TrackBack URI for this entry

Comments (1)

Subscribe to this comment's feed

...
written by binny jeshan , April 30, 2010

Thanks Yoav.

report abuse

vote down

vote up

Votes: +1