Back in 2016 VMware joined the Broadband Forum (BBF), a consortium of Telecommunication Service Providers, System Integrators and Technology Vendors, as the first Software Vendor. The BBF, amongst other things, develops best practices for the ‘Cloud Central Office’ (CloudCO), a next generating Central Office deployment. CloudCO makes innovative use of the following attributes:
- A Cloud ‘Anything-as-as-service’ (Xaas) consumption interface,
- Network Function Virtualization (NFV), and
- Software-Defined Networking (SDN) and Ultra-Fast access (and when formally defined 5G).
The aim is to deliver ultra-fast broadband services with distributed compute and storage to anywhere and any device in home or business locations. I have been personally very active at the Broadband Forum as the Cloud Central Office Project Stream Leader, setting out the direction and leading the work. For some history on the Cloud CO project, check my previous blog post here.
The Cloud Central Office Project Stream has accomplished quite a lot already:
- Defined the Cloud Central Office Reference Architectural Framework in TR-384.
- Delivered Applicability Scenarios and suggested legacy Use Cases that had to be supported on a Cloud Central Office based architecture, in TR-416.
Work is progressing on Interface Descriptions (WT-411), a catalogue of Test Cases (WT-412) to verify and/or augment these interfaces. Other work includes co-existence with, and migration from legacy Broadband Architectures (WT-408), amongst other things. Check out my update videos on the BBF website where I elaborate on the progress made to date!
What is the Cloud Central Office?
A TR-384 based architecture aims to disaggregate a lot of the functionality that used to live in monolithic devices such as Broadband Network Gateways (BNG) and other devices. These devices will be de-composed into various Virtual Network Functions (VNFs), and onboarded onto a Network Function Virtualization Infrastructure (NFVI). Access Devices will also leverage disaggregation in order to move the control and management plane functions to the NFVI, while using SDN to send traffic to the NFVI hosted VNFs. The NFVI will be implemented on a Software Defined Data Center inside the Central Office i.e. leveraging commodity switches and x86-based servers, such as the one depicted in Figure 1 . IETF NVO3-style Overlays are leveraged for connectivity and security across the NFVI.
SDN techniques steers Broadband Traffic received from the user at Access I/O devices to the VNFs inside the NFVI. The Access I/O Control Plane and Management Plane moves off-box by leveraging SDN as well. After going through the various Network Functions inside the NFVI, traffic travels to the Network I/O devices towards its destination.
The Cloud Central Office Architectural Framework
Although TR-384 is based on the philosophy of certain Open Source projects, it is not ‘yet-another-open-source’ project. TR-384 defines ‘black boxes’ of functionality inside Functional Modules, with Interfaces describing how these Functional Modules interoperate. In other words, it defines WHAT the functional modules do, but not HOW to achieve the functionality. Open and common Interface descriptions achieves interoperability between those functional modules, regardless whether implementing leveraging Open Source software, or Vendor Provider Software. TR-384’s architectural framework, shown in Figure 2 below,is compliant with ETSI’s NFV Reference Model. It adds a couple of extra SDN related components, to allow interworking between Physical Network Functions (such as Access-facing, and Network-facing functions, amongst others), and the VNFs running inside the Cloud Central Office NFVI.
The exact nature and definitions of those Interfaces is still a work in progress and will be documented in WT-411. WT-411 will re-use interfaces available in the industry (Open Standards, or Open Source) as much as possible, and where functionality is missing, it will generate requirements for Standard definitions, or requirements for upstreaming new functionality in Open Source projects, where applicable. The way that these eventual new requirements will come to light is by using an Agile Methodology through the use of Application Notes, or AppNotes (for a set of publicly available AppNotes, see here). AppNotes will also become a way for Communication Service Providers to define new and innovative services , using the TR-384 Architectural Framework.
AppNotes are a set of interactions between Cloud Central Office Functional Modules, typically starting with a given actor initiating an interaction at the Cloud Central Office Domain Level Northbound API, or an actor initiating a data plane flow. The set of Interactions lead to requirements for the Interfaces. In order to generate those requirements, the AppNote is instantiated running on a real-life Cloud Central Office architecture (see my Open Broadband Lab post here) and will be tested against a set of Test Cases, which will be defined in another set of work i.e. WT-412. This might result in new requirements for Open Interface and/or Upstreaming into existing Open Source Projects. Figure 3 shows the relationship between AppNotes, Interface work (WT-411) and Testing efforts (WT-412).
Why is this work important for VMware?
Our VMware vCloud NFV solution, leveraging VMware NSX, aims to be an NFVI that is truly vendor independent, both from an Underlay, as well as from an VNF perspective. It is our believe that Open standards and open interfaces, combined with a vendor-independent NFV infrastructure, are essential for operators looking for a cost-effective and smooth migration to next-generation architectures. Broadband Forum’s AppNote approach aims to define Open Interface specifications, while guaranteeing multi-vendor interoperability, and that is why we are very exited about helping out the industry with this work.
I hope this update has been useful and don’t hesitate to reach out to me if you have remarks or questions!