Menu

EKINOPS en français

WELCOME TO

EKINOPS BLOG

EKINOPS helps to bring optical transport a step closer to SDN

tunel-2055970_1920

Guillaume Crenn, EKINOPS Product line & Marketing Director, recounts a recent technical breakthrough enabling legacy optical equipment to function in tomorrow’s virtualized networks.

Interoperability remains one of the biggest challenges facing operators seeking to software define their networks. Powerful new frameworks, like OpenDaylight (ODL), are needed to disaggregate and rearchitect the network and enable the level of automation and programmability that will, eventually, deliver virtualization’s ‘new age’ of flexibility.

Designed by the Open Daylight Project - a global, collaborative community of vendor and user organizations, of which EKINOPS is a part - ODL is a modular, open framework designed to enable commercial solutions to address a variety of virtualized network use cases, such as automated service delivery, Cloud and NFV, resource optimization and network visibility and control.

A critical hurdle to overcome on the road to enabling such uses cases is how to establish the level of interoperability between the network’s newly separated components and functions in such a way that they can be managed and orchestrated. This is a complex task that requires utilizing controllers for both northbound and southbound communication throughout the virtualized network.

In the world of optical transport, enabling this controller-based communication in ODL is the job of OpenDaylight TransportPCE, a collaborative project led by Orange, EKINOPS and Orange Labs whose work describes an open-source application running on top of the OpenDaylight controller. Its primary function is to control an optical transport infrastructure using a non-proprietary South Bound Interface (SBI).

See full post

Agility is the Goal and Lack of it the Handbrake

blog_agility

When looking at the virtualization landscape in its broader sense I can’t help seeing that the real problem is agility or rather lack of it.

Take a look at SDN, whose main premise is to separate control from the data plane and thereby achieve high agility for its users. Same thing for NFV: abstract the software from the hardware and then combine and deploy software functions at will for high agility. So the operators, at least the bigger ones who have the least agility, are investing megabucks to deliver on the twin promises of SDN and NFV. What’s frustrating for them is that they are doing so lamentably slowly and in a decidedly non-agile manner.

In a sense it’s not so surprising. In effect, the operators are trying to re-engineer 15 years of painstakingly built managed services processes in a very short period of time. And they are doing so using a combination of new operational and management techniques, new albeit commonly available hardware, re-packaged software and co-opting their existing set of waterfall processes and organisational silos. This is like pressing on the accelerator with the handbrake on. Some, e.g. Verizon and belatedly AT&T, are trying to loosen the rigid structure of their organisations to create a more agile decision-making process and a Devops culture where network specialists and IT folk combine to break down internal barriers and loosen their internal disk-brakes.

It’s when we take a look at the arrival of SD-WAN that we see the real impact of lack of agility. SD-WAN vendors position their wares to enterprises with self-select portals, centralised policy control and the ability to take advantage of cheaper Internet links to deal with all the Cloud-based, Internet services that are swamping their traditional operator-provided WAN connections. This puts control and thus agility in the hands of the enterprises and this is precisely what they want.

The response of the operators to SD-WAN however is telling. As opposed to SDN and NFV, where they are re-engineering their processes with open APIs to (slowly) deliver on the promise of virtualization, they have taken a very different tack with SD-WAN. For the most part, they have:

See full post

Keeping Satellite in the 5G Game

Keeping_Satellite_5G_Game

EKINOPS explores the intersection between virtualization, 5G and satellite communications, highlighting how a recent technology breakthrough will deliver additional value for satcom providers, CSPs and end-users alike.

5GPP, the EU body charged with establishing global consensus on the use of 5G, has been making strong progress in defining how the new connectivity standard can support a rapidly growing range of future use cases. Telecom operators, who will be required to make huge investments in replacing masts, antennas, base stations and other equipment to support 5G, are happy to wait for the body to publish its specifications. Satcom providers, however, are not. As things currently stand, satcom is not part of the 5G game and, as a result, its equipment and service providers risk being elbowed out of use-cases for which satellite is today’s de-facto choice.

From a commercial perspective, communication service providers (CSPs) know that their ability to support all types of network links gives them the flexibility to deliver bespoke solutions that maximise value for their customers. To this end, harmonising satellite with 5G makes a lot of sense, particularly where the technology can augment 5G services.

The range of situations that favour a satcom/5G solution is bigger than one might think, and extends beyond the infrequent, high bandwidth requirements of native satcom broadcasting, live sports stadium feeds and news broadcasting. Satellite also has a valuable role to play in areas where 5G networks have limited coverage, allowing 5G traffic backhauling to remote areas, for example, and complementing ‘slow’ terrestrial links thanks to multi-link technology and connections to mobile vehicles and planes.

