MEF GEN14 update

It’s been more than a year since I wrote my last blog post. I was busy with other work (office, teaching, speaking, reading, traveling, advising, consulting, family…. ) and couldn’t really find a time to write something, though I had lot of things to share. However, I kept on my micro-blogging activities on twitter as usual. This post is actually a summarization about Metro Ethernet Forum (MEF) Global Ethernet Networking (GEN) 14 (MEF GEN14). 

I attended the 1st ever MEF GEN14 conference from 17th to 20th November 2014 at Gaylord National Resort and Convention Center at National Harbor waterfront entertainment district, located eight miles south of Washington DC, USA. On 17th, I had the privilege of attending the MEF Certified Professional’s convention as a guest resource person. Together with Marjory Sy (Carrier Ethernet Technical Lead, PLDT) and Sendang Praptomo (Telin, Singapore), I participated in the panel discussion ”Evolution of the Carrier Ethernet Professionals Community”. The panel was moderated remotely Dr. Vishal Sharma (Metanoia) together with on-site support of Daniel Bar-Lev (Director Certification/Strategic programs, MEF). The unique thing was that all of them are members of the LinkedIn Carrier Ethernet Group. 

I too had the privilege of listening to Prof. Bob Matcalf’s (Ethernet Inventor, 3Com founder and University of Texas, Austin Professor of Innovation)  keynote on 18th and later meeting him. In his keynote, he opposes net neutrality and talked about Freedom Of Choice Among Competing Alternatives (FOCACA) specially on the NFV and SDN choices. 

The Third Network concept was explained by Nan Chen, President MEF based on Network as a Service (NaaS) principles. Carrier Ethernet 2.0 (CE 2.0) provides assured Quality of Service (QoS) and security. It lacks agility. Internet on the other hand provides on-demand, ubiquitous services without any service assurance. Third Network tries to bring the best of both worlds by providing agility, assurance and orchestration. 

Software-Defined Networking (SDN) and Network Functions Virtualization (NFV) 

As any other conference these days, SDN and NFV played a big role throughout the conference, at leats using the words "SDN" and "NFV" :-) . It was mentioned by one of the speakers that Google manages ~10,000 servers with 1 guy and for a telco its 10 servers managed by 1 guy, which was seen as inefficient. With lots of things discussed about SDN and NFV, somebody viewed the whole thing as Software Defined Operator (SDO) meaning a combination of Internet Protocol (IP), SDN and infrastructure cloud NFV in telco environment.   Software Centric Network (SCN) was another name given to the combination of SDN and NFV. With everyone's talking about SDN and NFV, the question arises: Is software good and hardware bad?”. Almost all viewed SDN as a concept and not as a technology. SDN brings in control and automation, NFV brings cloud to the network, Carrier Ethernet sits in the heart of the access network and Data Center (DC). The financial guys questioned the economic model of SDN and NFV. For some of the participants SDN was "Still Don't Know".

The importance of having a single orchestrator communicating with multiple domain controllers was highlighted. Neela Jacques from Open DayLight shared his thoughts on open SDN and explained that Open DayLight is a community trying to build a common code base. Their charter looks similar to that of Open Networking Foundation (ONF), both talking about the importance of a single entity NOT getting the control of SDN. Cisco explained MPLS-SR (Multi Protocol Label Switching - Segment Routing), showing a halfway SDN migration approach. Going open source and using proprietary SDN was also discussed in the view of vendor lock-in. It looks like having a vendor is also beneficial, if it brings win-win situation. 

While there is a clear shift seen in the industry where operators are moving to IP/Ethernet services/networks from (Time Division Multiplexing) TDM services/networks, it was noted that Ethernet Operation, Administration and Management (OAM) needs improvements compared to TDM’s mature OAM.  Since IP is the end -to-end protocol, it was mentioned that all telecom services can be delivered via IP networks and should be: “everything on IP and IP on everything”. Fiber optics, Dense Wavelength Division Multiplexing (DWDM), Ethernet, IP, MPLS are considered IP helper technologies. In this situation, Open-IX highlighted the importance of having standards for IX/IXP operators. 

In the conference, the current market trend from customer perspective was identified as; on-demand, self-service, elastic, pay-as-you-go/grow and ubiquitous service requirements. It was mentioned that user experience matters in selecting a telecom services like a doctor is selected based on affability, ability and availability. What the telcos really need is something like the Burger King model: Have it your way, where as some operators still look to be operating on other models.

