The progressive virtualization of network functions and the expanding use of containers, both stateful and stateless, are rapidly increasing the complexity of management and orchestration of network functions and associated network resources, computing and storage, for services generation.
This has triggered innovation in management platforms such as OpenDaylight
, Kubernetes, policy-based configurations and more. Central Office Re-Architected as a Datacenter (CORD) is unique in that its focus includes network management at the edge or the last mile. (See CORD Becomes New Open Source Project.)
In Part 1 of this Q&A, Telco Transformation spoke to Tom Anschutz, Distinguished Member of Technical Staff at AT&T, about the value of CORD as a management platform. In Part II, Anschutz explains how CORD was designed to use containers and open networking at the network edge.
In his role as a network architect, Anschutz was instrumental in the development of AT&T's software-centric network, and in advancing the key technologies that support it, including SDN and NFV. He is the editor and chief contributor to AT&T's Domain 2.0 Vision white paper that describes a large transformative initiative to improve public networking and cloud computing.
Telco Transformation: Several management and orchestration platforms and frameworks, namely Kubernates, policy-based and OpenDaylight among others, have emerged with the increasing modularization of network functions and associated resources to provide the tools for the automation of service generation. What gave rise to the need for CORD?
Tom Anschutz: CORD is not just another management platform compared to Kubernetes or OpenDaylight. CORD is an integration of many existing platforms into a reference implementation that supports actual services and typical carrier functions. Within CORD you will find OpenStack , ONOS and XOS, as well as applications that solve carrier problems, like broadband, wireless, or Metro Ethernet services. Kubernetes, OpenDaylight and other existing "platforms" don't provide complete solutions on their own.
Having said this, CORD is still not a complete carrier solution, and should be viewed within a perspective of a hierarchy of network control. A centralized control plane (such as AT&T’s ECOMP) is typically used for end-to-end network management while a local control plane (CORD), with some autonomous features, serves distinct local needs. The hierarchy of control is desired in response to the timing of the control feedback loops. Shorter response times are needed for functions such as interactions with IPTVs or mobile devices. These are best served with the least latency by a local control plane.
By contrast, less timing sensitive controls are inclined to be centralized. CORD is both a management platform for the network infrastructure as well as that infrastructure and associated applications to perform useful services. It can enable bootstrapping of the infrastructure at the local level, and provide simplified, abstracted APIs to global orchestrators. However, the XOS system in CORD does include enough service orchestration, GUI and completeness for institutions such as universities, research laboratories, or small networks to have fully functional systems. They will be able to build self-contained infrastructure locally with CORD for needs such as research and a proof-of-concept.
TT: Local controllers presumably work in concert with centralized controllers. Could you explain how CORD coordinates with centralized controllers and has the need for this grown lately?
TA: Telecom architects have traditionally placed all levers of control, over any kind of function -- major or minor -- within a single layer, which is the classic management system. The management of all manner of minutiae needlessly added to overheads as resources were expended on configuring every detail to provide an end-to-end service and for managing the attendant operational complexity.
I would instead want to have several tiers of abstraction where the details become the responsibility of local controllers who will also monitor performance and the infrastructure to achieve it. Customer experience improves when, for example, signals sent from the remote controls of TVs of customers to change the streams of media content are processed at the local central office rather than at the core of the network.
Legacy infrastructure did have some control intelligence distributed to routers for optimizing traffic flows and with SDN/NFV similar decision points are available to respond to problems such as link failures. This distribution and abstraction of control will free central controllers to focus on more complex, end-to-end challenges in deploying services.
CORD hides complexity in its system through the XOS northbound interface, and that makes the global orchestration job simpler and more focused on service orchestration rather than infrastructure management. Attempts to achieve similar objectives with policy-based management have not come to fruition in the absence of multiple levels of abstraction.
TT: How do the methods of management and orchestration evolve for service generation with containers in a telco environment?
TA: Containers are lighter-weight and they need to scale elastically with incremental addition of resources as more microservices are consumed. They are typically used to support microservices that combine functionality and its management in a single system.
By contrast, virtualized machines typically call their element management systems (EMS) to deploy discrete resources almost as physical infrastructures did. Previously, the work of integration expanded disproportionally as the heterogeneity of IT systems and associated EMS and resources such as servers grew in the operating environment of service providers.
In a container environment, the familiar EMS becomes redundant as they are replaced by model-based methods that we have defined in our ECOMP system as well as other third-party tools. The service is managed with NETCONF and other protocols that use a common service orchestrator with the ability to compile the capability required instead of a costly IT development cycle that was the norm in the past.
So you have a model that describes how a service can be created, another model describes network or virtual network functions capabilities. From an orchestration perspective, a controller provides the means to bring together the processes of service creation and network functions to provide a service.
— Kishore Jethanandani, Contributing Writer, Telco Transformation