Fortunately, this argument has already been recognised within 5GPP, and has given rise to SaT5G, an H2020 European Research project with the objective of designing next generation standards that make satcom 5G-friendly. The group is developing a cost-effective ‘plug and play’ satcom solution for 5G to enable operators and network vendors to accelerate 5G deployment in all geographies and, at the same time, create new and growing market opportunities for satcom industry stakeholders.

See full post

Orchestrating the network beyond the NFVI boundary

orchestrating-the-network-beyond-the-nfvi-boundary

A key promise of SDN/NFV is to enable service providers to offer innovative, on-demand enterprise services with unprecedented flexibility. Building a network capable of delivering flexible, dynamic, customer-tailored services, is however a challenge for service providers. As a matter of fact, end-to-end service orchestration within the virtualized infrastructure and across complex multi-vendor network domains outside the NFVI is anything but a walk in the park.

Standardization bodies, the acceptance of open source solutions and service provider led programs such as AT&T Domain 2.0, Orange SDN for Business or Deutsche Telekom Terastream have driven interoperability in the NFVI and MANO spheres. One major roadblock to capture the full potential of network virtualization is the orchestration of network elements beyond the NFVI boundary, in order to provide full service delivery automation across the network. Yet one key question is how can orchestrators work with networking elements outside the NFVI? As service providers look to transform their networks, the answer to this question is crucial in order to deliver end-to-end enterprise managed services.

The challenge for the orchestrator is to configure all the nodes in the service delivery chain from the customer premises to the NFVI and steer the traffic to the virtual service platform. This integration work across multi-vendor network domains can be substantial as many network devices have to be configured and managed, often with specific proprietary interfaces. Nevertheless, the development of vendor equipment adapters in the orchestration platform to cope with proprietary CLI and varying administration protocols is a prospective cost that industry players want to avoid and is based on a short term view of the problem.

Verizon’s white paper on its SDN/NFV strategy confirms that cross-domain and cross-vendor programmability is key to meet the dynamicity promised by SDN/NFV services. In order to replace a myriad of element management systems (EMS) tied to network elements with proprietary protocols and interfaces, Verizon recommends in the near term to use domain-specific SDN controllers to manage vendor-specific network elements.

Looking at the longer-term perspective, there is an opportunity to unify a diverse set of provisioning and configuration chains under a common NETCONF/YANG umbrella to simplify integration, operation and maintenance. NETCONF/YANG provides a perfect programmatic interface to prolong the orchestration domain and configure end-to-end service chains on-demand by spawning VNFs in the NFVI and steering traffic according to service requirements across the network.
The significant traction of NETCONF/YANG in the multi-vendor orchestration space makes it a good fit to streamline the integration of end-to-end automated SDN/NFV services. The support of NETCONF/YANG by a number of commercial orchestration platforms (Ciena Blue Planet, WebNMS, Cisco NSO,...) and the standardization of YANG modules by the MEF (Metro Ethernet Forum) for the orchestration of Carrier Ethernet 2.0 services add momentum to an already fast moving trend toward a NETCONF/YANG end-to-end orchestrated network model.

See full post

NFV: The Current State of Play

SDN_NFV_virtualization_virtualizasation_lights_lumires_blue_bleu_tunnel

Act One of the NFV show has finished, leaving operators to sift through the hype, piece together what they have learned and knuckle down to the serious business of design, feasibility and business case development. Pravin Mirchandani, CMO and NFV Evangelist at OneAccess, recounts some sentiments and soundbites from the NFV circuit.

1. Whoa! NFV is expensive!

Operators have now moved beyond best guess, back-of-the-envelope cost estimates. At least some measured CAPEX projections are in, and with them comes a grudging realization of quite how costly NFV is going to be. Why? Because operators must build x86 server farms right across their network in order to host their NFV infrastructure (NFVi); something which is going to mean a significant investment up front. What’s more, because virtualized traffic management requires the NFVi to be distributed (to provide appropriate location of network functions and traffic management right across the geographic reaches of the network), savings can’t be made by consolidating these farms on a single location. Sitting on top of the compute infrastructure, there is of course the software infrastructure and network functions, which also needs to be funded. What this has resulted in is a marked shift in focus to citing OPEX savings, service velocity and service agility as the main justifications for NFV, away from CAPEX reductions

2. We need SLAs, not just I/O

To date, when considering performance, the industry’s focus has been on input/output (I/O) but, given that virtualized network functions (VNFs) are sold as services to paying customers, I/O is only half of the story. To be commercial contenders, VNFs need to be associated with performance guarantees that are enshrined in service level agreements (SLAs). Further, an assessment of compute and memory footprint for each network function is required in order to assess deployment scalability. This is no great challenge where dedicated hardware is concerned, but when the network function is software-based (as with a VNF), located on a shared computing platform, the factors influencing performance are dependent on a range of resource-related variables, making guarantees harder to establish. This area needs serious attention before the NFV can move into a fully commercial phase with the major operators.