On the mobile and Mobile Backhaul (MBH), it was mentioned that MEF currently doesn’t support Common Public Radio Interface (CPRI) on the front haul. It was also mentioned that MEF22.1 doesn’t address Time of Day (ToD) and phase. This will be addressed in MEF22.2 in the future. 5G was explained by Ericsson as using frequency above 3 GHz (up to 100 GHz) from 2020 to 2030 time frame and coming back to less than 3 GHz frequencies after that. 5G is expected to reduce (compared to 4G) the control traffic  and will introduce the current User Equipment (UE) multi-site connectivity to a multi-layer connectivity. In summary, 5G was viewed as a combination of 10 m cell radius, 1 ms over the air latency, licensed and unlicensed spectrum, 10 Gbps on the air interface requiring Tbps backhaul bandwidth requirements. 

On the video side it was mentioned that 4K video needs 3 times the bandwidth of High Definition (HD) video. Together with big screens it generates even more bandwidth to telco network. On handling bandwidth, it was mentioned that telcos, out of the 2 options (increase bandwidth, optimize bandwidth) have chosen increasing the bandwidth (building capacity) over the years. With regard to meeting the bandwidth requirements, Google fiber, was viewed more as a measure to scare the telecs to build the bandwidth and not that Google really wants to build fiber networks. 

The exhibition area of the GEN14 conference was really good with the participation of lot of vendors and operators. The demonstrations were more on how to use SDN, NFV, orchestration, SDN controllers etc. to achieve more programmable service assurance and fulfilment for telcos, not necessarily for Carrier Ethernet services, but in general for all end-to-end services. Even the vendors like Juniper, who are much strong in hardware, demonstrated NFV (Virtual Customer Premises Equipment (vCPE)). The impact of latency was questioned by the audience. 

The key takeaways of the conference, as explained by Stan Hubbard, MEF GEN14 Program director on closing remarks are; 

1. Third Network 
2. Lifecycle Service Orchestration (LSO) (LSO runs from service catalogue to usage)
3. LSO/SDN/NFV: 3 pillars 

However, I believe that was more from the MEF perspective. On a much general perspective, though the conference discussed about many topics, it looked to me that less was spoken about Carrier Ethernet but more was discussed on challenges faced by the industry in general in doing efficient, effective, productive and profitable business. With SDN, NFV, Cloud and virtualization, lot of things were discussed on how to use these concepts/technologies to achieve those goals.

Circuit to Packet and back to Circuit

In early days when most of us were not born,
operators built TDM (circuit) networks and offered data (circuit) services to customers.
Because customers wanted data(packet) services,
operators built IP/Ethernet (packet) networks.
Now customers ask for circuit like services again.
But, operators can’t build circuit networks again.
Operators have no choice than allowing circuit like services flow in their packet networks.

By Anuradha Udunuwara

25 March 2013, at home.

It’s been 3 weeks since I faced that accident. An accident changed my entire life. I died, almost,  on 4^th March 2013. The good news is I’m alive and recovering quickly. After spending 2 days in the hospital, I was discharged and asked to rest at home for 4 weeks. That’s a full month. I have never stayed (to best of my memory) at a hospital as a patient in my whole life, though I have stayed with my wife when she delivered our 2 kids. I have never stayed at home for this long in my whole life. I never thought, I will have to. But, now I think it happened for a specific reason and love the rare opportunity I have been given. I don’t want to explain the accident part of it, because it carries no meaning to me, at least. Those who read this can get an idea about the nature of it, just by thinking the time given me to rest.

I never thought of writing this. But spending at home made me write this today, after exactly 3 weeks from the incident. I was a frequent user of fixed telephony, mobile telephony, mobile Internet and fixed Internet for the last 10 years. But, for the last 3 weeks, I got fully disconnected form that digital world, except answering few telephone calls from my home phone or my wife’s phone for urgent matters. That again after 2 weeks from the incident. I lost my phone in the incident and I never wanted to buy one. I never had an Internet connection in my home and I still don’t have. We never had a television in our home (we came to our home in July 2008). I may probably update this writing in my blog, when I get a chance or I may not do that. I’m just writing this to record an important incident in my life. There have been other important incidents in my life and I have never recorded them in writing. I have photo and video records of most of them and many of my friends have seen them in facebook.

So, what did I do for the last 3 weeks? I slept. I ate. I spent time with the friends and relatives who came to seem me. I intentionally don’t call them visitors, because they are not. I realized later that I have had only friends and relatives in my life and no visitors. After 1 week, I started reading and watching movies on my laptop. I started listening to some sermons of Venerable Kiribathgoda Gnananada Thero, I had in my laptop. If it is not for this accident, I may have never listened to those in my entire life. Those sermons helped me a lot to understand “life” and the real purpose of “living” it.

