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

Why NETCONF beats OpenStack when managing uCPE

site-541197_1920

I know this question reads like comparing apples with oranges. In fact, I want to compare a uCPE managed with NETCONF versus a uCPE managed as an OpenStack compute node. First, it’s worth looking at why people think using OpenStack is a good idea.

OpenStack is THE open-source Virtualization Infrastructure Manager (VIM). As operators virtualize their data centers, OpenStack is pretty much the only solution if they want to move away from VMware. As operators move to OpenStack, they can extend it to manage Virtualized Network Functions (VNFs) in branches. The benefit looks obvious: one team in charge of both data center and branch virtualization and a streamlined software layer to deploy and manage.

In many ways, NETCONF vs OpenStack is a political decision. One that determines whether a combination of DevOps culture and IT teams will take power.

OpenStack: Free as in freedom, not as in price

OpenStack is not a piece of software, but rather a distribution of modules with heterogeneous documentation. More importantly, putting OpenStack into production requires the gathering of a critical mass of skilled experts. You need a good set of experienced architects who know what works, what does not and what will fail if you do things in a certain way. One well-known issue with OpenStack, for example, concerns planning upgrades. This is not a trivial job; VMware still makes a lot of money and Redhat or Mirantis put massive effort into packaging and supporting OpenStack.[1]

OpenStack was conceived for data centers

Using OpenStack for uCPE is about deploying VNFs where it makes sense, i.e. the trade-off between cost, latency and security. It implies VNFs would be seamlessly chained between a datacenter and branches. Extending OpenStack to the branch, however, poses challenges, the biggest of which is security. When VNFs are contained within a data center, the security perimeter is clearly defined. In contrast, deploying VNF in branches means the security boundaries are more open-ended as connections can be made to new customer branches. In this case, openness and security often contradict each other.

See full post

Unpacking the technologies behind the Zero-Touch Provisioning of a universal CPE

uCPE

Explore the combination of technologies that enable remote provisioning and management of the uCPE and the VNFs this powerful new device supports.

A Universal Customer Premises Equipment (uCPE) consists of both software and hardware components to create a small virtualization platform at the customer premises and which is capable of running multiple Virtual Network Functions (VNFs) in a local service chain. This is similar to running Virtualized Network Functions in the datacentre but at a smaller scale. This enables Communication Service Providers (CSPs) to disaggregate software and hardware at the CPE level and provides them with unprecedented flexibility to run any type of service on the same commoditized hardware platform.

The services delivered by this programmable end-user device are in general controlled by Next Generation Service Orchestrators, who take care of the service configuration aspects of the delivered services. Another level of Orchestration concerns the deployment of the uCPE in the field. One of the challenges is to minimize its deployment cost using zero-touch provisioning. Pushing a new configuration to a uCPE is more complicated than to legacy CPEs because not only the configuration of the uCPE needs to be pushed to the device, but also the service chaining topology and the VNF images with their initial configurations. Using the NETCONF/YANG protocol however it is possible to push the complete initial configuration to the uCPE including the service chaining configuration and the VNF images with their initial start-up configuration. The initial communication with the provisioning server can be achieved using the NETCONF Call Home functionality, which allows the CPE to identify itself to the provisioning server and receive the correct configuration associated with the customer where the device is installed.

With zero-touch provisioning it is possible to install a uCPE and its configuration in an automated way. In many cases, however, end-to-end orchestration systems don’t support zero-touch provisioning yet or provisioning systems are not in place or sufficiently mature to support this level of automation.

In addition to the OneAccess-branded uCPE hardware (OVP or Open Virtualized Platform) and software (LIM or Local Infrastructure Manager), EKINOPS also offers OneManage to provide a solution for zero-touch provisioning of uCPEs based on a service catalog. OneManage supports a northbound interface to interface with OSS/BSS systems to receive customer-related data associated with a new uCPE deployment. In this way OneManage is an infrastructure orchestrator or sub-orchestrator, taking care of the provisioning of the uCPEs and the management of the installed uCPE base.

