The Metro Ethernet Forum (known as MEF) has been defining Ethernet Service Architectures for a number of years and, in this author’s opinion, has done an excellent job of implementing achieveable standards that are designed to make Ethernet the de-facto transport and service technology Globally. From inception, MEF has been working tirelessly to define “Carrier Ethernet” and accelerate adoption of Ethernet as the ubiquitous service technology in Telecom. to For anyone who wants more information on the MEF should look here.
A true global telecommunications standard. This is the holy grail 
However there are challenges, not with the definitions (or the MEF) but with how those services are implemented by Carriers. These issues arise because we are in the middle of a technology shift from TDM based services to Ethernet/Packet based services. The inertia and in some cases the investment of legacy technologies is just too great to wholesale migrate to Ethernet overnight. We cannot supplant 50 years worth of core and access infrastructure without having a few hiccups along the way.
If we take a good look at how MEF services are being implemented by Carriers we see that there are two basic roots of the issues causing woes to Carriers here in Europe. These woes aren’t there because of MEF services but are now visible because those services have been implemented. I have had a number of conversations with Carriers in the last 6 months and there are a couple of common threads in the issues they are telling me about. One centers around how a Carrier should handle issues on Ethernet services when multiple carriers are involved and the other is more technical in nature regarding how some transport technologies aren’t so good at transporting Ethernet.
Inter Carrier Services
Inter Carrier Ethernet Services are, in essence, the MEF defined services that happen to traverse more than one carrier. Since all of these services run over Ethernet and use standards-based Ethernet enhancements there is, in effect, no interoperability issues between the carriers.
The main issue arises when there is a fault somewhere in any one of the participating Carriers’ networks that affect the customer service. Ethernet is a fantastic technology for this LAN type of service but is very bad at signalling faults or providing information about where a service disruption has taken place.
Furthermore Ethernet has no inherent demarcation capabilities in the sense of TDM demarcation. Troubleshooting tools like loopbacks, in-service testing and measurements aren’t readily available for MEF services without extra equipment.
This problem is especially nasty when the MEF service is E-LAN type service with many customer endpoints. As you can imagine, the manifestation of this issue becomes exponentially nasty the more carriers and more endpoints are involved.
In the end the result of any Inter-Carrier service failure is, usually, finger pointing amongst the carriers. With no clear troubleshooting and no clear service demarcation, “passing the buck” seems to be the only option without some serious investigation.
Transport Technology Mismatch
MEF Service definitions are, as said earlier, based entirely upon Ethernet. As we all know there are numbers of ways to carry Ethernet across the network and some of these are more Ethernet Friendly than others. Services built across network that utilize varied Ethernet transport technologies can be problematic. Since most carriers today have many different networks in many different stages of evolution, it is likely that a MEF service could be built simultaneously over native Ethernet, WiMax, Microwave, EoSDH(SONET) and IPVPN to achieve an end-to-end solution for a customer.
In the best case these transport technologies are Ethernet based, such as WiMax and WiFi and have relatively minor impact. The service issues experienced here are usually Ethernet QoS (COS) related and can be easily rectified with configuration of hardware, software or service.
Much more difficult issues arise when Ethernet is being transported over a technology that is fundamentally different in structure; Technologies such as SDH/SONET and ATM would fit into this category. Not only is Quality of Service a potential issue but so is the transport of certain types of Ethernet Frames that are fundamentally incompatible with the transport protocol(Jumbo Frames come to mind). These issues could lead to the inability to turn up a service or even worse prolonged outtages after a successful initial installation.
So what is the solution?
Obviously the best overall solution would be to demand that everyone use Ethernet over naive media and have the MEF with with the IEEE/ITU to develop and standardize transitive troubleshooting technologies. We all know how likely this is to happen
In tomorrow’s Blog Post I’ll talk about how to solve these issues with Ethernet Service Demarcation.