I realized that the life of mine and the others continued to roll despite me staying at home. My wife spent 2 weeks with me at home, even without sleeping at night. Rather than feeling sorry, I really admire, respect and honor the great courage she had as a women to face the situation. I had the great opportunity of understanding the iron lady within her. I’m also happy to see the way my 2 kids faced the situation. I still remember the way my 4 year old daughter cried when I came home from the hospital. Since then she wanted to whisper a secret to my left ear. I did not allow as the doctors advised me to protect that side of the head for some time. I still remember the joy she had, when I finally allowed her to do that after 2 weeks. Only then I realized that she really wanted to check whether my wounds are healed fully. My son brought a silver medal from his school sports meet, when I was at home. My wife goes to work as usual now. My 2 kids continued their schooling. But when all of them are out in the morning, though my father-in-law and mother-in-law are with us, I felt a big loneliness. I converted that loneliness to look in deeply in to my life. The life I have been living. We, including many of us in this world, are running like dogs, day and night. We never stop. We have no time to look at life, but rather we spend the life, without knowing what rally it is. Like very few in this world, I got the chance of “stopping”, at least once in my life, to look in to the life deeply. I really appreciate that opportunity I have been given. My only worry now is, whether I’ll join the same dog race, once I start working from 4^th April. I wish I’ll not.

I basically learned 2 things as a result of the incident I faced 3 weeks ago.

1.      You can lose your life at anytime, anywhere, any way.

2.      You need to earn more friends and less money.

I’m glad that I faced the 1^st one and experienced it. I’m also glad that I’ve been practicing the 2^nd in my entire life. I also realized that some small things, like spending time with kids, helping them to learn things, at least spending few minutes with parents (both yours and your spouse’s) , etc. are of high value and you only realize when you are unable to do those. I got attached to my family, relatives and friends more than ever and feel the results especially from my wife and kids. 

I have seen my relatives die. I have seen my friends die. I have seen my relatives get sick. I have seen my friends get sick. Though I knew that it’s common to everyone, I never realized it this deep, until I myself faced it. When life is so uncertain, every moment is so important and valuable. Time gone is gone. You can never recreate lost time. You can never recreate lost moments. 

I’m going to end this now. If I ever publish this in my blog, sorry if it is not the type of writing you expected from me. One thing at last, it’s not worth the risks we take with life. Never be hurried to anything. Take your time. Be focused. Never lose your mind.

Thank you for reading. I wish you all will understand “life”.

Anuradha Udunuwara 2.0

P.S: 2.0, because, I believe this is my 2^nd life.

Why should you select EoMPLS as the technology of choice for a green field CE deployment?

Introduction

Assume a Communication Service Provider (CSP) who does not have an aggregation network between the access and core. The CSP wants to use Carrier Ethernet (CE) technology to build the aggregation network. The CSP, most of the CSPs, intends to deliver/transport/aggregate the following services/traffic across the Carrier Ethernet Network (CEN) in an End-to-End (E2E) Internet protocol (IP) oriented architecture supporting the current and future demands;

o   Enterprise and corporate data services

§  Layer 3 Virtual Private Networks (VPN)

§  L2 VPN

§  L2 Point to Point (PP)

o   Consumer services

§  IP Television (IPTV) (multicast TV and unicast Video on Demand (VoD))

§  Broadband Internet

§  IP Voice

o   Wholesale services

§  Mobile backhauling

§  L2 VPN

§  L2 PP

IP/Multi-Protocol Label Switching (MPLS) has been a field proven technology and assume, like most of the CSPs, this CSP also has for the past several years implemented an IP/MPLS based core network and has built a team of experienced staff.

Options

To deploy a new CEN technology, the CSP has the following technology options available.
 

