Enabling 10G Networks Using Flexible MAC Architecture
By Colin Howlett
As with most technologies, DOCSIS has gone through bundling and unbundling phases over the last decade in the bundling of separate edge-QAM modulator and DOCSIS CMTS in an integrated centralized CCAP, then unbundling again with remote PHY using CCAP cores and distributed remote PHY devices (RPDs). Distributed access architectures are the future, and while not all segments of the network need the higher capacity, they would benefit from the reliability, latency, and security benefits included as part of the 10G platform.
How does an operator bridge this mix of access architectures as the network evolves to 10G?
One initiative designed to solve these problems for operators is CableLabs® flexible MAC architecture (FMA), a disaggregated headend architecture which supports a mix of access network components with standardized multi-vendor interoperability.
Why FMA?
Why did operators and vendors kick off the FMA initiative? The FMA work at CableLabs started as remote PHY, and moved from standards to early trials; operators were starting to better understand the deployment challenges of the remote PHY architecture as they moved from the aggregated CCAP to a disaggregated and virtualized CCAP core(s) with RPDs. While CCAP had bundled the CMTS and video edge-QAM modulators to minimize RF and increase density in the headend, DAA was unbundling those same components in different ways (remote PHY and remote MACPHY), with several choices for how networking, MAC, and PHY functions could be distributed between the various physical chassis and virtual implementations. The key goals being incorporated into the flexible MAC architecture specifications include:
Unified Deployment Architecture — A common interoperable management architecture that supports distributed or centralized DOCSIS, with flexible location of MAC functions in headends or outside plant, and support for physical or virtual implementation of the components.
Disaggregate the CCAP — Support the transition of cable access from highly integrated physical chassis into disaggregated components by carefully splitting management, control, and data planes into separate elements in an interoperable way.
Modernize Access (HERD) — Support a move to API-driven configuration and model-driven telemetry based on RESTCONF/YANG with capability for software defined network (SDN) and network functions virtualization (NFV) built into the architecture.
FMA Overview
The FMA architecture contains three primary components:
MAC Manager — A centralized, virtualized management component that aggregates many MAC NE devices together to look like a large integrated CCAP device, providing both existing OSS and eventually new modern OSS interfaces northbound to operational support systems while communicating with the MAC NE over an interoperable southbound interface based on RESTCONF/YANG.
MAC Network Element — A generalized name for a device that delivers MAC and/or PHY functionality and includes remote MACPHY devices, remote PHY devices, and CCAP cores.
CIN — An IP-based spine/leaf interconnect network that provides a secure transport from MAC NE to the operator network. The initial phase of FMA specifies a standard, interoperable data forwarding model for remote MACPHY devices to ensure that RMDs can work with existing IP networking technologies.
Further, taking an SDN approach the architecture considers the management plane, control plane, and data plane as separate self-contained entities that are disaggregated and communicate over open interfaces.
1. Management Plane
The management plane is contained within the MAC manager. It is focused on device aggregation, configuration, metrics and statistics, alarm management, and other management plane considerations. The MAC manager does not contain any data plane requirements and does not need to implement line-rate packet processing.
2. Control Plane
The control plane is contained within MAC NE devices, such as the RMD or RMC. It is focused on runtime state management, command processing, topology management, and other control plane considerations. The MAC NE can contain both the control plane and data plane, but the architecture also allows these concerns to be split.
3. Data Plane
The data plane is contained within MAC-NE devices, such as RMD. It is focused on line-rate packet processing, buffering, shaping, and other per-packet operations.
Additionally, FMA leverages the work already done for remote PHY to support traditional QAM STB video and control plane as well as the various unique outside plant signals needed for sweep, amplifier level control, and leakage/ingress detection. This approach ensures compatibility and consistency between deployed R-PHY and newer FMA components as operators start deploying FMA.
MAC Manager
The MAC manager provides interfaces in two directions: northbound to the OSS tools and southbound to the MAC NE. The MAC manager aggregates all the MAC NE devices to appear like a large-scale version of an existing CCAP. The MAC manager can be located anywhere in the network with suitable connectivity to the MAC elements and would typically be centralized in a data center serving hundreds or thousands of attached MAC NE.
Northbound is the alphabet soup of traditional protocols used by existing OSS tools to manage CMTS and CCAP devices such as IPDR, PNM, and SNMP. FMA includes placeholders for future phases to move to modern API-based configuration, model-driven telemetry, and SDN control of the network elements.
Southbound to the MAC elements is a new interface, the FMA MAC manager interface or FMA-MMI. FMA-MMI is built on top of a clearly defined YANG model using RESTCONF (REST-based HTTPS) transport. The key considerations for the move to this interface from what was used in remote PHY is to greatly ease interoperability with a standard machine-readable YANG data model and to allow easy development of tools that talk directly to MAC elements using common REST-based mechanisms.
MAC Network Elements
MAC NE is a generic term representing the diversity of implementations and locations of the DOCSIS MAC in the network. Operators and vendors continue to innovate and iterate on specific implementations, but the list of MAC NE being contemplated for FMA include:
Remote MACPHY Device (RMD) — MAC+PHY co-located in the node housing or a rack-mount shelf device. RMD contains physical components (it’s hard to virtualize the PHY!) generally deployed in untrusted remote locations.
Virtual CCAP Core (vCore) — Virtual network function for the DOCSIS MAC and data forwarding which supports subtended remote PHY devices (RPDs). The RPDs contain the DOCSIS and video PHY functions and are located either in the node housing or a rack-mount shelf device. The vCore element is deployed as a virtual function in COTS servers deployed in a trusted controlled environment such as a data center or headend.
Physical CCAP Core (pCore) — Physical network function for the DOCSIS MAC and data forwarding, implemented in purpose-built hardware deployed in a trusted controlled environment such as a hub. pCore generally refers to DOCSIS CCAP cores which support subtended RPDs, but could also include centralized CCAP chassis with integrated RF.
Remote MAC Core (RMC) — Physical network function for DOCSIS MAC and data forwarding, implemented in purpose-built hardware deployed in an untrusted remote location. RMC allow for movement of MAC functions closer to subtended RPDs than a pCore or vCore.
FMA Enables…
Now that we understand FMA and where it’s going, what does this enable for operators in the move to 10G networks?
Mixed deployment models — Centralized CCAP, virtual CCAP core, RPD, RMD, and/or RMC with an operator choosing where to deploy MAC functions based on the specific needs of each part of their network. MAC manager offers a common management interface and a common spine/leaf interconnect can be used between MAC NEs, MAC managers, and the core network. Operators can maintain centralized DOCSIS 3.1 CCAP in areas where capacity requirements are low while moving to DOCSIS 4.0 RMD in locations where customer demand is high.
Multi-vendor interoperability — Interoperability is a foundational pillar of FMA. A common standardized framework gives operators more vendor options than ever before to build open and interoperable access networks using a mix of best of breed technologies and vendors.
Modernized access architecture — FMA opens the path to more modern APIs between elements. Disaggregation of the CCAP allows data, control, and management planes to be distributed in the network and virtualized. RMD and RMC variants move the edge of the DOCSIS portion closer to the subscriber so more of the core network and OSP backbone can be standard packet-switched and routed network shared with other services such as FTTH, business services, and mobile transport.
FMA enables a strong foundation for 10G deployment!
Colin Howlett,
VP Architecture,
Vecima
Colin Howlett is responsible for defining overall technology strategy at Vecima and an active participant in industry standards development at CableLabs and SCTE•ISBE in the areas of DOCSIS and distributed access architectures. Colin holds multiple patents in cable broadband access, a Bachelor of Electrical Engineering degree and Bachelor of Computer Science degree from the University of Saskatchewan.