See full post

Why the time to move to NETCONF/YANG is now

time_to_move_netconf

With backing from major NFV/SDN projects and industry organizations, NETCONF, the client/server protocol designed to configure network devices more clearly and effectively, will soon become ubiquitous. Operators who migrate to NETCONF can both future-proof their operations for NFV and can also reap some of short-term benefits of automation, today.

Why NETCONF/YANG?

By addressing the shortcomings of existing network configuration protocols like Simple Network Management Protocol (SNMP) and Command Line Interface (CLI), NETCONF was developed to enable more efficient and effective network management. SNMP has long been cast off by operators and CSPs as hopelessly complicated and difficult to decipher. CLI may be readable by a network engineer, but it is prone to human error and can lead to vendor lock-in, since propriertary implementations often mean that only one vendor’s element management system can manage their network elements.

NETCONF, on the other hand, is designed specifically with programmability in mind, making it perfect for an automated, software-based environment. It enables a range of functions to be delivered automatically in the network, while maintaining flexibility and vendor independence (by removing the network’s dependence on device-specific CLI scripts). NETCONF also offers network management that is not only human readable, but also supports operations like transaction-based provisioning, querying, editing and deletion of configuration data.

YANG is the telecom-specific modelling language that makes NETCONF useful, by describing device configuration and state information that can be transported via the NETCONF protocol. The configuration is plain text and human-readable, plus it’s easy to copy and paste and compare between devices and services. Together, NETCONF and YANG can deliver a thus far elusive mix of predictability and automation.

NFV needs NETCONF

What’s even more powerful is that NETCONF and YANG combined offer the flexibility needed to manage both virtual and physical devices. This means that operators can get going with NETCONF now, before they start ripping out old devices and replacing them with white boxes. This is a necessary investment in the future; as we look forward to a virtualized networking environment, where network functions are spun up and changed continuously, the high level of automation enabled by NETCONF/YANG is not just preferable, it is essential.

See full post

The Song of the Sirens: Five ways to spot hidden NFV vendor lock-in

the-song-of-the-sirens-five-ways-to-spot-hidden-nfv-vendor-lock-in

One of the big attractions of NFV is that it gives operators a chance to break free of single vendor contracts and establish greater control over the future development of their networks.

Genuinely ‘open NFV’ gives operators the ability to change tack according to technical and commercial developments. It enables them to shop around for best of breed solutions and blend a mixture of, say, migration-oriented hybrid solutions with white or grey-box CPEs and connect them all to their choice of orchestrator. It also dramatically improves their negotiating power.

Yet, despite appearances, few NFV vendors practice ‘genuinely open NFV’ and instead disguise how they intend to close and lock the front door once their customer has stepped inside.

There are five common traps that vendors set for operators as they entice them toward ‘open NFV’ contracts:

#1 Charging for third-party connections

See full post

US Telcos Move Ahead on NFV as Europe Watches: 2017 Predictions

virtu2017

While huge progress has been made this year toward the development of virtualized services, a variety of challenges remain before widespread service roll-out can commence. 2017 will be the year that the industry takes positive steps to overcome these barriers, says Pravin Mirchandani, CMO at OneAccess Networks, who shares his five key predictions for the year ahead.

#1 Europe will stay on the sidelines as USA and Japan push on

We will see virtualized services start to roll out, principally in the USA, and to a lesser extent in Japan through NTT. While everyone remains sure that the way forward is virtualization, the industry is still figuring out how to solve the multiple technical, commercial and organizational challenges posed by migration.

Operators will be closely watching AT&T and its Domain 2.0 program and keeping an eye on Verizon too, in a bid to learn lessons about how to implement NFV. Europe’s hard-pressed operators, in particular, will mostly stay parked in ‘watch and learn’ mode, continuing with RFx, proof of concepts and trials. In fact, we’re unlikely to see any virtualized services roll out across Europe in 2017. Compelling business cases are harder to assemble in the European continent and, until these are squared away, operators will prefer to observe how US and Japanese trail-blazers facilitate service migration and preserve their choices – both major factors driving current and near-term investment decisions.