Feature	Provider Bridging (PB) / QinQ / Institute of Electrical and Electronic Engineers (IEEE) 802.1ad	Provider Backbone Bridging (PBB) / MAC in MAC / IEEE 802.1ah	PBB-Traffic Engineering (PBB-TE) / IEEE 802.1Qay	MPLS-Transport Profile (MPLS-TP)	IP/MPLS	Ethernet over Synchronous Digital Hierarchy (EoSDH)
Control Plane			Centralized Server	Centralized Server	MPLS	Centralized Server
Provisioning	Command Line Interface (CLI),  Element Management System (EMS)	CLI, EMS	EMS/Network Management System (NMS) only	EMS/NMS only	CLI, EMS	EMS/NMS only
Multipoint support	Yes	Yes	Yes	Yes (with VPLS)	Yes	No
Media Access Control (MAC) learning	CSP needs to learn all the MACs	reduced MAC learning	Not automatic	Yes (with VPLS)	Yes (Virtual Private Local Area Network (VPLS)	N/A
Protection	Spanning Tree Protocol (xSTP)	xSTP	Ethernet Ring Protection Scheme (ERPS)	Not mature Note 1	50 millisecond (ms), ring/mesh	50ms, ring
Operation			SDH like	SDH like		SDH like
Addressing scheme	Ethernet	Ethernet	Ethernet	different	Ethernet	N/A
TE	Poor	Poor	Good	Good	Good	Poor

Note 1: RFC 6372 (MPLS-TP Survivability Framework) released on September 2011

Feature	PB / QinQ / IEEE 802.1ad	PBB / MAC in MAC / IEEE 802.1ah	PBB-TE / IEEE 802.1Qay	MPLS-TP	EoMPLS	EoSDH
Maturity	High	Low	Low	Low	High	High
Interoperability	High	Low	Low	Low	High	High
Scalability	Low	High	High	High	High	Low
Separation of customer networks	High	High	High	High	High	High
Vendor stickiness	Low	High	High	High	Low	Low

Standard Defining Organizations have already published several standards for the IP/MPLS based CENs considering the current and future IP oriented service requirements. Following are some of the recent standards;

o   Broadband forum’s TR-221 (Technical Specifications for MPLS in Mobile Backhaul Networks)

o   Broadband forum’s,  WT-224 (MPLS in Carrier Ethernet Networks)

IP/MPLS in the CEN is required to support IP VPN and IP multicast features to support 4^th Generation (4G) mobile services such as Long Term Evolution (LTE) (all IP architecture).

To deliver the above mentioned multiple services on a single CEN with required service features, IP/MPLS is the most suited and matured technology. It is also needed to inter-op with the CSPs existing IP/MPLS core, especially for E2E seamless services.

It’s also noted that most of the access network uplinks are Ethernet or becoming Ethernet, while SDH/Plesiochronous Digital Hierarchy (PDH) networks are becoming outdated and obsolete. Hence investing on SDH is pointless.

Recommendations

Among many others, following are the most important recommendation for the CSP.

• The CEN shall be Transmission Agnostic.
• Aggregation of topology - to reduce the numbers of physical interfaces required at higher levels of the transport / switching hierarchy.
• Consolidation of network and transport protocols - to reduce the complexity of logical interfaces required at higher levels of the transport / switching hierarchy.
• To have different traffic types physically and logically aggregated, so that they can be transported by the Core Network.

• Development of CEN shall be closely mapped to service development strategy.

• The CEN shall be EoMPLS based.
• When selecting an CEN site, following shall be considered;
• number of access nodes in proposed topology
• total bandwidth demand and future bandwidth forecast that has to be aggregated and carried
• cost of alternate aggregation options and possible service impacts in a failure or other adverse condition
• All the network elements of different switching capacity and network shall have high availability features.
• The service delivery architecture within CEN shall be layer 2 based except for multicasting which shall be IP multicasting. However layer 2 multicasting features shall be available for customer multicasting services.
• The services and equipment shall be certified with Metro Ethernet Forum (MEF).
• Virtual Routing and Forwarding instance (VRF) shall not be brought to CEN level, unless it’s required for 4G Radio Access Network (RAN) backhauling (LTE) in the future as specified in Broadband forum TR-221.

CEN Requirements

Any CEN architecture needs to support key requirements of availability, stability, Quality of Service (QoS), performance, multicast support, Time Division Multiplexing (TDM) support, management and security. In the context of an EoMPLS based CEN,  that translates to what is explained below.

Availability (Resilience)

Since the CEN interfaces with the access layer, the resiliency is a key factor to avoid service outage due to the node failure or link failures. This is achieved by adopting multi-homing topology for the interconnection between CEN and the service edge network as well as the CEN and access layer where feasible. However, in order to avoid the complexity of the CEN, not more than two connections towards service edge network is recommended. Network side connections used for multi-homing requirements shall be terminated on physically separated line modules.

Equipment/node level high availability shall also be employed to ensure service and network availability due to failure of critical hardware and software modules of the CE node. The following redundancy mechanisms shall be available in all the network elements of CEN.

Hardware Component of CE Node	High Availability  mechanism
Route processor	1:1
Switching fabric	1:1
Power supply	1+1 Note 2
Power feed	1+1 Note 2
Cooling system	1+1 Note 2
Any other control plane module	1:1
Any other switching plane component	1:1

Note 2:   single component shall be able to take the full load of the CE node

The network shall use International Telecommunication Union-Standardization (ITU-T) G.8032 version 1 & 2 (ERPS) wherever possible to achieve sub 50ms protection and recovery for Ethernet in ring topology in case of a node or network failure.

Following software level high availability features shall be implemented;

• Non Stop Routing (NSR) for
• Label Distribution Protocol (LDP)
• Resource reservation Protocol (RSVP) TE
• Border Gateway Protocol (BGP)
• Open Shortest Path First (OSPF)
• Protocol Independent Multicast-Sparse Mode  (PIM-SM) and PIM-Source Specific Multicast (SSM)
• In Service Software Upgrade (ISSU)

Bidirectional Forwarding Detection (BFD) requirement shall be analyzed for following in the future stage

• LDP
• RSVP
• BGP
• OSPF
• PIM-SM and PIM-SSM

Non Stop Forwarding (NSF) requirement shall be analyzed in future stage.

Stability

Stability of the CEN and its Network Elements (NE) are very important. This should ensure consistent performance of the NE. Mean Time Between Failures (MTBF) and Mean Time To Repair (MTTR) values shall meet 99.999% node availability requirements.

QoS

CE QoS model is essential to provide dynamic quality of service feature without overbooking the bandwidth for applications. It should be able provide better service to selected traffic, depending on the individual requirements of different types of service and also to meet requirements in customer Service Level Agreements (SLA).

The CEN shall be able to handle Layer 2 (802.1Q), Layer 3 (Differential Services Code Point (DSCP)) and MPLS (Experiment (EXP)) QoS/Class of Service (CoS).  The CEN/NEss need to support classifying, marking, remarking, scheduling, shaping and policing for all the above QoS/CoS models at all egress and ingress ports whether access side or network side. Within the CEN, the nodes shall be able to support at least 4 hardware queues for traffic per port. The control and management traffic within the node shall be handled separately from the user traffic. Hierarchical QoS shall be analyzed in future stages.

Performance

Scalability of the CEN determine by providing sufficient bandwidth to be able to guarantee a committed level of performance for the full service portfolio of end users. CEN design to achieve the certain QoS requirements/Key Performance Indicators (KPIs) defined with the set of services/products. The CEN must be able to handle unpredictable surges in traffic, and appropriate load. The network utilization has to be maintained within 70% to facilitate the introduction of services and for the unpredictable surges in traffic.

Multicasting

To support IPTV and other multicast applications, the CEN shall support IP multicast protocols.  Layer 3 based (PIM) multicast technology is preferred over Layer 2 technology for scalability and flexibility reasons. Layer 2 multicasting features shall be available for customer multicasting services.

Supporting TDM services

TDM services shall be supported in the form of Circuit Emulation Services (CES) using Synchronous Ethernet (EtherSync/SyncE) or IEEE 1588v2 for frequency and time of day synchronization. At least E1 and STM-1 CES shall be supported. Enabling CES shall be done if the no. of TDM services few compared to the Ethernet services. If not, separate TDM equipment shall be used.

Management

All the CE elements should be able to address the management domain requirements. The standard functional entities such as: Fault management, Configuration management (Fulfillment support), Security management, Performance management and Inventory management on all Network Nodes will be required.

For service management, the network and the nodes shall support following Ethernet Operation Administration and Maintenance (OAM) standards;

• IEEE 802.1ag (Connectivity Fault Management (CFM))
• IEEE 802.3ah (Ethernet in the First Mile (EFM))

Security

The CEN addresses the security which provides confidentiality, integrity and availability of specific services. The following areas have been identified and will be equipped with necessary security mechanisms,

·         Node security

·         Access security

·         Interconnection security – User to Network Interface (UNI) and Internal-Network to Network Interface (I-NNI)

·         Protocol security – UNI and I-NNI

Standardization

MEF, the Broadband Forum, Internet Engineering Task Force (IETF), IEEE and ITU-T are the main Standard Defining Organization (SDO) with regard to the CEN.

The EoMPLS is a field proven and matured technology in implementing CENs. Though the standards are available, CSP needs to standardize this architecture and protocols. All the future network developments and deployments in the future need to align to these.

It is recommended that CSP get involved with these SDOs, especially the MEF and the Broadband forum. It is also recommended that CSP get the MEF certification for its services (E-Line, E-LAN, E-Tree and E-Access) and use MEF compliant equipment in the CEN (MEF 9- Ethernet Services at the UNI, MEF 14- Traffic Management Phase 1). Click here to see the 5 CE attributes defined by MEF.