Introduction
The market and network evolution is changing drastically and moving extremely fast and I would add even too fast for typical actors of the market. Indeed, both communities in our industry, the Service Providers community (MNO, MVNO, ILECs, CLECs and CSPs) and the Enterprise community (Financial institutions, Oil & Gas, etc...) have been monetizing networks and IT services based on two very important aspects : Stability and consistency. Other important aspects have been put aside, perhaps to complex to tackle, such as CAPex decrease and OPex optimization mainly because of a very tight control of the market by vendors.
Therefore, the promises of Open Source driven possibilities and innovations were considered as new options for a faster churn of massive opportunities with SDN/NFV as tools to monetize Virtual Services of different kinds either leveraging VNFs (VM-based) and the promising containerized services (CNFs).
An open new world was suddenly available open to new possibilities and fantasies about networking solutions. However, as active actors of our industry we all rapidly understood that we can’t foresee the future without nurturing the past. Indeed, legacy solutions (IPv4/IPv6 based routing, MPLS-TE, VPNs (IPsec, GRE, L2TP, etc..) were challenges to be mitigated with new generation of technologies (Carrier-Ethernet and MEF services, MPLS-TP, EVPN, VXLAN and VTP, SDN-driven overlay services, NFVi and OVS/NSX/Flannel, VNFs & CNFs orchestration and automation).
As part of this new emerging ecosystem, bad habits are often hard to kill because when we mention Carrier-Ethernet our technology reflexes turn us towards MEF and IEEE. When MPLS is mentioned we obviously turned our mindset towards IETF (MPLS) & ITU (T-MPLS) now efforts of both sides have converged with similar targets and results. On the other side, TIP (Facebook Telecom Infra Project) is not yet well understood or known but deserve more interest notably for its work towards Networks disaggregation for 3G/4G/5G Mobile Service Infrastructure where ODTN (Optical Disaggregated Transport Networks) promises and SDN capabilities expect to be fully leveraged. Once again, you will notice through the mention 3G/4G and 5G the need to make sure that legacy capabilities are cared for.
As you will read, the disaggregation or distribution of the service infrastructure is the very key element leading to 5G evolution and other transformation effects of the layers and functions that are shaping our industries nowadays. Let’s explore together then how two massively influential and new breeds of SDO such as MEF and TIP, could eventually be of interests to our industry and what changes would they unleash to our global market and industry.
Ultimately, if combined what could they do for us ?
What MEF and TIP could bring when combined for disaggregated networks ?
What is TIP (Telecom Infra Project) ?
TIP has been initiated by Facebook and hundreds of Service Providers and vendors have now joined this initiative group. Freshly created in 2016, the main goal of TIP has been to bring to surface all the necessary ingredients and functions to accompany the evolution towards new generation of mobile network infrastructure,, which could allow to take advantage of multiple elements notably :
Network foundations
(ODTN / Carrier-Ethernet / MPLS-TE & MPLS-TP / IP legacy services including even PWE3 tunnels) ;
Mobile backhaul and Clock Distribution and Synchronization
(Carrier-Ethernet / EVPN / Carrier-Ethernet and IP OAM / Synchronous Ethernet & IEEE 1588v2) ;
SDN and Service Orchestration capabilities (Netconf + Yang / PCEP / Segment Routing / BGP-LS / TOSCA)
Monitoring and Management (SNMP / Traditional ZTP or over Netconf / Service Assurance over Carrier-Ethernet OAM / Protection mechanisms automatic activation OAM triggered (G.8031 / G.8032 / Fast-Reroute + BFD).
Virtualized Functions or Services MPLS / IP-based services / vRAN / vIMS / vEPC / vRouter / SD-WAN & SD-Branch/Edge Computing and Open possibilities between RAN and RF solutions.
Yes, it is indeed a very dense list but also meant to bridge the legacy world (3G/4G and 5G) and the new world towards SDN & NFV based services leading to Disaggregated Networks & functions with Service orchestration & automation.
What is MEF (Metro Ethernet Forum) ?
The MEF (Metro Ethernet Forum) is born in 2001 as a standard body meant to make Carrier-Ethernet technologies to become ubiquitous across the market : Cable, Fiber, Copper and even wireless. Contrarily to other Standard bodies such as IETF, ITU or IEEE which are mostly driven by vendors.
Similarly, MEF is also mostly driven by Service Providers of any kind and supported by vendors. But, the most important element is that the MEF is filling up the cracks in our industry. Instead of technology specifications, they reuse these specifications to define service specifications.
These service specifications serve operators and enterprises to better anticipate and more clearly define guidelines how to establish P2P (Point-to-Point) aka E-Line, MP2MP (Multipoint to Multipoint) aka E-LAN and P2MP (Point to Multipoint) aka E-Tree. These service types are accompanied by three important definitions : UNI (User Network Interface) / NNI (Network-Network Interface) and EVC (Ethernet Virtual Circuit).
MEF has released a number of key service specifications, which has changed dramatically the way that services could be provided intra or between service providers, amongst which different categories exist : MEF Service Definitions / Service Assurance and Service Activation / Yang Modules / Agility and Orchestration
Additionally, the MEF 55 (LifeCycle Service Orchestration) specification provides a great deal of details about a set of API interfaces identified as Northbound / Southbound / Eastbound and Westbound thought to ease the relations between the different service infrastructure layers required in SDN/NFV : NFVi / Orchestration layer functions / Automation customer portal / OSS-BSS / SDN NNI towards another operator.
As shown above, through the MEF 3.0 initiative called Lifecycle Service Orchestration. This MEF Service specifications has been defining guidelines to accommodate new layers to collaborate seamlessly. This allows new service approaches for Optical, SD-WAN, SECaaS and other specifications to be leveraged from a comprehensive global perspective of vertical and horizontal APIs
WHERE DO TIP AND MEF CONVERGE ?
When diving into both of TIP work and MEF, It looks that there are trying to fill the cracks into the forgotten aspects of services nonetheless fundamental to define and provide services between service providers, which have their own respective service infrastructure. Also, unlocking the necessary changes to ease collaboration between market actors.
Market collaboration and competition has been and will remain, at the heart, of what operators do between them for the benefits of end-users. What is then common between TIP and MEF ?
Service Assurance-based connectivity
Amongst legacy and latest generation of technologies, only those that supporting the inherent capabilities towards OAM (Operations & Management), traffic restoration or protection mechanisms and services aggregation and convergence but also differentiated services support aka Class of Services (CoS), have been declared market successes.
Therefore, MEF and TIP both converge on various technologies that are supporting the necessary ingredients to leverage Carrier-Class technologies and this over different layer technologies.
From the Layer-2 standpoint, Carrier-Ethernet has been the foundation technology of the MEF and has become THE de-facto technology as a transport mechanism with EFM ( 802.3ah aka Ethernet First Mile), CFM (802.1ag Connectivity Fault Management) and Service OAM (ITU-T Y.1731 for CFM & Performance Monitoring) capabilities, coming mostly from the IEEE and ITU-T standard. Leveraging IEEE 802.1 standards such as 802.1d, 802.1ad (Provider Bridging with C & S-tags), 802.1ah (Provider Backbone Bridging aka MAC-in-MAC) and 802.1Qay (Provider Backbone Bridging - Traffic Engineering). Equally important, Carrier-Ethernet is leveraging service OAM capabilities to support protection mechanisms with linear protection (G.8031) and ring applications (G.8032).
On the Layer-3 level, MPLS-TE (RFC 2547bis and 4364) has reached the level of undisputed technology of choice for any network of scale to guarantee customers logical segregation using both VRF and MP-BGP extensions and, CoS support. Despite, it's long existence, IP and MPLS has evolved to be the best guarantee to support legacy technologies such as pseudo-wires tunneling technologies (Martini / Kompella) methodologies while maintaining the validity for IPv4 and IPv6 routing services. Despite, obvious interests, inherent limitations (PHP ; Unidirectional LSPs ; ECMP ) have prevented end-to-end OAM mechanisms to be fully adopted. Instead, BFD (Bidirectional Forwarding Detection) has been largely used to overcome the unidirectional nature of MPLS and perform below 100ms rapid failure detection. VPLS, on the other side, provides a layer-2 bridging dataplane capabilities while using a Layer-3 Control Plane-based networks to perform networks node discovery and pseudo-wires establishment.
Searching for technologies that fit in-between L2 and L3, it is very interesting to notice that new emerging technologies such as EVPN and MPLS-TP are leveraging both layers with potential great benefits but from a different angle of approach.
Ethernet VPN (EVPN) comes from the layer-2 standpoint by supporting VXLAN/VTP for virtual bridging capabilities. However, EVPN bridges can also extend Layer-2 circuits by interconnecting with Provider Edge nodes using either BGP/MP-BGP or even pseudowires tunneling. EVPN provides naturally all ingredients to support MEF services and beyond with Layer-3 options.
MPLS-TP (RFC 6372) is the result of an active collaboration between IETF and ITU-T started because of a war of naming about the name MPLS. On the opposite side, MPLS-TP leveraging multiple elements from various layers :
* LMP from GMPLS and Optical layer, as a configuration and management protocol for optical devices SDH/SONET and even WDM
* MPLS-TE Control Plane from Layer-3 but capable of supporting bidirectional LSPs
* Meant to leverage natively Carrier-Ethernet OAM capabilities to monitor Pseudowires, MPLS tunnels (LSPs).
As you can naturally point out, there is a strong convergence towards a need for legacy technologies such as pseudowires, ubiquity of MPLS (L2 or L3) and a growing and recurrent need for MEF services combined with OAM capabilities.
Are my DC or Edge Computing whiteboxes and NFVi choices still matter ?
Most of the times, the first steps leading towards the monetization start with the installation of functions on a bare-metal approach onto whitebox HW solutions. Then, the following steps lead towards the selection of a valid choice of a NFVi solution meeting all the Service Providers or Enterprises criterias, which are kind of common elements amongst market actors : cost-effectiveness, stability, referenced solution, VNFs & CNFs support capability and wide openness towards VNF solutions support from a wide choice of vendors. It is generally at this stage where headaches start…
In today’s market, it exists as much choice of NFVi as it exists shampoo choices in your local supermarket (shaving my head now saves me from this now). More seriously, OpenStack releases choice (Juniper, RedHat now IBM, Canonical, WindRiver, Oracle, Ericsson, Suse, Mirantis, ENEA…) has exploded in the past few years without mentioning the obvious players such as VMWARE, which was seriously challenged because of its supposed high-cost per socket. However, it’s been proven a non-stable, inability to work properly and inappropriate support would prove as costly as a proprietary solutions. Lately, the emergence and fast-acceptance and already ubiquity of Kubernetes & Docker have raised number of interests despite its limitations such as security and inability with Flannel to accommodate Telecom use-cases (luckily my friend Mohamed El-Serngawy has already proven a interesting solution, see here)
The main question is how proven my NFVi solutions is, how real-time my NFVi solution is and how much impact will this have when my overlay SDN instructions will reach my whitebox devices and how fast can these instructions be treated to ensure proper changes on my dataplane services!!?
These issues are extremely critical when the revenue model of a given enterprise or service provider is based on real-time/mission-critical services or simply how fast my customer choice made on my customer portal can get monitored to provide a satisfactory result in a given lapse of time (VNF instantiation / Tunnel creation / configuration change, etc..).
Can NFVi or virtual solutions exist without a platform to support them ? Whiteboxes for DC and Edge Computing revealed themselves equally important as the software stack running on top of them to ensure stability, scalability, manageability, but above all else : power consumption decrease and high-service density. The debate around NFVi and Whiteboxes is long especially when the scale of today’s network require a disaggregation of network infrastructure from DC/CO, PoP to customer premises. This require a mental challenge and new perspectives and ideas towards how scalable my products need to be to accommodate changes in a rapid and business fashion way. Typically, question like vCPE vs uCPE / Xeon-Scalable vs Xeon-D vs AMD vs ARM / DC-centralized vs partially centralized and distributed or even fully distributed.
These elements naturally fuels a lot of legitimate interrogations about the service infrastructure regarding Edge Computing and MEC (Multi-Access Edge Compute) platforms to understand how service dense does it need to be ? Does vRAN and vEPC are packaged together ? Does the vEPC components get to be separated between the E-NodeB, Hub or/and CO ? What about IMS / CDN / Gaming Server ? How my service latency would be ? Will my SDN/NFVO be efficient enough to impact Dataplane as quickly as tested ? If i disaggregate my applications then my service intelligence shall follow ? Such questions can only be answered on a case by case scenario because each operator is, by definition, unique.
Finally, What software and which features need to be residing in my whitebox if I want to leverage either a virtual switch or an embedded physical switch. Which NOS (Network Operating Software) will dominate the others ?
The battle of NOS, which impacts on the Service Orchestration functions ?
As per the previous paragraphs, i highlighted the necessity to nurture legacy solutions as well as the latest generation of solutions that will drive our industry onto the path of constant evolution without breaking it. However, as a lot of whiteboxes in the market support natively embedded switches as part of their HW responses. Then, it brings the question of the features brought by those switches and which embedded software will reside in it.
Due to a growing level of changes at various levels, we now know that all questions won’t be answered through virtual services. Instead, it requires a stable answer for NOS solutions with guarantee of legacy services support and new generation of functions support. Therefore, a war of NOS has now started between DANOS, Cisco, Juniper, Huawei, Ciena, ADVA and other independent NOS players (Metaswitch / Mellanox / IP Infusion or Cumulus Networks, etc…) to provide both the features/functions density and the assurance of Open-Source capabilities (Netconf/Yang). Potentially, with ONIE (Open Network Install Environment), there should no limitation about which NOS could be supported upon any whitebox either proprietary or Open-Source based.
Most of you must be surprised to read that a range of players are arming themselves to position themselves or have by their dominant position already positioned themselves as the de-facto market standard NOS in the market. Therefore, why NOS are so important ?
In order to take advantage of SDN-based fonctions any NOS vendors must build both a Yang model and Netconf structure to allow either their own SDN/NFVO function or Open-Source SDN/NFVO function to leverage their NOS option. More market importance, a NOS takes and greater the risk is to see the influence and effect of the lock-in effect on customers might be. Naturally, the same negative influence can easily be imagined when a given virtual service is not onboarded in a given NFVO function to favor the solution pushed by the NFVO vendor.
Therefore, it is very important that Service Providers or Enterprises maintain a certain of independence despite of the accelerated access to revenues when selecting proprietary solutions.
Is SDN (ODL/ONOS) so obvious nowadays or can NFVO at the Service Orchestration layer do better ?
As per my last week paper (Is there a future for SDN apart from NFVO), the question increases in interest considering the concentration of interests concerning the Service Orchestration layer. Indeed, with the wide array of possibilities unveiling before us in the market either at the NOS level and derived legacy features highly expected as well as the new ones, at the physical and virtual service layers (PNFs, VNFs & CNFs) supported by NFVi/VIM software layers finally encompassed by the necessity of creating hybrid Service chains . The question should be, where can we bring simplicity, readability and manageability to all this.
To me, in order to faster accelerate the access to revenues for SDN/NFV is somehow to reduce complexity. And, what better ways then to compress services and expectations into a single variance of function at the Service Orchestration layer with the NFVO. Separating SDN and NFVO doesn’t deliver anything near of reducing complexity but increases it while fundamentally slowing down access to revenues and return on investments. The best example of all is actually SD-WAN…
While SD-WAN is considered as a monolithic solution and fundamentally separated from the SDN/NFV building blocks. But, both SD-WAN and SDN/NFV related services converge over a unique service point of reference aka the NFVO function under a common RestFul API structure, orchestration capabilities, Netconf SFC & Yang model and eventually TOSCA templates. Would there be any reasons to believe that NOS solutions be any different ?
Will ODTN the layer dominate us all in the future ?
While the market is clearly transitioning itself towards to build capable networks to accommodate 5G Networks. Such networks bring natural questions about their inherent capabilities to cope with a fast-anticipated bandwidth growth which directly questions Carrier-Ethernet to provide the scalability required to sustain it, basically above 100G.
The combined promise of Optical + Ethernet was a constant reminder that in order to evolve towards packet-based services. Optical technologies needed to evolve from lambda-oriented to packet-switched networks with a native optical twist overcoming the limitations of a packet or frame-based technology.
Recent innovation such as ODTN from ONF, leverage the ideas that some SDN-based capability combined a common Transport API (TAPI) defined, validated and supported by major OTN vendors would lead to the Disaggregated of Optical transport. The link between packet-switched to optical-based underlay networks could be tackled by using technologies that share similar traits : Ethernet OAM and clock synchronization, MEF services support, BGP or MP-BGP compatibility, backward compatibility with legacy services but also forward compatibility with SDN-alike capabilities (Netconf / Yang / RestFul API).
What possibilities will open for you as Service Providers / Enterprises ?
The market is surely entering in a different phase of it's evolution where two sides will be visible.
One side will see typical vendors to maintain a certain pressure on their customers to associate both legacy and new services and technologies to hardware products. Therefore, maintaining the status quo as long as possible to keep the expectation of revenues as steady as possible. This is the definition of locking-in strategies.
The other side, will see a brave new world of innovative partnerships and collaboration of a new kinds between whitebox vendors, VNF & CNF vendors, OSS/BSS or Orchestration vendors bringing innovation and brilliant new ideas.
From this chaos, a new race of players will emerge : Solutions Service Integrators. Bringing a new type of knowledge notably making sure that all layers integrate and work seamlessly well together. They will maintain the evolution to be made possible while working in conjunction with customers, hardware and software vendors. A company like Datavision led by Mark Abolafia ( COO), represents extremely the ideal candidate with the type of required skills: diplomacy, finesse, technology maturity, humility but a solid confidence to understand what can be delivered and to keep tabs of what's required now, tomorrow and the day after tomorrow.
CONCLUSION
It is obvious that the evolution of our industry makes our market to be a very challenging and complex place to apprehend. We are entering into an era where a lot of evolutions brought by Open Source to be unlocking possibilities where proprietary solutions won’t be anymore the only options available but one of the many. We have to believe that all market actors generally come to the market with a given load of bagages (past investments) that might impact their transformation or transition and how quickly and how will they adopt any Open Source innovations as part of their changing service infrastructure. I fundamentally believe that the market will see its best results by combining proprietary solutions with Open Source innovations.
5G is expected to be the largest transformation that our market has never seen however I disagree in the analysis that this profound change will happen overnight. As the market expect the SDH sunset to be expunged in 2015, SONET & SDH are still technologies that are still in activity in North America, Asia and even Europe. Therefore, when we look at 5G we should observe that existing technologies such as 3G / 4G / MPLS / Carrier-Ethernet and other recent innovation are simply milestones that will help us to leverage Disaggregated Networks and 5G profound effect.
5G will not only propel our industry towards a new era of technologies but this will actually force to re-shape our complete view and understanding of network architecture and service infrastructure to make our solutions more efficient and more reliable.
Written by Luc-Yves Pagal Vinette