CORD : Telefónica and R-CORD

April 2020 Update

Since our last update and due to some differences between our design fundamentals and CORD’s Architecture, we have been adapting the R-CORD reference architecture to our CTpd Architecture’s overlay/underlay needs to accommodate different MVPs and field tests. This has helped us deploy and validate a disaggregated SDN-based Edge Computing capable solution as a replacement to our legacy designed HTTP Central Offices.

Some weeks ago, after a thorough architectural and functional revision, we decided to go for a full upgrade of our SDN stack to approximate CORD's SEBA Reference Architecture but enhanced with our current Edge Computing functionality. This required us to shift the way we used to deploy some components in VMs on top of KVM to containers fully managed by Kubernetes. We already adopted containers as the de facto entity to operate VOLTHA some time ago, but because operational and design concerns, we kept ONOS running on VM clusters, as we do with other Edge Computing services. 

Due to changes in requirements, we have also decided to embrace the Kubernetes orchestration patterns and see how it fits inside OnLife's CTpd architecture. Additionally, we have done exhaustive code refactoring, removing most changes we introduced on both ONOS and VOLTHA so now we can use Community VOLTHA and ONOS Core releases.

A real game-changer for this has been the wonderful work laid out on Ciena’s kind-voltha project. It helped us immensely to get a fully customizable stack running very fast. Even for users with little to none experience in Kubernetes. That sort of detailed picture has provided a sandbox in which we could perform E2E tests with the heterogeneous hardware we have been working so far.

Having all these milestones in mind, we have achieved a very promising and functional ONOS & VOLTHA setup on our test lab with very little tweaking. I dare to say, it is almost identical in features to the environment currently running in production to support our production pilots in Madrid.

While we keep working to validate further a Kubernetes-managed SDN control plane, e.g. by testing L2 ingress controllers for those OLTs that use frames for discovery and control messages. We also hit a bit of a wall when it comes to ONOS. We are talking about the highly available cluster setup supported by an underlying ATOMIX. While in version 1.14 this turned out pretty much straightforward, moving to newer versions has not been possible thus far. 

We tested with a few different version combinations but have been unable to isolate the root cause behind the failures that cause ONOS to fail and fall into a CrashLoopBackOff state. We have not found any additional configuration required when upgrading to ONOS 2.X. But this theory did not sustain after testing a cluster setup deployed on top of VMs.

On a more functional plane, during our production phase, we have identified some potential bugs in ONOS. Those are related mostly to how the handling of intents and request packets is done and to OpenFlow packet-in throttling. We would like to discuss and clarify the best way to contribute them.

As mentioned before, for SDN fabric we use our own CLOSfwd app, specifically built for the needs of a CO switching fabric control, to enable edge services and vCPE (vPdC in Spanish) requirements while using cost effective OFDPA switches. One key feature of this app is the vCPE traffic bypass capability depending on the service being supported. We are willing to contribute to the ONF community our CLOSfwd application, to further its utilization and add functionality as new Edge Computing use cases arise.

Regarding OLT integration with VOLTHA, we have been using both GPON and XGS-PON OLTs from manufacturers such as Celestica, TIBIT, Adtran and EdgeCore. For the Celestica OLT, we contributed already code for VOLTHA 1.4 and would consider porting to 2.2 if it is of interest to the Community. In this process we also adopted official vOLT app and moved the self-provisioning scenario to a complementary app that could be also released.

This shift on OnLife's development has also made us pause and re-think our way to interact with ONF projects. We want to take the next step in this journey and give back to ONOS and VOLTHA communities and contribute some of our learnings along the way. For this, we would appreciate support from the community too to help us meet all requirements to contribute in a proper and non-intrusive approach according to ongoing planification and deliverables from all teams.

July 2017 Update

During this month of July we received approval to move into a pilot with Customers of Telefónica España, expected duration of the Pilot is six months starting September 2017. Both Residential and Enterprise use cases will be part of this phase.

May 2017 Update

At the end of April 2017, we successfully concluded Phase 2 “Prototyping” of the OnLife Network, during this phase a production ready prototype was built with the necessary software and hardware.

The software was integrated in-house by Telefónica I+D with collaboration of Telcaria in the ONOS side and OpenNebula Systems for the OpenNebula. The 18 members Team incorporates Architects, Engineers, Developers and Product Developers with key specialist from our operators, Telefónica de España and Telefónica Business Solutions.

During the Phase 2 Stage Gate we demonstrated a fully functional prototype with an enhanced version of Telefónica’s Fusión residential service and two enterprise use cases, namely a SD-WAN provided by Navista and a cache by Qwilt. We also successfully integrated SBC solutions from Metaswitch and FreeSwitch.

The infrastructure is placed in an OpenRack v2, powered at -48vDC, the complete POD was designed, supplied and assembled by Amax in Ireland following our specifications, then shipped and deployed in the Madrid Peñuelas CO’s TechLab. The rack assembly shown in the photo is composed of

In an adjacent rack:

• Fujitsu successfully tested their GPON vOLT
• Intel provided 2 servers for load testing
• NetApp installed a storage appliance with HDD and SDD.

We have started Phase 3 and In September 2017 we will initiate Beta Testing with residential and SBE customers in Madrid. In this Phase we will also build the integration to our commercial and operations systems for complete orchestration of our Customer’s product and services delivery, maintenance and incidents resolution.

OnLife Networks Description

At Telefónica’s Product Innovation - Customer Centric Networks department we are developing a CORD-based solution for our PON access network named OnLife Network, we have made a slight variation on the choice of components of our solution, but the ONOS-CORD fundamental principles and constructs are being fully utilized.

Taking at heart “everything as a Service XaaS” the aim of our CTpd architecture is to migrate Telefónica’s current residential and business monolithic services to programmable IP services, and to host a new generation of edge-computing services that are furnished not only by Telefónica but from any third party that wants to benefit from a CO’s proximity to the Users.

The architectural components chosen for our implementation are depicted in the following diagram:

We opted for an all-IPv6 solution in the data plane which allows us to provide advanced networking solutions to our residential customers that otherwise are quite cumbersome to implement.

Right now we are actively contributing in the VOLTHA development.