#2 NFV’s ROI equation will need to be cracked

See full post

Pushing through Glass Ceilings at the SDN World Congress 2016

imageSDNWorldCongress_TheHague_2016

Live from the SDN World Congress Show in The Hague, Pravin Mirchandani, CMO, EKINOPS, reflects on the industry challenges steering the dialogue at this year’s conference.

In Gartner’s hype cycle, there is an inevitable time of disillusionment that follows the initial excitement of a new technology. At the SDN World Congress this feels different: although we have probably passed the peak of inflated expectations, there is less a trough of disillusionment, rather a set of major impediments that need to be cleared away in order to achieve the nirvana of SDN/NFV. Most actors can see what needs to be done and are steadfastly supporting the initial objectives but my impression is that breaking through to achieve the goals of network virtualization is like pushing through the famous glass ceiling. Though not created by prejudice, as in the traditional definition of glass ceiling, the barriers are real and there are many.

Glass Ceiling 1: Complexity One of the goals of software-defined networking is to reduce dependence on an army of network experts, who are difficult to recruit and retain, expensive to hire and prone to error. What’s clear is that what they do is indeed complex; and converting their expertise and processes into automated software processes and APIs is equally if not more complex, as there is a distinct lack of established practices and field-proven code to draw upon. Many of the speakers at SDN World Congress mentioned the issue of complexity and this was a constant theme in the corridor discussions. Laurent Herr, VP of OSS at Orange Business Services stated that Orange estimated it would take 20,000 man-days to convert their tens of IT systems to achieve virtualization.

Glass Ceiling 2: Culture Another common theme was the issue of culture. Telcos have been organised to deliver the ‘procure-design-integrate-deploy’ cycle for new services and have a well-established set of linear processes and organizational silos to achieve it. Introducing virtualized services however requires a DevOps culture based on agility, fast failing (anathema to the internal cultures of Telcos) and rapid assembly of multi-skilled teams (especially collaboration between network and IT experts) to deliver new outcomes, frequently, fast and reliably. Achieving a DevOps culture was one of the most frequently cited challenges by the Telco speakers at the Congress. Another common word they used was transformation.

Glass Ceiling 3: Lack of Expertise It’s difficult to estimate the number of engineers that really understand the principles and practices of virtualization but they probably number in the low hundreds across the globe. Given the ability of the vendors to pay better salaries, it’s a safe bet that the majority work for them rather than for the Telcos. Growing this number is difficult as it requires combining IT, programming and network skills. Creating collaborative teams helps but finding or training people to achieve mastery of the different skills is a challenge for the whole industry. This was more of a corridor conversation rather than openly cited by the speakers but it is a glass ceiling nevertheless.

See full post

Fifty Shades of NFV?

fifty_shades_of_nfv

In the racy world of CPE architecture, what virtualization-hungry service providers say they want isn’t always what they need, says Pravin Mirchandani, CMO, EKINOPS.

Alright, perhaps ‘racy’ is going a bit far, but as the virtualization industry moves out of ‘does it work’ and into ‘let’s make it happen’, pulses are certainly starting to quicken. Not least because service providers are having to make tough calls about how to architect their management and orchestration (MANO). Many of these decisions revolve around the deployment of virtualized network functions (VNFs), via some form of customer premises equipment (CPE).

Several ‘shades’ are emerging, each with their advantages and drawbacks.