3. Pricing is all over the map

Many operators won’t open the door to a VNF vendor without full disclosure of their pricing model, especially as a couple of leading vendors have announced pricing levels that are considered by the operators as unreasonable. Pricing models also remain fragmented between vendors, making it difficult for operators to compare like for like. The software element, in particular, is a minefield. Unsurprisingly, some vendors are applying NFV pricing in accordance with the anticipated impact that NFV will have on their future hardware revenues. This is distorting the market at a very early stage, inhibiting assessment by the operator community.

4. VNF trials are defined by what’s available, not by what’s needed

A lamentable result of the current NFV market is that operators’ choices of VNF trials are being defined by availability, not strategic objectives. vCPE and virtual firewall functions have both been around for a while, but are these two functions the only ones that the operators want to do? Perhaps it’s too early to say. In any case, the real focus of today’s VNF trials is to successfully build the NFVi and nail down the orchestration and management pieces. In this sense, it doesn’t yet matter what the actual VNF is. Over time, this will change. Operators will begin to assess which VNFs are the most important for their business, and which will save them the most money? Ideally, operators should be bringing this thinking forward; if they settle on VNFs that differ from those they have trialled, it will be a struggle to understand the commercial, technical and operational implications.

See full post

SDN/NFV – Is it the breakthrough CSPs need to help level the OTT playing field?

acceleration-techniques-for-white-box-cpe

I think that it is fair to say that the business communications services market is going through one of its most challenging periods at the moment as CSPs struggle to come to terms with the demand for faster, more reliable and feature-rich services from their customers, whilst also dealing with increased competition and the inevitable pressure this puts on prices. Although this is a typical and predictable scenario in what is a rapidly maturing tech-based market, it means that service providers cannot afford to assume that their customers will continue to renew their contracts out of a sense of loyalty, no matter what.

With increased choices for core communications requirements such as telephony and business application services readily available from specialist 3rd party providers in the Cloud, the CSPs’ pipe is now in danger of becoming regarded as just another basic utility along with the mains power and water services any organization needs to function. The challenge for CSPs is to find ways to tap into the new revenue potential, and compensate for ARPU decreases, by offering innovative new services themselves and fighting back against the OTT players who are increasingly eating more of their lunch. But it is not easy to see how this can be achieved without a radical change to their existing core infrastructure and CPE access technologies.

Given this challenging picture, the arrival of SDN/NFV technology on the scene could be the timely and welcome development CSPs have been looking for. With the potential to level the playing field and enabling the rapid rollout of new services virtually on demand, service providers could realistically begin to compete on price, features and functionality with pure-play hosted service operators.

SDN, and NFV functionality in particular provides the prospect of enabling service providers to add new features or switch existing services on and off in alignment with customers’ changing needs without having to install new network edge devices or change the CPE. When combined with the ability to remotely manage and provision unlimited numbers of individual routers from a central office location it means the proposition could literally be a game-changer for service providers.

SDN/NFV however, represents both opportunity and challenge for CSPs. Its promise of agility, flexibility and reduced costs are highly attractive but implementing SDN/NFV across their current silo-based organization and changing well-established business practices will be a non-trivial and lengthy set of people-oriented tasks to navigate. CSPs are also looking to vendors to progress beyond architectural and vision statements and show them some real use-cases for this new technology.

See full post

Latest News

  • EKINOPS completes the acquisition of OTN technology from Padtec

    EKINOPS (Euronext Paris - FR0011466069 – EKI), a leading supplier of telecommunications solutions for telecom operators, today completes the acquisition of the OTN-Switch (Optical Transport Network) platform developed by Padtec, an optical communications system manufacturer based in Brazil.

     
  • A record 2nd quarter with sequential growth of 17%. H1 2019: revenue of €45 million and expected improvement in EBITDA margin

    EKINOPS (Euronext Paris - FR0011466069 – EKI), a leading supplier of telecommunications solutions for telecom operators, has published its revenue for the second quarter of 2019.

     
  • EKINOPS Launches Channel Partner Program in EMEA and APAC

    EKINOPS (Euronext Paris - FR0011466069 – EKI), a leading supplier of optical transport equipment and router solutions, today announces the launch of the EKINOPS Channel Partner Program (ECPP). The program has been designed to support value-added resellers (VARs) and system integrators to differentiate in the market by providing them with the opportunity to build, sell and deliver solutions tailored to their customer needs, while still benefitting from the Ekinops’ extensive knowledge, resources and expertise.

     

EKINOPS Worldwide

EKINOPS EMEA & APAC
Telephone +33 (0)1 77 71 12 00

EKINOPS AMERICAS
Telephone +1 (571) 385-4103

 

E-MAIL ALERTS

Receive automatically EKINOPS information in your inbox!