The ‘NETCONF-enabled CPE’ model emulates what we have today: a fixed number of physical network functions (note: not virtual) are embedded into a traditional L3 multi-service access router. The key difference here is that the router, as its name suggests, supports the NETCONF management protocol and can, as result, be managed in a virtualized environment. In truth, this is a pretty rudimentary form of virtualization; the router can be managed by a next-generation OSS with NETCONF and its embedded physical functions can be turned on and off remotely, but that’s about it. The device is not reprogrammable, nor can its network functions be removed or replaced with alternatives. The market for this deployment model lies in two use-cases: Firstly, as a bridging solution enabling service providers to co-operate traditional and virtualized network services simultaneously, facilitating migration. Secondly, given that many of today’s VNFs are heavy and need considerable amounts of memory and processing resources in order to operate, the more flexible white-box alternatives are costly in comparison. Specialist vendors like OneAccess have been developing dedicated CPE appliances (with embedded PNFs) for years, where compact and efficient code has always been a design goal in order to keep appliance costs under control. For more conservative operators that are keen to get ‘in the game’, the proven reliability and comparative cost efficiency of this model can offset its relatively limited flexibility. Rome wasn’t built in a day and some operators will prefer to nail the centralized management and orchestration piece before investing heavily in pure-play virtualization appliances for the network’s edge.

A purer approach is to invest in a ‘thick branch CPE’ or, in other words, an x86-based white-box solution running Linux, onto which VNF packages can be either pre-loaded and, in the future, removed and replaced or even selected by customers via, say, a web portal. This approach delivers far greater flexibility and is truer to the original promise of NFV, in which the network’s functions and components can be dismantled and recomposed in order to adjust a service offer. The snag, however is that white-box CPEs come at a cost. More memory and more processing power mean more cash. That’s why the race is on to develop compact VNFs, so they can minimize processing requirements and, as a result, enable a limited spec white-box to do more, with less. Again, unsurprisingly, those ahead of the curve are VNF vendors that have the experience of wringing every last drop of performance out of compact and cost-efficient appliances, purpose-designed for operators and service providers.

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

Do CLI Experts Need to Worry about Their Jobs?

do-cli-experts-need-to-worry-about-their-jobs

Our customers tell us that NETCONF is fast becoming the preferred way to provision virtualized networking devices. Tail-f has been the main advocate of this protocol, with a pitch that goes roughly as follows: “NETCONF provides the toolset to configure an end-to-end service with a single network-wide transaction. OSS programmers spend less time in handling error cases –as the role of transactions is precisely to ensure success and rollback in case of errors. You do not need to pay high-salary CLI experts to handle such rollbacks manually, when the OSS has failed to do it in a proper way. And you can now automate service creation at an unprecedented level.”

The more you automate the less people you need and with the transactional capabilities of NETCONF you do not need them to recover the disaster of accidental automation glitches. That has got to be rather scary for the cohorts of CCIE-certified engineers and other CLI experts, doesn’t it? Does it mean their expertise will become redundant? Do they need to find a new mission in life?

I recently met some CLI engineers. They see the change coming but as they are buried by the demands of their day-to-day activities, they have not yet had the time to study and experiment with NETCONF. So, this protocol along with YANG data modelling remains very abstract, if not confusing to them. Of course they understand quite clearly that NETCONF is about a programmatic approach to the process of service creation. Network engineers thus understand they must acquire new skills in programming but it is certainly not their comfort zone today.

In many cases, an OSS will not manipulate YANG models or NETCONF directly. The likely way to program network services is to use tools that generate an interface code from the relevant YANG models and programmers will use that API to create the services. For IT engineers, service creation is not much more than mapping a Service Abstract Layer (SAL) data model to objects on a set of networking functions or devices, nothing more.

But that is not the starting point for network engineers. Their initial steps are still the same (as before NETCONF): create a network design, prepare a reference setup, elaborate configuration templates, write troubleshooting guides, etc., with the notable difference being that such templates must be written in NETCONF XML. With OneAccess products, this is a fairly natural step: first create the reference configuration using the familiar Command-Line Interface, then use some commands to export it as XML or a set of xpath statements. Using this process, CLI can be mapped to NETCONF pretty intuitively. In other words, an extensive CLI knowledge is still a valuable asset for engineers. Working with NETCONF is then an easy next step and defining XML templates is after all not so difficult.

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!